From nobody Sat Apr 18 09:32:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB66E2E54A3; Sat, 28 Feb 2026 17:32:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299968; cv=none; b=LxT2nZpKHRczVIG9vsZHwECHryWzrsfIzxReuDLBDeti1c5M07sfn5LXIE3o/6wzhz2OVj9JHZEDBlS/7PebEPeMbM7m41QopUm4vbHgVWKt0DVCQumczVS7+g9MFSRFi9VT46Fi36igTJ+PeYNzJTWdJZ+vtPWEjKE/jhM4VWY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299968; c=relaxed/simple; bh=E9+cyPqKW0RtkA1EiJIhnyPK+6LSG9lKcHTsb9AatU0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VjsH20irYW79jmPNYlSdRwHwtI8xATWYlWcEXPOnKGbVLYdYThFOpTkDdSHuE9f1qZoAPZdBKz4j+rElcvbf98MBhdBPLwHt7oQKOIz+Pt/zCKYdnUoVOj1LnTYoWnF8Zqoc3ONBqu5IK+IXtp4pS3aGK2VGfg/vF9eqtE/bEEA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sgt9Kfb6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sgt9Kfb6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF1FAC19423; Sat, 28 Feb 2026 17:32:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299968; bh=E9+cyPqKW0RtkA1EiJIhnyPK+6LSG9lKcHTsb9AatU0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sgt9Kfb60UmOEVaau+dKycPAO+1uYHZ08vwrSngSPChuv+HcDgnZ8Jbg41A9tToFb FXpiw3oyPVpt5uBxO/2gL8RvfRgZqArU1mW6s2Z/V6MWNK6a0p2KPrejjwOmtImODt 95INj2UIUOZm/qh4QzTg+Lk75VFETYKa9iEYgJIn1aVSsxjBqrDuTJtoxcpzekYMAC leKwLZURfhqU9qwycNAHCmOOQpGd9TiDjRSeZBOM/m9r690TPXzvL5rBYNbVdVjwwR dy2NaEnfSD6tL/7CKzYTpGliogg7bCFh6XI6TOdmhc8pcLQZIwcsvnX3dXF2lc6OTE FBK/ZvrFJHgvg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xi Ruoyao , Miguel Ojeda , Alice Ryhl , Greg Kroah-Hartman Subject: [PATCH 6.19 001/844] rust_binder: Fix build failure if !CONFIG_COMPAT Date: Sat, 28 Feb 2026 12:18:34 -0500 Message-ID: <20260228173244.1509663-2-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xi Ruoyao commit 174e2a339bf731e080ced67c215ad609a677560b upstream. The bindgen utility cannot handle "#define compat_ptr_ioctl NULL" in the C header, so we need to handle this case on our own. Simply skip this field in the initializer when !CONFIG_COMPAT as the SAFETY comment above this initializer implies this is allowed. Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/all/CANiq72mrVzqXnAV=3DHy2XBOonLHA6YQgH-ckZ= oc_h0VBvTGK8rA@mail.gmail.com/ Signed-off-by: Xi Ruoyao Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20251209125029.1117897-1-xry111@xry111.site Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/android/binder/rust_binder_main.rs | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/android/binder/rust_binder_main.rs b/drivers/android/b= inder/rust_binder_main.rs index c79a9e7422401..9a527268f5b45 100644 --- a/drivers/android/binder/rust_binder_main.rs +++ b/drivers/android/binder/rust_binder_main.rs @@ -314,6 +314,7 @@ unsafe impl Sync for AssertSync {} owner: THIS_MODULE.as_ptr(), poll: Some(rust_binder_poll), unlocked_ioctl: Some(rust_binder_ioctl), + #[cfg(CONFIG_COMPAT)] compat_ioctl: Some(bindings::compat_ptr_ioctl), mmap: Some(rust_binder_mmap), open: Some(rust_binder_open), --=20 2.51.0 From nobody Sat Apr 18 09:32:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95B96328B78; Sat, 28 Feb 2026 17:32:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299969; cv=none; b=HyAJ6v8sgaBn5bR8gtECuVZUKiTRWh8AeXn/ju/fynrWD4EDdvv/J43spVZYUNjSAv4CJ5mV3f8N3cI8qSNG/IHWv0w5+FzWtn/fNmKvc3LudydIGZrDOxApmMUofIrftObu0xWQX23ubb8sZrM5VVzUs8KRECBv4vL/fXGvVBI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299969; c=relaxed/simple; bh=9taDygXBPHFAL+8NwE6jVOboCmH2pLTlGH9WJiMeZew=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N/sUl/lah0nGj3i+i8qjocCUm4yUo0FBcliSo1fAxx59fi2R/7PV4PJ8XmWFmxvQJiDH1CCh1uuNawlQEKDSR6lNdH3D8LsHijv8gYAO70DGT0paE9+3RTM2Y1f/DFsEWlGjH8+sBFIVj5n7/oyqICKfL3arZGmI4QG/TbrisNg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WR76vOUc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WR76vOUc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E038BC19423; Sat, 28 Feb 2026 17:32:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299969; bh=9taDygXBPHFAL+8NwE6jVOboCmH2pLTlGH9WJiMeZew=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WR76vOUcrDpt2e0jkV7hy8NeVketJjy4cZlb8ad/xpjyz/HXya5Eik5mDZ7Bx3kE1 61gIbfnhHX28P3xBIfUuxAnyGYUOvbdahLphC9HjbZdzcpy6/EmsKtXCb/E5qk33+b eDrDiuFRXuVgnLIHOt4uVchsHXjjhqdwtkcjGU1QcpMehAehHZGxZmdnP6N4EXS7wj LXMPENMhlYiaa5YU39F3L9kBYFQFyTJsb3tdCGyb5SzDB7+oWBQg5bbiLo5mDuvemh N38lek+OKH9rK19+EYv8DgTwELNn5PwnPg+lpAgrzEBCaPycXrJo/WFFezTDzBvmSG MDG1AmgvkSQVg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Matthew Schwartz , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 002/844] mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms Date: Sat, 28 Feb 2026 12:18:35 -0500 Message-ID: <20260228173244.1509663-3-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Matthew Schwartz [ Upstream commit aced969e9bf3701dc75cfca57c78c031b7875b9d ] The existing 1ms delay in sd_power_on is insufficient and causes resume errors around 4% of the time. Increasing the delay to 5ms resolves this issue after testing 300 s2idle cycles. Fixes: 1f311c94aabd ("mmc: rtsx: add 74 Clocks in power on flow") Signed-off-by: Matthew Schwartz Link: https://patch.msgid.link/20260105060236.400366-3-matthew.schwartz@lin= ux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mmc/host/rtsx_pci_sdmmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_= sdmmc.c index 4db3328f46dfb..b6cf1803c7d27 100644 --- a/drivers/mmc/host/rtsx_pci_sdmmc.c +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c @@ -937,7 +937,7 @@ static int sd_power_on(struct realtek_pci_sdmmc *host, = unsigned char power_mode) if (err < 0) return err; =20 - mdelay(1); + mdelay(5); =20 err =3D rtsx_pci_write_register(pcr, CARD_OE, SD_OUTPUT_EN, SD_OUTPUT_EN); if (err < 0) --=20 2.51.0 From nobody Sat Apr 18 09:32:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B874033A70A; Sat, 28 Feb 2026 17:32:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299970; cv=none; b=slq8u/D7s08cczeAxYQ7ul4ITFbxVWMt2Z/dvo/nrIvRjB4x2X2j+JJnQxn6BpRUokE/eL7AKEhFEGLaOEvJWoKQJQ4NWEp1u8hb1MjoeJqA8B/5HoHMwZxZNIzoz7OmBCARmAVo0iOPNsy4hYRNrMWxC3CTGFnGa1rVpgxBoVg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299970; c=relaxed/simple; bh=BEp7I0nN80wTiulCvdpv1dALxHl+3lpsc3Fl/imuoZI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QEJ3gm4QqqrreUhO+5RUN0hQw67LpGjt9CucnO1kv9d8NQ+epJfx+GUcUMtZxdoqRI0ufAY6RCaFXK4V0kZYx3AXcweN9hLkZ/sY94tvBt9x0mvL1JsZ6X0kialCRKrBDuzZF5BeoHe+RvxoV/Y/GwQTjXKeN4+tkZWYO1gOHTY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aznwyzf7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aznwyzf7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA605C19425; Sat, 28 Feb 2026 17:32:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299970; bh=BEp7I0nN80wTiulCvdpv1dALxHl+3lpsc3Fl/imuoZI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aznwyzf7u3E77Zd3SBkQxwb9iHN/Q+G49NEVSRn4scbtM10O7SrYd9IHJnU2g8LEp ucIV+fF+YLm8x3jx8K66dvbMk/zKBnZ5PTOcIOETTKf6G+W6frZblOU0GKZyxww3X7 h1ukAuySTjZKIg7XwD+sRCVvmqDNzoBDbDNff4OVlSsCrkujo1eVpTo9Yzb3+FxBj1 v2UkRdcrVPIy2q5EQ48t52qhh7X6Ia2AlqtgMJXIDRNkegMuHqNySbzYyYXCfxsxBi FLlC+uDB8OCrgDxmgSjyHF+QQT9ZKVg2/NaB2f5+DXYBAafhhs5PGb/qMZqpnprmfq WQXVVlF1VAYYQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Matthew Schwartz , Ulf Hansson , Sasha Levin Subject: [PATCH 6.19 003/844] Revert "mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms" Date: Sat, 28 Feb 2026 12:18:36 -0500 Message-ID: <20260228173244.1509663-4-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Greg Kroah-Hartman [ Upstream commit ff112f1ecd10b72004eac05bae395e1c65f0c63c ] This reverts commit aced969e9bf3701dc75cfca57c78c031b7875b9d. It was determined that this was not the correct "fix", so should be reverted. Fixes: aced969e9bf3 ("mmc: rtsx_pci_sdmmc: increase power-on settling delay= to 5ms") Cc: Matthew Schwartz Cc: Ulf Hansson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mmc/host/rtsx_pci_sdmmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_= sdmmc.c index b6cf1803c7d27..4db3328f46dfb 100644 --- a/drivers/mmc/host/rtsx_pci_sdmmc.c +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c @@ -937,7 +937,7 @@ static int sd_power_on(struct realtek_pci_sdmmc *host, = unsigned char power_mode) if (err < 0) return err; =20 - mdelay(5); + mdelay(1); =20 err =3D rtsx_pci_write_register(pcr, CARD_OE, SD_OUTPUT_EN, SD_OUTPUT_EN); if (err < 0) --=20 2.51.0 From nobody Sat Apr 18 09:32:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 448EC328B78; Sat, 28 Feb 2026 17:32:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299972; cv=none; b=M9gCU+rQOE9bbmBlAhmKs4iN0qblE6kXGM6wlcT1E3Qh660ASQbjGf/vmUVa4HQ9dGXEmuwzFfiEO3tjirIcs7d1zC0a0JgrGkFCVBnaPd7XID/KDeFLSzav27S7CIaIcVdHYx/W5Y8nEFyqy8uBJU9hx/nTQaRUIDAE98K1KPM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299972; c=relaxed/simple; bh=mkR6AfW5Utma/fNsPijcJRYNsIfaMc2bi3R9oseisdI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qDZTg9oTbV4vza1mdw6MgKhZ5F0YD/tWOnvLHkeiHCkiwgRFjq1Zkf9nBSo/WAgaFOQKWMKU/vOI5Am/B7uTsz+hefOMRTNHMc1aP0AZbntvzXEW5Bth7aTEe4h/bstRY8ZYr02ixOPQjybZtbvbwe7huXx5qkokB8lgx1RY9qA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m1ZtdQcx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m1ZtdQcx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA69FC19423; Sat, 28 Feb 2026 17:32:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299971; bh=mkR6AfW5Utma/fNsPijcJRYNsIfaMc2bi3R9oseisdI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m1ZtdQcxYR61pv5DZpOvn4ZbrRFJzytREYjtHXn6hJd1PvYhbJAwqLLzjA250yO3W Bsbsq+GkKHnbNmRMM8IUouZbdzLRifGHcswp9fe6zdk0bZQzBbp/1dV9kNZZHS8GxC EJ8VQXL3GsnNwHPkLZqgS8/iCDcv/fBy4fOgzfcfmYW/NgMpXaMy1DYpoNC2j+1Pwk dsOy26Ak1cw/i4gzkSYvphKDicFYSJShqXSsNczIYhwDOUYSRkBfpt2Ypgpbuhzhu+ 1WTghdtdoJbOYPYjp1B+iINhV/CmcRalp+0qCW2FgdIiweDyr2qkOrBhnevl7oUfZX duXyOmY6uJ76g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Richter , Ian Rogers , Alexander Gordeev , Heiko Carstens , Jan Polensky , Namhyung Kim , Sumanth Korikkar , Vasily Gorbik , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 004/844] perf test: Fix test case perf evlist tests for s390x Date: Sat, 28 Feb 2026 12:18:37 -0500 Message-ID: <20260228173244.1509663-5-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Richter [ Upstream commit b04d2b9199129f4f0c992a518c0fb78c2efc1064 ] Perf test case 78: perf evlist tests fails on s390. The failure is causes by grouping events cycles and instructions because sampling does only support event cycles. Change the group to software events to fix this. Output before: # ./perf test 78 78: perf evlist tests : FAILED! # Output after: # ./perf test 78 78: perf evlist tests : Ok # Fixes: db452961de939225 ("perf tests evlist: Add basic evlist test") Signed-off-by: Thomas Richter Tested-by: Ian Rogers Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Jan Polensky Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Vasily Gorbik Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/tests/shell/evlist.sh | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/perf/tests/shell/evlist.sh b/tools/perf/tests/shell/evli= st.sh index 140f099e75c1e..5632be3917109 100755 --- a/tools/perf/tests/shell/evlist.sh +++ b/tools/perf/tests/shell/evlist.sh @@ -38,13 +38,14 @@ test_evlist_simple() { =20 test_evlist_group() { echo "Group evlist test" - if ! perf record -e "{cycles,instructions}" -o "${perfdata}" true 2> /dev= /null + if ! perf record -e "{cpu-clock,task-clock}" -o "${perfdata}" \ + -- perf test -w noploop 2> /dev/null then echo "Group evlist [Skipped event group recording failed]" return fi =20 - if ! perf evlist -i "${perfdata}" -g | grep -q "{.*cycles.*,.*instruction= s.*}" + if ! perf evlist -i "${perfdata}" -g | grep -q "{.*cpu-clock.*,.*task-clo= ck.*}" then echo "Group evlist [Failed to list event group]" err=3D1 --=20 2.51.0 From nobody Sat Apr 18 09:32:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C47C633F8AD; Sat, 28 Feb 2026 17:32:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299973; cv=none; b=PhIVgU0AKKesETrwqh7D9k2nLyKJKQqT6MbmVs6zhIy2BoExosWbtPL/yydIwQk1aJ88tCMr/aVMp/JqNOj2+jM2kg0BXkkQLGxRDeE27W8w72MGm/EM0rkHJo4qg3EDD2irf1B9A1mhe3pC8jQrot8Klrjxn1lri3dB+AbaSCg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299973; c=relaxed/simple; bh=fCv7ZEH1PEoB19yCk3SZZ78NeJRkIno69JE/9P62NwQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L35HhHdHzyXqIJBMZLXIKFJpLrqwUHfz25eNGQ3eTI3xMswuDKtRI7533ZyUvn0kbqwE3XZWgldUykeRAxdxNtUr7j3M+fQYLs+N++4ilvVfENMY6HvTS0vPlyJjRvee1TY2YdlHk0kTbWT/qCNg8m5CfL19XWYHr6Tq/2AiYRs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZQvclS1z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZQvclS1z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E26DC116D0; Sat, 28 Feb 2026 17:32:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299973; bh=fCv7ZEH1PEoB19yCk3SZZ78NeJRkIno69JE/9P62NwQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZQvclS1z0PeYriOeXdsrEOzIbGd5/wgJb1aQ18SLgAWDC3M2MqHnVz4j2Br2+wcSh RPq8Xq4mTq98NudwDgWXzaWZ16l/Qa+S0PxI4/lcnj5T/PWJcer1gtb9y33CxlSp+w a+mYeUA7c2WNl123KqHeF3iC29mERf7u+qg0R8h1mDXkWZm8ZP5n92kKshWhiRyupv O7ByBUxraRMf6SC20hvGVcAMfX1KUk8Qck3wMzjyZjEuhyzpb7exkJA5fNXNbrAAve 2+AKJiHGqnbm4tADOf+mDvxKmSO3F+eAypMcdyg1a3NXKp4fV5ckm46E9hLqgmWgwO 8fEESOhfEp4oA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Richter , Ian Rogers , James Clark , Alexander Gordeev , Heiko Carstens , Jan Polensky , linux-s390@vger.kernel.org, Namhyung Kim , Sumanth Korikkar , Vasily Gorbik , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 005/844] perf test stat tests: Fix for virtualized machines Date: Sat, 28 Feb 2026 12:18:38 -0500 Message-ID: <20260228173244.1509663-6-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Richter [ Upstream commit e272628902c1c96731e2d9f62a7fc77767686eb0 ] On s390 'perf test's 'perf stat tests', subtest test_hybrid fails for z/VM systems. The root cause is this statement: $(perf stat -a -- sleep 0.1 2>&1 |\ grep -E "/cpu-cycles/[uH]*| cpu-cycles[:uH]* -c) The 'perf stat' output on a s390 z/VM system is # perf stat -a -- sleep 0.1 2>&1 Performance counter stats for 'system wide': 56 context-switches # 46.3 cs/sec cs_per_second 1,210.41 msec cpu-clock # 11.9 CPUs CPUs_utilized 12 cpu-migrations # 9.9 migrations/sec ... 81 page-faults # 66.9 faults/sec ... 0.100891009 seconds time elapsed The grep command does not match any single line and exits with error code 1. As the bash script is executed with 'set -e', it aborts with the first error code being non-zero. Fix this and use 'wc -l' to count matching lines instead of 'grep ... -c'. Output before: # perf test 102 102: perf stat tests : FAILED! # Output after: # perf test 102 102: perf stat tests : Ok # Fixes: bb6e7cb11d97ce19 ("perf tools: Add fallback for exclude_guest") Reviewed-by: Ian Rogers Reviewed-by: James Clark Signed-off-by: Thomas Richter Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Jan Polensky Cc: linux-s390@vger.kernel.org Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Vasily Gorbik Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/tests/shell/stat.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/tests/shell/stat.sh b/tools/perf/tests/shell/stat.sh index 0b2f0f88ca166..792a0b79f6b86 100755 --- a/tools/perf/tests/shell/stat.sh +++ b/tools/perf/tests/shell/stat.sh @@ -233,7 +233,7 @@ test_hybrid() { fi =20 # Run default Perf stat - cycles_events=3D$(perf stat -a -- sleep 0.1 2>&1 | grep -E "/cpu-cycles/= [uH]*| cpu-cycles[:uH]* " -c) + cycles_events=3D$(perf stat -a -- sleep 0.1 2>&1 | grep -E "/cpu-cycles/= [uH]*| cpu-cycles[:uH]* " | wc -l) =20 # The expectation is that default output will have a cycles events on ea= ch # hybrid PMU. In situations with no cycles PMU events, like virtualized,= this --=20 2.51.0 From nobody Sat Apr 18 09:32:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 025BD34028B; Sat, 28 Feb 2026 17:32:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299976; cv=none; b=WFBZHYz9CEh5m/vDExUKIA8xir3j88dPBwERYBk2KVEmEgPZN70JpRVNsVg5wgpQbZhD6jsQH/6UT/0nTVriibb30vWkG8tHxQ5GlU/44OQiGqI8ggHhAyCH1vCYZv8gTuX2+6/tsQeJ92G3hCMBfdiUXlrCsQClofcNBbq6pXo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299976; c=relaxed/simple; bh=ZOzanoFOH5DzZMWofm4R8GIYtFn755rOXfZ3brBRN94=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ck+KEBTPMC+sxSuQCDJh+OHQ+T6JK5Bf1cXzeDv/aU5Cf3jS0nc0pEs21xx5kcmuejENcsEnvqHuKF/Oby1tyzxz8y7Q22lklcBLACm3pg/VJOCQRDME+XsQ52HffbwVr3AVhwCBh30Fhr9Ee9QD6UT0CjsO53f3dXgfdeztjhw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DZUMess8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DZUMess8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCE76C2BC87; Sat, 28 Feb 2026 17:32:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299975; bh=ZOzanoFOH5DzZMWofm4R8GIYtFn755rOXfZ3brBRN94=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DZUMess8FNw0gR7iiu1ieHsojmKzmtCDrnRBSkjsbASiu69FC3zmQFBuhn/Q/r4SD 2qHKlrpTyiE6YD0ydDUBz4UGVOuO03rO4Kla8qBCu8Rs74l4ZyYj1PIY37Rzgd/XlR uIAbg+TmzMI/V1FEGhKrRFUX4KIxKPeU7Afo0c97bm2M7ioSTA1QXQbINzyILqFHYn /VxLtY0ffyH2fGaqAx9QNT5R5X66PSHe9N8b7VwUn3knSvMOyguMKMzp5DXSNvdLkN R7OAlGqcJtRvnunHymz1+xmiwJKv5HvVFDRIxhUIv8zV8dyglI60qirGGedKkOtVgQ 5/c/soby5scew== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nicolas Schier , Namhyung Kim , Adrian Hunter , Alexander Shishkin , Ian Rogers , Ingo Molnar , Jakub Brnak , James Clark , Jiri Olsa , Mark Rutland , Michael Petlan , Nicolas Schier , Peter Zijlstra , Philipp Hahn , Veronika Molnarova , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 006/844] perf build: Raise minimum shellcheck version to 0.7.2 Date: Sat, 28 Feb 2026 12:18:39 -0500 Message-ID: <20260228173244.1509663-7-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicolas Schier [ Upstream commit 383f8e26e2c483e25453f8c3d0839877708ac701 ] Raise the minimum shellcheck version for perf builds to 0.7.2, so that systems with shellcheck versions below 0.7.2 will automatically skip the shell script checking, even if NO_SHELLCHECK is unset. Since commit 241f21be7d0fdf3c ("perf test perftool_testsuite: Use absolute paths"), shellcheck versions before 0.7.2 break the perf build with several SC1090 [2] warnings due to its too strict dynamic source handling [1], e.g.: In tests/shell/base_probe/test_line_semantics.sh line 20: . "$DIR_PATH/../common/init.sh" ^---------------------------^ SC1090: Can't follow non-constant source.= Use a directive to specify location. Fixes: 241f21be7d0fdf3c ("perf test perftool_testsuite: Use absolute paths") Signed-off-by: Nicolas Schier Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jakub Brnak Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Michael Petlan Cc: Nicolas Schier Cc: Peter Zijlstra Cc: Philipp Hahn Cc: Veronika Molnarova Link: https://github.com/koalaman/shellcheck/issues/1998 # [1] Link: https://www.shellcheck.net/wiki/SC1090 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/Makefile.perf | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index b3f481a626afa..e6895626c1872 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -251,11 +251,12 @@ else endif =20 # shellcheck is using in tools/perf/tests/Build with option -a/--check-sou= rced ( -# introduced in v0.4.7) and -S/--severity (introduced in v0.6.0). So make = the -# minimal shellcheck version as v0.6.0. +# introduced in v0.4.7) and -S/--severity (introduced in v0.6.0) as well as +# dynamic source inclusions (properly handled since v0.7.2). +# So make the minimal shellcheck version as v0.7.2. ifneq ($(SHELLCHECK),) ifeq ($(shell expr $(shell $(SHELLCHECK) --version | grep version: | \ - sed -e 's/.\+ \([0-9]\+\).\([0-9]\+\).\([0-9]\+\)/\1\2\3/g') \< 06= 0), 1) + sed -e 's/.\+ \([0-9]\+\).\([0-9]\+\).\([0-9]\+\)/\1\2\3/g') \< 07= 2), 1) SHELLCHECK :=3D else SHELLCHECK :=3D $(SHELLCHECK) -s bash -a -S warning --=20 2.51.0 From nobody Sat Apr 18 09:32:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B7CE934250D; Sat, 28 Feb 2026 17:32:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299977; cv=none; b=V6KFZfo08Psh6tkJtle0x0nZGqD6JSG+GyrqhTBwZtahRkjbenLOT4Z0eInwnkCL5WQ8QCX4PIgyHU+iYj1x3x9BYFpR2Tapw7I99t1ZzDYIH1rtBBtX9jCL/v5peDjAP8uZ3dYUKtWubEd/jekhlKoJmnKf0P7Ys9I0XmsZiF4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299977; c=relaxed/simple; bh=krid9cOIMHTsvZ7Qjdu//AWrJ+QyM9fIZuFb2ch7s6o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SBlb20Y6dDZQ6tEZBa1tchVkO/hYL5ps02vvAzjU7x31y1/ozUegkZh5n+6gWRc2Mgm/VXg5o6dpYK7vf3/xCcCd5zvSnF5lyjmuMPgtSp7xnnlCB7nGWdZMZ09VcnVDyfM2Msr+79NEXf/Pm1UL3dyHF4YFYJH0DWbOqveFFag= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XKB5ykSG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XKB5ykSG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED57FC19423; Sat, 28 Feb 2026 17:32:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299977; bh=krid9cOIMHTsvZ7Qjdu//AWrJ+QyM9fIZuFb2ch7s6o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XKB5ykSGvHqRdhLsAf9ZlK63PHe0KCIXa2OF9xYsV+CCYIJb5/tIRZS3Oe7PRC453 YysnhuW0ps1KIEBPqVxcl/huMNZv7cxPIdw12RkuD9eFs6Os0EjRQfw3hAHqdv9uuw L8XXt7l3bEbvyStjdTY+02wVhxA3F8xMS1+MRQBvpMsHRSgCP0QoNDOzS8pQr+4JJg hjc9jL6dHEK8WtMfNqy8cP8wU6SQP0ZMhD1GutL33fjeSrmF98CDGVWks374Zx44M+ BoQed6j2GDG2KKMIELYmAPN06jLqm7ZBW751jeS/ubWZgnAh6H+hza2cMh7KvbjkQu f+oCkLu+jAAwQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , James Clark , Adrian Hunter , Alexander Shishkin , Howard Chu , Ingo Molnar , Jiri Olsa , Namhyung Kim , Peter Zijlstra , Stephen Brennan , Tony Jones , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 007/844] perf unwind-libdw: Fix invalid reference counts Date: Sat, 28 Feb 2026 12:18:40 -0500 Message-ID: <20260228173244.1509663-8-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit f815fc0c66e777c727689666cfb46b8d461c2f99 ] The addition of addr_location__exit() causes use-after put on the maps and map references in the unwind info. Add the gets and then add the map_symbol__exit() calls. Fixes: 0dd5041c9a0eaf8c ("perf addr_location: Add init/exit/copy functions") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Howard Chu Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephen Brennan Cc: Tony Jones Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/unwind-libdw.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/unwind-libdw.c b/tools/perf/util/unwind-libdw.c index ae70fb56a0572..3ff427a49e4c5 100644 --- a/tools/perf/util/unwind-libdw.c +++ b/tools/perf/util/unwind-libdw.c @@ -136,8 +136,8 @@ static int entry(u64 ip, struct unwind_info *ui) } =20 e->ip =3D ip; - e->ms.maps =3D al.maps; - e->ms.map =3D al.map; + e->ms.maps =3D maps__get(al.maps); + e->ms.map =3D map__get(al.map); e->ms.sym =3D al.sym; =20 pr_debug("unwind: %s:ip =3D 0x%" PRIx64 " (0x%" PRIx64 ")\n", @@ -325,6 +325,9 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg, if (err) pr_debug("unwind: failed with '%s'\n", dwfl_errmsg(-1)); =20 + for (i =3D 0; i < ui->idx; i++) + map_symbol__exit(&ui->entries[i].ms); + dwfl_end(ui->dwfl); free(ui); return 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83FBE343D7B; Sat, 28 Feb 2026 17:32:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299979; cv=none; b=Likia65YzqdDZzDwiwt3hyk9O6riC1d4RHp7q8YMONdAR8CR/ufzb6j+O944dYkLsmIurnMKqFYMi8moTr576mkAuvyk2c4dUYY9RLwcRIrT8SoD0m3uDSB7Btevx1DEU5UWFNJRfB4rYQ5FsGhxlAmDqk/vryGzkfPy3tgHthw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299979; c=relaxed/simple; bh=JXmZxW8aypecdTK3JC3PR3n01rbBlYd6dg87U+ITZNk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XK4OaiUFATde+YmacT6Oj5HQJ9HrMOfaWiOYDFMR1Mt5IAIA3vDJBuQXv8InZ/+BFAb7WN4ufMnchSL7Fwvm/bTI+UH9Qr7VaxGuUjjpEjAxYqXM8lAXgz9igLBoeaZcM78QqFrNBTwHONOahN/Wac1T5fkyM5a2BhTaqWPh368= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HzhBQx2y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HzhBQx2y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7B20C116D0; Sat, 28 Feb 2026 17:32:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299979; bh=JXmZxW8aypecdTK3JC3PR3n01rbBlYd6dg87U+ITZNk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HzhBQx2yELtticJs3v9P1FKRKIFrIHYpBTm9k+2Kdot6KblfAkC50OIBfjZhTnsbh SmKRR5ls9B5IWfoRhJFVNbb+zjjlgQfwJV0PHV2rVK3xWGObEaRErUeWUlGK1lvi63 Q4RgQIHBWoMPlrLVmjdUQLyYE18bzKeEXANwvDd3fcCEM5MB1fEmXqfeDS5TrsH2du SAYk4joMn2btTq/QLvLp/w8xKhCmQD/rQf4hdxU+Uu8AkmyqkiTsnj1FX6Bi/RKfBa y/QkEeTMTAKmDjE4SO5opWFmpVSu6pjQCVXjdVzR9ixn58QJW8g84aXhPt4l6LZMq8 8qeMGkpkEJpRA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , James Clark , Adrian Hunter , Alexander Shishkin , Howard Chu , Ingo Molnar , Jiri Olsa , Namhyung Kim , Peter Zijlstra , Stephen Brennan , Tony Jones , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 008/844] perf callchain: Fix srcline printing with inlines Date: Sat, 28 Feb 2026 12:18:41 -0500 Message-ID: <20260228173244.1509663-9-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit abec464767b5d26f0612250d511c18f420826ca1 ] sample__fprintf_callchain() was using map__fprintf_srcline() which won't report inline line numbers. Fix by using the srcline from the callchain and falling back to the map variant. Fixes: 25da4fab5f66e659 ("perf evsel: Move fprintf methods to separate sour= ce file") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Howard Chu Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephen Brennan Cc: Tony Jones Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/evsel_fprintf.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/evsel_fprintf.c b/tools/perf/util/evsel_fprint= f.c index 10f1a03c28601..5521d00bff2c0 100644 --- a/tools/perf/util/evsel_fprintf.c +++ b/tools/perf/util/evsel_fprintf.c @@ -185,8 +185,12 @@ int sample__fprintf_callchain(struct perf_sample *samp= le, int left_alignment, if (print_dso && (!sym || !sym->inlined)) printed +=3D map__fprintf_dsoname_dsoff(map, print_dsoff, addr, fp); =20 - if (print_srcline) - printed +=3D map__fprintf_srcline(map, addr, "\n ", fp); + if (print_srcline) { + if (node->srcline) + printed +=3D fprintf(fp, "\n %s", node->srcline); + else + printed +=3D map__fprintf_srcline(map, addr, "\n ", fp); + } =20 if (sym && sym->inlined) printed +=3D fprintf(fp, " (inlined)"); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAB6133A01E; Sat, 28 Feb 2026 17:33:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299980; cv=none; b=gzdh6lL1Tvc1wgfs6vV4GlwmphNnu6hJYKPUPvhL3ehGKFN9by14iJsPcmtE1O/CibZTblcBknTgBPHlDLM3HshoXnRyZ2RXk5Kj9qomVQs3DrYUkVXkfggBBhicdzQhnx0jpMHE7B/0LnIL+xrOMfDBRXCMdrXCMdyqd3zMiOc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299980; c=relaxed/simple; bh=RIczDaL9PYQP5+M+OkprKa3ruNJrkZtJ83omwcciUhE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HxO5kejmk+CPfAKl6JYOH2r6aOU5JBGjm50ljYErhl7xoLhwddnJx7lOQ0CILAtdfsb44UAROWyRwU8AqVmYdZ5qofN8kqiIB+5Bc/cCaRGi1MzSJriSA1SLKoNR2hu5Xx3xD/G0HtCpR4Qg3muntztbWnYa8xEOSx1ztOqSr14= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Jg1woAdy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Jg1woAdy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7915FC19425; Sat, 28 Feb 2026 17:32:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299980; bh=RIczDaL9PYQP5+M+OkprKa3ruNJrkZtJ83omwcciUhE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Jg1woAdylgoVJCyZbzHNxHb4F7AoYeXfr6ESgJaXA9P+3S9vBkKlXDuF2ZwvD+rST +n7GG9zthLTMBW4l7G+hR2ilcTkNHZnHtc4fsPC+BRVWPo0dejAkYufVcerkNdOV2i ev98GnyhsohZx1IGWzOR6SUZC2AqGwHGFfPWPPI0Cql6OyLcP3K1Z16qtoIad9cfKe ZrHqtK+AA4eQOO2dSAcEUNzl0BRTnI7Qn3QKz+cFbs7Bt28to0RqHX5KJ52hrnIa0Z KoA5CD/QXBpp9JPgYgXisy8u0GLMVjuY47jliVv5ImxiJIIqBp7ExgidWEF3Rel8tR l11+MdExfu/KA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sri Jayaramappa , Guilherme Amadio , Ian Rogers , Joshua Hunt , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 009/844] libsubcmd: Fix null intersection case in exclude_cmds() Date: Sat, 28 Feb 2026 12:18:42 -0500 Message-ID: <20260228173244.1509663-10-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sri Jayaramappa [ Upstream commit b6ee9b6e206b288921c14c906eebf4b32fe0c0d8 ] When there is no exclusion occurring from the cmds list - for example - cmds contains ["read-vdso32"] and excludes contains ["archive"] - the main loop completes with ci =3D=3D cj =3D=3D 0. In the original code the lo= op processing the remaining elements in the list was conditional: if (ci !=3D cj) { ...} So we end up in the assertion loop since ci < cmds->cnt and we incorrectly try to assert the list elements to be NULL and fail with the following error help.c:104: exclude_cmds: Assertion `cmds->names[ci] =3D=3D NULL' failed. Fix this by moving the if (ci !=3D cj) check inside of a broader loop. If ci !=3D cj, left shift the list elements, as before, and then unconditionally advance the ci and cj indicies which also covers the ci =3D=3D cj case. Fixes: 1fdf938168c4d26f ("perf tools: Fix use-after-free in help_unknown_cm= d()") Reviewed-by: Guilherme Amadio Signed-off-by: Sri Jayaramappa Tested-by: Guilherme Amadio Tested-by: Ian Rogers Cc: Joshua Hunt Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20251202213632.2873731-1-sjayaram@akamai.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/lib/subcmd/help.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/lib/subcmd/help.c b/tools/lib/subcmd/help.c index ddaeb4eb3e249..db94aa685b73b 100644 --- a/tools/lib/subcmd/help.c +++ b/tools/lib/subcmd/help.c @@ -97,11 +97,13 @@ void exclude_cmds(struct cmdnames *cmds, struct cmdname= s *excludes) ei++; } } - if (ci !=3D cj) { - while (ci < cmds->cnt) { - cmds->names[cj++] =3D cmds->names[ci]; - cmds->names[ci++] =3D NULL; + while (ci < cmds->cnt) { + if (ci !=3D cj) { + cmds->names[cj] =3D cmds->names[ci]; + cmds->names[ci] =3D NULL; } + ci++; + cj++; } for (ci =3D cj; ci < cmds->cnt; ci++) assert(cmds->names[ci] =3D=3D NULL); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E72E346FAE; Sat, 28 Feb 2026 17:33:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299982; cv=none; b=N8e4Wh1XJ4YLB9T2bRqJHHiLXUjtuz+QNYPzC4VyJxWmdeBIewK8Wh6/fVBG8QqhH3YgQm5tquCcnk9BhgPxXN3E20vfwbc240AQa4tzikOMwnZyS5Rt9izRjyJUKyvtXzpRZfbKqgC+S44GdVgQSMyGoqN43ctguXoa3k58phI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299982; c=relaxed/simple; bh=SFnyf4F+oXbrayj46ArGg9lHqMGNk3XPYVJe7hBn9UU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oBqMrukLQFsL5ADcqNkqcl3LQkFlpDHZlTJ+nASC//E8Q8Ge6pTeRliWzuWDAUpW044eRSTIXtKUC23iMbiTxHe/YUlxdw6nPtMtjdglpmeb1t/Jro2vfgXX1/Bgg6NCFxRu8SrknIfSP0itAftI2AmpBm+aVtaJztgLWPaWpUM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RiEeW1P2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RiEeW1P2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EA24C19424; Sat, 28 Feb 2026 17:33:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299981; bh=SFnyf4F+oXbrayj46ArGg9lHqMGNk3XPYVJe7hBn9UU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RiEeW1P2NzZ4qkd/mBv4XqFDeMbFVnief/z2Kstn5IhdiT2ZgiJ4j5XivX3FRZzGY WGu0QY8UNyMAYDQ8uOehxIeF8ACjJnHLDEr/4NEsemVNeGnEcMOJWfga5Ub6lLdyZe X1Xp/TUIaurZRoF53uPJJgAPEgniV24Y4HxbGU2DTickZnLN5fY23yVvzjff9sG0d/ LX5n3Pakw5p4qZTWWposr2wQ0gb8trNPCbVOzz8j27mqkOBwiIl8xr4Sxus0k9MwNi /AhSR2YILGPHoXCBGDy5S5hOpd2ib6F7d+tCwAsJ0V6vtP03jHQjgIcjxDvFVrJStn /TmJ801/Vyi9g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Robinson , Shubhi Garg , Jon Hunter , Alexandre Belloni , Sasha Levin Subject: [PATCH 6.19 010/844] rtc: nvvrs: Add ARCH_TEGRA to the NV VRS RTC driver Date: Sat, 28 Feb 2026 12:18:43 -0500 Message-ID: <20260228173244.1509663-11-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Robinson [ Upstream commit f9ecfd9bfedba9fd9d4b015b33b847571f7fdd42 ] The NV VRS RTC driver currently is only supported on the Tegra platform so add a dep for ARCH_TEGRA and compile test so it doesn't show up universally across all arches/platforms. Fixes: 9d6d6b06933c8 ("rtc: nvvrs: add NVIDIA VRS RTC device driver") Cc: Shubhi Garg Cc: Jon Hunter Signed-off-by: Peter Robinson Acked-by: Jon Hunter Link: https://patch.msgid.link/20251222035651.433603-1-pbrobinson@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/rtc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 50dc779f7f983..50ba48609d74e 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -418,6 +418,7 @@ config RTC_DRV_SPACEMIT_P1 =20 config RTC_DRV_NVIDIA_VRS10 tristate "NVIDIA VRS10 RTC device" + depends on ARCH_TEGRA || COMPILE_TEST help If you say yes here you will get support for the battery backed RTC dev= ice of NVIDIA VRS (Voltage Regulator Specification). The RTC is connected v= ia --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1E5B3491C9; Sat, 28 Feb 2026 17:33:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299983; cv=none; b=G5pcbYocEzq1wjfuB8kZ83N+nj8B/uwevxl0xUl0T1QehKcltcH/oeB4F2/LzNEjMslie+XXC7Z5f3RoBTApwCx8f7usmjwDWYSYYZ13LaVa+wtuvtfQWIQyAWBqmhr8M9ditB7VpuaMU3KdwYT27cCSRe6HLx1+hXz7GO2n5Es= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299983; c=relaxed/simple; bh=bZJ3rfOPjv7sv5q4HAz0z1txbRUKRRKW+yJTZKrRPXA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=kNNcq+GXI62Omgmcw8FzWLni8KB8k3hiOxhKShEXnTCB27OiCBNFpoA9y6pJc+gGVcWEESH3fmxkEO2efHh0TGJQ5WrkffyMRs/9ktLQVhPEvQ0w+ZKHJAljcTtT5ogDQmHox0Iuafk6rqgdEKT3U52juV86O9GBasVxnwy0c2E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f6+R+viP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="f6+R+viP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16FC2C19423; Sat, 28 Feb 2026 17:33:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299982; bh=bZJ3rfOPjv7sv5q4HAz0z1txbRUKRRKW+yJTZKrRPXA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f6+R+viP5JhwNlc163QeYArBv4asWcMpS0ykcjthlzC88gqrxZ2kRtQbkqcnLtMRX 1y0dHosNKS+ETRjX6arUmyaN3CqUWuV9P5BlFT2O+9nsP+v12ZIv/yvzJE1w6d9nRJ Slymm6APiJIdAEHptZVq+QcFTAu3Lj/8Ik51W1HFyVc1hsgSKCSIRnbT7QepjPvYGT 1yhGN+lAsIt69YDuqXUPaxouCFZbjZZg4qJ1Ig45D7fW8wHPrY+mSiDX4DC02KZ/pM jejSUeQOLsfVTvM7ByylM/M/yHO06GN34PqHUcdq6yHwb/32nrgIEGLHd+zAtsWZQU /cMHT4RqyV/sg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Randy Dunlap , =?UTF-8?q?Nuno=20S=C3=A1?= , Alexandre Belloni , Sasha Levin Subject: [PATCH 6.19 011/844] rtc: max31335: use correct CONFIG symbol in IS_REACHABLE() Date: Sat, 28 Feb 2026 12:18:44 -0500 Message-ID: <20260228173244.1509663-12-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Randy Dunlap [ Upstream commit d5aca9a17f6de884febc56018f92d743b8ea1298 ] IS_REACHABLE() is meant to be used with full symbol names from a kernel .config file, not the shortened symbols used in Kconfig files, so change HWMON to CONFIG_HWMON in 3 places. Fixes: dedaf03b99d6 ("rtc: max31335: add driver support") Signed-off-by: Randy Dunlap Acked-by: Nuno S=C3=A1 Link: https://patch.msgid.link/20260108045432.2705691-1-rdunlap@infradead.o= rg Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/rtc/rtc-max31335.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/rtc/rtc-max31335.c b/drivers/rtc/rtc-max31335.c index 23b7bf16b4cd5..952b455071d68 100644 --- a/drivers/rtc/rtc-max31335.c +++ b/drivers/rtc/rtc-max31335.c @@ -591,7 +591,7 @@ static struct nvmem_config max31335_nvmem_cfg =3D { .size =3D MAX31335_RAM_SIZE, }; =20 -#if IS_REACHABLE(HWMON) +#if IS_REACHABLE(CONFIG_HWMON) static int max31335_read_temp(struct device *dev, enum hwmon_sensor_types = type, u32 attr, int channel, long *val) { @@ -672,7 +672,7 @@ static int max31335_clkout_register(struct device *dev) static int max31335_probe(struct i2c_client *client) { struct max31335_data *max31335; -#if IS_REACHABLE(HWMON) +#if IS_REACHABLE(CONFIG_HWMON) struct device *hwmon; #endif const struct chip_desc *match; @@ -727,7 +727,7 @@ static int max31335_probe(struct i2c_client *client) return dev_err_probe(&client->dev, ret, "cannot register rtc nvmem\n"); =20 -#if IS_REACHABLE(HWMON) +#if IS_REACHABLE(CONFIG_HWMON) if (max31335->chip->temp_reg) { hwmon =3D devm_hwmon_device_register_with_info(&client->dev, client->nam= e, max31335, &max31335_chip_info, NULL); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 79FA3338596; Sat, 28 Feb 2026 17:33:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299986; cv=none; b=ZZ9PZYJqwTikxaY1Fy+WIQeoEVpiLdidisclSe5OVBx8DNONo10qA8ZD8kR8Q/wx7A5hDjYN2SCp43ztSxUSq24pl3CdaQ+CwgidNFWganzljQHgUdsLox6fnVqwkzb9QUlwQzwf/nMAC6YgSOD9CgC+X1qnM+lL24II1HYk94w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299986; c=relaxed/simple; bh=X2/vC+9xwl0u42CuSal+ggvMlJF6drvzSnUvW3RqSrU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=R55K15i6V/16h1czstlwrEeMZjX3SkxOBpYro3ucATZm+bfIlwQiO8IcYLOEA11NNE3DUuK+bNww8xjYA5T4TSeINOU3Q1woLwJ/FIxxzSJbOhuLKE8jRZ0pnJfNns+voSG0Jd3GZDJb6iHWUUeXcNaVab/CRz6fHnzRXnF1hGU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hbTNd6/W; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hbTNd6/W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1166FC116D0; Sat, 28 Feb 2026 17:33:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299986; bh=X2/vC+9xwl0u42CuSal+ggvMlJF6drvzSnUvW3RqSrU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hbTNd6/W8P//B6B7e7K4Rf94LHASkv4Cj5l18taFX3FCjN59C/P/qy3b/pqWL8yrH TQonB268XY7jR0SZUqp8B/lzRUEloow4GGG3P34TO258Ac4KQtzVsh5rQfv8Sx+DlL zspLBcyWYFr7rMZfC3HkAeof0XyepYc+DEjfqOhoei/fiUI0SYr8wPuGSehfv0sBN8 pjNI5yx4uYlglv22KT8ANE3/AOFsAZHp+vPMpgP+V0IUbVH33/i/FQH7BElYfDAuNt 0hsVgh/MS5ISLlG7oXtehCebqyVNymLsbhyF0+1OeLQ0ixqJ3wcTLoY9Y5OD50vrHb wN0b9HsLdogDA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , Aditya Bodkhe , Adrian Hunter , Albert Ou , Alexandre Ghiti , Andi Kleen , Athira Rajeev , Chun-Tse Shao , Dmitriy Vyukov , "Dr. David Alan Gilbert" , Guo Ren , Haibo Xu , Howard Chu , Ingo Molnar , James Clark , Jiri Olsa , John Garry , =?UTF-8?q?Krzysztof=20=C5=81opatowski?= , Leo Yan , Mark Wielaard , Namhyung Kim , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Sergei Trofimovich , Shimin Guo , Stephen Brennan , Thomas Falcon , Will Deacon , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 012/844] perf symbol-elf: Fix leak of ELF files with GNU debugdata Date: Sat, 28 Feb 2026 12:18:45 -0500 Message-ID: <20260228173244.1509663-13-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ian Rogers [ Upstream commit 92d65d9c31621befe0a5f7c0bd43bd217613c6b6 ] The processing of DSO_BINARY_TYPE__GNU_DEBUGDATA in symsrc__init happens with an open ELF file but the error path only closes the associate fd. Fix the goto so that the ELF file is also ended and memory released. Fixes: b10f74308e130527 ("perf symbol: Support .gnu_debugdata for symbols") Signed-off-by: Ian Rogers Cc: Aditya Bodkhe Cc: Adrian Hunter Cc: Albert Ou Cc: Alexandre Ghiti Cc: Andi Kleen Cc: Athira Rajeev Cc: Chun-Tse Shao Cc: Dmitriy Vyukov Cc: Dr. David Alan Gilbert Cc: Guo Ren Cc: Haibo Xu Cc: Howard Chu Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: John Garry Cc: Krzysztof =C5=81opatowski Cc: Leo Yan Cc: Mark Wielaard Cc: Namhyung Kim Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Sergei Trofimovich Cc: Shimin Guo Cc: Stephen Brennan Cc: Thomas Falcon Cc: Will Deacon Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/symbol-elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c index d1dcafa4b3b80..439f252937b89 100644 --- a/tools/perf/util/symbol-elf.c +++ b/tools/perf/util/symbol-elf.c @@ -1173,7 +1173,7 @@ int symsrc__init(struct symsrc *ss, struct dso *dso, = const char *name, Elf *embedded =3D read_gnu_debugdata(dso, elf, name, &new_fd); =20 if (!embedded) - goto out_close; + goto out_elf_end; =20 elf_end(elf); close(fd); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95FFD34CFD7; Sat, 28 Feb 2026 17:33:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299987; cv=none; b=PhK2Af5i91hwMraeU2PXkk3i8Mr4HkWBKulv3eIw72AIO2BIe40MH0M+BUqpCVl8aK8JSZ7iGJPeo6qkH9HuQxjKw7I8LsVm9kpSFd1gKBgbKzcwR2MN2DPW/h8umu/lw4wKVM7GA6/9ERKQgRAI2bqkoV3vdJ1tXsXqDcYxrTc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299987; c=relaxed/simple; bh=YguACwKeqrdXixPWz4QFCRIZisZJoePDLuE9Nvn+DJg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U8oh2WEQZUUo1rd9KDjaIXureeCM3Fm0kjbFhNhG7wjT7Fnpf0FLdHwucV3MX2UVK7qp4cFBbzZ0hDPPaLL4OvVJ1mvfAC9Th1Uz2IIYD+dohwik1McUAi6Budx67Ed5mTcc9UfhMGCdg0znLTOojjNyXm9+kJ/VccV79RGS+/Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pOvwsfs7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pOvwsfs7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62E48C19423; Sat, 28 Feb 2026 17:33:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299987; bh=YguACwKeqrdXixPWz4QFCRIZisZJoePDLuE9Nvn+DJg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pOvwsfs7QTRpOFME2NTTRQ52DqXv1UF5XhHiOIRdKW8O7ais7DEkgjXF7P5HxyfBo CkEtqx/yBSHgEaMDvAQcm07TBPYOkBcW9aQAXaSK1dmwiFsxhifS7fmG3bATfG3XSp XHeLqgZhAJXe7HAdg6EUshXc6lLkb6V/IvEjMeqhrT7Pdil42y+FeUyQMtlvUP68ad d1ciO1/iB+ZD+ea7arDGEo1JiKz5uDzKYoNgpH7cR/gS5W/mFj+hFqJa56sPJdOROO k+cj8RLoqBMmoZ8edEF2SoGR1+gX+dcmimmqAdYmEYBnf33ZqJGqjBgG83b9Vq7Biy fIGOkgfLn+stA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Namhyung Kim , Ian Rogers , Adrian Hunter , Ingo Molnar , James Clark , Jiri Olsa , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 013/844] perf tools: Get debug info of DSO properly Date: Sat, 28 Feb 2026 12:18:46 -0500 Message-ID: <20260228173244.1509663-14-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Namhyung Kim [ Upstream commit 069e603d8248dac98b1ef2909e2f1c4169b9da11 ] The dso__debuginfo() just used the path name to open the file but it may be outdated. It should check build-ID and use the file in the build-ID cache if available rather than just using the path name. Let's factor out dso__get_filename() to avoid code duplicate. Fixes: 53a61a6ca279165d ("perf annotate: Add dso__debuginfo() helper") Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/dso.c | 63 ++++++++++++++++++++++++++++++++----------- tools/perf/util/dso.h | 11 ++------ 2 files changed, 50 insertions(+), 24 deletions(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 344e689567ee1..dc202d4943721 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -111,7 +111,7 @@ bool dso__is_object_file(const struct dso *dso) =20 int dso__read_binary_type_filename(const struct dso *dso, enum dso_binary_type type, - char *root_dir, char *filename, size_t size) + const char *root_dir, char *filename, size_t size) { char build_id_hex[SBUILD_ID_SIZE]; int ret =3D 0; @@ -563,20 +563,15 @@ char *dso__filename_with_chroot(const struct dso *dso= , const char *filename) return filename_with_chroot(nsinfo__pid(dso__nsinfo_const(dso)), filename= ); } =20 -static int __open_dso(struct dso *dso, struct machine *machine) - EXCLUSIVE_LOCKS_REQUIRED(_dso__data_open_lock) +static char *dso__get_filename(struct dso *dso, const char *root_dir, + bool *decomp) { - int fd =3D -EINVAL; - char *root_dir =3D (char *)""; char *name =3D malloc(PATH_MAX); - bool decomp =3D false; =20 - if (!name) - return -ENOMEM; + *decomp =3D false; =20 - mutex_lock(dso__lock(dso)); - if (machine) - root_dir =3D machine->root_dir; + if (name =3D=3D NULL) + return NULL; =20 if (dso__read_binary_type_filename(dso, dso__binary_type(dso), root_dir, name, PATH_MAX)) @@ -601,20 +596,38 @@ static int __open_dso(struct dso *dso, struct machine= *machine) size_t len =3D sizeof(newpath); =20 if (dso__decompress_kmodule_path(dso, name, newpath, len) < 0) { - fd =3D -(*dso__load_errno(dso)); + errno =3D *dso__load_errno(dso); goto out; } =20 - decomp =3D true; + *decomp =3D true; strcpy(name, newpath); } + return name; + +out: + free(name); + return NULL; +} =20 - fd =3D do_open(name); +static int __open_dso(struct dso *dso, struct machine *machine) + EXCLUSIVE_LOCKS_REQUIRED(_dso__data_open_lock) +{ + int fd =3D -EINVAL; + char *name; + bool decomp =3D false; + + mutex_lock(dso__lock(dso)); + + name =3D dso__get_filename(dso, machine ? machine->root_dir : "", &decomp= ); + if (name) + fd =3D do_open(name); + else + fd =3D -errno; =20 if (decomp) unlink(name); =20 -out: mutex_unlock(dso__lock(dso)); free(name); return fd; @@ -1910,3 +1923,23 @@ const u8 *dso__read_symbol(struct dso *dso, const ch= ar *symfs_filename, return __dso__read_symbol(dso, symfs_filename, start, len, out_buf, out_buf_len, is_64bit); } + +struct debuginfo *dso__debuginfo(struct dso *dso) +{ + char *name; + bool decomp =3D false; + struct debuginfo *dinfo =3D NULL; + + mutex_lock(dso__lock(dso)); + + name =3D dso__get_filename(dso, "", &decomp); + if (name) + dinfo =3D debuginfo__new(name); + + if (decomp) + unlink(name); + + mutex_unlock(dso__lock(dso)); + free(name); + return dinfo; +} diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h index f8ccb9816b89c..54e470dd07305 100644 --- a/tools/perf/util/dso.h +++ b/tools/perf/util/dso.h @@ -766,7 +766,7 @@ int dso__kernel_module_get_build_id(struct dso *dso, co= nst char *root_dir); =20 char dso__symtab_origin(const struct dso *dso); int dso__read_binary_type_filename(const struct dso *dso, enum dso_binary_= type type, - char *root_dir, char *filename, size_t size); + const char *root_dir, char *filename, size_t size); bool is_kernel_module(const char *pathname, int cpumode); bool dso__needs_decompress(struct dso *dso); int dso__decompress_kmodule_fd(struct dso *dso, const char *name); @@ -915,14 +915,7 @@ u64 dso__findnew_global_type(struct dso *dso, u64 addr= , u64 offset); bool perf_pid_map_tid(const char *dso_name, int *tid); bool is_perf_pid_map_name(const char *dso_name); =20 -/* - * In the future, we may get debuginfo using build-ID (w/o path). - * Add this helper is for the smooth conversion. - */ -static inline struct debuginfo *dso__debuginfo(struct dso *dso) -{ - return debuginfo__new(dso__long_name(dso)); -} +struct debuginfo *dso__debuginfo(struct dso *dso); =20 const u8 *dso__read_symbol(struct dso *dso, const char *symfs_filename, const struct map *map, const struct symbol *sym, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 348EA34D4FE; Sat, 28 Feb 2026 17:33:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299989; cv=none; b=c2LfKbn5MPD6aeUpOlzVg19814BGmWDA9/ll+4o0n74Rh/IXTxWiUjEquTcHhlCJBPREGXrcS7HqEt88mDFTcucsG+pFI5RRAZORNbEwvuEig1ShZqM+pWR3xaHGlzl0ieskJagr7tZXFH8EVbrWsz3f5eN7nrrmi6pGncFIDfA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299989; c=relaxed/simple; bh=Xgz+rL+ffqb5LBvI8GygPcblHAni9QFWHkSQbiyyDrk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OzExQ57h6F/oMOjNqFsMemjUVRT0/y/SAHzQdNV4PK8qFKtwl3VQCZwuoos65IH8hHfKhT1Dw+mjrA2AP3p7yDPnpiKqN4PKFF26XetYaupiOyAFl+IZ3tZEI4hVc+M+hF4oEpAihQMbqZlhuyLShj/3y/qbvs8Rh1cergYIPgg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p4AkRx5X; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p4AkRx5X" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDDA3C116D0; Sat, 28 Feb 2026 17:33:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299988; bh=Xgz+rL+ffqb5LBvI8GygPcblHAni9QFWHkSQbiyyDrk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p4AkRx5XVU0DU7/PIrXwhV3ly+tCeLbZFOWpw9eOqz7mBNLIdtpqxOoh9uNS+Fg+B +HKWUMA/PEBEjjj7gmo7rRLZ55j+4uIebmpTgV8ZF4LjpMdZ3aOa49Cm/B6jIX1YfI cfa0KrpGX83PQOVqHhgnFhwGDV+s90yvyV6f/veQPdhgPZU4I7zNSHCCAQMwX3KBBv jvyH4n0Neh2y+yxdrtXpuvy6TtwwkJH04owJQ9hdfx+Khu3QuVIfb7d6DEpl7+93nh eGB4CtgbM+/5qsamr3J/+q9Pdql+JxzMlcSTRjMm0n4BSoF4C33PdQqxp3gzaLCDR8 s9Gu09CM0x8Rw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , kernel test robot , James Clark , Ingo Molnar , Jiri Olsa , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 014/844] perf tests kallsyms: Fix missed map__put() Date: Sat, 28 Feb 2026 12:18:47 -0500 Message-ID: <20260228173244.1509663-15-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit a58807adbed5f532efb231e5490767f284f237c0 ] Issue was caught by leak sanitizer and the test robot. Fixes: 34e271ae55382fbd ("perf test: Add kallsyms split test") Reported-by: kernel test robot Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Closes: https://lore.kernel.org/oe-lkp/202512101502.f3819cd3-lkp@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/tests/kallsyms-split.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/tests/kallsyms-split.c b/tools/perf/tests/kallsyms-= split.c index bbbc66957e5d0..117ed3b70f630 100644 --- a/tools/perf/tests/kallsyms-split.c +++ b/tools/perf/tests/kallsyms-split.c @@ -148,6 +148,7 @@ static int test__kallsyms_split(struct test_suite *test= __maybe_unused, ret =3D TEST_OK; =20 out: + map__put(map); remove_proc_dir(0); machine__exit(&m); return ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 59E9634E774; Sat, 28 Feb 2026 17:33:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299991; cv=none; b=tAIZEdulqzU++H7nb6fXUSjxU+09eETypVv9oldSXN2RMCRO3EuazDYzzoGTP/NfIGUlaD/B1J49gn3NJPod8iWjTzB1cH+UeDJfKrC30t9u9dPTEIFNb5OUT9UPmEjngD2G/gR8PM+NzwBlJi2hOR0AuwgmbFvwBFwFRjeyc50= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299991; c=relaxed/simple; bh=qbAPtx4sjNdZn1KCKbOSxvpOPTfPds582xmJdx/32nA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=smi7C/PMcwoeM59IBtHfZgnW2T7ulIab8YrZDWV3DsCXV1SVP6Xsfk9s7QL5J6KWFO+vsTYJ1hIa9vORwQbnA1Y9aqTD3OtNpuQwfwJh1SFy9eFrsyeU97Eqbx4WKOUbRsoeBhx9mL6LGSCOaiOB3vmV6Kfsozsikyv0Qw5mMZk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p2F+ZJXF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p2F+ZJXF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28013C2BC87; Sat, 28 Feb 2026 17:33:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299991; bh=qbAPtx4sjNdZn1KCKbOSxvpOPTfPds582xmJdx/32nA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p2F+ZJXFVWOkY3hpEAGqpTmNqp3rQl8jAw/zQjVR7UlKiseF4LSGSKyutbPPXGAMq FmaJ1OoFfpqUJ4eSmXe5bOeE+Ot/GfVHItipBmRmV61LO2qZy4sjEucLWKDJKRUDjG 5w7QmiL9Wf+c0qWbwYVmUnx0EUVk6P45SBuCtSbNt0cnZ2DItM8sZ+oRWc4CsiemZe Nr+1eD7sQJH2TO/LHi1qWpeIuMs4ivS3yGoAU41/HEGWH2Jt/vBAbKcDWGUbUk3uDa hI0JLRNzsnKBAqLLqJaSe4zXYHonWV9hP6PH40m2nPh1dupLyn5i2UrWJOgRQ6sQ/4 AHZmy6SoZ0NdQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: James Clark , Leo Yan , Adrian Hunter , Alexander Shishkin , coresight@lists.linaro.org, Ian Rogers , Ingo Molnar , Jiri Olsa , John Garry , Mark Rutland , Mike Leach , Namhyung Kim , Peter Zijlstra , Suzuki Poulouse , Thomas Falcon , Will Deacon , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 015/844] perf cs-etm: Fix decoding for sparse CPU maps Date: Sat, 28 Feb 2026 12:18:48 -0500 Message-ID: <20260228173244.1509663-16-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: James Clark [ Upstream commit a70493e2bb0878885aa7a8178162550270693eb1 ] The ETM decoder incorrectly assumed that auxtrace queue indices were equivalent to CPU number. This assumption is used for inserting records into the queue, and for fetching queues when given a CPU number. This assumption held when Perf always opened a dummy event on every CPU, even if the user provided a subset of CPUs on the commandline, resulting in the indices aligning. For example: # event : name =3D cs_etm//u, , id =3D { 2451, 2452 }, type =3D 11 (cs_et= m), size =3D 136, config =3D 0x4010, { sample_period, samp> # event : name =3D dummy:u, , id =3D { 2453, 2454, 2455, 2456 }, type =3D= 1 (PERF_TYPE_SOFTWARE), size =3D 136, config =3D 0x9 (PER> 0 0 0x200 [0xd0]: PERF_RECORD_ID_INDEX nr: 6 ... id: 2451 idx: 2 cpu: 2 tid: -1 ... id: 2452 idx: 3 cpu: 3 tid: -1 ... id: 2453 idx: 0 cpu: 0 tid: -1 ... id: 2454 idx: 1 cpu: 1 tid: -1 ... id: 2455 idx: 2 cpu: 2 tid: -1 ... id: 2456 idx: 3 cpu: 3 tid: -1 Since commit 811082e4b668 ("perf parse-events: Support user CPUs mixed with threads/processes") the dummy event no longer behaves in this way, making the ETM event indices start from 0 on the first CPU recorded regardless of its ID: # event : name =3D cs_etm//u, , id =3D { 771, 772 }, type =3D 11 (cs_etm)= , size =3D 144, config =3D 0x4010, { sample_period, sample> # event : name =3D dummy:u, , id =3D { 773, 774 }, type =3D 1 (PERF_TYPE_= SOFTWARE), size =3D 144, config =3D 0x9 (PERF_COUNT_SW_DUM> 0 0 0x200 [0x90]: PERF_RECORD_ID_INDEX nr: 4 ... id: 771 idx: 0 cpu: 2 tid: -1 ... id: 772 idx: 1 cpu: 3 tid: -1 ... id: 773 idx: 0 cpu: 2 tid: -1 ... id: 774 idx: 1 cpu: 3 tid: -1 This causes the following segfault when decoding: $ perf record -e cs_etm//u -C 2,3 -- true $ perf report perf: Segmentation fault -------- backtrace -------- #0 0xaaaabf9fd020 in ui__signal_backtrace setup.c:110 #1 0xffffab5c7930 in __kernel_rt_sigreturn [vdso][930] #2 0xaaaabfb68d30 in cs_etm_decoder__reset cs-etm-decoder.c:85 #3 0xaaaabfb65930 in cs_etm__get_data_block cs-etm.c:2032 #4 0xaaaabfb666fc in cs_etm__run_per_cpu_timeless_decoder cs-etm.c:2551 #5 0xaaaabfb6692c in (cs_etm__process_timeless_queues cs-etm.c:2612 #6 0xaaaabfb63390 in cs_etm__flush_events cs-etm.c:921 #7 0xaaaabfb324c0 in auxtrace__flush_events auxtrace.c:2915 #8 0xaaaabfaac378 in __perf_session__process_events session.c:2285 #9 0xaaaabfaacc9c in perf_session__process_events session.c:2442 #10 0xaaaabf8d3d90 in __cmd_report builtin-report.c:1085 #11 0xaaaabf8d6944 in cmd_report builtin-report.c:1866 #12 0xaaaabf95ebfc in run_builtin perf.c:351 #13 0xaaaabf95eeb0 in handle_internal_command perf.c:404 #14 0xaaaabf95f068 in run_argv perf.c:451 #15 0xaaaabf95f390 in main perf.c:558 #16 0xffffaab97400 in __libc_start_call_main libc_start_call_main.h:74 #17 0xffffaab974d8 in __libc_start_main@@GLIBC_2.34 libc-start.c:128 #18 0xaaaabf8aa8f0 in _start perf[7a8f0] Fix it by inserting into the queues based on CPU number, rather than using the index. Fixes: 811082e4b668db96 ("perf parse-events: Support user CPUs mixed with t= hreads/processes") Signed-off-by: James Clark Tested-by: Leo Yan Cc: Adrian Hunter Cc: Alexander Shishkin Cc: coresight@lists.linaro.org Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Mark Rutland Cc: Mike Leach Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Suzuki Poulouse Cc: Thomas Falcon Cc: Will Deacon Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/cs-etm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 25d56e0f1c078..12b55c2bc2ca4 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -3086,7 +3086,7 @@ static int cs_etm__queue_aux_fragment(struct perf_ses= sion *session, off_t file_o =20 if (aux_offset >=3D auxtrace_event->offset && aux_offset + aux_size <=3D auxtrace_event->offset + auxtrace_event->s= ize) { - struct cs_etm_queue *etmq =3D etm->queues.queue_array[auxtrace_event->id= x].priv; + struct cs_etm_queue *etmq =3D cs_etm__get_queue(etm, auxtrace_event->cpu= ); =20 /* * If this AUX event was inside this buffer somewhere, create a new auxt= race event @@ -3095,6 +3095,7 @@ static int cs_etm__queue_aux_fragment(struct perf_ses= sion *session, off_t file_o auxtrace_fragment.auxtrace =3D *auxtrace_event; auxtrace_fragment.auxtrace.size =3D aux_size; auxtrace_fragment.auxtrace.offset =3D aux_offset; + auxtrace_fragment.auxtrace.idx =3D etmq->queue_nr; file_offset +=3D aux_offset - auxtrace_event->offset + auxtrace_event->h= eader.size; =20 pr_debug3("CS ETM: Queue buffer size: %#"PRI_lx64" offset: %#"PRI_lx64 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DA8F34E774; Sat, 28 Feb 2026 17:33:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299995; cv=none; b=e432oOSlFLr2l6lAOfxi+EooYOES/G8/HNiv+oxn7UV6Y4R0sNojWgEsO7c4e97FI0xjjHb7+x+iLvVSgWNdI0ZeQ/xRW2UyF/pZ6Ms6iVnrsUZTQI16iexhVZSKu73rV5C0llRMirN4kdMT1xhxT91oyfP+ECpidc9UWdZdiVY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299995; c=relaxed/simple; bh=6qtRVGbtS3aR0ZqG9gZBcpPW4reY+sZyC7E9G0/88Kk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=gk9k8y9cIrjXnKL+4OuApJkbfKcsdEcND1v02eN6zFk8w+yG5C1X2LEtSK2zSqWeldQDGoMcr5OEa8Z/LckyLPXZUA6QgfUauDe8YZsMFK9hk41rfsmL4n84nT7czeH5baZIT87azsTylomRw+0tDjKGmq6jT14CpBj+lbeWWz8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RTVkpQot; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RTVkpQot" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 556D3C116D0; Sat, 28 Feb 2026 17:33:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299994; bh=6qtRVGbtS3aR0ZqG9gZBcpPW4reY+sZyC7E9G0/88Kk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RTVkpQotEjY2XKW5ptVdwWfYTC7/ezU4MXgnPRchNo0lRMOotHQw+Dl8MYwpDP0pM 8yDsxhZIjUH59wxIxdmPO9D4Z0xMI5qFI9JQOwyxzFAGXw7ffZ+Xu3MhfSDsEdS9gw wsdnl8NUO1akO43ERZbbT5/51epsX+F/hDjs3GUccP9Aatl7QI/pfzrOF8XLpWAKd2 XixJsg4ewOK/NHDB36ofzugTEd7ztYCjwwtEay7g2p/DkkCtqGQnMN519EWgml5W00 3zxbLRDTqlwSFci64itcQ+tx+a0rSGp9VS6cRQHJJ0e9Hte3aWNOwfqt3teoG6wYI6 iEbefzv2hUqLA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , James Clark , Aditya Bodkhe , Adrian Hunter , Albert Ou , Alexander Shishkin , Alexandre Ghiti , Athira Rajeev , Bill Wendling , "Dr. David Alan Gilbert" , Guo Ren , Howard Chu , Ingo Molnar , Jiri Olsa , John Garry , Julia Lawall , Justin Stitt , =?UTF-8?q?Krzysztof=20=C5=81opatowski?= , Leo Yan , linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-riscv@lists.infradead.org, Namhyung Kim , Nathan Chancellor , Nick Desaulniers , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Sergei Trofimovich , Shimin Guo , Suchit Karunakaran , Thomas Falcon , Tianyou Li , Will Deacon , Zecheng Li , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 016/844] perf annotate: Fix args leak of map_symbol Date: Sat, 28 Feb 2026 12:18:49 -0500 Message-ID: <20260228173244.1509663-17-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ian Rogers [ Upstream commit 00419892bac28bf148450d762bbff990a6bd5494 ] map_symbol__exit() needs calling on an annotate_args.ms, however, rather than introduce proper reference count handling to symbol__annotate() just switch to passing the map_symbol pointer parameter around, making the puts the caller's responsibility. Fix a number of cases to ensure the map in a map_symbol has a reference count increment and add the then necessary map_symbol_exits. Fixes: 56e144fe98260a0f ("perf mem_info: Add and use map_symbol__exit and a= ddr_map_symbol__exit") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Aditya Bodkhe Cc: Adrian Hunter Cc: Albert Ou Cc: Alexander Shishkin Cc: Alexandre Ghiti Cc: Athira Rajeev Cc: Bill Wendling Cc: Dr. David Alan Gilbert Cc: Guo Ren Cc: Howard Chu Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Julia Lawall Cc: Justin Stitt Cc: Krzysztof =C5=81opatowski Cc: Leo Yan Cc: linux-arm-kernel@lists.infradead.org Cc: linux-csky@vger.kernel.org Cc: linux-riscv@lists.infradead.org Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Sergei Trofimovich Cc: Shimin Guo Cc: Suchit Karunakaran Cc: Thomas Falcon Cc: Tianyou Li Cc: Will Deacon Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../arch/loongarch/annotate/instructions.c | 14 ++++---- tools/perf/arch/s390/annotate/instructions.c | 11 +++--- tools/perf/util/annotate.c | 2 +- tools/perf/util/capstone.c | 14 ++++---- tools/perf/util/disasm.c | 36 ++++++++++--------- tools/perf/util/disasm.h | 2 +- tools/perf/util/llvm.c | 6 ++-- 7 files changed, 47 insertions(+), 38 deletions(-) diff --git a/tools/perf/arch/loongarch/annotate/instructions.c b/tools/perf= /arch/loongarch/annotate/instructions.c index 70262d5f14442..1c3abb43c8d72 100644 --- a/tools/perf/arch/loongarch/annotate/instructions.c +++ b/tools/perf/arch/loongarch/annotate/instructions.c @@ -10,9 +10,7 @@ static int loongarch_call__parse(struct arch *arch, struc= t ins_operands *ops, st { char *c, *endptr, *tok, *name; struct map *map =3D ms->map; - struct addr_map_symbol target =3D { - .ms =3D { .map =3D map, }, - }; + struct addr_map_symbol target; =20 c =3D strchr(ops->raw, '#'); if (c++ =3D=3D NULL) @@ -38,12 +36,16 @@ static int loongarch_call__parse(struct arch *arch, str= uct ins_operands *ops, st if (ops->target.name =3D=3D NULL) return -1; =20 - target.addr =3D map__objdump_2mem(map, ops->target.addr); + target =3D (struct addr_map_symbol) { + .ms =3D { .map =3D map__get(map), }, + .addr =3D map__objdump_2mem(map, ops->target.addr), + }; =20 if (maps__find_ams(ms->maps, &target) =3D=3D 0 && map__rip_2objdump(target.ms.map, map__map_ip(target.ms.map, target.ad= dr)) =3D=3D ops->target.addr) ops->target.sym =3D target.ms.sym; =20 + addr_map_symbol__exit(&target); return 0; } =20 @@ -58,7 +60,7 @@ static int loongarch_jump__parse(struct arch *arch, struc= t ins_operands *ops, st struct map *map =3D ms->map; struct symbol *sym =3D ms->sym; struct addr_map_symbol target =3D { - .ms =3D { .map =3D map, }, + .ms =3D { .map =3D map__get(map), }, }; const char *c =3D strchr(ops->raw, '#'); u64 start, end; @@ -90,7 +92,7 @@ static int loongarch_jump__parse(struct arch *arch, struc= t ins_operands *ops, st } else { ops->target.offset_avail =3D false; } - + addr_map_symbol__exit(&target); return 0; } =20 diff --git a/tools/perf/arch/s390/annotate/instructions.c b/tools/perf/arch= /s390/annotate/instructions.c index c61193f1e0964..626e6d2cbc81a 100644 --- a/tools/perf/arch/s390/annotate/instructions.c +++ b/tools/perf/arch/s390/annotate/instructions.c @@ -6,9 +6,7 @@ static int s390_call__parse(struct arch *arch, struct ins_o= perands *ops, { char *endptr, *tok, *name; struct map *map =3D ms->map; - struct addr_map_symbol target =3D { - .ms =3D { .map =3D map, }, - }; + struct addr_map_symbol target; =20 tok =3D strchr(ops->raw, ','); if (!tok) @@ -36,12 +34,17 @@ static int s390_call__parse(struct arch *arch, struct i= ns_operands *ops, =20 if (ops->target.name =3D=3D NULL) return -1; - target.addr =3D map__objdump_2mem(map, ops->target.addr); + + target =3D (struct addr_map_symbol) { + .ms =3D { .map =3D map__get(map), }, + .addr =3D map__objdump_2mem(map, ops->target.addr), + }; =20 if (maps__find_ams(ms->maps, &target) =3D=3D 0 && map__rip_2objdump(target.ms.map, map__map_ip(target.ms.map, target.ad= dr)) =3D=3D ops->target.addr) ops->target.sym =3D target.ms.sym; =20 + addr_map_symbol__exit(&target); return 0; } =20 diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c index cc7764455faf6..791d60f97c23e 100644 --- a/tools/perf/util/annotate.c +++ b/tools/perf/util/annotate.c @@ -1031,7 +1031,7 @@ int symbol__annotate(struct map_symbol *ms, struct ev= sel *evsel, return 0; =20 args.arch =3D arch; - args.ms =3D *ms; + args.ms =3D ms; =20 if (notes->src =3D=3D NULL) { notes->src =3D annotated_source__new(); diff --git a/tools/perf/util/capstone.c b/tools/perf/util/capstone.c index be5fd44b1f9dc..2c7feab61b7bf 100644 --- a/tools/perf/util/capstone.c +++ b/tools/perf/util/capstone.c @@ -143,7 +143,7 @@ static void print_capstone_detail(cs_insn *insn, char *= buf, size_t len, struct annotate_args *args, u64 addr) { int i; - struct map *map =3D args->ms.map; + struct map *map =3D args->ms->map; struct symbol *sym; =20 /* TODO: support more architectures */ @@ -222,7 +222,7 @@ int symbol__disassemble_capstone(const char *filename _= _maybe_unused, { #ifdef HAVE_LIBCAPSTONE_SUPPORT struct annotation *notes =3D symbol__annotation(sym); - struct map *map =3D args->ms.map; + struct map *map =3D args->ms->map; struct dso *dso =3D map__dso(map); u64 start =3D map__rip_2objdump(map, sym->start); u64 offset; @@ -256,7 +256,7 @@ int symbol__disassemble_capstone(const char *filename _= _maybe_unused, args->line =3D disasm_buf; args->line_nr =3D 0; args->fileloc =3D NULL; - args->ms.sym =3D sym; + args->ms->sym =3D sym; =20 dl =3D disasm_line__new(args); if (dl =3D=3D NULL) @@ -268,7 +268,7 @@ int symbol__disassemble_capstone(const char *filename _= _maybe_unused, !strcmp(args->options->disassembler_style, "att")) disassembler_style =3D true; =20 - if (capstone_init(maps__machine(args->ms.maps), &handle, is_64bit, disass= embler_style) < 0) + if (capstone_init(maps__machine(args->ms->maps), &handle, is_64bit, disas= sembler_style) < 0) goto err; =20 needs_cs_close =3D true; @@ -345,7 +345,7 @@ int symbol__disassemble_capstone_powerpc(const char *fi= lename __maybe_unused, { #ifdef HAVE_LIBCAPSTONE_SUPPORT struct annotation *notes =3D symbol__annotation(sym); - struct map *map =3D args->ms.map; + struct map *map =3D args->ms->map; struct dso *dso =3D map__dso(map); struct nscookie nsc; u64 start =3D map__rip_2objdump(map, sym->start); @@ -382,7 +382,7 @@ int symbol__disassemble_capstone_powerpc(const char *fi= lename __maybe_unused, !strcmp(args->options->disassembler_style, "att")) disassembler_style =3D true; =20 - if (capstone_init(maps__machine(args->ms.maps), &handle, is_64bit, disass= embler_style) < 0) + if (capstone_init(maps__machine(args->ms->maps), &handle, is_64bit, disas= sembler_style) < 0) goto err; =20 needs_cs_close =3D true; @@ -408,7 +408,7 @@ int symbol__disassemble_capstone_powerpc(const char *fi= lename __maybe_unused, args->line =3D disasm_buf; args->line_nr =3D 0; args->fileloc =3D NULL; - args->ms.sym =3D sym; + args->ms->sym =3D sym; =20 dl =3D disasm_line__new(args); if (dl =3D=3D NULL) diff --git a/tools/perf/util/disasm.c b/tools/perf/util/disasm.c index 50b9433f3f8e6..924429142631a 100644 --- a/tools/perf/util/disasm.c +++ b/tools/perf/util/disasm.c @@ -269,9 +269,7 @@ static int call__parse(struct arch *arch, struct ins_op= erands *ops, struct map_s { char *endptr, *tok, *name; struct map *map =3D ms->map; - struct addr_map_symbol target =3D { - .ms =3D { .map =3D map, }, - }; + struct addr_map_symbol target; =20 ops->target.addr =3D strtoull(ops->raw, &endptr, 16); =20 @@ -296,12 +294,16 @@ static int call__parse(struct arch *arch, struct ins_= operands *ops, struct map_s if (ops->target.name =3D=3D NULL) return -1; find_target: - target.addr =3D map__objdump_2mem(map, ops->target.addr); + target =3D (struct addr_map_symbol) { + .ms =3D { .map =3D map__get(map), }, + .addr =3D map__objdump_2mem(map, ops->target.addr), + }; =20 if (maps__find_ams(ms->maps, &target) =3D=3D 0 && map__rip_2objdump(target.ms.map, map__map_ip(target.ms.map, target.ad= dr)) =3D=3D ops->target.addr) ops->target.sym =3D target.ms.sym; =20 + addr_map_symbol__exit(&target); return 0; =20 indirect_call: @@ -366,7 +368,7 @@ static int jump__parse(struct arch *arch, struct ins_op= erands *ops, struct map_s struct map *map =3D ms->map; struct symbol *sym =3D ms->sym; struct addr_map_symbol target =3D { - .ms =3D { .map =3D map, }, + .ms =3D { .map =3D map__get(map), }, }; const char *c =3D strchr(ops->raw, ','); u64 start, end; @@ -440,7 +442,7 @@ static int jump__parse(struct arch *arch, struct ins_op= erands *ops, struct map_s } else { ops->target.offset_avail =3D false; } - + addr_map_symbol__exit(&target); return 0; } =20 @@ -1046,7 +1048,7 @@ static size_t disasm_line_size(int nr) struct disasm_line *disasm_line__new(struct annotate_args *args) { struct disasm_line *dl =3D NULL; - struct annotation *notes =3D symbol__annotation(args->ms.sym); + struct annotation *notes =3D symbol__annotation(args->ms->sym); int nr =3D notes->src->nr_events; =20 dl =3D zalloc(disasm_line_size(nr)); @@ -1064,7 +1066,7 @@ struct disasm_line *disasm_line__new(struct annotate_= args *args) } else if (disasm_line__parse(dl->al.line, &dl->ins.name, &dl->ops.raw) = < 0) goto out_free_line; =20 - disasm_line__init_ins(dl, args->arch, &args->ms); + disasm_line__init_ins(dl, args->arch, args->ms); } =20 return dl; @@ -1119,7 +1121,7 @@ static int symbol__parse_objdump_line(struct symbol *= sym, struct annotate_args *args, char *parsed_line, int *line_nr, char **fileloc) { - struct map *map =3D args->ms.map; + struct map *map =3D args->ms->map; struct annotation *notes =3D symbol__annotation(sym); struct disasm_line *dl; char *tmp; @@ -1151,7 +1153,7 @@ static int symbol__parse_objdump_line(struct symbol *= sym, args->line =3D parsed_line; args->line_nr =3D *line_nr; args->fileloc =3D *fileloc; - args->ms.sym =3D sym; + args->ms->sym =3D sym; =20 dl =3D disasm_line__new(args); (*line_nr)++; @@ -1169,12 +1171,14 @@ static int symbol__parse_objdump_line(struct symbol= *sym, if (dl->ins.ops && ins__is_call(&dl->ins) && !dl->ops.target.sym) { struct addr_map_symbol target =3D { .addr =3D dl->ops.target.addr, - .ms =3D { .map =3D map, }, + .ms =3D { .map =3D map__get(map), }, }; =20 - if (!maps__find_ams(args->ms.maps, &target) && + if (!maps__find_ams(args->ms->maps, &target) && target.ms.sym->start =3D=3D target.al_addr) dl->ops.target.sym =3D target.ms.sym; + + addr_map_symbol__exit(&target); } =20 annotation_line__add(&dl->al, ¬es->src->source); @@ -1338,7 +1342,7 @@ static int symbol__disassemble_raw(char *filename, st= ruct symbol *sym, struct annotate_args *args) { struct annotation *notes =3D symbol__annotation(sym); - struct map *map =3D args->ms.map; + struct map *map =3D args->ms->map; struct dso *dso =3D map__dso(map); u64 start =3D map__rip_2objdump(map, sym->start); u64 end =3D map__rip_2objdump(map, sym->end); @@ -1375,7 +1379,7 @@ static int symbol__disassemble_raw(char *filename, st= ruct symbol *sym, args->line =3D disasm_buf; args->line_nr =3D 0; args->fileloc =3D NULL; - args->ms.sym =3D sym; + args->ms->sym =3D sym; =20 dl =3D disasm_line__new(args); if (dl =3D=3D NULL) @@ -1501,7 +1505,7 @@ static int symbol__disassemble_objdump(const char *fi= lename, struct symbol *sym, struct annotate_args *args) { struct annotation_options *opts =3D &annotate_opts; - struct map *map =3D args->ms.map; + struct map *map =3D args->ms->map; struct dso *dso =3D map__dso(map); char *command; FILE *file; @@ -1644,7 +1648,7 @@ static int symbol__disassemble_objdump(const char *fi= lename, struct symbol *sym, int symbol__disassemble(struct symbol *sym, struct annotate_args *args) { struct annotation_options *options =3D args->options; - struct map *map =3D args->ms.map; + struct map *map =3D args->ms->map; struct dso *dso =3D map__dso(map); char symfs_filename[PATH_MAX]; bool delete_extract =3D false; diff --git a/tools/perf/util/disasm.h b/tools/perf/util/disasm.h index d2cb555e4a3be..a3ea9d6762816 100644 --- a/tools/perf/util/disasm.h +++ b/tools/perf/util/disasm.h @@ -97,7 +97,7 @@ struct ins_ops { =20 struct annotate_args { struct arch *arch; - struct map_symbol ms; + struct map_symbol *ms; struct annotation_options *options; s64 offset; char *line; diff --git a/tools/perf/util/llvm.c b/tools/perf/util/llvm.c index 2ebf1f5f65bf7..4ada9a10bd93f 100644 --- a/tools/perf/util/llvm.c +++ b/tools/perf/util/llvm.c @@ -118,7 +118,7 @@ int symbol__disassemble_llvm(const char *filename, stru= ct symbol *sym, { #ifdef HAVE_LIBLLVM_SUPPORT struct annotation *notes =3D symbol__annotation(sym); - struct map *map =3D args->ms.map; + struct map *map =3D args->ms->map; struct dso *dso =3D map__dso(map); u64 start =3D map__rip_2objdump(map, sym->start); /* Malloc-ed buffer containing instructions read from disk. */ @@ -184,7 +184,7 @@ int symbol__disassemble_llvm(const char *filename, stru= ct symbol *sym, args->line =3D disasm_buf; args->line_nr =3D 0; args->fileloc =3D NULL; - args->ms.sym =3D sym; + args->ms->sym =3D sym; =20 dl =3D disasm_line__new(args); if (dl =3D=3D NULL) @@ -242,7 +242,7 @@ int symbol__disassemble_llvm(const char *filename, stru= ct symbol *sym, &line_storage_len); args->line_nr =3D 0; args->fileloc =3D NULL; - args->ms.sym =3D sym; + args->ms->sym =3D sym; =20 llvm_addr2line(filename, pc, &args->fileloc, (unsigned int *)&args->line_nr, false, NULL); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A698B352F86; Sat, 28 Feb 2026 17:33:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299998; cv=none; b=DwhElVWnK65T3mvw+QOoUwaklEtbFrDFK1mnHVxh738hINXirUBz2eOWbRyGQ+tONAOuee4fBYHjROVtfxIr5QePPTgndnpuV1sx/QXATFXFJIza/XIXzF4ZJ+WhO8e8E4PN7o2BvFfbZ5K8mvsypOChZq0KPLFquVSyE2czFN8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299998; c=relaxed/simple; bh=eW4hqNf92B1OlhPszuKg7mUbAKWHuynd9my3GOZaESQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tYuctf1Ic7mk+AwIUd7ZaXxpe1cyavm2plmJeExLTKsyex5Vj6YVD9BCMB5d+8JhlquZ6ORW+wE/QTYCL1vANdklfas0N9p2j/bwzWfgksvEzf4GNaS1AQYO1dDEWYbPsN6kvx1vtm1CR+dOh08uCllthLckZlEsU0ASkH9uq2k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BZpe8fi2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BZpe8fi2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 370E6C19424; Sat, 28 Feb 2026 17:33:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299998; bh=eW4hqNf92B1OlhPszuKg7mUbAKWHuynd9my3GOZaESQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BZpe8fi2idn1DMWv49MUB64B0lYl2OgIrQVSCyzFTElhHhIHsHzf8F0ghPMD12Wvd Y8S9vM0rFYJh0Ld65ohDZp3NVGZqVW0+fIDwl7iqQBjjuG31JuANsvdCHFrLb490J5 HK6nAm1fqf5LVws3ZLkMm4r67q590ysQ29aoLMS4QbGzdsHKW4nvKozaeDZNqt2jmC ZWCXZeyHa2B44X2MfFaqvDO4KpfpqALgfVRpRqa8Tjnp/FeI4q2rDRy5/AP4tCp1Tq LP+uXD7zmEp4HDupAen+Jv/WF1c5a1V+gd+BvLPpU65D85Y2TI/CnxNnPGeYSym2cy J2wwkn81slT1g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , James Clark , Aditya Bodkhe , Adrian Hunter , Albert Ou , Alexander Shishkin , Alexandre Ghiti , Athira Rajeev , Bill Wendling , "Dr. David Alan Gilbert" , Guo Ren , Howard Chu , Ingo Molnar , Jiri Olsa , John Garry , Julia Lawall , Justin Stitt , =?UTF-8?q?Krzysztof=20=C5=81opatowski?= , Leo Yan , Namhyung Kim , Nathan Chancellor , Nick Desaulniers , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Sergei Trofimovich , Shimin Guo , Suchit Karunakaran , Thomas Falcon , Tianyou Li , Will Deacon , Zecheng Li , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 017/844] perf maps: Fix reference count leak in maps__find_ams() Date: Sat, 28 Feb 2026 12:18:50 -0500 Message-ID: <20260228173244.1509663-18-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ian Rogers [ Upstream commit 6fdd2676db55b503c52dd3f1359b5c57f774ab75 ] ams and so ams->ms.map is an in argument, however, it is also overwritten. As a map is reference counted, ensure a map__put() is done before overwriting it. Fixes: 42fd623b58dbcc48 ("perf maps: Get map before returning in maps__find= ") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Aditya Bodkhe Cc: Adrian Hunter Cc: Albert Ou Cc: Alexander Shishkin Cc: Alexandre Ghiti Cc: Athira Rajeev Cc: Bill Wendling Cc: Dr. David Alan Gilbert Cc: Guo Ren Cc: Howard Chu Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Julia Lawall Cc: Justin Stitt Cc: Krzysztof =C5=81opatowski Cc: Leo Yan Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Sergei Trofimovich Cc: Shimin Guo Cc: Suchit Karunakaran Cc: Thomas Falcon Cc: Tianyou Li Cc: Will Deacon Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/maps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/maps.c b/tools/perf/util/maps.c index c321d4f4d8466..8885c95f02b3e 100644 --- a/tools/perf/util/maps.c +++ b/tools/perf/util/maps.c @@ -676,6 +676,7 @@ int maps__find_ams(struct maps *maps, struct addr_map_s= ymbol *ams) if (ams->addr < map__start(ams->ms.map) || ams->addr >=3D map__end(ams->m= s.map)) { if (maps =3D=3D NULL) return -1; + map__put(ams->ms.map); ams->ms.map =3D maps__find(maps, ams->addr); if (ams->ms.map =3D=3D NULL) return -1; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B7E43563C7; Sat, 28 Feb 2026 17:33:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300000; cv=none; b=mgZiUTCHoSQJJ0f5mjlLvDsxyTAi7dgRtWTXB8+gnCGunOVsEdVTGWYKrNNV69SUAkEyZVOGxLN4xyYJPiwA9AXy6PqUzXK45ErOzMewGcesc4oXV1u0wNrszkpdEas2qY11vnQRWdH3TBXCi867pbRAJT9hirED7F7z1NuQuiQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300000; c=relaxed/simple; bh=b6+1gnxBezrGNZf3K8NI12Al8ckqgqSf2o1BUGhHJOI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TlVz0+GZDlakQvfA5f5qnZRBpA8+L8VcYfbix7ecVE+QzI4Y1aAa9td7srgzHo2q4YRVzI3ZG4vdJKwE7GHiLk7CStCEA2CZddIROcXigF2Yu6vAdAyUPceZC9RXbUwaPacqlhOBnoJpZhaignAQTTWPRx7w6EurhNEim0ys8ec= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F8KmuQE8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F8KmuQE8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE26EC116D0; Sat, 28 Feb 2026 17:33:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300000; bh=b6+1gnxBezrGNZf3K8NI12Al8ckqgqSf2o1BUGhHJOI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F8KmuQE8wuZznHG/1Vmv4PCj3tw3/iXKK9/EwE4+6J9SjSrGikUcupvpwRqzhiDGR yR05SQ52BMxICwDeybGwp7M4c9HjoFwn0a+w6EfhdToPrgbX6XuiQ2ijntDswAi0tf lzGeAXm1cC4ESmwc2lka4+qiv8LSTUXLynNKmJFmqXYAEwkpiD0N6mEgmLSWKDAZlS aEGtWqjSgERtvU3eewewtHOh5qpzjqpNh+7MfurlhL1DNNK/pJOEZzpaaLPeYliPeE d/VKg1QbvpfCqv+dRfVd8en14Zjkbjlq6etNNRAX7LL+KSvmydnCEIstVWMOh21naZ +El4v1Ay59t9Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , Arnaldo Carvalho de Melo , Adrian Hunter , Alexander Shishkin , Ingo Molnar , James Clark , Jiri Olsa , Namhyung Kim , Peter Zijlstra , Sasha Levin Subject: [PATCH 6.19 018/844] perf tests sched: Avoid error in cleanup on loaded machines Date: Sat, 28 Feb 2026 12:18:51 -0500 Message-ID: <20260228173244.1509663-19-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit c5e47e4d00fbc15f2390bb6ed8d9c21836363291 ] The stop_noploops function will kill the noploop processes that are running for 10 seconds. On a loaded machine they may have already terminated meaning the kill will return an error of no such process. This doesn't matter and so ignore the error to avoid the test terminating in the cleanup. Fixes: 0e22c5ca44e68798 ("perf test: Add sched latency and script shell tes= ts") Signed-off-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/tests/shell/sched.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/tests/shell/sched.sh b/tools/perf/tests/shell/sched= .sh index b9b81eaf856e6..b9637069adb1f 100755 --- a/tools/perf/tests/shell/sched.sh +++ b/tools/perf/tests/shell/sched.sh @@ -53,7 +53,7 @@ start_noploops() { } =20 cleanup_noploops() { - kill "$PID1" "$PID2" + kill "$PID1" "$PID2" || true } =20 test_sched_record() { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1979F33F38A; Sat, 28 Feb 2026 17:33:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300002; cv=none; b=BKd0EDBItTeCUTd8GUt4KHcvXMfoNLM/5IaKUDCKs86QOP61aFrLNfKZicOee1aQJZMV6yXXQy/s533nXI9nEBNviHJySAA/drRj8SxLbVixka/mcC9MKuJm2tBX5JcySbiown8UbijlXeHbhEbNwSzYxPJyVMY/tuZbcyQzzu4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300002; c=relaxed/simple; bh=7uvaeHPoSH2tKbMUr/MemqSD7tr+E+a5e34IHw6SqrI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oT1dJhlt8QEZjD9PcS7wwRCTUO/rnS8DK+rFEqfc6T/hBkX3xlFCYUSpD7tUehC7bXw+r4yMR3vYSk/+3cABtyAjYEbkqA9RPbXiNGJtEQtsyaQpkmbZBubVUXqWgTScJNfPLRHMyWb4xXJyOobltz/aOQJ8kpotLt86a5k+1iE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qMdQklAI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qMdQklAI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AF80C19423; Sat, 28 Feb 2026 17:33:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300001; bh=7uvaeHPoSH2tKbMUr/MemqSD7tr+E+a5e34IHw6SqrI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qMdQklAIFhOKKZCtpCfgOrvPI5/wRXT7yKhRrv/zZsslg3zesU1TQo7hZS1zCWzZk L9Z0ndXn+2TWgHjgV8Lx16+QoVtswnhQPsTCYU/hitLx3wNtTnxq5O3G8saJjJVnCo Hvd5gBuOHcEu2Gs72RdYppQU2AJYMzuaRhUJl+rn33HhRkH0TNbOWIC7w2Aq1lzxEn 7VbeIqp3FNp0DiAkI9LBeIOv5BX2jbArQigqF6foQPwUmkOdK9V8zLtF8J3r7djIGC OoS0oRGHJsjqe1Eu2p6VTsP+GGnxWas7R1eBj9I6oKj0fRoZnYtpIZnWHWAI4Hm9nC caVmL0C0OQNqA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Suchit Karunakaran , Ian Rogers , Adrian Hunter , Alexander Shishkin , Ingo Molnar , James Clark , Jiri Olsa , Mark Rutland , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 019/844] perf annotate: Fix memcpy size in arch__grow_instructions() Date: Sat, 28 Feb 2026 12:18:52 -0500 Message-ID: <20260228173244.1509663-20-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Suchit Karunakaran [ Upstream commit f0d98c78f8bf73ce2a9b7793f66cda240fa9ab10 ] The memcpy() in arch__grow_instructions() is copying the wrong number of bytes when growing from a non-allocated table. It should copy arch->nr_instructions * sizeof(struct ins) bytes, not just arch->nr_instructions bytes. This bug causes data corruption as only a partial copy of the instruction table is made, leading to garbage data in most entries and potential crashes Fixes: 2a1ff812c40be982 ("perf annotate: Introduce alternative method of ke= eping instructions table") Reviewed-by: Ian Rogers Signed-off-by: Suchit Karunakaran Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/disasm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/disasm.c b/tools/perf/util/disasm.c index 924429142631a..88706b98b9064 100644 --- a/tools/perf/util/disasm.c +++ b/tools/perf/util/disasm.c @@ -81,7 +81,7 @@ static int arch__grow_instructions(struct arch *arch) if (new_instructions =3D=3D NULL) return -1; =20 - memcpy(new_instructions, arch->instructions, arch->nr_instructions); + memcpy(new_instructions, arch->instructions, arch->nr_instructions * size= of(struct ins)); goto out_update_instructions; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8502E36F40A; Sat, 28 Feb 2026 17:33:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300003; cv=none; b=isv5JbV06NTyPY3hb7yCcpDDVHBimKqJ+73JfA5Jbt+6SekhR7n5oCYAitIdZu+PSRQXrguyMi3gxbmA+FvSbe0CjDY04QI3WTGJAk3NdUE4w4o+DLn13YsTyYD/SShNFOXrNJIMvV9dkt3xK/MyR91HZRqQQsuIyJdIr5iJT50= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300003; c=relaxed/simple; bh=YS4ql6IaG0Yax69ihYE0M0rLl2ObJX9geCS7pWfRBR4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Dey+OhUmX2LdRQu5VRi7UwYwPeQxApfzFJobhLx0BMCFzvmGKveTvp1vRqLJ2umzxjA+rSJs2zLODyhrmepzze5I9aoDpR97Y19k9AjhyJlHr9Wf/UotiA9GiBI4gUkLhEaiL+Q2tZ9aGaznday0J83w2g43B7CUCnKuyI/7jD8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BDjaMBNZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BDjaMBNZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04945C2BCB0; Sat, 28 Feb 2026 17:33:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300003; bh=YS4ql6IaG0Yax69ihYE0M0rLl2ObJX9geCS7pWfRBR4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BDjaMBNZzh4f+lS/VU63ytjjUxw0aV6ndD2g7NzdP5vxeSxZkawFAF9l2hgev5Uyw 0PBFnsZU7rg3so2BYLuyBM264LZX+D1aWx1osdeFyU5CsyxQJmyje1ai4RYjv8p5S9 4l+GKwneLmI5BYcCO6/RRtPljR1rWOB+WOpV9x+qa3HuNJ+zs3R9QB80z/0AAVyvAG 1n99BQFIduUqz8k3O+7iZKwoMSojEb7SNsyxnhx5Vg6fxABZlngLICbGN59cxLC1PI 7iDZSBz+RhhCzCbYR0+NrYJEeDXUKxV5x2AAfqm6yNhR/0YOAHExfcGZVppdSw2pHm xU6AOgWLEeFEQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Leo Yan , James Clark , Adrian Hunter , Arnd Bergmann , Ian Rogers , Jiri Olsa , Namhyung Kim , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 020/844] tools headers: Go back to include asm-generic/unistd.h for arm64 Date: Sat, 28 Feb 2026 12:18:53 -0500 Message-ID: <20260228173244.1509663-21-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Leo Yan [ Upstream commit 096b86ce08332fbcb0ec6ff6714c44899ec03970 ] The header unistd.h is included under Arm64's uAPI folder (see tools/arch/arm64/include/uapi/asm/), but it does not include its dependent header unistd_64.h. The intention is for unistd_64.h to be generated dynamically using scripts/Makefile.asm-headers. However, this dynamic approach causes problems because the header is not available early enough, even though it is widely included throughout tools. Using the perf build as an example: 1) Feature detection: Perf first runs feature tests. The BPF feature program test-bpf.c includes unistd.h. Since unistd_64.h has not been generated yet, the program fails to build, and the BPF feature ends up being disabled. 2) libperf build: The libperf Makefile later generates unistd_64.h on the fly, so libperf itself builds successfully. 3) Final perf build: Although the perf binary can build successfully using the generated header, we never get a chance to build BPF skeleton programs, because BPF support was already disabled earlier. Restore to include asm-generic/unistd.h for fixing the issue. This aligns with most architectures (x86 is a special case that keeps unistd_32.h/unistd_64.h for its particular syscall numbers) and ensures the header is available from the start. Fixes: 22f72088ffe69a37 ("tools headers: Update the syscall table with the = kernel sources") Reviewed-by: James Clark Signed-off-by: Leo Yan Cc: Adrian Hunter Cc: Arnd Bergmann Cc: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/arch/arm64/include/uapi/asm/unistd.h | 24 +++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/tools/arch/arm64/include/uapi/asm/unistd.h b/tools/arch/arm64/= include/uapi/asm/unistd.h index df36f23876e86..9306726337fe0 100644 --- a/tools/arch/arm64/include/uapi/asm/unistd.h +++ b/tools/arch/arm64/include/uapi/asm/unistd.h @@ -1,2 +1,24 @@ /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#include +/* + * Copyright (C) 2012 ARM Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + */ + +#define __ARCH_WANT_RENAMEAT +#define __ARCH_WANT_NEW_STAT +#define __ARCH_WANT_SET_GET_RLIMIT +#define __ARCH_WANT_TIME32_SYSCALLS +#define __ARCH_WANT_MEMFD_SECRET + +#include --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 211B63EBF04; Sat, 28 Feb 2026 17:33:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300004; cv=none; b=RmNYH4tCq/z2N5nXXIQ95unJx4pbm8MVDN1H/trRHZpkckq8Ri/yGHnjq6bWSd+aX5DVa1or7gTKEcR3l5MOWdPidZj3zv8n2MIXHKLjcsoFzrAGllo0YkoBJpHurI/EFB3jeVMb1LiDIyiI6SIZMh2tLAfgDWYUwtUYY6pDNYo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300004; c=relaxed/simple; bh=oC5OwErzOvt25sNB0iDaPD1OFTzz8KCsCEwh8JtgNgU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JNAjUBg4d+yA4GEDyp+c8pG/JnBFyjf1vWYskMjmz/DFFiAU9CfbNhs4i/OLI7S0B8Ii5NVjzMK+WR399ps7GlJ/P9iN7AU22897CFftKyUjC9P3cokjlsL7m/cPu7BqOHVw/7sKjyRoviFE335uevdMdNSA1DSRNF9X1umUqzo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z7z2mfJU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z7z2mfJU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6ADDDC19423; Sat, 28 Feb 2026 17:33:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300004; bh=oC5OwErzOvt25sNB0iDaPD1OFTzz8KCsCEwh8JtgNgU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z7z2mfJU80Rs3qOSbtc5CAx/TV9PBDRM3prRFrhXoPBz0z6V+4IFx0OPrdlDjdmEC Qg0fuIzlONjob2Ihjpt65BWLviiId1Af7pthMJlWqQy54OwELQXfoKAJMh9v5NqvlP XHjkDEs6Q5OHmTGd5X+RdNHUKkL4fzWezofD8VsMbCdMwWC0PB6r61UYVcAQcajOSF e961fHK+194KspP1a2OzrLkpkY8ZC1DLCdLdL8Cq/2J1VvwPXKf5DMJ4N4JUzD9xlj 3mCuSpCF/YtQksrKShGyX2V+c+MLdoQ7lx892LEwXei/NJQFK5io893iw4pVGc0XiP bJyG7X8jMINaA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnaldo Carvalho de Melo , Ian Rogers , Sasha Levin Subject: [PATCH 6.19 021/844] perf annotate: Fix BUILD_NONDISTRO=1 missing args->ms conversions to pointer Date: Sat, 28 Feb 2026 12:18:54 -0500 Message-ID: <20260228173244.1509663-22-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo [ Upstream commit dda5f926a1006c735b00ed5c27291fce64236656 ] Fix a few missing conversions to pointer in the usage of 'struct annotate_args' 'ms' member in symbol__disassemble_bpf_libbfd(). Fixes: 00419892bac28bf1 ("perf annotate: Fix args leak of map_symbol") Reviewed-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/libbfd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/libbfd.c b/tools/perf/util/libbfd.c index 79f4528234a9d..63ea3fb53e77d 100644 --- a/tools/perf/util/libbfd.c +++ b/tools/perf/util/libbfd.c @@ -501,7 +501,7 @@ int symbol__disassemble_bpf_libbfd(struct symbol *sym _= _maybe_unused, struct bpf_prog_info_node *info_node; int len =3D sym->end - sym->start; disassembler_ftype disassemble; - struct map *map =3D args->ms.map; + struct map *map =3D args->ms->map; struct perf_bpil *info_linear; struct disassemble_info info; struct dso *dso =3D map__dso(map); @@ -612,7 +612,7 @@ int symbol__disassemble_bpf_libbfd(struct symbol *sym _= _maybe_unused, args->line =3D strdup(srcline); args->line_nr =3D 0; args->fileloc =3D NULL; - args->ms.sym =3D sym; + args->ms->sym =3D sym; dl =3D disasm_line__new(args); if (dl) { annotation_line__add(&dl->al, @@ -624,7 +624,7 @@ int symbol__disassemble_bpf_libbfd(struct symbol *sym _= _maybe_unused, args->line =3D buf + prev_buf_size; args->line_nr =3D 0; args->fileloc =3D NULL; - args->ms.sym =3D sym; + args->ms->sym =3D sym; dl =3D disasm_line__new(args); if (dl) annotation_line__add(&dl->al, ¬es->src->source); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CF81E450902; Sat, 28 Feb 2026 17:33:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300005; cv=none; b=ascej5Etsqs9kBPrjMmw9AASeSQPzo9E4/Z67eY53YdutFbuWfuuwheqOR/V4JB+IQaXuf53ENAt120VWndtwGzDKGmyC+RP9IslndcKE/aNZil8dw7TG1rq9nbVlx/Ipp3WuRouF4FClXscMnL6W/INrSXIBqqlAjn7ZOw08yY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300005; c=relaxed/simple; bh=z/kL/bJWc08kyBG3h3vrZ//IIQRb6+jQdKuzcY2PTKI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q6RkQtBNwa2gWMrxDD18w+zMCdPCUgz2WHzQiaBlmzPU/zJJEJX11bWOoAFqs2UtHvm3wLA846wDG4HAZT8P3aGXYx1n/O0LK1nVIneNdKDu3Rwu9QG8KurhFvr8lipF/724EZfxgJ6cg2fwcFodiqt+ic5CguW50k1+hiE+/Wg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ff8zy+Yr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ff8zy+Yr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4512AC19425; Sat, 28 Feb 2026 17:33:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300005; bh=z/kL/bJWc08kyBG3h3vrZ//IIQRb6+jQdKuzcY2PTKI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ff8zy+YrMR+vuJkecCOCZhao97aPV9/qCtj8b71N7fWMrLSNEnbpHMDqfRLufUkFY hdejQ8NDO33wE5esv/iN7D+HARDlqjNtxNtKknMCd6j1ouXCT1cZCfFtKq6/aIjMIi BR9BWTvDm/AZYDLPoATNMhsjdvICoInViz9mlpGkAMql2NjmjLPW23mElwVV1PiQwE 756K3c4hSyC2hMbv4TyGXSn/68fo6MIuIY/RSmzyHdoz/hueBtPH3qfWrKu8VF5VbR WFBs0yrFr136m6F6HNt512kY25g9V8qJp6z0iR17prdW+juEhfpsZOzu6sA6kSjjQ0 Lhurniv6dbK2w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Richter , Ian Rogers , Jan Polensky , Alexander Gordeev , Heiko Carstens , Namhyung Kim , Sumanth Korikkar , Vasily Gorbik , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 022/844] perf test: Fix test perf evlist for z/VM s390x Date: Sat, 28 Feb 2026 12:18:55 -0500 Message-ID: <20260228173244.1509663-23-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Richter [ Upstream commit 008603bda19b29687edce533e4c09acff68c1077 ] Perf test case 'perf evlist tests' fails on z/VM machines on s390. The failure is causes by event cycles. This event is not available on virtualized machines like z/VM on s390. Change to software event cpu-clock to fix this. Output before: # ./perf test 78 79: perf evlist tests : FAILED! # Output after: # ./perf test 78 79: perf evlist tests : Ok # Fixes: b04d2b9199129f4f ("perf test: Fix test case perf evlist tests for s3= 90x") Reviewed-by: Ian Rogers Reviewed-by: Jan Polensky Signed-off-by: Thomas Richter Tested-by: Jan Polensky Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Thomas Richter Cc: Vasily Gorbik Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/tests/shell/evlist.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/tests/shell/evlist.sh b/tools/perf/tests/shell/evli= st.sh index 5632be3917109..8a22f4171c07c 100755 --- a/tools/perf/tests/shell/evlist.sh +++ b/tools/perf/tests/shell/evlist.sh @@ -21,13 +21,13 @@ trap trap_cleanup EXIT TERM INT =20 test_evlist_simple() { echo "Simple evlist test" - if ! perf record -e cycles -o "${perfdata}" true 2> /dev/null + if ! perf record -e cpu-clock -o "${perfdata}" true 2> /dev/null then echo "Simple evlist [Failed record]" err=3D1 return fi - if ! perf evlist -i "${perfdata}" | grep -q "cycles" + if ! perf evlist -i "${perfdata}" | grep -q "cpu-clock" then echo "Simple evlist [Failed to list event]" err=3D1 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD4F046AEF1; Sat, 28 Feb 2026 17:33:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300007; cv=none; b=OoyUTvYevpBUJ4KWCmwkw5X/4gj4DJm6v43WvEjubuZottYfObfXljG4WFhzqT8KS2d/FYxPtbxMHClkZaZDiTIi6ov5KNxn3xylxnifcasvCdMJL5HM8MPdGbyZ8fhkhGonJ1/BhbmXbSkLBJ9aSjxlHO66CrOcHxjDH6goU7g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300007; c=relaxed/simple; bh=5DLthrwaQ4P8bCT3/l3haLmoSWFTHHexrJJVVVyJFYI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y96rw9RKfa4TiH6vG+kplc0nUV3Di7CMJWJF1NMpOtqWLFrm5xKNnZURfEfeJ4gkID7VaBAw2ehjLvo9ObtH7ZsxYttcLfpS1tcsuwK5uSAcLsepUI3kVhFbZt0BPWHHr1criqAvoPFY/BUET/2IaK+uaUl1a+VEYS0LMGYm/mY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s4Y56Ajc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s4Y56Ajc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9476C19423; Sat, 28 Feb 2026 17:33:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300007; bh=5DLthrwaQ4P8bCT3/l3haLmoSWFTHHexrJJVVVyJFYI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s4Y56AjckbpHTsvZ651IA1MDdRUUhMZ8mw+YX23J7cQreEXxPfO4yLIfV2dacLqjj +65QfSUQTWauvXomaCqcqT1Qa1pdFjbsw4uTSSv7WYr8+KehbWQohZwecfbL/ZTFEG INBJepPP8M7POQvxph+3kJqUhZUNV50ePDs9/XXvOumNSvigONXBtmRUd5aXSope9A tBiKKUHoZnle3g3une4UuX4VymxmQB0GrXhbzzZu11s3EHmwwGx+IFON73YVTkohXH ym8bO9mxcxEOJkMvjEsX3FlzwY9tUR78sKeYFwFktvrKThG1j6GXskUJV9iyLgUeu3 mTQ4c3NWmQ/7Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sandipan Das , Suyash Mahar , Ian Rogers , Adrian Hunter , Alexander Shishkin , Ananth Narayan , Ingo Molnar , James Clark , Jiri Olsa , Mark Rutland , Namhyung Kim , Peter Zijlstra , Ravi Bangoria , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 023/844] perf vendor events amd: Fix Zen 5 MAB allocation events Date: Sat, 28 Feb 2026 12:18:56 -0500 Message-ID: <20260228173244.1509663-24-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sandipan Das [ Upstream commit 76b2cf07a6d2a836108f9c2486d76599f7adf6e8 ] The unit masks for PMCx041 vary across different generations of Zen processors. Fix the Zen 5 events based on PMCx041 as they incorrectly use the same unit masks as that of Zen 4. Fixes: 45c072f2537ab07b ("perf vendor events amd: Add Zen 5 core events") Reported-by: Suyash Mahar Reviewed-by: Ian Rogers Signed-off-by: Sandipan Das Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ananth Narayan Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Sandipan Das Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/pmu-events/arch/x86/amdzen5/load-store.json | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/perf/pmu-events/arch/x86/amdzen5/load-store.json b/tools= /perf/pmu-events/arch/x86/amdzen5/load-store.json index ff6627a778057..06bbaea159259 100644 --- a/tools/perf/pmu-events/arch/x86/amdzen5/load-store.json +++ b/tools/perf/pmu-events/arch/x86/amdzen5/load-store.json @@ -70,19 +70,19 @@ "EventName": "ls_mab_alloc.load_store_allocations", "EventCode": "0x41", "BriefDescription": "Miss Address Buffer (MAB) entries allocated by a = Load-Store (LS) pipe for load-store allocations.", - "UMask": "0x3f" + "UMask": "0x07" }, { "EventName": "ls_mab_alloc.hardware_prefetcher_allocations", "EventCode": "0x41", "BriefDescription": "Miss Address Buffer (MAB) entries allocated by a = Load-Store (LS) pipe for hardware prefetcher allocations.", - "UMask": "0x40" + "UMask": "0x08" }, { "EventName": "ls_mab_alloc.all_allocations", "EventCode": "0x41", "BriefDescription": "Miss Address Buffer (MAB) entries allocated by a = Load-Store (LS) pipe for all types of allocations.", - "UMask": "0x7f" + "UMask": "0x0f" }, { "EventName": "ls_dmnd_fills_from_sys.local_l2", --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3530C450902; Sat, 28 Feb 2026 17:33:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300009; cv=none; b=c5sQbageXmUu8O9Np5JX5VO6OMzj4HiemXTLnm4shxYI4d0nHsYszcUcZjuRPBqw5a8JBRETAVPJFtgrZVJSc/fVxkImRYzFulu172oPDmmS1mxl1zBPemAIdNam9+ff6BsUOXr48v0+Pd5aSsnPc9aU5Y/S8QIOgi9wPUkxb48= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300009; c=relaxed/simple; bh=5heWpwcKAHRgxqAbeBFY0hVw+1VaYDXdi1vvfst4SY8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WgawUUb/krrzP5hhc9yMTAlaMR1Vcu6n7Ch3vjnFUE2JC+kLCINgQb4fXr6P83p10cLJzce4clAytU6C8r5zZkkEvCms6esp0gMjqhYHcoGALCBnQKVsnDKF+/VHtuLF48jghc63DTemsYHl/OokmRrtMTrPjNyCn9piN1GejHo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iybTeFrx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iybTeFrx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABECDC2BCAF; Sat, 28 Feb 2026 17:33:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300009; bh=5heWpwcKAHRgxqAbeBFY0hVw+1VaYDXdi1vvfst4SY8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iybTeFrx+v5UldbmXXKH1MI5M8V7ALTNlQO0E3np8OvwYgh7eMyDPCA7a6wpSfqxx 46jzE2zxECcnBsAqqkySWofyopjp/AG2dzpcj1xUq3eIy6mSdtt2xtCvrJvccAi6Fh fKokqXDsuwhN2MjrWU11Wv7y9W/FZuuMhWkrEUn1swBv+91jYyNOqf4F1ogoiiXlNQ MRs051IUagi8acDy9EhT6tUsu95rGZRMPnY8A3XgppCaMo9iI8T1zIakA2WaEg0g+H xo3cA6q6EXp2i/hRTnsj7JXBWBQKyf102n/P6BS+PZCet8zTsBrsqqA4qpWIMR6JcU vHn7xTbnBhNtA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: James Clark , Mark Brown , Adrian Hunter , Alexander Shishkin , Ian Rogers , Ingo Molnar , Jiri Olsa , Mark Rutland , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 024/844] perf jevents: Handle deleted JSONS in out of source builds Date: Sat, 28 Feb 2026 12:18:57 -0500 Message-ID: <20260228173244.1509663-25-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: James Clark [ Upstream commit 297c9d96e3085116c5cde18170dba716a1f2591e ] Make the source folders a dependency for the generated folder root so that whenever a file is deleted from the source it will force a new fresh copy of all the JSON files and avoid stale deleted files. JSON_DIRS_OUTPUT_ROOT needs to be a dependency of LEGACY_CACHE_JSON so that the root folder doesn't get cleaned after the legacy JSON is generated. But this is a no-op with in-source builds as JSON_DIRS_OUTPUT_ROOT is unset. JSON_DIRS is added as a dependency of PMU_EVENTS_C which also forces a re-build for in source builds when JSON files are deleted. This could have also resulted in stale builds, but never a broken one. Closes: https://lore.kernel.org/linux-next/aW5XSAo88_LBPSYI@sirena.org.uk/ Fixes: 4bb55de4ff03db3e ("perf jevents: Support copying the source json fil= es to OUTPUT") Reported-by: Mark Brown Signed-off-by: James Clark Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/pmu-events/Build | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/tools/perf/pmu-events/Build b/tools/perf/pmu-events/Build index a46ab7b612dfc..4f9ef624ba70d 100644 --- a/tools/perf/pmu-events/Build +++ b/tools/perf/pmu-events/Build @@ -1,5 +1,6 @@ pmu-events-y +=3D pmu-events.o JSON =3D $(shell find pmu-events/arch -name '*.json' -o -name '*.csv') +JSON_DIRS =3D $(shell find pmu-events/arch -type d) JDIR_TEST =3D pmu-events/arch/test JSON_TEST =3D $(shell [ -d $(JDIR_TEST) ] && \ find $(JDIR_TEST) -name '*.json') @@ -31,16 +32,23 @@ $(PMU_EVENTS_C): $(EMPTY_PMU_EVENTS_C) else # Copy checked-in json to OUTPUT for generation if it's an out of source b= uild ifneq ($(OUTPUT),) -$(OUTPUT)pmu-events/arch/%: pmu-events/arch/% +# Remove all output directories when any source directory timestamp changes +# so there are no stale deleted files +JSON_DIRS_ROOT =3D $(OUTPUT)pmu-events/arch/ +$(JSON_DIRS_ROOT): $(JSON_DIRS) + $(Q)$(call echo-cmd,gen)rm -rf $@ + $(Q)mkdir -p $@ + +$(OUTPUT)pmu-events/arch/%: pmu-events/arch/% $(JSON_DIRS_ROOT) $(call rule_mkdir) $(Q)$(call echo-cmd,gen)cp $< $@ endif =20 -$(LEGACY_CACHE_JSON): $(LEGACY_CACHE_PY) +$(LEGACY_CACHE_JSON): $(LEGACY_CACHE_PY) $(JSON_DIRS_ROOT) $(call rule_mkdir) $(Q)$(call echo-cmd,gen)$(PYTHON) $(LEGACY_CACHE_PY) > $@ =20 -GEN_JSON =3D $(patsubst %,$(OUTPUT)%,$(JSON)) $(LEGACY_CACHE_JSON) +GEN_JSON =3D $(patsubst %,$(OUTPUT)%,$(JSON)) $(LEGACY_CACHE_JSON) $(JSON_= DIRS) =20 $(METRIC_TEST_LOG): $(METRIC_TEST_PY) $(METRIC_PY) $(call rule_mkdir) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC7A646AEF1; Sat, 28 Feb 2026 17:33:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300010; cv=none; b=VMPrcJjlcUJFOV68eJkGEnLqZmrTc1rdGGZasydBAhhVTDS6ZmQFWn+1yR5VPzxwxTl8U/sK44p9nEQ/9FLIG9DisL3T1bAhMreTPTvcy2VnNMIl4zht6RXiY4hrlqUdavUBkki61/athsmh85nGlF8TW99/QmYbQss02Zj5fWw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300010; c=relaxed/simple; bh=Wm5Ozx2khlW+XZO3E5ippyq/P9BQL9xkCFfyFdNKLbE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G34yyLNlhXAQthMKplMNaOj/4DktKpiytPVUwXVJafSB+7NBAGYvC1qrnGt4E3OktSlhbCmquk0MkIxumqF79kDfpWM/GSigF9rUjqyYZxeRsRA9WpNlN/i1S9MKgAFneLsg/t18I7uWtUpLCtvf+0FvRGQFKt3u8I/le6JEo3Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ec2JHmwu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ec2JHmwu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C380C19423; Sat, 28 Feb 2026 17:33:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300010; bh=Wm5Ozx2khlW+XZO3E5ippyq/P9BQL9xkCFfyFdNKLbE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ec2JHmwuYwqrV5pFORFXNjZLrbK85a0uDBBLs5M4K7asOYNW7WN0QnVwMdF4OsgCq hH/aY7w7xxaV/pZ8EEJORP9Brvo0Tydv25dlsA4QPimLZhmTC1fipgrr5xcngyPKsJ SWBEYn/6WC0NNh8k9+JhFQW7nkkI8a3S3pEcppEoAKDCRE8XzURa+s7PUtVSs7N7un tNI8quzxZ81Q/Pa1tgE0Kr3J3CUbQuI4jBv99FDA+/x/saf/bnqF5Y5NKeHbxpaHwv Jz0CG9IjjImljZDBUxNa+OpvkLI5d2bIK2kzyTYfdTTOVHgLP/z2aCydvCDg0NMseA AY+ZrlPLRCg/w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , Adrian Hunter , Alexander Shishkin , Ingo Molnar , James Clark , Jiri Olsa , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 025/844] perf build: Remove NO_LIBCAP that controls nothing Date: Sat, 28 Feb 2026 12:18:58 -0500 Message-ID: <20260228173244.1509663-26-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit 169343cc8ff2bd59758760d867bd26adae866a2b ] Using libcap was removed in commit e25ebda78e230283 ("perf cap: Tidy up and improve capability testing") and improve capability testing"), however, some build documentation and a use of the NO_LIBCAP=3D1 were lingering. Remove these left over bits. Fixes: e25ebda78e230283 ("perf cap: Tidy up and improve capability testing") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/Makefile.perf | 2 -- tools/perf/tests/make | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index e6895626c1872..fbeb5c81c8072 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -86,8 +86,6 @@ include ../scripts/utilities.mak # # Define NO_LIBBPF if you do not want BPF support # -# Define NO_LIBCAP if you do not want process capabilities considered by p= erf -# # Define NO_SDT if you do not want to define SDT event in perf tools, # note that it doesn't disable SDT scanning support. # diff --git a/tools/perf/tests/make b/tools/perf/tests/make index 6641701e48285..c721cd1bcaa9a 100644 --- a/tools/perf/tests/make +++ b/tools/perf/tests/make @@ -122,7 +122,7 @@ make_minimal +=3D NO_DEMANGLE=3D1 NO_LIBELF=3D1 = NO_BACKTRACE=3D1 make_minimal +=3D NO_LIBNUMA=3D1 NO_LIBBIONIC=3D1 NO_LIBDW=3D1 make_minimal +=3D NO_LIBDW_DWARF_UNWIND=3D1 NO_LIBBPF=3D1 make_minimal +=3D NO_SDT=3D1 NO_JVMTI=3D1 NO_LIBZSTD=3D1 -make_minimal +=3D NO_LIBCAP=3D1 NO_CAPSTONE=3D1 +make_minimal +=3D NO_CAPSTONE=3D1 =20 # $(run) contains all available tests run :=3D make_pure --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65EC847CC9B; Sat, 28 Feb 2026 17:33:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300012; cv=none; b=EZQdJ/qDbjtCAaIUhG1SXODN38qFsqRVBiFcyXSNw/BYLKg4Wfzd5Bxjjxl3T/302gsRdHaaw3VoP+yDMiXjZOySPsXJsQNbiJIOkuQpa2yB74kvEOKmeP9hFmAjPKRFuhYMaor3pXlV/+Rmrn1tgjl4e2Kc3d/fcAuLyuJ5DU0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300012; c=relaxed/simple; bh=arL/7RVLXJxrKVxhxcK9OJ/+zcoX0CjtV+x8HUGf0ic=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VhNVqjYY7nZv6yamfRdRZWoyA2DqzbBqT9fYJPxpBRJtRyKfSBSARPO4qgewHd5Aun+hddK76vtTdsHI7Opaw5mSp/FtAotebFEQ3GKW92ghTrmQ3KeackqOeebRPlQSuunFPMfQ7nAqrtDgVp19D/vuE+ZjDIY82w10a1BBLXk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ritUV/BC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ritUV/BC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBB84C2BCB3; Sat, 28 Feb 2026 17:33:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300012; bh=arL/7RVLXJxrKVxhxcK9OJ/+zcoX0CjtV+x8HUGf0ic=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ritUV/BClRe5EopSH+p/1AxrG1cPNBUw6oUjebWHzSarws8T61xMeJWXGjnQwopYY 1x9LjxYbmzoX8deY1o4ahAQKOkn3r6UTEV8gL2lxZUz2mazhNcogG/iVHhvx6cuG4f +bMzb6nNgrpk79jjL+ZHyshGVErj6BASKWHDy861S7a20EkuEIh7YyLghWf4/mNX1j 5DxSAa/WmjvCvMZ1qRcdryBEur6jPBL/0/hEUDCh/RcV6ZAmjDgxbN9SKecDObg41T APHRcR3qPKD+CDzsmeCp6JZrxeuTfRR4XS0hJejbOdWOMm+7r6bkbDdVKHkiLpHlcw 93vabIoCAbj1A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , Adrian Hunter , Alexander Shishkin , Ingo Molnar , James Clark , Jiri Olsa , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 026/844] libperf build: Always place libperf includes first Date: Sat, 28 Feb 2026 12:18:59 -0500 Message-ID: <20260228173244.1509663-27-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit 8c5b40678c63be6b85f1c2dc8c8b89d632faf988 ] When building tools/perf the CFLAGS can contain a directory for the installed headers. As the headers may be being installed while building libperf.a this can cause headers to be partially installed and found in the include path while building an object file for libperf.a. The installed header may reference other installed headers that are missing given the partial nature of the install and then the build fails with a missing header file. Avoid this by ensuring the libperf source headers are always first in the CFLAGS. Fixes: 3143504918105156 ("libperf: Make libperf.a part of the perf build") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/lib/perf/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/perf/Makefile b/tools/lib/perf/Makefile index 7fbb50b74c00b..5c64122bf5374 100644 --- a/tools/lib/perf/Makefile +++ b/tools/lib/perf/Makefile @@ -51,9 +51,9 @@ INCLUDES =3D \ -I$(srctree)/tools/include/uapi =20 # Append required CFLAGS +override CFLAGS :=3D $(INCLUDES) $(CFLAGS) override CFLAGS +=3D -g -Werror -Wall override CFLAGS +=3D -fPIC -override CFLAGS +=3D $(INCLUDES) override CFLAGS +=3D -fvisibility=3Dhidden override CFLAGS +=3D $(EXTRA_WARNINGS) override CFLAGS +=3D $(EXTRA_CFLAGS) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4BE947D936; Sat, 28 Feb 2026 17:33:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300013; cv=none; b=s0NW72qSeCjfOSDWCbJd10IkdlL6eam66dNQM9RgiGmIc+K9gOijMD3Iw4e1QF7u7izsLzqBTU+AD9wdQOeWAB+/8wAu2dTx2LIrSSFDTaUDvOfI1yUhxIFeZaxf/Xg4mhINX2vZQrfAM+gTL7bujuiJS15tLdnIP6ZDBFLyjKc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300013; c=relaxed/simple; bh=MYr2c1J4ADOsnfOTVMpeAwnhXCKn5YEPLHCPJdyqI2g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DLSUJb6Pyfi6CWS7DGRA/em14XA8R/zqkWAz8c55Hx4lJtdlPtUaHlFoLGvrUlolkLabT+x9yKVxCNvRdzm5JWPusS0zn47Q7LFOXSC6liSXCwO8Suk4DZm4OeMAbvlxcA1mELiGAIjOBQj4sG2rnq5+PpUEcgqlSpdFiLM4mwg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s47DDAEL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s47DDAEL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F838C116D0; Sat, 28 Feb 2026 17:33:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300013; bh=MYr2c1J4ADOsnfOTVMpeAwnhXCKn5YEPLHCPJdyqI2g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s47DDAELBfTi33vNHmnCnBHei7rS8CcENBF4HsMUQeajIzST7CyDauWp0roqvcrvh fd8jDl+VcWpZAFeWkkBxKoXU9nLyhdS8geYLwkdaAK7YlRS5uQi7ct31WhQeaLZimR 3HmR3ESgBk1VHE2PhGJ5+8+GlcT55W4/dDG6My8DwyzSZ0AG/AXQlm32+Mc6UHkycW kbvxCc8L/iGnCvTGgZRAb1JH7iuJS0YE2zQiutE9bxtKxBv7flTVhAsLZJt1fOItUs 3Ec/RaxudiQjeVYSX/ssy4SoePz62nKCDqMTcQE9SSRFHKFuHH5NSuS99nBSAIh9Sh 6Ae8B1e9Y+nsA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , Leo Yan , Adrian Hunter , Alexander Shishkin , Ingo Molnar , James Clark , Jiri Olsa , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 027/844] perf metricgroup: Don't early exit if no CPUID table exists Date: Sat, 28 Feb 2026 12:19:00 -0500 Message-ID: <20260228173244.1509663-28-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit cee275edcdb1acfdc8270f80e96f30750b633220 ] The failure to find a table of metrics with a CPUID shouldn't early exit as the metric code will now also consider the default table. When searching for a metric or metric group, pmu_metrics_table__for_each_metric() considers all tables and so the caller doesn't need to switch the table to do this. Fixes: c7adeb0974f18da4 ("perf jevents: Add set of common metrics based on = default ones") Reviewed-by: Leo Yan Signed-off-by: Ian Rogers Tested-by: Leo Yan Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/metricgroup.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c index 25c75fdbfc525..a21f2d4969c5c 100644 --- a/tools/perf/util/metricgroup.c +++ b/tools/perf/util/metricgroup.c @@ -1563,8 +1563,6 @@ int metricgroup__parse_groups(struct evlist *perf_evl= ist, { const struct pmu_metrics_table *table =3D pmu_metrics_table__find(); =20 - if (!table) - return -EINVAL; if (hardware_aware_grouping) pr_debug("Use hardware aware grouping instead of traditional metric grou= ping method\n"); =20 @@ -1602,22 +1600,16 @@ static int metricgroup__has_metric_or_groups_callba= ck(const struct pmu_metric *p =20 bool metricgroup__has_metric_or_groups(const char *pmu, const char *metric= _or_groups) { - const struct pmu_metrics_table *tables[2] =3D { - pmu_metrics_table__find(), - pmu_metrics_table__default(), - }; + const struct pmu_metrics_table *table =3D pmu_metrics_table__find(); struct metricgroup__has_metric_data data =3D { .pmu =3D pmu, .metric_or_groups =3D metric_or_groups, }; =20 - for (size_t i =3D 0; i < ARRAY_SIZE(tables); i++) { - if (pmu_metrics_table__for_each_metric(tables[i], - metricgroup__has_metric_or_groups_callback, - &data)) - return true; - } - return false; + return pmu_metrics_table__for_each_metric(table, + metricgroup__has_metric_or_groups_callback, + &data) + ? true : false; } =20 static int metricgroup__topdown_max_level_callback(const struct pmu_metric= *pm, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4930947D954; Sat, 28 Feb 2026 17:33:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300015; cv=none; b=rOFYeF97uNeMYk7s6tWzHG3Gd3dnegf/PY3ySpZ/tThBvcmFi3hPkIAi6CFFU1fUuNlKhvr4ORBZPkhY9QJxTgtoHXw4ql1uwIvaODMdcwqW29ZfNoo0cKp8Esin86NgQPskDuHk2fIcECKj0oDlaqAbVxALbFAIf+r1SOFohdU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300015; c=relaxed/simple; bh=bjZvF3HoqucTEu5JA0Fv2fjutW/UGHafxWfYSwNBAoY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=swUQtKvp4KHquEg2S5l4TazYOq9pA3F6/arYkVWb1HMPHmEUwZsDEsqUMF4UVMbXCdcnfi+24eYJw/UUvblNxDgFmT/0dChwP8mpAdD934ieuRBd5+Vopu2wNDs67n5El2DY0I7uIdvWE9Ig4iLP3Wxl6MHeORtZS0wTXggiJ0M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a3ZnkdMt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a3ZnkdMt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB158C2BC87; Sat, 28 Feb 2026 17:33:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300015; bh=bjZvF3HoqucTEu5JA0Fv2fjutW/UGHafxWfYSwNBAoY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a3ZnkdMt7cBUTvqnJNtrERsWlS0JgGXC5nSZNtjcsyvNkveM/5Oa8pLRCUe7TDIQs +w8ttn/gH40YUA0DkTofcJi2eE/eMWmBnJZmtwvVMNnEkM+vgKmtwF30D3CoSLblsW fNIeTAJkSvKOFfFEBujlNCIzFJpbdIChKYqhx15qZyAcqJbM+sjmNdYsll6qxl14Z9 WHbPtGIF70uYMIGYVL/6rcWHfC2J7jUCctwnpwKrygZvxB/WvQI67abn/5cnYF5fzS rwqw+bNGm4vgzjC3Gv3JvKw3gGEBZNZbs3mA9lzahH0IUgT/a4yRVO4vbaHo0yQGwE JNEsswcoAByhQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Richter , Jan Polensky , Alexander Gordeev , Heiko Carstens , Ian Rogers , linux-s390@vger.kernel.org, Namhyung Kim , Sumanth Korikkar , Vasily Gorbik , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 028/844] perf test: Fix test case perftool-testsuite_report for s390 Date: Sat, 28 Feb 2026 12:19:01 -0500 Message-ID: <20260228173244.1509663-29-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Richter [ Upstream commit 3d012b8614ee020666f3dd15af9f65dc487e3f5f ] Test case perftool-testsuite_report fails on s390 for some time now. Root cause is a time out which is too tight for large s390 machines. The time out value addr2line_timeout_ms is per default set to 1 second. This is the maximum time the function read_addr2line_record() waits for a reply from the forked off tool addr2line, which is started as a child in interactive mode. It reads stdin (an address in hexadecimal) and replies on stdout with function name, file name and line number. This might take more than one second. However one second is not always enough and the reply from addr2line tool is not received. Function read_addr2line_record() fails and emits a warning, which is not expected by the test case. It fails. Output before: # perf test -F 133 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data file =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.087 MB \ /tmp/perftool-testsuite_report.FHz/perf_report/perf.data.1 \ (207 samples) ] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- [ PASS ] -- perf_report :: setup :: prepare the perf.data.1 file ## [ PASS ] ## perf_report :: setup SUMMARY -- [ SKIP ] -- perf_report :: test_basic :: help message :: testcase skipp= ed Line did not match any pattern: "cmd__addr2line /usr/lib/debug/lib/modules/ 6.19.0-20260205.rc8.git366.9845cf73f7db.300.fc43.s390x+next/ vmlinux: could not read first record" Line did not match any pattern: "cmd__addr2line /usr/lib/debug/lib/modules/ 6.19.0-20260205.rc8.git366.9845cf73f7db.300.fc43.s390x+next/ vmlinux: could not read first record" -- [ FAIL ] -- perf_report :: test_basic :: basic execution (output regexp parsing) .... 133: perftool-testsuite_report : FAILED! Output after: # ./perf test -F 133 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data file =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.087 MB \ /tmp/perftool-testsuite_report.Mlp/perf_report/perf.data.1 (188 samples) ] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- [ PASS ] -- perf_report :: setup :: prepare the perf.data.1 file ## [ PASS ] ## perf_report :: setup SUMMARY -- [ SKIP ] -- perf_report :: test_basic :: help message :: testcase skipp= ed -- [ PASS ] -- perf_report :: test_basic :: basic execution -- [ PASS ] -- perf_report :: test_basic :: number of samples -- [ PASS ] -- perf_report :: test_basic :: header -- [ PASS ] -- perf_report :: test_basic :: header timestamp -- [ PASS ] -- perf_report :: test_basic :: show CPU utilization -- [ PASS ] -- perf_report :: test_basic :: pid -- [ PASS ] -- perf_report :: test_basic :: non-existing symbol -- [ PASS ] -- perf_report :: test_basic :: symbol filter -- [ PASS ] -- perf_report :: test_basic :: latency header -- [ PASS ] -- perf_report :: test_basic :: default report for latency pro= file -- [ PASS ] -- perf_report :: test_basic :: latency report for latency pro= file -- [ PASS ] -- perf_report :: test_basic :: parallelism histogram ## [ PASS ] ## perf_report :: test_basic SUMMARY 133: perftool-testsuite_report : Ok # Fixes: 257046a36750a6db ("perf srcline: Fallback between addr2line implemen= tations") Reviewed-by: Jan Polensky Signed-off-by: Thomas Richter Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Ian Rogers Cc: linux-s390@vger.kernel.org Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Vasily Gorbik Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/addr2line.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/addr2line.c b/tools/perf/util/addr2line.c index f2d94a3272d71..a8b39f4f202b6 100644 --- a/tools/perf/util/addr2line.c +++ b/tools/perf/util/addr2line.c @@ -18,8 +18,8 @@ =20 #define MAX_INLINE_NEST 1024 =20 -/* If addr2line doesn't return data for 1 second then timeout. */ -int addr2line_timeout_ms =3D 1 * 1000; +/* If addr2line doesn't return data for 5 seconds then timeout. */ +int addr2line_timeout_ms =3D 5 * 1000; =20 static int filename_split(char *filename, unsigned int *line_nr) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F9F947DD4A; Sat, 28 Feb 2026 17:33:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300016; cv=none; b=KFPE8cFcfLI8tOJubopxy8ItR4ziqKF5T8LIFctswqAX+1fo99ZpToT5NkAoIvL30ZX/+Y2zxfw75Giw17O6GkIRuC4GHBX4iCn+v2A7lKSuaX9aiG/SaQaq+n9V7nYCpARXdPSXhNwlkeK7Sh9pfoDYV+ybvut0x0mLGhoYhJ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300016; c=relaxed/simple; bh=GhDcMxB0dkxuFqlAzjTKzKEfE96+SmqNYcX3i2Jy8N8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Wl9El+fNVwqkWCVOLG62UNwyomFq8TK4gXEOkot7WXUR9VFtvmf27UWLEqwgmYp0hqLemDjhqopmDHygJxACee9ZCGSW9l+PdUl+rGbL6d3gUPdIDGrQC/v4KSkIqg71kxVpAPAIlWfgfQyCMyM4CDXHIzL3JfcNpvHTyYHlYVA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Yu1BLb9t; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yu1BLb9t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EFD7C19425; Sat, 28 Feb 2026 17:33:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300016; bh=GhDcMxB0dkxuFqlAzjTKzKEfE96+SmqNYcX3i2Jy8N8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Yu1BLb9tvJ338iqFApxUKuwNCy8LaVWqJHTecJJYnqGbNVoKV3Q88n3IvCao2TXWt GJ97yDbmYzQcNgeNKiewtuYt7DHXlIB8dQ91WNXeDkn68mDBwZ/KUUgKA9lZGM5zzc PWBnGiPZ0rvgiCwEUsTIY30sCYJLPwp1ija7g7pJCvxmqOzMNjh80nrZ3YmU3m5O2r LzqDZMNRgAwtlEOj04FlqI/XNIuuev1vo4Abrx/Ar/L58mdBi+x+APX4MuX9AX2ATG mk9Ipox2HZvDQnC0f9Sxxt/Z4uUHq5p5+RTIptV6dRN6ZqT5TZWhBwR69CiaANkFol z/FLElqdtpZ1w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miguel Ojeda , FUJITA Tomonori , Alice Ryhl , Sasha Levin Subject: [PATCH 6.19 029/844] objtool/rust: add one more `noreturn` Rust function Date: Sat, 28 Feb 2026 12:19:02 -0500 Message-ID: <20260228173244.1509663-30-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miguel Ojeda [ Upstream commit c431b00ca6afc5da3133636ecc34ee7edd38d6cc ] `objtool` with Rust 1.84.0 reports: rust/kernel.o: error: objtool: _RNvXNtNtCsaRPFapPOzLs_6kernel3str9parse= _intaNtNtB2_7private12FromStrRadix14from_str_radix() falls through to next function _RNvXNtNtCsaRPFapPOzLs_6kernel3str9parse= _intaNtNtB2_7private12FromStrRadix16from_u64_negated() This is very similar to commit c18f35e49049 ("objtool/rust: add one more `noreturn` Rust function"), which added `from_ascii_radix_panic` for Rust 1.86.0, except that Rust 1.84.0 ends up needing `from_str_radix_panic`. Thus add it to the list to fix the warning. Cc: FUJITA Tomonori Fixes: 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functio= ns") Reported-by: Alice Ryhl Link: https://rust-for-linux.zulipchat.com/#narrow/channel/291565/topic/x/w= ith/572427627 Tested-by: Alice Ryhl Link: https://patch.msgid.link/20260206204336.38462-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/objtool/check.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 3fd98c5b6e1a8..37ec0d757e9b1 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -197,7 +197,8 @@ static bool is_rust_noreturn(const struct symbol *func) * as well as changes to the source code itself between versions (since * these come from the Rust standard library). */ - return str_ends_with(func->name, "_4core3num22from_ascii_radix_panic") = || + return str_ends_with(func->name, "_4core3num20from_str_radix_panic") || + str_ends_with(func->name, "_4core3num22from_ascii_radix_panic") = || str_ends_with(func->name, "_4core5sliceSp15copy_from_slice17len_mi= smatch_fail") || str_ends_with(func->name, "_4core6option13expect_failed") || str_ends_with(func->name, "_4core6option13unwrap_failed") || --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 137DB47DD6B; Sat, 28 Feb 2026 17:33:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300018; cv=none; b=cVYiHzlbuGEwL7OiewkDVxbwHJs6t8erDQoPGLAlU9NmlrkFMfGb7yM6XGyMu9eTm+X8ONiiXM3o9L8+/DkWAcsM5S8hqkMXc2INcNsx5XuTY4HSv6ZostHL1y8knEnBlZVedkJ74dYHv5tmbVnUVaKCmauBIGrEvnwQrvhg5Sw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300018; c=relaxed/simple; bh=bSaXqGvxkb3yGTMEVun/Oo/Uh6Aj9cUn7V6/DfCuGGI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MNMCNJSrYUVyuFjxjkuYrTxH8Rtm0J7TEn8qtZY6r1hJWPCQ8FXegTClutQa86M6FaKjMh1y6WeZZfT8AkrfNjx1UWHpf7kXTYzOklopDBbh+OTWtC2iyB8rKlcMmwSj8uoiyj0Owmt8PykDeNthG3uu8O32wknlwc0s7v2A/vg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hz+GPP3f; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hz+GPP3f" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6653EC116D0; Sat, 28 Feb 2026 17:33:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300018; bh=bSaXqGvxkb3yGTMEVun/Oo/Uh6Aj9cUn7V6/DfCuGGI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hz+GPP3f6RXBO7ChSYI7DdHyUr+SjyAoJpT0omE593nTpEuUfj7om+X58JCQ6VunS 36pck1LmA0/bCegxfTNo7XF5TgBcuZPvgMzkfuA42Sxp3mYA9ZJbpvp1/EhIf2uMVd b+K/HKOJpQGTcEcMn9o1lByP1jT0tdgiJzz2k6QQ9cVDfkiOIv/jinrfjoMPI6NqIl JuzHxox6yEgQegy4IfxaPUj8bgTijjWR7LMF2XvG5sACYwDPYKN5lXCfSp7K81VEKR U/BsvYu1S/nUDbTcIp5xatdyfJt1R254ioQtCS0D0tABLk0F42zhOCCfQRaY2ySz8k bwbS9WvPaO2Dw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chun-Tse Shao , Ian Rogers , Adrian Hunter , Alexander Shishkin , Ingo Molnar , James Clark , Jiri Olsa , Kan Liang , Mark Rutland , Namhyung Kim , Peter Zijlstra , Yang Li , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 030/844] perf stat: Ensure metrics are displayed even with failed events Date: Sat, 28 Feb 2026 12:19:03 -0500 Message-ID: <20260228173244.1509663-31-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chun-Tse Shao [ Upstream commit bb5a920b9099127915706fdd23eb540c9a69c338 ] Currently, `perf stat` skips or hides metrics when the underlying hardware events cannot be counted (e.g., due to insufficient permissions or unsupported events). In `--metric-only` mode, this often results in missing columns or blank spaces, making the output difficult to parse. Modify the logic to ensure metrics are consistently displayed by propagating NAN (Not a Number) through the expression evaluator. Specifically: 1. Update `prepare_metric()` in stat-shadow.c to treat uncounted events (where `run =3D=3D 0`) as NAN. This leverages the existing math in expr.y to propagate NAN through metric expressions. 2. Remove the early return in the display logic's `printout()` function that was previously skipping metrics in `--metric-only` mode for failed events. l 3. Simplify `perf_stat__skip_metric_event()` to no longer depend on event runtime. Tested: 1. `perf all metrics test` did not crash while paranoid is 2. 2. Multiple combinations with `CPUs_utilized` while paranoid is 2. $ ./perf stat -M CPUs_utilized -a -- sleep 1 Performance counter stats for 'system wide': msec cpu-clock:u # nan CPUs = CPUs_utilized 1,006,356,120 duration_time 1.004375550 seconds time elapsed $ ./perf stat -M CPUs_utilized -a -j -- sleep 1 {"counter-value" : "", "unit" : "msec", "event" : "cpu-clo= ck:u", "event-runtime" : 0, "pcnt-running" : 100.00, "metric-value" : "nan"= , "metric-unit" : "CPUs CPUs_utilized"} {"counter-value" : "1006642462.000000", "unit" : "", "event" : "duration_= time", "event-runtime" : 1, "pcnt-running" : 100.00} $ ./perf stat -M CPUs_utilized -a --metric-only -- sleep 1 Performance counter stats for 'system wide': CPUs CPUs_utilized nan 1.004424652 seconds time elapsed $ ./perf stat -M CPUs_utilized -a --metric-only -j -- sleep 1 {"CPUs CPUs_utilized" : "none"} Reviewed-by: Ian Rogers Signed-off-by: Chun-Tse Shao Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Yang Li Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 63b320aaac08 ("perf stat-shadow: In prepare_metric fix guard= on reading NULL perf_stat_evsel") Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/stat-display.c | 59 +++++++++++++++------------------- tools/perf/util/stat-shadow.c | 8 ++--- tools/perf/util/stat.h | 2 +- 3 files changed, 29 insertions(+), 40 deletions(-) diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c index 6d02f84c5691a..f4bd579908b43 100644 --- a/tools/perf/util/stat-display.c +++ b/tools/perf/util/stat-display.c @@ -820,12 +820,6 @@ static void printout(struct perf_stat_config *config, = struct outstate *os, } =20 if (run =3D=3D 0 || ena =3D=3D 0 || counter->counts->scaled =3D=3D -1) { - if (config->metric_only) { - pm(config, os, METRIC_THRESHOLD_UNKNOWN, /*format=3D*/NULL, - /*unit=3D*/NULL, /*val=3D*/0); - return; - } - ok =3D false; =20 if (counter->supported) { @@ -848,33 +842,32 @@ static void printout(struct perf_stat_config *config,= struct outstate *os, print_running(config, os, run, ena, /*before_metric=3D*/true); } =20 - if (ok) { - if (!config->metric_only && counter->default_metricgroup && !counter->de= fault_show_events) { - void *from =3D NULL; - - aggr_printout(config, os, os->evsel, os->id, os->aggr_nr); - /* Print out all the metricgroup with the same metric event. */ - do { - int num =3D 0; - - /* Print out the new line for the next new metricgroup. */ - if (from) { - if (config->json_output) - new_line_json(config, (void *)os); - else - __new_line_std_csv(config, os); - } - - print_noise(config, os, counter, noise, /*before_metric=3D*/true); - print_running(config, os, run, ena, /*before_metric=3D*/true); - from =3D perf_stat__print_shadow_stats_metricgroup(config, counter, ag= gr_idx, - &num, from, &out); - } while (from !=3D NULL); - } else { - perf_stat__print_shadow_stats(config, counter, aggr_idx, &out); - } + if (!config->metric_only && counter->default_metricgroup && + !counter->default_show_events) { + void *from =3D NULL; + + aggr_printout(config, os, os->evsel, os->id, os->aggr_nr); + /* Print out all the metricgroup with the same metric event. */ + do { + int num =3D 0; + + /* Print out the new line for the next new metricgroup. */ + if (from) { + if (config->json_output) + new_line_json(config, (void *)os); + else + __new_line_std_csv(config, os); + } + + print_noise(config, os, counter, noise, + /*before_metric=3D*/true); + print_running(config, os, run, ena, + /*before_metric=3D*/true); + from =3D perf_stat__print_shadow_stats_metricgroup( + config, counter, aggr_idx, &num, from, &out); + } while (from !=3D NULL); } else { - pm(config, os, METRIC_THRESHOLD_UNKNOWN, /*format=3D*/NULL, /*unit=3D*/N= ULL, /*val=3D*/0); + perf_stat__print_shadow_stats(config, counter, aggr_idx, &out); } =20 if (!config->metric_only) { @@ -987,7 +980,7 @@ static void print_counter_aggrdata(struct perf_stat_con= fig *config, ena =3D aggr->counts.ena; run =3D aggr->counts.run; =20 - if (perf_stat__skip_metric_event(counter, ena, run)) + if (perf_stat__skip_metric_event(counter)) return; =20 if (val =3D=3D 0 && should_skip_zero_counter(config, counter, &id)) diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c index 9c83f7d96caa4..5d8d09e0e6ae5 100644 --- a/tools/perf/util/stat-shadow.c +++ b/tools/perf/util/stat-shadow.c @@ -83,7 +83,7 @@ static int prepare_metric(struct perf_stat_config *config, } /* Time events are always on CPU0, the first aggregation index. */ aggr =3D &ps->aggr[is_tool_time ? tool_aggr_idx : aggr_idx]; - if (!aggr || !metric_events[i]->supported) { + if (!aggr || !metric_events[i]->supported || aggr->counts.run =3D=3D 0) { /* * Not supported events will have a count of 0, which * can be confusing in a metric. Explicitly set the @@ -335,14 +335,10 @@ void perf_stat__print_shadow_stats(struct perf_stat_c= onfig *config, * perf_stat__skip_metric_event - Skip the evsel in the Default metricgrou= p, * if it's not running or not the metric event. */ -bool perf_stat__skip_metric_event(struct evsel *evsel, - u64 ena, u64 run) +bool perf_stat__skip_metric_event(struct evsel *evsel) { if (!evsel->default_metricgroup) return false; =20 - if (!ena || !run) - return true; - return !metricgroup__lookup(&evsel->evlist->metric_events, evsel, false); } diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h index f986911c9296e..4bced233d2fc0 100644 --- a/tools/perf/util/stat.h +++ b/tools/perf/util/stat.h @@ -163,7 +163,7 @@ void perf_stat__print_shadow_stats(struct perf_stat_con= fig *config, struct evsel *evsel, int aggr_idx, struct perf_stat_output_ctx *out); -bool perf_stat__skip_metric_event(struct evsel *evsel, u64 ena, u64 run); +bool perf_stat__skip_metric_event(struct evsel *evsel); void *perf_stat__print_shadow_stats_metricgroup(struct perf_stat_config *c= onfig, struct evsel *evsel, int aggr_idx, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7509F47DD65; Sat, 28 Feb 2026 17:33:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300020; cv=none; b=sIEA+lJqiU4MpiIlg6mBElFmhtKDvb3jMKSl321QZK+ttvkODDZP6SgQWOa02/lJxGLiyYZZefUHzqd66+lB2+n6XqrRGBOnDQh6iXs4CeLnax78Z1sQiNg31j3dyxjay1QCxg9y2eXn2FsQPxk8d8DydwR6gimThVttPaAtuII= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300020; c=relaxed/simple; bh=JR68V0AaPNuDBa1mHAvLSTn9vSVneWjfgN9rsMZwjUE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ph9CC20npcmW2feoXRYcWZbNiehHCcPEmtzb4HpB+QeIeODvl88yBMlXHLQX/uYQk1ffoPEY+zZo/h4F1fVTATHAcFYAVzG37RxXj1IqXfiuJrMpbrFuOWQIxVwixHrwSAsqO/6F9xOCfpTR/sn9RlxeKKBiMVZv3LwskG/LWGE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VWB8LFIQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VWB8LFIQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4628FC116D0; Sat, 28 Feb 2026 17:33:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300020; bh=JR68V0AaPNuDBa1mHAvLSTn9vSVneWjfgN9rsMZwjUE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VWB8LFIQwdgl+Y1baiFe9YsxvpFpfiNBlsqdP5y83Bd6xZy2onPh/mcTG0++jqrJa Nr3wV1jSUdXJIbZZy3/prGe3dybzNVMAKv72Cpec/f1+fSq6M3TAcWpTvo4aq+muRT K0xCejO7O4SPZj6M3HzEh9G/H/bzZXAOTHDwbb8rz8mpjMKHUUrNnLgd4mMxZtR7nc 2GijrKVHqnjH8TH2E1LKlRCne/pwwyd0jT0CFsCgLzeiajhQ3hM8gFr98OUz/J+hQj b908iv1zCfXq3OCVqMHt6Ozszv3DIhd+u+fq6DV7/MEm33sQRnViL9Lz5leRtqCh8j yEJ2JiEfHZXbg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , Andres Freund , Adrian Hunter , Alexander Shishkin , Andi Kleen , Dapeng Mi , "Dr. David Alan Gilbert" , Ingo Molnar , James Clark , Jiri Olsa , Namhyung Kim , Peter Zijlstra , Thomas Falcon , Thomas Richter , Yang Li , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 031/844] perf stat-shadow: In prepare_metric fix guard on reading NULL perf_stat_evsel Date: Sat, 28 Feb 2026 12:19:04 -0500 Message-ID: <20260228173244.1509663-32-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit 63b320aaac08ba267268ec21a195ce3c82dcb8ab ] The aggr value is setup to always be non-null creating a redundant guard for reading from it. Switch to using the perf_stat_evsel (ps) and narrow the scope of aggr so that it is known valid when used. Fixes: 3d65f6445fd93e3e ("perf stat-shadow: Read tool events directly") Reported-by: Andres Freund Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Dapeng Mi Cc: Dr. David Alan Gilbert Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Falcon Cc: Thomas Richter Cc: Yang Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/perf/util/stat-shadow.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c index 5d8d09e0e6ae5..59d2cd4f2188d 100644 --- a/tools/perf/util/stat-shadow.c +++ b/tools/perf/util/stat-shadow.c @@ -57,7 +57,6 @@ static int prepare_metric(struct perf_stat_config *config, bool is_tool_time =3D tool_pmu__is_time_event(config, metric_events[i], &tool_aggr_idx); struct perf_stat_evsel *ps =3D metric_events[i]->stats; - struct perf_stat_aggr *aggr; char *n; double val; =20 @@ -82,8 +81,7 @@ static int prepare_metric(struct perf_stat_config *config, } } /* Time events are always on CPU0, the first aggregation index. */ - aggr =3D &ps->aggr[is_tool_time ? tool_aggr_idx : aggr_idx]; - if (!aggr || !metric_events[i]->supported || aggr->counts.run =3D=3D 0) { + if (!ps || !metric_events[i]->supported) { /* * Not supported events will have a count of 0, which * can be confusing in a metric. Explicitly set the @@ -93,11 +91,21 @@ static int prepare_metric(struct perf_stat_config *conf= ig, val =3D NAN; source_count =3D 0; } else { - val =3D aggr->counts.val; - if (is_tool_time) - val *=3D 1e-9; /* Convert time event nanoseconds to seconds. */ - if (!source_count) - source_count =3D evsel__source_count(metric_events[i]); + struct perf_stat_aggr *aggr =3D + &ps->aggr[is_tool_time ? tool_aggr_idx : aggr_idx]; + + if (aggr->counts.run =3D=3D 0) { + val =3D NAN; + source_count =3D 0; + } else { + val =3D aggr->counts.val; + if (is_tool_time) { + /* Convert time event nanoseconds to seconds. */ + val *=3D 1e-9; + } + if (!source_count) + source_count =3D evsel__source_count(metric_events[i]); + } } n =3D strdup(evsel__metric_id(metric_events[i])); if (!n) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 69F61346772; Sat, 28 Feb 2026 17:33:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300021; cv=none; b=PZJPSJaYCSkEA5RPQeXJ33g4y+EiPu7pOvmtIvMzpg0BEriAUC3IEaquKx5oWdRw/UzD6I8dnF3OKvRUims797PA0/QjvRNcZJrBOkZo8l+ARJ+NozDQDB4Yg+iLnm9rZN9CcASAx85GO8nOV7+vWkneearCAlE3cIFmaE8Sbd8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300021; c=relaxed/simple; bh=zSBqITKXPk67SSan2baRsnOFT1Uv1ewpQLqTHOjYpk4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cVvPRyd1SNIKLLSAOgjAttznaAdzDSuuUk6NsjmQoYgLy/RK9wb4r/JRuO0hPNJ0ZK2EwYpOY1El4prPUHz/nlX1wh15/IXBWKKHaE5WWxPNISZqyOGKRRdfc6FmTO48zuxut39Af4IoTMLBoY7fPSK57kd6FGu1yaUtqofNi0I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uhh2TLTs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uhh2TLTs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B88FC19425; Sat, 28 Feb 2026 17:33:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300021; bh=zSBqITKXPk67SSan2baRsnOFT1Uv1ewpQLqTHOjYpk4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uhh2TLTsnR7VFm3Nh5o7FVT/TBaWBLX/AURn4V4EmL4IrNA80+cF3Y9TJQPgF4M7u hS59bPNI7alEU3FrZMemp4QsbJ45Jfg43oCeI/gCt30X5EnH3mFSpqoLMT/Zt06Ugm jEp4j5XFvsfrylR8HrkZUO86UIhtxrpdPigMudsLpfuupqFIWhfzCwNjWkKvT4YM9J mP5fXwah1rvRPLCAnzdzD1lMRJqexihi8N5y49HQ1dVvpi+VvDB22HytX+upR43yNz JVQq2RPk2OgFdv78ToOg2ikLyjHZVBk6dgzuOYE0SWqy5mEYvZx33kChaFCPl6YuVM K57wYj01JgwYQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Caleb Sander Mateos , Anuj Gupta , Kanchan Joshi , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 032/844] io_uring: add IORING_OP_URING_CMD128 to opcode checks Date: Sat, 28 Feb 2026 12:19:05 -0500 Message-ID: <20260228173244.1509663-33-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Caleb Sander Mateos [ Upstream commit 42a6bd57ee9f930a72c26f863c72f666d6ed9ea5 ] 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 Reviewed-by: Anuj Gupta Reviewed-by: Kanchan Joshi Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/io_uring.h | 6 ++++++ io_uring/kbuf.c | 2 +- io_uring/rw.c | 4 ++-- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/io_uring/io_uring.h b/io_uring/io_uring.h index a790c16854d32..0f096f44d34bf 100644 --- a/io_uring/io_uring.h +++ b/io_uring/io_uring.h @@ -595,6 +595,12 @@ static inline bool io_file_can_poll(struct io_kiocb *r= eq) return false; } =20 +static inline bool io_is_uring_cmd(const struct io_kiocb *req) +{ + return req->opcode =3D=3D IORING_OP_URING_CMD || + req->opcode =3D=3D IORING_OP_URING_CMD128; +} + static inline ktime_t io_get_time(struct io_ring_ctx *ctx) { if (ctx->clockid =3D=3D CLOCK_MONOTONIC) diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c index 67d4fe576473a..dae5b4ab3819c 100644 --- a/io_uring/kbuf.c +++ b/io_uring/kbuf.c @@ -171,7 +171,7 @@ static bool io_should_commit(struct io_kiocb *req, unsi= gned int issue_flags) return true; =20 /* uring_cmd commits kbuf upfront, no need to auto-commit */ - if (!io_file_can_poll(req) && req->opcode !=3D IORING_OP_URING_CMD) + if (!io_file_can_poll(req) && !io_is_uring_cmd(req)) return true; return false; } diff --git a/io_uring/rw.c b/io_uring/rw.c index 28555bc85ba0f..01367ac09531a 100644 --- a/io_uring/rw.c +++ b/io_uring/rw.c @@ -1253,7 +1253,7 @@ static int io_uring_classic_poll(struct io_kiocb *req= , struct io_comp_batch *iob { struct file *file =3D req->file; =20 - if (req->opcode =3D=3D IORING_OP_URING_CMD) { + if (io_is_uring_cmd(req)) { struct io_uring_cmd *ioucmd; =20 ioucmd =3D io_kiocb_to_cmd(req, struct io_uring_cmd); @@ -1376,7 +1376,7 @@ int io_do_iopoll(struct io_ring_ctx *ctx, bool force_= nonspin) break; nr_events++; req->cqe.flags =3D io_put_kbuf(req, req->cqe.res, NULL); - if (req->opcode !=3D IORING_OP_URING_CMD) + if (!io_is_uring_cmd(req)) io_req_rw_cleanup(req, 0); } if (unlikely(!nr_events)) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4747E33A6F2; Sat, 28 Feb 2026 17:33:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300022; cv=none; b=cOEiusZNRpv2oFpKVWPPV1RQZ77ihNYKJkoXNrDZyeuly8sH2pnUHBmEu2g/o9Qu4k9C4xVsh9/k6muuxxj7euS5G/lDlwp9j8ERlawBy+pTFZ6ISCQUW/O7N4zfdHFsc+Bn3/vJwkN0hkkISOUbIUyeQET48GNtQnGH4FVhXrk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300022; c=relaxed/simple; bh=D5N9c4KjXXhj07dBWuc9h4/fSwtFdozgTaLnNQb5bUY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ua9r40F77WgQyw6QVie/pxYXksdf+othg7BYrctFOLDlhsajs62cGi2xdHGktxeeEWPPyteOIZvh/6TQ95GKb3OwIQqTu8MiMQpuNAyuz8p5bHAsT6DCB5axJm2HXdpUw3/6yr6x8aewFw+khqwJ6M3neg5Q1AhQFXneyuWv+b4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kYE8Sprg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kYE8Sprg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 60C56C2BCAF; Sat, 28 Feb 2026 17:33:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300022; bh=D5N9c4KjXXhj07dBWuc9h4/fSwtFdozgTaLnNQb5bUY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kYE8SprgMBAmPuyCjP5w+5Do/G9xdFMLA6k55P4h4Tfq3vPoK1r9ziRAXoYN+YkUj A9EDfbUkQoYMGetSznLx3pLCBvczstvz7IZBdgfCwUwXAZyZWCMnyplmpNPf7izNxj HJn1TBLG7OJFAYdPTbDqcv58SebsGe3YUp3rgGNcWPIkOM4rZcNUc3vq0OIpux3fg0 1dqSMQKl8ER7S2aWAa7b88ykXWyEHTJIfC+x3SyavFgtRm3xsTNx24ETEm4+XVnQTt k2+JFo1wooMMJsMWs8eoeNksyloUiAS27dYwcK0DtTRQNS/kJshrH0cepWhJzYulkS JpknpZDtbjKbA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Anthony Pighin (Nokia)" , Esben Haabendal , Nick Bowler , Alexandre Belloni , Sasha Levin Subject: [PATCH 6.19 033/844] rtc: interface: Alarm race handling should not discard preceding error Date: Sat, 28 Feb 2026 12:19:06 -0500 Message-ID: <20260228173244.1509663-34-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Anthony Pighin (Nokia)" [ Upstream commit 81be22cd4ace020045cc6d31255c6f7c071eb7c0 ] Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") should not discard any errors from the preceding validations. Prior to that commit, if the alarm feature was disabled, or the set_alarm failed, a meaningful error code would be returned to the caller for further action. After, more often than not, the __rtc_read_time will cause a success return code instead, misleading the caller. An example of this is when timer_enqueue is called for a rtc-abx080x device. Since that driver does not clear the alarm feature bit, but instead relies on the set_alarm operation to return invalid, the discard of the return code causes very different behaviour; i.e. hwclock: select() to /dev/rtc0 to wait for clock tick timed out Fixes: 795cda8338ea ("rtc: interface: Fix long-standing race when setting a= larm") Signed-off-by: Anthony Pighin (Nokia) Reviewed-by: Esben Haabendal Tested-by: Nick Bowler Link: https://patch.msgid.link/BN0PR08MB6951415A751F236375A2945683D1A@BN0PR= 08MB6951.namprd08.prod.outlook.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/rtc/interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index b8b298efd9a9c..1906f4884a834 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -457,7 +457,7 @@ static int __rtc_set_alarm(struct rtc_device *rtc, stru= ct rtc_wkalrm *alarm) * are in, we can return -ETIME to signal that the timer has already * expired, which is true in both cases. */ - if ((scheduled - now) <=3D 1) { + if (!err && (scheduled - now) <=3D 1) { err =3D __rtc_read_time(rtc, &tm); if (err) return err; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 74DB747DFBA; Sat, 28 Feb 2026 17:33:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300023; cv=none; b=sDt1kHtA/TDwO4usZjU2zpEysjryXM3a37v8M+uYSVBgr/iikhiSSqbcjoHuklk2JhwV+sClVb1fomY0VxM6AnaE9F7AUEfnAbEnGDKwrkOr6vgHuTYyCkkwt7TTpyVYzn+sFEBebX9AUWLEkQdjymt+mR2XKWGkCuQiCrNaT4M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300023; c=relaxed/simple; bh=jm33/dDTMaejT8REIMFgGYTEkQhfYT6Fqs3geYv2D4I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=irr7/fq4IcEP0EDamajGxkjB2XCeMRMFjBD1LUZF3pKQt7F2edeGd6z47D7bHRbIQhTQMjIXJZEiGGe8CEw/PB2RXuGsRv1ffh3/5aTvA4VU6mNgwncIkHr0qWjSFtqQruH/5sakl1Rxf1Y3ue2y+8HNTbGgluS5atjDtBsAcHc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qoiJQxLt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qoiJQxLt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67D35C19425; Sat, 28 Feb 2026 17:33:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300023; bh=jm33/dDTMaejT8REIMFgGYTEkQhfYT6Fqs3geYv2D4I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qoiJQxLtJ4U3IeRjUoDxAmq99jaBThWRxiZhA20kYyGozzMNccqPSQyPa2yfj26CK IyuafeeSH5bFfP8McN3DegCyeFrybxddgmiE739CcTxEVCyscZuuV+OlGMPYyAD8K/ KGNO3aq23Rc6/3OgZna41kyOWVI/hjpZ5UzYR9E2WVE+JpHu3TnSpu6yT3Xx3WISYz 503gnpYO0cFNno5AqcdlywgLVYnpVerJK49W97OX7uSZ82MTateSdnka4ctO281AfO BfQu5VJL2tkkPkzDM9rL5Pid67tMmF2FREb2GNXbvKHZRwXfiQjK09oy/kWl1xu2RC D8IO7tBsh2/Wg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bhavik Sachdev , Miklos Szeredi , Christian Brauner , Sasha Levin Subject: [PATCH 6.19 034/844] statmount: permission check should return EPERM Date: Sat, 28 Feb 2026 12:19:07 -0500 Message-ID: <20260228173244.1509663-35-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bhavik Sachdev [ Upstream commit fccbe38a5d06dbe44bcd89196fe1d2c2272a1f4a ] Currently, statmount() returns ENOENT when caller is not CAP_SYS_ADMIN in the user namespace owner of target mount namespace. This should be EPERM instead. Suggested-by: Miklos Szeredi Signed-off-by: Bhavik Sachdev Link: https://patch.msgid.link/20251129091455.757724-2-b.sachdev1904@gmail.= com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index c58674a20cad5..f6879f282daec 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -5780,7 +5780,7 @@ SYSCALL_DEFINE4(statmount, const struct mnt_id_req __= user *, req, =20 if (kreq.mnt_ns_id && (ns !=3D current->nsproxy->mnt_ns) && !ns_capable_noaudit(ns->user_ns, CAP_SYS_ADMIN)) - return -ENOENT; + return -EPERM; =20 ks =3D kmalloc(sizeof(*ks), GFP_KERNEL_ACCOUNT); if (!ks) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F33747DF99; Sat, 28 Feb 2026 17:33:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300024; cv=none; b=KrsLQm6EkZFYJrgqz+gaEv15Q67mO3dsEgLE4qgiNuLtrzCECzk4RV3zMRYXdAG2mjTtIvnVMFnzFoGlKYEr0qhg2edHQLBn03CO8fOexn2Hbnt0CXrX1it9CRl+AGhdHAxMW7K/9uCk8zEeR+uEF3KT9E2rtcR0rPEz8sQCu30= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300024; c=relaxed/simple; bh=n8iukbmTfV+CBCIYw3iJyumSdlOa0DLhcpDjgW67Edc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=atnQB2ejTyBWg2fU+etrZwM5ktk5XwfSz1jK7g7hXKOAQYi2bJ/VZQYb6ie9kT+GzTRcdxJx9hQ82oNVmdL+bMQL5K9H4ztORQSQGn0StEj4G0nXKoJJ8cihcVhZ1u43MVKabzERYc1t/bFvPRUHupToZ7FxXL+4oR16E8CQdzs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=W6IeBY3r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="W6IeBY3r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E6FDC2BC9E; Sat, 28 Feb 2026 17:33:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300024; bh=n8iukbmTfV+CBCIYw3iJyumSdlOa0DLhcpDjgW67Edc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W6IeBY3rww+Mml4/ENkMM2urCelASPHAg54BETKWsD33yIKJbKqJYufNjrOxTnYbz t2iP0VQEJ7WPs6DYnYejAq/t+ORjfVS5ZOZrLZFtxyxbnsCW4mjrPrOhdzD5oOQJGU txynZUtGGMRrODHKuHK7Hh4mQXRv0OuCWDEX1oyIB6bn9Y03LhuyYItDg/iXnkvp4n /D1cORyK9HJxIjuihSIChqlVaIPFtS6KhDN6N+8QA2NdQ4XMTl8PcinqIaGmvGQ8vD UUuo3+LhISoDdOtLY3hy6Gnbiq8CEe9Ch59A5PGAYWIHC07t3lzDjoppv5UjC/EMZy SqLjLAqILZyXg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Viacheslav Dubeyko , John Paul Adrian Glaubitz , Yangtao Li , linux-fsdevel@vger.kernel.org, Sasha Levin Subject: [PATCH 6.19 035/844] hfsplus: fix volume corruption issue for generic/480 Date: Sat, 28 Feb 2026 12:19:08 -0500 Message-ID: <20260228173244.1509663-36-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Viacheslav Dubeyko [ Upstream commit bea4429eb30190c59b5ac7c8ff6c90176c7c110f ] The xfstests' test-case generic/480 leaves HFS+ volume in corrupted state: sudo ./check generic/480 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.17.0-rc1+ #4 SMP PREEMPT_DY= NAMIC Wed Oct 1 15:02:44 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/480 _check_generic_filesystem: filesystem on /dev/loop51 is inconsi= stent (see XFSTESTS-2/xfstests-dev/results//generic/480.full for details) Ran: generic/480 Failures: generic/480 Failed 1 of 1 tests sudo fsck.hfsplus -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=3D32K cacheTotalBlock=3D1024 cacheSize=3D32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. Incorrect number of file hard links ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. invalid VHB nextCatalogID Volume header needs minor repair (2, 0) Verify Status: VIStat =3D 0x8000, ABTStat =3D 0x0000 EBTStat =3D 0x0000 CBTStat =3D 0x0000 CatStat =3D 0x00000002 ** Repairing volume. Incorrect flags for file hard link (id =3D 19) (It should be 0x22 instead of 0x2) Incorrect flags for file inode (id =3D 18) (It should be 0x22 instead of 0x2) first link ID=3D0 is < 16 for fileinode=3D18 Error getting first link ID for inode =3D 18 (result=3D2) Invalid first link in hard link chain (id =3D 18) (It should be 19 instead of 0) Indirect node 18 needs link count adjustment (It should be 1 instead of 2) ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The generic/480 test executes such steps on final phase: "Now remove of the links of our file and create a new file with the same name and in the same parent directory, and finally fsync this new file." unlink $SCRATCH_MNT/testdir/bar touch $SCRATCH_MNT/testdir/bar $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir/bar "Simulate a power failure and mount the filesystem to check that replaying the fsync log/journal succeeds, that is the mount operation does not fail." _flakey_drop_and_remount The key issue in HFS+ logic is that hfsplus_link(), hfsplus_unlink(), hfsplus_rmdir(), hfsplus_symlink(), and hfsplus_mknod() methods don't call hfsplus_cat_write_inode() for the case of modified inode objects. As a result, even if hfsplus_file_fsync() is trying to flush the dirty Catalog File, but because of not calling hfsplus_cat_write_inode() not all modified inodes save the new state into Catalog File's records. Finally, simulation of power failure results in inconsistent state of Catalog File and FSCK tool reports about volume corruption. This patch adds calling of hfsplus_cat_write_inode() method for modified inodes in hfsplus_link(), hfsplus_unlink(), hfsplus_rmdir(), hfsplus_symlink(), and hfsplus_mknod() methods. Also, it adds debug output in several methods. sudo ./check generic/480 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #18 SMP PREE= MPT_DYNAMIC Thu Dec 4 12:24:45 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/480 16s ... 16s Ran: generic/480 Passed all 1 tests Signed-off-by: Viacheslav Dubeyko cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20251205000054.3670326-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/hfsplus/dir.c | 46 +++++++++++++++++++++++++++++++++++++++++++++- fs/hfsplus/inode.c | 5 +++++ 2 files changed, 50 insertions(+), 1 deletion(-) diff --git a/fs/hfsplus/dir.c b/fs/hfsplus/dir.c index cadf0b5f93422..ca5f74a140ec1 100644 --- a/fs/hfsplus/dir.c +++ b/fs/hfsplus/dir.c @@ -313,6 +313,9 @@ static int hfsplus_link(struct dentry *src_dentry, stru= ct inode *dst_dir, if (!S_ISREG(inode->i_mode)) return -EPERM; =20 + hfs_dbg("src_dir->i_ino %lu, dst_dir->i_ino %lu, inode->i_ino %lu\n", + src_dir->i_ino, dst_dir->i_ino, inode->i_ino); + mutex_lock(&sbi->vh_mutex); if (inode->i_ino =3D=3D (u32)(unsigned long)src_dentry->d_fsdata) { for (;;) { @@ -332,7 +335,7 @@ static int hfsplus_link(struct dentry *src_dentry, stru= ct inode *dst_dir, cnid =3D sbi->next_cnid++; src_dentry->d_fsdata =3D (void *)(unsigned long)cnid; res =3D hfsplus_create_cat(cnid, src_dir, - &src_dentry->d_name, inode); + &src_dentry->d_name, inode); if (res) /* panic? */ goto out; @@ -350,6 +353,21 @@ static int hfsplus_link(struct dentry *src_dentry, str= uct inode *dst_dir, mark_inode_dirty(inode); sbi->file_count++; hfsplus_mark_mdb_dirty(dst_dir->i_sb); + + res =3D hfsplus_cat_write_inode(src_dir); + if (res) + goto out; + + res =3D hfsplus_cat_write_inode(dst_dir); + if (res) + goto out; + + res =3D hfsplus_cat_write_inode(sbi->hidden_dir); + if (res) + goto out; + + res =3D hfsplus_cat_write_inode(inode); + out: mutex_unlock(&sbi->vh_mutex); return res; @@ -367,6 +385,9 @@ static int hfsplus_unlink(struct inode *dir, struct den= try *dentry) if (HFSPLUS_IS_RSRC(inode)) return -EPERM; =20 + hfs_dbg("dir->i_ino %lu, inode->i_ino %lu\n", + dir->i_ino, inode->i_ino); + mutex_lock(&sbi->vh_mutex); cnid =3D (u32)(unsigned long)dentry->d_fsdata; if (inode->i_ino =3D=3D cnid && @@ -408,6 +429,15 @@ static int hfsplus_unlink(struct inode *dir, struct de= ntry *dentry) inode_set_ctime_current(inode); mark_inode_dirty(inode); out: + if (!res) { + res =3D hfsplus_cat_write_inode(dir); + if (!res) { + res =3D hfsplus_cat_write_inode(sbi->hidden_dir); + if (!res) + res =3D hfsplus_cat_write_inode(inode); + } + } + mutex_unlock(&sbi->vh_mutex); return res; } @@ -429,6 +459,8 @@ static int hfsplus_rmdir(struct inode *dir, struct dent= ry *dentry) inode_set_ctime_current(inode); hfsplus_delete_inode(inode); mark_inode_dirty(inode); + + res =3D hfsplus_cat_write_inode(dir); out: mutex_unlock(&sbi->vh_mutex); return res; @@ -465,6 +497,12 @@ static int hfsplus_symlink(struct mnt_idmap *idmap, st= ruct inode *dir, =20 hfsplus_instantiate(dentry, inode, inode->i_ino); mark_inode_dirty(inode); + + res =3D hfsplus_cat_write_inode(dir); + if (res) + goto out; + + res =3D hfsplus_cat_write_inode(inode); goto out; =20 out_err: @@ -506,6 +544,12 @@ static int hfsplus_mknod(struct mnt_idmap *idmap, stru= ct inode *dir, =20 hfsplus_instantiate(dentry, inode, inode->i_ino); mark_inode_dirty(inode); + + res =3D hfsplus_cat_write_inode(dir); + if (res) + goto out; + + res =3D hfsplus_cat_write_inode(inode); goto out; =20 failed_mknod: diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c index 7ae6745ca7ae1..c762bf909d1aa 100644 --- a/fs/hfsplus/inode.c +++ b/fs/hfsplus/inode.c @@ -328,6 +328,9 @@ int hfsplus_file_fsync(struct file *file, loff_t start,= loff_t end, struct hfsplus_vh *vhdr =3D sbi->s_vhdr; int error =3D 0, error2; =20 + hfs_dbg("inode->i_ino %lu, start %llu, end %llu\n", + inode->i_ino, start, end); + error =3D file_write_and_wait_range(file, start, end); if (error) return error; @@ -616,6 +619,8 @@ int hfsplus_cat_write_inode(struct inode *inode) hfsplus_cat_entry entry; int res =3D 0; =20 + hfs_dbg("inode->i_ino %lu\n", inode->i_ino); + if (HFSPLUS_IS_RSRC(inode)) main_inode =3D HFSPLUS_I(inode)->rsrc_inode; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E6EF47ECE8; Sat, 28 Feb 2026 17:33:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300025; cv=none; b=guQ+5xGvn8n8TvLfYbNO5RKyQzwxTRc4xc4GY7SGRv+1i8+7G5JKdJ8+QUa7fJEh/uMEDjDMhUYjWFrKeSe7vsvfl05VHB/iwYnsqTMJrEY7ezlRkAOUtPaqqnzWWU6EoaCqgjruO28SncNbu0sil3exTYs1WiGqOYHfBlIoUgo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300025; c=relaxed/simple; bh=EY/BGeOOCFFP9d7pnNT8svYATTIHoqhTE4sX02nGVNg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Oyu4PnxBROBLP6MmGFFV9MBhJ2KkSllPEU7KY9QOqKjcVQhLasCnl1GUk9aJgBBsmy2JPQllUqHRfm78wroZ+IX8cRKHR2YQF2Mi9D4Blgq/Za3crTqGuw6UTT8QmiGI9GS6V6KHAm7TSRfNwI9yBCc/xNugeOoAkXZRALrRQE0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GBUOH1uu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GBUOH1uu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65CBDC116D0; Sat, 28 Feb 2026 17:33:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300025; bh=EY/BGeOOCFFP9d7pnNT8svYATTIHoqhTE4sX02nGVNg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GBUOH1uuu+sPK48Wl9xyQZeNy2ZZNi0ImLz/6KZsavTrqMvDqpoBDjx8yzhLKVLl5 rhRea2BzEmFIwxA1zGeJ7ekntL7LVGueAuLvsIp+85g5TVMjbL6Vl9iumhKGMF9t9h SkqVb/lJpTKqVibWfm2hjjpNdfuiKtO2zjjmtFGrsydpu8LAqdU9xN3pjHJ5zMuyKN uvI/MYSehn65TiJvxbeQxbiIQxbBbPdPZeLmEny8kXsMB+r1pOdiUq8iddPAMOWCXn 8z0wcjN1gcuKYjhzE3QSgEtMhdfVgPP7sQN2t9EpCewB5kll9ttIhR0dzdiSvyZ60U 2QY08bPOIs8UA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jeffrey Bencteux , Paul Moore , Sasha Levin Subject: [PATCH 6.19 036/844] audit: add fchmodat2() to change attributes class Date: Sat, 28 Feb 2026 12:19:09 -0500 Message-ID: <20260228173244.1509663-37-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jeffrey Bencteux [ Upstream commit 4f493a6079b588cf1f04ce5ed6cdad45ab0d53dc ] fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class. Signed-off-by: Jeffrey Bencteux Signed-off-by: Paul Moore Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/asm-generic/audit_change_attr.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/asm-generic/audit_change_attr.h b/include/asm-generic/= audit_change_attr.h index cc840537885fb..ddd90bbe40dfc 100644 --- a/include/asm-generic/audit_change_attr.h +++ b/include/asm-generic/audit_change_attr.h @@ -26,6 +26,9 @@ __NR_fremovexattr, __NR_fchownat, __NR_fchmodat, #endif +#ifdef __NR_fchmodat2 +__NR_fchmodat2, +#endif #ifdef __NR_chown32 __NR_chown32, __NR_fchown32, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24BEF47ECFE; Sat, 28 Feb 2026 17:33:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300026; cv=none; b=Qa29c9WnPVkXoEcwHcTNGDJ8pJJx8lGTbWjCHIWdKpo4Ip7LrfCViR7nQO78ADcWsHwe5LdXqc1oE9RAnc3yxEYN6KuJcyjF9zyuil5T1sVBpkCZ15TtFmA37VchEPLqhWHP8AbR5XcWFLA2WMyr7vGc0ywubHuUxPzqgub36rg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300026; c=relaxed/simple; bh=lgckruRzCqInsR1TwxzrE/g9fFUJVXK1HokDjmRbsYk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p24EV/HIJqt1MGGIRP3r6dg+9FDqbUYyK2kE/Lq9rwpR7/T9efKDRUtxwmNooiot4Bms0mP/tcZ43JqVYsXucQkh+MQxKfWYq0y5UTVHqovUgyQZ7z2DthjAAuqMTA3QmUjze/IjdwSt9JO3moV8lWrzEsMpvXJA197vfwnTJgY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PTSDz73A; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PTSDz73A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 461D9C19425; Sat, 28 Feb 2026 17:33:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300026; bh=lgckruRzCqInsR1TwxzrE/g9fFUJVXK1HokDjmRbsYk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PTSDz73A83ptiKoY65VZpn3rSCu6ix3f44K9goywMJBjvUAgzpKe0dzuTmaTfqsWB bks+5RtZo5mUkMrppCLWkYFv7Lz5Shjv6Ww2773qbRIdQtFKkhhTUqHPlOucgaDPsQ BCwJljQJMEstnE4HzwDkh9oFpdYyQXHwjpSbBLBK3QjsCjbyxmKxSc/v+mBI+3K/yN 1R+l5YGwp2KRlmTDnhGsMC9kP0MhOnAtLGrMq4YRqv1qfxLPpyl0ODL+WzUbJE4Ezb U5emMNZY+Iml0dnWfcip0stZJRQq9dUnC2H/a8EvW0b/YNc6OjmNF1gPOTwOUnbQBK 55+I8iFVghSxQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Viacheslav Dubeyko , John Paul Adrian Glaubitz , Yangtao Li , linux-fsdevel@vger.kernel.org, Sasha Levin Subject: [PATCH 6.19 037/844] hfsplus: fix volume corruption issue for generic/498 Date: Sat, 28 Feb 2026 12:19:10 -0500 Message-ID: <20260228173244.1509663-38-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Viacheslav Dubeyko [ Upstream commit 9a8c4ad44721da4c48e1ff240ac76286c82837fe ] The xfstests' test-case generic/498 leaves HFS+ volume in corrupted state: sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #18 SMP PREEMPT_D= YNAMIC Thu Dec 4 12:24:45 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 _check_generic_filesystem: filesystem on /dev/loop51 is inconsi= stent (see XFSTESTS-2/xfstests-dev/results//generic/498.full for details) Ran: generic/498 Failures: generic/498 Failed 1 of 1 tests sudo fsck.hfsplus -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=3D32K cacheTotalBlock=3D1024 cacheSize=3D32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. Invalid leaf record count (It should be 16 instead of 2) ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. Verify Status: VIStat =3D 0x0000, ABTStat =3D 0x0000 EBTStat =3D 0x0000 CBTStat =3D 0x8000 CatStat =3D 0x00000000 ** Repairing volume. ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The generic/498 test executes such steps on final phase: mkdir $SCRATCH_MNT/A mkdir $SCRATCH_MNT/B mkdir $SCRATCH_MNT/A/C touch $SCRATCH_MNT/B/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/B/foo ln $SCRATCH_MNT/B/foo $SCRATCH_MNT/A/C/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/A "Simulate a power failure and mount the filesystem to check that what we explicitly fsync'ed exists." _flakey_drop_and_remount The FSCK tool complains about "Invalid leaf record count". HFS+ b-tree header contains leaf_count field is updated by hfs_brec_insert() and hfs_brec_remove(). The hfs_brec_insert() is involved into hard link creation process. However, modified in-core leaf_count field is stored into HFS+ b-tree header by hfs_btree_write() method. But, unfortunately, hfs_btree_write() hasn't been called by hfsplus_cat_write_inode() and hfsplus_file_fsync() stores not fully consistent state of the Catalog File's b-tree. This patch adds calling hfs_btree_write() method in the hfsplus_cat_write_inode() with the goal of storing consistent state of Catalog File's b-tree. Finally, it makes FSCK tool happy. sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #22 SMP PREE= MPT_DYNAMIC Sat Dec 6 17:01:31 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 33s ... 31s Ran: generic/498 Passed all 1 tests Signed-off-by: Viacheslav Dubeyko cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20251207035821.3863657-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/hfsplus/inode.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c index c762bf909d1aa..6153e5cc6eb65 100644 --- a/fs/hfsplus/inode.c +++ b/fs/hfsplus/inode.c @@ -615,6 +615,7 @@ int hfsplus_cat_read_inode(struct inode *inode, struct = hfs_find_data *fd) int hfsplus_cat_write_inode(struct inode *inode) { struct inode *main_inode =3D inode; + struct hfs_btree *tree =3D HFSPLUS_SB(inode->i_sb)->cat_tree; struct hfs_find_data fd; hfsplus_cat_entry entry; int res =3D 0; @@ -627,7 +628,7 @@ int hfsplus_cat_write_inode(struct inode *inode) if (!main_inode->i_nlink) return 0; =20 - if (hfs_find_init(HFSPLUS_SB(main_inode->i_sb)->cat_tree, &fd)) + if (hfs_find_init(tree, &fd)) /* panic? */ return -EIO; =20 @@ -692,6 +693,15 @@ int hfsplus_cat_write_inode(struct inode *inode) set_bit(HFSPLUS_I_CAT_DIRTY, &HFSPLUS_I(inode)->flags); out: hfs_find_exit(&fd); + + if (!res) { + res =3D hfs_btree_write(tree); + if (res) { + pr_err("b-tree write err: %d, ino %lu\n", + res, inode->i_ino); + } + } + return res; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 168A947F2DD; Sat, 28 Feb 2026 17:33:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300027; cv=none; b=ZqPr5+VO8OQ63KnThwhIF/CEGEkCulQjl1jRzxzgsDn3U3pN2t/4/945ZHZr6X9uoM5Tx2ltCb1nJQAq6W+o3xVlfT+r83nSZzxexjH4Xki7iQn37gO7eIfWJ4DhwF25NVhbBu4RwfDszz9jKT3eIxQEX/edfq53Ogs6hZQ2KSk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300027; c=relaxed/simple; bh=L7r/ZydBdbS3/Kljjcw3TA4m/2thEk7br8YIHdiykkw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FHSh4TOcgEgfGu7/ZwvwjbHDCTT0BKpV0MICqtGPHolds7Ph0zaJwZqZYRMt0g1zSlBo6lvLnh0+n6b7fv2CsJyL5KmhZdm3395wxhZD1D+aqdvGx2Uv2ZGtxvTYHmiRMV5Hu+wqLnow9KJCAiXTMqLBPSEnIW22z1XK9RLiaeI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=joOAxSd+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="joOAxSd+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BF67C19425; Sat, 28 Feb 2026 17:33:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300027; bh=L7r/ZydBdbS3/Kljjcw3TA4m/2thEk7br8YIHdiykkw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=joOAxSd+18RFQNMSpiu+tFsoWGkhYTlr9c1QilVdhK1oI5L7ECnP7lwvVaM1YXtPV Yo6hx2wRJKm7Ly8iMfmg2Nt5XcRsJEZjSyk/0wLqAMFASBDrAkDPhg48+85H/M5OSh lZWJuF4t/TcIetS83mnQJVczu/7yZhMuVCa9Djk+XxgNYMYSyfUXW7F5T2tH1fGESf thszKNLKNbs3JRZ+0pDEHr4bOZAi1/jHITn1fXb3CJgFzqYHb7latt18cnXM5I/kwR AojUe6kXfL7f+uqYcSIh24ZvjMMomCrDeEV7zfN5fd+Oeu3RLnk5JdMhMfOhmPTW2R swsi5anE/nnWg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Deepakkumar Karn , Jan Kara , Christian Brauner , Sasha Levin Subject: [PATCH 6.19 038/844] fs/buffer: add alert in try_to_free_buffers() for folios without buffers Date: Sat, 28 Feb 2026 12:19:11 -0500 Message-ID: <20260228173244.1509663-39-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Deepakkumar Karn [ Upstream commit b68f91ef3b3fe82ad78c417de71b675699a8467c ] try_to_free_buffers() can be called on folios with no buffers attached when filemap_release_folio() is invoked on a folio belonging to a mapping with AS_RELEASE_ALWAYS set but no release_folio operation defined. In such cases, folio_needs_release() returns true because of the AS_RELEASE_ALWAYS flag, but the folio has no private buffer data. This causes try_to_free_buffers() to call drop_buffers() on a folio with no buffers, leading to a null pointer dereference. Adding a check in try_to_free_buffers() to return early if the folio has no buffers attached, with WARN_ON_ONCE() to alert about the misconfiguration. This provides defensive hardening. Signed-off-by: Deepakkumar Karn Link: https://patch.msgid.link/20251211131211.308021-1-dkarn@redhat.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/buffer.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/buffer.c b/fs/buffer.c index 838c0c5710229..28e4d53f17173 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -2948,6 +2948,10 @@ bool try_to_free_buffers(struct folio *folio) if (folio_test_writeback(folio)) return false; =20 + /* Misconfigured folio check */ + if (WARN_ON_ONCE(!folio_buffers(folio))) + return true; + if (mapping =3D=3D NULL) { /* can this still happen? */ ret =3D drop_buffers(folio, &buffers_to_free); goto out; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0DCC233A9D1; Sat, 28 Feb 2026 17:33:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300028; cv=none; b=G0DFRerakwKgrVD4IaJGkjqjoZcqoonVQC3X+Chd3dHO5oQXU1KkHzPjCC+nZtFtJhHb0epu72TdqW1daLI+dDS9qVBbR/VhiTsSSHTS4NP7zlyry+6cPx65FBlFNXOgpF73psUJH2jdxpMUQ/XzCIR4m5+tuo6PGe6/5WJ0i2M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300028; c=relaxed/simple; bh=OuM3R714gkSYXJVa0MHO55s0U6lgQYUyrnpXyQvuiPc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LVHxdu4WN3oWS3Cr/BKbHJnUu6GlSDKxdPbRPdiXEA+9O09AkjC9G41coW/mnGExCC+8uGp9ZgpkDgKafjD/rWR1OEQG8FtgzVYXgQd8yyUu+mnTt5/JL418EbNxAltWK0l0laMgc6KUAaTOPR70hZ0WRXU/rvU1rvn11Vhn9Mw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lUkIuBlh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lUkIuBlh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41525C19423; Sat, 28 Feb 2026 17:33:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300027; bh=OuM3R714gkSYXJVa0MHO55s0U6lgQYUyrnpXyQvuiPc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lUkIuBlhp0Mzxet/p4bMXjAfkqVwqPx9S9f2c+NYI4p1doDuxaHTwlw5mqc7f6/oD jIyfKoS8kE0ASgejnx7yQXhnne8ECU1sj5EMfhXZhyprAAfk1TwpLPmOiqFt4pRTea JcVyJjSkZrxjyeJ0qdeaATXAvOCTgDVhj+x1Nkh0VtQWDnEIFt74gCkuc3whPoWr0J zfKfcxLuntLiXz9CYwRUgbSv80c2mbYQXTKrYLYB4NJbjBvQx5BlVet9ZMJjq0kOjI Pz10RisqBHKljcMDYSDtjt+trgQtLZJ89RZxCqj81mOJz1ExRQieA6HLVN4Y+OiTjF esgRhwqO8gWyA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Clint George , Ming Lei , Shuah Khan , Sasha Levin Subject: [PATCH 6.19 039/844] kselftest/kublk: include message in _Static_assert for C11 compatibility Date: Sat, 28 Feb 2026 12:19:12 -0500 Message-ID: <20260228173244.1509663-40-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Clint George [ Upstream commit 3e6ad272bb8b3199bad952e7b077102af2d8df03 ] Add descriptive message in the _Static_assert to comply with the C11 standard requirement to prevent compiler from throwing out error. The compiler throws an error when _Static_assert is used without a message as that is a C23 extension. [] Testing: The diff between before and after of running the kselftest test of the module shows no regression on system with x86 architecture [] Error log: ~/Desktop/kernel-dev/linux-v1/tools/testing/selftests/ublk$ make LLVM=3D1 W= =3D1 CC kublk In file included from kublk.c:6: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extensio= n [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <=3D 7); | ^ | , "" 1 error generated. In file included from null.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extensio= n [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <=3D 7); | ^ | , "" 1 error generated. In file included from file_backed.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extensio= n [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <=3D 7); | ^ | , "" 1 error generated. In file included from common.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extensio= n [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <=3D 7); | ^ | , "" 1 error generated. In file included from stripe.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extensio= n [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <=3D 7); | ^ | , "" 1 error generated. In file included from fault_inject.c:11: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extensio= n [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <=3D 7); | ^ | , "" 1 error generated. make: *** [../lib.mk:225: ~/Desktop/kernel-dev/linux-v1/tools/testing/selft= ests/ublk/kublk] Error 1 Link: https://lore.kernel.org/r/20251215085022.7642-1-clintbgeorge@gmail.com Signed-off-by: Clint George Reviewed-by: Ming Lei Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/testing/selftests/ublk/kublk.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/ublk/kublk.h b/tools/testing/selftests= /ublk/kublk.h index 8a83b90ec603a..cae2e30f0cdd5 100644 --- a/tools/testing/selftests/ublk/kublk.h +++ b/tools/testing/selftests/ublk/kublk.h @@ -223,7 +223,7 @@ static inline __u64 build_user_data(unsigned tag, unsig= ned op, unsigned tgt_data, unsigned q_id, unsigned is_target_io) { /* we only have 7 bits to encode q_id */ - _Static_assert(UBLK_MAX_QUEUES_SHIFT <=3D 7); + _Static_assert(UBLK_MAX_QUEUES_SHIFT <=3D 7, "UBLK_MAX_QUEUES_SHIFT must = be <=3D 7"); assert(!(tag >> 16) && !(op >> 8) && !(tgt_data >> 16) && !(q_id >> 7)); =20 return tag | (op << 16) | (tgt_data << 24) | --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 093DB480336; Sat, 28 Feb 2026 17:33:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300029; cv=none; b=NrlwuTNm2fvzEz6R6DuqFxUDYrD2fxpBND+G5PRcckzuzufWu7VeFPKCwMmIvDpqGjc8yP6clpBwFJMaskdwB8zVa4wG9jxPxLlnI0cJoc6OabizZx5w+/so8SDBEIJTcSeWlOtyRYLvW82bSwRBCT+cH7sCxpMFRBP41cDrwbs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300029; c=relaxed/simple; bh=k1eVPDFyak+bkrd/W+y8JFeWv2XzHiOhynm/OIhazF4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KrobaGjNT6rZtfwIPiaJg/9bv3c6QDadhcflS3UZOFlak4Ru9bIIz1NJqk+1LUPwZe1NKdT4OaeV8M39ccrXxMRFoHlFLly6XyryPIlpa0km7H43wEx3P5rQsy7ZqS8qVfslUcz/EJ36OZSZ9jXNTLEjymPb6nGD1SUyQSH9Zts= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ff1IEegK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ff1IEegK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39C5BC2BC9E; Sat, 28 Feb 2026 17:33:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300028; bh=k1eVPDFyak+bkrd/W+y8JFeWv2XzHiOhynm/OIhazF4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ff1IEegKK1nwye8IntdaeAlOlWQOwLGAKItGTQN+Rm+dlcocGyy4m2Fr3JosvKYi9 1L/9USaIzstKcc6dOX/HWNawSfIJKlT8GYY1Lm0Ky3q7a7MJBXxx4CAzDTrCzKaq1L 2yX7adp7jALOVApakiyf2c8GJTh124Vwr97EL32rz7Go3FRJXLQnUEgEaLm+YUbzls /krGedmA+dXZ0nEX3gwbPwo7XRpW8jL9XNwa7I2Y1BWwY8Z6XVKzt2Uskivb2rsVn8 Wk1xnxT+lghBYItr8kvDKX+Dw3Rn3kZzBnXpRbugDTtY4/imk1BHCQQpvrr2fsAral HtResEqLIBqPA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jori Koolstra , syzbot+17cc9bb6d8d69b4139f0@syzkaller.appspotmail.com, Viacheslav Dubeyko , Sasha Levin Subject: [PATCH 6.19 040/844] hfs: Replace BUG_ON with error handling for CNID count checks Date: Sat, 28 Feb 2026 12:19:13 -0500 Message-ID: <20260228173244.1509663-41-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jori Koolstra [ Upstream commit b226804532a875c10276168dc55ce752944096bd ] In a06ec283e125 next_id, folder_count, and file_count in the super block info were expanded to 64 bits, and BUG_ONs were added to detect overflow. This triggered an error reported by syzbot: if the MDB is corrupted, the BUG_ON is triggered. This patch replaces this mechanism with proper error handling and resolves the syzbot reported bug. Singed-off-by: Jori Koolstra Reported-by: syzbot+17cc9bb6d8d69b4139f0@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=3D17cc9bb6d8d69b4139f0 Signed-off-by: Jori Koolstra Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20251220191006.2465256-1-jkoolstra@xs4all.nl Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/hfs/dir.c | 15 +++++++++++---- fs/hfs/hfs_fs.h | 1 + fs/hfs/inode.c | 30 ++++++++++++++++++++++++------ fs/hfs/mdb.c | 31 +++++++++++++++++++++++++++---- fs/hfs/super.c | 3 +++ 5 files changed, 66 insertions(+), 14 deletions(-) diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c index 86a6b317b474a..0c615c078650c 100644 --- a/fs/hfs/dir.c +++ b/fs/hfs/dir.c @@ -196,8 +196,8 @@ static int hfs_create(struct mnt_idmap *idmap, struct i= node *dir, int res; =20 inode =3D hfs_new_inode(dir, &dentry->d_name, mode); - if (!inode) - return -ENOMEM; + if (IS_ERR(inode)) + return PTR_ERR(inode); =20 res =3D hfs_cat_create(inode->i_ino, dir, &dentry->d_name, inode); if (res) { @@ -226,8 +226,8 @@ static struct dentry *hfs_mkdir(struct mnt_idmap *idmap= , struct inode *dir, int res; =20 inode =3D hfs_new_inode(dir, &dentry->d_name, S_IFDIR | mode); - if (!inode) - return ERR_PTR(-ENOMEM); + if (IS_ERR(inode)) + return ERR_CAST(inode); =20 res =3D hfs_cat_create(inode->i_ino, dir, &dentry->d_name, inode); if (res) { @@ -254,11 +254,18 @@ static struct dentry *hfs_mkdir(struct mnt_idmap *idm= ap, struct inode *dir, */ static int hfs_remove(struct inode *dir, struct dentry *dentry) { + struct super_block *sb =3D dir->i_sb; struct inode *inode =3D d_inode(dentry); int res; =20 if (S_ISDIR(inode->i_mode) && inode->i_size !=3D 2) return -ENOTEMPTY; + + if (unlikely(!is_hfs_cnid_counts_valid(sb))) { + pr_err("cannot remove file/folder\n"); + return -ERANGE; + } + res =3D hfs_cat_delete(inode->i_ino, dir, &dentry->d_name); if (res) return res; diff --git a/fs/hfs/hfs_fs.h b/fs/hfs/hfs_fs.h index e94dbc04a1e43..ac0e83f77a0f1 100644 --- a/fs/hfs/hfs_fs.h +++ b/fs/hfs/hfs_fs.h @@ -199,6 +199,7 @@ extern void hfs_delete_inode(struct inode *inode); extern const struct xattr_handler * const hfs_xattr_handlers[]; =20 /* mdb.c */ +extern bool is_hfs_cnid_counts_valid(struct super_block *sb); extern int hfs_mdb_get(struct super_block *sb); extern void hfs_mdb_commit(struct super_block *sb); extern void hfs_mdb_close(struct super_block *sb); diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c index 524db1389737d..878535db64d67 100644 --- a/fs/hfs/inode.c +++ b/fs/hfs/inode.c @@ -187,16 +187,23 @@ struct inode *hfs_new_inode(struct inode *dir, const = struct qstr *name, umode_t s64 next_id; s64 file_count; s64 folder_count; + int err =3D -ENOMEM; =20 if (!inode) - return NULL; + goto out_err; + + err =3D -ERANGE; =20 mutex_init(&HFS_I(inode)->extents_lock); INIT_LIST_HEAD(&HFS_I(inode)->open_dir_list); spin_lock_init(&HFS_I(inode)->open_dir_lock); hfs_cat_build_key(sb, (btree_key *)&HFS_I(inode)->cat_key, dir->i_ino, na= me); next_id =3D atomic64_inc_return(&HFS_SB(sb)->next_id); - BUG_ON(next_id > U32_MAX); + if (next_id > U32_MAX) { + atomic64_dec(&HFS_SB(sb)->next_id); + pr_err("cannot create new inode: next CNID exceeds limit\n"); + goto out_discard; + } inode->i_ino =3D (u32)next_id; inode->i_mode =3D mode; inode->i_uid =3D current_fsuid(); @@ -210,7 +217,11 @@ struct inode *hfs_new_inode(struct inode *dir, const s= truct qstr *name, umode_t if (S_ISDIR(mode)) { inode->i_size =3D 2; folder_count =3D atomic64_inc_return(&HFS_SB(sb)->folder_count); - BUG_ON(folder_count > U32_MAX); + if (folder_count> U32_MAX) { + atomic64_dec(&HFS_SB(sb)->folder_count); + pr_err("cannot create new inode: folder count exceeds limit\n"); + goto out_discard; + } if (dir->i_ino =3D=3D HFS_ROOT_CNID) HFS_SB(sb)->root_dirs++; inode->i_op =3D &hfs_dir_inode_operations; @@ -220,7 +231,11 @@ struct inode *hfs_new_inode(struct inode *dir, const s= truct qstr *name, umode_t } else if (S_ISREG(mode)) { HFS_I(inode)->clump_blocks =3D HFS_SB(sb)->clumpablks; file_count =3D atomic64_inc_return(&HFS_SB(sb)->file_count); - BUG_ON(file_count > U32_MAX); + if (file_count > U32_MAX) { + atomic64_dec(&HFS_SB(sb)->file_count); + pr_err("cannot create new inode: file count exceeds limit\n"); + goto out_discard; + } if (dir->i_ino =3D=3D HFS_ROOT_CNID) HFS_SB(sb)->root_files++; inode->i_op =3D &hfs_file_inode_operations; @@ -244,6 +259,11 @@ struct inode *hfs_new_inode(struct inode *dir, const s= truct qstr *name, umode_t hfs_mark_mdb_dirty(sb); =20 return inode; + + out_discard: + iput(inode); + out_err: + return ERR_PTR(err); } =20 void hfs_delete_inode(struct inode *inode) @@ -252,7 +272,6 @@ void hfs_delete_inode(struct inode *inode) =20 hfs_dbg("ino %lu\n", inode->i_ino); if (S_ISDIR(inode->i_mode)) { - BUG_ON(atomic64_read(&HFS_SB(sb)->folder_count) > U32_MAX); atomic64_dec(&HFS_SB(sb)->folder_count); if (HFS_I(inode)->cat_key.ParID =3D=3D cpu_to_be32(HFS_ROOT_CNID)) HFS_SB(sb)->root_dirs--; @@ -261,7 +280,6 @@ void hfs_delete_inode(struct inode *inode) return; } =20 - BUG_ON(atomic64_read(&HFS_SB(sb)->file_count) > U32_MAX); atomic64_dec(&HFS_SB(sb)->file_count); if (HFS_I(inode)->cat_key.ParID =3D=3D cpu_to_be32(HFS_ROOT_CNID)) HFS_SB(sb)->root_files--; diff --git a/fs/hfs/mdb.c b/fs/hfs/mdb.c index f28cd24dee842..a97cea35ca2e1 100644 --- a/fs/hfs/mdb.c +++ b/fs/hfs/mdb.c @@ -64,6 +64,27 @@ static int hfs_get_last_session(struct super_block *sb, return 0; } =20 +bool is_hfs_cnid_counts_valid(struct super_block *sb) +{ + struct hfs_sb_info *sbi =3D HFS_SB(sb); + bool corrupted =3D false; + + if (unlikely(atomic64_read(&sbi->next_id) > U32_MAX)) { + pr_warn("next CNID exceeds limit\n"); + corrupted =3D true; + } + if (unlikely(atomic64_read(&sbi->file_count) > U32_MAX)) { + pr_warn("file count exceeds limit\n"); + corrupted =3D true; + } + if (unlikely(atomic64_read(&sbi->folder_count) > U32_MAX)) { + pr_warn("folder count exceeds limit\n"); + corrupted =3D true; + } + + return !corrupted; +} + /* * hfs_mdb_get() * @@ -159,6 +180,11 @@ int hfs_mdb_get(struct super_block *sb) atomic64_set(&HFS_SB(sb)->file_count, be32_to_cpu(mdb->drFilCnt)); atomic64_set(&HFS_SB(sb)->folder_count, be32_to_cpu(mdb->drDirCnt)); =20 + if (!is_hfs_cnid_counts_valid(sb)) { + pr_warn("filesystem possibly corrupted, running fsck.hfs is recommended.= Mounting read-only.\n"); + sb->s_flags |=3D SB_RDONLY; + } + /* TRY to get the alternate (backup) MDB. */ sect =3D part_start + part_size - 2; bh =3D sb_bread512(sb, sect, mdb2); @@ -212,7 +238,7 @@ int hfs_mdb_get(struct super_block *sb) =20 attrib =3D mdb->drAtrb; if (!(attrib & cpu_to_be16(HFS_SB_ATTRIB_UNMNT))) { - pr_warn("filesystem was not cleanly unmounted, running fsck.hfs is recom= mended. mounting read-only.\n"); + pr_warn("filesystem was not cleanly unmounted, running fsck.hfs is recom= mended. Mounting read-only.\n"); sb->s_flags |=3D SB_RDONLY; } if ((attrib & cpu_to_be16(HFS_SB_ATTRIB_SLOCK))) { @@ -270,15 +296,12 @@ void hfs_mdb_commit(struct super_block *sb) /* These parameters may have been modified, so write them back */ mdb->drLsMod =3D hfs_mtime(); mdb->drFreeBks =3D cpu_to_be16(HFS_SB(sb)->free_ablocks); - BUG_ON(atomic64_read(&HFS_SB(sb)->next_id) > U32_MAX); mdb->drNxtCNID =3D cpu_to_be32((u32)atomic64_read(&HFS_SB(sb)->next_id)); mdb->drNmFls =3D cpu_to_be16(HFS_SB(sb)->root_files); mdb->drNmRtDirs =3D cpu_to_be16(HFS_SB(sb)->root_dirs); - BUG_ON(atomic64_read(&HFS_SB(sb)->file_count) > U32_MAX); mdb->drFilCnt =3D cpu_to_be32((u32)atomic64_read(&HFS_SB(sb)->file_count)); - BUG_ON(atomic64_read(&HFS_SB(sb)->folder_count) > U32_MAX); mdb->drDirCnt =3D cpu_to_be32((u32)atomic64_read(&HFS_SB(sb)->folder_count)); =20 diff --git a/fs/hfs/super.c b/fs/hfs/super.c index df289cbdd4e85..97546d6b41f47 100644 --- a/fs/hfs/super.c +++ b/fs/hfs/super.c @@ -34,6 +34,7 @@ MODULE_LICENSE("GPL"); =20 static int hfs_sync_fs(struct super_block *sb, int wait) { + is_hfs_cnid_counts_valid(sb); hfs_mdb_commit(sb); return 0; } @@ -65,6 +66,8 @@ static void flush_mdb(struct work_struct *work) sbi->work_queued =3D 0; spin_unlock(&sbi->work_lock); =20 + is_hfs_cnid_counts_valid(sb); + hfs_mdb_commit(sb); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 26BB348034A; Sat, 28 Feb 2026 17:33:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300030; cv=none; b=R0lQAIYRqenI/Jp0t3A1wSBq1b9uG123EVEa4L6fqXbMVcwXfnHHVH5sy6xptPMfiQ56AtEXt0Ew8r5h/l55WU7szBYDeMFTvXF8pFFwWJHThRv6z+pzdoj2P+wE2tnxVzvO/NGn7T2TqBEQnQo1qErvUGKdUhDEe5pnu5ozTr4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300030; c=relaxed/simple; bh=x3mFUwKG+WkAkFMJ/2Po3saOmtkk6EbTvNzoqVjfVOY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mI23rnlzktdpDg0S0Afr0hSP+xXZy5+A64CS7fBxEUlNHFHsdUXHg4s9i7/sfwYgcJC6P6kxp8ijxQVHXSFEPIOJ7WmdxxxeBeAKgl7G90sACXLWJndcOL+YykiMAmOIUOgKz3WhEFwPV25BxqNwx+7YJuhv98e2Vcfx6Iabb9Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NuhoiVZ2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NuhoiVZ2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 335E8C116D0; Sat, 28 Feb 2026 17:33:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300029; bh=x3mFUwKG+WkAkFMJ/2Po3saOmtkk6EbTvNzoqVjfVOY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NuhoiVZ2UM4BgZ3PncEIMft+ND8g5KyQJPEYnFYmLsO58bliwhafFCs6usksuHszc WP7rko000aV4bHNHtQ+A9IRw+TICmnwQfSV4eYb2X6mr21Gf6Aym/aHQ69gudEva/m XwQCGltY3QUje4xf1w0rTe9GKYgaexBOhe+T4A2U9LF37UupCuCj1JtgAAj0Lbjjao xfbMsyjNlN9ze/7jc1S+1ryR+bCkRmry+czMvWAy0OBIFwXJ/p/014SXiTqsQX+tC4 o/FMI4iJdIsf+UArrXDEH3l/Mca7YLRV7u2di10YJpCOQC3VKOMrjxds0gx1W6at71 mZQQgVWyvX+pw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jeffrey Bencteux , Paul Moore , Sasha Levin Subject: [PATCH 6.19 041/844] audit: add missing syscalls to read class Date: Sat, 28 Feb 2026 12:19:14 -0500 Message-ID: <20260228173244.1509663-42-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jeffrey Bencteux [ Upstream commit bcb90a2834c7393c26df9609b889a3097b7700cd ] The "at" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class. Signed-off-by: Jeffrey Bencteux Signed-off-by: Paul Moore Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/asm-generic/audit_read.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/asm-generic/audit_read.h b/include/asm-generic/audit_r= ead.h index 7bb7b5a83ae2e..fb9991f53fb6f 100644 --- a/include/asm-generic/audit_read.h +++ b/include/asm-generic/audit_read.h @@ -4,9 +4,15 @@ __NR_readlink, #endif __NR_quotactl, __NR_listxattr, +#ifdef __NR_listxattrat +__NR_listxattrat, +#endif __NR_llistxattr, __NR_flistxattr, __NR_getxattr, +#ifdef __NR_getxattrat +__NR_getxattrat, +#endif __NR_lgetxattr, __NR_fgetxattr, #ifdef __NR_readlinkat --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2CF433A9D1; Sat, 28 Feb 2026 17:33:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300031; cv=none; b=kOKUpRGapR+sPnzWLkr62zIi9xhAdNSYIGR+JsUIXyZqPrg5RyuNC5/qUPzgGDSInQYTWMnXUA3onkW1PLVRGmxPdy7Ct4G91xu2VhAUOL7aPP2kejysYdymlf1XEZ1MDfCQhrMka7bDDj+GymqRrIjUZjiq7+9iB8ZW3HxgGp8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300031; c=relaxed/simple; bh=MgRoRHKMN2hql43Baj4t2TCddrzhBbDDOZni91WrMe4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gQSRuMBIq8vTYTckNyODh51C8RaG0itKvdVS9GeOB3Q+0fvNcFKVEpXBkWP7JtLrPcOglx1btJfANv4lsZWPqIxrMCUd7w5fD+rgiZfp6KO4sSwgB+K1y2tRqV5EZgIQS6lyQIsk8Iwdhz8OkqrW/8VRxF7HnT7vJDlMfoLGtec= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CCo3MB8l; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CCo3MB8l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D3F8C2BC87; Sat, 28 Feb 2026 17:33:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300030; bh=MgRoRHKMN2hql43Baj4t2TCddrzhBbDDOZni91WrMe4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CCo3MB8lqBtr+ToySNE6sUy8W4xYd4ptCytwL5Hyvv8gnJ/oQjWENki91HQR/nZIw 2gUctkpg7YK/gIDc6mREBU2YnaGNaD8pTnX4NQ+GDE7uVZfVYSmHfwa3XzuqsGciGL qheVWHCKig8V24qJYwpf6oUbkgJK+XbVTSxXEyy5n6SAEz+/ZV8Bwn9ZctcXDI+6cA Pe07lXTtiZBTzB+zWOtybBwq84UAkxajIIXqB4MoMFoMeFihgYLJhtjDqi2X716X4T ArOgEuFgvuZgFa1Nt9iLCO848R1hd7EMHMcQ8nlPna2QR/SVEQaTsrsGQ3LuVCcNld MgXXopSTuSkpQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tetsuo Handa , syzbot , Viacheslav Dubeyko , Sasha Levin Subject: [PATCH 6.19 042/844] hfsplus: pretend special inodes as regular files Date: Sat, 28 Feb 2026 12:19:15 -0500 Message-ID: <20260228173244.1509663-43-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tetsuo Handa [ Upstream commit ed8889ca21b6ab37bc1435c4009ce37a79acb9e6 ] Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=3D895c23f6917da440ed0d Signed-off-by: Tetsuo Handa Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/d0a07b1b-8b73-4002-8e29-e2bd56871262@I-love= .SAKURA.ne.jp Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/hfsplus/super.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index aaffa9e060a0a..7f327b777ece8 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -53,6 +53,12 @@ static int hfsplus_system_read_inode(struct inode *inode) return -EIO; } =20 + /* + * Assign a dummy file type, for may_open() requires that + * an inode has a valid file type. + */ + inode->i_mode =3D S_IFREG; + return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4D2534A784; Sat, 28 Feb 2026 17:33:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300032; cv=none; b=NBfbqbpZXkXJ9JYinoLV7cWbZ+n1HBnlpvYIdz0dfmZDygJBpwS1C33DukphwA7gQvzaCJp2Tqa0eOWdFhP8YJEmdEB6Yia5JG+/J4CjypPRcVviJoF0P+Tw+TO7RryzAgtxmBOyo/G7ux7vy58lrKXvWuwgtbsCs4flMORu6J0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300032; c=relaxed/simple; bh=O0ssoK+Ropf2+wKoGNPKJ0dRMeEOUWpGrGNqjOpJUxI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=crOQBT2rnC7xCsmQSQ2Wx67jPmv3QKouccKpfQOUlW0YW7uAxaK679hMUdNvS1Lzh1eGeTyQD2vZHn1J6shM54Zb5Axfg1Zf/BwJb/Yxiy5VueI+Og3CFLEDNsWsDvKP1GQpUvvDty1B2U2nT0qvpPzYuWmdipDnGKUVR0IuwjA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pSCJt1Ry; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pSCJt1Ry" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F213DC116D0; Sat, 28 Feb 2026 17:33:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300031; bh=O0ssoK+Ropf2+wKoGNPKJ0dRMeEOUWpGrGNqjOpJUxI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pSCJt1Ryy36iIml2yf/iMpGR4II51U7yKnJhpcQZnvCYCZ6nLiu5bPnTSI/JEnUhR pklWLBktM9HKNn+/EurugFubkHn1oxuffREXdHVQCrfNz7d3oeoLi58awPRb5WFqjB 4TXTZfnkyFHjfSwvIlCLpPiWrZL1jI9QIaPNXiqrkzxap18+5vrBwgTpds8539Nkib ufzXxGNeuzMwde+pbSfTkexhhIB7isWYMrPGCJmBOOyVEcBct31lpzKAaOW6lzdNad awOIguG+/fSE48XwhDwwvCTR4I9t6+uNjEvCezWefV8gjm2HAP/iLEXMDiXXf8p0Sd k5S69ptGpa+5w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frank Li , kernel test robot , Alexandre Belloni , Sasha Levin Subject: [PATCH 6.19 043/844] i3c: master: svc: Initialize 'dev' to NULL in svc_i3c_master_ibi_isr() Date: Sat, 28 Feb 2026 12:19:16 -0500 Message-ID: <20260228173244.1509663-44-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frank Li [ Upstream commit 3c9ffb4db787428a5851d5865823ab23842d5103 ] Initialize the 'dev' pointer to NULL in svc_i3c_master_ibi_isr() and add a NULL check in the error path. Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202512131016.YCKIsDXM-lkp@intel.com/ Signed-off-by: Frank Li Link: https://patch.msgid.link/20251215200852.3079073-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/i3c/master/svc-i3c-master.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i= 3c-master.c index a62f22ff8b576..857504d36e186 100644 --- a/drivers/i3c/master/svc-i3c-master.c +++ b/drivers/i3c/master/svc-i3c-master.c @@ -533,8 +533,8 @@ static int svc_i3c_master_handle_ibi_won(struct svc_i3c= _master *master, u32 msta static void svc_i3c_master_ibi_isr(struct svc_i3c_master *master) { struct svc_i3c_i2c_dev_data *data; + struct i3c_dev_desc *dev =3D NULL; unsigned int ibitype, ibiaddr; - struct i3c_dev_desc *dev; u32 status, val; int ret; =20 @@ -627,7 +627,7 @@ static void svc_i3c_master_ibi_isr(struct svc_i3c_maste= r *master) * for the slave to interrupt again. */ if (svc_i3c_master_error(master)) { - if (master->ibi.tbq_slot) { + if (master->ibi.tbq_slot && dev) { data =3D i3c_dev_get_master_data(dev); i3c_generic_ibi_recycle_slot(data->ibi_pool, master->ibi.tbq_slot); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAB88480979; Sat, 28 Feb 2026 17:33:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300032; cv=none; b=IMbPD7p7MA5o+ZLqUBDDVXcA9ODO3UUU3t0evEHvfqSTpO9W/GhJ9zf+/SflZ5k3GwDbE7XmJiNErOKMVeRsy2UwDRHh64g0lxe/5aT22Du8AGz4GiqYFE5GiVnEhnGo8I5CYv8Z8vTktbPgcca4UOyVj7IUhWeaXgXDs2KJmFw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300032; c=relaxed/simple; bh=HfdzIhtm/P1ivjYx+JiI04y9xYn3VxaKtR7qwfHK22Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KaZ7ndEO1LgQgEEppTybz3hEHroCJbjyiOL28y61XbGr0qQoVPZl0wgY1IH79vXfeyn9dZzSn46dSfPH3YcZJ9xwiwnTUXF5aU1QnIPM1HukcKT+9Flo8hU3jIUtlGk5x2bV6J6U6QwsjWz64/Oz49W84BNfe6agxzuFsDr1xLI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=luPk9op3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="luPk9op3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1D3EC2BC87; Sat, 28 Feb 2026 17:33:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300032; bh=HfdzIhtm/P1ivjYx+JiI04y9xYn3VxaKtR7qwfHK22Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=luPk9op3YEbiisEcfN++v/TMwgcgWobD/kWifiZtbd8Lw9ZkXf6Rds32nADJdKDK/ QY6KQ8g7NBpg/WxcXW9JpcRfpYedRBn/LyHV7iJYgKA3je1UYmmP1xc3GoayL5F1GH U5rrRmEihIicTs+xpnkX3l0eu3asXW2zxLD9WgBi3E24ZCtbQFkMAgX0dbHpjPx+eN ZjHUrjCq7i8X6WxMd3rmVmBcopJoMhagzGwoD8fFD+TNqbbTEe4ffzyHn8CCqmHP1h uuDpj+G/F+ZbQFKFNtg0G4bWkXLEKNFfjUzdOplhPqN2KC+Zi7NDtZQgLyeWC6MAjQ +qlic40IBOfRQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Adrian Hunter , Frank Li , Alexandre Belloni , Sasha Levin Subject: [PATCH 6.19 044/844] i3c: mipi-i3c-hci: Stop reading Extended Capabilities if capability ID is 0 Date: Sat, 28 Feb 2026 12:19:17 -0500 Message-ID: <20260228173244.1509663-45-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Adrian Hunter [ Upstream commit 0818e4aa8fdeeed5973e0a8faeddc9da599fc897 ] Extended Capability ID value 0 is special. It signifies the end of the list. Stop reading Extended Capabilities if capability ID is 0. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260106164416.67074-3-adrian.hunter@intel.c= om Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/i3c/master/mipi-i3c-hci/ext_caps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i3c/master/mipi-i3c-hci/ext_caps.c b/drivers/i3c/maste= r/mipi-i3c-hci/ext_caps.c index 7714f00ea9cc0..533a495e14c86 100644 --- a/drivers/i3c/master/mipi-i3c-hci/ext_caps.c +++ b/drivers/i3c/master/mipi-i3c-hci/ext_caps.c @@ -272,7 +272,7 @@ int i3c_hci_parse_ext_caps(struct i3c_hci *hci) cap_length =3D FIELD_GET(CAP_HEADER_LENGTH, cap_header); dev_dbg(&hci->master.dev, "id=3D0x%02x length=3D%d", cap_id, cap_length); - if (!cap_length) + if (!cap_id || !cap_length) break; if (curr_cap + cap_length * 4 >=3D end) { dev_err(&hci->master.dev, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AC2B33A01E; Sat, 28 Feb 2026 17:33:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300033; cv=none; b=dKr8dXyH2mc7BVwfzk2ehF/fcIBLak3GpzZDOpz9p3OPl6DyKpAJxRsva8Cqj0oq7EBom9Fr01cYlf64d9OwZIHDHmWhgT5Pb5pIO1hd5w1bVLe/MAt1bVCZ6u8dW+rMiHorTySBIsWt1SD31sUIZsBkVB+MCRpTcxKVWbiapm8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300033; c=relaxed/simple; bh=iv7VVudKM1I3hlT9k5+PCMCP6tgXzG9LZ2Dv/FdCcbk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WMoAcjFzsktvT5Q5aAkHjF8ctvhS9nUwx/0jslV0hlwccoDrtjM21hb640lHr740ZUrw13JR4+RM/z5hagL9SmoFxrn5XfMedFzNKLda0PCqC9aeo5naBeBm8LSjLm4t6Pjw7A68Fbnbtg8cbJ3PaFiYndPDsMaEQIwG4DLOuc0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S2IIWYqI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S2IIWYqI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3853C2BC9E; Sat, 28 Feb 2026 17:33:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300033; bh=iv7VVudKM1I3hlT9k5+PCMCP6tgXzG9LZ2Dv/FdCcbk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S2IIWYqIf5BpIWUo3NvABgdA1tcvEfwbelncS8UOOEg7ZnWgEr+5kvE5qF/tDycpk Lzp14zcKWDRXkbkIYg5qvTihEk+74peOOTGUhoI0RoxoMxo1wgbZhyBt2fZxp661RY HUAfmBZ8lmBoPhil43L1RvGV4h/jUsqropZYijdMHSVD7HLy/sIsIBSnZ5IfAJe9FY 9O2tuRFQxXHNw+ERAfkQXUg0++gTk3xGaq/4vZ9fwPPN3a5RzNZdN/BVsAaA8XIbrf zV1bAuWCafd8CB0Z/dOWTJsFhC6cz7r1y9b5aD0ShB4xQJZWDaMe+szv3jFTInzJHw 7hUrSG0h5/yvA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Adrian Hunter , Frank Li , Alexandre Belloni , Sasha Levin Subject: [PATCH 6.19 045/844] i3c: mipi-i3c-hci: Reset RING_OPERATION1 fields during init Date: Sat, 28 Feb 2026 12:19:18 -0500 Message-ID: <20260228173244.1509663-46-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Adrian Hunter [ Upstream commit 78f63ae4a82db173f93adca462e63d11ba06b126 ] The MIPI I3C HCI specification does not define reset values for RING_OPERATION1 fields, and some controllers (e.g., Intel) do not clear them during a software reset. Ensure the ring pointers are explicitly set to zero during bus initialization to avoid inconsistent state. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113072702.16268-2-adrian.hunter@intel.c= om Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/i3c/master/mipi-i3c-hci/dma.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/i3c/master/mipi-i3c-hci/dma.c b/drivers/i3c/master/mip= i-i3c-hci/dma.c index c401a9425cdc5..951abfea5a6fd 100644 --- a/drivers/i3c/master/mipi-i3c-hci/dma.c +++ b/drivers/i3c/master/mipi-i3c-hci/dma.c @@ -342,6 +342,14 @@ static int hci_dma_init(struct i3c_hci *hci) rh_reg_write(INTR_SIGNAL_ENABLE, regval); =20 ring_ready: + /* + * The MIPI I3C HCI specification does not document reset values for + * RING_OPERATION1 fields and some controllers (e.g. Intel controllers) + * do not reset the values, so ensure the ring pointers are set to zero + * here. + */ + rh_reg_write(RING_OPERATION1, 0); + rh_reg_write(RING_CONTROL, RING_CTRL_ENABLE | RING_CTRL_RUN_STOP); } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 765CA480DE0; Sat, 28 Feb 2026 17:33:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300034; cv=none; b=CLm7N3MsO698H3JwJfrf4+HB8/2lA5gcCLoGexUvtu/yfnktkdAzIJX8B/vsWh5iHhO1JnJXhvwng+vySJfGMNtholNsRKj6X9ZHXlYvp6gEwP9gZ+Vqiyj/uMlg0zaP37pusuPuEzJFmraF0WWelolimUEy6+98OI65/6hqDrQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300034; c=relaxed/simple; bh=S8OInPU44O8H08ja7d4spf82h8LMrpkcMHwGprFpQ4Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TH9J6P8aMaGuI2rjx+qee0m4+gE9jrqmZHbYcrGtiAMzENy34HLsOOShP0G676REQSHdLO5p4pOxYy2oqHPzOYDqcwU3f99eoC6+IWnMqqWP7MWEBivC+c2J7OmK8DE5n7uupR3FBjwwIO5cYIZa/0AkYNxidyTBtDfPQQh4MD0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a0hA44KW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a0hA44KW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C08B0C116D0; Sat, 28 Feb 2026 17:33:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300034; bh=S8OInPU44O8H08ja7d4spf82h8LMrpkcMHwGprFpQ4Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a0hA44KW+XS/JXgiHvPshwIMGx4GBBUAgGG4Vxic/l09LtGdy/LNJSTk2j3+kMRk1 /+IAoSQtMeHXeqAaFp9v5QLWV+wmZCGc21Om5k4m29U0iiYk2Np7pP59RAsz87b4P3 OUK/oSWCZuZPGClQfle8dpa/mqnsg1WtFePG/+/UCj2804Ml8ifTZau2T5r1GGtUY4 OH86lNH/+7PYT75MYL7CXJpBQWUpPd4nRtVcOMCnn7L2y+5MYk/6h++ajdR2L2N69+ +eY+FUd36+5rrNN/lBpHUNmmaV26mTM2tusLi+yPqPYcaJ8x/c5iFd/0WoFErtrJAl LboekIr4dtAyw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alexander Aring , David Teigland , Sasha Levin Subject: [PATCH 6.19 046/844] dlm: fix recovery pending middle conversion Date: Sat, 28 Feb 2026 12:19:19 -0500 Message-ID: <20260228173244.1509663-47-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexander Aring [ Upstream commit 1416bd508c78bdfdb9ae0b4511369e5581f348ea ] During a workload involving conversions between lock modes PR and CW, lock recovery can create a "conversion deadlock" state between locks that have been recovered. When this occurs, kernel warning messages are logged, e.g. "dlm: WARN: pending deadlock 1e node 0 2 1bf21" "dlm: receive_rcom_lock_args 2e middle convert gr 3 rq 2 remote 2 1e" After this occurs, the deadlocked conversions both appear on the convert queue of the resource being locked, and the conversion requests do not complete. Outside of recovery, conversions that would produce a deadlock are resolved immediately, and return -EDEADLK. The locks are not placed on the convert queue in the deadlocked state. To fix this problem, an lkb under conversion between PR/CW is rebuilt during recovery on a new master's granted queue, with the currently granted mode, rather than being rebuilt on the new master's convert queue, with the currently granted mode and the newly requested mode. The in-progress convert is then resent to the new master after recovery, so the conversion deadlock will be processed outside of the recovery context and handled as described above. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/dlm/lock.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index be938fdf17d96..c01a291db401b 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -5014,25 +5014,8 @@ void dlm_receive_buffer(const union dlm_packet *p, i= nt nodeid) static void recover_convert_waiter(struct dlm_ls *ls, struct dlm_lkb *lkb, struct dlm_message *ms_local) { - if (middle_conversion(lkb)) { - log_rinfo(ls, "%s %x middle convert in progress", __func__, - lkb->lkb_id); - - /* We sent this lock to the new master. The new master will - * tell us when it's granted. We no longer need a reply, so - * use a fake reply to put the lkb into the right state. - */ - hold_lkb(lkb); - memset(ms_local, 0, sizeof(struct dlm_message)); - ms_local->m_type =3D cpu_to_le32(DLM_MSG_CONVERT_REPLY); - ms_local->m_result =3D cpu_to_le32(to_dlm_errno(-EINPROGRESS)); - ms_local->m_header.h_nodeid =3D cpu_to_le32(lkb->lkb_nodeid); - _receive_convert_reply(lkb, ms_local, true); - unhold_lkb(lkb); - - } else if (lkb->lkb_rqmode >=3D lkb->lkb_grmode) { + if (middle_conversion(lkb) || lkb->lkb_rqmode >=3D lkb->lkb_grmode) set_bit(DLM_IFL_RESEND_BIT, &lkb->lkb_iflags); - } =20 /* lkb->lkb_rqmode < lkb->lkb_grmode shouldn't happen since down conversions are async; there's no reply from the remote master */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7CE51481221; Sat, 28 Feb 2026 17:33:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300035; cv=none; b=aUpQqKJqxs5DQOkLmDZ09oeC1rALh/whZ31R4q4226xTmqyPsGoMz+Jloa7LJWeAIXQST2Nxic+pBhu9wB34/jJnUDjtXJJjB+cbYTFuRM68LOAu/VHHxXBBzropo3qd9YgUE4YYXpRrN7Tgs4kXn5l7/Sv5QAlQkrOZ0+3fdTU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300035; c=relaxed/simple; bh=3hym72ytkvsMcl0STiUx/epQk0w3xXD3m4DrcNFZKlU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Su2Eq0Hkc3f1Y0UkYBqDK4swyhSo+nr26AgnmcIYLvUja+cPjGQp72iT6pcWpnFSBoFf58gy1ZrFYrYeveFw1voGyvcy8skh2Irn8+WJKDZ6DozGNd0lQ6YQWZhA6f6L7Hj85iGvqNv/UgLwoUYOIVzXRakC8Vh/JulLK6RWpFA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Kj/cTzTS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Kj/cTzTS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1ADFC19424; Sat, 28 Feb 2026 17:33:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300035; bh=3hym72ytkvsMcl0STiUx/epQk0w3xXD3m4DrcNFZKlU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kj/cTzTSWtCJYCllYau+iVdvMKoFl2u4o0Zveaycq0UcGtuU70QdIW7F3Esz5B8xO Wss1QORwG2cq3YVa0UHPuCOGlSMtWrbEf8Dz7rsS+HwtEvQhibgu9MRxVzwBZVnLVh VJuGQERwqlehx0VtsKb1Nv7libq+hD4beBVlbdogFgldkJzYvqx9ZKcn/uNgaUFivt E+bkXWMWKSo4sq9wnJ82pCfInNc6Upnl6/bCFlLRxerBJTYuMOPKegqw81Ch0bhf3v tdIR3IhJxQU92+dnLmU3yWAe3559eLuQKCBAbxWQkHTMd0EhLJKyHiQOqzE9k5kwWn bilEWXkabCrPQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jori Koolstra , Jan Kara , syzbot+5ad0824204c7bf9b67f2@syzkaller.appspotmail.com, Christian Brauner , Sasha Levin Subject: [PATCH 6.19 047/844] minix: Add required sanity checking to minix_check_superblock() Date: Sat, 28 Feb 2026 12:19:20 -0500 Message-ID: <20260228173244.1509663-48-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jori Koolstra [ Upstream commit 8c97a6ddc95690a938ded44b4e3202f03f15078c ] The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report. Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20251208153947.108343-1-jkoolstra@xs4all.nl Reviewed-by: Jan Kara Reported-by: syzbot+5ad0824204c7bf9b67f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D5ad0824204c7bf9b67f2 Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/minix/inode.c | 50 ++++++++++++++++++++++++++++-------------------- 1 file changed, 29 insertions(+), 21 deletions(-) diff --git a/fs/minix/inode.c b/fs/minix/inode.c index 51ea9bdc813f7..c8c6b2135abe7 100644 --- a/fs/minix/inode.c +++ b/fs/minix/inode.c @@ -170,10 +170,38 @@ static int minix_reconfigure(struct fs_context *fc) static bool minix_check_superblock(struct super_block *sb) { struct minix_sb_info *sbi =3D minix_sb(sb); + unsigned long block; =20 - if (sbi->s_imap_blocks =3D=3D 0 || sbi->s_zmap_blocks =3D=3D 0) + if (sbi->s_log_zone_size !=3D 0) { + printk("minix-fs error: zone size must equal block size. " + "s_log_zone_size > 0 is not supported.\n"); + return false; + } + + if (sbi->s_ninodes < 1 || sbi->s_firstdatazone <=3D 4 || + sbi->s_firstdatazone >=3D sbi->s_nzones) return false; =20 + /* Apparently minix can create filesystems that allocate more blocks for + * the bitmaps than needed. We simply ignore that, but verify it didn't + * create one with not enough blocks and bail out if so. + */ + block =3D minix_blocks_needed(sbi->s_ninodes, sb->s_blocksize); + if (sbi->s_imap_blocks < block) { + printk("MINIX-fs: file system does not have enough " + "imap blocks allocated. Refusing to mount.\n"); + return false; + } + + block =3D minix_blocks_needed( + (sbi->s_nzones - sbi->s_firstdatazone + 1), + sb->s_blocksize); + if (sbi->s_zmap_blocks < block) { + printk("MINIX-fs: file system does not have enough " + "zmap blocks allocated. Refusing to mount.\n"); + return false; + } + /* * s_max_size must not exceed the block mapping limitation. This check * is only needed for V1 filesystems, since V2/V3 support an extra level @@ -293,26 +321,6 @@ static int minix_fill_super(struct super_block *s, str= uct fs_context *fc) minix_set_bit(0,sbi->s_imap[0]->b_data); minix_set_bit(0,sbi->s_zmap[0]->b_data); =20 - /* Apparently minix can create filesystems that allocate more blocks for - * the bitmaps than needed. We simply ignore that, but verify it didn't - * create one with not enough blocks and bail out if so. - */ - block =3D minix_blocks_needed(sbi->s_ninodes, s->s_blocksize); - if (sbi->s_imap_blocks < block) { - printk("MINIX-fs: file system does not have enough " - "imap blocks allocated. Refusing to mount.\n"); - goto out_no_bitmap; - } - - block =3D minix_blocks_needed( - (sbi->s_nzones - sbi->s_firstdatazone + 1), - s->s_blocksize); - if (sbi->s_zmap_blocks < block) { - printk("MINIX-fs: file system does not have enough " - "zmap blocks allocated. Refusing to mount.\n"); - goto out_no_bitmap; - } - /* set up enough so that it can read an inode */ s->s_op =3D &minix_sops; s->s_time_min =3D 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FC3434C128; Sat, 28 Feb 2026 17:33:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300036; cv=none; b=I6YxlbVjOj0wgJuoABV59KxTh+MZMEagdstxbUQrzF8VgGIG6cRnY2P0yuvlKiabLmJzpfltOH9a4de85HWQvUAUDeH0s+Ht2kRU0Qt1LfTHXM0tLzhxK45nxdNglOx5WjCnq6dzehdECXTWEYR4IP7ikrxk0gosUhy3UTXt9C8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300036; c=relaxed/simple; bh=qFxe7UMVks0SzFECFu0TKvPZLn9NTWwEwRkXjs1MK28=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fj/JjEdKRAZD+7aOBWY7G+vRMsU3AKz4DAJApTQnb1NSDMhFtFle1eO76UnLmJq0qbQywn04gxbZ7zsjOdVtsqnl6/QwlsBV30kGvG9kt4RiQsmPZs41c9TGiKm3qEb6heZyR4n5LMNiTCK6JnW4TGVgHPqCCtED89Ct6H3v/3M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hgfCQbkF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hgfCQbkF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7EC6C116D0; Sat, 28 Feb 2026 17:33:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300036; bh=qFxe7UMVks0SzFECFu0TKvPZLn9NTWwEwRkXjs1MK28=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hgfCQbkFIveFgOG5kcSRWNONWA5k8VtyfEoCk+Lk1TXuxbN93WlBsr1ilIXz4xklT 9p1R1uqeYRjDe2cMu8FPoWbjRDKP1RncUSBYeIbfd4QsjZrslryoeoBEm8y7JTY28v buiSIZQUIuuQJE7H1QMHRm+yWRV9pGLZTk501fGsKSgbKVlcwuV+Iihvg4z+eoXyAg ErJFERHs2apVNXOHv218cr1McwRslSrKsL1ce0pX/PKB0ZlJNG7VCUqUxa+Xy1gGxe j2uER0kpiRZgBzzwYcIY3HaliiwllDvektK+PXt0nnzdthMZIcxYvlJpaKuzUjRLzH 1QCFo431os46g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ezrak1e , Alexander Aring , David Teigland , Sasha Levin Subject: [PATCH 6.19 048/844] dlm: validate length in dlm_search_rsb_tree Date: Sat, 28 Feb 2026 12:19:21 -0500 Message-ID: <20260228173244.1509663-49-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ezrak1e [ Upstream commit 080e5563f878c64e697b89e7439d730d0daad882 ] The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow. Signed-off-by: Ezrak1e Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/dlm/lock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index c01a291db401b..a393ecaf3442a 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -626,7 +626,8 @@ int dlm_search_rsb_tree(struct rhashtable *rhash, const= void *name, int len, struct dlm_rsb **r_ret) { char key[DLM_RESNAME_MAXLEN] =3D {}; - + if (len > DLM_RESNAME_MAXLEN) + return -EINVAL; memcpy(key, name, len); *r_ret =3D rhashtable_lookup_fast(rhash, &key, dlm_rhash_rsb_params); if (*r_ret) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7497748124C; Sat, 28 Feb 2026 17:33:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300037; cv=none; b=PPQTg+UhC54l7LjgAjz05tbKucA8UsVwK98AJIkHUUFbF5NuCFRTQIKD4NQ5uDyIAtM9+wm6r6xfvKfox5jN+tO3QxEPdWS/jt4MCt76NvdGfyfNDfRypsql/YvnHN/3A8W/t13XdS12utJRmmQo5+5Hg2E6T7hKfgtAgA5WRR4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300037; c=relaxed/simple; bh=shKv+VDd4E1VGWSIsBcGikJ997ldocGnM8jUq154LlA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=afbUd+Y1taYXibnMbLHPsaHghruSjEY8OgFCQRdaaHym+ct6Ymt19HQXFELdHL8TC2v6sU7/0hcwuGHDttynHUx/jytMGBiEkWOT746W+w6eZ1p/bruM9JBDuTlg/MZ9EHmgNxiDfqg6Ud5uKaVJ54EoaamQjTYrQ4ycv83iYo8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q/m4Gzut; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="q/m4Gzut" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9702FC19424; Sat, 28 Feb 2026 17:33:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300037; bh=shKv+VDd4E1VGWSIsBcGikJ997ldocGnM8jUq154LlA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q/m4GzutPo+MdStrTkHiZBhbLLHHzNSGIRL1W+GO7MrAqJ+x+ydC3P2xxdIFHjAjo aNuMkIi5vsLbJ6MRlFQW6uhaUD2ItOpIjIgofO22Wj2jIeCOty+MTU1iNSpfFLH6fS PcY4495GJ3skksR+ufL11jkSnVSDHAEjjVFkwEMt4VxJpzxUqyExisQUboyDc1Uk9b Ouir6AEJTDObdoKaL4dggRhxmomXF8ITA5sydL+7u0q1/6d1wByzTkS4e0RDVSU1N2 S9HToHt1Z+uT3AkekyCgD9/iFLEgeHmvqWYAVBciRokJA6iqQ4xKEpBPDg3NsHhWza aud9vI1f0UoTQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Filipe Manana , Boris Burkov , Qu Wenruo , David Sterba , Sasha Levin Subject: [PATCH 6.19 049/844] btrfs: don't BUG() on unexpected delayed ref type in run_one_delayed_ref() Date: Sat, 28 Feb 2026 12:19:22 -0500 Message-ID: <20260228173244.1509663-50-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Filipe Manana [ Upstream commit c7d1d4ff56744074e005771aff193b927392d51f ] There is no need to BUG(), we can just return an error and log an error message. Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/extent-tree.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index e4cae34620d19..1bf081243efb2 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -1761,32 +1761,36 @@ static int run_one_delayed_ref(struct btrfs_trans_h= andle *trans, struct btrfs_delayed_extent_op *extent_op, bool insert_reserved) { + struct btrfs_fs_info *fs_info =3D trans->fs_info; int ret =3D 0; =20 if (TRANS_ABORTED(trans)) { if (insert_reserved) { btrfs_pin_extent(trans, node->bytenr, node->num_bytes); - free_head_ref_squota_rsv(trans->fs_info, href); + free_head_ref_squota_rsv(fs_info, href); } return 0; } =20 if (node->type =3D=3D BTRFS_TREE_BLOCK_REF_KEY || - node->type =3D=3D BTRFS_SHARED_BLOCK_REF_KEY) + node->type =3D=3D BTRFS_SHARED_BLOCK_REF_KEY) { ret =3D run_delayed_tree_ref(trans, href, node, extent_op, insert_reserved); - else if (node->type =3D=3D BTRFS_EXTENT_DATA_REF_KEY || - node->type =3D=3D BTRFS_SHARED_DATA_REF_KEY) + } else if (node->type =3D=3D BTRFS_EXTENT_DATA_REF_KEY || + node->type =3D=3D BTRFS_SHARED_DATA_REF_KEY) { ret =3D run_delayed_data_ref(trans, href, node, extent_op, insert_reserved); - else if (node->type =3D=3D BTRFS_EXTENT_OWNER_REF_KEY) + } else if (node->type =3D=3D BTRFS_EXTENT_OWNER_REF_KEY) { ret =3D 0; - else - BUG(); + } else { + ret =3D -EUCLEAN; + btrfs_err(fs_info, "unexpected delayed ref node type: %u", node->type); + } + if (ret && insert_reserved) btrfs_pin_extent(trans, node->bytenr, node->num_bytes); if (ret < 0) - btrfs_err(trans->fs_info, + btrfs_err(fs_info, "failed to run delayed ref for logical %llu num_bytes %llu type %u action = %u ref_mod %d: %d", node->bytenr, node->num_bytes, node->type, node->action, node->ref_mod, ret); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 914B348164B; Sat, 28 Feb 2026 17:33:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300038; cv=none; b=QPs6rRZQLZxEe7j3AGPoCRQwDp7REq506o6YiL3gKlLXnAvXNMl5VyFxaWU9kkkbCPeCCfdS2ptWlFp5pvBUMfqX11lFismT65R3+J83IJFHPeG6Fi6jFjOBCO1tGqxJjCeop/t00FtnXq9lSil8rlI06pyhzsU8nZm+iEvgy8A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300038; c=relaxed/simple; bh=lTdForvCOvrxAPpSHmdeGiymh4Jk0WDPoCxGqiaDsIk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iWoyYN6HoEn6j7uUrvkOpjtF+wP46+9ylFGgrK2SwanqRXPvnaboLTAevHKXeRgC78D8gS0Nh9smGAN4XrPXm3EuThwbMI4rblIQsop6ASGqOXn6Hv+ewy/+QPDiSy2sYjMhT4UqlkMcWE0MCrQRw8sa/JCMc8GbQWsLOR0Z7no= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RdMqhcJu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RdMqhcJu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9CE82C19423; Sat, 28 Feb 2026 17:33:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300038; bh=lTdForvCOvrxAPpSHmdeGiymh4Jk0WDPoCxGqiaDsIk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RdMqhcJu+NgV8oVBrWM3BSw0up/Ys89nO68ymbjpwZd3Hefv8RQ4fDHDtKRpU3QFI B9DKljsOqrcAGmnTTUyADGK/fWj1giqYW06A0FY+2BMIZ6pZ9X2QlU0kmLRiV1GKi4 AARto2rZcA7MuF3IlcTiX4o3qqKZXqxmtDbojIXKQJDfcom1yh5OwTOHjpOhARwy5h yd2N/RMAJmlZncJGD9dBcx+4XzN9XnTswPYNMH8sSk28Ohi/d2pSBpjjob+s4bJlhW ZB6EFGkrKn24nvYxh28tgFA26ZojHdAtELBxw8Ih/aZVTkJLkSVLIiIscBwHlsdnrL KcrrXWhAP6GTg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Qu Wenruo , David Sterba , Sasha Levin Subject: [PATCH 6.19 050/844] btrfs: fallback to buffered IO if the data profile has duplication Date: Sat, 28 Feb 2026 12:19:23 -0500 Message-ID: <20260228173244.1509663-51-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Qu Wenruo [ Upstream commit 7c2830f00c3e086292c1ee9f27b61efaf8e76c9a ] [BACKGROUND] Inspired by a recent kernel bug report, which is related to direct IO buffer modification during writeback, that leads to contents mismatch of different RAID1 mirrors. [CAUSE AND PROBLEMS] The root cause is exactly the same explained in commit 968f19c5b1b7 ("btrfs: always fallback to buffered write if the inode requires checksum"), that we can not trust direct IO buffer which can be modified halfway during writeback. Unlike data checksum verification, if this happened on inodes without data checksum but has the data has extra mirrors, it will lead to stealth data mismatch on different mirrors. This will be way harder to detect without data checksum. Furthermore for RAID56, we can even have data without checksum and data with checksum mixed inside the same full stripe. In that case if the direct IO buffer got changed halfway for the nodatasum part, the data with checksum immediately lost its ability to recover, e.g.: " " =3D Good old data or parity calculated using good old data "X" =3D Data modified during writeback 0 32K 64K Data 1 | | Has csum Data 2 |XXXXXXXXXXXXXXXX | No csum Parity | | In above case, the parity is calculated using data 1 (has csum, from page cache, won't change during writeback), and old data 2 (has no csum, direct IO write). After parity is calculated, but before submission to the storage, direct IO buffer of data 2 is modified, causing the range [0, 32K) of data 2 has a different content. Now all data is submitted to the storage, and the fs got fully synced. Then the device of data 1 is lost, has to be rebuilt from data 2 and parity. But since the data 2 has some modified data, and the parity is calculated using old data, the recovered data is no the same for data 1, causing data checksum mismatch. [FIX] Fix the problem by checking the data allocation profile. If our data allocation profile is either RAID0 or SINGLE, we can allow true zero-copy direct IO and the end user is fully responsible for any race. However this is not going to fix all situations, as it's still possible to race with balance where the fs got a new data profile after the data allocation profile check. But this fix should still greatly reduce the window of the original bug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D99171 Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/direct-io.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/fs/btrfs/direct-io.c b/fs/btrfs/direct-io.c index 07e19e88ba4b3..5443d69efe956 100644 --- a/fs/btrfs/direct-io.c +++ b/fs/btrfs/direct-io.c @@ -814,6 +814,8 @@ ssize_t btrfs_direct_write(struct kiocb *iocb, struct i= ov_iter *from) ssize_t ret; unsigned int ilock_flags =3D 0; struct iomap_dio *dio; + const u64 data_profile =3D btrfs_data_alloc_profile(fs_info) & + BTRFS_BLOCK_GROUP_PROFILE_MASK; =20 if (iocb->ki_flags & IOCB_NOWAIT) ilock_flags |=3D BTRFS_ILOCK_TRY; @@ -827,6 +829,16 @@ ssize_t btrfs_direct_write(struct kiocb *iocb, struct = iov_iter *from) if (iocb->ki_pos + iov_iter_count(from) <=3D i_size_read(inode) && IS_NOS= EC(inode)) ilock_flags |=3D BTRFS_ILOCK_SHARED; =20 + /* + * If our data profile has duplication (either extra mirrors or RAID56), + * we can not trust the direct IO buffer, the content may change during + * writeback and cause different contents written to different mirrors. + * + * Thus only RAID0 and SINGLE can go true zero-copy direct IO. + */ + if (data_profile !=3D BTRFS_BLOCK_GROUP_RAID0 && data_profile !=3D 0) + goto buffered; + relock: ret =3D btrfs_inode_lock(BTRFS_I(inode), ilock_flags); if (ret < 0) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 901F8481666; Sat, 28 Feb 2026 17:33:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300039; cv=none; b=qi9xslZ4n7gOh0MgHDMUgmyeq+RRoocc7Or9Mng2U8tXSn0brLOaaEzUW89He02/uoaRas1p6fTi7zRQmeOdBQQUBYBnkwxTu0mPaNnu/f3korz9uZf+/gIA8bSSywlyowLb1OP0m+EJ9CPj1JrtnB0Ho4hYpEbm+GeiNq8WDho= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300039; c=relaxed/simple; bh=xw88FVVbPcXSiYHWeteOKEwT0qvb3ts8yZxMO2C0w3A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VDEKH/UDGpPh8FOhtIIBrliOQZKEmjrfOvidNNwcjQ5LG+Y2GKN5XbNUlPQdZ/+I9K/D7kwvzuUBheAd27URQ7L8bzPHMBVuwFoemGIMDnRC9ozmxmKK5JRww1rxr6auz9cbQ+V2T9S9r/VGtYFiWxIbha9b0sH2PO8zldoQ0Iw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E+uLclxH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E+uLclxH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82E12C116D0; Sat, 28 Feb 2026 17:33:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300039; bh=xw88FVVbPcXSiYHWeteOKEwT0qvb3ts8yZxMO2C0w3A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E+uLclxH4pcdzfAl8UGKnq97tQMQOWSswod1eip4TKSV+Q1tdtOrL1o0UnGoXx4+3 SJ36oUhp50va8tlHGIsSVb1mnwrEFKumRZiqxS+6/TskOLUs6/1Ik7iHib6mtiSgds I8NnTLSls5F3KqKt1V7fRQr+iizvvv2AIrV22eWAkr6sJbW1e+eiYF3BXqCXMgzGeH +h0kNR5EGVdilHqnkbIzXabfdcB6RHNEZ7q0ACtPIIIUTaAG7i5c6dJ0hvMTbTgm2/ 6yv8cEBBcEHLddvuhyUvYH1GoLbS6zPCcDGJbjm5CkIDkwBnsR1vaP24+pxZDJCvIz sa0RP1rRpR9ug== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: jinbaohong , Qu Wenruo , Robbie Ko , Filipe Manana , David Sterba , Sasha Levin Subject: [PATCH 6.19 051/844] btrfs: handle user interrupt properly in btrfs_trim_fs() Date: Sat, 28 Feb 2026 12:19:24 -0500 Message-ID: <20260228173244.1509663-52-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: jinbaohong [ Upstream commit bfb670b9183b0e4ba660aff2e396ec1cc01d0761 ] When a fatal signal is pending or the process is freezing, btrfs_trim_block_group() and btrfs_trim_free_extents() return -ERESTARTSYS. Currently this is treated as a regular error: the loops continue to the next iteration and count it as a block group or device failure. Instead, break out of the loops immediately and return -ERESTARTSYS to userspace without counting it as a failure. Also skip the device loop entirely if the block group loop was interrupted. Reviewed-by: Qu Wenruo Signed-off-by: Robbie Ko Signed-off-by: jinbaohong Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/extent-tree.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 1bf081243efb2..8bdb609f58a7e 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -6555,6 +6555,10 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, str= uct fstrim_range *range) range->minlen); =20 trimmed +=3D group_trimmed; + if (ret =3D=3D -ERESTARTSYS || ret =3D=3D -EINTR) { + btrfs_put_block_group(cache); + break; + } if (ret) { bg_failed++; bg_ret =3D ret; @@ -6568,6 +6572,9 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, stru= ct fstrim_range *range) "failed to trim %llu block group(s), last error %d", bg_failed, bg_ret); =20 + if (ret =3D=3D -ERESTARTSYS || ret =3D=3D -EINTR) + return ret; + mutex_lock(&fs_devices->device_list_mutex); list_for_each_entry(device, &fs_devices->devices, dev_list) { if (test_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state)) @@ -6576,6 +6583,8 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, stru= ct fstrim_range *range) ret =3D btrfs_trim_free_extents(device, &group_trimmed); =20 trimmed +=3D group_trimmed; + if (ret =3D=3D -ERESTARTSYS || ret =3D=3D -EINTR) + break; if (ret) { dev_failed++; dev_ret =3D ret; @@ -6589,6 +6598,8 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, stru= ct fstrim_range *range) "failed to trim %llu device(s), last error %d", dev_failed, dev_ret); range->len =3D trimmed; + if (ret =3D=3D -ERESTARTSYS || ret =3D=3D -EINTR) + return ret; if (bg_ret) return bg_ret; return dev_ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A438048167D; Sat, 28 Feb 2026 17:34:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300040; cv=none; b=eylPcTIyvDOGuiQWqriQ0hvWeoQjolor90x+1J0+Xi3pz8LSfwx0UgFhADD6qxYvQuaWo9zIpNbbZKzJFzJOqBJD2QCfX3XKwttCzIwddz8hbzuxciGkew6qdI/XwayeWwQaMkzJEzUQW0xsjesVf9K8qli1V+S9LE+s93G6pj8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300040; c=relaxed/simple; bh=xGS7k8bup1A3BByGv4uqYT1BPnXWLFgBjfkOw8FyJj4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kch+xk4SXXUMV/qK4rNP995pYUnIYDDECr91+EAjaXVPa7dDU8yzTLxxhL7Vs4nNJG0Cz06p0Olzrj4N528Jl5EGSwa97CnTKlviPiyhKJ5f/Y2OvI/4y5OVz9PxsKlqaueVg9iYNWc9ZAR4v9CVWaUnMj+bwWeivFFPFITtNhQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TyANpNji; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TyANpNji" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2547C19424; Sat, 28 Feb 2026 17:33:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300040; bh=xGS7k8bup1A3BByGv4uqYT1BPnXWLFgBjfkOw8FyJj4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TyANpNjio0vzmIMXqX6c4MPCefIJVj/0n8vVpnCy/ISzjuHI4dWeaFACpHl6970jp EpHOcmY/nFciXWa/aM1najmLfjLgMx6/zMCm4Tu1FJE2qr8ZeGswR3mPu41OJy6pmU a68gn0sCRoSNiAuQ3N7ikoOFvmmUTmOyL+R3dXgBqJA7+JzX1C7V8o35DqY3ur8LAU 64D5fgToTRjoCU/glAt0XLmLcfWZrufGQ6cN/cBg9FrZGPtk1D8QE/m66+5D6qQSyZ mj5uu3I88u+pZ1y6jgcwsn+BnVUG1Ig4CbbxALgiOfCB+ayxtZ875o142Bn5ybOK4j h73mnPZBVLHZg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shyam Prasad N , David Howells , Steve French , Sasha Levin Subject: [PATCH 6.19 052/844] netfs: when subreq is marked for retry, do not check if it faced an error Date: Sat, 28 Feb 2026 12:19:25 -0500 Message-ID: <20260228173244.1509663-53-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shyam Prasad N [ Upstream commit 82e8885bd7633a36ee9050e6d7f348a4155eed5f ] The *_subreq_terminated functions today only process the NEED_RETRY flag when the subreq was successful or failed with EAGAIN error. However, there could be other retriable errors for network filesystems. Avoid this by processing the NEED_RETRY irrespective of the error code faced by the subreq. If it was specifically marked for retry, the error code must not matter. Acked-by: David Howells Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/netfs/read_collect.c | 10 ++++++++++ fs/netfs/read_retry.c | 4 ++-- fs/netfs/write_collect.c | 8 ++++---- fs/netfs/write_issue.c | 1 + 4 files changed, 17 insertions(+), 6 deletions(-) diff --git a/fs/netfs/read_collect.c b/fs/netfs/read_collect.c index 7a0ffa675fb17..137f0e28a44c5 100644 --- a/fs/netfs/read_collect.c +++ b/fs/netfs/read_collect.c @@ -546,6 +546,15 @@ void netfs_read_subreq_terminated(struct netfs_io_subr= equest *subreq) } } =20 + /* If need retry is set, error should not matter unless we hit too many + * retries. Pause the generation of new subreqs + */ + if (test_bit(NETFS_SREQ_NEED_RETRY, &subreq->flags)) { + trace_netfs_rreq(rreq, netfs_rreq_trace_set_pause); + set_bit(NETFS_RREQ_PAUSE, &rreq->flags); + goto skip_error_checks; + } + if (unlikely(subreq->error < 0)) { trace_netfs_failure(rreq, subreq, subreq->error, netfs_fail_read); if (subreq->source =3D=3D NETFS_READ_FROM_CACHE) { @@ -559,6 +568,7 @@ void netfs_read_subreq_terminated(struct netfs_io_subre= quest *subreq) set_bit(NETFS_RREQ_PAUSE, &rreq->flags); } =20 +skip_error_checks: trace_netfs_sreq(subreq, netfs_sreq_trace_terminated); netfs_subreq_clear_in_progress(subreq); netfs_put_subrequest(subreq, netfs_sreq_trace_put_terminated); diff --git a/fs/netfs/read_retry.c b/fs/netfs/read_retry.c index b99e84a8170af..7793ba5e3e8fc 100644 --- a/fs/netfs/read_retry.c +++ b/fs/netfs/read_retry.c @@ -12,6 +12,7 @@ static void netfs_reissue_read(struct netfs_io_request *rreq, struct netfs_io_subrequest *subreq) { + subreq->error =3D 0; __clear_bit(NETFS_SREQ_MADE_PROGRESS, &subreq->flags); __set_bit(NETFS_SREQ_IN_PROGRESS, &subreq->flags); netfs_stat(&netfs_n_rh_retry_read_subreq); @@ -242,8 +243,7 @@ static void netfs_retry_read_subrequests(struct netfs_i= o_request *rreq) subreq =3D list_next_entry(subreq, rreq_link); abandon: list_for_each_entry_from(subreq, &stream->subrequests, rreq_link) { - if (!subreq->error && - !test_bit(NETFS_SREQ_FAILED, &subreq->flags) && + if (!test_bit(NETFS_SREQ_FAILED, &subreq->flags) && !test_bit(NETFS_SREQ_NEED_RETRY, &subreq->flags)) continue; subreq->error =3D -ENOMEM; diff --git a/fs/netfs/write_collect.c b/fs/netfs/write_collect.c index cbf3d9194c7bf..61eab34ea67ef 100644 --- a/fs/netfs/write_collect.c +++ b/fs/netfs/write_collect.c @@ -492,11 +492,11 @@ void netfs_write_subrequest_terminated(void *_op, ssi= ze_t transferred_or_error) =20 if (IS_ERR_VALUE(transferred_or_error)) { subreq->error =3D transferred_or_error; - if (subreq->error =3D=3D -EAGAIN) - set_bit(NETFS_SREQ_NEED_RETRY, &subreq->flags); - else + /* if need retry is set, error should not matter */ + if (!test_bit(NETFS_SREQ_NEED_RETRY, &subreq->flags)) { set_bit(NETFS_SREQ_FAILED, &subreq->flags); - trace_netfs_failure(wreq, subreq, transferred_or_error, netfs_fail_write= ); + trace_netfs_failure(wreq, subreq, transferred_or_error, netfs_fail_writ= e); + } =20 switch (subreq->source) { case NETFS_WRITE_TO_CACHE: diff --git a/fs/netfs/write_issue.c b/fs/netfs/write_issue.c index dd8743bc8d7fe..34894da5a23ec 100644 --- a/fs/netfs/write_issue.c +++ b/fs/netfs/write_issue.c @@ -250,6 +250,7 @@ void netfs_reissue_write(struct netfs_io_stream *stream, iov_iter_truncate(&subreq->io_iter, size); =20 subreq->retry_count++; + subreq->error =3D 0; __clear_bit(NETFS_SREQ_MADE_PROGRESS, &subreq->flags); __set_bit(NETFS_SREQ_IN_PROGRESS, &subreq->flags); netfs_stat(&netfs_n_wh_retry_write_subreq); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 62472481A89; Sat, 28 Feb 2026 17:34:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300041; cv=none; b=UDSZa0v5hRB7Rt34fh/rFS7F7ozPv7yQNvrcL3aRjeRJeqTXROBxrrnyG6omT4Hm0o6XKpMTabIuVj1bAOFzFc/tms0HkL++wc1+foyR6V0ELbeG5Q78OSgll/y0wIhZIIKW5FQmiOUIsqHQbhFW1LHsBD4WjQ30TagVIaBp4Yk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300041; c=relaxed/simple; bh=Lo+ZeyzO3oAro0iucUjc9K+Xe8giSkt3BfgizsfWyJM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hbkkKcn+01PkzcDftKHH4wyg47OiXd7cXvuFfUVhZFhYchBZJUa3YZ5kFAKA81546fw94JPc3bNiwbVBrT2vABr1knzul2f4tV36KgMXgt6BgGCK3O+SSxtxWD8p4kggPGDNPg4Tzs9IsKnLzavozBrY3GWXlPd++4R6TZ2guwo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WvjKgoLA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WvjKgoLA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF8C6C19423; Sat, 28 Feb 2026 17:34:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300041; bh=Lo+ZeyzO3oAro0iucUjc9K+Xe8giSkt3BfgizsfWyJM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WvjKgoLAxwOOcQuGVSYGf9RBwUcA7fd5fTLIkZ5/K9vUqZRIzeNp86aNdOtrhMC1x iW+rfHIOGgwWmneJKqEaBIhbakrT8ew0EWs+PVZWRDn5ZzVvUSGIaprR3mUvzCSdX8 7VplhNPglOwgGHug2FYdgwDewRrmf3KPwchOme2wwz8Up700UKi+zKKAmk5urHQ6IC 4rqbD+IRgyomypoeEt7XufXRn06htZwWTpSAWKx6EfllkQEo2RxAn4Lt7op1NeWBD/ /XkejJCklG8Uc2fsgLG4+KBbD73e3UPzJgK6ZFsalo1URCcpH7dlTzWQoo0z47s06R NUngUjS4rWwrg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Henrique Carvalho , Steve French , Sasha Levin Subject: [PATCH 6.19 053/844] smb: client: add proper locking around ses->iface_last_update Date: Sat, 28 Feb 2026 12:19:26 -0500 Message-ID: <20260228173244.1509663-54-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Henrique Carvalho [ Upstream commit e97dcac3dc0bd37e4b56aaa6874b572a3a461102 ] There is a missing ses->iface_lock in cifs_setup_session, around ses->iface_last_update. Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/smb/client/connect.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/smb/client/connect.c b/fs/smb/client/connect.c index ce620503e9f70..60c76375f0f50 100644 --- a/fs/smb/client/connect.c +++ b/fs/smb/client/connect.c @@ -4270,7 +4270,9 @@ cifs_setup_session(const unsigned int xid, struct cif= s_ses *ses, ses->ses_status =3D SES_IN_SETUP; =20 /* force iface_list refresh */ + spin_lock(&ses->iface_lock); ses->iface_last_update =3D 0; + spin_unlock(&ses->iface_lock); } spin_unlock(&ses->ses_lock); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2947E481AA0; Sat, 28 Feb 2026 17:34:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300042; cv=none; b=FyjyyXjUsJ04D4yELF3SBxAIrNZFPHHjTKTboBC2DMM4F/74TrZvHmzQUu85iKMrvzhTNQdo7mkAcONq9BFMp2EV16SxAzeFlyS+P08OLNnWODO+dABaK1cWBi524pH3JPm5HXw88uy1avNpJVZ7JXQv+yK+11YlbMDwgWvoX64= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300042; c=relaxed/simple; bh=WQb3T0/L1+8anuTwixTyTOgkjYPaAbTKREJMPMmfGzc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X2bHgNjBzOGKD1YwSuvfzNW8/0xUA9CR9gC9+ZfAEK/KvUODAft3mzn56LuC9ahQrEdCHLq9H4/AFSe/wykIoiyHd/qH7xds0VuXQ4mpqdoXZ1trmzwxlaqEFn1lTLRuIHfy3wAi5yXHOHOsciWp+vKKLU6wkE0PSgvYmuQYwkU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BAdVC39m; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BAdVC39m" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A70CC4AF09; Sat, 28 Feb 2026 17:34:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300042; bh=WQb3T0/L1+8anuTwixTyTOgkjYPaAbTKREJMPMmfGzc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BAdVC39mG+vnRYTJ0VEeRuWaIuXZb3DVzG4EEFCIttf6rQqoIXCFway8XK6KoH2MR yaQ72p+18VB84bMtUG4cu0c5nuP+aJf7MXgq/YDq5QnuLdTraj2pMrUGvCUcGBNwNi 08MbKP/ut45CcuSw4co6It+iRk4OdHO/sVaAdvMBYHlokhgRnhUCRZ0WghdaNYuFOx BjNFwDCL/DU5DhBbBAZtZ134S8WNRbLZCsjorytVRdlXygAsUlEtbniNrOgvUEBKwn GF3EJqQQj54GRwr4WYqpuSj24fcJ8956VsnrZ61/jR7o3jQrDGPk3Q4K+xLPpPU2B/ vh+5ZCNb61mmQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andreas Gruenbacher , Sasha Levin Subject: [PATCH 6.19 054/844] gfs2: fiemap page fault fix Date: Sat, 28 Feb 2026 12:19:27 -0500 Message-ID: <20260228173244.1509663-55-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andreas Gruenbacher [ Upstream commit e411d74cc5ba290f85d0dd5e4d1df8f1d6d975d2 ] In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/gfs2/inode.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c index b6ed069b34872..4d65e4a752626 100644 --- a/fs/gfs2/inode.c +++ b/fs/gfs2/inode.c @@ -2192,6 +2192,14 @@ static int gfs2_getattr(struct mnt_idmap *idmap, return 0; } =20 +static bool fault_in_fiemap(struct fiemap_extent_info *fi) +{ + struct fiemap_extent __user *dest =3D fi->fi_extents_start; + size_t size =3D sizeof(*dest) * fi->fi_extents_max; + + return fault_in_safe_writeable((char __user *)dest, size) =3D=3D 0; +} + static int gfs2_fiemap(struct inode *inode, struct fiemap_extent_info *fie= info, u64 start, u64 len) { @@ -2201,14 +2209,22 @@ static int gfs2_fiemap(struct inode *inode, struct = fiemap_extent_info *fieinfo, =20 inode_lock_shared(inode); =20 +retry: ret =3D gfs2_glock_nq_init(ip->i_gl, LM_ST_SHARED, 0, &gh); if (ret) goto out; =20 + pagefault_disable(); ret =3D iomap_fiemap(inode, fieinfo, start, len, &gfs2_iomap_ops); + pagefault_enable(); =20 gfs2_glock_dq_uninit(&gh); =20 + if (ret =3D=3D -EFAULT && fault_in_fiemap(fieinfo)) { + fieinfo->fi_extents_mapped =3D 0; + goto retry; + } + out: inode_unlock_shared(inode); return ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 039F1481FA0; Sat, 28 Feb 2026 17:34:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300043; cv=none; b=AHeTr7epQOuRHl4w2F47Z3gu1b7OjvndOgv2GzNjhA82Q1Ke/B59MYq0/nNtzKlLk8Kgjmyzs+m8hF9tgv5ENx+CpT5q6c3138FTD4Hfw7BVkDVMe/SYCGlAeISchbtpfvuNwH1OJUsq4Zrhwzy8ZWCXYe0CAHT+1lJxcoc+3Uo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300043; c=relaxed/simple; bh=rCtsUBhmHVt+naUikG3iEK7KYnS6aBRu7BnLeOQdy9c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MIGA0iK+SkId/4Z7KdPL4jsRpCsviAX4+Y8YtQXroFGKfTig6UJcL6mu7IpIiCFcU5TcGEdAiYfKGKxOTO19zQXAh1U9hKSXAFtfHQu5EmbBAQiqW3A9ZroWT0VijaaUdhYp02z4EuMlg75IAjjZkcEknc1b5IBEAD6uQoZxhuQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XpgSVuXv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XpgSVuXv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 503BAC19423; Sat, 28 Feb 2026 17:34:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300042; bh=rCtsUBhmHVt+naUikG3iEK7KYnS6aBRu7BnLeOQdy9c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XpgSVuXvN+MUERPW0BPaYOtOv7yB26HHeC63w4RURfH1ooTsYVq99tRYcE389GI8K B3ZXTHynhIQg0YOJGwLm9RXzcoGV73yHAWZcPM+X+dADVGKO2OduHF/JZOntTi8v83 cO4W7+38ZuIjqX9dmkka17mmnC9yzvtdYZmMbTkI5SjOFHY0KP2qQn2GQFPExqKJKi EjkQU0xu05QSoZ3iI105hy6pPqNBTRV9ztGBs1kVO5ViGSbld9d60QotZ9BfH694OW Iy922BAFFZewKwBrrvtNcwSc4+y3T/cQR3cIZvVPrSTUXBC1Cv53tskeRr1U1KnTr3 7uWdsHLKFmQtg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Henrique Carvalho , Steve French , Sasha Levin Subject: [PATCH 6.19 055/844] smb: client: prevent races in ->query_interfaces() Date: Sat, 28 Feb 2026 12:19:28 -0500 Message-ID: <20260228173244.1509663-56-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Henrique Carvalho [ Upstream commit c3c06e42e1527716c54f3ad2ced6a034b5f3a489 ] It was possible for two query interface works to be concurrently trying to update the interfaces. Prevent this by checking and updating iface_last_update under iface_lock. Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/smb/client/smb2ops.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index c1aaf77e187b6..edfd6a4e87e8b 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -637,13 +637,6 @@ parse_server_interfaces(struct network_interface_info_= ioctl_rsp *buf, p =3D buf; =20 spin_lock(&ses->iface_lock); - /* do not query too frequently, this time with lock held */ - if (ses->iface_last_update && - time_before(jiffies, ses->iface_last_update + - (SMB_INTERFACE_POLL_INTERVAL * HZ))) { - spin_unlock(&ses->iface_lock); - return 0; - } =20 /* * Go through iface_list and mark them as inactive @@ -666,7 +659,6 @@ parse_server_interfaces(struct network_interface_info_i= octl_rsp *buf, "Empty network interface list returned by server %s\n", ses->server->hostname); rc =3D -EOPNOTSUPP; - ses->iface_last_update =3D jiffies; goto out; } =20 @@ -795,8 +787,6 @@ parse_server_interfaces(struct network_interface_info_i= octl_rsp *buf, + sizeof(p->Next) && p->Next)) cifs_dbg(VFS, "%s: incomplete interface info\n", __func__); =20 - ses->iface_last_update =3D jiffies; - out: /* * Go through the list again and put the inactive entries @@ -825,10 +815,17 @@ SMB3_request_interfaces(const unsigned int xid, struc= t cifs_tcon *tcon, bool in_ struct TCP_Server_Info *pserver; =20 /* do not query too frequently */ + spin_lock(&ses->iface_lock); if (ses->iface_last_update && time_before(jiffies, ses->iface_last_update + - (SMB_INTERFACE_POLL_INTERVAL * HZ))) + (SMB_INTERFACE_POLL_INTERVAL * HZ))) { + spin_unlock(&ses->iface_lock); return 0; + } + + ses->iface_last_update =3D jiffies; + + spin_unlock(&ses->iface_lock); =20 rc =3D SMB2_ioctl(xid, tcon, NO_FILE_ID, NO_FILE_ID, FSCTL_QUERY_NETWORK_INTERFACE_INFO, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D1458481FB8; Sat, 28 Feb 2026 17:34:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300043; cv=none; b=KllUHieYFtQdNlgwQTGPEBbC+AndSncOYQKGM6bPP2ZBXa4qdqcUqvXDpzla2+92CV5alCYcPpJhvash+ZgXTQ1gmG1GpSAV5xTuW/gKzdq2/HM/zaXkMJiEyDkL+bvPHv8xrYMToe3s+BIAZZoX4VGLrvls1A+WfcYNOb85z/g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300043; c=relaxed/simple; bh=7vVPGALmuNeLk8yGU4KurhELNTDP0geSF1U6fTA/0yY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UR16s5sVoFnwbRJtCypHgTP5MgtaocV3lmmFENc5QgrAO5Thhlb6PmU51dRKIVJX/xVcTWkdMfYDbI2dMtfZYLlCF3xdqLJuMHrUL05+2BRqZI74+DIn3NUOCtZPtcGVs8fn0fS9NGw6iyYhXcCS0urF6lsVpohMbD36SUXTfoQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LCq0tulH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LCq0tulH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27FAEC19423; Sat, 28 Feb 2026 17:34:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300043; bh=7vVPGALmuNeLk8yGU4KurhELNTDP0geSF1U6fTA/0yY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LCq0tulHXpFfScEQZ87Mn6mK52UoTXyTTTJO+zm8UKdXqc0mUN19jb8GdJKm9brh0 w2rwUMpQGXaNTZyD8o9GcvcI4dNSWBgWWUJXJ8TMh0c7JbM6UO40aYWGWHJKHCJJAX AA7ynm/1jVn7yTmtDtNda+N3V3pw0BUjqIvNgr+JXRBjlOMK6VGVNHvUZBpD5cr/V3 KMVCIz6sLHVnA8K7SEReQEdM5Dqnh0RCdIYaexauzxc5TyKDLSstf6IQxZz5sT6B28 Iy4uMYiS/KKxvfz0/VZ31CoPg3o/KsBswQHIJAClbur+MU/d3db9Mtg4ECR1QlhEV0 s8ChhJsGLu89A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kaushlendra Kumar , Shuah Khan , Sasha Levin Subject: [PATCH 6.19 056/844] tools/cpupower: Fix inverted APERF capability check Date: Sat, 28 Feb 2026 12:19:29 -0500 Message-ID: <20260228173244.1509663-57-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kaushlendra Kumar [ Upstream commit 24858a84163c8d04827166b3bcaed80612bb62fc ] The capability check was inverted, causing the function to return error when APERF support is available and proceed when it is not. Negate the condition to return error only when APERF capability is absent. Link: https://lore.kernel.org/r/20251126091613.567480-1-kaushlendra.kumar@i= ntel.com Signed-off-by: Kaushlendra Kumar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/power/cpupower/utils/cpufreq-info.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/power/cpupower/utils/cpufreq-info.c b/tools/power/cpupow= er/utils/cpufreq-info.c index 7d3732f5f2f6f..5fe01e516817e 100644 --- a/tools/power/cpupower/utils/cpufreq-info.c +++ b/tools/power/cpupower/utils/cpufreq-info.c @@ -270,7 +270,7 @@ static int get_freq_hardware(unsigned int cpu, unsigned= int human) { unsigned long freq; =20 - if (cpupower_cpu_info.caps & CPUPOWER_CAP_APERF) + if (!(cpupower_cpu_info.caps & CPUPOWER_CAP_APERF)) return -EINVAL; =20 freq =3D cpufreq_get_freq_hardware(cpu); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5206481AA0; Sat, 28 Feb 2026 17:34:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300044; cv=none; b=U8y92fwEScfrHPWyrS43Aw6PJkeX1/s69Zm5Lh2i2lTHXUMjXCpPQdq8e5R+vA8103XcFZtFNrZxvtN26kBBcq4Cek/sKzXDb8BeC3VE8MsHRpEN4/Q3xY6XcFhRB17I38Kf94z8IzUrzc9r3PW1leOy1Gtsst6W9+gR2cZEyjw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300044; c=relaxed/simple; bh=l//FoZgeTK71MhpWblD6GoSpBOiJdL79uAa8VL6fHKY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZsVEE6j+16kOeVyq9cmRzbZYyfleBzMww12P0eMcXywk1LeNDLMo+abKrLBM45BtVGlxL5V6tY7mXgggmNZyn0WJ4yl85M2YA/MpgH5wdIuDFUtXKEvQaS4eZP1vzjYOF/EkLnftlga3MjSnNVxPda87WOX+vHvX/R+C+1dzDWo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rsXssFFn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rsXssFFn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0411AC19423; Sat, 28 Feb 2026 17:34:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300044; bh=l//FoZgeTK71MhpWblD6GoSpBOiJdL79uAa8VL6fHKY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rsXssFFnSnBONs2g7P2yqO743SULqKM9fo0oNHGPLX3qBCXEmOGe/CBiyFNZa0T+S aGkPEHov1CDHvVV8tN2tqPpOXxZdl0ZStSJ1XKR84YFRp+WkpxHFcAp0Dqq8ZmeCy1 IO18HtXB4qmSG6VTDoLHaobNW2PbqaBqsdIrovDHHrKklrYDxT2n4am/zW+LlAQS8g 2SBQYQ+LB7YdshudcjUt6oB3LPt2mfLfYJy18jAKCC1HKobTBy7/3wJNXkC9BleHxq iuw+vSrqMPbI16DC7exiPuoCxBAQLV7lkh8YjNRN3T8aozbs3cRFFdHHealu8dz2Qr o0omNFTxsUtYQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Heiko Carstens , Sasha Levin Subject: [PATCH 6.19 057/844] s390/boot: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS Date: Sat, 28 Feb 2026 12:19:30 -0500 Message-ID: <20260228173244.1509663-58-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Heiko Carstens [ Upstream commit 5ba35a6c13fff0929c34aba6b7602dacbe68686c ] Add -Wno-default-const-init-unsafe to boot KBUILD_CFLAGS, similar to scripts/Makefile.extrawarn, since clang generates warnings for the dummy variable in typecheck(): CC arch/s390/boot/version.o arch/s390/include/asm/ptrace.h:221:9: warning: default initialization= of an object of type 'typeof (regs->psw)' (aka 'const psw_t') leaves the o= bject uninitialized [-Wdefault-const-init-var-unsafe] 221 | return psw_bits(regs->psw).pstate; | ^ arch/s390/include/asm/ptrace.h:98:2: note: expanded from macro 'psw_b= its' 98 | typecheck(psw_t, __psw); \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/s390/boot/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/s390/boot/Makefile b/arch/s390/boot/Makefile index 490167faba7a4..a1e719a79d38c 100644 --- a/arch/s390/boot/Makefile +++ b/arch/s390/boot/Makefile @@ -21,6 +21,7 @@ KBUILD_AFLAGS :=3D $(filter-out $(CC_FLAGS_MARCH),$(KBUIL= D_AFLAGS_DECOMPRESSOR)) KBUILD_CFLAGS :=3D $(filter-out $(CC_FLAGS_MARCH),$(KBUILD_CFLAGS_DECOMPRE= SSOR)) KBUILD_AFLAGS +=3D $(CC_FLAGS_MARCH_MINIMUM) -D__DISABLE_EXPORTS KBUILD_CFLAGS +=3D $(CC_FLAGS_MARCH_MINIMUM) -D__DISABLE_EXPORTS +KBUILD_CFLAGS +=3D $(call cc-option, -Wno-default-const-init-unsafe) =20 CFLAGS_sclp_early_core.o +=3D -I$(srctree)/drivers/s390/char =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 77C8C48A2A4; Sat, 28 Feb 2026 17:34:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300045; cv=none; b=hFL9oXZW+UdQjIKSJ9ItB3hry6VO/PBP2kHJ9cmxuEmMZ35pt9kQKnn72lHdJNH0Dastz5t3t2tRcV7XGyudvVbNH69xFO/LrAnYUOn2kQQ+KUPqYyAFoOnepMmLh5+AWBXQ13K8c35/Ee0wfBpjRief3Y3JstenECJg5Ck92qY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300045; c=relaxed/simple; bh=ANDSCPHjokIvXexJoyEmdLJh4bwF/OZdktQa/MDY09o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f8duuelZknw/FNOF/VFirDs9+Tkx01WBaKUS3pA54bFduVEwRMB/VVwBAAs4W0Qg75l14ozI5x3t3FZrKPp8BezZQov7F0IKAyVkpIAP3xAHyJNhmjmY7DUHedLcF6PUm8fCJn5jrgQSMaTc7VVJU8xpcrU4a+rbEergq1t7k/4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s/ECMo8Y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s/ECMo8Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C14EBC2BCB1; Sat, 28 Feb 2026 17:34:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300045; bh=ANDSCPHjokIvXexJoyEmdLJh4bwF/OZdktQa/MDY09o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s/ECMo8YVhM/ApM505rgK3WiCek+A+yyboxYdo72pbK08aUEyzh7U+1WUTEjV+pAe XNxNunKgIEWR90M8wC1qKr/vWb8D0SOXURcue9/XwLb1t+0jP8betzMr2eshBW6edr adaO3o75l/NWZqASC3GjaWys0jzpvlMsnPVQ/+xXYVfO9gRelRwVfltLQqteW4XZg1 7XNNINvmPY2Uh+r5+ajn3xf2gFtvigc4d74LWVb5UGqPJf62eY1pzs/Rtteq7xGl7Y uvKwv2gL43KwR/OIgs1td2OEgEa/5zfvwWNJzTXRnBa1MOtCzG7X4pKYAf+oHdIPMD XBX1xOPIpp64Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kaushlendra Kumar , Shuah Khan , Sasha Levin Subject: [PATCH 6.19 058/844] tools/power cpupower: Reset errno before strtoull() Date: Sat, 28 Feb 2026 12:19:31 -0500 Message-ID: <20260228173244.1509663-59-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kaushlendra Kumar [ Upstream commit f9bd3762cf1bd0c2465f2e6121b340883471d1bf ] cpuidle_state_get_one_value() never cleared errno before calling strtoull(), so a prior ERANGE caused every cpuidle counter read to return zero. Reset errno to 0 before the conversion so each sysfs read is evaluated independently. Link: https://lore.kernel.org/r/20251201121745.3776703-1-kaushlendra.kumar@= intel.com Signed-off-by: Kaushlendra Kumar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/power/cpupower/lib/cpuidle.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/power/cpupower/lib/cpuidle.c b/tools/power/cpupower/lib/= cpuidle.c index f2c1139adf716..bd857ee7541a7 100644 --- a/tools/power/cpupower/lib/cpuidle.c +++ b/tools/power/cpupower/lib/cpuidle.c @@ -150,6 +150,7 @@ unsigned long long cpuidle_state_get_one_value(unsigned= int cpu, if (len =3D=3D 0) return 0; =20 + errno =3D 0; value =3D strtoull(linebuf, &endp, 0); =20 if (endp =3D=3D linebuf || errno =3D=3D ERANGE) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3FC6448A2BB; Sat, 28 Feb 2026 17:34:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300046; cv=none; b=r21IyAYwtwa8018vAwxM5ES7Avt9HnZzBqo5cfqbyLcz80ZHnuNa+qijQQ00sCHGWAqjQS+Ci9G9OcFI72tLQT1Pq2d5oRl+sp7hsuPjxbmvQOAyRzD8fMMYQYN2I0j88K6Qb9n6nttXMgW2AVHHyYytF4lLecfJ9/CLl6DUDPE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300046; c=relaxed/simple; bh=Z4QxMGUMs+yL5pkf3AhedAWqGSrzajzhBO6RxS9IArk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jncoO1zNRPmDP/iU7Mf4pScX1YAw5n45Xjukl5B5Uo0D0yhsM92fhR58j9R95F8DPpiyDqs+76n923tifAnPgw+N+DxmjXli9FNl44GO2sIymogaYhRYMAjma9ICYix9d+8P5MkSVZReRYjeNtHkyc3EtZ7m72aUeIccfwhIC1o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ejiMAbtE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ejiMAbtE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9FD41C116D0; Sat, 28 Feb 2026 17:34:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300046; bh=Z4QxMGUMs+yL5pkf3AhedAWqGSrzajzhBO6RxS9IArk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ejiMAbtEdmtoTY05xrfQuEaCe10SvdXbxScdN92stW0IpLUauglHA16jGAw5mkz4i zoB6VV/YvR9/izODsMFFmMM5/zQPXiw6ic3L8Cxs/ujGaBMAor+HgF6iTKSruwzM61 pQ1AH1qDHXMrA2hbAOWdtUYXprDUNKtUvRqOdUy8n26aK0PbySCROGSyCCUtbwvaP4 vukR9yZqqqvgYh+XUrMU/T4z9FqOtc2PsRsiAt2974tLNJt910KqaBWnc40O+a4z5b aFC+cuqleIuUHLfRAbIH37toSlWgUt7pMzNNjwrjLgLVBAk2EraGRP5rdAgNwi/9H0 xgxL7ORwt6tOg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Heiko Carstens , Sasha Levin Subject: [PATCH 6.19 059/844] s390/purgatory: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS Date: Sat, 28 Feb 2026 12:19:32 -0500 Message-ID: <20260228173244.1509663-60-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Heiko Carstens [ Upstream commit b4780fe4ddf04b51127a33d705f4a2e224df00fa ] Add -Wno-default-const-init-unsafe to purgatory KBUILD_CFLAGS, similar to scripts/Makefile.extrawarn, since clang generates warnings for the dummy variable in typecheck(): CC arch/s390/purgatory/purgatory.o arch/s390/include/asm/ptrace.h:221:9: warning: default initialization= of an object of type 'typeof (regs->psw)' (aka 'const psw_t') leaves the o= bject uninitialized [-Wdefault-const-init-var-unsafe] 221 | return psw_bits(regs->psw).pstate; | ^ arch/s390/include/asm/ptrace.h:98:2: note: expanded from macro 'psw_b= its' 98 | typecheck(psw_t, __psw); \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/s390/purgatory/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/s390/purgatory/Makefile b/arch/s390/purgatory/Makefile index 0c196a5b194af..61d240a37633d 100644 --- a/arch/s390/purgatory/Makefile +++ b/arch/s390/purgatory/Makefile @@ -23,6 +23,7 @@ KBUILD_CFLAGS +=3D -D__DISABLE_EXPORTS KBUILD_CFLAGS +=3D $(CLANG_FLAGS) KBUILD_CFLAGS +=3D $(if $(CONFIG_CC_IS_CLANG),-Wno-microsoft-anon-tag) KBUILD_CFLAGS +=3D $(call cc-option,-fno-PIE) +KBUILD_CFLAGS +=3D $(call cc-option, -Wno-default-const-init-unsafe) KBUILD_AFLAGS :=3D $(filter-out -DCC_USING_EXPOLINE,$(KBUILD_AFLAGS)) KBUILD_AFLAGS +=3D -D__DISABLE_EXPORTS =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C4B248A2DD; Sat, 28 Feb 2026 17:34:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300047; cv=none; b=NweG3qFYNWuGh71fztdzsZbKwpORimng1+5bFgsqyAD2T0UXJH7VFOfXWjD3jiqpshDiwnpJRtzq6Pq2E3SECSJmZAkKAexObXTiUryMDf/NWxuvGE3kNdW7/Q0vR1KgW9hoKYFpL3tEN8kEZ0RoNjJ9Sg4FNKxZnk1gSPYe684= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300047; c=relaxed/simple; bh=ac4WStoxKfAasctsVBfwXUUhvWrA9GNM2xoK62d7wz8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JPlWbtSa8pRUj6PAl/ZSQwp1e56S9ZELbK2X+wykT/F3OYoWbfYzil/t7ntxU50QqfEnIgpbBoks9ouexT/klePX0nEtaizj0U8FlboYif9/38iN4bsmnDQvOa7spRUlvs4eo2F2Nmc+cDy2nwwFRLZc7BKZWMXt0sD3ssPVwOg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=etAsrVsw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="etAsrVsw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67F01C19425; Sat, 28 Feb 2026 17:34:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300047; bh=ac4WStoxKfAasctsVBfwXUUhvWrA9GNM2xoK62d7wz8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=etAsrVswaz6sxnAsvJhjEKT+Xhb/CyFizisBl4ltXFfmju7qSx3MC/GIIttzzSU9n Z1Lm4tCOlRt2QqZ/f8iOYdz3a7souLfjxedVugJMwk19dpQk+F3eejQMgHn8EF4wy8 Tlqn4+cxNcSjicy+v+iL8U03jO4FDk8QQ5kSG3d7BpWGsP9OBNJtcHJ9uFTOE+sFEF gZJdWyGNKX/wtCOS/5bDjgblZgwQ2n6gwkSu5n6Qc0iYAjLk1dTTQGV1AN3QBFxpnm zAT6hHUdvxm/oRTx4k8aUpCx1ybbqVm0Mg/FnIf37/6j859POqMF61ccnP8u0AzyoF 0OKLPlUoR/KsA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Robin Murphy , Ilkka Koskinen , Michal Simek , Will Deacon , Sasha Levin Subject: [PATCH 6.19 060/844] perf/arm-cmn: Support CMN-600AE Date: Sat, 28 Feb 2026 12:19:33 -0500 Message-ID: <20260228173244.1509663-61-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Robin Murphy [ Upstream commit 12a94953c37e834c3eabb839ce057094946fe67a ] The functional safety features of CMN-600AE have little to no impact on the PMU relative to the base CMN-600 design, so for simplicity we can reasonably just treat it as the same thing. The only obvious difference is that the revision numbers aren't aligned, so we may hide some aliases for events which do actually exist, but those can still be specified via the underlying "type,eventid" format so it's not too big a deal. Signed-off-by: Robin Murphy Reviewed-by: Ilkka Koskinen Tested-by: Michal Simek Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/perf/arm-cmn.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c index 23245352a3fc0..651edd73bfcb1 100644 --- a/drivers/perf/arm-cmn.c +++ b/drivers/perf/arm-cmn.c @@ -210,6 +210,7 @@ enum cmn_model { enum cmn_part { PART_CMN600 =3D 0x434, PART_CMN650 =3D 0x436, + PART_CMN600AE =3D 0x438, PART_CMN700 =3D 0x43c, PART_CI700 =3D 0x43a, PART_CMN_S3 =3D 0x43e, @@ -2266,6 +2267,9 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsi= gned int rgn_offset) reg =3D readq_relaxed(cfg_region + CMN_CFGM_PERIPH_ID_01); part =3D FIELD_GET(CMN_CFGM_PID0_PART_0, reg); part |=3D FIELD_GET(CMN_CFGM_PID1_PART_1, reg) << 8; + /* 600AE is close enough that it's not really worth more complexity */ + if (part =3D=3D PART_CMN600AE) + part =3D PART_CMN600; if (cmn->part && cmn->part !=3D part) dev_warn(cmn->dev, "Firmware binding mismatch: expected part number 0x%x, found 0x%x\n", --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41E4A48AE16; Sat, 28 Feb 2026 17:34:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300048; cv=none; b=N5a7eskoP58HtylJA71BeEXpPho/5figJn+3AsxSo9e3kAtSgoeGLggGN20vuf+HEmNE4ImYNm2yTJU8Fi09gkXkSMWc9jpt7x7wGVt5Mfvvc12nELNuKUN6aeD8dK3w6w8lDrdx3bGXWbUr5PrVpZxBlzPb/9fI+68Vn6BXDUM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300048; c=relaxed/simple; bh=eZhw+wdg5qva2KkhBd421DUYgq7bIAGOMWDp7kXJ3IA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=m3WcVNT7cMIsA0t0dV9C41zSIKVR6b/W3C+EWNwW6bCsGUDrBxrHSigjXmdEa+iR7LRkXrqpeTkX5yho+qu4fEOyo/H4xhzVBoFCiW9oPQToHO5PH91tEuFQMCnikQZ1XRFTSGD9ZwlpeXQm99VECyM6Vp0DC/mxaYHVLV0PJAU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=J+8cx1uI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="J+8cx1uI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76FC7C19423; Sat, 28 Feb 2026 17:34:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300048; bh=eZhw+wdg5qva2KkhBd421DUYgq7bIAGOMWDp7kXJ3IA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=J+8cx1uIraUM17nEZce3DjP6eexzwvjKUkf1YUM900I3466FrEXWdp3g5IW8gr3NP SJCgcKADI3/OWdLaeVdt4A7PV00CuwV25eGcTPB7thFrvwmS383ey5K+ofiefo2c+S VK/+uhDgJCUxDgbePQf6IiH1f3ST1wpwEc6r/KQeB9zBrXG4HhjxPETtcMv/76wvGs ZgORqXJcK/NDJP+Q1dlwUCLOkeSWUwpzd158KF/7ef/NtAjNdrF404PsJjkUMEUx/U l+OgAtIgVMt5zYfOj8WPYbxIY/0gEK5SCyPgQvUHA4b5AfoMCkvSI30JL28a2tA98c VSSM+rrAKJAEw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jinqian Yang , Zenghui Yu , Will Deacon , Sasha Levin Subject: [PATCH 6.19 061/844] arm64: Add support for TSV110 Spectre-BHB mitigation Date: Sat, 28 Feb 2026 12:19:34 -0500 Message-ID: <20260228173244.1509663-62-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jinqian Yang [ Upstream commit e3baa5d4b361276efeb87b20d8beced451a7dbd5 ] The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation. Signed-off-by: Jinqian Yang Reviewed-by: Zenghui Yu Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/kernel/proton-pack.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pac= k.c index 80a580e019c50..b3801f532b10b 100644 --- a/arch/arm64/kernel/proton-pack.c +++ b/arch/arm64/kernel/proton-pack.c @@ -887,6 +887,7 @@ static u8 spectre_bhb_loop_affected(void) MIDR_ALL_VERSIONS(MIDR_CORTEX_X2), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1), + MIDR_ALL_VERSIONS(MIDR_HISI_TSV110), {}, }; static const struct midr_range spectre_bhb_k24_list[] =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 490C648AE2F; Sat, 28 Feb 2026 17:34:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300049; cv=none; b=jdX5EPE2ses1tjg1OLBU60B+bNCmi36Ky3uFAbou6KruYfdXvp8x+vPoN9ItukoDX9UeA6uIAT0DuN27U2fBc8+B7BYQuuzL+lhtdKT/8/yW+tYINTf4uygsGaj0q2qnJfH4EiJ2ODRDrY2ZEBbMjlcD7KqYOwaSe2/jxVFlfZk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300049; c=relaxed/simple; bh=WbOc48pJBDDfUlPeP7anR7Ynv05Vmmb383+6hK4/yFY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VTxtww2j9oHzLZrH35iJhKx8JKir34tfiMUAB8CDJTei18zXEkEDEhzkoTHVRz6YxgcTgT22fUG8NBeM1egD7VXoD1JPFKUTDjSLp17pl/nD3Tj3RTcILJqiPdzSVe1YeXORAhlDdjJ3nxRprky8m5AGyoQ+uqBEDgCOd36JsSU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RCBxTsdC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RCBxTsdC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6ACCCC19424; Sat, 28 Feb 2026 17:34:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300049; bh=WbOc48pJBDDfUlPeP7anR7Ynv05Vmmb383+6hK4/yFY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RCBxTsdCRwysuESwwwM+p1pgjRIN9f8DQiCs3w2JYn45hwDL8X7JubkxkNv8RY58Q aE+uGnXFISfSgq7cHekrIMs/lrzOqZ8JyVhikTNe6PvMiVtRpRzDjxN0IWGsWAuSWp tgSlTCujKoMMA2DaoAY4QdEfeGVtr+tUg24aKW2AjGZWoPwp2tcHWohriUaSstFdlu UqJQ9HZIho5ftrpbdODjgvaIHoc9VpreMIQN0Bmx5FSkD4skVhcKIQONtNJDD8nri2 ju3d96OeaJ1cfOt9zOv/ffQHRBrPj0kzHHVlCTUawtZuJ8tQYc9UvvwdWWXDHCJlBz 8xqh4KiKKHsLQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Md Haris Iqbal , Jack Wang , Grzegorz Prajsner , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 062/844] rnbd-srv: Zero the rsp buffer before using it Date: Sat, 28 Feb 2026 12:19:35 -0500 Message-ID: <20260228173244.1509663-63-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Md Haris Iqbal [ Upstream commit 69d26698e4fd44935510553809007151b2fe4db5 ] Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions. Signed-off-by: Md Haris Iqbal Signed-off-by: Jack Wang Signed-off-by: Grzegorz Prajsner Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/block/rnbd/rnbd-srv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/block/rnbd/rnbd-srv.c b/drivers/block/rnbd/rnbd-srv.c index 9b3fdc202e152..7eeb321d61402 100644 --- a/drivers/block/rnbd/rnbd-srv.c +++ b/drivers/block/rnbd/rnbd-srv.c @@ -551,6 +551,8 @@ static void rnbd_srv_fill_msg_open_rsp(struct rnbd_msg_= open_rsp *rsp, { struct block_device *bdev =3D file_bdev(sess_dev->bdev_file); =20 + memset(rsp, 0, sizeof(*rsp)); + rsp->hdr.type =3D cpu_to_le16(RNBD_MSG_OPEN_RSP); rsp->device_id =3D cpu_to_le32(sess_dev->device_id); rsp->nsectors =3D cpu_to_le64(bdev_nr_sectors(bdev)); @@ -657,6 +659,7 @@ static void process_msg_sess_info(struct rnbd_srv_sessi= on *srv_sess, =20 trace_process_msg_sess_info(srv_sess, sess_info_msg); =20 + memset(rsp, 0, sizeof(*rsp)); rsp->hdr.type =3D cpu_to_le16(RNBD_MSG_SESS_INFO_RSP); rsp->ver =3D srv_sess->ver; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A48D48AE15; Sat, 28 Feb 2026 17:34:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300050; cv=none; b=Wl9dvHzLoUa28vbeE6cpoMpAglIRw4j2Se0UVqbiv1GOOM0Agx0Qlmky+7Gpc4ORc+CynjclxDAqyBuNrmMFQqtEBJGyp04sL9NEV6+u+FoRByGrjaAltrIHkmLDcqafi5a9//DxQTJemSC92YVKiM6g3uKzAYzWCBRoLulLv/4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300050; c=relaxed/simple; bh=LXfydIHbtyS7K6xEZPDR93d+R5QphdM5i5xDyAVm46E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qhED6S7pDnmhTsBrSY2WLBVGsXfdi1tfFb5UTW9zYfTLdkPhM8Fg9we7UyuTd+vHwU623JpAfGi28YP9HCzvWTT9s5FheV7E6TUyJhawiwGOnd2vGUDsxX0lVZXQ1E1EWYaevnon35xSBCM1aFY4LWcUOb+bxVVkz/fRO+azRLc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZQ7FX2te; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZQ7FX2te" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7323CC116D0; Sat, 28 Feb 2026 17:34:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300050; bh=LXfydIHbtyS7K6xEZPDR93d+R5QphdM5i5xDyAVm46E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZQ7FX2teRFLyTfSD6AePp2UXw17Cj1FHbAlz3TmntVSsTq1eI957kJzbwXih6yRn8 T8Crvy7z/18LEI2Zkg/37W7rdyCAyyDB29fHrFWP3mw7bG00gKvkjPfk0Apk6g2qRn bW2eh1WLxHjDgyVgaf1IUXrpotXUVuqxjPOS/Y0i7KgJYEokLF2GA0gzYU0o7afWoB xi4pcKqjdXMiWLht02oZn1N+InPFxzjQfLnTBl1eLhs2UvXViWnlDyf1c5TrsdcI3j L3Pn6j5JiMVhApOr6kPBR6WZPA9jEAgFRRORioEmPyJJJL9/V3j5Ya64kUHcJ9w/EU /B4683EvEtuFQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hou Wenlong , Juergen Gross , Sasha Levin Subject: [PATCH 6.19 063/844] x86/xen/pvh: Enable PAE mode for 32-bit guest only when CONFIG_X86_PAE is set Date: Sat, 28 Feb 2026 12:19:36 -0500 Message-ID: <20260228173244.1509663-64-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hou Wenlong [ Upstream commit db9aded979b491a24871e1621cd4e8822dbca859 ] The PVH entry is available for 32-bit KVM guests, and 32-bit KVM guests do not depend on CONFIG_X86_PAE. However, mk_early_pgtbl_32() builds different pagetables depending on whether CONFIG_X86_PAE is set. Therefore, enabling PAE mode for 32-bit KVM guests without CONFIG_X86_PAE being set would result in a boot failure during CR3 loading. Signed-off-by: Hou Wenlong Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/platform/pvh/head.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S index 344030c1a81d4..53ee2d53fcf8e 100644 --- a/arch/x86/platform/pvh/head.S +++ b/arch/x86/platform/pvh/head.S @@ -91,10 +91,12 @@ SYM_CODE_START(pvh_start_xen) =20 leal rva(early_stack_end)(%ebp), %esp =20 +#if defined(CONFIG_X86_64) || defined(CONFIG_X86_PAE) /* Enable PAE mode. */ mov %cr4, %eax orl $X86_CR4_PAE, %eax mov %eax, %cr4 +#endif =20 #ifdef CONFIG_X86_64 /* Enable Long mode. */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E64B948B37D; Sat, 28 Feb 2026 17:34:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300051; cv=none; b=CeuIS5/nIywm4oTm7xXUQVaNu4/ooAp2kcvutxaxJob2/qYmHqno5iNGPmUmn3sK12dWRRVMpO02z/3VOjDA618tw6ZAK2j1UkiU/eQ9iOopaOl1bSNBONEbFFUjuAQwdA/AOagQZy3kWkykHF6gY6pHEwUZNgthjb7lFLJNEhA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300051; c=relaxed/simple; bh=SxsZQUx3dc03EUsZvghPb+/oSolQMLkg3M61Te1RedM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UNkNRYveivzaAq5zffFj3cHfkZ9eSYZIqAoxLBPw170S7EbXRbGOgBvaKEDZZ8azn8xRRy0oFOgR4fS//E2WGZ4OuFsWiO7FlisoQGPQM9st7IlZeRq3HYBtJCjGgbTxpf1DmYG49U7OZ22ApY+1uHRdBZ+K0A53FgIcBPqE5kw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lq53E0Aa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lq53E0Aa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51ADFC19423; Sat, 28 Feb 2026 17:34:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300050; bh=SxsZQUx3dc03EUsZvghPb+/oSolQMLkg3M61Te1RedM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lq53E0Aa3OVBFhTmFMVcY2SbHSdCUzfvl3b4LU0m6qOaLwMnh+GvxhAwF5LjQa2ve +PlRu8iR7B7LO2Q8tAoGnkYCd59uzucjxwCmTp2/3tDe3ZDRuS+BnGZXNSZfU4LcGO spXJ8lsr3tmfssPrtXZ3CNkK1s7dB59x9jN27pmz8uLpcP4MJbUPHlGrWEPMzrBfS1 /acu06Xvshdh0We0lYu7f1beDUhj3S9aDpxEqG8XWVLw84fM5x4e8U+HYL+PPu8ll7 DdIW0m/WdyAZq2dFfjPDX2wIqqxgo3zDdHpCuyWBvCFuRng1voPr3/S/xL9zsyk+aO mkkR3fakGht/g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Al Viro , Sasha Levin Subject: [PATCH 6.19 064/844] ntfs: ->d_compare() must not block Date: Sat, 28 Feb 2026 12:19:37 -0500 Message-ID: <20260228173244.1509663-65-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Al Viro [ Upstream commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce ] ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ntfs3/dir.c | 5 ++--- fs/ntfs3/fsntfs.c | 4 ++-- fs/ntfs3/inode.c | 13 ++++++------- fs/ntfs3/namei.c | 17 ++++++++--------- fs/ntfs3/xattr.c | 5 ++--- 5 files changed, 20 insertions(+), 24 deletions(-) diff --git a/fs/ntfs3/dir.c b/fs/ntfs3/dir.c index b98e95d6b4d99..cf038d713f507 100644 --- a/fs/ntfs3/dir.c +++ b/fs/ntfs3/dir.c @@ -423,8 +423,7 @@ static int ntfs_readdir(struct file *file, struct dir_c= ontext *ctx) if (!dir_emit_dots(file, ctx)) return 0; =20 - /* Allocate PATH_MAX bytes. */ - name =3D __getname(); + name =3D kmalloc(PATH_MAX, GFP_KERNEL); if (!name) return -ENOMEM; =20 @@ -502,7 +501,7 @@ static int ntfs_readdir(struct file *file, struct dir_c= ontext *ctx) =20 out: =20 - __putname(name); + kfree(name); put_indx_node(node); =20 if (err =3D=3D 1) { diff --git a/fs/ntfs3/fsntfs.c b/fs/ntfs3/fsntfs.c index 5f138f7158357..bd67ba7b50153 100644 --- a/fs/ntfs3/fsntfs.c +++ b/fs/ntfs3/fsntfs.c @@ -2627,7 +2627,7 @@ int ntfs_set_label(struct ntfs_sb_info *sbi, u8 *labe= l, int len) u32 uni_bytes; struct ntfs_inode *ni =3D sbi->volume.ni; /* Allocate PATH_MAX bytes. */ - struct cpu_str *uni =3D __getname(); + struct cpu_str *uni =3D kmalloc(PATH_MAX, GFP_KERNEL); =20 if (!uni) return -ENOMEM; @@ -2671,6 +2671,6 @@ int ntfs_set_label(struct ntfs_sb_info *sbi, u8 *labe= l, int len) err =3D _ni_write_inode(&ni->vfs_inode, 0); =20 out: - __putname(uni); + kfree(uni); return err; } diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c index ec8e954f4426c..bf6ef525d9562 100644 --- a/fs/ntfs3/inode.c +++ b/fs/ntfs3/inode.c @@ -1280,7 +1280,7 @@ int ntfs_create_inode(struct mnt_idmap *idmap, struct= inode *dir, fa |=3D FILE_ATTRIBUTE_READONLY; =20 /* Allocate PATH_MAX bytes. */ - new_de =3D kmem_cache_zalloc(names_cachep, GFP_KERNEL); + new_de =3D kzalloc(PATH_MAX, GFP_KERNEL); if (!new_de) { err =3D -ENOMEM; goto out1; @@ -1701,7 +1701,7 @@ int ntfs_create_inode(struct mnt_idmap *idmap, struct= inode *dir, ntfs_mark_rec_free(sbi, ino, false); =20 out2: - __putname(new_de); + kfree(new_de); kfree(rp); =20 out1: @@ -1722,7 +1722,7 @@ int ntfs_link_inode(struct inode *inode, struct dentr= y *dentry) struct NTFS_DE *de; =20 /* Allocate PATH_MAX bytes. */ - de =3D kmem_cache_zalloc(names_cachep, GFP_KERNEL); + de =3D kzalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; =20 @@ -1736,7 +1736,7 @@ int ntfs_link_inode(struct inode *inode, struct dentr= y *dentry) =20 err =3D ni_add_name(ntfs_i(d_inode(dentry->d_parent)), ni, de); out: - __putname(de); + kfree(de); return err; } =20 @@ -1759,8 +1759,7 @@ int ntfs_unlink_inode(struct inode *dir, const struct= dentry *dentry) if (ntfs_is_meta_file(sbi, ni->mi.rno)) return -EINVAL; =20 - /* Allocate PATH_MAX bytes. */ - de =3D kmem_cache_zalloc(names_cachep, GFP_KERNEL); + de =3D kzalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; =20 @@ -1796,7 +1795,7 @@ int ntfs_unlink_inode(struct inode *dir, const struct= dentry *dentry) =20 out: ni_unlock(ni); - __putname(de); + kfree(de); return err; } =20 diff --git a/fs/ntfs3/namei.c b/fs/ntfs3/namei.c index 3b24ca02de614..b2af8f695e60f 100644 --- a/fs/ntfs3/namei.c +++ b/fs/ntfs3/namei.c @@ -68,7 +68,7 @@ static struct dentry *ntfs_lookup(struct inode *dir, stru= ct dentry *dentry, u32 flags) { struct ntfs_inode *ni =3D ntfs_i(dir); - struct cpu_str *uni =3D __getname(); + struct cpu_str *uni =3D kmalloc(PATH_MAX, GFP_KERNEL); struct inode *inode; int err; =20 @@ -85,7 +85,7 @@ static struct dentry *ntfs_lookup(struct inode *dir, stru= ct dentry *dentry, inode =3D dir_search_u(dir, uni, NULL); ni_unlock(ni); } - __putname(uni); + kfree(uni); } =20 /* @@ -303,8 +303,7 @@ static int ntfs_rename(struct mnt_idmap *idmap, struct = inode *dir, return err; } =20 - /* Allocate PATH_MAX bytes. */ - de =3D __getname(); + de =3D kmalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; =20 @@ -349,7 +348,7 @@ static int ntfs_rename(struct mnt_idmap *idmap, struct = inode *dir, ni_unlock(ni); ni_unlock(dir_ni); out: - __putname(de); + kfree(de); return err; } =20 @@ -407,7 +406,7 @@ static int ntfs_d_hash(const struct dentry *dentry, str= uct qstr *name) /* * Try slow way with current upcase table */ - uni =3D kmem_cache_alloc(names_cachep, GFP_NOWAIT); + uni =3D kmalloc(PATH_MAX, GFP_NOWAIT); if (!uni) return -ENOMEM; =20 @@ -429,7 +428,7 @@ static int ntfs_d_hash(const struct dentry *dentry, str= uct qstr *name) err =3D 0; =20 out: - kmem_cache_free(names_cachep, uni); + kfree(uni); return err; } =20 @@ -468,7 +467,7 @@ static int ntfs_d_compare(const struct dentry *dentry, = unsigned int len1, * Try slow way with current upcase table */ sbi =3D dentry->d_sb->s_fs_info; - uni1 =3D __getname(); + uni1 =3D kmalloc(PATH_MAX, GFP_NOWAIT); if (!uni1) return -ENOMEM; =20 @@ -498,7 +497,7 @@ static int ntfs_d_compare(const struct dentry *dentry, = unsigned int len1, ret =3D !ntfs_cmp_names_cpu(uni1, uni2, sbi->upcase, false) ? 0 : 1; =20 out: - __putname(uni1); + kfree(uni1); return ret; } =20 diff --git a/fs/ntfs3/xattr.c b/fs/ntfs3/xattr.c index c93df55e98d07..f3bb2c41c000f 100644 --- a/fs/ntfs3/xattr.c +++ b/fs/ntfs3/xattr.c @@ -556,8 +556,7 @@ struct posix_acl *ntfs_get_acl(struct mnt_idmap *idmap,= struct dentry *dentry, if (unlikely(is_bad_ni(ni))) return ERR_PTR(-EINVAL); =20 - /* Allocate PATH_MAX bytes. */ - buf =3D __getname(); + buf =3D kmalloc(PATH_MAX, GFP_KERNEL); if (!buf) return ERR_PTR(-ENOMEM); =20 @@ -588,7 +587,7 @@ struct posix_acl *ntfs_get_acl(struct mnt_idmap *idmap,= struct dentry *dentry, if (!IS_ERR(acl)) set_cached_acl(inode, type, acl); =20 - __putname(buf); + kfree(buf); =20 return acl; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15E6D48AE2F; Sat, 28 Feb 2026 17:34:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300052; cv=none; b=NSdqVvWHx4F9U0bkn8yu9zHUP5Gaji+kNMHLVd26MxYzIXfElwlEniSqV0QJEhND8B/Hu9dKYtKrM3L4jitADr3vDhI23VbQyq8ogwLLlEVzpuDpxAlc76JxFY0gG0+IgB38unmkTMKJvS12o+kXKdwoNNtNUeSUKdphWmD2Ong= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300052; c=relaxed/simple; bh=3ehqF7E1bgU2yP6k2XkYnR7D370BRBMbkJnAp8RL7Og=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=V/jAIYLbzCVGdwlXxDpavZ279loCYBKmYdKlfGtzdIqHJUqXHfS2N/3XKkSwmvR/3DrYp9hyGsxg9KLSalh6MPG5kN/gg39pyw4T7/AnF8RBRq0LVVW0+KvCKJe+3c+DDx8CIsXecCecfg5OYUamt7z1YxqtgjHH1KAzQV596pA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TBnhUSm2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TBnhUSm2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1BA78C19423; Sat, 28 Feb 2026 17:34:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300052; bh=3ehqF7E1bgU2yP6k2XkYnR7D370BRBMbkJnAp8RL7Og=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TBnhUSm2rW+ozOGA66GaGvzHGFFg0EM6Jn+OMEFCbpcArZ9Y6CSi8mO1ea9QeDLuu s3rKCUmrs52y13MVRXoJy/dpb4aCSprEBwiDinzim3qH9CvVhjLC+hS4hAnbc04/j0 cUnuKBV2QZ868W8ZOo5HODMJb1nvFH16GVPJDyJ50wGt5hbTp4ssvFwuSQzlqjvbqs DHgR5FlLlIGF8nakvzs5BsEoFR43zub8eUnZm9FoOkBnzmUsqn7BXQqj0SrpB9DT49 adoheg+Ps+B9CLQalTXoOXYd0/dMsrYIjHyuH6gMomj3euJCTNa+VZphHdIJccrveq b9IEJm/1Lfjtw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mauro Carvalho Chehab , Jonathan Cameron , Ard Biesheuvel , Hanjun Guo , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 065/844] EFI/CPER: don't dump the entire memory region Date: Sat, 28 Feb 2026 12:19:38 -0500 Message-ID: <20260228173244.1509663-66-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mauro Carvalho Chehab [ Upstream commit 55cc6fe5716f678f06bcb95140882dfa684464ec ] The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -=3D offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/1752b5ba63a3e2f148ddee813b36c996cc617e86.176= 7871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/firmware/efi/cper.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c index bd99802cb0cad..09a4f0168df80 100644 --- a/drivers/firmware/efi/cper.c +++ b/drivers/firmware/efi/cper.c @@ -560,6 +560,11 @@ static void cper_print_fw_err(const char *pfx, } else { offset =3D sizeof(*fw_err); } + if (offset > length) { + printk("%s""error section length is too small: offset=3D%d, length=3D%d\= n", + pfx, offset, length); + return; + } =20 buf +=3D offset; length -=3D offset; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DEF948BD33; Sat, 28 Feb 2026 17:34:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300053; cv=none; b=Dyr/gZcBBklrbxPj4UrKWhVetojezc258utvkdBToNtN6y4XMtD/Gwb39MLJk7uB8nGqJIvXoboEXRkOL/Cc0RRH21+aMTy06jz+yG5KZAsvbq7BWPMj3XtFMhENb0JaV8TWvyuF0kIlA+0IL9EAn5v1JaACdapT2yZznvwUK+k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300053; c=relaxed/simple; bh=WVF40FSFeIi/MlfoGa/yfIpY+sPRyFeLMXkqnv8miz0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OzH1qoex+yIXlzisWalH3L3RnCxSf73k0NJtazdVF+xVjgByNCjrfp1qRuazI1vGWt1bzx6moW6FdrfYzkyIt10pW0pnoW6vXb4kKKtJgOj2AlJRdkskDWowAFND1P+JVT7F2Lfbv51676QET837VsRoPY0PYkpr1XlA9YN3wi4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ABQKywp2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ABQKywp2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47EAEC116D0; Sat, 28 Feb 2026 17:34:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300053; bh=WVF40FSFeIi/MlfoGa/yfIpY+sPRyFeLMXkqnv8miz0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ABQKywp2aPpnWzudue/zZlJvsWDa6Gj8XgIXP4pVd0qayTHmwQAy2RpdF2n2AxBhs AV/VA3U5AXJ7hIc48j7C2aMo+KoN9VGx2X/2TNOPgIm3irvAe5H2JHcN1+R1RAw3kk H/2lakFrJaWYRrUVAB4DDKTIDhXD+OufhYoiLuw3diuaawrtryOK/tacYvsSgJEaJY diprBQtwX93uqzrusOE0uAF9G//k3VwBRemi1kiBeAzjlE0r98gWuDOG7kT3j5JGXX Qw7Uraj3SpqHGL4chFubUVOH8zpl/OnNbcaz7wG83O+xdFgkkYwVyJlewphDhDMybO +b5krcWPPC+SQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mauro Carvalho Chehab , Jonathan Cameron , Ard Biesheuvel , Hanjun Guo , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 066/844] APEI/GHES: ensure that won't go past CPER allocated record Date: Sat, 28 Feb 2026 12:19:39 -0500 Message-ID: <20260228173244.1509663-67-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mauro Carvalho Chehab [ Upstream commit fa2408a24f8f0db14d9cfc613ef162dc267d7ad4 ] The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40= 000 Mem abort info: ESR =3D 0x0000000096000007 EC =3D 0x25: DABT (current EL), IL =3D 32 bits SET =3D 0, FnV =3D 0 EA =3D 0, S1PTW =3D 0 FSC =3D 0x07: level 3 translation fault Data abort info: ISV =3D 0, ISS =3D 0x00000007, ISS2 =3D 0x00000000 CM =3D 0, WnR =3D 0, TnD =3D 0, TagAccess =3D 0 GCS =3D 0, Overlay =3D 0, DirtyBit =3D 0, Xs =3D 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=3D000000008ba16000 [fff00000f9b40000] pgd=3D180000013ffff403, p4d=3D180000013fffe403, pud= =3D180000013f85b403, pmd=3D180000013f68d403, pte=3D0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-g= da407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=3D--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/4e70310a816577fabf37d94ed36cde4ad62b1e0a.176= 7871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/apei/ghes.c | 6 +++++- include/acpi/ghes.h | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 0dc767392a6c6..a37c8fb574832 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include @@ -294,6 +295,7 @@ static struct ghes *ghes_new(struct acpi_hest_generic *= generic) error_block_length =3D GHES_ESTATUS_MAX_SIZE; } ghes->estatus =3D kmalloc(error_block_length, GFP_KERNEL); + ghes->estatus_length =3D error_block_length; if (!ghes->estatus) { rc =3D -ENOMEM; goto err_unmap_status_addr; @@ -365,13 +367,15 @@ static int __ghes_check_estatus(struct ghes *ghes, struct acpi_hest_generic_status *estatus) { u32 len =3D cper_estatus_len(estatus); + u32 max_len =3D min(ghes->generic->error_block_length, + ghes->estatus_length); =20 if (len < sizeof(*estatus)) { pr_warn_ratelimited(FW_WARN GHES_PFX "Truncated error status block!\n"); return -EIO; } =20 - if (len > ghes->generic->error_block_length) { + if (!len || len > max_len) { pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid error status block length!= \n"); return -EIO; } diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h index ebd21b05fe6ed..93db60da5934e 100644 --- a/include/acpi/ghes.h +++ b/include/acpi/ghes.h @@ -21,6 +21,7 @@ struct ghes { struct acpi_hest_generic_v2 *generic_v2; }; struct acpi_hest_generic_status *estatus; + unsigned int estatus_length; unsigned long flags; union { struct list_head list; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C2B148B390; Sat, 28 Feb 2026 17:34:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300054; cv=none; b=fwIa+5vrGSeiTV+xMGPkCciiXTGm+pqa5eitr/h+rydR+7QYXHZmEbT8pkPErHsqB2W6cquHwyBvC5W8WxmTPZvs7qqzxTg2uj7do1K6va1+naEn/NIeKwaJS8zG1ntbecaf5fHDLmo0GvObQ/9eJA3K+Hi+KcZOpQnk+L+3r4s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300054; c=relaxed/simple; bh=Yz/ggIybgY+zK+e3qiPFxgkkDOVInDd1F0NP/qxgqpQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RBEQvA/W3R6sA+iAKApOYs9yMEUad2lE4z4xMOXFCcOeYPOoyoX7h9eIASLyyKAmzYMBzSDMiezYZPhvwumz/+udm/iFC39N4qZk0+n77F/7V8lUoAgHi58U1zOTJHU4/ZooDImk5udXGSTIFuKMmXTrlQd2SN3ndROYAUfd720= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sLVCOw8U; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sLVCOw8U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 663DDC116D0; Sat, 28 Feb 2026 17:34:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300054; bh=Yz/ggIybgY+zK+e3qiPFxgkkDOVInDd1F0NP/qxgqpQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sLVCOw8Ubd0kQ4MKgcgd/ejlEAh5faIwH4nipJTYHBSuUOaEZasNPv1ofGpZ67QIZ 9L8wtkCS1Um4qNMicRWnx9ijSPlfyhKpFNSMGL0py1t3HicoLR8OmmhHU6niiOayvL SVP6LQHMyp5fyZtVxyrP4AV+LaCyPRpZH0ROcr1sxUqQMj8ttVwKTi0nUfTp1+tp8T kCCsCloC3M8DQOw8h8kr6se31nwZeKogNK4ZA1Eo84l0t13WE8ahD63o467uEJcaCX mWU9kGNy7RaGMF8JD2ZPGgMhOcpKIHetRlF9bznUq6StLaThs5Xr31HAC4kdfwz8sc ehXy8bw86i53w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mauro Carvalho Chehab , Jonathan Cameron , Ard Biesheuvel , Hanjun Guo , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 067/844] APEI/GHES: ARM processor Error: don't go past allocated memory Date: Sat, 28 Feb 2026 12:19:40 -0500 Message-ID: <20260228173244.1509663-68-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mauro Carvalho Chehab [ Upstream commit 87880af2d24e62a84ed19943dbdd524f097172f2 ] If the BIOS generates a very small ARM Processor Error, or an incomplete one, the current logic will fail to deferrence err->section_length and ctx_info->size Add checks to avoid that. With such changes, such GHESv2 records won't cause OOPSes like this: [ 1.492129] Internal error: Oops: 0000000096000005 [#1] SMP [ 1.495449] Modules linked in: [ 1.495820] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.18.0-rc= 1-00017-gabadcc3553dd-dirty #18 PREEMPT [ 1.496125] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02= /2022 [ 1.496433] Workqueue: kacpi_notify acpi_os_execute_deferred [ 1.496967] pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE= =3D--) [ 1.497199] pc : log_arm_hw_error+0x5c/0x200 [ 1.497380] lr : ghes_handle_arm_hw_error+0x94/0x220 0xffff8000811c5324 is in log_arm_hw_error (../drivers/ras/ras.c:75). 70 err_info =3D (struct cper_arm_err_info *)(err + 1); 71 ctx_info =3D (struct cper_arm_ctx_info *)(err_info + err->err_info_num); 72 ctx_err =3D (u8 *)ctx_info; 73 74 for (n =3D 0; n < err->context_info_num; n++) { 75 sz =3D sizeof(struct cper_arm_ctx_info) + ctx_info->size; 76 ctx_info =3D (struct cper_arm_ctx_info *)((long)ctx_info + sz); 77 ctx_len +=3D sz; 78 } 79 and similar ones while trying to access section_length on an error dump with too small size. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/7fd9f38413be05ee2d7cfdb0dc31ea2274cf1a54.176= 7871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/apei/ghes.c | 32 ++++++++++++++++++++++++++++---- drivers/ras/ras.c | 6 +++++- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index a37c8fb574832..77ea7a5b761f1 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -556,21 +556,45 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest= _generic_data *gdata, { struct cper_sec_proc_arm *err =3D acpi_hest_get_payload(gdata); int flags =3D sync ? MF_ACTION_REQUIRED : 0; + int length =3D gdata->error_data_length; char error_type[120]; bool queued =3D false; int sec_sev, i; char *p; =20 sec_sev =3D ghes_severity(gdata->error_severity); - log_arm_hw_error(err, sec_sev); + if (length >=3D sizeof(*err)) { + log_arm_hw_error(err, sec_sev); + } else { + pr_warn(FW_BUG "arm error length: %d\n", length); + pr_warn(FW_BUG "length is too small\n"); + pr_warn(FW_BUG "firmware-generated error record is incorrect\n"); + return false; + } + if (sev !=3D GHES_SEV_RECOVERABLE || sec_sev !=3D GHES_SEV_RECOVERABLE) return false; =20 p =3D (char *)(err + 1); + length -=3D sizeof(err); + for (i =3D 0; i < err->err_info_num; i++) { - struct cper_arm_err_info *err_info =3D (struct cper_arm_err_info *)p; - bool is_cache =3D err_info->type & CPER_ARM_CACHE_ERROR; - bool has_pa =3D (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICA= L_ADDR); + struct cper_arm_err_info *err_info; + bool is_cache, has_pa; + + /* Ensure we have enough data for the error info header */ + if (length < sizeof(*err_info)) + break; + + err_info =3D (struct cper_arm_err_info *)p; + + /* Validate the claimed length before using it */ + length -=3D err_info->length; + if (length < 0) + break; + + is_cache =3D err_info->type & CPER_ARM_CACHE_ERROR; + has_pa =3D (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADD= R); =20 /* * The field (err_info->error_info & BIT(26)) is fixed to set to diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c index 2a5b5a9fdcb36..03df3db623346 100644 --- a/drivers/ras/ras.c +++ b/drivers/ras/ras.c @@ -72,7 +72,11 @@ void log_arm_hw_error(struct cper_sec_proc_arm *err, con= st u8 sev) ctx_err =3D (u8 *)ctx_info; =20 for (n =3D 0; n < err->context_info_num; n++) { - sz =3D sizeof(struct cper_arm_ctx_info) + ctx_info->size; + sz =3D sizeof(struct cper_arm_ctx_info); + + if (sz + (long)ctx_info - (long)err >=3D err->section_length) + sz +=3D ctx_info->size; + ctx_info =3D (struct cper_arm_ctx_info *)((long)ctx_info + sz); ctx_len +=3D sz; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A85648BD5F; Sat, 28 Feb 2026 17:34:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300055; cv=none; b=gtvccx+AHnXKolZlw23C1b+YAtQ6rMqD7VsPTPGbGTPpEM7PXiLSCtFssZx2WzAY411LVSXxyZQnMEpE/IjTAu1H2AfmOfRMRX2LEZ1Y4qoqeYBXvElpzavKSaCh7IusirPKTKvB04GCZZK4nkTisR5OY7hcFg+nFBZqWcgpnCE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300055; c=relaxed/simple; bh=hAz/c0KoPSLMkWFoUhxDy36nd/6iei+x1ma2sWOFKc8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NzuPTD5yYhV5mq7CChZLrgr3D2l5jhy8bvukEmOurwZ5JdDfRfcryB7pH3QdQFC6VBdnceCqFxYZ98m7X7O6OI5A0rN1PYpfEpYFlc77dL2v2apO1ulMIgU75DrlYm7XaB4vpEvGHp32h/2/cigrdpHr67Az7Tv6rV3CaJpeDY0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NaDZ+azE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NaDZ+azE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85CC0C116D0; Sat, 28 Feb 2026 17:34:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300055; bh=hAz/c0KoPSLMkWFoUhxDy36nd/6iei+x1ma2sWOFKc8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NaDZ+azE1AcOSz2tnKG3eCEugJ4HTP0xMCVxC+QG2A7BGXmz+0RXBoh8BzWlj5MI4 ztjBGSuHelRMBTdHimT7ONZCEBmGaqJgdosvv35Pp3KFhz43kmlPqUynBTA7WBvxHY MFl4vYxzMsEpMty8Ew/vWtp9x0Sw4MfifcQjy8426dBhehH9H7/NooHy6UmJV4bQF2 +1r9ojmYY0bqRb9whm+RnX4jBK5E+AncCvyHUYlYaioMZ7tgOoLGz15yGaua7GIOro 66A09aYqXu3hFkZVedocSewhEi9pjF6WnvZFb4PB+bQ0eTKwLSngQX1YYEIx32a0EB 6L4jPBG9KEjrg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mauro Carvalho Chehab , Jonathan Cameron , Ard Biesheuvel , Hanjun Guo , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 068/844] EFI/CPER: don't go past the ARM processor CPER record buffer Date: Sat, 28 Feb 2026 12:19:41 -0500 Message-ID: <20260228173244.1509663-69-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mauro Carvalho Chehab [ Upstream commit eae21beecb95a3b69ee5c38a659f774e171d730e ] There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERR_INFO_NUM is 46198 Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject and changelog tweaks ] Link: https://patch.msgid.link/41cd9f6b3ace3cdff7a5e864890849e4b1c58b63.176= 7871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/firmware/efi/cper-arm.c | 12 ++++++++---- drivers/firmware/efi/cper.c | 3 ++- include/linux/cper.h | 3 ++- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/firmware/efi/cper-arm.c b/drivers/firmware/efi/cper-ar= m.c index 76542a53e2027..b21cb1232d820 100644 --- a/drivers/firmware/efi/cper-arm.c +++ b/drivers/firmware/efi/cper-arm.c @@ -226,7 +226,8 @@ static void cper_print_arm_err_info(const char *pfx, u3= 2 type, } =20 void cper_print_proc_arm(const char *pfx, - const struct cper_sec_proc_arm *proc) + const struct cper_sec_proc_arm *proc, + u32 length) { int i, len, max_ctx_type; struct cper_arm_err_info *err_info; @@ -238,9 +239,12 @@ void cper_print_proc_arm(const char *pfx, =20 len =3D proc->section_length - (sizeof(*proc) + proc->err_info_num * (sizeof(*err_info))); - if (len < 0) { - printk("%ssection length: %d\n", pfx, proc->section_length); - printk("%ssection length is too small\n", pfx); + + if (len < 0 || proc->section_length > length) { + printk("%ssection length: %d, CPER size: %d\n", + pfx, proc->section_length, length); + printk("%ssection length is too %s\n", pfx, + (len < 0) ? "small" : "big"); printk("%sfirmware-generated error record is incorrect\n", pfx); printk("%sERR_INFO_NUM is %d\n", pfx, proc->err_info_num); return; diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c index 09a4f0168df80..06b4fdb59917a 100644 --- a/drivers/firmware/efi/cper.c +++ b/drivers/firmware/efi/cper.c @@ -664,7 +664,8 @@ cper_estatus_print_section(const char *pfx, struct acpi= _hest_generic_data *gdata =20 printk("%ssection_type: ARM processor error\n", newpfx); if (gdata->error_data_length >=3D sizeof(*arm_err)) - cper_print_proc_arm(newpfx, arm_err); + cper_print_proc_arm(newpfx, arm_err, + gdata->error_data_length); else goto err_section_too_small; #endif diff --git a/include/linux/cper.h b/include/linux/cper.h index 5b1236d8c65bb..440b35e459e53 100644 --- a/include/linux/cper.h +++ b/include/linux/cper.h @@ -595,7 +595,8 @@ void cper_mem_err_pack(const struct cper_sec_mem_err *, const char *cper_mem_err_unpack(struct trace_seq *, struct cper_mem_err_compact *); void cper_print_proc_arm(const char *pfx, - const struct cper_sec_proc_arm *proc); + const struct cper_sec_proc_arm *proc, + u32 length); void cper_print_proc_ia(const char *pfx, const struct cper_sec_proc_ia *proc); int cper_mem_err_location(struct cper_mem_err_compact *mem, char *msg); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57AA848C3F2; Sat, 28 Feb 2026 17:34:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300056; cv=none; b=frJBw7H4Vb9OkK5Bau9mo4HecBkyfRcyvGIiLEsyLJDNXaWLKy33YrFOFQBHfSK5HVnzF+HNcYrUD44UOPHvfgXUaZ7omo2LQzthH0qw/sdmSBNXdwttsftJfu9kAAf/y4KIAyRgEbXmys+fus02wusAIQTcPHpWpCapWFK5uGQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300056; c=relaxed/simple; bh=0CCz9biBOud+8uzG72V1nDJ7Iom/YHhR3IuKnMgsuys=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=a1XJMptNGrvdgPyAn8B5c+XZJLdCVxNPjEzl0bazYXdqqZB8bv7C/0KF5VkUEO9dpEPTqQO8ZsqYAIAMXRQepZLJyAzEFS6u/Mfg2HMIOAxfhjpIfn2I/fecOgIwLtkoZdJ0mkyE8AoSi9X36bLZHTHNAabklIRFxfWYrGtopGA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RiIrjCe1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RiIrjCe1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A24E8C116D0; Sat, 28 Feb 2026 17:34:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300056; bh=0CCz9biBOud+8uzG72V1nDJ7Iom/YHhR3IuKnMgsuys=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RiIrjCe1lscbNkswzFtqcY8R6B30HYCdi2rS7qlOWpL9v7CTtZa5QUqZoWRvAWoEF E10521nhmmChueaVJzZ8w3Clvek1QyvFoZWS3ou0jyysZa6iiayOGwXPlZKsR/vaQc Fss0bs7EZtl/kLPCsdBQAzwqHdGIQjv6+8luVKkhIfu1pKTd+tX54J2pdk6FWkhYQU 0wVSi9AY/YCPKQwmaqOkS5nvAjaV1G1F8LJig3PrGtkWQLlHgtcB29yDY+1hPIk8SZ d+SXDPTy8s5t+lYCf5msQ/RPshoiiSHb8EcP9VozRyrLh6op6Hg/yf+h7bcH5DyWbP 8rfcExxHDRX9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tuo Li , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 069/844] ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() Date: Sat, 28 Feb 2026 12:19:42 -0500 Message-ID: <20260228173244.1509663-70-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tuo Li [ Upstream commit f132e089fe89cadc2098991f0a3cb05c3f824ac6 ] In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev =3D pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev =3D pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. Signed-off-by: Tuo Li [ rjw: Subject adjustment, added an empty code line ] Link: https://patch.msgid.link/20260111163214.202262-1-islituo@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/acpi_processor.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 7ec1dc04fd11b..85096ce7b658b 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -50,6 +50,7 @@ static int acpi_processor_errata_piix4(struct pci_dev *de= v) { u8 value1 =3D 0; u8 value2 =3D 0; + struct pci_dev *ide_dev =3D NULL, *isa_dev =3D NULL; =20 =20 if (!dev) @@ -107,12 +108,12 @@ static int acpi_processor_errata_piix4(struct pci_dev= *dev) * each IDE controller's DMA status to make sure we catch all * DMA activity. */ - dev =3D pci_get_subsys(PCI_VENDOR_ID_INTEL, + ide_dev =3D pci_get_subsys(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB, PCI_ANY_ID, PCI_ANY_ID, NULL); - if (dev) { - errata.piix4.bmisx =3D pci_resource_start(dev, 4); - pci_dev_put(dev); + if (ide_dev) { + errata.piix4.bmisx =3D pci_resource_start(ide_dev, 4); + pci_dev_put(ide_dev); } =20 /* @@ -124,24 +125,25 @@ static int acpi_processor_errata_piix4(struct pci_dev= *dev) * disable C3 support if this is enabled, as some legacy * devices won't operate well if fast DMA is disabled. */ - dev =3D pci_get_subsys(PCI_VENDOR_ID_INTEL, + isa_dev =3D pci_get_subsys(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_0, PCI_ANY_ID, PCI_ANY_ID, NULL); - if (dev) { - pci_read_config_byte(dev, 0x76, &value1); - pci_read_config_byte(dev, 0x77, &value2); + if (isa_dev) { + pci_read_config_byte(isa_dev, 0x76, &value1); + pci_read_config_byte(isa_dev, 0x77, &value2); if ((value1 & 0x80) || (value2 & 0x80)) errata.piix4.fdma =3D 1; - pci_dev_put(dev); + pci_dev_put(isa_dev); } =20 break; } =20 - if (errata.piix4.bmisx) - dev_dbg(&dev->dev, "Bus master activity detection (BM-IDE) erratum enabl= ed\n"); - if (errata.piix4.fdma) - dev_dbg(&dev->dev, "Type-F DMA livelock erratum (C3 disabled)\n"); + if (ide_dev) + dev_dbg(&ide_dev->dev, "Bus master activity detection (BM-IDE) erratum e= nabled\n"); + + if (isa_dev) + dev_dbg(&isa_dev->dev, "Type-F DMA livelock erratum (C3 disabled)\n"); =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3869A48C405; Sat, 28 Feb 2026 17:34:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300057; cv=none; b=DgbYxAj6+3D2FmEsmMMTgIXmQcxykkerEWsmG8Y+KJ/xGY/mKanb9ug4gTB7nxowG8xsiY03XEqilJOlH7K9dhntXRay5R7vvzwhpQmuq9ICH4kiui1Dw/uOD1jQDW+TQ8/o5qr0ubeqeZ7nt+vXip48B/PjYw3dS3n1Kh7yDcI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300057; c=relaxed/simple; bh=HawuXlsx55D4Kfk39pDirEMY1A8otxhSLro4Pg4y1uQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aleEF5gWoUfR0nE9AC1AQYCK8/nVma3MvgDdv3Q8yT9q+26vx3pRzyYIPIdYpefq2ekQPlSMn1uHcYkL6zgdKAfJ7uAil2TrsXz+D8snr4igA4SMhHAeOZJtXS8JiAVADVBAwnkXKuLpvVT9f7I+4/xQxRYzwttE8boMt7aUD2I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E4pWfC8u; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E4pWfC8u" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82331C19423; Sat, 28 Feb 2026 17:34:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300057; bh=HawuXlsx55D4Kfk39pDirEMY1A8otxhSLro4Pg4y1uQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E4pWfC8uOsTaX40hD4MYPWv3i9Q5+j7VbcbYLhctUbDdrr+KH8iIyo6u7oVZwpxsP 49uEZwphX16r79NiWFmyE20i2d6I9hDMWIX0jSYQjTmRlGSmk4lFAQ3r+2+WraM6aW lw2ePWeF9XODajLQmQZU475Tsb1bi86NhPltQCKFnNWfidUAm2f3SukJ6w7w4A7PjM yAfgdztUXgu/+XoFh5UhzFNXuYcry86n7MnE2kyzDcgRHIAMPA2aLbqXCMY4TYoQEH YHXp7M38/g2sV1rmgyl+I3CzHiquRo7GIayW443Mcp2c1xk6c3zqvpTY57fHuPwCIf ZzOnn+jam9C+w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ai Chao , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 070/844] ACPI: resource: Add JWIPC JVC9100 to irq1_level_low_skip_override[] Date: Sat, 28 Feb 2026 12:19:43 -0500 Message-ID: <20260228173244.1509663-71-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ai Chao [ Upstream commit ba6ded26dffe511b862a98a25955955e7154bfa8 ] Like the JWIPC JVC9100 has its serial IRQ (10 and 11) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh which breaks the serial. irq 10, level, active-low, shared, skip-override irq 11, level, active-low, shared, skip-override Add the JVC9100 to the irq1_level_low_skip_override[] quirk table to fix this. Signed-off-by: Ai Chao Link: https://patch.msgid.link/20260113072719.4154485-1-aichao@kylinos.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/resource.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index d16906f46484d..bc8050d8a6f51 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -532,6 +532,12 @@ static const struct dmi_system_id irq1_level_low_skip_= override[] =3D { DMI_MATCH(DMI_BOARD_NAME, "16T90SP"), }, }, + { + /* JWIPC JVC9100 */ + .matches =3D { + DMI_MATCH(DMI_BOARD_NAME, "JVC9100"), + }, + }, { } }; =20 @@ -706,6 +712,8 @@ struct irq_override_cmp { =20 static const struct irq_override_cmp override_table[] =3D { { irq1_level_low_skip_override, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW,= 0, false }, + { irq1_level_low_skip_override, 10, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW= , 1, false }, + { irq1_level_low_skip_override, 11, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW= , 1, false }, { irq1_edge_low_force_override, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, = 1, true }, }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DE1848C8AC; Sat, 28 Feb 2026 17:34:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300058; cv=none; b=Zj1YKE02cVMuDaQc796IUbWgUS2HGM1PqJ4plkUVrZHeKgXkOIfupPZpfolnOExV8xPpOyLDf0C8x/7V5cWjj7OrkZXPWKdV+Ws31MRlMw0hRYOiAP/SGYeReXLXv7gH1o0BIJedKKbn7o9N7fAsZg1CQBB/g8yunZGLjXWvk0I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300058; c=relaxed/simple; bh=BrE/nUq19xa+JatKpg2di0H3+n6ik0XyUYvDeY1PfEU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F6MEOUq00FnlK0ddEE6uNlWFudit+LtdEAiGNZccAGN6SYv5ygi4ZaYG2PORPRZSTe7uZRYF7AZAH+89s+ElQ0YVdCsG3AEFhJCv5imJyJ5JU62Ww6OEMld5gPPXNMdBtBecabMyFbfXwKHpDkPC90kBHyla38Yjb62Es+IWg/c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Pq20UahS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Pq20UahS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61AB5C116D0; Sat, 28 Feb 2026 17:34:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300058; bh=BrE/nUq19xa+JatKpg2di0H3+n6ik0XyUYvDeY1PfEU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Pq20UahS2gt61RbHDXWoUD/EoPZuIcaMYIS7q1Ng0Hz4aPiu4QFRD49KxADokY7AP n8hO04cXcybe1+QTpJlH92jc7l17zSM0EX7gEIlSDYk0zFjjg4H2ksC/o4lLHYrUp3 G8NcGrCJNg8smclh499qNGMh7hc7ycNva4ydAM5/P9x55S1z70LX+cqVi5/6khqrRS I0zRb1OrffuHChvsHqZxBOXq+a/b3VAehFmm+otY11K3uOM9z8slFlNoauVpUjLqTm KRu8C+90knd5CT2qhueETBmX8SDhNKYOkPQrsFixFmIU0qYR/k6dCFQrdPbLnepwqX 3DwvJ60tuPJCg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Armin Wolf , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 071/844] ACPICA: Abort AML bytecode execution when executing AML_FATAL_OP Date: Sat, 28 Feb 2026 12:19:44 -0500 Message-ID: <20260228173244.1509663-72-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Armin Wolf [ Upstream commit 026ad376a6a48538b576f3589331daa94daae6f0 ] The ACPI specification states that when executing AML_FATAL_OP, the OS should log the fatal error event and shutdown in a timely fashion. Windows complies with this requirement by immediatly entering a Bso_d, effectively aborting the execution of the AML bytecode in question. ACPICA however might continue with the AML bytecode execution should acpi_os_signal() simply return AE_OK. This will cause issues because ACPI BIOS implementations might assume that the Fatal() operator does not return. Fix this by aborting the AML bytecode execution in such a case by returning AE_ERROR. Also turn struct acpi_signal_fatal_info into a local variable because of its small size (12 bytes) and to ensure that acpi_os_signal() always receives valid information about the fatal ACPI BIOS error. Link: https://github.com/acpica/acpica/commit/d516c7758ba6 Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3325491.5fSG56mABF@rafael.j.wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/acpica/exoparg3.c | 46 +++++++++++++--------------------- 1 file changed, 18 insertions(+), 28 deletions(-) diff --git a/drivers/acpi/acpica/exoparg3.c b/drivers/acpi/acpica/exoparg3.c index bf08110ed6d25..c8c8c4e49563e 100644 --- a/drivers/acpi/acpica/exoparg3.c +++ b/drivers/acpi/acpica/exoparg3.c @@ -10,6 +10,7 @@ #include #include "accommon.h" #include "acinterp.h" +#include #include "acparser.h" #include "amlcode.h" =20 @@ -51,8 +52,7 @@ ACPI_MODULE_NAME("exoparg3") acpi_status acpi_ex_opcode_3A_0T_0R(struct acpi_walk_state *walk_state) { union acpi_operand_object **operand =3D &walk_state->operands[0]; - struct acpi_signal_fatal_info *fatal; - acpi_status status =3D AE_OK; + struct acpi_signal_fatal_info fatal; =20 ACPI_FUNCTION_TRACE_STR(ex_opcode_3A_0T_0R, acpi_ps_get_opcode_name(walk_state->opcode)); @@ -60,28 +60,23 @@ acpi_status acpi_ex_opcode_3A_0T_0R(struct acpi_walk_st= ate *walk_state) switch (walk_state->opcode) { case AML_FATAL_OP: /* Fatal (fatal_type fatal_code fatal_arg) */ =20 - ACPI_DEBUG_PRINT((ACPI_DB_INFO, - "FatalOp: Type %X Code %X Arg %X " - "<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<\n", - (u32)operand[0]->integer.value, - (u32)operand[1]->integer.value, - (u32)operand[2]->integer.value)); - - fatal =3D ACPI_ALLOCATE(sizeof(struct acpi_signal_fatal_info)); - if (fatal) { - fatal->type =3D (u32) operand[0]->integer.value; - fatal->code =3D (u32) operand[1]->integer.value; - fatal->argument =3D (u32) operand[2]->integer.value; - } + fatal.type =3D (u32)operand[0]->integer.value; + fatal.code =3D (u32)operand[1]->integer.value; + fatal.argument =3D (u32)operand[2]->integer.value; =20 - /* Always signal the OS! */ + ACPI_BIOS_ERROR((AE_INFO, + "Fatal ACPI BIOS error (Type 0x%X Code 0x%X Arg 0x%X)\n", + fatal.type, fatal.code, fatal.argument)); =20 - status =3D acpi_os_signal(ACPI_SIGNAL_FATAL, fatal); + /* Always signal the OS! */ =20 - /* Might return while OS is shutting down, just continue */ + acpi_os_signal(ACPI_SIGNAL_FATAL, &fatal); =20 - ACPI_FREE(fatal); - goto cleanup; + /* + * Might return while OS is shutting down, so abort the AML execution + * by returning an error. + */ + return_ACPI_STATUS(AE_ERROR); =20 case AML_EXTERNAL_OP: /* @@ -93,21 +88,16 @@ acpi_status acpi_ex_opcode_3A_0T_0R(struct acpi_walk_st= ate *walk_state) * wrong if an external opcode ever gets here. */ ACPI_ERROR((AE_INFO, "Executed External Op")); - status =3D AE_OK; - goto cleanup; + + return_ACPI_STATUS(AE_OK); =20 default: =20 ACPI_ERROR((AE_INFO, "Unknown AML opcode 0x%X", walk_state->opcode)); =20 - status =3D AE_AML_BAD_OPCODE; - goto cleanup; + return_ACPI_STATUS(AE_AML_BAD_OPCODE); } - -cleanup: - - return_ACPI_STATUS(status); } =20 /*************************************************************************= ****** --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ECECE34F49C; Sat, 28 Feb 2026 17:34:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300059; cv=none; b=C5mMy226iCvOSeYUXrcm8lMSoTDJhBD1HEOl4Lj+SMlRq4/X5FhvUCR17BIcqJc0SaftEgADxWFJMGQ4KnQNmcxBEGhkBNpI8YazIi00SOZy99TLpo9LujetZdTfuBdHPOL0Ab+mwFc7LkLEovWgWiTmURtOructJyDRxRAnP7s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300059; c=relaxed/simple; bh=xn1bCIo/367N91ZjLg+LSBuqHZFM0nJNCs7CSOAh0R4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Xu2FXGSATn9EsHnFt1nTDXOsnJjOjA5BQ48SlCqXZueVomz0pn8hZUqveM1dNUnBBhsiDLlvc6G7Hr5+O+KYz3gHjrSHbZ6rdqZnB5SspvZhOMq7G/8lClltrxiWNhVS3GaXeNJLDq89ga/EhmSEcczwsJWA0K7cpMConAzTG5Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TW4EzGPO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TW4EzGPO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40552C2BCB0; Sat, 28 Feb 2026 17:34:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300058; bh=xn1bCIo/367N91ZjLg+LSBuqHZFM0nJNCs7CSOAh0R4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TW4EzGPOz5syxJq/wq0Ww8fVHtiLCXxdKJWE1kMPyHOuRtQDfyh0CT0yBJfHNoCnZ 4JJD8H326154IdgExLsMExCnpK0hvzCK6urA3Yjvwu5iJgqM66Cu23f3/CFMCCQg1G uyd6lY+CbdNpoQk/RNOT2z2gh8i+BZn4cT2Jl2/35T5oNbkAyG87dJU3zhrQMFV67O EgAm03+9ktX6TlnKAmS+a4NG5ugsTSIuNWeEmFaLSoIgsccoIFCxY8Hb9PuVhKUGPW F2PXcLaJ0UH1AowDqAzBHFZVzZrtpen8owz5g+qb2XnNe/Zh+UbirwvwpYSSOAWCyx kCQST6LC1ODiw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Daniel Tang , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 072/844] powercap: intel_rapl: Add PL4 support for Ice Lake Date: Sat, 28 Feb 2026 12:19:45 -0500 Message-ID: <20260228173244.1509663-73-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Daniel Tang [ Upstream commit 54b3cd55a515c7c0fcfa0c1f0b10d62c11d64bcc ] Microsoft Surface Pro 7 firmware throttles the processor upon boot/resume. Userspace needs to be able to restore the correct value. Link: https://github.com/linux-surface/linux-surface/issues/706 Signed-off-by: Daniel Tang Link: https://patch.msgid.link/6088605.ChMirdbgyp@daniel-desktop3 Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/powercap/intel_rapl_msr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_rap= l_msr.c index 152893dca5653..3d5e7f56d68a1 100644 --- a/drivers/powercap/intel_rapl_msr.c +++ b/drivers/powercap/intel_rapl_msr.c @@ -160,6 +160,7 @@ static int rapl_msr_write_raw(int cpu, struct reg_actio= n *ra) =20 /* List of verified CPUs. */ static const struct x86_cpu_id pl4_support_ids[] =3D { + X86_MATCH_VFM(INTEL_ICELAKE_L, NULL), X86_MATCH_VFM(INTEL_TIGERLAKE_L, NULL), X86_MATCH_VFM(INTEL_ALDERLAKE, NULL), X86_MATCH_VFM(INTEL_ALDERLAKE_L, NULL), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C53EA34D4FE; Sat, 28 Feb 2026 17:34:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300059; cv=none; b=XMw6lmYO/9ec8JwVD8QovmkkNNI1lmHvswoeqUNbepg+mxe1e/baTzTZ5fZNyUfYndKZBtaEcHUHNlFja2dRExCnvjTMCTEI6L0FfkYvjAX9i48N2a12pPDcxUDED+JIb8yJ9Tte4bRa87Yo6udeiSCu8pxyL9gEdbJAPI5JQbU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300059; c=relaxed/simple; bh=ZB/QjOcRQSR7jSiCPUV7WmVsTIcYLesh42owSyloUOI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X/oyOOIGHSIitimybM/g1JRHAcgE9BDCeVpy2GbXNEBuqgZe4lqRxOGAbxNN767UinyRNENHQ1/lAsDfx+O9YLZO79ziAFUVnokPCGWF0T/NP7Ta6pDXSOfmY3IZAP8FtnXLTxj+vgGvSvchv5B3kUtjaEwoljSoLoOzxLFXo8g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ptgxzod8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ptgxzod8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E257C116D0; Sat, 28 Feb 2026 17:34:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300059; bh=ZB/QjOcRQSR7jSiCPUV7WmVsTIcYLesh42owSyloUOI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ptgxzod85qUvP770PYPD76M2ELk4PBAxOeyLYdppdQ7vNyCn0eFzwxWoJj8yhD8XH jUAbjgZebq2sNiPp8jv08gT9KClt/nvH1OyPicc/QwxVPdWykr+AgNOyP+aEVyZ1JP XWBqmA/C0kUsNEvPkgYjF51CD6bW8KkeGFs2/PuK8x3OFlv4O5DtiJIWlM6h2/3O2k SGhxnt9hXPaFklTijR2fm+Cgscq10k0z2IcTRII8LWC0c4iuUxfrYTUsd/hox0Os2p puVJjePoqeu4MWWfQx+V5NTtDPdP4+6nUC/f/klzgj/C8nJH8dKEEkZaToSYw9e6fu HDF5ONMu2vLhw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jens Axboe , syzbot+6c48db7d94402407301e@syzkaller.appspotmail.com, Sasha Levin Subject: [PATCH 6.19 073/844] io_uring/timeout: annotate data race in io_flush_timeouts() Date: Sat, 28 Feb 2026 12:19:46 -0500 Message-ID: <20260228173244.1509663-74-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jens Axboe [ Upstream commit 42b12cb5fd4554679bac06bbdd05dc8b643bcc42 ] syzbot correctly reports this as a KCSAN race, as ctx->cached_cq_tail should be read under ->uring_lock. This isn't immediately feasible in io_flush_timeouts(), but as long as we read a stable value, that should be good enough. If two io-wq threads compete on this value, then they will both end up calling io_flush_timeouts() and at least one of them will see the correct value. Reported-by: syzbot+6c48db7d94402407301e@syzkaller.appspotmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/timeout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/io_uring/timeout.c b/io_uring/timeout.c index d8fbbaf31cf35..84dda24f3eb24 100644 --- a/io_uring/timeout.c +++ b/io_uring/timeout.c @@ -130,7 +130,7 @@ __cold void io_flush_timeouts(struct io_ring_ctx *ctx) u32 seq; =20 raw_spin_lock_irq(&ctx->timeout_lock); - seq =3D ctx->cached_cq_tail - atomic_read(&ctx->cq_timeouts); + seq =3D READ_ONCE(ctx->cached_cq_tail) - atomic_read(&ctx->cq_timeouts); =20 list_for_each_entry_safe(timeout, tmp, &ctx->timeout_list, list) { struct io_kiocb *req =3D cmd_to_io_kiocb(timeout); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D08194921A2; Sat, 28 Feb 2026 17:34:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300060; cv=none; b=B0DLVZOycdFw4cgcYPfsHfeAT5gu+cChFjzdKkt9jsdELz6G15Pj2zRMvvlOFpKuvzBfO1Rq5WqUh12ckSmEl5yUgMKY410lTE4VQUlltJds/ZhmtYiz5pwLIt6Uz5N+5VByMTBiNBKUYol56onLBRyl1aHBBchSk5yzuMmYagY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300060; c=relaxed/simple; bh=iPHL5fHDNkD0s+OK8W08RPRr3MyV1q3fjkFPa2mlYxo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uickTqyPr8LFXfz6fcAeDLzJgjIaC2EnUMV6wh9QIniugWfVYn/oK/7wDkrAuQ21JqvVPuOFRMeCYAiPa0843f1TIOBvtWR03q0tr318egsVfSTPRDv8OVJ7xyPOf8+dj6AIHwZecDF1zCNFPZXxI+G5Rx6gpV5O1//h9skXGtc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uBzKjERW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uBzKjERW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED8A1C19423; Sat, 28 Feb 2026 17:34:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300060; bh=iPHL5fHDNkD0s+OK8W08RPRr3MyV1q3fjkFPa2mlYxo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uBzKjERWsBY3e9hhJUq6Sl5JU9scrdKdUyP7EjGixqgUcN3a7dJlA4sWSsIa5gwNh 7vcgBt9t06UaN1S+PNLZaZgsypAssoBjfNZ3JYHVxpx00oHKcoaDNQW1hBwcoCiV+j jgWpswmuom3U20IXj/p94DPFUeEKBIl5tfMNkl53GAfkZlKGF1Yd7prH0ok4XOdzfz Rjl/8zClSBIbnuEgE67e9HL9R5ziIjc8NOoYaVfwilKDyjuDYfQ0MvumPQbfst/Kq3 VUr048RR8uTWJf8sPT+zVal3Q8D48O5tbfhDwfJGJfgvF/4rheGEVH9lF1A25F0WJX gmt5d4iGlC2OA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Magnus Lindholm , Ivan Kokshaysky , Matoro Mahri , Michael Cree , Sasha Levin Subject: [PATCH 6.19 074/844] alpha: fix user-space corruption during memory compaction Date: Sat, 28 Feb 2026 12:19:47 -0500 Message-ID: <20260228173244.1509663-75-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Magnus Lindholm [ Upstream commit dd5712f3379cfe760267cdd28ff957d9ab4e51c7 ] Alpha systems can suffer sporadic user-space crashes and heap corruption when memory compaction is enabled. Symptoms include SIGSEGV, glibc allocator failures (e.g. "unaligned tcache chunk"), and compiler internal errors. The failures disappear when compaction is disabled or when using global TLB invalidation. The root cause is insufficient TLB shootdown during page migration. Alpha relies on ASN-based MM context rollover for instruction cache coherency, but this alone is not sufficient to prevent stale data or instruction translations from surviving migration. Fix this by introducing a migration-specific helper that combines: - MM context invalidation (ASN rollover), - immediate per-CPU TLB invalidation (TBI), - synchronous cross-CPU shootdown when required. The helper is used only by migration/compaction paths to avoid changing global TLB semantics. Additionally, update flush_tlb_other(), pte_clear(), to use READ_ONCE()/WRITE_ONCE() for correct SMP memory ordering. This fixes observed crashes on both UP and SMP Alpha systems. Reviewed-by: Ivan Kokshaysky Tested-by: Matoro Mahri Tested-by: Michael Cree Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260102173603.18247-2-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/alpha/include/asm/pgtable.h | 33 ++++++++- arch/alpha/include/asm/tlbflush.h | 4 +- arch/alpha/mm/Makefile | 2 +- arch/alpha/mm/tlbflush.c | 112 ++++++++++++++++++++++++++++++ 4 files changed, 148 insertions(+), 3 deletions(-) create mode 100644 arch/alpha/mm/tlbflush.c diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgta= ble.h index 90e7a95391022..c9508ec37efc4 100644 --- a/arch/alpha/include/asm/pgtable.h +++ b/arch/alpha/include/asm/pgtable.h @@ -17,6 +17,7 @@ #include /* For TASK_SIZE */ #include #include +#include =20 struct mm_struct; struct vm_area_struct; @@ -183,6 +184,9 @@ extern inline void pud_set(pud_t * pudp, pmd_t * pmdp) { pud_val(*pudp) =3D _PAGE_TABLE | ((((unsigned long) pmdp) - PAGE_OFFSET)= << (32-PAGE_SHIFT)); } =20 =20 +extern void migrate_flush_tlb_page(struct vm_area_struct *vma, + unsigned long addr); + extern inline unsigned long pmd_page_vaddr(pmd_t pmd) { @@ -202,7 +206,7 @@ extern inline int pte_none(pte_t pte) { return !pte_va= l(pte); } extern inline int pte_present(pte_t pte) { return pte_val(pte) & _PAGE_VAL= ID; } extern inline void pte_clear(struct mm_struct *mm, unsigned long addr, pte= _t *ptep) { - pte_val(*ptep) =3D 0; + WRITE_ONCE(pte_val(*ptep), 0); } =20 extern inline int pmd_none(pmd_t pmd) { return !pmd_val(pmd); } @@ -264,6 +268,33 @@ extern inline pte_t * pte_offset_kernel(pmd_t * dir, u= nsigned long address) =20 extern pgd_t swapper_pg_dir[1024]; =20 +#ifdef CONFIG_COMPACTION +#define __HAVE_ARCH_PTEP_GET_AND_CLEAR + +static inline pte_t ptep_get_and_clear(struct mm_struct *mm, + unsigned long address, + pte_t *ptep) +{ + pte_t pte =3D READ_ONCE(*ptep); + + pte_clear(mm, address, ptep); + return pte; +} + +#define __HAVE_ARCH_PTEP_CLEAR_FLUSH + +static inline pte_t ptep_clear_flush(struct vm_area_struct *vma, + unsigned long addr, pte_t *ptep) +{ + struct mm_struct *mm =3D vma->vm_mm; + pte_t pte =3D ptep_get_and_clear(mm, addr, ptep); + + page_table_check_pte_clear(mm, pte); + migrate_flush_tlb_page(vma, addr); + return pte; +} + +#endif /* * The Alpha doesn't have any external MMU info: the kernel page * tables contain all the necessary information. diff --git a/arch/alpha/include/asm/tlbflush.h b/arch/alpha/include/asm/tlb= flush.h index ba4b359d6c395..0c8529997f54e 100644 --- a/arch/alpha/include/asm/tlbflush.h +++ b/arch/alpha/include/asm/tlbflush.h @@ -58,7 +58,9 @@ flush_tlb_other(struct mm_struct *mm) unsigned long *mmc =3D &mm->context[smp_processor_id()]; /* Check it's not zero first to avoid cacheline ping pong when possible. */ - if (*mmc) *mmc =3D 0; + + if (READ_ONCE(*mmc)) + WRITE_ONCE(*mmc, 0); } =20 #ifndef CONFIG_SMP diff --git a/arch/alpha/mm/Makefile b/arch/alpha/mm/Makefile index 101dbd06b4ceb..2d05664058f64 100644 --- a/arch/alpha/mm/Makefile +++ b/arch/alpha/mm/Makefile @@ -3,4 +3,4 @@ # Makefile for the linux alpha-specific parts of the memory manager. # =20 -obj-y :=3D init.o fault.o +obj-y :=3D init.o fault.o tlbflush.o diff --git a/arch/alpha/mm/tlbflush.c b/arch/alpha/mm/tlbflush.c new file mode 100644 index 0000000000000..ccbc317b9a348 --- /dev/null +++ b/arch/alpha/mm/tlbflush.c @@ -0,0 +1,112 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Alpha TLB shootdown helpers + * + * Copyright (C) 2025 Magnus Lindholm + * + * Alpha-specific TLB flush helpers that cannot be expressed purely + * as inline functions. + * + * These helpers provide combined MM context handling (ASN rollover) + * and immediate TLB invalidation for page migration and memory + * compaction paths, where lazy shootdowns are insufficient. + */ + +#include +#include +#include +#include +#include +#include + +#define asn_locked() (cpu_data[smp_processor_id()].asn_lock) + +/* + * Migration/compaction helper: combine mm context (ASN) handling with an + * immediate per-page TLB invalidate and (for exec) an instruction barrier. + * + * This mirrors the SMP combined IPI handler semantics, but runs locally o= n UP. + */ +#ifndef CONFIG_SMP +void migrate_flush_tlb_page(struct vm_area_struct *vma, + unsigned long addr) +{ + struct mm_struct *mm =3D vma->vm_mm; + int tbi_type =3D (vma->vm_flags & VM_EXEC) ? 3 : 2; + + /* + * First do the mm-context side: + * If we're currently running this mm, reload a fresh context ASN. + * Otherwise, mark context invalid. + * + * On UP, this is mostly about matching the SMP semantics and ensuring + * exec/i-cache tagging assumptions hold when compaction migrates pages. + */ + if (mm =3D=3D current->active_mm) + flush_tlb_current(mm); + else + flush_tlb_other(mm); + + /* + * Then do the immediate translation kill for this VA. + * For exec mappings, order instruction fetch after invalidation. + */ + tbi(tbi_type, addr); +} + +#else +struct tlb_mm_and_addr { + struct mm_struct *mm; + unsigned long addr; + int tbi_type; /* 2 =3D DTB, 3 =3D ITB+DTB */ +}; + +static void ipi_flush_mm_and_page(void *x) +{ + struct tlb_mm_and_addr *d =3D x; + + /* Part 1: mm context side (Alpha uses ASN/context as a key mechanism). */ + if (d->mm =3D=3D current->active_mm && !asn_locked()) + __load_new_mm_context(d->mm); + else + flush_tlb_other(d->mm); + + /* Part 2: immediate per-VA invalidation on this CPU. */ + tbi(d->tbi_type, d->addr); +} + +void migrate_flush_tlb_page(struct vm_area_struct *vma, unsigned long addr) +{ + struct mm_struct *mm =3D vma->vm_mm; + struct tlb_mm_and_addr d =3D { + .mm =3D mm, + .addr =3D addr, + .tbi_type =3D (vma->vm_flags & VM_EXEC) ? 3 : 2, + }; + + /* + * One synchronous rendezvous: every CPU runs ipi_flush_mm_and_page(). + * This is the "combined" version of flush_tlb_mm + per-page invalidate. + */ + preempt_disable(); + on_each_cpu(ipi_flush_mm_and_page, &d, 1); + + /* + * mimic flush_tlb_mm()'s mm_users<=3D1 optimization. + */ + if (atomic_read(&mm->mm_users) <=3D 1) { + + int cpu, this_cpu; + this_cpu =3D smp_processor_id(); + + for (cpu =3D 0; cpu < NR_CPUS; cpu++) { + if (!cpu_online(cpu) || cpu =3D=3D this_cpu) + continue; + if (READ_ONCE(mm->context[cpu])) + WRITE_ONCE(mm->context[cpu], 0); + } + } + preempt_enable(); +} + +#endif --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0510733EAEA; Sat, 28 Feb 2026 17:34:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300062; cv=none; b=BFf3JnblGZ9+PKkZnkGyXdQU2vbhWBgU6YHRETvaJrylFwPYQCdcjzmGq9+GeAHcR5MvD9PXP6aJsUJrBTppCSeBW/jxO6E+5TnpKoMJFlvxrmtnKt8dCzvcqWbLEen0bBzZfBmDxSTeOvpclWayysRSCuc0zLnvtfpYLWVlluA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300062; c=relaxed/simple; bh=sUj53CCzyRZ+Nl+bD3YaS0/JzC1/MC3O53QNnmpsXGw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jMd5AqqE2Jh+u7RcjcCDsfnFBJT/lWsRbyODNKVUH+91U98NI02tEAqRM0DP4r94ar1er4sOIU5ulKddTMSd4jNOkHTN9/JkksS3zcacb/ogjEWslzSEf2VlItKPiCTd9qKS8hHhqCr7P7Afmar9eb9IX5wrlxTIsWVuwLoSSoM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rYjHnJZ7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rYjHnJZ7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03DE4C116D0; Sat, 28 Feb 2026 17:34:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300061; bh=sUj53CCzyRZ+Nl+bD3YaS0/JzC1/MC3O53QNnmpsXGw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rYjHnJZ7sRuv4STALOj1YTLTJWPUEK7JZr/3UCgWg1XXGHbpfUO1Kqd6AtSock5Kb U+yn0vnYAz1CdXemZUNVsU9u3GHscGYxLynXLwXC7ByxIVTEwqtHGmRYoi1gdnzL1B 8lx7hAGmELZF81WsqkSkTb1lRxgDZBMPgCcZJDcQIZmPr1hGhH6wp54Sa/7cslnM85 0GP7JsOdaYlTKlexlkE3yOVkbvrh+d6Kpq9H4CP/LCF79XYjM0GUV434Ucyl/cYMXi 3nK3Sj+1SLR+z0oaqOOj7iIK/Ai2eR1/0JoKMdjeH+3T+KEfQh9Wb8LCF8gz018emI V+C17JwTP7Jkg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiasheng Jiang , Yu Kuai , Sasha Levin Subject: [PATCH 6.19 075/844] md-cluster: fix NULL pointer dereference in process_metadata_update Date: Sat, 28 Feb 2026 12:19:48 -0500 Message-ID: <20260228173244.1509663-76-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiasheng Jiang [ Upstream commit f150e753cb8dd756085f46e86f2c35ce472e0a3c ] The function process_metadata_update() blindly dereferences the 'thread' pointer (acquired via rcu_dereference_protected) within the wait_event() macro. While the code comment states "daemon thread must exist", there is a valid race condition window during the MD array startup sequence (md_run): 1. bitmap_load() is called, which invokes md_cluster_ops->join(). 2. join() starts the "cluster_recv" thread (recv_daemon). 3. At this point, recv_daemon is active and processing messages. 4. However, mddev->thread (the main MD thread) is not initialized until later in md_run(). If a METADATA_UPDATED message is received from a remote node during this specific window, process_metadata_update() will be called while mddev->thread is still NULL, leading to a kernel panic. To fix this, we must validate the 'thread' pointer. If it is NULL, we release the held lock (no_new_dev_lockres) and return early, safely ignoring the update request as the array is not yet fully ready to process it. Link: https://lore.kernel.org/linux-raid/20260117145903.28921-1-jiashengjia= ngcool@gmail.com Signed-off-by: Jiasheng Jiang Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/md-cluster.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c index 11f1e91d387d8..896279988dfd5 100644 --- a/drivers/md/md-cluster.c +++ b/drivers/md/md-cluster.c @@ -549,8 +549,13 @@ static void process_metadata_update(struct mddev *mdde= v, struct cluster_msg *msg =20 dlm_lock_sync(cinfo->no_new_dev_lockres, DLM_LOCK_CR); =20 - /* daemaon thread must exist */ thread =3D rcu_dereference_protected(mddev->thread, true); + if (!thread) { + pr_warn("md-cluster: Received metadata update but MD thread is not ready= \n"); + dlm_unlock_sync(cinfo->no_new_dev_lockres); + return; + } + wait_event(thread->wqueue, (got_lock =3D mddev_trylock(mddev)) || test_bit(MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD, &cinfo->state)); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 89078492188; Sat, 28 Feb 2026 17:34:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300062; cv=none; b=t3mzIQnDlPC9KI6C+DTEhajAeP7dSP5ePA8p6YyFHPEmw5p4Y1hbKUmleoc8W5LBWFpmUFPgLXAgEVqazogXzsIu6KDeIg/kDCh7I7LjcdlNwHSepue/EELB1AM2E49ynqB/XmEAedjLdi5k0mMmnQM9Yr8USJDVLcW30MXHFlA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300062; c=relaxed/simple; bh=tJNJ6IxtqMjafIYy7IX3Ga8HA564+B01cMNRrZI8zW0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WhA3AhnFyGoe785I/Ij2qCMAqajghwwNI3UMNeRmEEJgbydpgJGvNGNfncpHoy0VsEHDLhanWAQN532NeyQSEYlBBAtUeh1krOtjPuAG627/0lCOXxJhQ8o5oGCwNXye+QsJlJTTS+OXmQnMHn7bD/v1NOfEwpD5AkNaWQtKnx0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Q3ua12Nn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Q3ua12Nn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D503BC19423; Sat, 28 Feb 2026 17:34:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300062; bh=tJNJ6IxtqMjafIYy7IX3Ga8HA564+B01cMNRrZI8zW0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q3ua12NnlnY1bwHa0dqq6YPFNWwn30K3EzTufGyfQNDhzGD8Q0TAK6t4byIR8cmvc VHb2cug6aN6L6ewm0UL9WbB1pP8+06hCF0f6adZInc/VBpRlxPjFY8Rpo+WPlzW4uI hgHEXXYNdrHUR/Spoc/NGDJNDpiM+U1kgGFahP6ODvoCidyJtQWVqImeHt/ytvbtf9 9yVm1aDnxW0B6otuT0AyUprF92jbxlrHi95RHKrYllLI5Snz3CzqqvRwLfACJXylz1 3O3Z189pu0KQd8dwZt7nYPsLrqp2B3YnXFcQcb5YHsYME96Iqo90/dJAdaMzisDyps wS2ZzWijltoqg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Heinz Mauelshagen , Yu Kuai , Sasha Levin Subject: [PATCH 6.19 076/844] md raid: fix hang when stopping arrays with metadata through dm-raid Date: Sat, 28 Feb 2026 12:19:49 -0500 Message-ID: <20260228173244.1509663-77-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Heinz Mauelshagen [ Upstream commit cefcb9297fbdb6d94b61787b4f8d84f55b741470 ] When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions. This occurs when: - A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices) - The top-level RAID device is then removed Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-int= ent operations and causing an indefinite block. Fix: - Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O - Still allow write-intent bitmap flushing when called from dm-raid suspend context This ensures that RAID array teardown can complete successfully even when t= he underlying devices are in a suspended state. This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above. Link: https://lore.kernel.org/linux-raid/CAM23VxqYrwkhKEBeQrZeZwQudbiNey2_8= B_SEOLqug=3DpXxaFrA@mail.gmail.com Signed-off-by: Heinz Mauelshagen Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/md.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 6d73f6e196a9f..ac71640ff3a81 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -6848,13 +6848,15 @@ static void __md_stop_writes(struct mddev *mddev) { timer_delete_sync(&mddev->safemode_timer); =20 - if (mddev->pers && mddev->pers->quiesce) { - mddev->pers->quiesce(mddev, 1); - mddev->pers->quiesce(mddev, 0); - } + if (md_is_rdwr(mddev) || !mddev_is_dm(mddev)) { + if (mddev->pers && mddev->pers->quiesce) { + mddev->pers->quiesce(mddev, 1); + mddev->pers->quiesce(mddev, 0); + } =20 - if (md_bitmap_enabled(mddev, true)) - mddev->bitmap_ops->flush(mddev); + if (md_bitmap_enabled(mddev, true)) + mddev->bitmap_ops->flush(mddev); + } =20 if (md_is_rdwr(mddev) && ((!mddev->in_sync && !mddev_is_clustered(mddev)) || --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C4E85492521; Sat, 28 Feb 2026 17:34:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300063; cv=none; b=loocchFKkmthzH0Zsob06jf0tvk41C3ZPJ4XFpHpagXNvRKPu6vORJC5iD8U4kz7WJGdckMlKkxjQC/DDG8BHisQfYeW3eZlzPTskdNGkHdt+fpZ2+CECfn9a733SJoiwEQGeTYl09aEJDO1diDhSMA3OEpob8ku5KanovFDHUw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300063; c=relaxed/simple; bh=pqOKYIqpNgvGVcdU0f2NquL1lyA2LhxfoqCDro18LU0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Scp+2njp1gPyN+WObFgQgWs8U/+mLj9mNnrT7bbAA6dw4Zo6xObCT758JORg19JSDmbgaol88IVg/xMYlFaThUklyQ3tbtiacPd35gyE6VgC8w/mjmPsaQoCTcvaYHjUHXtGJMtDApU0IX3/KeIFmBL0FXvew/6+bS11908W6IA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N3S89Drt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N3S89Drt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2AAAC116D0; Sat, 28 Feb 2026 17:34:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300063; bh=pqOKYIqpNgvGVcdU0f2NquL1lyA2LhxfoqCDro18LU0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N3S89Drthuc0TEZZl5PbMTaV8vPLJ8pNK8eZG9o4GNPbwC1lYObWApAlTHtDvAnLw yCuZcps7uEibQA8VYD1LcmSlP9+vwA/azLEQGT31ovV9aC6HysT9Fye89I02z5fmcf TtHlUpoHrfcPQugr/IEgeeRbghIxMtF3TXsSF6LFrFZ1ls4Z+DYkrBLnRxUyZpzsBL n4O7b7nLLLtEbUNGp/jDvgBE+Gv4IeLuKWHo1YQHFkXUw9eJH2lm5GHY4xc21QaedY 8JS0/G+lunJ7kVmiU385YWNM6Ppcz9Z1u1cEYXeFRVWo+2qqOWKSVL2LoHz8HQ1LB3 IV/1kSp8GdMnw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alexandre Courbot , Daniel Almeida , Viresh Kumar , Sasha Levin Subject: [PATCH 6.19 077/844] rust: cpufreq: always inline functions using build_assert with arguments Date: Sat, 28 Feb 2026 12:19:50 -0500 Message-ID: <20260228173244.1509663-78-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexandre Courbot [ Upstream commit 8c8b12a55614ea05953e8d695e700e6e1322a05d ] `build_assert` relies on the compiler to optimize out its error path. Functions using it with its arguments must thus always be inlined, otherwise the error path of `build_assert` might not be optimized out, triggering a build error. Signed-off-by: Alexandre Courbot Reviewed-by: Daniel Almeida Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- rust/kernel/cpufreq.rs | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs index f968fbd228905..0879a79485f8e 100644 --- a/rust/kernel/cpufreq.rs +++ b/rust/kernel/cpufreq.rs @@ -1015,6 +1015,8 @@ impl Registration { ..pin_init::zeroed() }; =20 + // Always inline to optimize out error path of `build_assert`. + #[inline(always)] const fn copy_name(name: &'static CStr) -> [c_char; CPUFREQ_NAME_LEN] { let src =3D name.to_bytes_with_nul(); let mut dst =3D [0; CPUFREQ_NAME_LEN]; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9289833E367; Sat, 28 Feb 2026 17:34:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300064; cv=none; b=uTxzol2sEQd/PgWFF/1PP9ykW80wbbeMm+3eSHesUC6Rbqs3xvJJuICsINlNKVWAtH3pqMYhdK3iNdVX+QdMfoKgWs9ObMYABIyeURAD5lZTcyKgnsB+bzq4n0oaMHVibYe8+8XeofsubPMQPSwMY7a6K3duLR/SBQDzToFjhr0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300064; c=relaxed/simple; bh=PCEMzzxLXGpmxcOlMeVYiq+8d2ssX8aaUrN3TwllnxA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LZV3w/ybSD6nQIoj3wc2HErsOnrFMv85Yet7F+q072OstgWQ+MjYTNOH4TZiQqAvq49GCfQXrEe4AQBRk8VCaHRdE/WcSoXnOEGiM7+2SZ8SvC2cRV/5/QrAWVk83hVxHyQcFrrfaIKYtbJYQYsfbKMxF/E0XV5Axux8DUFMu/s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WtYoipL+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WtYoipL+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7562C2BC9E; Sat, 28 Feb 2026 17:34:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300064; bh=PCEMzzxLXGpmxcOlMeVYiq+8d2ssX8aaUrN3TwllnxA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WtYoipL+/bed/4u26hdffaFdLEa4x2d7/5aPA26IACpUBl8LYbJMHvi1K5+xMH4gO hnqZyjI5IjOgRIhAHKRgUGyuvySj63zQFRbAhFtdTMK1bf8NXJWtYMWS378q80C/1+ ReyG00NLG9wXUbwPFsN0p+h3jHkkz1ldEK1Vt3jgbIq5i8TMuZy9JyV6WUkeeAEa1E atVRR9fBxrr6FbReQgpIBlEFZvjDaamHwJ0pb8QAdUKU5mhkqYVO1quFQsdDP34OY0 l0nPqn6XvGoD90TmFM+7ZS6DAeQg2kymEvcOj7KybGYTxLnLUw9ZHKz+uhaAHGcvPd PyATAi0Byn8Eg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Viresh Kumar , Sasha Levin Subject: [PATCH 6.19 078/844] cpufreq: dt-platdev: Block the driver from probing on more QC platforms Date: Sat, 28 Feb 2026 12:19:51 -0500 Message-ID: <20260228173244.1509663-79-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 7b781899072c5701ef9538c365757ee9ab9c00bd ] Add a number of QC platforms to the blocklist, they all use either the qcom-cpufreq-hw driver. Signed-off-by: Konrad Dybcio Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq= -dt-platdev.c index b06a43143d23c..2fecab989dacc 100644 --- a/drivers/cpufreq/cpufreq-dt-platdev.c +++ b/drivers/cpufreq/cpufreq-dt-platdev.c @@ -169,8 +169,11 @@ static const struct of_device_id blocklist[] __initcon= st =3D { { .compatible =3D "qcom,sdm845", }, { .compatible =3D "qcom,sdx75", }, { .compatible =3D "qcom,sm6115", }, + { .compatible =3D "qcom,sm6125", }, + { .compatible =3D "qcom,sm6150", }, { .compatible =3D "qcom,sm6350", }, { .compatible =3D "qcom,sm6375", }, + { .compatible =3D "qcom,sm7125", }, { .compatible =3D "qcom,sm7225", }, { .compatible =3D "qcom,sm7325", }, { .compatible =3D "qcom,sm8150", }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C96A4949F4; Sat, 28 Feb 2026 17:34:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300065; cv=none; b=ED4qeg8O3kUHrTP5nizK8vhWW3TbN+F/DGardwZ37J7RaIeknpxzSAHxJTDRPTBck4+CLeYfjWp4qisFjKMB5ravxfgXawquzkRyM8pWm7STCnBDCoHFqrdMjycEMfSo4AICXDeQmSqz8wJJWmbUEQb2T9W04So/7IXI3E88EGo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300065; c=relaxed/simple; bh=0MZBtuNaedMgvgH2TwTNzAS+vPFC78vsJmzGEl2nJmE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RzC2duILn2RjEWTn1/ipHuq8LboZsMeKTYKbwR3lqw0C6JCz1ylCha5UsNkgReSJk18FvPFTvHrK3ILVMAMa9YI9kC6Bz3oAHS+NnNVhCau1yfKXFWcINCb1Ti7bjygmI+IwCuyQ+KCT/c9bVErAQGaU0Px4q2z+eYN4x2L5fF4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nAVrkk2M; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nAVrkk2M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83987C19424; Sat, 28 Feb 2026 17:34:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300065; bh=0MZBtuNaedMgvgH2TwTNzAS+vPFC78vsJmzGEl2nJmE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nAVrkk2MmBfRE1qpxhXWXvJjs0EfHBGK7NAgWgYxe1v2PpsRBUxHwBwQjULLmNV+y GhYA6edTnqIzFMxQJ+2bxwkAKHp7Yc4rFSPeekk//QYSY1cddZMIz7ViYMGZX8Sqml rbZE3VG3MZ3q8PPj2Dc1dxw/3p6BboLY7Lh8qgtLB8EFmZypx2LUit8tsvdB79RB/W srbnoPn1wiRBDNZ6SQQFFvaHSiyvWiz8LXK0hc7k3u0y2b6Dt5f0s2EeXllkltvJDd d3pw6CbSt6LYjNlyqTFsLBB4XOcSiQA8IfEMAz+l7jMFJNYtBUjcCkJm3TcZ6i3H5m v2rb3DcOaAR7Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Richter , Jan Polensky , Heiko Carstens , Sasha Levin Subject: [PATCH 6.19 079/844] s390/perf: Disable register readout on sampling events Date: Sat, 28 Feb 2026 12:19:52 -0500 Message-ID: <20260228173244.1509663-80-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Richter [ Upstream commit b2c04fc1239062b39ddfdd8731ee1a10810dfb74 ] Running commands # ./perf record -IR0,R1 -a sleep 1 extracts and displays register value of general purpose register r1 and r0. However the value displayed of any register is random and does not reflect the register value recorded at the time of the sample interrupt. The sampling device driver on s390 creates a very large buffer for the hardware to store the samples. Only when that large buffer gets full an interrupt is generated and many hundreds of sample entries are processed and copied to the kernel ring buffer and eventually get copied to the perf tool. It is during the copy to the kernel ring buffer that each sample is processed (on s390) and at that time the register values are extracted. This is not the original goal, the register values should be read when the samples are created not when the samples are copied to the kernel ring buffer. Prevent this event from being installed in the first place and return -EOPNOTSUPP. This is already the case for PERF_SAMPLE_REGS_USER. Signed-off-by: Thomas Richter Reviewed-by: Jan Polensky Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/s390/kernel/perf_cpum_sf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/kernel/perf_cpum_sf.c b/arch/s390/kernel/perf_cpum_s= f.c index 459af23a47a5e..e8bd19ac82c7d 100644 --- a/arch/s390/kernel/perf_cpum_sf.c +++ b/arch/s390/kernel/perf_cpum_sf.c @@ -841,7 +841,7 @@ static bool is_callchain_event(struct perf_event *event) u64 sample_type =3D event->attr.sample_type; =20 return sample_type & (PERF_SAMPLE_CALLCHAIN | PERF_SAMPLE_REGS_USER | - PERF_SAMPLE_STACK_USER); + PERF_SAMPLE_REGS_INTR | PERF_SAMPLE_STACK_USER); } =20 static int cpumsf_pmu_event_init(struct perf_event *event) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B412494A0D; Sat, 28 Feb 2026 17:34:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300066; cv=none; b=AgUd93dXNZ5LX8DMKt3fKUsu0Ii9ibVFdEgFvE0yQt7V35x9fn2D1JygXpFjf9+zPzHlMT0JrtRF3nWQQbF9DKddAJWuI1ab26K4mRI4RKQqQR2ANqyKV4LGdRcO6kw2WcKCVwzHVDeCnjEE1PIoLkKKzcg4obrdp3lq3EPB5lU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300066; c=relaxed/simple; bh=9WitjgVvnfmCaDPrPZhij7/m17PwDVIt3q1JqDXF3A0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=REuQ6r8mjR3HZuvtD1yLFsgqyhxT7evBI8VKHoryiUJ8OYfgjqqvWGCD/Igjc77Z6dLvue5XH2jbRITm262hVLzHkFRSKjJuu05KOwFFB7jRVl7HBIgXNAeDcderzOVzzrcKzHkPTcJYP5X2wOM32TS0m9uysjTNPbRlxFB21BI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oPNHucj0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oPNHucj0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D88FC19423; Sat, 28 Feb 2026 17:34:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300066; bh=9WitjgVvnfmCaDPrPZhij7/m17PwDVIt3q1JqDXF3A0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oPNHucj0dyOvcC4TD8gCjnsbx3pp3Zq+XYsOmCxrUzLV0HBI1kbefb8JlgfYhoM41 H6N5h0UYVWcU/iLpku53CgsJfyCaw4Zi5H/uU/NpgLXw5qUrtAE7CWGVdwjwb+HHZu ldu3vv/oXNsHoD9L8Agt4KBMa8qWbh5ZtaX+e3SESjGxP6Py2BSYD7qtp+yxaSNqsD M2/FMWx14nAq7zniPeiYH6r2zuea6ZybfDkTudx3plD6JcVm1FGZKpoZqY2sBiN1lk /8DBgF2Kg8S13jkpw4YOxVqGpuUaHkIYN5TWcT2rHidaL/a6Sb4Jy1A7DrKCG5xUtc u4ihT1UtlZRcw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Carl Worth , Taehyun Noh , Catalin Marinas , Will Deacon , Sasha Levin Subject: [PATCH 6.19 080/844] arm64: mte: Set TCMA1 whenever MTE is present in the kernel Date: Sat, 28 Feb 2026 12:19:53 -0500 Message-ID: <20260228173244.1509663-81-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Carl Worth [ Upstream commit a4e5927115f30a301f9939ed43e6a21a343e06ad ] Set the TCMA1 bit so that access to TTBR1 addresses with 0xf in their tag bits will be treated as tag unchecked. This is important to avoid unwanted tag checking on some systems. Specifically, SCTLR_EL1.TCF can be set to indicate that no tag check faults are desired. But the architecture doesn't guarantee that in this case the system won't still perform tag checks. Use TCMA1 to ensure that undesired tag checks are not performed. This bit was already set in the KASAN case. Adding it to the non-KASAN case prevents tag checking since all TTBR1 address will have a value of 0xf in their tag bits. This patch has been measured on an Ampere system to improve the following: * Eliminate over 98% of kernel-side tag checks during "perf bench futex hash", as measured with "perf stat". * Eliminate all MTE overhead (was previously a 25% performance penalty) from the Phoronix pts/memcached benchmark (1:10 Set:Get ration with 96 cores). Reported-by: Taehyun Noh Suggested-by: Catalin Marinas Signed-off-by: Carl Worth Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/mm/proc.S | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S index 5d907ce3b6d3f..22866b49be372 100644 --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -48,14 +48,14 @@ #define TCR_KASAN_SW_FLAGS 0 #endif =20 -#ifdef CONFIG_KASAN_HW_TAGS -#define TCR_MTE_FLAGS TCR_EL1_TCMA1 | TCR_EL1_TBI1 | TCR_EL1_TBID1 -#elif defined(CONFIG_ARM64_MTE) +#ifdef CONFIG_ARM64_MTE /* * The mte_zero_clear_page_tags() implementation uses DC GZVA, which relie= s on - * TBI being enabled at EL1. + * TBI being enabled at EL1. TCMA1 is needed to treat accesses with the + * match-all tag (0xF) as Tag Unchecked, irrespective of the SCTLR_EL1.TCF + * setting. */ -#define TCR_MTE_FLAGS TCR_EL1_TBI1 | TCR_EL1_TBID1 +#define TCR_MTE_FLAGS TCR_EL1_TCMA1 | TCR_EL1_TBI1 | TCR_EL1_TBID1 #else #define TCR_MTE_FLAGS 0 #endif --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93B00495509; Sat, 28 Feb 2026 17:34:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300067; cv=none; b=ML2xzXh02LsSeT2f3dczatk+nhCeHsMoAkJf/QIeCH+atEzkGQCNbQaZk+/TTM02bIj7o/nBst1K9YfNKP3lpFc4jpoIJFKOOIEWwKwAB219fdfyvdyp+6Xt83RoQIQkQoVqcnb9Dn2JasEgdh1MGBlE5HIO1qDSsm/Q5K3dOtk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300067; c=relaxed/simple; bh=pOvG3Od1IZRVUetc72P1RuXm0cu7iWlVDHRtFCIDi3Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pgHDsN23ncy1KefRIB4jU5wDRIcu+OK4RWki0t1o3KtRt6aWuvNnS8fIO3WWZmBSbdUJ4uRaP10B6GLOO6Ku1th3Iq6YWiq7u9em83X1SjG/RpZ3HYQXUmZsaFXho7gW/2GQbwHRGi4mHYFEzL6tDZIO3mX7fhzhz68nJM0G4Z0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aFEdc3xE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aFEdc3xE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8583CC19423; Sat, 28 Feb 2026 17:34:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300067; bh=pOvG3Od1IZRVUetc72P1RuXm0cu7iWlVDHRtFCIDi3Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aFEdc3xEXqEHnCEAtykMTNHsnoS4VamLvffWTZUAchuFM32LLr2QOwm3QTDe617k2 F0eUQ5G7x3eRvBxwtqUev0jD86QlgCT8Eymgov326ddH0uXdskLIR2nD3usjDqWaJ3 XXWXrrm/0RvwszXqiGWpEOPZFuK1c1UrpGJ3LFM3LmNBUbUJf5APUTiJL+BQjCQeSl EXyMvJRrdASiZt4l/lvWG9pa3VgBN2wiNx34BQ5BsNe1cuKUvFMOgCalDMaywZhL0o TVltWCxODg6bHHmKgruCp4Q8jYW8/YvWGG3KCMhQ7hNwLwdCumvPKu6wKJa9hKA70p nlwgRTAhiaGlg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sebastian Andrzej Siewior , Jonathan Cameron , Will Deacon , Sasha Levin Subject: [PATCH 6.19 081/844] perf/cxlpmu: Replace IRQF_ONESHOT with IRQF_NO_THREAD Date: Sat, 28 Feb 2026 12:19:54 -0500 Message-ID: <20260228173244.1509663-82-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sebastian Andrzej Siewior [ Upstream commit ab26d9c85554c4ff1d95ca8341522880ed9219d6 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also disallows force-threading of the primary handler and the irq-core will warn about this. The intention here was probably not allowing forced-threading. Replace IRQF_ONESHOT with IRQF_NO_THREAD. Reviewed-by: Jonathan Cameron Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/perf/cxl_pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/perf/cxl_pmu.c b/drivers/perf/cxl_pmu.c index d094030220bf2..68a54d97d2a8a 100644 --- a/drivers/perf/cxl_pmu.c +++ b/drivers/perf/cxl_pmu.c @@ -877,7 +877,7 @@ static int cxl_pmu_probe(struct device *dev) if (!irq_name) return -ENOMEM; =20 - rc =3D devm_request_irq(dev, irq, cxl_pmu_irq, IRQF_SHARED | IRQF_ONESHOT, + rc =3D devm_request_irq(dev, irq, cxl_pmu_irq, IRQF_SHARED | IRQF_NO_THRE= AD, irq_name, info); if (rc) return rc; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CC5B494A1E; Sat, 28 Feb 2026 17:34:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300068; cv=none; b=BPR6ucZSxS1yLZPmHN0LS3kw0VBEAMPrqlNJili8OW+5+D5Yj4aeCWM0MZ2OOJ4xZrS41rx3R9KCSqLhAxj8Gys3uDBLzHh0jHh3GKaU7r18yWunBTjhgqrV4zjHN22HdeR6CJDRHrT4OaTAlYrxam4lz7MLawB6ih4E4rMFw6I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300068; c=relaxed/simple; bh=Mcfvj2nZM5JB64KW50/Cmp3FQ/BWsJZ+wF1KoAyR0zo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EyPAXQjknNuNvecKc5LBP0dNbPbuTDmfjnhJXt2wNggiCWvT0ViUDixsk8KwDTOqJxu9yWgt0VE3kBGT6xhr4Wqdhdo8T2vdAtml2vt9x4RB5E94rbWUAhL9tqwOjdnaV6yIiSUc/ipi3YDB/jUSikOMHdxALCdc4+swqFftEO0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BvqFzOZJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BvqFzOZJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BA43C116D0; Sat, 28 Feb 2026 17:34:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300068; bh=Mcfvj2nZM5JB64KW50/Cmp3FQ/BWsJZ+wF1KoAyR0zo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BvqFzOZJ6BzJBpk554CNm/F5FySYKyHXH1osnflUoz7EtDYXxXr+pIP2RQU9NpLS3 KaA5b5ZnyUqEDY30fK+9ZqA8jrKtH4FeSgZZXvZ9kfzc2EpT84bY3C48ERu7TrC6cN QIImDJsXQzDflCXAloOqi9QKJu0hx3oIr4Gp50+gmFQ329wej8jfpkYo6dCT9s7kDA SAikbG63IDpc0pJgAVcRCBPFe8qAhPsP4cTn+L8PZn6ZkV3u0EbK+QUMue7yPF+zGY 859OZp4lMpEAS5cZDcjJC1jK7NSjzHgcQUES1QyMLcsZ4v46N+6eeVZ/SAiGVsc5I7 SUV23tC2a8zRg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jakob Riemenschneider , Antheas Kapenekakis , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 082/844] ACPI: x86: s2idle: Invoke Microsoft _DSM Function 9 (Turn On Display) Date: Sat, 28 Feb 2026 12:19:55 -0500 Message-ID: <20260228173244.1509663-83-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jakob Riemenschneider [ Upstream commit 229ecbaac6b31f89c554b77eb407377a5eade7d4 ] Windows 11, version 22H2 introduced a new function index (Function 9) to the Microsoft LPS0 _DSM, titled "Turn On Display Notification". According to Microsoft documentation, this function signals to the system firmware that the OS intends to turn on the display when exiting Modern Standby. This allows the firmware to release Power Limits (PLx) earlier. Crucially, this patch fixes a functional issue observed on the Lenovo Yoga Slim 7i Aura (15ILL9), where system fans and keyboard backlights fail to resume after suspend. Investigation linked shows the EC on this device turns off these components during sleep but requires the Function 9 notification to wake them up again. This patch defines the new function index (ACPI_MS_TURN_ON_DISPLAY) and invokes it in acpi_s2idle_restore_early_lps0(). The execution order is updated to match the logic of an "intent" signal: 1. LPS0 Exit (Function 6) 2. Turn On Display Intent (Function 9) 3. Modern Standby Exit (Function 8) 4. Screen On (Function 4) Invoking Function 9 before the Modern Standby Exit ensures the firmware has time to restore power rails and functionality (like fans) before the software fully exits the sleep state. Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-expe= riences/modern-standby-firmware-notifications#turn-on-display-notification-= function-9 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D220505 Suggested-by: Antheas Kapenekakis Signed-off-by: Jakob Riemenschneider Link: https://patch.msgid.link/20260127200121.1292216-1-riemenschneiderjako= b@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/x86/s2idle.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c index cc3c83e4cc23b..2189330ffc6d3 100644 --- a/drivers/acpi/x86/s2idle.c +++ b/drivers/acpi/x86/s2idle.c @@ -49,6 +49,7 @@ static const struct acpi_device_id lps0_device_ids[] =3D { #define ACPI_LPS0_EXIT 6 #define ACPI_LPS0_MS_ENTRY 7 #define ACPI_LPS0_MS_EXIT 8 +#define ACPI_MS_TURN_ON_DISPLAY 9 =20 /* AMD */ #define ACPI_LPS0_DSM_UUID_AMD "e3f32452-febc-43ce-9039-932122d37721" @@ -356,6 +357,8 @@ static const char *acpi_sleep_dsm_state_to_str(unsigned= int state) return "lps0 ms entry"; case ACPI_LPS0_MS_EXIT: return "lps0 ms exit"; + case ACPI_MS_TURN_ON_DISPLAY: + return "lps0 ms turn on display"; } } else { switch (state) { @@ -617,6 +620,9 @@ static void acpi_s2idle_restore_early_lps0(void) if (lps0_dsm_func_mask_microsoft > 0) { acpi_sleep_run_lps0_dsm(ACPI_LPS0_EXIT, lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft); + /* Intent to turn on display */ + acpi_sleep_run_lps0_dsm(ACPI_MS_TURN_ON_DISPLAY, + lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft); /* Modern Standby exit */ acpi_sleep_run_lps0_dsm(ACPI_LPS0_MS_EXIT, lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 23E17495533; Sat, 28 Feb 2026 17:34:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300069; cv=none; b=FCLlgFzGVufEnUzRH4mRE04Ft5ml7uzyINEDm5UvIIkCDhvYNYA4HyuRgBsjrC7qTUXbQhmXiFNfS9eUm5B+Hc0RvlAvpJIbD/d5Cm2sdsL5vJIcg/NzAiIeIidegk5nW2ioYFaSMNTQcwUSqbDnRX2zNpWnOVHltGKP5xzXBmY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300069; c=relaxed/simple; bh=2pipMRddz6ailbs3zM8XCtd8z26OQ4v2LeH8oipn5UU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JHzvhsNZpWLbMSEaZlE3y/Y79ET0LIm0cvxFRA2iOdDgmjWV/idJiaB/le9KfbX+IQN461cIAG6SSTTF6KWZH1aZc3QC1D8TZxrN9Ds2GVIKgyD59GmTI8W2UpNc45r0YCl6Zjxrh0L0vJRVGEQNkLrXTxl20XxVaaGFk38G1mA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hWI/Fi4c; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hWI/Fi4c" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71E94C4AF0B; Sat, 28 Feb 2026 17:34:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300069; bh=2pipMRddz6ailbs3zM8XCtd8z26OQ4v2LeH8oipn5UU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hWI/Fi4cHHU97E+Us3UEjdk28loRMIZCK9tKLGak7LC0jeO1ncqEpJQRRIXe16QeT wCQn6ptnP2ZjdyGNnnCr71Qz1tWGT8k81K/r5NCGGJrDtMDMZFtNWA+gVyhNeI3S1u MvMKySD9jrduVLlkMnCGeCKTzLmVRLSBUFM+C9Vw8YJbPLBAU6V8QUi4uz2IIF1ktd Zj1cF2d6I4zDUe2dweNMzU5emxe0Rizkud1o4XkLqQMHpOIVrHX/lIWa7+Ivp7fINF Vwi9IJ+QAsF+QM64rT4O1Fzm8jSov1llwaydVwf3Guqwlet0lHeSdm4blZKV0yTXiV Ckmoj3F+sZuug== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yicong Yang , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 083/844] ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn() Date: Sat, 28 Feb 2026 12:19:56 -0500 Message-ID: <20260228173244.1509663-84-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yicong Yang [ Upstream commit 7cf28b3797a81b616bb7eb3e90cf131afc452919 ] The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a system workqueue which is not guaranteed to be finished before entering userspace. This may cause some key devices to be missing when userspace init task tries to find them. Two issues observed on RISCV platforms: - Kernel panic due to userspace init cannot have an opened console. The console device scanning is queued by acpi_scan_clear_dep_queue() and not finished by the time userspace init process running, thus by the time userspace init runs, no console is present. - Entering rescue shell due to the lack of root devices (PCIe nvme in our case). Same reason as above, the PCIe host bridge scanning is queued on a system workqueue and finished after init process runs. The reason is because both devices (console, PCIe host bridge) depend on riscv-aplic irqchip to serve their interrupts (console's wired interrupt and PCI's INTx interrupts). In order to keep the dependency, these devices are scanned and created after initializing riscv-aplic. The riscv-aplic is initialized in device_initcall() and a device scan work is queued via acpi_scan_clear_dep_queue(), which is close to the time userspace init process is run. Since system_dfl_wq is used in acpi_scan_clear_dep_queue() with no synchronization, the issues will happen if userspace init runs before these devices are ready. The solution is to wait for the queued work to complete before entering userspace init. One possible way would be to use a dedicated workqueue instead of system_dfl_wq, and explicitly flush it somewhere in the initcall stage before entering userspace. Another way is to use async_schedule_dev_nocall() for scanning these devices. It's designed for asynchronous initialization and will work in the same way as before because it's using a dedicated unbound workqueue as well, but the kernel init code calls async_synchronize_full() right before entering userspace init which will wait for the work to complete. Compared to a dedicated workqueue, the second approach is simpler because the async schedule framework takes care of all of the details. The ACPI code only needs to focus on its job. A dedicated workqueue for this could also be redundant because some platforms don't need acpi_scan_clear_dep_queue() for their device scanning. Signed-off-by: Yicong Yang [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart= .com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/scan.c | 41 +++++++++++++++-------------------------- 1 file changed, 15 insertions(+), 26 deletions(-) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 416d87f9bd107..b78f6be2f9468 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -5,6 +5,7 @@ =20 #define pr_fmt(fmt) "ACPI: " fmt =20 +#include #include #include #include @@ -2360,46 +2361,34 @@ static int acpi_dev_get_next_consumer_dev_cb(struct= acpi_dep_data *dep, void *da return 0; } =20 -struct acpi_scan_clear_dep_work { - struct work_struct work; - struct acpi_device *adev; -}; - -static void acpi_scan_clear_dep_fn(struct work_struct *work) +static void acpi_scan_clear_dep_fn(void *dev, async_cookie_t cookie) { - struct acpi_scan_clear_dep_work *cdw; - - cdw =3D container_of(work, struct acpi_scan_clear_dep_work, work); + struct acpi_device *adev =3D to_acpi_device(dev); =20 acpi_scan_lock_acquire(); - acpi_bus_attach(cdw->adev, (void *)true); + acpi_bus_attach(adev, (void *)true); acpi_scan_lock_release(); =20 - acpi_dev_put(cdw->adev); - kfree(cdw); + acpi_dev_put(adev); } =20 static bool acpi_scan_clear_dep_queue(struct acpi_device *adev) { - struct acpi_scan_clear_dep_work *cdw; - if (adev->dep_unmet) return false; =20 - cdw =3D kmalloc(sizeof(*cdw), GFP_KERNEL); - if (!cdw) - return false; - - cdw->adev =3D adev; - INIT_WORK(&cdw->work, acpi_scan_clear_dep_fn); /* - * Since the work function may block on the lock until the entire - * initial enumeration of devices is complete, put it into the unbound - * workqueue. + * Async schedule the deferred acpi_scan_clear_dep_fn() since: + * - acpi_bus_attach() needs to hold acpi_scan_lock which cannot + * be acquired under acpi_dep_list_lock (held here) + * - the deferred work at boot stage is ensured to be finished + * before userspace init task by the async_synchronize_full() + * barrier + * + * Use _nocall variant since it'll return on failure instead of + * run the function synchronously. */ - queue_work(system_dfl_wq, &cdw->work); - - return true; + return async_schedule_dev_nocall(acpi_scan_clear_dep_fn, &adev->dev); } =20 static void acpi_scan_delete_dep_data(struct acpi_dep_data *dep) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40A974963AD; Sat, 28 Feb 2026 17:34:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300070; cv=none; b=Sg6ibb6EarVyyxZ+Alb5aCO/BYpvw0MwzwB5vLp53IMYxppvhc3KW5ypvAZMb3gps5rpSwiVJoozh8coZ0H1UDbzL5r0VgeCEQLCvVBcmeEVRRz0DsMvIhR3imRxdX5aN8WGZYI2zyK/cfsaITkY3c7zPerkPf/0X9FLUNIG/6w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300070; c=relaxed/simple; bh=UR2i7G4HhfAb4y8Ra8SYvSvCSZT6TKtawcwG5ZL5Fs4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RoPUZLAD3BCq5gV4f7Ut1d19n5zsoVn8CdDkigH3oH78GliQjCZR3R/iegJJy8SxDPJFOwF2O/BkhPCehyeTdta8/wj9PrUORUfRd8BGz1oPxCqTQFtnizU4EEoMfqy+q4yxRIW0IdMLkl44cMNfHN7hFSLpc8UZ3GAHv6WqiI4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RWUbJ3MW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RWUbJ3MW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B7BFC19423; Sat, 28 Feb 2026 17:34:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300069; bh=UR2i7G4HhfAb4y8Ra8SYvSvCSZT6TKtawcwG5ZL5Fs4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RWUbJ3MWm+SKJF7AL9WQbeTJyInhEWmGrMc3j7laim/9Nxwex5WEOlpTlFdB45Gdj 81akm3KtgwAhVFAwBLRqf7LAMq8cpJ5fkW0kWB4EGOc1M1h767gEH337HH+vZAIQ/D tC5i98mLSgHqQOWoH1i56Kc2RVlemHENkrgQy2hYQGv/DnKEb0TyMMFpdOCeCIS4Fj hs3TGaiW9JR8mx5aA1SpOeUbya9R3Ea2+lmdk3tFxjLTPxGB6ywOcHar8/EPrf78Mr JNMgf8kk0rB9nZFMslCwE7s9Kz/qHDZMalo1JRAPcyj1lemvhbMdbTR3vFAYoOmFiM nqA6agqEMM8iA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ata=20=C4=B0lhan=20K=C3=B6kt=C3=BCrk?= , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 084/844] ACPI: battery: fix incorrect charging status when current is zero Date: Sat, 28 Feb 2026 12:19:57 -0500 Message-ID: <20260228173244.1509663-85-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ata =C4=B0lhan K=C3=B6kt=C3=BCrk [ Upstream commit bb1256e0ddc7e9e406164319769b9f8d8389f056 ] On some laptops, such as the Huawei Matebook series, the embedded controller continues to report "Charging" status even when the charge threshold is reached and no current is being drawn. This incorrect reporting prevents the system from switching to battery power profiles, leading to significantly higher power (e.g., 18W instead of 7W during browsing) and missed remaining battery time estimation. Validate the "Charging" state by checking if rate_now is zero. If the hardware reports charging but the current is zero, report "Not Charging" to user space. Signed-off-by: Ata =C4=B0lhan K=C3=B6kt=C3=BCrk [ rjw: Whitespace fix, braces added to an inner if (), new comment rewrite ] [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260129144856.43058-1-atailhan2006@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/battery.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index 34181fa52e937..4b28ef79e6ac8 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -211,7 +211,14 @@ static int acpi_battery_get_property(struct power_supp= ly *psy, if (battery->state & ACPI_BATTERY_STATE_DISCHARGING) val->intval =3D acpi_battery_handle_discharging(battery); else if (battery->state & ACPI_BATTERY_STATE_CHARGING) - val->intval =3D POWER_SUPPLY_STATUS_CHARGING; + /* Validate the status by checking the current. */ + if (battery->rate_now !=3D ACPI_BATTERY_VALUE_UNKNOWN && + battery->rate_now =3D=3D 0) { + /* On charge but no current (0W/0mA). */ + val->intval =3D POWER_SUPPLY_STATUS_NOT_CHARGING; + } else { + val->intval =3D POWER_SUPPLY_STATUS_CHARGING; + } else if (battery->state & ACPI_BATTERY_STATE_CHARGE_LIMITING) val->intval =3D POWER_SUPPLY_STATUS_NOT_CHARGING; else if (acpi_battery_is_charged(battery)) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4EF34963BE; Sat, 28 Feb 2026 17:34:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300071; cv=none; b=Pt+OTZAU64j5UHYtCrsMOiwuv5j+h6uZo/bU1bHE7dHR9CtdBf4Z680QaqG3eQIkiyljqpX3CdcO0iG6nEajyIr/mAHGQx+idl4mXqorfgbFHJzb6fVdCwNBytvLBI23VJfFl8q82BAQR5/F4gFgGqh0B5Sw+SGRIOBozoxZNhI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300071; c=relaxed/simple; bh=yL/3J+Kc+ufBQbQo8CUEsiiz0KXUEBwUey7O3oZpMAM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HVxJqkVgoygajIf8B/l8r1DiV/NQeIs6jQ4LOvr93W5PYoIWSigz68DmoBDIQtloCrR9H1lsn3+2hfpYBfpngDfAjYx4hwuleG6YaH521g7Mol0DVrnyK5+Aw+Pg9Zcvk4d8FgXHvXZyvyjo87acQCJ9WrgQyuX+eCRmPBl5gA8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ad2/hYTj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ad2/hYTj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D069C19424; Sat, 28 Feb 2026 17:34:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300070; bh=yL/3J+Kc+ufBQbQo8CUEsiiz0KXUEBwUey7O3oZpMAM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ad2/hYTjInBeOyrWpHsERcZ2yiK9+pB84MpCKTxG54ROmfQo8FUWoPJML0Z7HGr38 Fqo1r4wZr1dQz3bTgOFz+sLNY7ddIoAPP4kHKaKn1EUnvna9CqG3Qv/v5dOlzbrbKo v/sCimfBD8etOiGxK0tV8n7lZfkvQW6h8ZLGRMjUnJF2H+afgiAEYcenZpBRCea4tS lVwSCafdHMaWAsTyAzp3DAUTPxyj6rVAFeEoPfyWIw9NsNV5ioywv19cRJxZtJRyGc cRZ4TjnP6w8ZgMREpWskB51UGGmy+gd4vnZsg8MAmr6auguXYfTDRVvl1k5n3h4QJ6 XGdPb3Aq6Gpow== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jason Andryuk , Juergen Gross , Sasha Levin Subject: [PATCH 6.19 085/844] xenbus: Use .freeze/.thaw to handle xenbus devices Date: Sat, 28 Feb 2026 12:19:58 -0500 Message-ID: <20260228173244.1509663-86-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jason Andryuk [ Upstream commit e08dd1ee49838750a514e83c0aa60cd12ba6ecbb ] The goal is to fix s2idle and S3 for Xen PV devices. A domain resuming from s3 or s2idle disconnects its PV devices during resume. The backends are not expecting this and do not reconnect. b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for suspend/ resume/chkpt") changed xen_suspend()/do_suspend() from PMSG_SUSPEND/PMSG_RESUME to PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE, but the suspend/resume callbacks remained. .freeze/restore are used with hiberation where Linux restarts in a new place in the future. .suspend/resume are useful for runtime power management for the duration of a boot. The current behavior of the callbacks works for an xl save/restore or live migration where the domain is restored/migrated to a new location and connecting to a not-already-connected backend. Change xenbus_pm_ops to use .freeze/thaw/restore and drop the .suspend/resume hook. This matches the use in drivers/xen/manage.c for save/restore and live migration. With .suspend/resume empty, PV devices are left connected during s2idle and s3, so PV devices are not changed and work after resume. Signed-off-by: Jason Andryuk Acked-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20251119224731.61497-2-jason.andryuk@amd.com> Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/xen/xenbus/xenbus_probe_frontend.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbu= s/xenbus_probe_frontend.c index 6d1819269cbe5..199917b6f77ca 100644 --- a/drivers/xen/xenbus/xenbus_probe_frontend.c +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c @@ -148,11 +148,9 @@ static void xenbus_frontend_dev_shutdown(struct device= *_dev) } =20 static const struct dev_pm_ops xenbus_pm_ops =3D { - .suspend =3D xenbus_dev_suspend, - .resume =3D xenbus_frontend_dev_resume, .freeze =3D xenbus_dev_suspend, .thaw =3D xenbus_dev_cancel, - .restore =3D xenbus_dev_resume, + .restore =3D xenbus_frontend_dev_resume, }; =20 static struct xen_bus_type xenbus_frontend =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F272E4963DD; Sat, 28 Feb 2026 17:34:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300072; cv=none; b=CD0BVv/hrzQordmEJKRctV+dcVULotd2QJ/+ntFm10PPjhWmg9GUMU8/0VXzkNOs+3QdCqyvq0t+5qtafYHDVyPte8v6hMcqDXjHRFgnSJJrz07q1AI8zIrr675l8p6iewY7hWeu/BIbXOakkq/PXqr5po3Mrq8wKy2k3NgVPMQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300072; c=relaxed/simple; bh=NJLBrRX2j4NQXdAxOknzdGN5sq8YYJbadoVPGouiUgc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bq6CCxXRJnKGyzDvVapqoE24o1V0GvZJjj4wsViAkP+YAJrC+do9f4Z6DtrhCkjz39Mg5EB0fK6gR4ZoVEEI94AmlBSCJs7TKwxWRgRyu305Iqy6RwpWqUo/TCm0Jy/rA7bmr7buyE9mY+M6wDrwxYzAOjIQNCsti8P/EcDh/O0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PKoJgdTS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PKoJgdTS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 080A5C116D0; Sat, 28 Feb 2026 17:34:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300071; bh=NJLBrRX2j4NQXdAxOknzdGN5sq8YYJbadoVPGouiUgc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PKoJgdTSiWfkQYKb3buqqp2ZlGfojiTw20RQkssXYJqiSD3OpDf1QuZjEK0A1wtbF Z4YDi/9GvVcRvaFffR/wvZdHu/Cf/fJ+r5ryeRUYuJijkaRNVASF1lpAdqCz+m0R5a s9mcFdCK7wh9kgk81VlzfuvQfYz5RlyNTjcN0TDh6SRsFWxQL81fnNkaLMsMjJ+8nY AqUz3PiikC2+oNsJcy+/HIi5mFzRQBjOm6b4L846iUJxtTTQbh9SNaSzWGDbj+fPLn LuNAszbSnbVQQhOv2eIJWJQqzHHsTbWqBiY9wjBTqzIOBqfFco/bqLvGX+aRWO5+wW L5Zl0i7af+v6g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yu Kuai , Nilay Shroff , Ming Lei , Hannes Reinecke , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 086/844] blk-mq-debugfs: add missing debugfs_mutex in blk_mq_debugfs_register_hctxs() Date: Sat, 28 Feb 2026 12:19:59 -0500 Message-ID: <20260228173244.1509663-87-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yu Kuai [ Upstream commit 9d20fd6ce1ba9733cd5ac96fcab32faa9fc404dd ] In blk_mq_update_nr_hw_queues(), debugfs_mutex is not held while creating debugfs entries for hctxs. Hence add debugfs_mutex there, it's safe because queue is not frozen. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Reviewed-by: Ming Lei Reviewed-by: Hannes Reinecke Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- block/blk-mq-debugfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c index 4896525b1c054..553d93b88e194 100644 --- a/block/blk-mq-debugfs.c +++ b/block/blk-mq-debugfs.c @@ -686,8 +686,10 @@ void blk_mq_debugfs_register_hctxs(struct request_queu= e *q) struct blk_mq_hw_ctx *hctx; unsigned long i; =20 + mutex_lock(&q->debugfs_mutex); queue_for_each_hw_ctx(q, hctx, i) blk_mq_debugfs_register_hctx(q, hctx); + mutex_unlock(&q->debugfs_mutex); } =20 void blk_mq_debugfs_unregister_hctxs(struct request_queue *q) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 136604968F6; Sat, 28 Feb 2026 17:34:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300073; cv=none; b=k9NV819wTEOCQvPOEacDaYJgHS8RL9ERg3QHFUMGRM08TiPIzvx6RkwnFy5qILuywfpefXl+rkwNXHdir6Bs5rmzi8X+2qKxi+tsyAK2/ERkqffUmLmS3GzXsjH9zJEtVOy6Mr1ke1GWwEI6vc+ZaRn2D69/t4KRmr4koFbfQB8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300073; c=relaxed/simple; bh=UMjfOwNikfLmdobeqAcJ09rP1M4uJMBjOepfIEYUQSc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tTMNK/kBa/SYzMw7kycdUvU+0fp491+OkqtgUV3WJ+YfHfpo2+xlEnGqcldiUIGJl4k0brzMQPm9DPL2Z1QDC2ev1+5LPisxMqB1k/emDEkFTyInt/+NgwCAtQWtsHDGy2Q2g8sJlS/5yvDfj6psrrCrm7ONwdTcWpSVFvIivN0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tdKLnf89; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tdKLnf89" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 298F0C19423; Sat, 28 Feb 2026 17:34:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300072; bh=UMjfOwNikfLmdobeqAcJ09rP1M4uJMBjOepfIEYUQSc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tdKLnf89/dVryuSAIsdjMXBjar0icx+LHS8h7jZOpZ+3ws0myiXfhr10h8lUCtO5w Ca83YJUW/YCfg+iPtLwt8fwKg0SbnvD+qUZXxeG10/vkhUqNFsAn7MUgXCJTuRkZ0I W8Ec6/1fYeGzn95ErcUvqnu9tBPizFgXpJheiLRz0b2GHMdkE04l6z5LE46j2fVFwX f9LBUJAgXZUiiADNjDQGUOCLMEVtpoR0utFJ/nk/aAttEulgIwY6xOOXAwNaDNcWaQ 8/4HkBIUBpTDz6xJh838o8xrIo5YuBwhd32Shx5/pdPpiMivgnv+E8bF2xyZukyaga BoCqw4A/dhiEQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yu Kuai , Nilay Shroff , Hannes Reinecke , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 087/844] blk-mq-sched: unify elevators checking for async requests Date: Sat, 28 Feb 2026 12:20:00 -0500 Message-ID: <20260228173244.1509663-88-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yu Kuai [ Upstream commit 1db61b0afdd7e8aa9289c423fdff002603b520b5 ] bfq and mq-deadline consider sync writes as async requests and only reserve tags for sync reads by async_depth, however, kyber doesn't consider sync writes as async requests for now. Consider the case there are lots of dirty pages, and user use fsync to flush dirty pages. In this case sched_tags can be exhausted by sync writes and sync reads can stuck waiting for tag. Hence let kyber follow what mq-deadline and bfq did, and unify async requests checking for all elevators. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Reviewed-by: Hannes Reinecke Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- block/bfq-iosched.c | 2 +- block/blk-mq-sched.h | 5 +++++ block/kyber-iosched.c | 2 +- block/mq-deadline.c | 2 +- 4 files changed, 8 insertions(+), 3 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 6e54b1d3d8bc2..9e9d081e86bb2 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -697,7 +697,7 @@ static void bfq_limit_depth(blk_opf_t opf, struct blk_m= q_alloc_data *data) unsigned int limit, act_idx; =20 /* Sync reads have full depth available */ - if (op_is_sync(opf) && !op_is_write(opf)) + if (blk_mq_is_sync_read(opf)) limit =3D data->q->nr_requests; else limit =3D bfqd->async_depths[!!bfqd->wr_busy_queues][op_is_sync(opf)]; diff --git a/block/blk-mq-sched.h b/block/blk-mq-sched.h index 02c40a72e9598..5678e15bd33c4 100644 --- a/block/blk-mq-sched.h +++ b/block/blk-mq-sched.h @@ -137,4 +137,9 @@ static inline void blk_mq_set_min_shallow_depth(struct = request_queue *q, depth); } =20 +static inline bool blk_mq_is_sync_read(blk_opf_t opf) +{ + return op_is_sync(opf) && !op_is_write(opf); +} + #endif diff --git a/block/kyber-iosched.c b/block/kyber-iosched.c index c1b36ffd19ceb..2b3f5b8959af0 100644 --- a/block/kyber-iosched.c +++ b/block/kyber-iosched.c @@ -556,7 +556,7 @@ static void kyber_limit_depth(blk_opf_t opf, struct blk= _mq_alloc_data *data) * We use the scheduler tags as per-hardware queue queueing tokens. * Async requests can be limited at this stage. */ - if (!op_is_sync(opf)) { + if (!blk_mq_is_sync_read(opf)) { struct kyber_queue_data *kqd =3D data->q->elevator->elevator_data; =20 data->shallow_depth =3D kqd->async_depth; diff --git a/block/mq-deadline.c b/block/mq-deadline.c index 3e3719093aec7..29d00221fbea6 100644 --- a/block/mq-deadline.c +++ b/block/mq-deadline.c @@ -495,7 +495,7 @@ static void dd_limit_depth(blk_opf_t opf, struct blk_mq= _alloc_data *data) struct deadline_data *dd =3D data->q->elevator->elevator_data; =20 /* Do not throttle synchronous reads. */ - if (op_is_sync(opf) && !op_is_write(opf)) + if (blk_mq_is_sync_read(opf)) return; =20 /* --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EED97496908; Sat, 28 Feb 2026 17:34:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300074; cv=none; b=ZYyrjjK5cD7nAmvwvM+uWMBzhwbSGBOUcAMLIlN5IHlSVRzmpbWKo3EW/AhM0NW9aF+aM9OB+maOg+EKncWMg6afMqNczgtYX98HrBhB0XKMMlqou2DXlgcSh4BFZK3K0JL6H2aJ4nNKQikTzv5sZxm1whpBv6w9BiuT5ISLGHE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300074; c=relaxed/simple; bh=JqjnUMKlVgixfHjEdpBSAggZsMoLdZspUbOL62UOxns=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UvDpOsLenOv8LpHWql4smI5tXMYppFkTH6AaWJppTba+AljYyHQvS5A3qdgDb/KbtM6DHk+DCvhOX7UQNnvZczhdcqp/DlY/HxwfQrOKjy2wFnZ0D4lXTUZx6Rp97ZhXbY53rID9K5RNnhyIZLsOBifR6u1P0Ror0ALZ7Xr8z9g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qg7ZG1E2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qg7ZG1E2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 309BFC19425; Sat, 28 Feb 2026 17:34:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300073; bh=JqjnUMKlVgixfHjEdpBSAggZsMoLdZspUbOL62UOxns=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qg7ZG1E2saEPW3niEDpZ3fgZx0yxac4NY73887q1z7KrgnNNHhYDAmA2B3J2ecsTd Eh6Dy5pf8DuaC7QDuVr1JkuWePCsUY7P3X/SbSZVfcdq9ThO7Xj/FAgcgfaJXyJUcZ h35NzTOvFdRyCEMj1T1gDtWcrw05ciNBsDxNfUPG/qy/WOxToSDC4jFJk3WeFHH0Kf /eOdclNhIBL8LqpuzeW4BYXGy56ojRKYysCq1vB307EesjnqosUe0515t+NC2Tktdt T8YBkGYPBC+B6/dW6s58NfQqxJSeDtrIwy60AUhC6U41vdY+FkvNF175MMZakDK997 NJeWCEOp/6mfw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luke Wang , Ulf Hansson , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 088/844] block: decouple secure erase size limit from discard size limit Date: Sat, 28 Feb 2026 12:20:01 -0500 Message-ID: <20260228173244.1509663-89-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luke Wang [ Upstream commit ee81212f74a57c5d2b56cf504f40d528dac6faaf ] Secure erase should use max_secure_erase_sectors instead of being limited by max_discard_sectors. Separate the handling of REQ_OP_SECURE_ERASE from REQ_OP_DISCARD to allow each operation to use its own size limit. Signed-off-by: Luke Wang Reviewed-by: Ulf Hansson Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- block/blk-merge.c | 21 +++++++++++++++++---- block/blk.h | 6 +++++- 2 files changed, 22 insertions(+), 5 deletions(-) diff --git a/block/blk-merge.c b/block/blk-merge.c index d3115d7469df0..bf8faadb0bd46 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -158,8 +158,9 @@ static struct bio *bio_submit_split(struct bio *bio, in= t split_sectors) return bio; } =20 -struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *= lim, - unsigned *nsegs) +static struct bio *__bio_split_discard(struct bio *bio, + const struct queue_limits *lim, unsigned *nsegs, + unsigned int max_sectors) { unsigned int max_discard_sectors, granularity; sector_t tmp; @@ -169,8 +170,7 @@ struct bio *bio_split_discard(struct bio *bio, const st= ruct queue_limits *lim, =20 granularity =3D max(lim->discard_granularity >> 9, 1U); =20 - max_discard_sectors =3D - min(lim->max_discard_sectors, bio_allowed_max_sectors(lim)); + max_discard_sectors =3D min(max_sectors, bio_allowed_max_sectors(lim)); max_discard_sectors -=3D max_discard_sectors % granularity; if (unlikely(!max_discard_sectors)) return bio; @@ -194,6 +194,19 @@ struct bio *bio_split_discard(struct bio *bio, const s= truct queue_limits *lim, return bio_submit_split(bio, split_sectors); } =20 +struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *= lim, + unsigned *nsegs) +{ + unsigned int max_sectors; + + if (bio_op(bio) =3D=3D REQ_OP_SECURE_ERASE) + max_sectors =3D lim->max_secure_erase_sectors; + else + max_sectors =3D lim->max_discard_sectors; + + return __bio_split_discard(bio, lim, nsegs, max_sectors); +} + static inline unsigned int blk_boundary_sectors(const struct queue_limits = *lim, bool is_atomic) { diff --git a/block/blk.h b/block/blk.h index e4c433f62dfc7..4cd5a91346d8a 100644 --- a/block/blk.h +++ b/block/blk.h @@ -208,10 +208,14 @@ static inline unsigned int blk_queue_get_max_sectors(= struct request *rq) struct request_queue *q =3D rq->q; enum req_op op =3D req_op(rq); =20 - if (unlikely(op =3D=3D REQ_OP_DISCARD || op =3D=3D REQ_OP_SECURE_ERASE)) + if (unlikely(op =3D=3D REQ_OP_DISCARD)) return min(q->limits.max_discard_sectors, UINT_MAX >> SECTOR_SHIFT); =20 + if (unlikely(op =3D=3D REQ_OP_SECURE_ERASE)) + return min(q->limits.max_secure_erase_sectors, + UINT_MAX >> SECTOR_SHIFT); + if (unlikely(op =3D=3D REQ_OP_WRITE_ZEROES)) return q->limits.max_write_zeroes_sectors; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2BDA94A1383; Sat, 28 Feb 2026 17:34:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300075; cv=none; b=XAp8kOiDJw2YXIdKXmMqgdWalMzprPsEMq0Mv9H0QZcRZFcrh7kEO0XkzhkvxWI7W/B+K/0dgRnNXHuys9W3rUCf+zI4Vdj7cGx4ln8EDz/yBeJEW3Jzy7yrDXaVPKSh8kOK1m/qmsEVk8oYFUE3Bjqnm89c71QX8ozyKsVQ064= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300075; c=relaxed/simple; bh=5FWSGWoP1DeTrBtFBKNXyNxpZ0WVhV/7ov6m7oEI/PI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VQCeugz8IPchsnwTKN1hozUhoEHPjvvJCMUd+KjOjzY2eu7XbGjrXqYNpvKuW+cbL8zpfvLMMHrD82wjx73GP2uxahK7BJUQ92dlnn92yLiEADcbYLEMFPUQl2Km+rkHPfPz85Bk4KDysvLnqK93kUgvhULzx6LMvVFeXycP2lE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jtpWgWSr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jtpWgWSr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 232E8C19423; Sat, 28 Feb 2026 17:34:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300074; bh=5FWSGWoP1DeTrBtFBKNXyNxpZ0WVhV/7ov6m7oEI/PI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jtpWgWSr6yl5C8MaL+Y0GozAOzHWUPazYeQv9cexMkVL8ud2TtsJrnR5emVe6/acx CfiB1dGTR5L69PpgLkZ0N920VfWXCS1YNlh4gMdVVggMY2hNHqHmlkPP+1bAe1bqYR 9OlaJlwnSQhiZYOfpuU92BEqzyf7Nf0f6vBiklU4ZkZ10esFayGGyzKVEPnFgH5C8e nKmx5H5fVlitrOrRjRY6JFFyNtG2d54Vry/wm3t7cULIe4Stg+eQqb0JATEVh79yvm BqRtcOCHMfGi9q5jkyQmXP2CO1Loxq4XG6FavXBkuYthfzDHgUUDVvR+HvveG3TQue ZZ8LVQfzVpFug== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andreas Larsson , Ludwig Rydberg , John Paul Adrian Glaubitz , Sasha Levin Subject: [PATCH 6.19 089/844] sparc: Synchronize user stack on fork and clone Date: Sat, 28 Feb 2026 12:20:02 -0500 Message-ID: <20260228173244.1509663-90-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andreas Larsson [ Upstream commit e38eba3b77878ada327a572a41596a3b0b44e522 ] Flush all uncommitted user windows before calling the generic syscall handlers for clone, fork, and vfork. Prior to entering the arch common handlers sparc_{clone|fork|vfork}, the arch-specific syscall wrappers for these syscalls will attempt to flush all windows (including user windows). In the window overflow trap handlers on both SPARC{32|64}, if the window can't be stored (i.e due to MMU related faults) the routine backups the user window and increments a thread counter (wsaved). By adding a synchronization point after the flush attempt, when fault handling is enabled, any uncommitted user windows will be flushed. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31394 Closes: https://lore.kernel.org/sparclinux/fe5cc47167430007560501aabb28ba15= 4985b661.camel@physik.fu-berlin.de/ Signed-off-by: Andreas Larsson Signed-off-by: Ludwig Rydberg Tested-by: John Paul Adrian Glaubitz Link: https://lore.kernel.org/r/20260119144753.27945-2-ludwig.rydberg@gaisl= er.com Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/sparc/kernel/process.c | 38 +++++++++++++++++++++++-------------- 1 file changed, 24 insertions(+), 14 deletions(-) diff --git a/arch/sparc/kernel/process.c b/arch/sparc/kernel/process.c index 0442ab00518d3..7d69877511fac 100644 --- a/arch/sparc/kernel/process.c +++ b/arch/sparc/kernel/process.c @@ -17,14 +17,18 @@ =20 asmlinkage long sparc_fork(struct pt_regs *regs) { - unsigned long orig_i1 =3D regs->u_regs[UREG_I1]; + unsigned long orig_i1; long ret; struct kernel_clone_args args =3D { .exit_signal =3D SIGCHLD, - /* Reuse the parent's stack for the child. */ - .stack =3D regs->u_regs[UREG_FP], }; =20 + synchronize_user_stack(); + + orig_i1 =3D regs->u_regs[UREG_I1]; + /* Reuse the parent's stack for the child. */ + args.stack =3D regs->u_regs[UREG_FP]; + ret =3D kernel_clone(&args); =20 /* If we get an error and potentially restart the system @@ -40,16 +44,19 @@ asmlinkage long sparc_fork(struct pt_regs *regs) =20 asmlinkage long sparc_vfork(struct pt_regs *regs) { - unsigned long orig_i1 =3D regs->u_regs[UREG_I1]; + unsigned long orig_i1; long ret; - struct kernel_clone_args args =3D { .flags =3D CLONE_VFORK | CLONE_VM, .exit_signal =3D SIGCHLD, - /* Reuse the parent's stack for the child. */ - .stack =3D regs->u_regs[UREG_FP], }; =20 + synchronize_user_stack(); + + orig_i1 =3D regs->u_regs[UREG_I1]; + /* Reuse the parent's stack for the child. */ + args.stack =3D regs->u_regs[UREG_FP]; + ret =3D kernel_clone(&args); =20 /* If we get an error and potentially restart the system @@ -65,15 +72,18 @@ asmlinkage long sparc_vfork(struct pt_regs *regs) =20 asmlinkage long sparc_clone(struct pt_regs *regs) { - unsigned long orig_i1 =3D regs->u_regs[UREG_I1]; - unsigned int flags =3D lower_32_bits(regs->u_regs[UREG_I0]); + unsigned long orig_i1; + unsigned int flags; long ret; + struct kernel_clone_args args =3D {0}; =20 - struct kernel_clone_args args =3D { - .flags =3D (flags & ~CSIGNAL), - .exit_signal =3D (flags & CSIGNAL), - .tls =3D regs->u_regs[UREG_I3], - }; + synchronize_user_stack(); + + orig_i1 =3D regs->u_regs[UREG_I1]; + flags =3D lower_32_bits(regs->u_regs[UREG_I0]); + args.flags =3D (flags & ~CSIGNAL); + args.exit_signal =3D (flags & CSIGNAL); + args.tls =3D regs->u_regs[UREG_I3]; =20 #ifdef CONFIG_COMPAT if (test_thread_flag(TIF_32BIT)) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C4A584A13A1; Sat, 28 Feb 2026 17:34:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300075; cv=none; b=FolTesQ91FLm/NeWBUAAPe6XvkdA2on6aXvx/zmjb5oPfXJIm4kUJGG92arionJVj/A/yETxZXXfnXnnKBiPuI2zq+ycWrLwC8jjWeB8RlA6PkuAJgLgBV2yIqpYUDhwkoUQF6SYS0n4driYiKM7XtSd4IEy6ERSQKy4Fx6/OOI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300075; c=relaxed/simple; bh=y120UP/A72i4KPCXXzfD+Gijbl0GECCbaubnP5MiEKM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oG0UaecktPOlutr3ypE8tTUxyOKAgLg8ZIZe1y6JGIw2fYuaW4ucvxweXl8VX83uCTz5PhXP55v5PkdBZYYYCmZ57ORv+CGYiFERaCJOQVP/tjNL6o/XQIHtavZknGgaLdMDdL+di2Wa+do5+ofu6IKM19pDyzuK86COTM7l1vc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rHnTbfuP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rHnTbfuP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19863C116D0; Sat, 28 Feb 2026 17:34:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300075; bh=y120UP/A72i4KPCXXzfD+Gijbl0GECCbaubnP5MiEKM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rHnTbfuPu+HJoWF+fNx6Y0gOpAG7he3n8F3CYLeOIpRegQaEmZw8DQF4zRfCG+Lfa i0EgO5kG8V6ltlgG+3Gb7eflTTzrckLoCoCO7jvu8gAy/qf/PQg7vAFFFppeLtza/y c4dsFhh6w0jq8oihUXiSxVXKJ7W50wE7DWbfvSP5iNE2WIByWESp5nXVoyKSMAD9l2 dZU2Tj4sN9+ew4AvyiNP5B3dPH1+/K6Fnr/jWbcnA8kilXdyQgt7ZIuumtpxWTi+hz zfyvr6f5RjQ9EUpp8BB/uUTeIOQsWnlhGnCWt4dY0EN+eLmnJLtTisJ8hmCWi/Feld DSqTkVqTlSjOQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sam James , Andreas Larsson , Sasha Levin Subject: [PATCH 6.19 090/844] sparc: don't reference obsolete termio struct for TC* constants Date: Sat, 28 Feb 2026 12:20:03 -0500 Message-ID: <20260228173244.1509663-91-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sam James [ Upstream commit be0bccffcde3308150d2a90e55fc10e249098909 ] Similar in nature to commit ab107276607a ("powerpc: Fix struct termio relat= ed ioctl macros"). glibc-2.42 drops the legacy termio struct, but the ioctls.h header still defines some TC* constants in terms of termio (via sizeof). Hardcode the values instead. This fixes building Python for example, which falls over like: ./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to in= complete type 'struct termio' Link: https://bugs.gentoo.org/961769 Link: https://bugs.gentoo.org/962600 Signed-off-by: Sam James Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/sparc/include/uapi/asm/ioctls.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/sparc/include/uapi/asm/ioctls.h b/arch/sparc/include/uapi= /asm/ioctls.h index 7fd2f5873c9e7..a8bbdf9877a41 100644 --- a/arch/sparc/include/uapi/asm/ioctls.h +++ b/arch/sparc/include/uapi/asm/ioctls.h @@ -5,10 +5,10 @@ #include =20 /* Big T */ -#define TCGETA _IOR('T', 1, struct termio) -#define TCSETA _IOW('T', 2, struct termio) -#define TCSETAW _IOW('T', 3, struct termio) -#define TCSETAF _IOW('T', 4, struct termio) +#define TCGETA 0x40125401 /* _IOR('T', 1, struct termio) */ +#define TCSETA 0x80125402 /* _IOW('T', 2, struct termio) */ +#define TCSETAW 0x80125403 /* _IOW('T', 3, struct termio) */ +#define TCSETAF 0x80125404 /* _IOW('T', 4, struct termio) */ #define TCSBRK _IO('T', 5) #define TCXONC _IO('T', 6) #define TCFLSH _IO('T', 7) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 589BA496903; Sat, 28 Feb 2026 17:34:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300077; cv=none; b=CwTTgbK8AqZi7KEePoSflmA63/0tyDivOHF5imp5PCQmne7ncTccHjOEEXi3F1UEHLzNRuRO9b7vgkVgDiMExpkSY68ML0oabwj6yj0dR4aHsH6RXM3kWrnS7/O+6dyvZmg+h15RFLwk46sXqdBraKZttkCSWA55J/dHIxCeZOU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300077; c=relaxed/simple; bh=36eFDMC+F8u+wuAGtj38JKzg3v6qAA/eyc8rh47FPEA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TB2l1/ASPPihMF5AcuoCTWJU36qjr685YDe6tKT113950hUDT/IOsBqCjiKmfblj0MWGJoNqLIJsBXmGoh1TydkMN8cVV9PYP7iuWvgWvDaO42pi+IYdsCxulPOyFrLnBZhhZHZ6VSK922H0sE5JyqtnVvUlkTDCXNlHSePPjB8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BSoMNi6K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BSoMNi6K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00F04C116D0; Sat, 28 Feb 2026 17:34:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300077; bh=36eFDMC+F8u+wuAGtj38JKzg3v6qAA/eyc8rh47FPEA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BSoMNi6KS/cTVQdWyCs2RuYzRf6QPhZBriAUCrxD+BSnXgrL4bBBfNkpdAxjdIzil JGADP0XYhKf/Kpq56Z4cTz3gU5tYNA+zojYow9WXbdVsfhPf5EJG8+1LH3Ov6DpYKk pkk6AdwO4BYWEpzNow9BfdySPonCe+G86VwmNGwf/+jXRT5gBnlFIHsOvKYkkjgAHB xvcX74aPjIqV9SS7gCCRTBDNJZVuu00K/wWBbeEPN19iOVvOPlnVVov8b4kZU0ZVh/ aKhOiT+jTmSOC3miotva4o/lDRXh5YSUaAPQuih/kBJkqOMuRerzy7wp30FfTVozRK HWT/yX0ULLD7A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Cupertino Miranda , Andrew Pinski , Eduard Zingerman , David Faust , Jose Marchesi , Elena Zannoni , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.19 091/844] bpf: verifier improvement in 32bit shift sign extension pattern Date: Sat, 28 Feb 2026 12:20:04 -0500 Message-ID: <20260228173244.1509663-92-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Cupertino Miranda [ Upstream commit d18dec4b8990048ce75f0ece32bb96b3fbd3f422 ] This patch improves the verifier to correctly compute bounds for sign extension compiler pattern composed of left shift by 32bits followed by a sign right shift by 32bits. Pattern in the verifier was limitted to positive value bounds and would reset bound computation for negative values. New code allows both positive and negative values for sign extension without compromising bound computation and verifier to pass. This change is required by GCC which generate such pattern, and was detected in the context of systemd, as described in the following GCC bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D119731 Three new tests were added in verifier_subreg.c. Signed-off-by: Cupertino Miranda Signed-off-by: Andrew Pinski Acked-by: Eduard Zingerman Cc: David Faust Cc: Jose Marchesi Cc: Elena Zannoni Link: https://lore.kernel.org/r/20251202180220.11128-2-cupertino.miranda@or= acle.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/bpf/verifier.c | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index fe01edfcc34c6..7069e9f527eaa 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -15305,21 +15305,17 @@ static void __scalar64_min_max_lsh(struct bpf_reg= _state *dst_reg, u64 umin_val, u64 umax_val) { /* Special case <<32 because it is a common compiler pattern to sign - * extend subreg by doing <<32 s>>32. In this case if 32bit bounds are - * positive we know this shift will also be positive so we can track - * bounds correctly. Otherwise we lose all sign bit information except - * what we can pick up from var_off. Perhaps we can generalize this - * later to shifts of any length. + * extend subreg by doing <<32 s>>32. smin/smax assignments are correct + * because s32 bounds don't flip sign when shifting to the left by + * 32bits. */ - if (umin_val =3D=3D 32 && umax_val =3D=3D 32 && dst_reg->s32_max_value >= =3D 0) + if (umin_val =3D=3D 32 && umax_val =3D=3D 32) { dst_reg->smax_value =3D (s64)dst_reg->s32_max_value << 32; - else - dst_reg->smax_value =3D S64_MAX; - - if (umin_val =3D=3D 32 && umax_val =3D=3D 32 && dst_reg->s32_min_value >= =3D 0) dst_reg->smin_value =3D (s64)dst_reg->s32_min_value << 32; - else + } else { + dst_reg->smax_value =3D S64_MAX; dst_reg->smin_value =3D S64_MIN; + } =20 /* If we might shift our top bit out, then we know nothing */ if (dst_reg->umax_value > 1ULL << (63 - umax_val)) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57C4E4A2E26; Sat, 28 Feb 2026 17:34:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300078; cv=none; b=EZaySM8++9aOyTjJgjHkb5yKuWojL32CNUOBCMzldHGHJInsp/IzVyRVNldRWwyNzSqyWJFE2sA8qLl3Z11KDZUtmLT4lCTMazh584+x5xvMal5BuLZSUy9c0sPKrbIxrzj/I7f70IfI9AUVMJ0JoMswTFgSpaCfZz0r/YdzQIQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300078; c=relaxed/simple; bh=2uN9iCK6tuGK6dMbwblD+HHT/IcSCyQZCs/7NUou670=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ceGb9k8ImgBJhE9jeNwCUvYB8uBFM/Wj/fdYatpV4T/7t+MLCFQsVNAlJw1IA7jA1EHs6dQp72K2m03f7JnD/cCbLmC0vB45vai7Sklr3k93xIDfWzZrTBfJIPWCXVZ7EGCgfm63ObtQcEgyBM0FAYqEF6gqMJpIbwU3kYHST9Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YDwFFHae; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YDwFFHae" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 492C0C2BC87; Sat, 28 Feb 2026 17:34:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300078; bh=2uN9iCK6tuGK6dMbwblD+HHT/IcSCyQZCs/7NUou670=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YDwFFHaeyTgR78skJnEtFUt55xNJKhECYypVk6I3cpS54qdS+tDS4m1ImTnSdFA8p /gICFvkIsThIDE5IhBUIPrie4rbQANYqEPId2C2FXF4HCgCDIITfCHumbJmhlCPrmE 7vw577AVVzmOzUUY6oA1HCMGum+9XZilo4ECBaXmTxxFhCdJmnHrqYVuyqolayPgAe 41uPphZx91+kamA8Lv3McSz1szjxwkYm8geWNSRy/pUp1OXKUsSs6IpWEKNmnhtEl5 KrnPRJr5MAznHrEdF0g9FjTBYwaKy/B1GH3mvYxrqSXwYY64MXgs72Ad9lWrOZ67e2 v1hsPpXgaZtVQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nick Hu , Thomas Gleixner , Yong-Xuan Wang , Cyan Yang , Anup Patel , Nutty Liu , Sasha Levin Subject: [PATCH 6.19 092/844] irqchip/riscv-imsic: Add a CPU pm notifier to restore the IMSIC on exit Date: Sat, 28 Feb 2026 12:20:05 -0500 Message-ID: <20260228173244.1509663-93-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nick Hu [ Upstream commit f48b4bd0915bf61ac12b8c65c7939ebd03bc8abf ] The IMSIC might be reset when the system enters a low power state, but on exit nothing restores the registers, which prevents interrupt delivery. Solve this by registering a CPU power management notifier, which restores the IMSIC on exit. Signed-off-by: Nick Hu Signed-off-by: Thomas Gleixner Reviewed-by: Yong-Xuan Wang Reviewed-by: Cyan Yang Reviewed-by: Anup Patel Reviewed-by: Nutty Liu Link: https://patch.msgid.link/20251202-preserve-aplic-imsic-v3-1-1844fbf1f= e92@sifive.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/irqchip/irq-riscv-imsic-early.c | 39 ++++++++++++++++++++----- 1 file changed, 31 insertions(+), 8 deletions(-) diff --git a/drivers/irqchip/irq-riscv-imsic-early.c b/drivers/irqchip/irq-= riscv-imsic-early.c index 6bac67cc0b6d9..ba903fa689bd5 100644 --- a/drivers/irqchip/irq-riscv-imsic-early.c +++ b/drivers/irqchip/irq-riscv-imsic-early.c @@ -7,6 +7,7 @@ #define pr_fmt(fmt) "riscv-imsic: " fmt #include #include +#include #include #include #include @@ -123,14 +124,8 @@ static void imsic_handle_irq(struct irq_desc *desc) chained_irq_exit(chip, desc); } =20 -static int imsic_starting_cpu(unsigned int cpu) +static void imsic_hw_states_init(void) { - /* Mark per-CPU IMSIC state as online */ - imsic_state_online(); - - /* Enable per-CPU parent interrupt */ - enable_percpu_irq(imsic_parent_irq, irq_get_trigger_type(imsic_parent_irq= )); - /* Setup IPIs */ imsic_ipi_starting_cpu(); =20 @@ -142,6 +137,18 @@ static int imsic_starting_cpu(unsigned int cpu) =20 /* Enable local interrupt delivery */ imsic_local_delivery(true); +} + +static int imsic_starting_cpu(unsigned int cpu) +{ + /* Mark per-CPU IMSIC state as online */ + imsic_state_online(); + + /* Enable per-CPU parent interrupt */ + enable_percpu_irq(imsic_parent_irq, irq_get_trigger_type(imsic_parent_irq= )); + + /* Initialize the IMSIC registers to enable the interrupt delivery */ + imsic_hw_states_init(); =20 return 0; } @@ -157,6 +164,22 @@ static int imsic_dying_cpu(unsigned int cpu) return 0; } =20 +static int imsic_pm_notifier(struct notifier_block *self, unsigned long cm= d, void *v) +{ + switch (cmd) { + case CPU_PM_EXIT: + /* Initialize the IMSIC registers to enable the interrupt delivery */ + imsic_hw_states_init(); + break; + } + + return NOTIFY_OK; +} + +static struct notifier_block imsic_pm_notifier_block =3D { + .notifier_call =3D imsic_pm_notifier, +}; + static int __init imsic_early_probe(struct fwnode_handle *fwnode) { struct irq_domain *domain; @@ -194,7 +217,7 @@ static int __init imsic_early_probe(struct fwnode_handl= e *fwnode) cpuhp_setup_state(CPUHP_AP_IRQ_RISCV_IMSIC_STARTING, "irqchip/riscv/imsic= :starting", imsic_starting_cpu, imsic_dying_cpu); =20 - return 0; + return cpu_pm_register_notifier(&imsic_pm_notifier_block); } =20 static int __init imsic_early_dt_init(struct device_node *node, struct dev= ice_node *parent) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 489B64A2E39; Sat, 28 Feb 2026 17:34:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300079; cv=none; b=aHJpRCnDVrbyw3d/PpFGT/sAGRwCWerz3CCPHMgIalWH4WTlK5OagSkDQv6mxmY2OSb7/iLCJ+fBg19SbIOZEAvEVsUWYWvo+eoi31jVzLmWZkeJ1sui1Q2riN1XohESYsU+kwowvsk+jOVovtSxm9GvkdHjgjJXbTcShrY91vQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300079; c=relaxed/simple; bh=H5FE0biINAPqcQj2mRaD4fEdEN96p45GPqIJtXKgFHE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nBlqcn8I3RTT4nVPNXhPQ9SmMkjCN1brYOS8bjD6wvUuxbGt8OK3MHZEtoull14oFUsGKp+2qfCRaURft6pvNxBa5ZEQ+gRehYK0djr17UYybkwBbfhFtVmd2CKstJPbYt2PX1eTd8eYKgKUEzm3G8DH8gqelXdYTqaspSCRF2Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nUnQtGUE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nUnQtGUE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DB5AC19423; Sat, 28 Feb 2026 17:34:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300079; bh=H5FE0biINAPqcQj2mRaD4fEdEN96p45GPqIJtXKgFHE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nUnQtGUE0eaexUArwnAWNu6+S3MNTA0y50chrwaLSl98NWMM0c775NghL3TUhh9GI 1WJSi8dOnaHoeF+LBfxxY2Udi+gmNE5aiZogPdtPs67iQC+oHwjo8UV+cL6NDvey/K q0f9r+Wr1WYSz9F2W3FmvBGe7KP0t/TALlqwMlX4bP61SehYp9HXmKHM5kqLGK3twl N8KtWZa4WZQJ0dc52CLNSHzR7S2gm5atrHb9c5OgajALldo0QkqUZiIM5z2wfG8FAS 7sTcp2z3lSJ6JWGbYqZ6zMkj7PXSOhd1ZstFSu+uc7fq4sZzIKO7UgscJT0NqDIZop nKn7/lbY/nqAw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Martin Schiller , "Peter Zijlstra (Intel)" , Dapeng Mi , Sasha Levin Subject: [PATCH 6.19 093/844] perf/x86/msr: Add Airmont NP Date: Sat, 28 Feb 2026 12:20:06 -0500 Message-ID: <20260228173244.1509663-94-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Martin Schiller [ Upstream commit 63dbadcafc1f4d1da796a8e2c0aea1e561f79ece ] Like Airmont, the Airmont NP (aka Intel / MaxLinear Lightning Mountain) supports SMI_COUNT MSR. Signed-off-by: Martin Schiller Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20251124074846.9653-2-ms@dev.tdt.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/events/msr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c index 7f5007a4752a1..8052596b85036 100644 --- a/arch/x86/events/msr.c +++ b/arch/x86/events/msr.c @@ -78,6 +78,7 @@ static bool test_intel(int idx, void *data) case INTEL_ATOM_SILVERMONT: case INTEL_ATOM_SILVERMONT_D: case INTEL_ATOM_AIRMONT: + case INTEL_ATOM_AIRMONT_NP: =20 case INTEL_ATOM_GOLDMONT: case INTEL_ATOM_GOLDMONT_D: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D4E733FE12; Sat, 28 Feb 2026 17:34:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300080; cv=none; b=hjFdhJ89qyYKqmIEESZXflp6f4CQDBoqp+KwbCcyXIb/W5CREGpHtmeHH5CcbVq0AXdU0DIe8G5hcbvP8If7qSZaxi+ZyWEgbu61Mu8PutXqMrGnfyIlJTmaNbC/mc/wWRNu/c3UkPdfrbs/tw83kc5SBWsOBHQ7zI9ivN5LlfQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300080; c=relaxed/simple; bh=TmeLW5qr0QCHMuHsr+B7FWmNu2EJjch5/GeBaeSU8/s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mz6W7rpStsPLu7Pmfp3myAEuMToOzgaCxdAdYghb8OxEvE1CJLrtgWDV8JrR7TT1tMhXkqSn5LiKQNMuqk21+IuDQnFy34lJY/DoHw58Mou66v3O0xllotzLnNkGcp/JQvZa+//mXqUISS0caui5oOjdGSYrX+zVbF56aUswRfk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nkjOwsRg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nkjOwsRg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72A53C19424; Sat, 28 Feb 2026 17:34:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300080; bh=TmeLW5qr0QCHMuHsr+B7FWmNu2EJjch5/GeBaeSU8/s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nkjOwsRgHh6r3bbtk+qJb1hJJbmgTmlsDuR7hGNU3XlmioIESXJtkqiPxw7jTBa2v bft12MUC6XgxN9u320xsAVq4FrDtiSwRG+2Ht6KJpbHVRV9Ms8MErGWTqZG6yJ/Qiz O2ApWu7rXMXl6+6v86qZmr/zQXGsBz+MRTwtEGn4ExNinW2F6Q5H0MLE5dTpoMwZqr 2yXpb5AmTN2yYpQZFviJN9c/2MW+WGzv9MCH6AD42twJDk0FrMgrDgjAJ45POPj+cs GKQRjgzf/YbAZ0ooIriEAchz4zUu0m2nGc+Q2ZqbNQfZjhnijZJ296UC4FUGdI/mMC pqEd0a5VsaqHg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Martin Schiller , "Peter Zijlstra (Intel)" , Dapeng Mi , Sasha Levin Subject: [PATCH 6.19 094/844] perf/x86/cstate: Add Airmont NP Date: Sat, 28 Feb 2026 12:20:07 -0500 Message-ID: <20260228173244.1509663-95-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Martin Schiller [ Upstream commit 3006911f284d769b0f66c12b39da130325ef1440 ] From the perspective of Intel cstate residency counters, the Airmont NP (aka Lightning Mountain) is identical to the Airmont. Signed-off-by: Martin Schiller Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20251124074846.9653-4-ms@dev.tdt.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/events/intel/cstate.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c index fa67fda6e45b4..c1e318bdaa397 100644 --- a/arch/x86/events/intel/cstate.c +++ b/arch/x86/events/intel/cstate.c @@ -599,6 +599,7 @@ static const struct x86_cpu_id intel_cstates_match[] __= initconst =3D { X86_MATCH_VFM(INTEL_ATOM_SILVERMONT, &slm_cstates), X86_MATCH_VFM(INTEL_ATOM_SILVERMONT_D, &slm_cstates), X86_MATCH_VFM(INTEL_ATOM_AIRMONT, &slm_cstates), + X86_MATCH_VFM(INTEL_ATOM_AIRMONT_NP, &slm_cstates), =20 X86_MATCH_VFM(INTEL_BROADWELL, &snb_cstates), X86_MATCH_VFM(INTEL_BROADWELL_D, &snb_cstates), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 307624A3410; Sat, 28 Feb 2026 17:34:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300081; cv=none; b=tgPAf4n5j4AtCVQZhmu5/BanaWq2omEc/M8AW1SijO7eaL/C4AYpMU7qIc6X8gMeMQKmo7l+TPcrbwC+3Z2gKfBgKO/S2o0c1DKe+5Vkf0XoMIWYR3ENkL+FVBSXzfI1xzGlXHhHPRX5gl8/3CEGua9qdNs1JBA45y/u5Zg2di4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300081; c=relaxed/simple; bh=Rv86ksDJSKVkNYqm19gbqZf2YHOvAYL0Z8AjVnsxgPY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ui8MRe60aATVojA6PwJcvVYwy1BTBBYGOFh5cbqnTOkEjT9T3wE4ukbGiwQqXsa7vwTMbLgfUFEIYmQYp08GGQMsRYxmHDiAJD1z5cDrWblvoyugCy/txFv4MmAFyoecIsuzqXWKnGhT8TyJH0XfMASIGa1MvhDd2zfUACYxn8I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R2LVeUgD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R2LVeUgD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 654C5C19424; Sat, 28 Feb 2026 17:34:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300081; bh=Rv86ksDJSKVkNYqm19gbqZf2YHOvAYL0Z8AjVnsxgPY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R2LVeUgDRiSFewiySwVU4hJS90i9NvVZzed3szLhIq7iwbtH2WZftK/0teI5LHM7b G1+HmgwK0LfevbUkfDQmWNsa/wejdrM/GdM/dEpblKRa98JV6LvXZ6iBL/ESAjbK5Q p1MvAvulQzf23E0bsIxWS37p1dV3cb31jS9jCFt7PiEK79npXaSB9cHs2hJsx2ycZk hNfSDw3J3IDOMS869ZqcNQLDMHwINr78XmfLE/85cCdnt+wnsUjqoUqIwu+RoF/oAi rMJu2n3Z7YpsKRC9OoR5YQj7oyRuefJPPJCLUHS2Jw4rvnAhglV8jcpBXkd7VjXi1P qJFz6TA2ccdPQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Martin Schiller , "Peter Zijlstra (Intel)" , Dapeng Mi , Sasha Levin Subject: [PATCH 6.19 095/844] perf/x86/intel: Add Airmont NP Date: Sat, 28 Feb 2026 12:20:08 -0500 Message-ID: <20260228173244.1509663-96-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Martin Schiller [ Upstream commit a08340fd291671c54d379d285b2325490ce90ddd ] The Intel / MaxLinear Airmont NP (aka Lightning Mountain) supports the same architectual and non-architecural events as Airmont. Signed-off-by: Martin Schiller Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20251124074846.9653-3-ms@dev.tdt.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/events/intel/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index bdf3f0d0fe216..d85df652334fb 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -7405,6 +7405,7 @@ __init int intel_pmu_init(void) case INTEL_ATOM_SILVERMONT_D: case INTEL_ATOM_SILVERMONT_MID: case INTEL_ATOM_AIRMONT: + case INTEL_ATOM_AIRMONT_NP: case INTEL_ATOM_SILVERMONT_MID2: memcpy(hw_cache_event_ids, slm_hw_cache_event_ids, sizeof(hw_cache_event_ids)); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B30F4ADD8C; Sat, 28 Feb 2026 17:34:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300082; cv=none; b=t4IuEojhvA0yuD0lUUGUov1yy5eoFzc7sCz6wldQ4cLNVhNzC5/u622ASniDi7SXf4fjvJUKPMZMUqdTgOTc9ib67JAUYhRvKMXxmWK4CEKNEETp8dV0IGLXjnZSV6/eojuNm6F7msm9ndtDGHV0KpRqNwIknhIzzPqvvCGltG8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300082; c=relaxed/simple; bh=zz3M9mpjhNOrmlHz15hpQTc3IFIDCq+wlZspWI8Z17g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=omftgbZRyeUDSNvif4FrBXMnj8jWimquIPMoiOsiyziRTALgg86SthQwNMVQci2QgpojRRndZcvjUw46BPSySalMdKOHU6kDe1ij2lAbFi2PvbL4YgmGmNqJcBHAx53hjn74p0OeC6cbaOHAtqovCT4janR5qMC2QnR77LfYZ88= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QQD9cKZo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QQD9cKZo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57E67C116D0; Sat, 28 Feb 2026 17:34:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300081; bh=zz3M9mpjhNOrmlHz15hpQTc3IFIDCq+wlZspWI8Z17g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QQD9cKZobvxZnEhvXs9fO/FeubGacBApnVT5fZSTLa21qSmRE7gDk+9+jiLSefdaX aT35aXJbArqXT/XA8p8i63nVUCtPAxPtnQW7IlbgJ1Zd4YY+aZI5mqi3oPqStruZm1 8kEoJNKDZr7h+QwLYht7p6k1mtwbV5KANCz2DcGjNX/YhbIMqoJi/D8cUkcY2qN1Qy m9sdq5pYEn/as5zJLMMmnJlmqeMejlWTuwFSCwVyiOuRL9RKQYxWu4W+syCtobi3YT gztPDPYwk+EtuM8fskVy+e3CoaFDqE99VgkSsjOBgvv9mgTRqHldE/0WJYyC6UphCz P7IMlMCShoixQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sami Tolvanen , =?UTF-8?q?Michal=20Such=C3=A1nek?= , Sasha Levin Subject: [PATCH 6.19 096/844] gendwarfksyms: Fix build on 32-bit hosts Date: Sat, 28 Feb 2026 12:20:09 -0500 Message-ID: <20260228173244.1509663-97-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Sami Tolvanen [ Upstream commit ddc54f912a551f6eb0bbcfc3880f45fe27a252cb ] We have interchangeably used unsigned long for some of the types defined in elfutils, assuming they're always 64-bit. This obviously fails when building gendwarfksyms on 32-bit hosts. Fix the types. Reported-by: Michal Such=C3=A1nek Closes: https://lore.kernel.org/linux-modules/aRcxzPxtJblVSh1y@kitsune.suse= .cz/ Tested-by: Michal Such=C3=A1nek Signed-off-by: Sami Tolvanen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- scripts/gendwarfksyms/dwarf.c | 4 +++- scripts/gendwarfksyms/symbols.c | 5 +++-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/scripts/gendwarfksyms/dwarf.c b/scripts/gendwarfksyms/dwarf.c index 3538a7d9cb070..e76d732f5f602 100644 --- a/scripts/gendwarfksyms/dwarf.c +++ b/scripts/gendwarfksyms/dwarf.c @@ -750,6 +750,7 @@ static void process_enumerator_type(struct state *state= , struct die *cache, Dwarf_Die *die) { bool overridden =3D false; + unsigned long override; Dwarf_Word value; =20 if (stable) { @@ -761,7 +762,8 @@ static void process_enumerator_type(struct state *state= , struct die *cache, return; =20 overridden =3D kabi_get_enumerator_value( - state->expand.current_fqn, cache->fqn, &value); + state->expand.current_fqn, cache->fqn, &override); + value =3D override; } =20 process_list_comma(state, cache); diff --git a/scripts/gendwarfksyms/symbols.c b/scripts/gendwarfksyms/symbol= s.c index ecddcb5ffcdfb..42cd27c9cec4f 100644 --- a/scripts/gendwarfksyms/symbols.c +++ b/scripts/gendwarfksyms/symbols.c @@ -3,6 +3,7 @@ * Copyright (C) 2024 Google LLC */ =20 +#include #include "gendwarfksyms.h" =20 #define SYMBOL_HASH_BITS 12 @@ -242,7 +243,7 @@ static void elf_for_each_global(int fd, elf_symbol_call= back_t func, void *arg) error("elf_getdata failed: %s", elf_errmsg(-1)); =20 if (shdr->sh_entsize !=3D sym_size) - error("expected sh_entsize (%lu) to be %zu", + error("expected sh_entsize (%" PRIu64 ") to be %zu", shdr->sh_entsize, sym_size); =20 nsyms =3D shdr->sh_size / shdr->sh_entsize; @@ -292,7 +293,7 @@ static void set_symbol_addr(struct symbol *sym, void *a= rg) hash_add(symbol_addrs, &sym->addr_hash, symbol_addr_hash(&sym->addr)); =20 - debug("%s -> { %u, %lx }", sym->name, sym->addr.section, + debug("%s -> { %u, %" PRIx64 " }", sym->name, sym->addr.section, sym->addr.address); } else if (sym->addr.section !=3D addr->section || sym->addr.address !=3D addr->address) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E95A4ADDAB; Sat, 28 Feb 2026 17:34:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300083; cv=none; b=ipDRx/aECis2q8Wk1ut8blqUtPS7khKrrK8EIB8hX37PnDzKNUy5EtB4wlO3NMmKWUnxEZBSNfPHkkGhrr7eNPAD5dQSJs1mtNRKQOw3k/oc1s7jWejAsHRFP6uyRMhyH/3KngAXWXqXWlFDVPnBqq93hdgK3cIiX9MoveStjh8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300083; c=relaxed/simple; bh=gwtE0C/HA4WXWj1SxfDqkRuaPdlFJr5XvrMKodsPQpI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JvtI6o2Smf5BDVQfJk8TuAuYF0/l50gw4gIeeemK4zn+tesdoyL2giyEfqLA0XKRr9bdfTpUyV71RnN+Ke2nKtgqZyTYHemghCwbdAqCP7/pQT6RuE+SQTNTjBtFJsB3+jlYVB+isNjgEZk/UXMeTfxQ15MkhYN6j6YuRGKRDCE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mBPN/lWg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mBPN/lWg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3047AC19424; Sat, 28 Feb 2026 17:34:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300083; bh=gwtE0C/HA4WXWj1SxfDqkRuaPdlFJr5XvrMKodsPQpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mBPN/lWgssMcz+JkLuxx/piEYD5OYz4bFj1J3Asu95i643PYt6QHUi8ZvpOfGZtW6 kMmIg4J0HOlw0cew1zDccUQs1sBQ1RCGiIerzSAzUlELEW4/H9+LD7Y+CrYPRIHwiQ mx27JWPhecK9exVV/c6mt0OeHdGgjf9vU8l8z18CUufMf7NCMo2FQV9aSjOzxec6zC RhsAdWtVOsB66o19qzimS453c0ev8HZ746y5VW/4fTgjdi0L07nBUnLYcLXmMwK0Tt nhz06QVdTNoWTCP41+prsdSwd55I9HkPNwjzXJEQoH4ZJFYYSJ8RMqPJ0JfCVxB0od OZnad38dhJgvw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sami Tolvanen , Yonghong Song , Viktor Malik , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.19 097/844] bpf: crypto: Use the correct destructor kfunc type Date: Sat, 28 Feb 2026 12:20:10 -0500 Message-ID: <20260228173244.1509663-98-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sami Tolvanen [ Upstream commit b40a5d724f29fc2eed23ff353808a9aae616b48a ] With CONFIG_CFI enabled, the kernel strictly enforces that indirect function calls use a function pointer type that matches the target function. I ran into the following type mismatch when running BPF self-tests: CFI failure at bpf_obj_free_fields+0x190/0x238 (target: bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc) Internal error: Oops - CFI: 00000000f2008228 [#1] SMP ... As bpf_crypto_ctx_release() is also used in BPF programs and using a void pointer as the argument would make the verifier unhappy, add a simple stub function with the correct type and register it as the destructor kfunc instead. Signed-off-by: Sami Tolvanen Acked-by: Yonghong Song Tested-by: Viktor Malik Link: https://lore.kernel.org/r/20260110082548.113748-7-samitolvanen@google= .com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/bpf/crypto.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/crypto.c b/kernel/bpf/crypto.c index 83c4d9943084b..1d024fe7248ac 100644 --- a/kernel/bpf/crypto.c +++ b/kernel/bpf/crypto.c @@ -261,6 +261,12 @@ __bpf_kfunc void bpf_crypto_ctx_release(struct bpf_cry= pto_ctx *ctx) call_rcu(&ctx->rcu, crypto_free_cb); } =20 +__bpf_kfunc void bpf_crypto_ctx_release_dtor(void *ctx) +{ + bpf_crypto_ctx_release(ctx); +} +CFI_NOSEAL(bpf_crypto_ctx_release_dtor); + static int bpf_crypto_crypt(const struct bpf_crypto_ctx *ctx, const struct bpf_dynptr_kern *src, const struct bpf_dynptr_kern *dst, @@ -368,7 +374,7 @@ static const struct btf_kfunc_id_set crypt_kfunc_set = =3D { =20 BTF_ID_LIST(bpf_crypto_dtor_ids) BTF_ID(struct, bpf_crypto_ctx) -BTF_ID(func, bpf_crypto_ctx_release) +BTF_ID(func, bpf_crypto_ctx_release_dtor) =20 static int __init crypto_kfunc_init(void) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2DCD94ADDBC; Sat, 28 Feb 2026 17:34:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300084; cv=none; b=nQUuJt6LOptA7MUto4nVXXuIcDUhzGdj92EBHceDl0X2bvjeq3D2mzTN4hct3eAISQ6PGtT+qdaneAwBNVhaAs9K5SgzhtFwJ5F2y8QjlbwOIqwSvxZtJl/SzRTaZJMDJ2FZHFO2+XQ9Wn1mHHWxzReL2IPB5iNTz/Ksu+dG7P4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300084; c=relaxed/simple; bh=Tt05porqRyRnssxdn9DZukO1OHEjo69i5bpT6YuJ088=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qqBXz0kU2m+Av29v1mCQho0YJ8Yxs9vLUTmJ9wJUmXwquPhJgHNWA0bB2XqPfwhrcW8NgsCE72Rgm7vSj2YWa7vFsdjn1RNeaZpLcwD0lUUWdfesDLy1TAlkUTCXHO1YpDXkfYwnL51hvUlx7KhZYWfW3bemBNBwRdemeRzKdaQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iB8Q+DXl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iB8Q+DXl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43C39C19424; Sat, 28 Feb 2026 17:34:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300083; bh=Tt05porqRyRnssxdn9DZukO1OHEjo69i5bpT6YuJ088=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iB8Q+DXlOntdJ95eItB2rMV9H8nAi4f8oNXmzW9kQUCQrOk0U9pOJ9MU8Tjl9JCoc 7MiPuJzTGbanP4euNr03NT5vOuNcm5E7mgtW+poPtH10uxQiRTeZ4rra3hwsrap/vi 4om/R3/ouW84cSEJf+CImSJ0X3L7JPuseC6mYoF8wyQRjuqCGpj1zerr161YHI6q8l W5/IOlC+rqxf4maIareB4IH6n4X/rKUIyiWSfW+ICat9YINzIhPGbvuqdBdag2Ovx3 CDBFpUUal8UxRNxqFRIb2oc7e1EV8iB2Rjtvsqv0FeObypx7i8b2Mxzw+WD0xJnTzj XL570wlaNw6Tg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sami Tolvanen , Yonghong Song , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.19 098/844] bpf: net_sched: Use the correct destructor kfunc type Date: Sat, 28 Feb 2026 12:20:11 -0500 Message-ID: <20260228173244.1509663-99-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sami Tolvanen [ Upstream commit c99d97b46631c4bea0c14b7581b7a59214601e63 ] With CONFIG_CFI enabled, the kernel strictly enforces that indirect function calls use a function pointer type that matches the target function. As bpf_kfree_skb() signature differs from the btf_dtor_kfunc_t pointer type used for the destructor calls in bpf_obj_free_fields(), add a stub function with the correct type to fix the type mismatch. Signed-off-by: Sami Tolvanen Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20260110082548.113748-8-samitolvanen@google= .com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/sched/bpf_qdisc.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/net/sched/bpf_qdisc.c b/net/sched/bpf_qdisc.c index adcb618a2bfca..e9bea9890777d 100644 --- a/net/sched/bpf_qdisc.c +++ b/net/sched/bpf_qdisc.c @@ -202,6 +202,12 @@ __bpf_kfunc void bpf_kfree_skb(struct sk_buff *skb) kfree_skb(skb); } =20 +__bpf_kfunc void bpf_kfree_skb_dtor(void *skb) +{ + bpf_kfree_skb(skb); +} +CFI_NOSEAL(bpf_kfree_skb_dtor); + /* bpf_qdisc_skb_drop - Drop an skb by adding it to a deferred free list. * @skb: The skb whose reference to be released and dropped. * @to_free_list: The list of skbs to be dropped. @@ -449,7 +455,7 @@ static struct bpf_struct_ops bpf_Qdisc_ops =3D { .owner =3D THIS_MODULE, }; =20 -BTF_ID_LIST_SINGLE(bpf_sk_buff_dtor_ids, func, bpf_kfree_skb) +BTF_ID_LIST_SINGLE(bpf_sk_buff_dtor_ids, func, bpf_kfree_skb_dtor) =20 static int __init bpf_qdisc_kfunc_init(void) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 368464B8DD5; Sat, 28 Feb 2026 17:34:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300085; cv=none; b=uEF1okTsUJs4eCdt7BLmE1wj97G4OJOroMHPrHvuwyh8U/jqI2KGweOm852YbcOzGUejp31fuQZEbG1fYfrDF4VTVCNIU3qHDc9VievL0MDdOOBAr63/0pZaahRS/F9wkRCazFTf98stQAK/CnANV3TkhGGYoN4SDttzTXuNnls= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300085; c=relaxed/simple; bh=3c4NhBPLgo9FfMKcLK5LLw/+6nibsJH+j22RB86RwJw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H+FZWXTjFjHXIrZu549rojqb6+W0hsfIEo4wmob/Xt4tYdbRVfXywZz7mH9tdGlCkny9+GP0QYgcNguiMinR5QV2qYooYF/JRVPyl7LOGJZ1gWISVdVdFBiH/7ZmW9kZ2lr78RgT2Fi4ZUMwCrtHXBv7PkKDEWf6QwVCGPveyJs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UXbE0TXP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UXbE0TXP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BBF0C116D0; Sat, 28 Feb 2026 17:34:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300084; bh=3c4NhBPLgo9FfMKcLK5LLw/+6nibsJH+j22RB86RwJw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UXbE0TXPjJxRqTpGFRcs6FfMMfI/FXcDUkNxN3tgRPSApoGSv2xqt+uBVu6wDhAu8 n1506g1hqEq5qG6IrTkYh+HW9MnzCaF4IGArdW6N7PupMGc1EOVR1nDmOS64ygwMIK jU3jHKkyc42U3HZjskMw3aX0KLaX6vEHmYlj4IHeMY14gjdx6KdbLG6+RYSiyypb43 YV11gSA5245y1uEpbO5PGfmuewQjLpHeKc+fiAM7bSzdeWo5puy8E+1klHVvxHod5N umjprdZH1UD91xIGFq1rjW8kwHKi0WDZ4ldWS9j7v9MRZ2yOA4l7Y+irxlFDtNnFxJ fICWPXDVT8YdA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alexei Starovoitov , Hao Sun , Puranjay Mohan , Sasha Levin Subject: [PATCH 6.19 099/844] bpf: Recognize special arithmetic shift in the verifier Date: Sat, 28 Feb 2026 12:20:12 -0500 Message-ID: <20260228173244.1509663-100-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexei Starovoitov [ Upstream commit bffacdb80b93b7b5e96b26fad64cc490a6c7d6c7 ] cilium bpf_wiregard.bpf.c when compiled with -O1 fails to load with the following verifier log: 192: (79) r2 =3D *(u64 *)(r10 -304) ; R2=3Dpkt(r=3D40) R10=3Dfp0 fp-304= =3Dpkt(r=3D40) ... 227: (85) call bpf_skb_store_bytes#9 ; R0=3Dscalar() 228: (bc) w2 =3D w0 ; R0=3Dscalar() R2=3Dscalar(smin=3D= 0,smax=3Dumax=3D0xffffffff,var_off=3D(0x0; 0xffffffff)) 229: (c4) w2 s>>=3D 31 ; R2=3Dscalar(smin=3D0,smax=3Dumax= =3D0xffffffff,smin32=3D-1,smax32=3D0,var_off=3D(0x0; 0xffffffff)) 230: (54) w2 &=3D -134 ; R2=3Dscalar(smin=3D0,smax=3Dumax= =3Dumax32=3D0xffffff7a,smax32=3D0x7fffff7a,var_off=3D(0x0; 0xffffff7a)) ... 232: (66) if w2 s> 0xffffffff goto pc+125 ; R2=3Dscalar(smin=3Dumin=3Du= min32=3D0x80000000,smax=3Dumax=3Dumax32=3D0xffffff7a,smax32=3D-134,var_off= =3D(0x80000000; 0x7fffff7a)) ... 238: (79) r4 =3D *(u64 *)(r10 -304) ; R4=3Dscalar() R10=3Dfp0 fp-304=3D= scalar() 239: (56) if w2 !=3D 0xffffff78 goto pc+210 ; R2=3D0xffffff78 // -136 ... 258: (71) r1 =3D *(u8 *)(r4 +0) R4 invalid mem access 'scalar' The error might confuse most bpf authors, since fp-304 slot had 'pkt' pointer at insn 192 and became 'scalar' at 238. That happened because bpf_skb_store_bytes() clears all packet pointers including those in the stack. On the first glance it might look like a bug in the source code, since ctx->data pointer should have been reloaded after the call to bpf_skb_store_bytes(). The relevant part of cilium source code looks like this: // bpf/lib/nodeport.h int dsr_set_ipip6() { if (ctx_adjust_hroom(...)) return DROP_INVALID; // -134 if (ctx_store_bytes(...)) return DROP_WRITE_ERROR; // -141 return 0; } bool dsr_fail_needs_reply(int code) { if (code =3D=3D DROP_FRAG_NEEDED) // -136 return true; return false; } tail_nodeport_ipv6_dsr() { ret =3D dsr_set_ipip6(...); if (!IS_ERR(ret)) { ... } else { if (dsr_fail_needs_reply(ret)) return dsr_reply_icmp6(...); } } The code doesn't have arithmetic shift by 31 and it reloads ctx->data every time it needs to access it. So it's not a bug in the source code. The reason is DAGCombiner::foldSelectCCToShiftAnd() LLVM transformation: // If this is a select where the false operand is zero and the compare is= a // check of the sign bit, see if we can perform the "gzip trick": // select_cc setlt X, 0, A, 0 -> and (sra X, size(X)-1), A // select_cc setgt X, 0, A, 0 -> and (not (sra X, size(X)-1)), A The conditional branch in dsr_set_ipip6() and its return values are optimized into BPF_ARSH plus BPF_AND: 227: (85) call bpf_skb_store_bytes#9 228: (bc) w2 =3D w0 229: (c4) w2 s>>=3D 31 ; R2=3Dscalar(smin=3D0,smax=3Dumax=3D0xffffffff,sm= in32=3D-1,smax32=3D0,var_off=3D(0x0; 0xffffffff)) 230: (54) w2 &=3D -134 ; R2=3Dscalar(smin=3D0,smax=3Dumax=3Dumax32=3D0xff= ffff7a,smax32=3D0x7fffff7a,var_off=3D(0x0; 0xffffff7a)) after insn 230 the register w2 can only be 0 or -134, but the verifier approximates it, since there is no way to represent two scalars in bpf_reg_state. After fallthough at insn 232 the w2 can only be -134, hence the branch at insn 239: (56) if w2 !=3D -136 goto pc+210 should be always taken, and trapping insn 258 should never execute. LLVM generated correct code, but the verifier follows impossible path and rejects valid program. To fix this issue recognize this special LLVM optimization and fork the verifier state. So after insn 229: (c4) w2 s>>=3D 31 the verifier has two states to explore: one with w2 =3D 0 and another with w2 =3D 0xffffffff which makes the verifier accept bpf_wiregard.c A similar pattern exists were OR operation is used in place of the AND operation, the verifier detects that pattern as well by forking the state before the OR operation with a scalar in range [-1,0]. Note there are 20+ such patterns in bpf_wiregard.o compiled with -O1 and -O2, but they're rarely seen in other production bpf programs, so push_stack() approach is not a concern. Reported-by: Hao Sun Signed-off-by: Alexei Starovoitov Co-developed-by: Puranjay Mohan Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260112201424.816836-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/bpf/verifier.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 7069e9f527eaa..1999b8d244f64 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -15499,6 +15499,35 @@ static bool is_safe_to_compute_dst_reg_range(struc= t bpf_insn *insn, } } =20 +static int maybe_fork_scalars(struct bpf_verifier_env *env, struct bpf_ins= n *insn, + struct bpf_reg_state *dst_reg) +{ + struct bpf_verifier_state *branch; + struct bpf_reg_state *regs; + bool alu32; + + if (dst_reg->smin_value =3D=3D -1 && dst_reg->smax_value =3D=3D 0) + alu32 =3D false; + else if (dst_reg->s32_min_value =3D=3D -1 && dst_reg->s32_max_value =3D= =3D 0) + alu32 =3D true; + else + return 0; + + branch =3D push_stack(env, env->insn_idx + 1, env->insn_idx, false); + if (IS_ERR(branch)) + return PTR_ERR(branch); + + regs =3D branch->frame[branch->curframe]->regs; + if (alu32) { + __mark_reg32_known(®s[insn->dst_reg], 0); + __mark_reg32_known(dst_reg, -1ull); + } else { + __mark_reg_known(®s[insn->dst_reg], 0); + __mark_reg_known(dst_reg, -1ull); + } + return 0; +} + /* WARNING: This function does calculations on 64-bit values, but the actu= al * execution may occur on 32-bit values. Therefore, things like bitshifts * need extra checks in the 32-bit case. @@ -15561,11 +15590,21 @@ static int adjust_scalar_min_max_vals(struct bpf_= verifier_env *env, scalar_min_max_mul(dst_reg, &src_reg); break; case BPF_AND: + if (tnum_is_const(src_reg.var_off)) { + ret =3D maybe_fork_scalars(env, insn, dst_reg); + if (ret) + return ret; + } dst_reg->var_off =3D tnum_and(dst_reg->var_off, src_reg.var_off); scalar32_min_max_and(dst_reg, &src_reg); scalar_min_max_and(dst_reg, &src_reg); break; case BPF_OR: + if (tnum_is_const(src_reg.var_off)) { + ret =3D maybe_fork_scalars(env, insn, dst_reg); + if (ret) + return ret; + } dst_reg->var_off =3D tnum_or(dst_reg->var_off, src_reg.var_off); scalar32_min_max_or(dst_reg, &src_reg); scalar_min_max_or(dst_reg, &src_reg); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9D994B8DE7; Sat, 28 Feb 2026 17:34:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300086; cv=none; b=tOd1Pgmpvt2cA3YRLRoKt65b69uPe+3ZfJmfuWRg8XviK3Fd/4eIrpq/IBPTLlc8o+p/YXWfSYS2OlPrVrMd3E7YaUBjWHYCkVwIsvZtEGS10fjpX3AGtdb5+FJdmiUCzfO9bw9+4rDwc+8GC3xfeEfvKaBqIBtp0NTEQrYPOZo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300086; c=relaxed/simple; bh=2FxwK8i+h0M1bYTgtHo9Ve86ZHv07KMFCI3ENdzh6/E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Uru+2OKadZIS4RctBSWnrVZJP2jKvkrBrVl6sIrUCB4yrggYJOM8DUfVxtj7DlfQ9FrRVHIdM9n0fQ3Xui5rrcDwkFKP6R8MPMLgTf4zl4pRJPXg4iu+ekA3mmea7p5zIbbg/P274FUKEHM/Y8kWwaKIrlO1L/CAE44ydhnOdtU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dkDUP+79; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dkDUP+79" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2EEE6C19423; Sat, 28 Feb 2026 17:34:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300085; bh=2FxwK8i+h0M1bYTgtHo9Ve86ZHv07KMFCI3ENdzh6/E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dkDUP+79VYvD8GY8C7nN0KDa45hjMd7L8RYKHhqgvczhHukzN9SwUhFuX4PRMzjZA RXfYgG6pDgv5Bgdq1EbLmc9of6jbiNmc9pa1LwVc/Wrsld4GyWeqdMDRIb63n2XQVV Y5M1bmgpgFVTf7jJaLiyXnzgVYtmRO3TDh53Xt7rMze6b+YFfVdKUIgeG7QQMCQhkt K4yC2sheWcBllFv7hWMeE3+VHX0L/cQAXv3DZKgUl3pojkFj4BnmMUveGoh73D05CT ypldFzPqF0mQJYuBhs5oNdST2ip0e3mHisazhm8vLLan+jbIXx3lNYQz0F/aGNj/nd ydAZ+x6OR25Ow== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Imran Khan , Thomas Gleixner , Sasha Levin Subject: [PATCH 6.19 100/844] genirq/cpuhotplug: Notify about affinity changes breaking the affinity mask Date: Sat, 28 Feb 2026 12:20:13 -0500 Message-ID: <20260228173244.1509663-101-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Imran Khan [ Upstream commit dd9f6d30c64001ca4dde973ac04d8d155e856743 ] During CPU offlining the interrupts affined to that CPU are moved to other online CPUs, which might break the original affinity mask if the outgoing CPU was the last online CPU in that mask. This change is not propagated to irq_desc::affinity_notify(), which leaves users of the affinity notifier mechanism with stale information. Avoid this by scheduling affinity change notification work for interrupts that were affined to the CPU being offlined, if the new target CPU is not part of the original affinity mask. Since irq_set_affinity_locked() uses the same logic to schedule affinity change notification work, split out this logic into a dedicated function and use that at both places. [ tglx: Removed the EXPORT(), removed the !SMP stub, moved the prototype, added a lockdep assert instead of a comment, fixed up coding style and name space. Polished and clarified the change log ] Signed-off-by: Imran Khan Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260113143727.1041265-1-imran.f.khan@oracle= .com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/irq/cpuhotplug.c | 6 ++++-- kernel/irq/internals.h | 2 +- kernel/irq/manage.c | 26 ++++++++++++++++++-------- 3 files changed, 23 insertions(+), 11 deletions(-) diff --git a/kernel/irq/cpuhotplug.c b/kernel/irq/cpuhotplug.c index 755346ea98196..cd5689e383b00 100644 --- a/kernel/irq/cpuhotplug.c +++ b/kernel/irq/cpuhotplug.c @@ -177,9 +177,11 @@ void irq_migrate_all_off_this_cpu(void) bool affinity_broken; =20 desc =3D irq_to_desc(irq); - scoped_guard(raw_spinlock, &desc->lock) + scoped_guard(raw_spinlock, &desc->lock) { affinity_broken =3D migrate_one_irq(desc); - + if (affinity_broken && desc->affinity_notify) + irq_affinity_schedule_notify_work(desc); + } if (affinity_broken) { pr_debug_ratelimited("IRQ %u: no longer affine to CPU%u\n", irq, smp_processor_id()); diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h index 0164ca48da59e..5568ed3a8b852 100644 --- a/kernel/irq/internals.h +++ b/kernel/irq/internals.h @@ -135,6 +135,7 @@ extern bool irq_can_set_affinity_usr(unsigned int irq); =20 extern int irq_do_set_affinity(struct irq_data *data, const struct cpumask *dest, bool force); +extern void irq_affinity_schedule_notify_work(struct irq_desc *desc); =20 #ifdef CONFIG_SMP extern int irq_setup_affinity(struct irq_desc *desc); @@ -142,7 +143,6 @@ extern int irq_setup_affinity(struct irq_desc *desc); static inline int irq_setup_affinity(struct irq_desc *desc) { return 0; } #endif =20 - #define for_each_action_of_desc(desc, act) \ for (act =3D desc->action; act; act =3D act->next) =20 diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 349ae7979da0e..4873b0f73df96 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -347,6 +347,21 @@ static bool irq_set_affinity_deactivated(struct irq_da= ta *data, return true; } =20 +/** + * irq_affinity_schedule_notify_work - Schedule work to notify about affin= ity change + * @desc: Interrupt descriptor whose affinity changed + */ +void irq_affinity_schedule_notify_work(struct irq_desc *desc) +{ + lockdep_assert_held(&desc->lock); + + kref_get(&desc->affinity_notify->kref); + if (!schedule_work(&desc->affinity_notify->work)) { + /* Work was already scheduled, drop our extra ref */ + kref_put(&desc->affinity_notify->kref, desc->affinity_notify->release); + } +} + int irq_set_affinity_locked(struct irq_data *data, const struct cpumask *m= ask, bool force) { @@ -367,14 +382,9 @@ int irq_set_affinity_locked(struct irq_data *data, con= st struct cpumask *mask, irq_copy_pending(desc, mask); } =20 - if (desc->affinity_notify) { - kref_get(&desc->affinity_notify->kref); - if (!schedule_work(&desc->affinity_notify->work)) { - /* Work was already scheduled, drop our extra ref */ - kref_put(&desc->affinity_notify->kref, - desc->affinity_notify->release); - } - } + if (desc->affinity_notify) + irq_affinity_schedule_notify_work(desc); + irqd_set(data, IRQD_AFFINITY_SET); =20 return ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B59464B8DFA; Sat, 28 Feb 2026 17:34:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300086; cv=none; b=ABKQhYJ8dQ8jIGzhyG1psMmieMhGLTdeshBPGXZVl/s3sqRsEtJEzVfkHYh/iMBz2NkdWhBCVJT2vhn0XCuUtTXj0b5FBnd7JU7iIf+tN/cOcTqOA9qpWlyoPGpWAE6UkvfdkOJeYbrOXCtTPZa0WJxfv+ewHsTG/OCHJ2j3N5o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300086; c=relaxed/simple; bh=n4I3ZRd9nos2v/LrmTbU4sUnLQMETJn5sEgj8BQmspU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LN2JxOTTo2qeu1IgMPOM38lZQSIQaB1JG9TaAvKJjd+SOpw34BQ8LsyeSvnj9dZyjP+9xIs/szRWsdfuG21dgr0dfYUZ9OOa4x46xxK+YoxxSsHlit9Fjpa7405pHAvrEe8UaPNCsdkiOBCqAvSSDDXIRtAAwIJ/49ekbAt8HLI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a2w6WLug; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a2w6WLug" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A166C2BCAF; Sat, 28 Feb 2026 17:34:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300086; bh=n4I3ZRd9nos2v/LrmTbU4sUnLQMETJn5sEgj8BQmspU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a2w6WLugSYu41Ap68YbTOsmiYsh2FAJY2XuXRN+GuMQ3cJoBYURIXxRd9fcn6frUT VgFDoUTZpcZJ01X0X0dFUtMqUStaY9/BwiDasgnqJ6/ed1vCVGosfmKDTQyC/cPobr Zc94oCWdMpIy6a0N1JAXDtgvoseZCIQOmlwhMSE9kI1Z8oJUtTDPcHYU6g6PrjSjAP mvbnw+B2aavsOld7a+Q58WJeLyH4tH9LmYzNlLKq3j9wkIV+slZHKFtgVJKBP+Elg0 Ws/iA5dmTZcK+SH9lPfUMYLb+xXFK/sOm0CDK/qe3YBGCz78nYKRirGi9ibR0wT/D1 sbqHQZeI1DqTg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Anton Protopopov , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.19 101/844] bpf: Properly mark live registers for indirect jumps Date: Sat, 28 Feb 2026 12:20:14 -0500 Message-ID: <20260228173244.1509663-102-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Anton Protopopov [ Upstream commit d1aab1ca576c90192ba961094d51b0be6355a4d6 ] For a `gotox rX` instruction the rX register should be marked as used in the compute_insn_live_regs() function. Fix this. Signed-off-by: Anton Protopopov Link: https://lore.kernel.org/r/20260114162544.83253-2-a.s.protopopov@gmail= .com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/bpf/verifier.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 1999b8d244f64..783d984d7884d 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -24852,6 +24852,12 @@ static void compute_insn_live_regs(struct bpf_veri= fier_env *env, case BPF_JMP32: switch (code) { case BPF_JA: + def =3D 0; + if (BPF_SRC(insn->code) =3D=3D BPF_X) + use =3D dst; + else + use =3D 0; + break; case BPF_JCOND: def =3D 0; use =3D 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A99384BC015; Sat, 28 Feb 2026 17:34:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300087; cv=none; b=t16QyI4J8h4AzWrbPL1PrKwxwYoUQL8SPckV+Eg3ihBrHmUMLSh5qZNVLRI/8Kh4AzdHnNGzqkjvgibHIa563wNZiIA6nh2omTTXpLgG8qrN37VhuMPiLK+d43XsqoBKojoP7CcKVgSvqAAQW4hKAe2GMirhVQKwNmjcZMoJI+E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300087; c=relaxed/simple; bh=kvUMyJMY36JwN472Kvu7Uo2pNYLuOdV0dgpV5Exx4wQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cJL1IFc1yAylqM7iwjzZJSRZELQsyJ4nE/NewgkSoadOCj4MCuN1eAqu8JjPj7C3835xg7NJJCid7zB7qDdH4QjkPYJh/rgOdtNIoI5xbYtTHLSg0A9WBL38jjQGu2hFFT7MJl3qqB2BiCCfwdX+m3QMl618HqepxiXKbJW4VrU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kGtHXMF2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kGtHXMF2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC517C19424; Sat, 28 Feb 2026 17:34:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300087; bh=kvUMyJMY36JwN472Kvu7Uo2pNYLuOdV0dgpV5Exx4wQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kGtHXMF2OmMk+11Y9LjlvuAXgCJ2nEWMvV6ob7qq0tq+cp0jAUciiynKtGVa6nEFD gbDqZtJyOsN52eBtgICW69vAsPpFhDiZ/2iOgElwDnE5+EhZgg2JGBLpxf0YHCcq0+ nclgSRMUaxSsKzj3xQH5AWycAefMJ0Gd/Xx3G4VlqsLG65O4Wo6rBrwMZzrjzSKdaa Z0B03dCeU1Pv4U28ZybH7d0AW+Ni9D5fj/3m/Dh5mlD2MMiikfkC+TV4o9Oi+ZbO12 FxZtW49aLUOh1EM/mhFGYsREBuc+5DjdrP4ukx+GjvQ368mKTf0VaRrMhhFhCbUVkE eoqY+Z0X84CgQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Namhyung Kim , Rosalie Fang , Peter Zijlstra , Sasha Levin Subject: [PATCH 6.19 102/844] perf/core: Fix slow perf_event_task_exit() with LBR callstacks Date: Sat, 28 Feb 2026 12:20:15 -0500 Message-ID: <20260228173244.1509663-103-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Namhyung Kim [ Upstream commit 4960626f956d63dce57f099016c2ecbe637a8229 ] I got a report that a task is stuck in perf_event_exit_task() waiting for global_ctx_data_rwsem. On large systems with lots threads, it'd have performance issues when it grabs the lock to iterate all threads in the system to allocate the context data. And it'd block task exit path which is problematic especially under memory pressure. perf_event_open perf_event_alloc attach_perf_ctx_data attach_global_ctx_data percpu_down_write (global_ctx_data_rwsem) for_each_process_thread alloc_task_ctx_data do_exit perf_event_exit_task percpu_down_read (global= _ctx_data_rwsem) It should not hold the global_ctx_data_rwsem on the exit path. Let's skip allocation for exiting tasks and free the data carefully. Reported-by: Rosalie Fang Suggested-by: Peter Zijlstra Signed-off-by: Namhyung Kim Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260112165157.1919624-1-namhyung@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/events/core.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 8cca800946248..69c56cad88a89 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -5280,9 +5280,20 @@ attach_task_ctx_data(struct task_struct *task, struc= t kmem_cache *ctx_cache, return -ENOMEM; =20 for (;;) { - if (try_cmpxchg((struct perf_ctx_data **)&task->perf_ctx_data, &old, cd)= ) { + if (try_cmpxchg(&task->perf_ctx_data, &old, cd)) { if (old) perf_free_ctx_data_rcu(old); + /* + * Above try_cmpxchg() pairs with try_cmpxchg() from + * detach_task_ctx_data() such that + * if we race with perf_event_exit_task(), we must + * observe PF_EXITING. + */ + if (task->flags & PF_EXITING) { + /* detach_task_ctx_data() may free it already */ + if (try_cmpxchg(&task->perf_ctx_data, &cd, NULL)) + perf_free_ctx_data_rcu(cd); + } return 0; } =20 @@ -5328,6 +5339,8 @@ attach_global_ctx_data(struct kmem_cache *ctx_cache) /* Allocate everything */ scoped_guard (rcu) { for_each_process_thread(g, p) { + if (p->flags & PF_EXITING) + continue; cd =3D rcu_dereference(p->perf_ctx_data); if (cd && !cd->global) { cd->global =3D 1; @@ -14294,8 +14307,11 @@ void perf_event_exit_task(struct task_struct *task) =20 /* * Detach the perf_ctx_data for the system-wide event. + * + * Done without holding global_ctx_data_rwsem; typically + * attach_global_ctx_data() will skip over this task, but otherwise + * attach_task_ctx_data() will observe PF_EXITING. */ - guard(percpu_read)(&global_ctx_data_rwsem); detach_task_ctx_data(task); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05A774BCAA0; Sat, 28 Feb 2026 17:34:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300089; cv=none; b=JfLOdBABMY1ya5E8s+akOy18p9WNV8RBaVivCxLxGU+ls8dbf6zh6GdoxInKJxu68iV21YFH7pUYSPuStlPEslqWFem6j8o2YP07l9pbK2SG0Dz+op6n9KyLJeQdjrSNbhIc8jswzyaDgAuBz2AyvzimyEMU0QFNrSbs42bczyo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300089; c=relaxed/simple; bh=z6QPyugg6VyaFBQ2lBqGIoU1ZPNNnRArOOY/e7Iit6M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PrBbUVwaw5HEjNwSmtKtDiCeLUD9WY3BrX/w1hVcJNBOpXwU1YfiHYsT+xbCv4fpFqWrpERR5jA55q1KDerNJAVHW25+RpEK2FjXfqSPwkhBkVmEDfu9R/vxzAhGSv/K6YW75Hcjt1AEwRHpmeBzgpToD62WgC419w6rfW3yAtY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ddC8ogpd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ddC8ogpd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8978C19423; Sat, 28 Feb 2026 17:34:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300088; bh=z6QPyugg6VyaFBQ2lBqGIoU1ZPNNnRArOOY/e7Iit6M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ddC8ogpd094VRZl9X4uofD0F1P6PWMCPZkLII6nXhsllxelpFZwv5bal0QdNAyZUt nLjMuw8eQKPhZSBSFmd88GMWxVvd+2ry/owyQsveAcPDaL9eXPHmTPPW1TITIcrmEG MRqaNoK087K8gHdfdLZD+ed7q5R+f7n7SwyLbpAhquUE4RzuDnp6+jT+KZ78DuTo3B emkQCbk83zyhIeCOmlS9IOhDN+EpyDdkJUCdK4tyLlv+b242hRaM3GlxvHxpk6upiN RFHO3ydsLByJqUnPl/0cax+agvboaY3c5DUazyUoAWN2+YXeUL6RnuTRf6yV1VT1AG J3NHPz6U28Pag== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiri Olsa , Mahe Tardy , Andrii Nakryiko , "Steven Rostedt (Google)" , Will Deacon , Sasha Levin Subject: [PATCH 6.19 103/844] arm64/ftrace,bpf: Fix partial regs after bpf_prog_run Date: Sat, 28 Feb 2026 12:20:16 -0500 Message-ID: <20260228173244.1509663-104-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiri Olsa [ Upstream commit 276f3b6daf6024ae2742afd161e7418a5584a660 ] Mahe reported issue with bpf_override_return helper not working when executed from kprobe.multi bpf program on arm. The problem is that on arm we use alternate storage for pt_regs object that is passed to bpf_prog_run and if any register is changed (which is the case of bpf_override_return) it's not propagated back to actual pt_regs object. Fixing this by introducing and calling ftrace_partial_regs_update function to propagate the values of changed registers (ip and stack). Reported-by: Mahe Tardy Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Reviewed-by: Steven Rostedt (Google) Acked-by: Will Deacon Link: https://lore.kernel.org/bpf/20260112121157.854473-1-jolsa@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/ftrace_regs.h | 25 +++++++++++++++++++++++++ kernel/trace/bpf_trace.c | 1 + 2 files changed, 26 insertions(+) diff --git a/include/linux/ftrace_regs.h b/include/linux/ftrace_regs.h index 15627ceea9bcc..386fa48c4a957 100644 --- a/include/linux/ftrace_regs.h +++ b/include/linux/ftrace_regs.h @@ -33,6 +33,31 @@ struct ftrace_regs; #define ftrace_regs_get_frame_pointer(fregs) \ frame_pointer(&arch_ftrace_regs(fregs)->regs) =20 +static __always_inline void +ftrace_partial_regs_update(struct ftrace_regs *fregs, struct pt_regs *regs= ) { } + +#else + +/* + * ftrace_partial_regs_update - update the original ftrace_regs from regs + * @fregs: The ftrace_regs to update from @regs + * @regs: The partial regs from ftrace_partial_regs() that was updated + * + * Some architectures have the partial regs living in the ftrace_regs + * structure, whereas other architectures need to make a different copy + * of the @regs. If a partial @regs is retrieved by ftrace_partial_regs() = and + * if the code using @regs updates a field (like the instruction pointer or + * stack pointer) it may need to propagate that change to the original @fr= egs + * it retrieved the partial @regs from. Use this function to guarantee that + * update happens. + */ +static __always_inline void +ftrace_partial_regs_update(struct ftrace_regs *fregs, struct pt_regs *regs) +{ + ftrace_regs_set_instruction_pointer(fregs, instruction_pointer(regs)); + ftrace_regs_set_return_value(fregs, regs_return_value(regs)); +} + #endif /* HAVE_ARCH_FTRACE_REGS */ =20 /* This can be overridden by the architectures */ diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 59c2394981c72..325579c7da260 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -2564,6 +2564,7 @@ kprobe_multi_link_prog_run(struct bpf_kprobe_multi_li= nk *link, old_run_ctx =3D bpf_set_run_ctx(&run_ctx.session_ctx.run_ctx); err =3D bpf_prog_run(link->link.prog, regs); bpf_reset_run_ctx(old_run_ctx); + ftrace_partial_regs_update(fregs, bpf_kprobe_multi_pt_regs_ptr()); rcu_read_unlock(); =20 out: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AFC8B4BCAAB; Sat, 28 Feb 2026 17:34:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300089; cv=none; b=MOlaPd0vf1IGmOHW2oHkS2g3N08Cl/HvulKf6ai0sOV231XSvx6usLBd30p651EBnk0XBABkptAWkJRMns9bwTW3Ib6NEt2gJep/b7D/wx8VGRhzusUokkQgT9efsTFrf8AB8KO5sReq5Lcn3xp2NpYKZO6Xc5ObDGy1nXWX1sU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300089; c=relaxed/simple; bh=ekwY7CiqwLp2u9VBMcGssaKBwBUJCQ7Kk2xOjUl9ol8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CPIAk0+sWT8tf+bUT7A037U/LrLXR6TxJ+kshRq6aooBmRaC6ezLi249BPskzpn4imTdvN3l7NCMwPM2bYiDeDSotxHoSw9z+RtipZGpu4HrdX/pukamQoeKDCtf2tFPZ/elIJnimDH/YmPAVp2vnpBT+ZGnI4Xq+VXYCLDpY+U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=emF7yaKe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="emF7yaKe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E80CDC19424; Sat, 28 Feb 2026 17:34:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300089; bh=ekwY7CiqwLp2u9VBMcGssaKBwBUJCQ7Kk2xOjUl9ol8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=emF7yaKelSf9jCNN7JPz9iosWL/ieNd+hlXRAMn0huFbFCOfNbSP9bax+8Dw1nZ1k 3urNAdQLYKUldZuxUZFtHszXnu1/4OEdpwqOp+MgOIoCRQt99FqKJgItpUtrcj2z+U Bu2e1ck3GdOCIX4VqShFgnTeIRlH99NQrlpCP53h7oDkQutNu/A3XkFsuS4QzSoNB0 ov0e3RIAYm63AJjFAvzBUiDW6rslSjSgkh2R3Z1q6KxWIsigDEb0Jyx0iHH+Gxvmf8 MMBvmTncxr/v3mSjjq6URHMua54C7CGo7HEFhhNDhfmFuiy2i6tocvB/l6sP+22hCI E4ggyCl+loryw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Niklas=20S=C3=B6derlund?= , Daniel Lezcano , Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.19 104/844] clocksource/drivers/sh_tmu: Always leave device running after probe Date: Sat, 28 Feb 2026 12:20:17 -0500 Message-ID: <20260228173244.1509663-105-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Niklas S=C3=B6derlund [ Upstream commit b1278972b08e480990e2789bdc6a7c918bc349be ] The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resum= e+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF40000= 1/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_contro= l+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-0= 9926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (= DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe. Signed-off-by: Niklas S=C3=B6derlund Signed-off-by: Daniel Lezcano Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251202221341.1856773-1-niklas.soderlund+re= nesas@ragnatech.se Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clocksource/sh_tmu.c | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/drivers/clocksource/sh_tmu.c b/drivers/clocksource/sh_tmu.c index beffff81c00f3..3fc6ed9b56300 100644 --- a/drivers/clocksource/sh_tmu.c +++ b/drivers/clocksource/sh_tmu.c @@ -143,16 +143,6 @@ static void sh_tmu_start_stop_ch(struct sh_tmu_channel= *ch, int start) =20 static int __sh_tmu_enable(struct sh_tmu_channel *ch) { - int ret; - - /* enable clock */ - ret =3D clk_enable(ch->tmu->clk); - if (ret) { - dev_err(&ch->tmu->pdev->dev, "ch%u: cannot enable clock\n", - ch->index); - return ret; - } - /* make sure channel is disabled */ sh_tmu_start_stop_ch(ch, 0); =20 @@ -174,7 +164,6 @@ static int sh_tmu_enable(struct sh_tmu_channel *ch) if (ch->enable_count++ > 0) return 0; =20 - pm_runtime_get_sync(&ch->tmu->pdev->dev); dev_pm_syscore_device(&ch->tmu->pdev->dev, true); =20 return __sh_tmu_enable(ch); @@ -187,9 +176,6 @@ static void __sh_tmu_disable(struct sh_tmu_channel *ch) =20 /* disable interrupts in TMU block */ sh_tmu_write(ch, TCR, TCR_TPSC_CLK4); - - /* stop clock */ - clk_disable(ch->tmu->clk); } =20 static void sh_tmu_disable(struct sh_tmu_channel *ch) @@ -203,7 +189,6 @@ static void sh_tmu_disable(struct sh_tmu_channel *ch) __sh_tmu_disable(ch); =20 dev_pm_syscore_device(&ch->tmu->pdev->dev, false); - pm_runtime_put(&ch->tmu->pdev->dev); } =20 static void sh_tmu_set_next(struct sh_tmu_channel *ch, unsigned long delta, @@ -552,7 +537,6 @@ static int sh_tmu_setup(struct sh_tmu_device *tmu, stru= ct platform_device *pdev) goto err_clk_unprepare; =20 tmu->rate =3D clk_get_rate(tmu->clk) / 4; - clk_disable(tmu->clk); =20 /* Map the memory resource. */ ret =3D sh_tmu_map_memory(tmu); @@ -626,8 +610,6 @@ static int sh_tmu_probe(struct platform_device *pdev) out: if (tmu->has_clockevent || tmu->has_clocksource) pm_runtime_irq_safe(&pdev->dev); - else - pm_runtime_idle(&pdev->dev); =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87C2A4BCABD; Sat, 28 Feb 2026 17:34:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300090; cv=none; b=ct3OkJSKrvj+ri4RtImF5vBx6nF3y8g1nocH+eKS/8yYWyro8TXrFtKNunx/+n8JlDDzjYPdoOK70U3OcITAQhA3D3h5G7N47XtPsedg6tn+4kOCFvcHIKpKZifW0Sx+st+exFMAYsoU+VR0vA9O9HV/h4t+tgIitgBpz8aGS4Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300090; c=relaxed/simple; bh=oEQ7cxlEZJ+m+808c6oLL95QBAxAtktXtcZfXJjr7YI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pg3cWtkS57nkx6qbVPeSo0yHq/fyCyMZ6OrkuyYmMW/1YucZcaq/+MxiJ2n5a2vrxgjtwimbUFgVpmhQ1RBJG/kfwNjxqs8Lw8XjWKOsjdV/YB2/0TFyQKRhRQJLQyIHoVa6sa0AWDtAs2nubk8V1E5lJIo7de2IA/92ADYD67c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JyI5HPve; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JyI5HPve" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6A51C116D0; Sat, 28 Feb 2026 17:34:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300090; bh=oEQ7cxlEZJ+m+808c6oLL95QBAxAtktXtcZfXJjr7YI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JyI5HPve/iXATzANggjllAXf5qlaxVSQRRElgXoUqpfKTluPwTFmfYzMSTHH+ufVB KTXcXtPw0Hv5xN5FoIISl6XsxUnETc6m28Q1YbowimjWQHacsuYGQkEQcn2nM74hok mp3tRc+/jABylrM0K/RX41AsRG8j8X5CYgLI9S5aNZNHBd5l7o4MDCyL2c4NxIvVqQ EQz4CVZCJYQfgYUOZuJ/fdT7vDM2T/dVVlyPYEydAgd8snh6h3CpSfvZhaW7YZGq5K g0JXZdtBiZTZj56Zvo7eHGpJB5i72dDc3Tz25bPT2uXdcD1t8Oi+niJaOsMcSOnIDN UTAnjY172TAtw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bartosz Golaszewski , Daniel Lezcano , Sasha Levin Subject: [PATCH 6.19 105/844] clocksource/drivers/timer-integrator-ap: Add missing Kconfig dependency on OF Date: Sat, 28 Feb 2026 12:20:18 -0500 Message-ID: <20260228173244.1509663-106-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bartosz Golaszewski [ Upstream commit 2246464821e2820572e6feefca2029f17629cc50 ] This driver accesses the of_aliases global variable declared in linux/of.h and defined in drivers/base/of.c. It requires OF support or will cause a link failure. Add the missing Kconfig dependency. Closes: https://lore.kernel.org/oe-kbuild-all/202601152233.og6LdeUo-lkp@int= el.com/ Signed-off-by: Bartosz Golaszewski Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260116111723.10585-1-bartosz.golaszewski@o= ss.qualcomm.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clocksource/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index aa59e5b133510..fd91127065454 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -254,6 +254,7 @@ config KEYSTONE_TIMER =20 config INTEGRATOR_AP_TIMER bool "Integrator-AP timer driver" if COMPILE_TEST + depends on OF select CLKSRC_MMIO help Enables support for the Integrator-AP timer. --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 663A84BCAD6; Sat, 28 Feb 2026 17:34:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300091; cv=none; b=a5q8YWTRT/ICmtVZXYSikwazLaNdBxZIn/IfN+bAqrM9+L6BwYRTF7o0TRuGs6lSgckZV2iFKWwNyuMZhUTtKixrS/BcX5YAmJC7Ww76qZ6ZB1gLH4gHgXGtAH3gQuTpA267GcA4PEAo92VvnzmBV4hiLvsigxVPGNzUjuezAyA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300091; c=relaxed/simple; bh=dnKOTn7uV2wDaoLtoSPJID9JuTwR5i5ibtM0JG+68U8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tJnj5+KHEC6t0XVwqF7txNkGfBHUZNFMHqvVAa81B4jc1/28ojur0Y56FG7rsOO+c6vUVGXerdB+9E78NsRwdYKwf81mRzPb9rcSOxUiSeSHQftFWwVicJ6YU2DicYrwcNmkwgQVKkBLs5GMe5nO1E8MGM9HFf+OMfyHdNCZjOc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WT5vfDSY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WT5vfDSY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B04C7C2BC87; Sat, 28 Feb 2026 17:34:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300091; bh=dnKOTn7uV2wDaoLtoSPJID9JuTwR5i5ibtM0JG+68U8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WT5vfDSYkOH//HU1gFNJioiX+Xcou+blcrmAZQg22JsS2xEhs5z0NjSPfEEOHF0A9 /bzB1nPNUQ1+g/TQD7IbAG6vPwU50fURENpoAg12/JddHD4MsIwfoorAc7ET/44mr9 m9NJRzI0FOy7dE9Ubgu346p+IS0J+9GKJ11k+ySC/vYySWd0E6ukj1Ej71o0SiFU6m Z1evNlFmvh0LrxYJ9pIZ6uueXH9rKIXiyCHnPvf2Dm5DhCCK4xJhNzE5sr8brxA8Et UjEbEVap78as/yAdmooqOSYz2Tzd3UWxWcBEQQIJ05CE+/oFN/UlqDpKnjxT5rSWbi FB3O7+MbFOh9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Thomas Gleixner , Sasha Levin Subject: [PATCH 6.19 106/844] PCI/MSI: Unmap MSI-X region on error Date: Sat, 28 Feb 2026 12:20:19 -0500 Message-ID: <20260228173244.1509663-107-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202 ] msix_capability_init() fails to unmap the MSI-X region if msix_setup_interrupts() fails. Add the missing iounmap() for that error path. [ tglx: Massaged change log ] Signed-off-by: Haoxiang Li Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260125144452.2103812-1-lihaoxiang@isrc.isc= as.ac.cn Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/msi/msi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c index 34d664139f48f..e010ecd9f90dd 100644 --- a/drivers/pci/msi/msi.c +++ b/drivers/pci/msi/msi.c @@ -737,7 +737,7 @@ static int msix_capability_init(struct pci_dev *dev, st= ruct msix_entry *entries, =20 ret =3D msix_setup_interrupts(dev, entries, nvec, affd); if (ret) - goto out_disable; + goto out_unmap; =20 /* Disable INTX */ pci_intx_for_msi(dev, 0); @@ -758,6 +758,8 @@ static int msix_capability_init(struct pci_dev *dev, st= ruct msix_entry *entries, pcibios_free_irq(dev); return 0; =20 +out_unmap: + iounmap(dev->msix_base); out_disable: dev->msix_enabled =3D 0; pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL | PCI_MSIX_FLAGS_= ENABLE, 0); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86F134C0414; Sat, 28 Feb 2026 17:34:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300092; cv=none; b=Oq/ww5WaxpP8ZrU8xA+0stFiRNXGxSsXmgSJfPg9oGyRQUCmfb5icnZErLiyFXotZOyO1sdl1Cgbgpmidm1Qa/Y0m1aegL1OI/ZP6+FxErUl7QVCEtarTu6a2wkhwDzweAjRBwSG6Qx5BiA+xL3KJXpciFr6zBN9gnwybOhZMjg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300092; c=relaxed/simple; bh=5OS9MRJeSPsiwJmaYcDdz4TVLeyQSuvgfYTBYkHqbjs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ssYT1MMn8fyInCuJZRUwkFUKVPVOVwpFKBOzA+YTk2upI+pqC8krYIPsxtaPgVPXKXMG45JBXFF5q820QaDuryyC61kEJXq1DtbUZ7klP3ynpfGSPat8j5xIkamEgxVwq/fAiNkljho4ACfoZhpd5guWmGGaW8WD8gIOZkIq4D4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LgHiC//i; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LgHiC//i" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C7CAC116D0; Sat, 28 Feb 2026 17:34:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300092; bh=5OS9MRJeSPsiwJmaYcDdz4TVLeyQSuvgfYTBYkHqbjs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LgHiC//iYb3UsGI9nuGzvQCZ/F7vlwqKRlVvfWgJDPza9x9vulA/MNy3F9lqabmcj s2VN778zxhwLG1cJt2Xoq3HoEKzcvHMl/CdDHmy6NpEHmycU71qZy1U0QF4F8H2DD2 1/sxsZ7bLaOQm5tte2VVs4lDV4uzXK/aEJXOIVCFJ7kFjuzSsqqKmM2sMv5ivbJZE4 zvWeWofdjcx7HNa1AUn6BhwU2Id8VTEImK2hd9wyBtKKWDT4wkmFbCy0u/CjqO7PCQ 4jB3SI/7103X5h4Ej2VmTvmJHfBYB1FkSegfy4jaqnyvbabHxV47rx8rd6UUNQFzyf vlfqmdy/dJexA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ihor Solodrai , Andrii Nakryiko , Sasha Levin Subject: [PATCH 6.19 107/844] bpftool: Fix dependencies for static build Date: Sat, 28 Feb 2026 12:20:20 -0500 Message-ID: <20260228173244.1509663-108-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ihor Solodrai [ Upstream commit 08a7491843224f8b96518fbe70d9e48163046054 ] When building selftests/bpf with EXTRA_LDFLAGS=3D-static the follwoing error happens: LINK /ws/linux/tools/testing/selftests/bpf/tools/build/bpftool/bootstr= ap/bpftool /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-linux-gnu/15/../../..= /x86_64-linux-gnu/libcrypto.a(libcrypto-lib-dso_dlfcn.o): in function `dlfc= n_globallookup': [...] /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-linux-gnu/15/../../..= /x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_on= eshot_expand_block': (.text+0xc64): undefined reference to `uncompress' /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-linux-gnu/15/../../..= /x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_on= eshot_compress_block': (.text+0xce4): undefined reference to `compress' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:252: /ws/linux/tools/testing/selftests/bpf/tools/bui= ld/bpftool/bootstrap/bpftool] Error 1 make: *** [Makefile:327: /ws/linux/tools/testing/selftests/bpf/tools/sbin/b= pftool] Error 2 make: *** Waiting for unfinished jobs.... This is caused by wrong order of dependencies in the Makefile. Fix it. Signed-off-by: Ihor Solodrai Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260128211255.376933-1-ihor.solodrai@lin= ux.dev Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/bpf/bpftool/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile index 5442073a2e428..519ea5cb8ab1c 100644 --- a/tools/bpf/bpftool/Makefile +++ b/tools/bpf/bpftool/Makefile @@ -130,8 +130,8 @@ include $(FEATURES_DUMP) endif endif =20 -LIBS =3D $(LIBBPF) -lelf -lz -lcrypto -LIBS_BOOTSTRAP =3D $(LIBBPF_BOOTSTRAP) -lelf -lz -lcrypto +LIBS =3D $(LIBBPF) -lelf -lcrypto -lz +LIBS_BOOTSTRAP =3D $(LIBBPF_BOOTSTRAP) -lelf -lcrypto -lz =20 ifeq ($(feature-libelf-zstd),1) LIBS +=3D -lzstd --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DA904C042E; Sat, 28 Feb 2026 17:34:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300093; cv=none; b=E9hEiDsalss57+He3i7+xy1+MHKK+tQGnZsnWHEPDE/gV702FPOen7+PLncpP2bJ6hFo1gpriJqu7DC53nAGojWlOJwhCCh03puv9Pt0fyTRCQMk08y2alsCxNPL+IJxdAA7TXifQkdzk6SsiZEnhrlRPu89GT0Zyl8AEhQaHEs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300093; c=relaxed/simple; bh=Ix2tqAtDfLsARaykkaLnpch4kUaJMJ6GE7Rk6SrSrnc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qYGMAtYyzEji5PXpoCdU4WDl3F7RNovIXCaueQEmKR/GvfFkwd8G3JKCXD90023SpynJokv7mR5FqeHMNSIr7+HnQME2FemW77389pW3qcRwkHlnDn40uNyN+SbcKRlXeqQzwxqUOoi8ZrrGAWP11bHzPlN2Ws29qonB6VD3Yjw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hGAY53nJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hGAY53nJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6933BC19423; Sat, 28 Feb 2026 17:34:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300093; bh=Ix2tqAtDfLsARaykkaLnpch4kUaJMJ6GE7Rk6SrSrnc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hGAY53nJKJZ+plk62JEKoWdbtIjfpDcGkAwSl6+0uWj7UyncoRveT2iTZqUCn6zvc 8lBl+jvhgZ/TiO7Cr23dbURI+txD5WOrbEXEluDd6rhtUUbyeAEMgDlPkBqXU+xHcx IlzANQ26IGYgRBXBmUquaj6cFYAZbgzGgHa7pB8sh6StHl01efLgyJL8CwYjm9HRs+ ns+apv45jhYgYOSLbQHMG4IymqKBoxJ+3uwaqF+t2xJpNO3KNLDD3iPse/ZezikHXS mIYPcDkNs/N4JHkzZCPUXSpi+5pT0TtyFO1BCLFwaOCLSChddfU3mxHCInh41viBL/ EINJ0Q/X0WC9A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chenghai Huang , Herbert Xu , Sasha Levin Subject: [PATCH 6.19 108/844] crypto: hisilicon/qm - move the barrier before writing to the mailbox register Date: Sat, 28 Feb 2026 12:20:21 -0500 Message-ID: <20260228173244.1509663-109-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chenghai Huang [ Upstream commit ebf35d8f9368816c930f5d70783a72716fab5e19 ] Before sending the data via the mailbox to the hardware, to ensure that the data accessed by the hardware is the most up-to-date, a write barrier should be added before writing to the mailbox register. The current memory barrier is placed after writing to the register, the barrier order should be modified to be before writing to the register. Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/crypto/hisilicon/qm.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c index b8e59f99f7007..cf58d0d01b199 100644 --- a/drivers/crypto/hisilicon/qm.c +++ b/drivers/crypto/hisilicon/qm.c @@ -609,9 +609,13 @@ static void qm_mb_write(struct hisi_qm *qm, const void= *src) } =20 #if IS_ENABLED(CONFIG_ARM64) + /* + * The dmb oshst instruction ensures that the data in the + * mailbox is written before it is sent to the hardware. + */ asm volatile("ldp %0, %1, %3\n" - "stp %0, %1, %2\n" "dmb oshst\n" + "stp %0, %1, %2\n" : "=3D&r" (tmp0), "=3D&r" (tmp1), "+Q" (*((char __iomem *)fun_base)) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEFB44C6EE5; Sat, 28 Feb 2026 17:34:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300094; cv=none; b=Km98v7fG90sHWtWtjnvwvxlS0aFqQs08JK9DsGYFhXycYs+IaPIr92MbsvLTH+2ZwkhnE8LTMqVTm9ogvC/a7dMi9vo2rYpt4pvIY6XVxk99zCZa04x2msghZpNQ1+D76KkXPi+4oM0pKprgd95aVlCNqtgG4w9nHJ6/+muZsUU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300094; c=relaxed/simple; bh=qmhSjwrAXFUSiHBCb2qH3lHoG/iFuO65+VBFT9ezRaI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QNJr928OZxBP9V/8M4REfXYkNp9kxhC8Man8VYYXAqDfO5TcOZdNN/m2TESIYbosnDeVqlANsACj4NG9hzw8LlpS9RI6aB49MM1crBHnYfXVynq/YSP6XEcGv7iuBrNyYsIr9O/WccTuGxP7NmeWmsLJd3whmYNFCnBPPn7Z+q8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=shOwYhfM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="shOwYhfM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 444DEC116D0; Sat, 28 Feb 2026 17:34:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300093; bh=qmhSjwrAXFUSiHBCb2qH3lHoG/iFuO65+VBFT9ezRaI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=shOwYhfMsdInbH0TCgKHGRy6D4fZJBurHSspKO2bUNIcYQDQx4myijh2pejKHtDkT JNU99iseN9PUhhjMAN0O4SiTOasBysSAYV/tsuzY4L5zul7+7lvvDk839RNq+XzYuD +NFPPEgSusTTJj/QEsvhHBDFpvoumgh+bvrhxYJ8SdAjxK7Cwjaotf7ohmlpoB0mfa /8zJMbBHeKcPkattk5cLGJIJCLYz/VUcXs/9GaEMaOfHkc0OdqV4aMy8LQ9rYsUAet 4ozkt8nN+A40DWPP0mE3z+eAlevx1EA7HdiWCIE3VAIvJiIZlrJNZxMQVUoTGHGuVb vu5RvPLtDVEWA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sebastian Andrzej Siewior , Thomas Gleixner , Sasha Levin Subject: [PATCH 6.19 109/844] mailbox: bcm-ferxrm-mailbox: Use default primary handler Date: Sat, 28 Feb 2026 12:20:22 -0500 Message-ID: <20260228173244.1509663-110-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sebastian Andrzej Siewior [ Upstream commit 03843d95a4a4e0ba22ad4fcda65ccf21822b104c ] request_threaded_irq() is invoked with a primary and a secondary handler and no flags are passed. The primary handler is the same as irq_default_primary_handler() so there is no need to have an identical copy. The lack of the IRQF_ONESHOT flag can be dangerous because the interrupt source is not masked while the threaded handler is active. This means, especially on LEVEL typed interrupt lines, the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-5-bigeasy@linutronix.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mailbox/bcm-flexrm-mailbox.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c b/drivers/mailbox/bcm-fle= xrm-mailbox.c index 41f79e51d9e5a..4255fefc3a5a0 100644 --- a/drivers/mailbox/bcm-flexrm-mailbox.c +++ b/drivers/mailbox/bcm-flexrm-mailbox.c @@ -1173,14 +1173,6 @@ static int flexrm_debugfs_stats_show(struct seq_file= *file, void *offset) =20 /* =3D=3D=3D=3D=3D=3D FlexRM interrupt handler =3D=3D=3D=3D=3D */ =20 -static irqreturn_t flexrm_irq_event(int irq, void *dev_id) -{ - /* We only have MSI for completions so just wakeup IRQ thread */ - /* Ring related errors will be informed via completion descriptors */ - - return IRQ_WAKE_THREAD; -} - static irqreturn_t flexrm_irq_thread(int irq, void *dev_id) { flexrm_process_completions(dev_id); @@ -1271,10 +1263,8 @@ static int flexrm_startup(struct mbox_chan *chan) ret =3D -ENODEV; goto fail_free_cmpl_memory; } - ret =3D request_threaded_irq(ring->irq, - flexrm_irq_event, - flexrm_irq_thread, - 0, dev_name(ring->mbox->dev), ring); + ret =3D request_threaded_irq(ring->irq, NULL, flexrm_irq_thread, + IRQF_ONESHOT, dev_name(ring->mbox->dev), ring); if (ret) { dev_err(ring->mbox->dev, "failed to request ring%d IRQ\n", ring->num); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF0F14C6EFE; Sat, 28 Feb 2026 17:34:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300094; cv=none; b=KssFmOJE1I1+mLqSSS4uExPFW4eSnUTBph2zzNwfAlNeCJVMsS8xlRoqvowO6tpJ4OJLYWznxoXyfsUvhinyiuduJdX0E9F+cOS6fFggRh6wNciw/z6vTY8aBvvwZOBoGfJielhuPvOk7u4VHD/NfkVEM8lYO5uNYLxsC9YEA7Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300094; c=relaxed/simple; bh=qBb3984FcUVkn6ObiM6blPgcfp4SWEUhlMD4uB277ag=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VotNrJZqjr+zsio2P7dRfUErH8ClA8NkxbjXFytHcoKGcGK8hvJ67hX6mFUWiotlFcPhiYIKAiwLKR2YSGmZd9EqZkWiwVWZyGp5wn2ZJtvCMfZWpvZFhB77xNcj8c5GLG3Rm7FU17OiMJUueFDaaN70p7rGqBwqfrMB2cbmmFU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SzLjjhkT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SzLjjhkT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21C95C19425; Sat, 28 Feb 2026 17:34:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300094; bh=qBb3984FcUVkn6ObiM6blPgcfp4SWEUhlMD4uB277ag=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SzLjjhkTVIkurwRXqePBbIKwuU7JolT+rdxIRW9Ho4/DQQ/dPhRZjFh2RJlKnE4IU lnCuWOkFO/pyu2jURgHpEe3v/k3SHSoiGvP3EbPrlyIW+aqXjOozOm5M2NYrurXVGF iuNPiM6D34IKiGuZVk6QZFRL9ImFU9fLjFOlgvRFMTjk9VssHfdHzqquqJnxYIj2q1 VtkG8SCz+wXXCS9m8bcuDpH/GokyNfgBh3f3qwhTABf/3Msw7q9Wc+ZsEgcZgaaIsy Q8jYMB2Aj1QrwaqX6EHsCMbYetC87cwpJpd7e8bnmEIAqdnQMDIAq7KwI3QhRhRc+i JRVi8oW/ACI1w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sebastian Andrzej Siewior , Thomas Gleixner , Jarkko Sakkinen , Sasha Levin Subject: [PATCH 6.19 110/844] char: tpm: cr50: Remove IRQF_ONESHOT Date: Sat, 28 Feb 2026 12:20:23 -0500 Message-ID: <20260228173244.1509663-111-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sebastian Andrzej Siewior [ Upstream commit 1affd29ffbd50125a5492c6be1dbb1f04be18d4f ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Jarkko Sakkinen Link: https://patch.msgid.link/20260128095540.863589-10-bigeasy@linutronix.= de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/char/tpm/tpm_tis_i2c_cr50.c | 3 +-- drivers/char/tpm/tpm_tis_spi_cr50.c | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/char/tpm/tpm_tis_i2c_cr50.c b/drivers/char/tpm/tpm_tis= _i2c_cr50.c index fc6891a0b6936..b48cacacc0664 100644 --- a/drivers/char/tpm/tpm_tis_i2c_cr50.c +++ b/drivers/char/tpm/tpm_tis_i2c_cr50.c @@ -749,8 +749,7 @@ static int tpm_cr50_i2c_probe(struct i2c_client *client) =20 if (client->irq > 0) { rc =3D devm_request_irq(dev, client->irq, tpm_cr50_i2c_int_handler, - IRQF_TRIGGER_FALLING | IRQF_ONESHOT | - IRQF_NO_AUTOEN, + IRQF_TRIGGER_FALLING | IRQF_NO_AUTOEN, dev->driver->name, chip); if (rc < 0) { dev_err(dev, "Failed to probe IRQ %d\n", client->irq); diff --git a/drivers/char/tpm/tpm_tis_spi_cr50.c b/drivers/char/tpm/tpm_tis= _spi_cr50.c index f4937280e9406..32920b4cecfb4 100644 --- a/drivers/char/tpm/tpm_tis_spi_cr50.c +++ b/drivers/char/tpm/tpm_tis_spi_cr50.c @@ -287,7 +287,7 @@ int cr50_spi_probe(struct spi_device *spi) if (spi->irq > 0) { ret =3D devm_request_irq(&spi->dev, spi->irq, cr50_spi_irq_handler, - IRQF_TRIGGER_RISING | IRQF_ONESHOT, + IRQF_TRIGGER_RISING, "cr50_spi", cr50_phy); if (ret < 0) { if (ret =3D=3D -EPROBE_DEFER) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 262D04C77A4; Sat, 28 Feb 2026 17:34:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300096; cv=none; b=CeOMfPkxKqL2nXz/htS9+7FVPmmVcBCSbzKMHweVTkPlHEjBx7goS9ikeOVYazbTS0KplOG+iLZ+86kbq1XYqzGKOqzSjJEOlomWQFwVGtGLZoSkAdqQusZZ2ZK9jylM9dfT6pPeSgD2dmAYNkQsVY1MvkyUPm/B/QL+kigsRtQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300096; c=relaxed/simple; bh=j5xNUslQNcpWHSQ8UAeGt65hKPEGFjMUP9W6SWona0E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Og9RIjPfIvwtO6RLciUnvfit7853EUo4vboLfha4s3MyTPJHMwJnsLwohGY9wL7AhicPPrGaS+pE5VkTvN6Vn47N1BDm/J5gETSba1IaJpKRA7kP+k5+rGFiHFNKBQn2mr2JiMsM2/HhUuC5gpkp9fqwchdacJ4/55UDcpE+rwE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=prfp3rQy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="prfp3rQy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13E34C19424; Sat, 28 Feb 2026 17:34:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300096; bh=j5xNUslQNcpWHSQ8UAeGt65hKPEGFjMUP9W6SWona0E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=prfp3rQyWBg4CiVOeoBb57Bacl0RPu7pFpB9aK+B4OzVXNgoHPH9XfcIlq0kxfbx9 gP8C3ZwdhULXfwYr4NL4BKVJQ7cIqCNhD0Luiek96u0XevuSY+kTaFI+eFteMN8PAP XaNe73c7Di/sB6jme/L3fvRGjKLyeCBBrJ2N1wm2gbYaamMSuNs/KXU8TTcWmQy7H9 JqId5Obp07oL0QsLHCUuY8tg5gaFpNMLmUl59EAwRXZEp/9VC0ZEZaoV0hZLwaDwx0 mcLlp05aDVaCWPG1pmzDt8EbB2Et559stujr8yWh0V43RQZ+GXWOFvo2nD5vzDOYju 9AkCyynI9qB1Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Joel Fernandes , "Peter Zijlstra (Intel)" , Juri Lelli , Andrea Righi , Tejun Heo , Christian Loehle , Sasha Levin Subject: [PATCH 6.19 111/844] sched/debug: Fix updating of ppos on server write ops Date: Sat, 28 Feb 2026 12:20:24 -0500 Message-ID: <20260228173244.1509663-112-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Joel Fernandes [ Upstream commit 6080fb211672aec6ce8f2f5a2e0b4eae736f2027 ] Updating "ppos" on error conditions does not make much sense. The pattern is to return the error code directly without modifying the position, or modify the position on success and return the number of bytes written. Since on success, the return value of apply is 0, there is no point in modifying ppos either. Fix it by removing all this and just returning error code or number of bytes written on success. Signed-off-by: Joel Fernandes Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Reviewed-by: Andrea Righi Acked-by: Tejun Heo Tested-by: Christian Loehle Link: https://patch.msgid.link/20260126100050.3854740-3-arighi@nvidia.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/sched/debug.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c index 41caa22e0680a..93f009e1076d8 100644 --- a/kernel/sched/debug.c +++ b/kernel/sched/debug.c @@ -345,8 +345,8 @@ static ssize_t sched_fair_server_write(struct file *fil= p, const char __user *ubu long cpu =3D (long) ((struct seq_file *) filp->private_data)->private; struct rq *rq =3D cpu_rq(cpu); u64 runtime, period; + int retval =3D 0; size_t err; - int retval; u64 value; =20 err =3D kstrtoull_from_user(ubuf, cnt, 10, &value); @@ -380,8 +380,6 @@ static ssize_t sched_fair_server_write(struct file *fil= p, const char __user *ubu dl_server_stop(&rq->fair_server); =20 retval =3D dl_server_apply_params(&rq->fair_server, runtime, period, 0); - if (retval) - cnt =3D retval; =20 if (!runtime) printk_deferred("Fair server disabled in CPU %d, system may crash due t= o starvation.\n", @@ -389,6 +387,9 @@ static ssize_t sched_fair_server_write(struct file *fil= p, const char __user *ubu =20 if (rq->cfs.h_nr_queued) dl_server_start(&rq->fair_server); + + if (retval < 0) + return retval; } =20 *ppos +=3D cnt; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1275A4C77BE; Sat, 28 Feb 2026 17:34:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300097; cv=none; b=X/JdPryEgJEFmsE9Tdps9HOoyScEswzHISBzuKL5v14i7FUuLcZHClhNoDor4xPMK50nPhTcwx1zgfyl3BJG1YhV9J8G/6wAbrh91l1nYoq6ZR8mJAC884wWfKhgQjcgRTyJv5AceAaaXK25/iOnZLbF1FqvM3H6H+74nalXKxw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300097; c=relaxed/simple; bh=hqFVOjlF5+ZO2pilwS5gg2mQkEKBO5ayny0CHgbb+js=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U3divR2PaL7yrW5sc6i2PgAd9JO/LAjLvLOPBut8Z0WsiLRXlCyAYLm9GW5Hiow9iFN1KvJCjV6Qlug3A/5v5N3n+z64s5VuHWSkJ8jQel3tqpsYyFoyyDJIZ2/CHZzGqR00Z5z5joReV2I8ZKilb7zQd2Z9Tcpxjhjp9BAuBjs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NgYapZDR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NgYapZDR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4383CC19423; Sat, 28 Feb 2026 17:34:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300096; bh=hqFVOjlF5+ZO2pilwS5gg2mQkEKBO5ayny0CHgbb+js=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NgYapZDRUtiCOZt2p1TmMiGGviXg7kIQ1Qs6FsJ1PBJSgJBLLfgrX8JsNiYBd0lOW bHo/+pLSssyVtGJGiVMZnAoeNsGIpMl6NNPfHDd4JFbD56Ov1JJ7xtJTHbjH6MradI w+HjzvJS1U57fYBceEJoX4BerJn+1C1YFekc3quiCJf3b4Npo/+z6WlOumelnc4Oii fdAQkJYDlR8l/xQZzPlE3iJgFYS14ljujqiL99NU7kqVwSaXhThjCOAbZFAKZNOyo+ 1lqoJGenMBXiOaAqROkfG+A2lBaegTOHRpLB8IQGhxZ+JR4zLe4LorXidtG0m55OtN ALs5ZQm46fWeg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ruipeng Qi , Kees Cook , Sasha Levin Subject: [PATCH 6.19 112/844] pstore: ram_core: fix incorrect success return when vmap() fails Date: Sat, 28 Feb 2026 12:20:25 -0500 Message-ID: <20260228173244.1509663-113-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ruipeng Qi [ Upstream commit 05363abc7625cf18c96e67f50673cd07f11da5e9 ] In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures. Signed-off-by: Ruipeng Qi Link: https://patch.msgid.link/20260203020358.3315299-1-ruipengqi3@gmail.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/pstore/ram_core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c index c9eaacdec37e4..7b6d6378a3b87 100644 --- a/fs/pstore/ram_core.c +++ b/fs/pstore/ram_core.c @@ -457,6 +457,13 @@ static void *persistent_ram_vmap(phys_addr_t start, si= ze_t size, vaddr =3D vmap(pages, page_count, VM_MAP | VM_IOREMAP, prot); kfree(pages); =20 + /* + * vmap() may fail and return NULL. Do not add the offset in this + * case, otherwise a NULL mapping would appear successful. + */ + if (!vaddr) + return NULL; + /* * Since vmap() uses page granularity, we must add the offset * into the page here, to get the byte granularity address --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6AA14C77D0; Sat, 28 Feb 2026 17:34:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300097; cv=none; b=kMIlYXsOgvZhnIRRSpd+obPELXyIAVwbD6DvZiZtHFjqGiSAbrIcE/+kk+lgZWI/Nuv8XsKaGnsJC3YH25fo+R0QLawz+vEWWHSyWAgPdWFyEow5UeskTN+uTGKBpVoKYYWwoiKP9LeJxMVDPwfjd3Id4PYn6IdJSI6ZJTLqq8g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300097; c=relaxed/simple; bh=rbgw5izTleVxv+iMLaezDmiKBi4xS3WfjILjsEfjiqo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YTd79rfFA4+02+ZLrtoMvOAPcbG8hXNMcJSuDJ1yJVnaUJOZ+nsz+lF8kSDoukvMZocrIFDMcvvFr6/6r11COywJORAL8eu33DF8LQ5J9PZT+d+P5HXKQBWgpbe+uDUhGbwwBiYG8C7gvqtHBFQu9vnGfENZ0Ic2zaRWcpLSito= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gUSzzXcV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gUSzzXcV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22BB3C116D0; Sat, 28 Feb 2026 17:34:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300097; bh=rbgw5izTleVxv+iMLaezDmiKBi4xS3WfjILjsEfjiqo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gUSzzXcVStM3Qq45TTrEbolAO5lY8C6GP6yEmMk+19h6yq/LvSXNThr+lfQVsjaOX A7v4zVvuMnv+fSYZMTLxvAdO9z4RCMv19hEZ4Vd9vOUK10GV/j0zjkLJTPn+xVDBk5 vzRHjkESrLFPza49C0joVKmYE2REqLEu/5sWnBlnmYFgSLhJhV33yFMRhx39H1vBsD n20qwIKGBlCrM6OWCcUzWaoJPcTJx9C03W1bH4WiLLOn5VM5BzUIbWEtolZW+QtsWs q7hRjFj9M3vnIjqkRZMw9nE65H51OvwaJ62i29TSSZL2uxToHLcuJAfiii/Q+MF0ru rCF6KbKqAKWkQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Sudeep Holla , Sasha Levin Subject: [PATCH 6.19 113/844] firmware: arm_ffa: Unmap Rx/Tx buffers on init failure Date: Sat, 28 Feb 2026 12:20:26 -0500 Message-ID: <20260228173244.1509663-114-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit 9fda364cb78c8b9e1abe4029f877300c94655742 ] ffa_init() maps the Rx/Tx buffers via ffa_rxtx_map() but on the partition setup failure path it never unmaps them. Add the missing ffa_rxtx_unmap() call in the error path so that the Rx/Tx buffers are properly released before freeing the backing pages. Signed-off-by: Haoxiang Li Message-Id: <20251210031656.56194-1-lihaoxiang@isrc.iscas.ac.cn> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/firmware/arm_ffa/driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/d= river.c index c501c3104b3a4..11a702e7f641c 100644 --- a/drivers/firmware/arm_ffa/driver.c +++ b/drivers/firmware/arm_ffa/driver.c @@ -2093,6 +2093,7 @@ static int __init ffa_init(void) =20 pr_err("failed to setup partitions\n"); ffa_notifications_cleanup(); + ffa_rxtx_unmap(drv_info->vm_id); free_pages: if (drv_info->tx_buffer) free_pages_exact(drv_info->tx_buffer, rxtx_bufsz); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1C2E4C8FE7; Sat, 28 Feb 2026 17:34:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300098; cv=none; b=bSOaZa/70JuUy5yW8Ny6anf31A7tSyrgL4udmR9t1mIDNneysmrAsSMuGmtj9im4z3TGMdvvMM+GFv7UF5CUmlIeXO8oeg2SmJzbC4erUrjmzyPE4h2mFjYtjKWkF/kc47AuVNMKq628o6mD6sZzf26LDyS6deLMF5xlVhBpPRg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300098; c=relaxed/simple; bh=npRQ0tXYpgs62t84J3RGWsOTLTpkojqnwhv4hiqG08s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iHkDVTHRTxOLlnFD5nJHssUPlOnJG41Tq89l1cPSgHgzWj9g9aSRxfW/HFW70e4gI0IXw8BvnYElstiFE9ZHrnPNzYtjtJtVoOT4D71EN63THPjrVR73jG22Tej8l7J4tkwBPxMG24wf32oDuieutjXODWUvJAyeQ5o/1C2vhd0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=btfSCLA5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="btfSCLA5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF9DDC2BCAF; Sat, 28 Feb 2026 17:34:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300098; bh=npRQ0tXYpgs62t84J3RGWsOTLTpkojqnwhv4hiqG08s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=btfSCLA5z5gmWbIvTTfbWZ1Cjv6wl3OgviL5roAMkVZD/ubZX4BCIGr1q5eGkGmXb GuJBnUJYsc94cflkLGGJ0YkhXD3dNeEpRSxmV7LIVkDp6EiuuTYXsbHauBtwKPcrGA TmNjix+Hs5AK8v5JzVp8ubC7+7ZUQXx+KgxAPZP3lkH82XrsdZfCeTXsu7KzKx9dj5 KlECEUEjZZFHVxSfklIkG5kLd2cXkO3ZBqsJ5sK5gtrHYo1UKxcUrxMs1oZLjwyhDY gy5CTbifYDEDVsYHOpS4gkRPL9nMM5FgjqZXcvSK1KJji478SWeihB0PBgGUSbqHAw Xn1i6MszFa34g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tomas Melin , Michal Simek , Sasha Levin Subject: [PATCH 6.19 114/844] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree" Date: Sat, 28 Feb 2026 12:20:27 -0500 Message-ID: <20260228173244.1509663-115-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tomas Melin [ Upstream commit c197179990124f991fca220d97fac56779a02c6d ] This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe. OP-TEE logic in U-Boot automatically injects a reserved-memory node along with optee firmware node to kernel device tree. The injection logic is dependent on that there is no manually defined optee node. Having the node in zynqmp.dtsi effectively breaks OP-TEE's insertion of the reserved-memory node, causing memory access violations during runtime. Signed-off-by: Tomas Melin Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20251125-revert-zynqmp-optee-v1-1-d2ce4c0fc= af6@vaisala.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 5 ----- 1 file changed, 5 deletions(-) diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/x= ilinx/zynqmp.dtsi index 938b014ca9231..b55c6b2e8e0e1 100644 --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi @@ -192,11 +192,6 @@ psci { }; =20 firmware { - optee: optee { - compatible =3D "linaro,optee-tz"; - method =3D "smc"; - }; - zynqmp_firmware: zynqmp-firmware { compatible =3D "xlnx,zynqmp-firmware"; #power-domain-cells =3D <1>; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE0714C77DF; Sat, 28 Feb 2026 17:34:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300099; cv=none; b=VGxd4+/fLyHf7jU2OcZp6HfWvb8FklYyLBVzI2RVFMIk/14MNmFUGYg/IhiHsBMEufnJhNt8EIiIxqej/VePli+3n7QwLgECuonjH/xKP0mq8P8wkXJmjT1Rdpb5TNuUTtx8sVfzhh4dL/OA8GfYseVAcHkaVo1n+uAkd9LmC1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300099; c=relaxed/simple; bh=S5fQ+sckVXoHsbrEtarJTHKqAYCpXhdtcT3vfSIfn1w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TfEY3kp2OMtSYErjzNMtt6pwsrJXTcy0ftAPidz91lQLYWo7wQpor0HfkLvi2YjpjKftn7KmwVoRlqV8DkfAT68LOy+u2aPG8w8mdy8cKh6kIpUpym7mKIi1FeqsH0ti3h07QtmmRUSQb56+Um0igIPNHgCBdbGeOsUVKJ/u94o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ef2TWQx6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ef2TWQx6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA218C116D0; Sat, 28 Feb 2026 17:34:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300099; bh=S5fQ+sckVXoHsbrEtarJTHKqAYCpXhdtcT3vfSIfn1w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ef2TWQx63pHu7NwxEqp8AASz6qTmimYv9+18tyekFTO28KyNqAoxeX6nl2n3k/vHk eQRex0GFxzZYWzdHNCqUcJ3UjcDhiw/hC73gQcai44VfWTcL+quZe2Mb7A7ff0Hzzr s+e+0ZAn6PjUF1yg2FL2/5nYBVD5CcYyGTMiPHhLX05PUlVTImmZHuQlTwG9e4K/1b Ep75syQPPqLpgDKmuXwHCKCRKJSBIQToSeFJrp2XIVH2mzMHgVAs5UDBZeYc9jXfM0 +A0h0Fr4tH5wjxgNoTkd3p3zfmn4KCDQ9QcuUz1tBmtvVO8uu867WCDo6TlqZD/bI+ fpYYJ+Nvyujmg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lili Li , Tony Luck , Qiuxu Zhuo , Sasha Levin Subject: [PATCH 6.19 115/844] EDAC/igen6: Add more Intel Panther Lake-H SoCs support Date: Sat, 28 Feb 2026 12:20:28 -0500 Message-ID: <20260228173244.1509663-116-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lili Li [ Upstream commit 4c36e6106997b6ad8f4a279b4bdbca3ed6f53c6c ] Add more Intel Panther Lake-H SoC compute die IDs for EDAC support. Signed-off-by: Lili Li Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Link: https://patch.msgid.link/20251124131537.3633983-1-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/edac/igen6_edac.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/edac/igen6_edac.c b/drivers/edac/igen6_edac.c index 553c31a2d9226..839b6dd3629e9 100644 --- a/drivers/edac/igen6_edac.c +++ b/drivers/edac/igen6_edac.c @@ -274,6 +274,16 @@ static struct work_struct ecclog_work; #define DID_PTL_H_SKU1 0xb000 #define DID_PTL_H_SKU2 0xb001 #define DID_PTL_H_SKU3 0xb002 +#define DID_PTL_H_SKU4 0xb003 +#define DID_PTL_H_SKU5 0xb004 +#define DID_PTL_H_SKU6 0xb005 +#define DID_PTL_H_SKU7 0xb008 +#define DID_PTL_H_SKU8 0xb011 +#define DID_PTL_H_SKU9 0xb014 +#define DID_PTL_H_SKU10 0xb015 +#define DID_PTL_H_SKU11 0xb028 +#define DID_PTL_H_SKU12 0xb029 +#define DID_PTL_H_SKU13 0xb02a =20 /* Compute die IDs for Wildcat Lake with IBECC */ #define DID_WCL_SKU1 0xfd00 @@ -636,6 +646,16 @@ static struct pci_device_id igen6_pci_tbl[] =3D { { PCI_VDEVICE(INTEL, DID_PTL_H_SKU1), (kernel_ulong_t)&mtl_p_cfg }, { PCI_VDEVICE(INTEL, DID_PTL_H_SKU2), (kernel_ulong_t)&mtl_p_cfg }, { PCI_VDEVICE(INTEL, DID_PTL_H_SKU3), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU4), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU5), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU6), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU7), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU8), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU9), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU10), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU11), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU12), (kernel_ulong_t)&mtl_p_cfg }, + { PCI_VDEVICE(INTEL, DID_PTL_H_SKU13), (kernel_ulong_t)&mtl_p_cfg }, { PCI_VDEVICE(INTEL, DID_WCL_SKU1), (kernel_ulong_t)&wcl_cfg }, { }, }; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 866114C901C; Sat, 28 Feb 2026 17:35:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300100; cv=none; b=pDXsXmxW4CWJkY5KqSY9dk1S9gGH4Hpa2Yl64GrlnWZxZjQ2GSq1I5fCCqGbf6qpSi4rrkUO91C4NgVIKH5GBR8qbTyZu5dDyY13FmbwuVDCUhUlYCPt3kR6/6eFFhSck92YyjierI0WDjc9gqi4MWE3JwZ56uAgXphX9q7SIiU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300100; c=relaxed/simple; bh=KZzFRZBpSG0W8DPwDPhrbD6AABynbOqamuy0NSCIbNM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GOFivm07uudhcNOFExcIcV5Hd8qLzypNldSe0Tzf3bInP0sa9AA5Ai8lO/bZBKl0yq5Ku3Srii8U/zaT4k9RICDZsMzw5GxYyUjnv6VXmPbWMDhIuynWFARymBgbwYpKojs2AXCAtsovVxpc1c3z7QwQa8rlUno6+VPDfnS7pKo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CT1jYF21; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CT1jYF21" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B77DDC19423; Sat, 28 Feb 2026 17:34:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300100; bh=KZzFRZBpSG0W8DPwDPhrbD6AABynbOqamuy0NSCIbNM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CT1jYF21wUKv7wik9IrscruDF2xaecEU+kp/vmcn4TpsqvaC750pGXZ/jTPneQDrK cOJoaktG4CsNWJCdl/czbV7e1ak4GxipRIrMSGOossjPNzRCq7vEFquP/IjyqXf2GZ mQW4DwclLHEqiLNAGHCvV7e7q9MUqZa47U+gNmtbLKQRyMIGAnjktXKIZ2vq8C8LJN FaK/H75e/tKtJ+ZTbq0T8Rcty98qOMsYn6/+Gep0G2EAS7uCqhcvvJSsbQ4G7MeItV XeP/mukWCOd/24eQmm55/hQFfiE3mqe/0157N0tulVdD12mb28nSjr58qB3p55SVN9 q3wFQxAdxDeIA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Qiuxu Zhuo , Tony Luck , Jianfeng Gao , Sasha Levin Subject: [PATCH 6.19 116/844] EDAC/igen6: Add two Intel Amston Lake SoCs support Date: Sat, 28 Feb 2026 12:20:29 -0500 Message-ID: <20260228173244.1509663-117-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Qiuxu Zhuo [ Upstream commit 41ca2155d62b0b0d217f59e1bce18362d0c2446f ] Intel Amston Lake SoCs with IBECC (In-Band ECC) capability share the same IBECC registers as Alder Lake-N SoCs. Add two new compute die IDs for Amston Lake SoC products to enable EDAC support. Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Jianfeng Gao Link: https://patch.msgid.link/20251124065457.3630949-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/edac/igen6_edac.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/edac/igen6_edac.c b/drivers/edac/igen6_edac.c index 839b6dd3629e9..f2c9270c1893c 100644 --- a/drivers/edac/igen6_edac.c +++ b/drivers/edac/igen6_edac.c @@ -246,6 +246,8 @@ static struct work_struct ecclog_work; =20 /* Compute did IDs for Amston Lake with IBECC */ #define DID_ASL_SKU1 0x464a +#define DID_ASL_SKU2 0x4646 +#define DID_ASL_SKU3 0x4652 =20 /* Compute die IDs for Raptor Lake-P with IBECC */ #define DID_RPL_P_SKU1 0xa706 @@ -628,6 +630,8 @@ static struct pci_device_id igen6_pci_tbl[] =3D { { PCI_VDEVICE(INTEL, DID_ADL_N_SKU12), (kernel_ulong_t)&adl_n_cfg }, { PCI_VDEVICE(INTEL, DID_AZB_SKU1), (kernel_ulong_t)&adl_n_cfg }, { PCI_VDEVICE(INTEL, DID_ASL_SKU1), (kernel_ulong_t)&adl_n_cfg }, + { PCI_VDEVICE(INTEL, DID_ASL_SKU2), (kernel_ulong_t)&adl_n_cfg }, + { PCI_VDEVICE(INTEL, DID_ASL_SKU3), (kernel_ulong_t)&adl_n_cfg }, { PCI_VDEVICE(INTEL, DID_RPL_P_SKU1), (kernel_ulong_t)&rpl_p_cfg }, { PCI_VDEVICE(INTEL, DID_RPL_P_SKU2), (kernel_ulong_t)&rpl_p_cfg }, { PCI_VDEVICE(INTEL, DID_RPL_P_SKU3), (kernel_ulong_t)&rpl_p_cfg }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5AADB4C8FE7; Sat, 28 Feb 2026 17:35:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300101; cv=none; b=JRKjtNUXQmIVSF2ATr06NAvMvkTaJxs36zklt98dWLV/v+P1sWaQbeOJDXCxGdtiy4SGi+hho1MRNIgSYvL1qnL+R99A6Jy1iViXsTubZoOENZ8UoFvUjowanLaExZG8ihkZ6WGd0H3NMkyF+t/6e95snxKm5PwVJ4L00cvkzmM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300101; c=relaxed/simple; bh=yImonkXw0LmD3jgTI0jyV1ufEXShaTFRfPts7soQ5OY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=imWmUOc+Zewhn/2qe8eNG5yXNvTduvufK/rRZeZ5tykIwrCnEfJ9Oxjh97prs4BLPu4BIDZZwnmAfLx6fts5pDdQj1Oo/2uJLqzLorLjt5lc4QtdVfA1Kg0RdTXU/iTsq8lVNz+0EPMrK1WfPedaEwiS+j4SDjYn+QMeyEcs7U4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Guw5q+i+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Guw5q+i+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6FFBC116D0; Sat, 28 Feb 2026 17:35:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300101; bh=yImonkXw0LmD3jgTI0jyV1ufEXShaTFRfPts7soQ5OY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Guw5q+i+gtm7rdiP6oRlifIMNBndOlpUByBe4VRlJDbLdyrEiyG260Rjn7zuu+hee Q4Bom8XN8FYs7UmaY10Iy/SYFmqm/xGCymrouHLF9lcTNqtPpiUoSyBmN2un4jzCuF FWM2rQ9mMyTCuWTF0xGMu6RhAsFH7Nf+h8BQuDNqD5KnSNyY1EbL8oxuHqmH6aO7BL IuupH1ReOMsfcsGaX8z5iKMWKjUBwK4MqQS+HD0ix++Sq6WMUqPrygPY+gHVv00kZD 8yAb72PxvALr6pvNIHMnVhK/3yp6/+1pnRKEnSxbDn81cqhrLrXf1PGRgavhPpg7mR ibzKnUy6sx/dA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Diogo Ivo , Thierry Reding , Sasha Levin Subject: [PATCH 6.19 117/844] arm64: tegra: smaug: Add usb-role-switch support Date: Sat, 28 Feb 2026 12:20:30 -0500 Message-ID: <20260228173244.1509663-118-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Diogo Ivo [ Upstream commit dfa93788dd8b2f9c59adf45ecf592082b1847b7b ] The USB2 port on Smaug is configured for OTG operation but lacked the required 'usb-role-switch' property, leading to a failed probe and a non-functioning USB port. Add the property along with setting the default role to host. Signed-off-by: Diogo Ivo Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts b/arch/arm64/boo= t/dts/nvidia/tegra210-smaug.dts index 5aa6afd56cbc6..dfbd1c72388c1 100644 --- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts +++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts @@ -1809,6 +1809,8 @@ usb2-0 { status =3D "okay"; vbus-supply =3D <&usbc_vbus>; mode =3D "otg"; + usb-role-switch; + role-switch-default-mode =3D "host"; }; =20 usb3-0 { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CECF24C9577; Sat, 28 Feb 2026 17:35:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300102; cv=none; b=LSt/Qc1W2sTZ7Fyt1SdrIJvJBvNfwh0Q7NIni9ywX1v6Fjmp/rycsxWY8yPcZUFJSbQ25KwqVIi6VzCT0HzuGWWyy5+Qo6jjPXxliDYCjbXKF0bb743BUoCxKRe4C5/rhinhUJN/iesAcovgJ7JIkFvITM/kQq8CG7Aa8RbblDc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300102; c=relaxed/simple; bh=uZiaFSzPj05fK+Caj/goHYRSBC6v9HZFf3WZoHgNqrU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PVeTqCV/HS7/x7YX5i4Xbu2PAV4BxIi8oMtBfvw0B6PS4XIDbx9oNXrjxYkAU4B5+909efulgp4fkCvzi97wWO4ZjwrGuNWcfiRlqba+qk0CTJD15rFhFOgGW8k5I495f3jNydFUL/GSCxM3C6oBcyN7F5LOA1YizrJ3zCzlHrM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NH96b393; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NH96b393" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80168C2BC87; Sat, 28 Feb 2026 17:35:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300102; bh=uZiaFSzPj05fK+Caj/goHYRSBC6v9HZFf3WZoHgNqrU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NH96b393xCqy+49/IWoO0ROc41LF9oUtnAGxBkMIylxqHbwForToPWleiG+A444tZ qliyPXZVnsQVP6AmpZPr0/K5EXCSeSmgsfnnywAIbOISr1OHVuPeyKq/J+8ppfBXo6 cW3OODVb3CxkFC+hiIZgUgDwgEnEPdOrCIsUrjqdYIq3TauHWi4frfs+9DbV8gg0ac w2/eDeHygKesYakAnNYYyOOnsLvLyLchbbF5ZfKxLfSOIfX2BAjZpRlUZWBnMg+69Q 5piDlTgSp5bjBqpkyBk+Lff5kwxq2+tfXW+GCHQVemZ4rzOgx7iJii0RSDdCBQkY6D kaeMDo3FqxiNA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peng Fan , kernel test robot , Dan Carpenter , Marco Felsch , Daniel Baluta , Shawn Guo , Sasha Levin Subject: [PATCH 6.19 118/844] soc: imx8m: Fix error handling for clk_prepare_enable() Date: Sat, 28 Feb 2026 12:20:31 -0500 Message-ID: <20260228173244.1509663-119-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peng Fan [ Upstream commit f6ef3d9ff81240e9bcc030f2da132eb0f8a761d7 ] imx8m_soc_prepare() directly returns the result of clk_prepare_enable(), which skips proper cleanup if the clock enable fails. Check the return value of clk_prepare_enable() and release resources if failure. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202601111406.ZVV3YaiU-lkp@intel.com/ Signed-off-by: Peng Fan Reviewed-by: Marco Felsch Reviewed-by: Daniel Baluta Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/soc/imx/soc-imx8m.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c index 04a1b60f2f2b5..8e2322999f099 100644 --- a/drivers/soc/imx/soc-imx8m.c +++ b/drivers/soc/imx/soc-imx8m.c @@ -148,7 +148,11 @@ static int imx8m_soc_prepare(struct platform_device *p= dev, const char *ocotp_com goto err_clk; } =20 - return clk_prepare_enable(drvdata->clk); + ret =3D clk_prepare_enable(drvdata->clk); + if (ret) + goto err_clk; + + return 0; =20 err_clk: iounmap(drvdata->ocotp_base); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C4DD84CA26C; Sat, 28 Feb 2026 17:35:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300103; cv=none; b=R8lqTqqjemAd3gwi0FQlxu2+PbRumx3Gv5k1RmfZXSJXiALuOjV4eBExgfhdg3xxOjB4ZmEmaENNhzGzGpUwWamOIL6v9IXkvU3S8cBRWg7HsMT3DN+KnHUsxDFK4RtqIZw7oGZ9rBDmFo4twI0Lo71l9ZRgEDclG/lykxo4GT4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300103; c=relaxed/simple; bh=dvot2Tw321UuMNMxBvyf4qtctaikUI3kLXxgzVKFsSs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lpHb0TknkezWjA7KAhpO6HEAWhMowjhKDdv5gmgyY7/8aeJX4JqoMD5KASuhtJ315hbwXHw0Jot/tgtgkmW4uLdvo9zUzBEaOT03xoB+X0swlbNPxZ3+aK6W0f0BcXOG7mFLRLQ0PdkizYvh2tNrc3lqaGnPxBm5k+0vdHzm0DA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z6EXlkrS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z6EXlkrS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B191DC19423; Sat, 28 Feb 2026 17:35:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300103; bh=dvot2Tw321UuMNMxBvyf4qtctaikUI3kLXxgzVKFsSs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z6EXlkrSuRu90vCVmRAw75wSxNo65c7G1UyvBw85Kpr6Iaj+1k1FRa0XxaAlGuqmS mnLcjfXb+p33pjG5AiT/3JrXu2F0fkl3r/1KX33DGgTHhPV3IJcufm5P6MbT5fGH/+ A+MqfU72kbKWQ4GHuoFNVm3mGgUowOtp4eL3EzBRBJrzdfaIDwNgrFEESMlm/dHqWi nd+DZqiJGFD2xbLhxTU/butwWOlUh7jOXJqg3dQ0w4Z0xh/cpgsmKeb+Pf1gxX2kYB 2MeJQrvxDqaoLXo6958XYp5J2tLbyKHeA1N3DvAHkbZlEqaw7rv6jutG70wyWTRvzl xgrCRxiq8hzDw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Prathamesh Shete , Petlozu Pravareshwar , Jon Hunter , Thierry Reding , Sasha Levin Subject: [PATCH 6.19 119/844] soc/tegra: pmc: Fix unsafe generic_handle_irq() call Date: Sat, 28 Feb 2026 12:20:32 -0500 Message-ID: <20260228173244.1509663-120-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Prathamesh Shete [ Upstream commit e6d96073af681780820c94079b978474a8a44413 ] Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. Signed-off-by: Petlozu Pravareshwar Signed-off-by: Prathamesh Shete Reviewed-by: Jon Hunter Tested-by: Jon Hunter [treding@nvidia.com: miscellaneous cleanups] Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/soc/tegra/pmc.c | 104 ++++++++++++++++++++++++++++------------ 1 file changed, 74 insertions(+), 30 deletions(-) diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c index f3760a3b3026d..407fa840814c3 100644 --- a/drivers/soc/tegra/pmc.c +++ b/drivers/soc/tegra/pmc.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -468,6 +469,10 @@ struct tegra_pmc { unsigned long *wake_sw_status_map; unsigned long *wake_cntrl_level_map; struct syscore syscore; + + /* Pending wake IRQ processing */ + struct irq_work wake_work; + u32 *wake_status; }; =20 static struct tegra_pmc *pmc =3D &(struct tegra_pmc) { @@ -1905,6 +1910,50 @@ static int tegra_pmc_parse_dt(struct tegra_pmc *pmc,= struct device_node *np) return 0; } =20 +/* translate sc7 wake sources back into IRQs to catch edge triggered wakeu= ps */ +static void tegra186_pmc_wake_handler(struct irq_work *work) +{ + struct tegra_pmc *pmc =3D container_of(work, struct tegra_pmc, wake_work); + unsigned int i, wake; + + for (i =3D 0; i < pmc->soc->max_wake_vectors; i++) { + unsigned long status =3D pmc->wake_status[i]; + + for_each_set_bit(wake, &status, 32) { + irq_hw_number_t hwirq =3D wake + (i * 32); + struct irq_desc *desc; + unsigned int irq; + + irq =3D irq_find_mapping(pmc->domain, hwirq); + if (!irq) { + dev_warn(pmc->dev, + "No IRQ found for WAKE#%lu!\n", + hwirq); + continue; + } + + dev_dbg(pmc->dev, + "Resume caused by WAKE#%lu mapped to IRQ#%u\n", + hwirq, irq); + + desc =3D irq_to_desc(irq); + if (!desc) { + dev_warn(pmc->dev, + "No descriptor found for IRQ#%u\n", + irq); + continue; + } + + if (!desc->action || !desc->action->name) + continue; + + generic_handle_irq(irq); + } + + pmc->wake_status[i] =3D 0; + } +} + static int tegra_pmc_init(struct tegra_pmc *pmc) { if (pmc->soc->max_wake_events > 0) { @@ -1923,6 +1972,18 @@ static int tegra_pmc_init(struct tegra_pmc *pmc) pmc->wake_cntrl_level_map =3D bitmap_zalloc(pmc->soc->max_wake_events, G= FP_KERNEL); if (!pmc->wake_cntrl_level_map) return -ENOMEM; + + pmc->wake_status =3D kcalloc(pmc->soc->max_wake_vectors, sizeof(u32), GF= P_KERNEL); + if (!pmc->wake_status) + return -ENOMEM; + + /* + * Initialize IRQ work for processing wake IRQs. Must use + * HARD_IRQ variant to run in hard IRQ context on PREEMPT_RT + * because we call generic_handle_irq() which requires hard + * IRQ context. + */ + pmc->wake_work =3D IRQ_WORK_INIT_HARD(tegra186_pmc_wake_handler); } =20 if (pmc->soc->init) @@ -3129,47 +3190,30 @@ static void wke_clear_wake_status(struct tegra_pmc = *pmc) } } =20 -/* translate sc7 wake sources back into IRQs to catch edge triggered wakeu= ps */ -static void tegra186_pmc_process_wake_events(struct tegra_pmc *pmc, unsign= ed int index, - unsigned long status) -{ - unsigned int wake; - - dev_dbg(pmc->dev, "Wake[%d:%d] status=3D%#lx\n", (index * 32) + 31, inde= x * 32, status); - - for_each_set_bit(wake, &status, 32) { - irq_hw_number_t hwirq =3D wake + 32 * index; - struct irq_desc *desc; - unsigned int irq; - - irq =3D irq_find_mapping(pmc->domain, hwirq); - - desc =3D irq_to_desc(irq); - if (!desc || !desc->action || !desc->action->name) { - dev_dbg(pmc->dev, "Resume caused by WAKE%ld, IRQ %d\n", hwirq, irq); - continue; - } - - dev_dbg(pmc->dev, "Resume caused by WAKE%ld, %s\n", hwirq, desc->action-= >name); - generic_handle_irq(irq); - } -} - static void tegra186_pmc_wake_syscore_resume(void *data) { - u32 status, mask; unsigned int i; + u32 mask; =20 for (i =3D 0; i < pmc->soc->max_wake_vectors; i++) { mask =3D readl(pmc->wake + WAKE_AOWAKE_TIER2_ROUTING(i)); - status =3D readl(pmc->wake + WAKE_AOWAKE_STATUS_R(i)) & mask; - - tegra186_pmc_process_wake_events(pmc, i, status); + pmc->wake_status[i] =3D readl(pmc->wake + WAKE_AOWAKE_STATUS_R(i)) & mas= k; } + + /* Schedule IRQ work to process wake IRQs (if any) */ + irq_work_queue(&pmc->wake_work); } =20 static int tegra186_pmc_wake_syscore_suspend(void *data) { + unsigned int i; + + /* Check if there are unhandled wake IRQs */ + for (i =3D 0; i < pmc->soc->max_wake_vectors; i++) + if (pmc->wake_status[i]) + dev_warn(pmc->dev, + "Unhandled wake IRQs pending vector[%u]: 0x%x\n", + i, pmc->wake_status[i]); wke_read_sw_wake_status(pmc); =20 /* flip the wakeup trigger for dual-edge triggered pads --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 935F34CA27C; Sat, 28 Feb 2026 17:35:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300104; cv=none; b=DWeWbiT0cbSHW2tqpZ1bzolfVOfKyUAve7CkHIOkLijgacJMLrLOO1nH/8oChRp14nOfmWs8XXpjrYfhwKtnPgsYYfCRF78gjqHENb5Aao0P+tSXb3nOtsmh9dFbXhtFpvmVeiRUt1ae+MZJEFfncaS5q59+KNc0iVUuQoeGrI4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300104; c=relaxed/simple; bh=xaIgGtio2hQ3S0ThiGuPtYQV1KuDGEDcRMPFl0mXZ0o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RWqJmkAfFPZ4RVBOhAsWDGWAgMxKQZZMO9s3VuMKeji+IcOACRpTeU2l4ufDMkoUVCp8LiMVKVkDLCUORjTnPOOpwBx5hhisK013M3dlFNzjn0msWq7mhkDAeH88VWbLEdMvRPRrenpfcF8HBaRfI+3fIYDJ299Sj3GLwwM3eqk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fADaQdch; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fADaQdch" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7D76C19424; Sat, 28 Feb 2026 17:35:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300104; bh=xaIgGtio2hQ3S0ThiGuPtYQV1KuDGEDcRMPFl0mXZ0o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fADaQdch841eACSrppRDy049WI5w7SujVVmdgoJkI908v5jbO1wM10czymyUCfnT3 JBOLAcjHQh0DVHrG9oJ4xYVqjfDPFBHwQYOxwJh3qMZCRR/D6QtACkugTSdizmCzAo zGY0QRW5s1DfyCvBBLkkkaAo1peHs1K/7jN1VPZy7e2QjyhSvFuTqGUxjzHG6BvFnR 7EM6k++qQF7dIbnktEGAwq034Br4xFu/hO6Kzds6yK0fgKOS/K1LvH1W7utFxPJe8x PWAQDxP3kkZykqf5Aeq4hUj7vBWMunxS4VbckCkwa9v9Q3JtDMnVzaj+p3LMQ+lpm9 2u947hU3YOV6A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Borislav Petkov (AMD)" , kernel test robot , Julia Lawall , Tom Lendacky , Sasha Levin Subject: [PATCH 6.19 120/844] x86/sev: Use kfree_sensitive() when freeing a SNP message descriptor Date: Sat, 28 Feb 2026 12:20:33 -0500 Message-ID: <20260228173244.1509663-121-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Borislav Petkov (AMD)" [ Upstream commit af05e558988ed004a20fc4de7d0f80cfbba663f0 ] Use the proper helper instead of an open-coded variant. Closes: https://lore.kernel.org/r/202512202235.WHPQkLZu-lkp@intel.com Reported-by: kernel test robot Reported-by: Julia Lawall Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Link: https://patch.msgid.link/20260112114147.GBaWTd-8HSy_Xp4S3X@fat_crate.= local Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/coco/sev/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c index 9ae3b11754e65..c8ddb9febe3d9 100644 --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -2008,8 +2008,7 @@ void snp_msg_free(struct snp_msg_desc *mdesc) free_shared_pages(mdesc->request, sizeof(struct snp_guest_msg)); iounmap((__force void __iomem *)mdesc->secrets); =20 - memset(mdesc, 0, sizeof(*mdesc)); - kfree(mdesc); + kfree_sensitive(mdesc); } EXPORT_SYMBOL_GPL(snp_msg_free); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E5F04CA296; Sat, 28 Feb 2026 17:35:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300105; cv=none; b=fYSiEn9lA9hlmraCeoji1uNEjHF+5QfiWLGGYkvKEw41lisQhqQkyT/NJDRiMF7WFwZBtRUVnMPBEcimjiCEYvs6RLplzlxrc1n6rlpbw1UDG+k4sTV4lp+nDvJVCqNIgyB8cW05OzwUR6Y/ZB+QPK69nkRVydvMaQIU8Ruz0Cs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300105; c=relaxed/simple; bh=GiSdY7QWPuOmRrO/Wej4YIsbBGCxiqtbm54OJsH3IzQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YOCY0bZ+aRsR5rtZXMDWhFNU91zhEDstTbAdevF4CixiVBDHp46jWdCG7H3nYTk+wXpdiDDN+RrVEff2VoJaw4yJPm05nc2lFn7nOs1rR/LScmvy0ajALMqXaMwsMd9WXSUsNN7C2Y0yNFvzZgWxwfgzpQFlbVhecG7k4+n4hgc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s0s13dw6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s0s13dw6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD23DC19423; Sat, 28 Feb 2026 17:35:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300105; bh=GiSdY7QWPuOmRrO/Wej4YIsbBGCxiqtbm54OJsH3IzQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s0s13dw6LihjVPsSX1fMw7E10Puax+PKU5yLHHPSUYVhCwWj385AabM80Z1XJlq86 8ONc/ejjZUKWufbWs8TGNsSr0wcyrfYz8IkG6uo8UnvpOQUG42gP2JaDtj5Q7ETqXe GoW9p/dWW61K78mAscNYW0L6TJBUGLp3akE9y/4isiJEylYyu+SNKP5uD4xF01kVGt OX9Z7Dgji2l2d3gaFnGilh791l1HBUYCWNqu5jUis9x4sWDA5qpCI/oOQDQIeGu+3r PVqR2eFkFtiWWxVwGd4t8L+Uo8w6wu/gpORuAgsG2uvBYkmt55ZnuD9RlZhlEb+a5m WixSDJf2BOHsg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Helge Deller , Sasha Levin Subject: [PATCH 6.19 121/844] parisc: Prevent interrupts during reboot Date: Sat, 28 Feb 2026 12:20:34 -0500 Message-ID: <20260228173244.1509663-122-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Helge Deller [ Upstream commit 35ac5a728c878594f2ea6c43b57652a16be3c968 ] Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/parisc/kernel/process.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c index e64ab5d2a40d6..703644e5bfc4a 100644 --- a/arch/parisc/kernel/process.c +++ b/arch/parisc/kernel/process.c @@ -85,6 +85,9 @@ void machine_restart(char *cmd) #endif /* set up a new led state on systems shipped with a LED State panel */ pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN); + + /* prevent interrupts during reboot */ + set_eiem(0); =09 /* "Normal" system reset */ pdc_do_reset(); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E4244D2ECB; Sat, 28 Feb 2026 17:35:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300106; cv=none; b=fJj3G89dqIa2MG0lGmc0bg6g3Q42zgTboPys3n1IKj+OBeBZvA3scHSL/SvthNKRzYClheayvYTJZMGO5r4FRGNBkxoNMO4fQqkmJltMZaEXL1F0/q034j29VoqOT/9mSRU2iMQizVlxmptkpZZ2AAg5tYLHA/hb27S+C8egM2s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300106; c=relaxed/simple; bh=Mt4jFdGJyq8egqIKlvbkD1pcSAEmCL3DQ1jiF/WWx/I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kbSO7wXtvWEeLxt6n6zYotGe79vWps2jC7PTeWPOOOQlEa17dmZA0wJ6CjWoWNDd4HuLSfDJh0YqRe/m6AvjVokvY+iCwVuKHMycZvroaya3xFORQMu3s99BqkEiSbFBduX+NOcVHkmmt3eoQaLlpzwN6mmGTpgldoGe5s9nScY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pY6uR1/O; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pY6uR1/O" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B6FBC116D0; Sat, 28 Feb 2026 17:35:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300106; bh=Mt4jFdGJyq8egqIKlvbkD1pcSAEmCL3DQ1jiF/WWx/I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pY6uR1/O+6GQ/bc06OQu84gca9yAWUSXkj3v/0HuWAhYhZ+KztRQ8S9Mbkoy93O0v 8NGFClWS9ntL4HHI/pb9iTGBlz3au7WPMMPdd7J6bUZN6A631y+doQ4tGJl9XJhuX6 14Kj7HOTx22gsh/h5FRbOZ4xQ2APZ8D6PtTzP4zOEVsV68C/dv7gc7rBBpDGXhxqtD YEPp/wRtDbSXXgQ7huPb/67X6vHgaTJI8H+wJOBVDKBFbj1HYJN8Vj241GYcp2URWQ VVnegc9cSojqc5TLA97pkHnAeqnfO38fnnEVolHIfs5SrseGeDnvIPjTxITp5VjySr DTWVcmF+TW9gw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Matt Roper , Gustavo Sousa , Sasha Levin Subject: [PATCH 6.19 122/844] drm/xe/ggtt: Use scope-based runtime pm Date: Sat, 28 Feb 2026 12:20:35 -0500 Message-ID: <20260228173244.1509663-123-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Matt Roper [ Upstream commit 8a579f4b2476fd1df07e2bca9fedc82a39a56a65 ] Switch the GGTT code to scope-based runtime PM for consistency with other parts of the driver. Reviewed-by: Gustavo Sousa Link: https://patch.msgid.link/20251118164338.3572146-51-matthew.d.roper@in= tel.com Signed-off-by: Matt Roper Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/xe/xe_ggtt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_ggtt.c b/drivers/gpu/drm/xe/xe_ggtt.c index 793d7324a395d..9e6b4e9835424 100644 --- a/drivers/gpu/drm/xe/xe_ggtt.c +++ b/drivers/gpu/drm/xe/xe_ggtt.c @@ -396,9 +396,8 @@ static void ggtt_node_remove_work_func(struct work_stru= ct *work) delayed_removal_work); struct xe_device *xe =3D tile_to_xe(node->ggtt->tile); =20 - xe_pm_runtime_get(xe); + guard(xe_pm_runtime)(xe); ggtt_node_remove(node); - xe_pm_runtime_put(xe); } =20 /** --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1BC444CA26C; Sat, 28 Feb 2026 17:35:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300107; cv=none; b=PIokPMotF3EevgfOj1SCtywX7L1uWW8joMd/MRiUcT/84bvPWTHDTzg0QcK2pN0r6xoqv2z38PtoYwi341s9cT7E3OogQrI8+/+1P65L26hcTMc/H27NFR3HhPdPnf1gfkk8yoBZ0niAHUVNNKhsGKO5V/e2a8CybszUVGwkTk0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300107; c=relaxed/simple; bh=Q2NV62oJ9Rk/vMU9B7uyWbpa6IUD0HHYXjbz4QRK468=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BumdZBPVoeGdBEk+XktUi6RuexOIvkOJoXybS41DuPCXX4b89oyMhs58WnifXtFI/T8Dueqn+WGYir5RWDv2yYmsipphEhUM+GOgOf5Is6XVBniegco1Rlg/CzwRTI3NX4jZPNsQtajSSZAuV7FFNpQGSZUwXQg/WmmHbXo2jr4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mROXQa4z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mROXQa4z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6492FC19425; Sat, 28 Feb 2026 17:35:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300107; bh=Q2NV62oJ9Rk/vMU9B7uyWbpa6IUD0HHYXjbz4QRK468=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mROXQa4z70cL4KsxQCjDl1jvvYgi32EJci9/hE0lom6GRekfxrA9682O02+AdQUE0 92kK35oh27FSKgaUVe1jaiJiXeKk0Cku5+iklN45L4xR6TdbI7vZWV8cDAjRVrrS3L pHf0MifBWs/yQ8jUXTk8yqYAC8YaTuCoJqBw+9hzGX5jqp3l5BOi0PP//w6m1JXzeD x6LA+3U8B6DbztKwW1OcjrPICyIMwvytwOzn3GDO6VQGF/z7zBbTBBSCKG0LLiyHW/ Qd5ObXauPpInUTz7fqYc7Yt30Ex+DUyEGR5qKlp/gCm/FXk5tny2G3uN3mjo347B8s rkG8WP9R6Gu8w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Matthew Brost , Tejas Upadhyay , Sasha Levin Subject: [PATCH 6.19 123/844] drm/xe: Covert return of -EBUSY to -ENOMEM in VM bind IOCTL Date: Sat, 28 Feb 2026 12:20:36 -0500 Message-ID: <20260228173244.1509663-124-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Matthew Brost [ Upstream commit 6028f59620927aee2e15a424004012ae05c50684 ] xe_vma_userptr_pin_pages can return -EBUSY but -EBUSY has special meaning in VM bind IOCTLs that user fence is pending that is attached to the VMA. Convert -EBUSY to -ENOMEM in this case as -EBUSY in practice means we are low or out of memory. Signed-off-by: Matthew Brost Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20251122012502.382587-2-matthew.brost@intel.= com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/xe/xe_vm.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index 095bb197e8b05..9781209dd26ed 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -2451,8 +2451,17 @@ static struct xe_vma *new_vma(struct xe_vm *vm, stru= ct drm_gpuva_op_map *op, if (IS_ERR(vma)) return vma; =20 - if (xe_vma_is_userptr(vma)) + if (xe_vma_is_userptr(vma)) { err =3D xe_vma_userptr_pin_pages(to_userptr_vma(vma)); + /* + * -EBUSY has dedicated meaning that a user fence + * attached to the VMA is busy, in practice + * xe_vma_userptr_pin_pages can only fail with -EBUSY if + * we are low on memory so convert this to -ENOMEM. + */ + if (err =3D=3D -EBUSY) + err =3D -ENOMEM; + } } if (err) { prep_vma_destroy(vm, vma, false); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F28C4D8D87; Sat, 28 Feb 2026 17:35:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300108; cv=none; b=BJAmfZAeJ5UdDSbR0uRakeXag/d4/PlYMb03FR645ElhLDJtEBxm4QTpYL6D2XT7qiG8loYuwyl4xCvnoekrC40ABL2PRyLNEXPjKk02T1qGZexAba21UVuC2vh6PvyQOOczF1E5m1oOpWj0m0ih3lMKihldReOblO7Y+PMfPrk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300108; c=relaxed/simple; bh=V/p2T36y6sxgHGYF7MNGfb1Sl2dsCVVYF9H5KcDeDcs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=o9J2zcptqvhBGNFO1ZZui6UG8Jhqlrwiz9LqHWm0Zu6m5XpwoqO+tLkueGPTMR4G20WgF8sXIfCvSMxpbYTX3SkldHV2WgiXt4kaqspIId79aXMewO/t78nlY03X8ijtkHbK+J8nAWnSDuyEqw0qxHkFAQ/7I6q6h0MxQKOZcmY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rf39c5oy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rf39c5oy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42D8CC19424; Sat, 28 Feb 2026 17:35:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300107; bh=V/p2T36y6sxgHGYF7MNGfb1Sl2dsCVVYF9H5KcDeDcs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rf39c5oyim/4AyN3Jhljd3+MWyJqnt0uPT7IaHjuK8Mcp7gt4bpvAe42piLsTI/1T hD6lA3UcxZH0Q+KVbk8M5RFQfyFZl8msmbecPEBAkBvYyjHhj7CihVaDEgX+9eVm/i 6domWo8isVa84NTG4zrxvXaM/VLMLj9YS6v+e2eEumht5/yHtYrwaiiMWyVC8NTpDJ hERLrfTIoFBhsqQgSjB9sIvp3uZWq6qXmv280iIaRgduXuvTIA1v6vx8jef0NWDAnG gbZAFZvutz+hxa9lAD32GC1QkAfOmskQygj/kKVyOWMMmMJsleVDbqI7vAzeBcG6v7 rYh0i2kAXkVSw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Himal Prasad Ghimiray , Matthew Brost , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Sasha Levin Subject: [PATCH 6.19 124/844] drm/xe/vm: Skip ufence association for CPU address mirror VMA during MAP Date: Sat, 28 Feb 2026 12:20:37 -0500 Message-ID: <20260228173244.1509663-125-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Himal Prasad Ghimiray [ Upstream commit 7f08cc5b3cc3bf6416f8b55bff906f67ed75637d ] The MAP operation for a CPU address mirror VMA does not require ufence association because such mappings are not GPU-synchronized and do not participate in GPU job completion signaling. Remove the unnecessary ufence addition for this case to avoid -EBUSY failure in check_ufence of unbind ops. Cc: Matthew Brost Cc: Thomas Hellstr=C3=B6m Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20251125075628.1182481-6-himal.prasad.ghimir= ay@intel.com Signed-off-by: Himal Prasad Ghimiray Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/xe/xe_vm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index 9781209dd26ed..612fc5b2539cd 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -3223,7 +3223,8 @@ static void op_add_ufence(struct xe_vm *vm, struct xe= _vma_op *op, { switch (op->base.op) { case DRM_GPUVA_OP_MAP: - vma_add_ufence(op->map.vma, ufence); + if (!xe_vma_is_cpu_addr_mirror(op->map.vma)) + vma_add_ufence(op->map.vma, ufence); break; case DRM_GPUVA_OP_REMAP: if (op->remap.prev) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB6854D8D9C; Sat, 28 Feb 2026 17:35:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300108; cv=none; b=oEbJwf0cqdzV7TiFYvoxC6MsoK+NHRZ/CyZNcrXmPxRVJ2MXpClUBonUQqjAmT0HgGB5/SmuF42pxrdaB92equILwgVy6txVoiEWNHxVbWVk7XyOhzPR6ri633oWZgAcYQLTK6XHsFfUP05FZLyg3mImX++184cPM9p7IDwacf4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300108; c=relaxed/simple; bh=tBg3vpDSFHpRBvcSIvLKnAjE33wX6Eu8WWVlpec+G9A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=k/keo7DtNX84j9OjIk3DHzYXGmPqCJugeIr9A1+qOTsyYJw9jeEFMyrpyJ7ZCsem5TDTa5ievOPH83SjZKE1yojnNTrnQj/kHGMjCIHI09UYnpv9X5M3KdqO9zGzFzAiuei0CN6f2IH+fTPbojtmZ6rKVM72ptAhfgTGsqfDQTo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UIZRwC0u; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UIZRwC0u" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34F03C116D0; Sat, 28 Feb 2026 17:35:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300108; bh=tBg3vpDSFHpRBvcSIvLKnAjE33wX6Eu8WWVlpec+G9A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UIZRwC0uJALE5lv3tH1CQOt6imtsAZlh2JJ862vk+jin4cjNYeLlibfev+cswkG3f dlPPQ9/c4CDuMcXmJop+qkMVK4jKDhXwaBZqHpaROHlPTR64yTLPl6Ledsd9zlWkR6 3yZxz98Vo7bZP9izC035uVJkmR8XuXCuVGclkugkSOPSJ2h1nik80FOxBmi4352pdT yfbH3Pln7oWk8ilZ2/+CFAicPse5VZ57WkNeJduFfRmp+ZCeEt+4ud9qsvDRBkR98e yii6XVMJlxdDKT0WJJ7Lr+mWBut8T806LuXV/1TCluoFytfdCFWwyzRGBkPUi7rY7R BDA7cjGWUUdvg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Boris Brezillon , Steven Price , Sasha Levin Subject: [PATCH 6.19 125/844] drm/panthor: Always wait after sending a command to an AS Date: Sat, 28 Feb 2026 12:20:38 -0500 Message-ID: <20260228173244.1509663-126-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Boris Brezillon [ Upstream commit d2c6fde56d451ca48a5e03428535ce3dbc8fc910 ] There's currently no situation where we want to issue a command to an AS and not wait for this command to complete. The wait is either explicitly done (LOCK, UNLOCK) or it's missing (UPDATE). So let's turn write_cmd() into as_send_cmd_and_wait() that has the wait after a command is sent. v2: - New patch v3: - Collect R-b v4: - No changes Reviewed-by: Steven Price Link: https://patch.msgid.link/20251128084841.3804658-2-boris.brezillon@col= labora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/panthor/panthor_mmu.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/pantho= r/panthor_mmu.c index 9194bad4b6196..c15d2a3906db9 100644 --- a/drivers/gpu/drm/panthor/panthor_mmu.c +++ b/drivers/gpu/drm/panthor/panthor_mmu.c @@ -510,27 +510,29 @@ static int wait_ready(struct panthor_device *ptdev, u= 32 as_nr) return ret; } =20 -static int write_cmd(struct panthor_device *ptdev, u32 as_nr, u32 cmd) +static int as_send_cmd_and_wait(struct panthor_device *ptdev, u32 as_nr, u= 32 cmd) { int status; =20 /* write AS_COMMAND when MMU is ready to accept another command */ status =3D wait_ready(ptdev, as_nr); - if (!status) + if (!status) { gpu_write(ptdev, AS_COMMAND(as_nr), cmd); + status =3D wait_ready(ptdev, as_nr); + } =20 return status; } =20 -static void lock_region(struct panthor_device *ptdev, u32 as_nr, - u64 region_start, u64 size) +static int lock_region(struct panthor_device *ptdev, u32 as_nr, + u64 region_start, u64 size) { u8 region_width; u64 region; u64 region_end =3D region_start + size; =20 if (!size) - return; + return 0; =20 /* * The locked region is a naturally aligned power of 2 block encoded as @@ -553,7 +555,7 @@ static void lock_region(struct panthor_device *ptdev, u= 32 as_nr, =20 /* Lock the region that needs to be updated */ gpu_write64(ptdev, AS_LOCKADDR(as_nr), region); - write_cmd(ptdev, as_nr, AS_COMMAND_LOCK); + return as_send_cmd_and_wait(ptdev, as_nr, AS_COMMAND_LOCK); } =20 static int mmu_hw_do_operation_locked(struct panthor_device *ptdev, int as= _nr, @@ -586,9 +588,7 @@ static int mmu_hw_do_operation_locked(struct panthor_de= vice *ptdev, int as_nr, * power it up */ =20 - lock_region(ptdev, as_nr, iova, size); - - ret =3D wait_ready(ptdev, as_nr); + ret =3D lock_region(ptdev, as_nr, iova, size); if (ret) return ret; =20 @@ -601,10 +601,7 @@ static int mmu_hw_do_operation_locked(struct panthor_d= evice *ptdev, int as_nr, * at the end of the GPU_CONTROL cache flush command, unlike * AS_COMMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. */ - write_cmd(ptdev, as_nr, AS_COMMAND_UNLOCK); - - /* Wait for the unlock command to complete */ - return wait_ready(ptdev, as_nr); + return as_send_cmd_and_wait(ptdev, as_nr, AS_COMMAND_UNLOCK); } =20 static int mmu_hw_do_operation(struct panthor_vm *vm, @@ -633,7 +630,7 @@ static int panthor_mmu_as_enable(struct panthor_device = *ptdev, u32 as_nr, gpu_write64(ptdev, AS_MEMATTR(as_nr), memattr); gpu_write64(ptdev, AS_TRANSCFG(as_nr), transcfg); =20 - return write_cmd(ptdev, as_nr, AS_COMMAND_UPDATE); + return as_send_cmd_and_wait(ptdev, as_nr, AS_COMMAND_UPDATE); } =20 static int panthor_mmu_as_disable(struct panthor_device *ptdev, u32 as_nr) @@ -648,7 +645,7 @@ static int panthor_mmu_as_disable(struct panthor_device= *ptdev, u32 as_nr) gpu_write64(ptdev, AS_MEMATTR(as_nr), 0); gpu_write64(ptdev, AS_TRANSCFG(as_nr), AS_TRANSCFG_ADRMODE_UNMAPPED); =20 - return write_cmd(ptdev, as_nr, AS_COMMAND_UPDATE); + return as_send_cmd_and_wait(ptdev, as_nr, AS_COMMAND_UPDATE); } =20 static u32 panthor_mmu_fault_mask(struct panthor_device *ptdev, u32 value) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B736B36F40A; Sat, 28 Feb 2026 17:35:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300109; cv=none; b=Wv9v0HStjpjvIF8hiqnM9RYkIwhR4P8aJtU/HAjEqsH+8wmsjMYdQZdZkue51C5PeHd4FLyOgk8Zdm5H2NAqElrZMeKowm+x0Pbd+QO4QmhfqwHUisnns9P3nlJWGUQxzXSfXcmzPAO8+IvHuJDEuAzNv5wmLqH65MP3Rj1pPis= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300109; c=relaxed/simple; bh=dXPRIil9Z8yUwBs9VwVNLimcRmtPk4s6VpP+5WBMpgY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q/47A+NFOiHooaqOg2eQBGVanmkerSb8OS9aMPDEF/E7wiK5g4eAOZCY3fDzAnlpcfYqFojowhL7blasmcaHMVWJIpBkRsFKtRPygFUvx6k7/0urWOCIlRgC65UXvFQXeQw0zcOf5xO+JWewVFSjH2MgdqQ0BXXFV68O6YNgKHQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=psAweZjG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="psAweZjG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10F2EC19423; Sat, 28 Feb 2026 17:35:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300109; bh=dXPRIil9Z8yUwBs9VwVNLimcRmtPk4s6VpP+5WBMpgY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=psAweZjGpN1D/zdZHM3Eh8kF6+ahcQR64bJ1O9DWfTECisWCui5yyVOLuIGbjXyY0 qxqpcexFsvVniqvVzx6FCSUd1yKHpPnXtf3+PxzZ6Q4K1q6rcfxcSYdH780P/w4mmE DqIFl4HEm5eQ2dxV9lV+Glo5Hj1c8YwDf8Wwvjr7avIqbBlrZ/QC+Kvjmz5vFGWu/l 4y09ES3nG+Lu0vthNnYHqwm4R6fL9H3QLhnMTJ5zJhJShgRahKkEHCGeagQiuHDMBN Q+h3v8HycbZfOzrE0Ow2OLZn9d/sdCnv/CAgJIQd2mHXjZH5HUdnKDofFQX96e3Oet D+InEC/Zrm6qQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Balasubramani Vivekanandan , Matt Roper , Sasha Levin Subject: [PATCH 6.19 126/844] drm/xe/xe3_lpg: Apply Wa_16028005424 Date: Sat, 28 Feb 2026 12:20:39 -0500 Message-ID: <20260228173244.1509663-127-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Balasubramani Vivekanandan [ Upstream commit 9d94c1cf6ef938abd4b849b66f8eab11e3c537ef ] Applied Wa_16028005424 to Graphics version from 30.00 to 30.05 Reviewed-by: Matt Roper Signed-off-by: Balasubramani Vivekanandan Link: https://patch.msgid.link/20251121100822.20076-2-balasubramani.vivekan= andan@intel.com Signed-off-by: Matt Roper Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/xe/regs/xe_guc_regs.h | 3 +++ drivers/gpu/drm/xe/xe_wa.c | 5 +++++ 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/xe/regs/xe_guc_regs.h b/drivers/gpu/drm/xe/reg= s/xe_guc_regs.h index 2118f7dec287f..87984713dd126 100644 --- a/drivers/gpu/drm/xe/regs/xe_guc_regs.h +++ b/drivers/gpu/drm/xe/regs/xe_guc_regs.h @@ -90,6 +90,9 @@ #define GUC_SEND_INTERRUPT XE_REG(0xc4c8) #define GUC_SEND_TRIGGER REG_BIT(0) =20 +#define GUC_INTR_CHICKEN XE_REG(0xc50c) +#define DISABLE_SIGNALING_ENGINES REG_BIT(1) + #define GUC_BCS_RCS_IER XE_REG(0xc550) #define GUC_VCS2_VCS1_IER XE_REG(0xc554) #define GUC_WD_VECS_IER XE_REG(0xc558) diff --git a/drivers/gpu/drm/xe/xe_wa.c b/drivers/gpu/drm/xe/xe_wa.c index c7eab0c4af7a8..68238e73015b7 100644 --- a/drivers/gpu/drm/xe/xe_wa.c +++ b/drivers/gpu/drm/xe/xe_wa.c @@ -15,6 +15,7 @@ =20 #include "regs/xe_engine_regs.h" #include "regs/xe_gt_regs.h" +#include "regs/xe_guc_regs.h" #include "regs/xe_regs.h" #include "xe_device_types.h" #include "xe_force_wake.h" @@ -315,6 +316,10 @@ static const struct xe_rtp_entry_sr gt_was[] =3D { XE_RTP_ACTIONS(SET(VDBOX_CGCTL3F10(0), RAMDFTUNIT_CLKGATE_DIS)), XE_RTP_ENTRY_FLAG(FOREACH_ENGINE), }, + { XE_RTP_NAME("16028005424"), + XE_RTP_RULES(GRAPHICS_VERSION_RANGE(3000, 3005)), + XE_RTP_ACTIONS(SET(GUC_INTR_CHICKEN, DISABLE_SIGNALING_ENGINES)) + }, }; =20 static const struct xe_rtp_entry_sr engine_was[] =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 933144D90B1; Sat, 28 Feb 2026 17:35:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300110; cv=none; b=pWeFm5W/g0g34vbpXevVx+oJaLORFybcxOKpjY64wrP+seCqB0+HGmdib3RherXK3oS6gZslaFibz+kc2g1UtmvfHcgpx81fSADqEPl+xwXt30Xiz6h8TjvbM6J4UzwzLifY+1IqhiWoiPNzP77P8MgRXz6+ileim1qoOpy6C04= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300110; c=relaxed/simple; bh=LXPnYFyjecgtFc/ffRpGlEF9xDMmt3tX7KpNWgiAbYc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=i+a+VX52QsM5HJrjIPrvXsXa3WR2HqpK9dbBt6ffLows/39fMzEtcYjKj2OcppI5mE6lNALcBFEdmO17AvqL2J0zlZwaf/1LhnWuaU2MAJFIhcDr5GqyAClrlK///IRp/MSYefCinJ8hUiXRK7t1HNhHLNilhpwkrULurx+zKE0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hABZIGlt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hABZIGlt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC352C19423; Sat, 28 Feb 2026 17:35:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300110; bh=LXPnYFyjecgtFc/ffRpGlEF9xDMmt3tX7KpNWgiAbYc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hABZIGltr0Huw9E9Plr2omWdLW8DY5y2DjFxZj04+5LKkRZVhBSicw7Dp+mIsMjl/ kFM9LvdsudLeLHBZZbm6e67asXzyKYeYdZk08CAqPKf/brfq2bYD2UfAeB3IEJ+knw fqxRBwtkc929ymeEoFc1RfRKSLqx1wtuW2HBXd1d65WyFb6spT/bZadsfvzIyDR7m8 fZd7G9Ok8MqKn83zcGRLvinHFk0+mUWO0a5alXB6BR9pqqD9zqQJIWuqma7vOAb9f8 jqOvBBJld8aTRfbsEoceBMfgm52q1B9stH6Ek5A9i4Tq7CdEO7TRymQqm/QVgrSczl R25P+2hARAwOg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Langyan Ye , Douglas Anderson , Sasha Levin Subject: [PATCH 6.19 127/844] drm/panel-edp: Add CSW MNE007QB3-1 Date: Sat, 28 Feb 2026 12:20:40 -0500 Message-ID: <20260228173244.1509663-128-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Langyan Ye [ Upstream commit b1ea3babb67dcb8b0881c2ab49dfba88b1445856 ] Add support for the CSW MNE007QB3-1, pleace the EDID here for subsequent reference. 00 ff ff ff ff ff ff 00 0e 77 7c 14 00 00 00 00 00 23 01 04 a5 1e 13 78 07 ee 95 a3 54 4c 99 26 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 35 3c 80 a0 70 b0 23 40 30 20 36 00 2d bc 10 00 00 18 2b 30 80 a0 70 b0 23 40 30 20 36 00 2d bc 10 00 00 18 00 00 00 fd 00 28 3c 4a 4a 0f 01 0a 20 20 20 20 20 20 00 00 00 fc 00 4d 4e 45 30 30 37 51 42 33 2d 31 0a 20 01 5b 70 20 79 02 00 21 00 1d c8 0b 5d 07 80 07 b0 04 00 3d 8a 54 cd a4 99 66 62 0f 02 45 54 40 5e 40 5e 00 44 12 78 2e 00 06 00 44 40 5e 40 5e 81 00 20 74 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 8d 00 e3 05 04 00 e6 06 01 00 60 60 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 68 90 Signed-off-by: Langyan Ye Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251127121601.1608379-1-yelangyan@huaqin.co= rp-partner.google.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/panel/panel-edp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/pane= l-edp.c index 415b894890ad7..023fbbb10eb4f 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -2033,6 +2033,7 @@ static const struct edp_panel_entry edp_panels[] =3D { EDP_PANEL_ENTRY('C', 'S', 'W', 0x1462, &delay_200_500_e50, "MNE007QS5-2"), EDP_PANEL_ENTRY('C', 'S', 'W', 0x1468, &delay_200_500_e50, "MNE007QB2-2"), EDP_PANEL_ENTRY('C', 'S', 'W', 0x146e, &delay_80_500_e50_d50, "MNE007QB3-= 1"), + EDP_PANEL_ENTRY('C', 'S', 'W', 0x147c, &delay_200_500_e50_d100, "MNE007QB= 3-1"), EDP_PANEL_ENTRY('C', 'S', 'W', 0x1519, &delay_200_500_e80_d50, "MNF601BS1= -3"), =20 EDP_PANEL_ENTRY('E', 'T', 'C', 0x0000, &delay_50_500_e200_d200_po2e335, "= LP079QX1-SP0V"), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C4E14D90CC; Sat, 28 Feb 2026 17:35:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300111; cv=none; b=XO80sIF25MKwwu43zvE+mRS4inplYKtnGhfeLUTKDpn1Qj247tgBpc6zvOir9ISBqP2dgBMKQBJit3ETjOlOLchBzgFjJ6n0EVzg18vd4miHVptaUPu1vaGDw28PTiTDeCrmTzdRMzOlun1ZcQXygyvWp8pL5pRrgqtRQ6ifF4I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300111; c=relaxed/simple; bh=Kjivy1/YxcWIrWPJjkwYGfoTheQc5bVZ6kO0ti60zlo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gEQtABeMVpObz/+D5F746kIvh9SY+DvqoXDbyaymu4Nz0HZ94Gag09lI+9td001cl1AVLGGcl3+jkgoYUUuHvKbNpKNhYenb0Aa36nN8XJpdyR1ug5KzQ8Q7G7LHaI/awvUvZHNbybtMrhH53PqCJQkDWlo/xSuUyGFsjKAAUHM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TyH0UAce; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TyH0UAce" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA263C19423; Sat, 28 Feb 2026 17:35:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300111; bh=Kjivy1/YxcWIrWPJjkwYGfoTheQc5bVZ6kO0ti60zlo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TyH0UAceZElPYcQIuakOkkO6/V3HotwBbBvTsGkuW5Ck0q7kgCiuhuamAVtUWJHu5 lKVlS5GsWuVEw0MY0nJESw6W6rYvNLlDFxNKUSCDcs6lhXO2SF3MS3ogaudq9Hflxl fytDEA1/Ognj2tnFWX1hA9HdfhsGidYPxx9uCMhxepJeRdsEs/xjtz+RqzsYG3uewp tVVa4THoSUOkngyxloOukEOMUljLKq1U3O965eSJuRi8hZrMFnI3g4e3TStrJ15EaW QnscTAphKzM4KYMZJ4OqTNmQ17r6UdmS5XFyb1F1XnoCVc7b/MEavrdR/2OgYEbR4F SFrTpEXgyA9RA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alexey Klimov , Bjorn Andersson , Vinod Koul , Douglas Anderson , Sasha Levin Subject: [PATCH 6.19 128/844] gpu/panel-edp: add AUO panel entry for B140HAN06.4 Date: Sat, 28 Feb 2026 12:20:41 -0500 Message-ID: <20260228173244.1509663-129-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexey Klimov [ Upstream commit 2976aeb0de77da599ad37691963efbdcb07435ce ] Add an eDP panel entry for AUO B140HAN06.4 that is also used in some variants of Lenovo Flex 5G with Qcom SC8180 SoC. The raw edid of the panel is: 00 ff ff ff ff ff ff 00 06 af 3d 64 00 00 00 00 2b 1d 01 04 a5 1f 11 78 03 b8 1a a6 54 4a 9b 26 0e 52 55 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 14 37 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 10 2c 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 34 30 48 41 4e 30 36 2e 34 20 0a 00 eb I do not have access to the datasheet and but it is tested on above mentioned laptop for a few weeks and seems to work just fine with timing info of similar panels. Cc: Bjorn Andersson Cc: Vinod Koul Signed-off-by: Alexey Klimov Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251203074555.690613-1-alexey.klimov@linaro= .org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/panel/panel-edp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/pane= l-edp.c index 023fbbb10eb4f..2c35970377431 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -1904,6 +1904,7 @@ static const struct edp_panel_entry edp_panels[] =3D { EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, &delay_200_500_e50, "B116XAN06.1"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, &delay_200_500_e50, "B116XAN06.3"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, &delay_200_500_e50, "B140HAK02.7"), + EDP_PANEL_ENTRY('A', 'U', 'O', 0x643d, &delay_200_500_e50, "B140HAN06.4"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x723c, &delay_200_500_e50, "B140XTN07.2"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x73aa, &delay_200_500_e50, "B116XTN02.3"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, &delay_200_500_e50, "B133UAN01.0"), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C4E954D98E1; Sat, 28 Feb 2026 17:35:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300112; cv=none; b=nmAysnzQmMWeJ8Z/DVlRRJH4ovnh7Dsx7ELHIVnXzc2qOtn0/REw9pX7FAnFuLdjOJTNbKJnijQ5eVnSdbBO9egYXhKBO5EwdIQvktchk+ucNHWWD2CuU7JEvw1zskCaDyEgPv2UHuEUhBME5rV+2ZKJt6S4kNLhi6GyMlm5YVY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300112; c=relaxed/simple; bh=66nRdHdWaLc7C/fW+wYiSsFKUWY4bfYvWEp6G+IZgRQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l1Zo9ttRqbwpldqJhsRbtA5uodxC2oAPUGnxsuw1cgBQUJFd/vtcAhf3cV1oEBu/VbpwiM9NzbTAv9g6DOdsTCk6EuHmkQMyIrXjCeeYPoVVmbyFk+JVXbwhUDsLb89y2504cSZZio/vW5SlXKgBZi2Ua0+InGZvVuqQi9tZgPo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D0sbPQsE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="D0sbPQsE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3AFEC116D0; Sat, 28 Feb 2026 17:35:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300112; bh=66nRdHdWaLc7C/fW+wYiSsFKUWY4bfYvWEp6G+IZgRQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D0sbPQsEeOZ9/VFdJOM+fzJkgygtDJKMucLlwgi8EZXOVSMutFo/PpeV2lTYz/Dbz WTbTG0blw9M3ztx2Yoj4LR/ZU3QEyrEx4I/Va3zxtQ9DjWZqvqW8511cczuqE6SIxJ gWIN68pNkNLvHIWAvvnZEoYpm6BCFIo6WYSqUK28ZLJe4L6F4a55YRIPbXvPij7s4k xVShcNo9TH28wBvZidRRHf8iaRpfy+fZlLF+EWJpF5HONIj9a8A3eHMcN63risJVNV pMIDlHbCUpBrZEZ7JWM0QWNNFZvBsd1Vwp4s6ghuhwgUvGrRRoOChzsnFfy+1zD1Tt 0uYCl2Bz2mpYw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lizhi Hou , Maciej Falkowski , Sasha Levin Subject: [PATCH 6.19 129/844] accel/amdxdna: Fix tail-pointer polling in mailbox_get_msg() Date: Sat, 28 Feb 2026 12:20:42 -0500 Message-ID: <20260228173244.1509663-130-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lizhi Hou [ Upstream commit cd77d5a4aaf8c5c1d819f47cf814bf7d4920b0a2 ] In mailbox_get_msg(), mailbox_reg_read_non_zero() is called to poll for a non-zero tail pointer. This assumed that a zero value indicates an error. However, certain corner cases legitimately produce a zero tail pointer. To handle these cases, remove mailbox_reg_read_non_zero(). The zero tail pointer will be treated as a valid rewind event. Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251204181603.793824-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/accel/amdxdna/amdxdna_mailbox.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/drivers/accel/amdxdna/amdxdna_mailbox.c b/drivers/accel/amdxdn= a/amdxdna_mailbox.c index 8b72cf6bd6e4d..469242ed82246 100644 --- a/drivers/accel/amdxdna/amdxdna_mailbox.c +++ b/drivers/accel/amdxdna/amdxdna_mailbox.c @@ -112,22 +112,6 @@ static u32 mailbox_reg_read(struct mailbox_channel *mb= _chann, u32 mbox_reg) return readl(ringbuf_addr); } =20 -static int mailbox_reg_read_non_zero(struct mailbox_channel *mb_chann, u32= mbox_reg, u32 *val) -{ - struct xdna_mailbox_res *mb_res =3D &mb_chann->mb->res; - void __iomem *ringbuf_addr =3D mb_res->mbox_base + mbox_reg; - int ret, value; - - /* Poll till value is not zero */ - ret =3D readx_poll_timeout(readl, ringbuf_addr, value, - value, 1 /* us */, 100); - if (ret < 0) - return ret; - - *val =3D value; - return 0; -} - static inline void mailbox_set_headptr(struct mailbox_channel *mb_chann, u32 headptr_val) { @@ -291,8 +275,7 @@ static int mailbox_get_msg(struct mailbox_channel *mb_c= hann) u32 start_addr; int ret; =20 - if (mailbox_reg_read_non_zero(mb_chann, mb_chann->res[CHAN_RES_I2X].mb_ta= il_ptr_reg, &tail)) - return -EINVAL; + tail =3D mailbox_get_tailptr(mb_chann, CHAN_RES_I2X); head =3D mb_chann->i2x_head; ringbuf_size =3D mailbox_get_ringbuf_size(mb_chann, CHAN_RES_I2X); start_addr =3D mb_chann->res[CHAN_RES_I2X].rb_start_addr; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DD124D98FD; Sat, 28 Feb 2026 17:35:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300113; cv=none; b=je5UIDL8YhlRVgc+lNsbYK9VNzAmCXRmZCj3MZbBEBqNcr4IvKbWmHnK63prRFXDvJHeDq1+4HE2yCc20CCsZjhAGBeT7+tmdgwIDvzZZFhyQZt5oQCeeV1GDqKOcRtLGKROLXs3ERMcKXF3azu8jsVVCEfe2qZEHzk1RW09Pag= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300113; c=relaxed/simple; bh=4tVWj2D0Kmv3FbEwQy/QSrljpJfLDz+tARS2Fp3sK08=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q5Si69ySnat/PGPeYkjPt0N1ZPQI0FrTsnaHiYvSRd7+rDmrY26zxd26Xc1rQ7/oVsMkH/ytGeo4S+jOYL+JnpukdUz3rVX8D6K8keUEoxefZNLfZIPYuDvYt4Ni3HMJuEAtzIk3lKRHA0Nl2Q3QaANVnOwEtfZryUHNd9XZn58= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HLCjrVup; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HLCjrVup" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2BFAC19423; Sat, 28 Feb 2026 17:35:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300113; bh=4tVWj2D0Kmv3FbEwQy/QSrljpJfLDz+tARS2Fp3sK08=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HLCjrVupEm/W5V/qS56iH12uQNzVCgZwHBQyqniJnV/ylrLr2yEcvS7J0ibN4sVcX ZPeYXQUTeyAZCueQVN+iYjNZeBiSt3C9CdSLQ4xsl49kVysHvm8HrKewiLgcaeozV1 HU+rczvTTU0o6LtclZ3At2ZBSHZBwfbeR6r3KyT1KjNGTRFeWDqtlUjuYrxjzQrEnb mecPErSeMVZPSfjNFjbbB4CQmJ74XxqF+9ffKz5DijA4jD/27btNP5qz72vJYc9f8J W9MDI4JKuLwd+42nTK6b7s8Txrv+X3/b15epiBkkZxFTN8KZeJpaHgzCiyNfkY5tbw qLZkTZH+nTzAw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Likun Gao , Hawking Zhang , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 130/844] drm/amdgpu: fix NULL pointer issue buffer funcs Date: Sat, 28 Feb 2026 12:20:43 -0500 Message-ID: <20260228173244.1509663-131-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Likun Gao [ Upstream commit 9877a865d62c9c3e0f4cc369dc9ca9f7f24f5ee9 ] If SDMA block not enabled, buffer_funcs will not initialize, fix the null pointer issue if buffer_funcs not initialized. Signed-off-by: Likun Gao Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/a= md/amdgpu/amdgpu_device.c index d2c3885de711f..ba6fb23b840a0 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3309,7 +3309,8 @@ static int amdgpu_device_ip_init(struct amdgpu_device= *adev) if (r) goto init_failed; =20 - if (adev->mman.buffer_funcs_ring->sched.ready) + if (adev->mman.buffer_funcs_ring && + adev->mman.buffer_funcs_ring->sched.ready) amdgpu_ttm_set_buffer_funcs_status(adev, true); =20 /* Don't init kfd if whole hive need to be reset during init */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A3B054D991A; Sat, 28 Feb 2026 17:35:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300114; cv=none; b=P6Ye18wzEXHiQ+Q4z7yz+UmsX65GAdPv5vs4dtwXBlwSuLTgQ6HP8a8vdpQC12fiGeR8zNpxvb5pqPDxYwCk1VTsPPXia5+owBsRVQQbOlO0Xf7dwTmTjAaVvKTT5lTDo8qYJ19wUX0gBBTSAInnq/9z+/eQq48zF2zNWN9yFDA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300114; c=relaxed/simple; bh=qM7gp6HDaVPEmQMATIfFXNVj9J3aUDIQ9zDTxA3dCqw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EkFXEFuX+kKV3NqLyyGkCk0xuJnbpHeSYIPMeBawzTyY2iQl9EuMDEi4QKMbzPYahZY62VNs5Owe44ghvc2wBe+w3kGwP3+xU8pURlmv260M2ugpb50DocNMdjQcoAyX4Uy0g7Vqqs7azVOAtHua8qECvUT9Oys0QORlvBG6afE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q/Sza/uv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="q/Sza/uv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95891C19423; Sat, 28 Feb 2026 17:35:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300114; bh=qM7gp6HDaVPEmQMATIfFXNVj9J3aUDIQ9zDTxA3dCqw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q/Sza/uvloARo5emfZIRZyGlwJanSE6exJIceOGNgIlBggH10o8xQdmQVjdxQuo6l edN8Atcm8gmsWEHWmwgBMAj0N9GA2hWOcwC+UI1pxnIQWGcx2yME5C1A6l6WGsT05E kvymBOn+EimtMiMIu+OrLB7RJ2+wPO9XWAdqui627Jil672GJ+d9bYB3u3oC8i1N4E jI3g1RdFWsLT19MRzi8AAGgmGV/XwWo4yuwrDNmN2Y3XaX3u8sxdraNGwy3ZU8RaYM IrI094+1wweYqnsnC1xNpC+BXq9uuRwW9yEt2qhz21kD8yAfiaYeaFhOX5ilM6M4OT a2iW1KbCWkK1A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tao Zhou , Hawking Zhang , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 131/844] drm/amdgpu: fix the calculation of RAS bad page number Date: Sat, 28 Feb 2026 12:20:44 -0500 Message-ID: <20260228173244.1509663-132-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tao Zhou [ Upstream commit f752e79d38857011f1293fcb6c810409c3b669ee ] __amdgpu_ras_restore_bad_pages is responsible for the maintenance of bad page number, drop the unnecessary bad page number update in the error handling path of add_bad_pages. Signed-off-by: Tao Zhou Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/= amdgpu/amdgpu_ras.c index 8de9f68f7bea6..9c21401c9b830 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -3249,8 +3249,6 @@ int amdgpu_ras_add_bad_pages(struct amdgpu_device *ad= ev, /* deal with retire_unit records a time */ ret =3D __amdgpu_ras_convert_rec_array_from_rom(adev, &bps[i], &err_data, nps); - if (ret) - con->bad_page_num -=3D adev->umc.retire_unit; i +=3D (adev->umc.retire_unit - 1); } else { break; @@ -3263,8 +3261,6 @@ int amdgpu_ras_add_bad_pages(struct amdgpu_device *ad= ev, for (; i < pages; i++) { ret =3D __amdgpu_ras_convert_rec_from_rom(adev, &bps[i], &err_data, nps); - if (ret) - con->bad_page_num -=3D adev->umc.retire_unit; } =20 con->eh_data->count_saved =3D con->eh_data->count; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64B0A4DA530; Sat, 28 Feb 2026 17:35:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300115; cv=none; b=FpfXfHQDYXTWPX6TC1IcqBNI2OcaUocjLy5Ym5I64LYbcyXTCTqHdEra/zG4KIbs/vgy8KeFYL/MdP/wQ1MVicTGltJAb7DqRyFlBhSxAb0LiSjhulkDlijSCCg3mRad2mryX1ztiOwJUSXaqZ7+S/3CsB5QZKkKQ1vcXoz0gY0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300115; c=relaxed/simple; bh=AhOMUSrE/ytYego96oRmMCNdcXFTfLYdL+MN4A/YjGc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HXH0+RjkAp3u/fWFEjSUjVrcpYH4kWEn+/HqQ1+vp/W9mXVUAkTI+uS4kGUbtf219kl0NJpOyLUMuYM0iBnCXZCiKWmVS0ExXtaUiTy04/mirdLboasbzE5BFN48oTB9eWzlAWqN8DftLO+AQ/zJi3uw/K3k+K8dwJAsy4Cy2YQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cu9SEBai; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cu9SEBai" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83B3EC19424; Sat, 28 Feb 2026 17:35:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300115; bh=AhOMUSrE/ytYego96oRmMCNdcXFTfLYdL+MN4A/YjGc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cu9SEBaiXPidfc4L6scFGuBTx9/VV+fiS3pG5zYoZIqsvdqzFhSPNNin+lhDiAiOe 0gI/sxm9pSU941xIcQqo+xewUktbX/ROZ6ZY5EhDxIq/SRz3Qt4CfLRs9SnU2i1CBc 6DD7uAKUxJuRVpmCJS8/hW9BHhCKRrXcOpzouzn35ngirfwPQuQX3ieO2xZYSTYFc6 Xlfv1coTV1Bou+t/Pu31+MPVuWST9WsNouL3LF8QehZjshuyNgSBFDXypwWySkmoSV nNYlUI7ZScvEnm1Vk31GOfnh12yPCGQ5j7WfATyo/WeGU+Bh6CNbAXRm4mLBut/Wop KuHDqvrbJzoYQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Asad Kamal , Lijo Lazar , Hawking Zhang , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 132/844] drm/amdgpu/ras: Move ras data alloc before bad page check Date: Sat, 28 Feb 2026 12:20:45 -0500 Message-ID: <20260228173244.1509663-133-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Asad Kamal [ Upstream commit bd68a1404b6fa2e7e9957b38ba22616faba43e75 ] In the rare event if eeprom has only invalid address entries, allocation is skipped, this causes following NULL pointer issue [ 547.103445] BUG: kernel NULL pointer dereference, address: 0000000000000= 010 [ 547.118897] #PF: supervisor read access in kernel mode [ 547.130292] #PF: error_code(0x0000) - not-present page [ 547.141689] PGD 124757067 P4D 0 [ 547.148842] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 547.158504] CPU: 49 PID: 8167 Comm: cat Tainted: G OE 6.8= .0-38-generic #38-Ubuntu [ 547.177998] Hardware name: Supermicro AS -8126GS-TNMR/H14DSG-OD, BIOS 1.= 7 09/12/2025 [ 547.195178] RIP: 0010:amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu] [ 547.210375] Code: e8 63 78 82 c0 45 31 d2 45 3b 75 08 48 8b 45 a0 73 44 = 44 89 f1 48 8b 7d 88 48 89 ca 48 c1 e2 05 48 29 ca 49 8b 4d 00 48 01 d1 <48= > 83 79 10 00 74 17 49 63 f2 48 8b 49 08 41 83 c2 01 48 8d 34 76 [ 547.252045] RSP: 0018:ffa0000067287ac0 EFLAGS: 00010246 [ 547.263636] RAX: ff11000167c28130 RBX: ff11000127600000 RCX: 00000000000= 00000 [ 547.279467] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ff11000125b= 1c800 [ 547.295298] RBP: ffa0000067287b50 R08: 0000000000000000 R09: 00000000000= 00000 [ 547.311129] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000= 00000 [ 547.326959] R13: ff11000217b1de00 R14: 0000000000000000 R15: 00000000000= 00092 [ 547.342790] FS: 0000746e59d14740(0000) GS:ff11017dfda80000(0000) knlGS:= 0000000000000000 [ 547.360744] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 547.373489] CR2: 0000000000000010 CR3: 000000019585e001 CR4: 0000000000f= 71ef0 [ 547.389321] PKRU: 55555554 [ 547.395316] Call Trace: [ 547.400737] [ 547.405386] ? show_regs+0x6d/0x80 [ 547.412929] ? __die+0x24/0x80 [ 547.419697] ? page_fault_oops+0x99/0x1b0 [ 547.428588] ? do_user_addr_fault+0x2ee/0x6b0 [ 547.438249] ? exc_page_fault+0x83/0x1b0 [ 547.446949] ? asm_exc_page_fault+0x27/0x30 [ 547.456225] ? amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu] [ 547.470040] ? mas_wr_modify+0xcd/0x140 [ 547.478548] sysfs_kf_bin_read+0x63/0xb0 [ 547.487248] kernfs_file_read_iter+0xa1/0x190 [ 547.496909] kernfs_fop_read_iter+0x25/0x40 [ 547.506182] vfs_read+0x255/0x390 This also result in space left assigned to negative values. Moving data alloc call before bad page check resolves both the issue. Signed-off-by: Asad Kamal Suggested-by: Lijo Lazar Reviewed-by: Hawking Zhang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/= amdgpu/amdgpu_ras.c index 9c21401c9b830..6b069dc4bab06 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -3076,6 +3076,11 @@ static int __amdgpu_ras_restore_bad_pages(struct amd= gpu_device *adev, struct ras_err_handler_data *data =3D con->eh_data; =20 for (j =3D 0; j < count; j++) { + if (!data->space_left && + amdgpu_ras_realloc_eh_data_space(adev, data, 256)) { + return -ENOMEM; + } + if (amdgpu_ras_check_bad_page_unlock(con, bps[j].retired_page << AMDGPU_GPU_PAGE_SHIFT)) { data->count++; @@ -3083,11 +3088,6 @@ static int __amdgpu_ras_restore_bad_pages(struct amd= gpu_device *adev, continue; } =20 - if (!data->space_left && - amdgpu_ras_realloc_eh_data_space(adev, data, 256)) { - return -ENOMEM; - } - amdgpu_ras_reserve_page(adev, bps[j].retired_page); =20 memcpy(&data->bps[data->count], &(bps[j]), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9720E4DA54B; Sat, 28 Feb 2026 17:35:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300116; cv=none; b=V9OQk+K7Kk2XFswUxe0sOVbElT3ZCcDmmOYEVQKdrOnhzypIPHlqoC8Me9becWOA+8d0WlZb0W/iO+hek1AeCBgMOamOR+mIzJd2q+OpUXXFmDRV6wjog4xaNEkJjL264tgeFvLKxbco77AewitP7ZRxX4tiXiFH5hMTw4x0VE0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300116; c=relaxed/simple; bh=oebkLr1MOMbtNP7pNpSiDx60nHAn9VCedlTylHJXxHM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DiMK1o1a1AHuQ8QzKJ/c7bgv8yx1QUP+Moycf1hlt5xtxWolLhl7BYmLKGdxPhLC1kXk2H+3WjpG759CqILlTIY2T1tSfEXCszIQYgYvzDwcwFnJQkSBb9fcDouMccj6Ii6ZeXV8SMAqtGvSVvgGaApGPXEfVlAYZcMWlaB9YuA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Di/gpas4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Di/gpas4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D76EC116D0; Sat, 28 Feb 2026 17:35:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300116; bh=oebkLr1MOMbtNP7pNpSiDx60nHAn9VCedlTylHJXxHM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Di/gpas4w8gvh+YJfgY67xSFkyIzwrEGoHxu0pzBIObatkxj+8bGE+cIR9+6M8veT O67ZoL7T5k53IOT35BTNxcdNfCEvaliHYBACOrHfnf4PuGJ9isqkCcfRGwcwUg+ano RII0fOMhrupweIVxAh76vGsm1s/6SCerEiTGZeXgMdFPW5dUTihRMvlBlD+T0y9ylb DsJsAqusGsVOsdRhJYY7NyJLiK3QUt1ZhyDh95212w/kIFStvNEHP4T/gaOBW/LMRy JDqgsLQ9hIjrNo3yETtFU15BCQoI+c++5B/5teDRax4efnTtZ+nKb28tK9Qe3GtQJg iabczt5+6L/Rw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Relja Vojvodic , Chris Park , Wenjing Liu , Alex Hung , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 133/844] drm/amd/display: Correct DSC padding accounting Date: Sat, 28 Feb 2026 12:20:46 -0500 Message-ID: <20260228173244.1509663-134-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Relja Vojvodic [ Upstream commit c7062be3380cb20c8b1c4a935a13f1848ead0719 ] [WHY] - After the addition of all OVT patches, DSC padding was being accounted for multiple times, effectively doubling the padding - This caused compliance failures or corruption [HOW] - Add padding to DSC pic width when required by HW, and do not re-add when calculating reg values - Do not add padding when computing PPS values, and instead track padding separately to add when calculating slice width values Reviewed-by: Chris Park Reviewed-by: Wenjing Liu Signed-off-by: Relja Vojvodic Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c | 2 +- drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c | 2 +- drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c | 2 +- drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 3 ++- .../gpu/drm/amd/display/dc/resource/dcn20/dcn20_resource.c | 6 +++--- 5 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c b/dr= ivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c index 4ee6ed610de0b..3e239124c17d8 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c @@ -108,7 +108,7 @@ static void update_dsc_on_stream(struct pipe_ctx *pipe_= ctx, bool enable) dsc_cfg.dc_dsc_cfg =3D stream->timing.dsc_cfg; ASSERT(dsc_cfg.dc_dsc_cfg.num_slices_h % opp_cnt =3D=3D 0); dsc_cfg.dc_dsc_cfg.num_slices_h /=3D opp_cnt; - dsc_cfg.dsc_padding =3D pipe_ctx->dsc_padding_params.dsc_hactive_padding; + dsc_cfg.dsc_padding =3D 0; =20 dsc->funcs->dsc_set_config(dsc, &dsc_cfg, &dsc_optc_cfg); dsc->funcs->dsc_enable(dsc, pipe_ctx->stream_res.opp->inst); diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c b/driv= ers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c index be1f3caf4096f..24af5e94c7fce 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c @@ -1063,7 +1063,7 @@ void dcn32_update_dsc_on_stream(struct pipe_ctx *pipe= _ctx, bool enable) dsc_cfg.dc_dsc_cfg =3D stream->timing.dsc_cfg; ASSERT(dsc_cfg.dc_dsc_cfg.num_slices_h % opp_cnt =3D=3D 0); dsc_cfg.dc_dsc_cfg.num_slices_h /=3D opp_cnt; - dsc_cfg.dsc_padding =3D pipe_ctx->dsc_padding_params.dsc_hactive_padding; + dsc_cfg.dsc_padding =3D 0; =20 if (should_use_dto_dscclk) dccg->funcs->set_dto_dscclk(dccg, dsc->inst, dsc_cfg.dc_dsc_cfg.num_sli= ces_h); diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c b/driv= ers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c index 7aa0f452e8f7a..cb2dfd34b5e2e 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c @@ -364,7 +364,7 @@ static void update_dsc_on_stream(struct pipe_ctx *pipe_= ctx, bool enable) dsc_cfg.dc_dsc_cfg =3D stream->timing.dsc_cfg; ASSERT(dsc_cfg.dc_dsc_cfg.num_slices_h % opp_cnt =3D=3D 0); dsc_cfg.dc_dsc_cfg.num_slices_h /=3D opp_cnt; - dsc_cfg.dsc_padding =3D pipe_ctx->dsc_padding_params.dsc_hactive_padding; + dsc_cfg.dsc_padding =3D 0; =20 dsc->funcs->dsc_set_config(dsc, &dsc_cfg, &dsc_optc_cfg); dsc->funcs->dsc_enable(dsc, pipe_ctx->stream_res.opp->inst); diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c b/drivers/gpu/= drm/amd/display/dc/link/link_dpms.c index 635f614c06734..770c9cd128ae8 100644 --- a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c +++ b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c @@ -841,7 +841,7 @@ void link_set_dsc_on_stream(struct pipe_ctx *pipe_ctx, = bool enable) dsc_cfg.dc_dsc_cfg =3D stream->timing.dsc_cfg; ASSERT(dsc_cfg.dc_dsc_cfg.num_slices_h % opp_cnt =3D=3D 0); dsc_cfg.dc_dsc_cfg.num_slices_h /=3D opp_cnt; - dsc_cfg.dsc_padding =3D pipe_ctx->dsc_padding_params.dsc_hactive_padding; + dsc_cfg.dsc_padding =3D 0; =20 if (should_use_dto_dscclk) dccg->funcs->set_dto_dscclk(dccg, dsc->inst, dsc_cfg.dc_dsc_cfg.num_sli= ces_h); @@ -857,6 +857,7 @@ void link_set_dsc_on_stream(struct pipe_ctx *pipe_ctx, = bool enable) } dsc_cfg.dc_dsc_cfg.num_slices_h *=3D opp_cnt; dsc_cfg.pic_width *=3D opp_cnt; + dsc_cfg.dsc_padding =3D pipe_ctx->dsc_padding_params.dsc_hactive_padding; =20 optc_dsc_mode =3D dsc_optc_cfg.is_pixel_format_444 ? OPTC_DSC_ENABLED_44= 4 : OPTC_DSC_ENABLED_NATIVE_SUBSAMPLED; =20 diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn20/dcn20_resource.c= b/drivers/gpu/drm/amd/display/dc/resource/dcn20/dcn20_resource.c index 6679c1a14f2fe..8d10aac9c510c 100644 --- a/drivers/gpu/drm/amd/display/dc/resource/dcn20/dcn20_resource.c +++ b/drivers/gpu/drm/amd/display/dc/resource/dcn20/dcn20_resource.c @@ -1660,8 +1660,8 @@ bool dcn20_validate_dsc(struct dc *dc, struct dc_stat= e *new_ctx) if (pipe_ctx->top_pipe || pipe_ctx->prev_odm_pipe || !stream || !stream-= >timing.flags.DSC) continue; =20 - dsc_cfg.pic_width =3D (stream->timing.h_addressable + stream->timing.h_b= order_left - + stream->timing.h_border_right) / opp_cnt; + dsc_cfg.pic_width =3D (stream->timing.h_addressable + pipe_ctx->dsc_padd= ing_params.dsc_hactive_padding + + stream->timing.h_border_left + stream->timing.h_border_right) / opp_= cnt; dsc_cfg.pic_height =3D stream->timing.v_addressable + stream->timing.v_b= order_top + stream->timing.v_border_bottom; dsc_cfg.pixel_encoding =3D stream->timing.pixel_encoding; @@ -1669,7 +1669,7 @@ bool dcn20_validate_dsc(struct dc *dc, struct dc_stat= e *new_ctx) dsc_cfg.is_odm =3D pipe_ctx->next_odm_pipe ? true : false; dsc_cfg.dc_dsc_cfg =3D stream->timing.dsc_cfg; dsc_cfg.dc_dsc_cfg.num_slices_h /=3D opp_cnt; - dsc_cfg.dsc_padding =3D pipe_ctx->dsc_padding_params.dsc_hactive_padding; + dsc_cfg.dsc_padding =3D 0; =20 if (!pipe_ctx->stream_res.dsc->funcs->dsc_validate_stream(pipe_ctx->stre= am_res.dsc, &dsc_cfg)) return false; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1C7E4DB549; Sat, 28 Feb 2026 17:35:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300118; cv=none; b=K+SxVDErSGr7h7i6Ug1oSBMSePHcBevcmd2G6/pUI4TwXa8lr7NMQzeJyExJCFBYLrvjMueUl9iPcfwb8iipeH//Uf1q4gM0OmHO5wPXspGcX9/wb8csq09VhXUoQh+dpgNt9Z7b+DPXu8C1yW3P3QEisBe/VoBpNa1z7aS2CN4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300118; c=relaxed/simple; bh=TywdRE/Kigswv+zpZOJ5QiFmh2zPbE8rx25M2o9DWgs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h9tdYKF7WS/Z+upjE+vbaOILMTKqNzn2JIkRsmT7uSU9KU23+IW3uEb7Wt9ONX0NQcrqQMxW+C3pV9tFl2USTRQ7BhN4YmCru2vlBGKhHC9Em7MrKMOStLj2dQNWVapQ/b5OAMjqz6yFd5nNBEUu/I0FtuhRWqqt6pP1pKmCxDA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V0V1kkM+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V0V1kkM+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF5E5C19423; Sat, 28 Feb 2026 17:35:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300117; bh=TywdRE/Kigswv+zpZOJ5QiFmh2zPbE8rx25M2o9DWgs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V0V1kkM+VEJcGRQEacnO6gR1mybos/tG0T/2lXHsEN+59fU+C9QmcqIzLRYJPUIIt NCSnu+h8nOB/aHTzJUjOpEtZcFWzcfhUktN0xZrPR92tbm1KVoTMR0i+BSri8ReucC hW9WSK0C5ibRFpXiVN+Qcy892uJbFm3XRHbRqhID5JQ+95ReiNMpcw234CGR2VpN6f 1vIbuEh9wl1ykLChozujyS+3DCj/fzCmHTsO7kQIRp5eazpFwYaXBZOk8D9wC7C7n0 fy71aOi3CMnAYvuwkOyF6rdfTjFl0tk/tkj7jdWLUb5p/7kh6w2Dgty/I1DVxKoLkB 0e9vF2Mo2F9QA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nicholas Kazlauskas , Alvin Lee , Roman Li , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 134/844] drm/amd/display: Fix wrong x_pos and y_pos for cursor offload Date: Sat, 28 Feb 2026 12:20:47 -0500 Message-ID: <20260228173244.1509663-135-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicholas Kazlauskas [ Upstream commit c02288724b98cbc018231200891d66578f83f848 ] [Why] The hubp401_cursor_set_position function programs a different value than it stores for use with cursor offload. This can cause a desync when switching between cursor programming paths. [How] We do the translation to destination space currently twice: once in the HWSS layer, and then again in the HUBP layer since we never store the translated result. HUBP expects to program the pos->x and pos->y directly for other ASIC, so follow that pattern here as well. Reviewed-by: Alvin Lee Signed-off-by: Nicholas Kazlauskas Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c | 14 ++++++-------- .../drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 3 +++ 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c b/dri= vers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c index f01eae50d02f7..c205500290ecd 100644 --- a/drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c +++ b/drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c @@ -733,10 +733,8 @@ void hubp401_cursor_set_position( const struct dc_cursor_mi_param *param) { struct dcn20_hubp *hubp2 =3D TO_DCN20_HUBP(hubp); - int x_pos =3D pos->x - param->recout.x; - int y_pos =3D pos->y - param->recout.y; - int rec_x_offset =3D x_pos - pos->x_hotspot; - int rec_y_offset =3D y_pos - pos->y_hotspot; + int rec_x_offset =3D pos->x - pos->x_hotspot; + int rec_y_offset =3D pos->y - pos->y_hotspot; int dst_x_offset; int x_pos_viewport =3D 0; int x_hot_viewport =3D 0; @@ -748,10 +746,10 @@ void hubp401_cursor_set_position( * within preceeding ODM slices. */ if (param->recout.width) { - x_pos_viewport =3D x_pos * param->viewport.width / param->recout.width; + x_pos_viewport =3D pos->x * param->viewport.width / param->recout.width; x_hot_viewport =3D pos->x_hotspot * param->viewport.width / param->recou= t.width; } else { - ASSERT(!cur_en || x_pos =3D=3D 0); + ASSERT(!cur_en || pos->x =3D=3D 0); ASSERT(!cur_en || pos->x_hotspot =3D=3D 0); } =20 @@ -790,8 +788,8 @@ void hubp401_cursor_set_position( =20 if (!hubp->cursor_offload) { REG_SET_2(CURSOR_POSITION, 0, - CURSOR_X_POSITION, x_pos, - CURSOR_Y_POSITION, y_pos); + CURSOR_X_POSITION, pos->x, + CURSOR_Y_POSITION, pos->y); =20 REG_SET_2(CURSOR_HOT_SPOT, 0, CURSOR_HOT_SPOT_X, pos->x_hotspot, diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c b/dr= ivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c index 5eda7648d0d2b..5ffe41a96864a 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c @@ -1215,6 +1215,9 @@ void dcn401_set_cursor_position(struct pipe_ctx *pipe= _ctx) if (recout_y_pos + (int)hubp->curs_attr.height <=3D 0) pos_cpy.enable =3D false; /* not visible beyond top edge*/ =20 + pos_cpy.x =3D x_pos; + pos_cpy.y =3D y_pos; + hubp->funcs->set_cursor_position(hubp, &pos_cpy, ¶m); dpp->funcs->set_cursor_position(dpp, &pos_cpy, ¶m, hubp->curs_attr.wi= dth, hubp->curs_attr.height); } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 197204DB541; Sat, 28 Feb 2026 17:35:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300119; cv=none; b=OhYpVkn0jBiOX3eh41ftzkW5KQP7NyVyJdPX320M/KNvAUTNk9pbymvVDWZIXws7Y/4TpYTqMUt503UZAwm1lJAsdWBAna73NH+33v40Wlt3hVMog33T7quydmtRfpE9yWiB6OcVE0SCie49tWYRen16/SYcDBLMotIcRiQK30g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300119; c=relaxed/simple; bh=zQQDabQxX/Mj3pMOdIretiHOgmTgNC9y9Xg7vn5SY9I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=E0CyD6SSIk28MeiSuOR4NsSF9qJLjWhUrrM7KJb4DlMoGQFUQioWcsEisU96tl/+WEA4O7qEsz71XrgRr0kRaF7HVWpS2NRG1L+yrrhx9jCQVGbRNOPpdOIaEyO0rrucIc1Fp+uGvQREjbh7IdarKeY4SFUfxwK/noldRsXGjm0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t7YnQmEL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="t7YnQmEL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8C93C2BC87; Sat, 28 Feb 2026 17:35:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300118; bh=zQQDabQxX/Mj3pMOdIretiHOgmTgNC9y9Xg7vn5SY9I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=t7YnQmELM5f+3HHzS+ijzPXYcSlwqzuuw5BkrFj2FbmJ1e/FowVqrGVpspp674s/Y IOMIJvBIkw6v5ku7Lq8fPi5Z0d2EZSSohoEx4JadfxNxRUOH0uPFQ2z4PP8ASUtC+q h/GmGFHIBtB7sPE3t9hYiGGASpPrmX0EHhO9VjGYRsENDvCrA+1x6vB74L74aBAXd/ oe30/AcXJm28Gn6idNqHoexHvGDV4Bp5TG0whwDJfrvqzoiVFevNs4aHV03XEH1xuM nQ0tWFh8sIzxcPFgHy4oheQ707EPdwKbygqHsJ14rA6jI7AZcq/NaeKcTXuORUBiX8 oFSnAscRAqRGw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jing Zhou , Charlene Liu , Wenjing Liu , Roman Li , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 135/844] drm/amd/display: Correct FIXED_VS Link Rate Toggle Condition Date: Sat, 28 Feb 2026 12:20:48 -0500 Message-ID: <20260228173244.1509663-136-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jing Zhou [ Upstream commit 531fe6e0fee85a1bdb5b8223a706fff654ed0a61 ] [WHY&HOW] The condition is only perform toggle if FIXED_VS LTTPR reports no IEEE OUI. The literal "\x0,\x0,\x0" contains commas changes the bytes being compared to {0x00,0x2C,0X00}. The correct literal should be "\x00\x00\x00" without commas. Reviewed-by: Charlene Liu Reviewed-by: Wenjing Liu Signed-off-by: Jing Zhou Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training= _fixed_vs_pe_retimer.c b/drivers/gpu/drm/amd/display/dc/link/protocols/link= _dp_training_fixed_vs_pe_retimer.c index ce174ce5579c0..6a7c4a59ff4c7 100644 --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training_fixed_= vs_pe_retimer.c +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training_fixed_= vs_pe_retimer.c @@ -271,7 +271,7 @@ enum link_training_result dp_perform_fixed_vs_pe_traini= ng_sequence( rate =3D get_dpcd_link_rate(<_settings->link_settings); =20 // Only perform toggle if FIXED_VS LTTPR reports no IEEE OUI - if (memcmp("\x0,\x0,\x0", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], = 3) =3D=3D 0) { + if (memcmp("\x00\x00\x00", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0],= 3) =3D=3D 0) { /* Vendor specific: Toggle link rate */ toggle_rate =3D (rate =3D=3D 0x6) ? 0xA : 0x6; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C8344DB579; Sat, 28 Feb 2026 17:35:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300120; cv=none; b=TMzxhyajFaNCDo5hw0qIBFJGCW7LnvTlhOZ3K183fXQRAQhKcL4RaPuyUl9/I8XelhEsrVVZWQReP4Lkiglxdsp7kOz8p0vjraPsYfIhbyEj43XRYaMymS7QzRXo0cgrQ88RD5+mhnSjdlcojT+iSHjwovnWmmY7NS31poUSiH8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300120; c=relaxed/simple; bh=d9/1ShxoaaOuUBmvZ5NReuYcP1/oe01v6p1gTJbqV84=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CnUM+75p1Up7bf1ZL8M61PNDEfhfSdXwG9f5gozvhornAjugsOmnoNeG+XgyvmXxPSTa21v/ZN7KaP5DucO6liBHLib5jj4gGMqy4USPFqmTZJTYk/gZk9L9kDLlnmGgMw/DDvoyxG+vjnUFC77N61gT7FD/GKWC0N/7HQcXlmA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EDzdgcMT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EDzdgcMT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19507C19424; Sat, 28 Feb 2026 17:35:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300119; bh=d9/1ShxoaaOuUBmvZ5NReuYcP1/oe01v6p1gTJbqV84=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EDzdgcMTYGCWj3vh1sGRZxJDaNjAGVpk2nZwdarOHiH5/3aNikZ2yTN93HjuONJEk yfiJraEZNuZQ2OLQe41Uqrr8xjKudzPaqGLCFD6g4ysBtPWanlQnAWn4XsVuaME/FE B15COp+QrHDCkX+S+2Pd0DfVUEq7j6Oajl1SwIdZvWzs4Y6oQA0XXgntC/7Kn9n6AC FdlLRl+gsxlak7NBPPSi5FO1PeMsehGJV5gpktMIfdoUKKi5KycVOJzCZe+kZ6KYi2 Uyk33N10tez1gu8ON1nLUkieK4iYZG8bPuTTNbaoA/wN0dWyquJQW1eAP+agq00qn0 +EV+2N5ywS3dw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dillon Varone , Sridevi Arvindekar , Roman Li , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 136/844] drm/amd/display: Guard FAMS2 configuration updates Date: Sat, 28 Feb 2026 12:20:49 -0500 Message-ID: <20260228173244.1509663-137-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dillon Varone [ Upstream commit 7dedb906cdfec100061daf41f8e54266e975987d ] [WHY&HOW] If DMCUB is not initialized or FAMS2 is not supported, the interface should not be called. Reviewed-by: Sridevi Arvindekar Signed-off-by: Dillon Varone Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c b/dr= ivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c index 5ffe41a96864a..12ce3789f5130 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c @@ -1774,7 +1774,8 @@ void dcn401_unblank_stream(struct pipe_ctx *pipe_ctx, void dcn401_hardware_release(struct dc *dc) { if (!dc->debug.disable_force_pstate_allow_on_hw_release) { - dc_dmub_srv_fams2_update_config(dc, dc->current_state, false); + if (dc->ctx->dmub_srv && dc->debug.fams2_config.bits.enable) + dc_dmub_srv_fams2_update_config(dc, dc->current_state, false); =20 /* If pstate unsupported, or still supported * by firmware, force it supported by dcn @@ -1794,7 +1795,9 @@ void dcn401_hardware_release(struct dc *dc) dc->clk_mgr->clks.p_state_change_support =3D false; dc->clk_mgr->funcs->update_clocks(dc->clk_mgr, dc->current_state, true); } - dc_dmub_srv_fams2_update_config(dc, dc->current_state, false); + + if (dc->ctx->dmub_srv && dc->debug.fams2_config.bits.enable) + dc_dmub_srv_fams2_update_config(dc, dc->current_state, false); } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E55B24DBD75; Sat, 28 Feb 2026 17:35:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300121; cv=none; b=W9h8+60yyEGRm270HkbZw4zmHD4DPE2uOrV1Y+DaoC8FsIf2VhcLxSoH7KAoHiP+TN2fNs5epyAAVeXPG1qJrC5a8swU1sJ3D5YQ3lZAtkFAKZQjbfdc2J8gLJdC8860o3QyZtcjtCenfP6p6bOUdOXZVNA2LCFQLkeS7N8i0Fc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300121; c=relaxed/simple; bh=r4mqs94xvraAjLpwrzacbIkmYCZB0A7V9JtP283uhv4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ULhq+A+phdytZdt1awUtsMFOl6ilviuV5vDQPB6QVfKDZV4Mw3kST8FaDLEDPzTjd1y8WmOAln3iu5enYXr9CzgQT5kW6fO//TrPvEn0PSmsUFhbvoOIdBP/l4G/GPMJeMHG2OojjJrtUVpM8Y5Vre0e4bZLdBhjpbgegdbgBQY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pPXweO4p; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pPXweO4p" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33268C19424; Sat, 28 Feb 2026 17:35:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300120; bh=r4mqs94xvraAjLpwrzacbIkmYCZB0A7V9JtP283uhv4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pPXweO4pJR3vB3Ha6eRIEP8rpD6OeGfm4TZtC1ft9/Ubn5IyPowujNVBZlspmLn4Y MEIGAh8LlFXXc1SnbNNGrQ52Hs1bZ9pLKDnKDUnJaVoMCJPcquwDhRPPgrxEGWpNAW CR78bXUzBx1vIdbkLZ99+4EVxUwIFbOCW03098avyS4XStoUMyOln7XgVzbFnyhOEG 2gL1SQ1XCjVSIaN/+t58JBar3uhjByXknPEey61KHd7FxuG9hoEKfjraIMiw4+g8A5 wMUQOKPvyQleNYowWAi3/JdMmkU+i1IpWdpAHzmxNRtlXo5gMFnQKd+S6sx0kBYK4U Zl3naI0gmXg5g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Val Packett , Douglas Anderson , Sasha Levin Subject: [PATCH 6.19 137/844] drm/panel-edp: Add AUO B140QAX01.H panel Date: Sat, 28 Feb 2026 12:20:50 -0500 Message-ID: <20260228173244.1509663-138-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Val Packett [ Upstream commit bcd752c706c357229185a330ab450b86236d9031 ] A 14-inch 2560x1600 60Hz matte touch panel, found on a Dell Latitude 7455 laptop (second-source with BOE NE14QDM), according to online sources it's also found on the Latitude 7440 and some ASUS models. Raw EDID dump: 00 ff ff ff ff ff ff 00 06 af a4 0b 00 00 00 00 00 20 01 04 a5 1e 13 78 03 ad f5 a8 54 47 9c 24 0e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 f0 68 00 a0 a0 40 2e 60 30 20 35 00 2d bc 10 00 00 1a f3 53 00 a0 a0 40 2e 60 30 20 35 00 2d bc 10 00 00 1a 00 00 00 fe 00 36 39 52 31 57 80 42 31 34 30 51 41 58 00 00 00 00 00 02 41 21 a8 00 01 00 00 1a 41 0a 20 20 00 a1 Don't have datasheet access, but the same timing as for other panels from the same manufacturer works fine. Signed-off-by: Val Packett [dianders: Moved to the right location in the table] Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251206173739.2222940-1-val@packett.cool Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/panel/panel-edp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/pane= l-edp.c index 2c35970377431..85dd3f4cb8e1c 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -1880,6 +1880,7 @@ static const struct panel_delay delay_80_500_e50_d50 = =3D { */ static const struct edp_panel_entry edp_panels[] =3D { EDP_PANEL_ENTRY('A', 'U', 'O', 0x04a4, &delay_200_500_e50, "B122UAN01.0"), + EDP_PANEL_ENTRY('A', 'U', 'O', 0x0ba4, &delay_200_500_e50, "B140QAX01.H"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x105c, &delay_200_500_e50, "B116XTN01.0"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x1062, &delay_200_500_e50, "B120XAN01.0"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x125c, &delay_200_500_e50, "Unknown"), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D43E44DBD98; Sat, 28 Feb 2026 17:35:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300121; cv=none; b=MbdSCY9g5NOAzqSMugkgK9bRx032WaK/sjmhZXdAFMmgjf0CZ5uI8WZ+PYHlcT2QPiD1KaocKu6NmBteEVU9zTEY274AB1XwCR+BgLquYHQAoIeNGktgmFOfe6rhKHLysWJ/SYj6uuhowtpNH//WTi5Jt2QoSksQqlJNT6qih2U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300121; c=relaxed/simple; bh=UEHRO0JjcXGWwUefm/KvjqDR+eXCgmSQLiASBuhYmis=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FzP7yZVnGlMc7/9e/mogcHWsxvT3rXOyMBTK63rwl5QJG92aT5Og15XYBoekxCUWr+H6Gal7eLbgAJ1b5MoPzrNOBewwy0b5wNtuBTnxuDbt0syceDrwvI3Net7BysaFtzlRnj7IpZDrmAkbZF/+oXz0SoBTZSNMehElLgVqGfo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NAkvOYW9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NAkvOYW9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F268C116D0; Sat, 28 Feb 2026 17:35:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300121; bh=UEHRO0JjcXGWwUefm/KvjqDR+eXCgmSQLiASBuhYmis=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NAkvOYW9BVpxJsNy5dOKl471bZ52bsPYyQ9pw90Q9aZREepR653IVJKlNF1s8SWP1 T6cL0z5A9DpXIya8GrmZPIBpZjl0cBW5Yb2bnYnOZSKCsM+k0H5K9lP6otu/NnFX7U RUGa1hYiCQRIWwKV+0H7sOZS/n3aGtQs+mqDtelBeiR2OHnhAL4WxgDieAtFacuvFc MnkeB2royKo3ajKCbo78Qdu4YT8xGBavlpbx1v+xJv9beyemzFVFybN7UCO5tOE6Pz hvBgq+WJas76xY0b37uHToBvga8P/ZpQIupsEC2jl3eHbo0YifLAOYXNpcetVxCHj4 Frp71ilY68clw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Philip Yang , Harish Kasiviswanathan , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 138/844] drm/amdkfd: Handle GPU reset and drain retry fault race Date: Sat, 28 Feb 2026 12:20:51 -0500 Message-ID: <20260228173244.1509663-139-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Philip Yang [ Upstream commit 5b57c3c3f22336e8fd5edb7f0fef3c7823f8eac1 ] Only check and drain IH1 ring if CAM is not enabled. If GPU is under reset, don't access IH to drain retry fault. Signed-off-by: Philip Yang Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amd= kfd/kfd_svm.c index 79ea138897fcf..a10cf8650c92b 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c @@ -33,6 +33,7 @@ #include "amdgpu_hmm.h" #include "amdgpu.h" #include "amdgpu_xgmi.h" +#include "amdgpu_reset.h" #include "kfd_priv.h" #include "kfd_svm.h" #include "kfd_migrate.h" @@ -2349,6 +2350,9 @@ static void svm_range_drain_retry_fault(struct svm_ra= nge_list *svms) =20 pr_debug("drain retry fault gpu %d svms %p\n", i, svms); =20 + if (!down_read_trylock(&pdd->dev->adev->reset_domain->sem)) + continue; + amdgpu_ih_wait_on_checkpoint_process_ts(pdd->dev->adev, pdd->dev->adev->irq.retry_cam_enabled ? &pdd->dev->adev->irq.ih : @@ -2358,6 +2362,7 @@ static void svm_range_drain_retry_fault(struct svm_ra= nge_list *svms) amdgpu_ih_wait_on_checkpoint_process_ts(pdd->dev->adev, &pdd->dev->adev->irq.ih_soft); =20 + up_read(&pdd->dev->adev->reset_domain->sem); =20 pr_debug("drain retry fault gpu %d svms 0x%p done\n", i, svms); } @@ -2541,7 +2546,7 @@ svm_range_unmap_from_cpu(struct mm_struct *mm, struct= svm_range *prange, adev =3D pdd->dev->adev; =20 /* Check and drain ih1 ring if cam not available */ - if (adev->irq.ih1.ring_size) { + if (!adev->irq.retry_cam_enabled && adev->irq.ih1.ring_size) { ih =3D &adev->irq.ih1; checkpoint_wptr =3D amdgpu_ih_get_wptr(adev, ih); if (ih->rptr !=3D checkpoint_wptr) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A96534DC539; Sat, 28 Feb 2026 17:35:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300122; cv=none; b=ntF9K2zvJPlVrb9Ao8ixaScjWG7C9h16K0swy9nKqFy2OXLVmPpdvB2gNmRARYFq8ST/AVhWa6SCOB6SzgsecWb2dJIw28FYoTLNH14NeuhO/giUTr+oA56U0J1Udq8BCfH7xBj7ksV8x/zBemn2werEh0HpTcJXe3zPy+/ydX0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300122; c=relaxed/simple; bh=ioaz2LX6Riu+loomCejEGpzXL8egcwvTRFq/OvGpw7s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VXvzeAzisiEFuwKmBs3/NRV6pwhLHeoaN2Bi9NF/FqFK7sxoxwg9nUN5CcWVyj/75QSH4Ko+9U8ECdK2q/pcBiH7799SUGvB6GUywfmXCMAiSO8VwjPizTPSk4AnpKPB3vnOaEIBmOG0k2Rn30Q9s49b7ekxiKKW909xhq4Z4VM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GWj7djLj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GWj7djLj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3A83C19424; Sat, 28 Feb 2026 17:35:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300122; bh=ioaz2LX6Riu+loomCejEGpzXL8egcwvTRFq/OvGpw7s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GWj7djLjtA33okc1Ulzj5T5kPI5pyQ68/n+OtuujSYC8rmXA/ZKd4Gb4U+sLDUFYN xp4tYZ/KHGclwgvW9w2FgscdKkGuR4OP2sVN9llfvYTCV3xTHd/hmqhc11G6jbjMfs 9QlaV+yeThqrC3D4Xu2e3jkZREzJYDFiC05AfN/emx8M1FV3hGLfeCMg0cEQynVEaf luo1QTQkrZPdl95jdkB+Nxq1xwSnvoq7li1nO1cUC1VH7gvkm0cByWH0vM+30Q37LF 2HPjv0vRxFCMmuP3wlklWxwaRPeIY6wrF+ZrWxbSpp/cIhAfniyVkuJV6D/afG13yE MU3VK4+96hpAQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jonathan Marek , Mark Brown , Sasha Levin Subject: [PATCH 6.19 139/844] spi-geni-qcom: initialize mode related registers to 0 Date: Sat, 28 Feb 2026 12:20:52 -0500 Message-ID: <20260228173244.1509663-140-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jonathan Marek [ Upstream commit 739062a9f1e9a77a9687c8fd30f8e5dd12ec70be ] setup_fifo_params assumes these will be zero, it won't write these registers if the initial mode is zero. Signed-off-by: Jonathan Marek Link: https://patch.msgid.link/20251120211204.24078-4-jonathan@marek.ca Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spi-geni-qcom.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c index a0d8d3425c6c6..9e9953469b3a0 100644 --- a/drivers/spi/spi-geni-qcom.c +++ b/drivers/spi/spi-geni-qcom.c @@ -724,6 +724,12 @@ static int spi_geni_init(struct spi_geni_master *mas) case 0: mas->cur_xfer_mode =3D GENI_SE_FIFO; geni_se_select_mode(se, GENI_SE_FIFO); + /* setup_fifo_params assumes that these registers start with a zero valu= e */ + writel(0, se->base + SE_SPI_LOOPBACK); + writel(0, se->base + SE_SPI_DEMUX_SEL); + writel(0, se->base + SE_SPI_CPHA); + writel(0, se->base + SE_SPI_CPOL); + writel(0, se->base + SE_SPI_DEMUX_OUTPUT_INV); ret =3D 0; break; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9061E47CC62; Sat, 28 Feb 2026 17:35:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300123; cv=none; b=scHHG4ZWhO57M72QAs0xPnPFPrsUMWg9yTmIIcJWnpsnR3ONEyhEzvLnMTo3rdsMR8UcO4hXQSMdExSQwzSb9CzOUEWgz4afwYNF1tUkh4yYTrcbJSL1k8tsaq4RQ/tV54gFPSRsORflCNyvh+9Y7FFwB6FPrGPn9m2Gby21j9o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300123; c=relaxed/simple; bh=bzZk1TOgUSd5fSDGays6IuFF1nr/j71MGP5pJ4t2xL0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tEASWTnJYi8N5/42lgJgrb16/j7l2ffU4rkKMnPsqMSmNhDOebTEMbLC54NXPg/ejjA7a9O84Xg+ljowmPYva45R2A4b8j68KinGCIqC0X8mJX3/WEJNC8C/al3C2Iety6ObVCKP048UA8KmFtYX2Are6ghnLYaiEHA7cY+Gi/c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OgZJpFRb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OgZJpFRb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D175CC2BC87; Sat, 28 Feb 2026 17:35:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300123; bh=bzZk1TOgUSd5fSDGays6IuFF1nr/j71MGP5pJ4t2xL0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OgZJpFRbeZ4ACteRn5mvxrC2dZK6eqQltbYOGuDKJmelh1xjsnTK7fyYhJyNHHAa5 Ps8kU12yXJ1UXOJ0kqCcdZIK/PJCiKeVVMW/5hJwyIP1p44jtSIue75frtRoXbB9iL kwT8LFxkAIKJq3SQFy9tD3FbkL1IZzs1bc/D9PHSoJnxlHIlqhU4v+BbADSr1GQ9aN barX4Vq/6mp4RcC0FJo5FQh1a2YsA+YMmqcTZ564hENSc8DIV5/K3biYYOw/asNwMy 5qgisrVJG6GRB+J0SlQizZXKPBQxh6k9xK6wGi1t/38LPFg2s4/Q6I/GCas0JbVskW RHf+faHakgJIA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jonathan Marek , Mark Brown , Sasha Levin Subject: [PATCH 6.19 140/844] spi-geni-qcom: use xfer->bits_per_word for can_dma() Date: Sat, 28 Feb 2026 12:20:53 -0500 Message-ID: <20260228173244.1509663-141-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jonathan Marek [ Upstream commit fb2bbe3838728f572485706677590e4fc41eec5c ] mas->cur_bits_per_word may not reflect the value of xfer->bits_per_word when can_dma() is called. Use the right value instead. Signed-off-by: Jonathan Marek Link: https://patch.msgid.link/20251120211204.24078-3-jonathan@marek.ca Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spi-geni-qcom.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c index 9e9953469b3a0..5ab20d7955121 100644 --- a/drivers/spi/spi-geni-qcom.c +++ b/drivers/spi/spi-geni-qcom.c @@ -548,10 +548,10 @@ static u32 get_xfer_len_in_words(struct spi_transfer = *xfer, { u32 len; =20 - if (!(mas->cur_bits_per_word % MIN_WORD_LEN)) - len =3D xfer->len * BITS_PER_BYTE / mas->cur_bits_per_word; + if (!(xfer->bits_per_word % MIN_WORD_LEN)) + len =3D xfer->len * BITS_PER_BYTE / xfer->bits_per_word; else - len =3D xfer->len / (mas->cur_bits_per_word / BITS_PER_BYTE + 1); + len =3D xfer->len / (xfer->bits_per_word / BITS_PER_BYTE + 1); len &=3D TRANS_LEN_MSK; =20 return len; @@ -571,7 +571,7 @@ static bool geni_can_dma(struct spi_controller *ctlr, return true; =20 len =3D get_xfer_len_in_words(xfer, mas); - fifo_size =3D mas->tx_fifo_depth * mas->fifo_width_bits / mas->cur_bits_p= er_word; + fifo_size =3D mas->tx_fifo_depth * mas->fifo_width_bits / xfer->bits_per_= word; =20 if (len > fifo_size) return true; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 62B904DC537; Sat, 28 Feb 2026 17:35:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300124; cv=none; b=BmUYG4Jvh/ObbibneoQ/oaY6mU28Zx4rVdOz/jHKztXTr5p/DPTERFfAlK/2/bmHTyL++jsSRwRY9aEj6rbifyZQa/DCk4aQBEWZQRu9sux1HmMej7okZaGRnEnlQZR/K9WuH0CzPxI4C/3wUF7yY99v0wuzMQ0amdf4ICJ3JgI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300124; c=relaxed/simple; bh=5fvreIE8mUPNC0VdxmGRMolDmw7x/N2lHp1Cli5MCvg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nCBgsYDJS9aM6oU/5ZJJI+8Q5IwuqNihKhx2HX5oT9w1YdN7O7/5uojqvX5UEvUvFrPdduBbxUHkkxwgXmm37mxKg0j6S9eFNumWQZGAplcbSVhaA66MWH9GD/89OdgYDrhJMFbrQaA0Oyry4WvSgDq56uXfR8tFMmpOKyB9PsI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Cps5PGhw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Cps5PGhw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD757C116D0; Sat, 28 Feb 2026 17:35:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300124; bh=5fvreIE8mUPNC0VdxmGRMolDmw7x/N2lHp1Cli5MCvg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Cps5PGhwyomf1bMroOlau3npJRDFlLEnc7K8Lw3ga7jst3JF/+WlZ5ls5mQf+mnEb KVTOAmEtDaCqG0dRIhZV1KObU6vY2OfdX2OCVoTfktdUUVPMUNo8YlzYOOzcnpqZwx J19Yq9eMCeIvBTNVKpRPbO29JlcVl20x3vL+EW7gUFRDgAUBQWqzC8ZMtumIYtnVVH TljxfQW2DzTdrmxqGxfm1m8466NVRQStqvLoD+UhdndSDsBbaUGjrTCLLCbWz5zuCk rcHHbUPwsqCk1Q4u/UCLix3Avp+Penl0Et2fd5/V1BwCd6CH2pqspEIZjFcCX8BGdw Mb/raPxJhgupA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mark Brown , Francesco Dolcini , Sasha Levin Subject: [PATCH 6.19 141/844] spi: cadence-quadspi: Parse DT for flashes with the rest of the DT parsing Date: Sat, 28 Feb 2026 12:20:54 -0500 Message-ID: <20260228173244.1509663-142-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mark Brown [ Upstream commit 9f0736a4e136a6eb61e0cf530ddc18ab6d816ba3 ] The recent refactoring of where runtime PM is enabled done in commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance") made the fact that when we do a pm_runtime_disable() in the error paths of probe() we can trigger a runtime disable which in turn results in duplicate clock disables. This is particularly likely to happen when there is missing or broken DT description for the flashes attached to the controller. Early on in the probe function we do a pm_runtime_get_noresume() since the probe function leaves the device in a powered up state but in the error path we can't assume that PM is enabled so we also manually disable everything, including clocks. This means that when runtime PM is active both it and the probe function release the same reference to the main clock for the IP, triggering warnings from the clock subsystem: [ 8.693719] clk:75:7 already disabled [ 8.693791] WARNING: CPU: 1 PID: 185 at /usr/src/kernel/drivers/clk/clk.= c:1188 clk_core_disable+0xa0/0xb ... [ 8.694261] clk_core_disable+0xa0/0xb4 (P) [ 8.694272] clk_disable+0x38/0x60 [ 8.694283] cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi] [ 8.694309] platform_probe+0x5c/0xa4 Dealing with this issue properly is complicated by the fact that we don't know if runtime PM is active so can't tell if it will disable the clocks or not. We can, however, sidestep the issue for the flash descriptions by moving their parsing to when we parse the controller properties which also save us doing a bunch of setup which can never be used so let's do that. Reported-by: Francesco Dolcini Closes: https://lore.kernel.org/r/20251201072844.GA6785@francesco-nb Signed-off-by: Mark Brown Link: https://patch.msgid.link/20251204-spi-cadence-qspi-runtime-pm-imbalan= ce-v2-1-10af9115d531@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spi-cadence-quadspi.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-qu= adspi.c index b9a560c75c5cd..b1cf182d65665 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -1844,6 +1844,12 @@ static int cqspi_probe(struct platform_device *pdev) return -ENODEV; } =20 + ret =3D cqspi_setup_flash(cqspi); + if (ret) { + dev_err(dev, "failed to setup flash parameters %d\n", ret); + return ret; + } + /* Obtain QSPI clock. */ cqspi->clk =3D devm_clk_get(dev, NULL); if (IS_ERR(cqspi->clk)) { @@ -1987,12 +1993,6 @@ static int cqspi_probe(struct platform_device *pdev) pm_runtime_get_noresume(dev); } =20 - ret =3D cqspi_setup_flash(cqspi); - if (ret) { - dev_err(dev, "failed to setup flash parameters %d\n", ret); - goto probe_setup_failed; - } - host->num_chipselect =3D cqspi->num_chipselect; =20 if (ddata && (ddata->quirks & CQSPI_SUPPORT_DEVICE_RESET)) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 806124DD6F0; Sat, 28 Feb 2026 17:35:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300125; cv=none; b=W3KY9B+gANWIces/zdEUUpeUnwGWPKHhJ5GezuW15Jg2tYTLx5CB/QlNV/EYqZJfPNP2SfTFXUpefsTuFRZ2hCcKi83WVkzGyL1vBNEyZw1Iz5P5H1mIKBFvMukDxUOMqDTlYUYtAFjlX+lxqqTlmgEnZMpPfZxvtFY9Upz4UhM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300125; c=relaxed/simple; bh=W8BP5h1dYiVSU+0St47+879EwoKOsmZLFs0bgq2p2TM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iriEenHKollN8aKQ3Z59+uXs5s+aG2OKxFlMkjYFLG3aXIBlyugXkYw+wSq0aaQodV9nUVs8MMKM75TURJ2ONxmrv5Da7GKGMYdzuhgjh+hTjhsPeMFz5cDzXvmk5CKSgyxtSkxyv0okfirWUKBg+/v/sviEjusFQKEk3bsneog= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q3TNGuRm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="q3TNGuRm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89A66C116D0; Sat, 28 Feb 2026 17:35:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300125; bh=W8BP5h1dYiVSU+0St47+879EwoKOsmZLFs0bgq2p2TM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q3TNGuRm1ptd4xAB5PZm2tH441EowlwI6g+3rg5lR3NuhT/GuAvlGAe4IvtK+b3Eg WPCEHfZ03fNa/9Xdk4wevpi/AR10xTSVJRoiVvGRHQkqZHMDSo6z+mBJ7S+rkry7Ak 5qwX9U1PCEabcwJiZdkJeeBWtk393Nta4XKV7DLszK+zPrEo0OHoL3ZHj6Fh5v8hVn fz3rLdGoyaMYoXUCl86j8RofGbhKwOMGdWUkKtFMUOWT+cMYnwoWVe3AEcjN1DSFIt fqZZ4JG4eTRNmy5VdAq9Ghn1WaehKoIdbbLIT7Pq63lSOuDmJjs6YDpZeKYCuFVF+A R0vPSugvZ8NyA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Charlene Liu , Swapnil Patel , Chenyu Chen , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 142/844] drm/amd/display: Fix DP no audio issue Date: Sat, 28 Feb 2026 12:20:55 -0500 Message-ID: <20260228173244.1509663-143-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Charlene Liu [ Upstream commit bf5e396957acafd46003318965500914d5f4edfa ] [why] need to enable APG_CLOCK_ENABLE enable first also need to wake up az from D3 before access az block Reviewed-by: Swapnil Patel Signed-off-by: Charlene Liu Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c b/dr= ivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c index 12ce3789f5130..e1f5b1a34cde8 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c @@ -297,7 +297,6 @@ void dcn401_init_hw(struct dc *dc) } } } - for (i =3D 0; i < res_pool->audio_count; i++) { struct audio *audio =3D res_pool->audios[i]; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CFBE4E376A; Sat, 28 Feb 2026 17:35:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300126; cv=none; b=iibPuDbHb1EQclR9F+4lT3WbrRqs54Xpw/c2T6CRocrO6i2tOikbQHlMiRJLOEVgxkwfJn3iuzNyK4UIWwTZArHK20/WSo46Mrydv4xSMSWhNdUGBjVNsCCoHs21mbiPdQ1WDkm1JEKXOW4OkPVa9oe/4b2oIdIWs12oqS8auIU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300126; c=relaxed/simple; bh=xeZh3cF455He9JeR56322hkv854L2QK5u/JbF7eXb38=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YXDUozOMgK7lc0/Qhk15MtNVewfHrl62wDkbr0M9ph8aeaoECK/pKZ1uYnBgQZmCQ6MnZKwIbNhn2y6UITHWi0JXXIxCUqz0Qn66RYooEIQT9/8xTa/DteSHiWLcje5n5K3YJw3U+UboJkZMJZtSZw1ULxsV+6BTlze4iY8zzXc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pOBK4lRN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pOBK4lRN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9C73C116D0; Sat, 28 Feb 2026 17:35:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300126; bh=xeZh3cF455He9JeR56322hkv854L2QK5u/JbF7eXb38=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pOBK4lRNzxH74jIjbJkY+6zol57W17DZYOOlnw4ZKdGfOVwiE6XBojzv2/l41fW2f mJahhwTZRt137MWegFItTvyu5cYbuNukwJF6wLOpmV62H/OyCeCmfxYVHMZMxnB0sB xItHoqYgPlZzsxTh4MTWOM2AwUQDf6yCwYpCdhnmuNSS3xGRNDBFQwt+jTZ2O3aURX AMy+UsLxr4ok2G+57rTsCyQKqx+3HVtBNWD7ruRXGkfDnMUMH95+2TDpUiG4BniLbT rXsdVSwKRjRbrYoMD0/b9FYaV6TmdSIQamuAvMQRJBOK7fLA6Q0UTEF0+wx6nL+yS/ Z1pl6+Jl+y17w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: LinCheng Ku , PeiChen Huang , Chenyu Chen , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 143/844] drm/amd/display: Add USB-C DP Alt Mode lane limitation in DCN32 Date: Sat, 28 Feb 2026 12:20:56 -0500 Message-ID: <20260228173244.1509663-144-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: LinCheng Ku [ Upstream commit cea573a8e1ed83840a2173d153dd68e172849d44 ] [Why] USB-C DisplayPort Alt Mode with concurrent USB data needs lane count limitation to prevent incorrect 4-lane DP configuration when only 2 lanes are available due to hardware lane sharing between DP and USB3. [How] Query DMUB for Alt Mode status (is_dp_alt_disable, is_usb, is_dp4) in dcn32_link_encoder_get_max_link_cap() and cap DP to 2 lanes when USB is active on USB-C port. Added inline documentation explaining the USB-C lane sharing constraint. Reviewed-by: PeiChen Huang Signed-off-by: LinCheng Ku Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../display/dc/dio/dcn32/dcn32_dio_link_encoder.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dio/dcn32/dcn32_dio_link_encode= r.c b/drivers/gpu/drm/amd/display/dc/dio/dcn32/dcn32_dio_link_encoder.c index 06907e8a4eda1..ddc736af776c9 100644 --- a/drivers/gpu/drm/amd/display/dc/dio/dcn32/dcn32_dio_link_encoder.c +++ b/drivers/gpu/drm/amd/display/dc/dio/dcn32/dcn32_dio_link_encoder.c @@ -188,9 +188,18 @@ void dcn32_link_encoder_get_max_link_cap(struct link_e= ncoder *enc, if (!query_dp_alt_from_dmub(enc, &cmd)) return; =20 - if (cmd.query_dp_alt.data.is_usb && - cmd.query_dp_alt.data.is_dp4 =3D=3D 0) - link_settings->lane_count =3D MIN(LANE_COUNT_TWO, link_settings->lane_co= unt); + /* + * USB-C DisplayPort Alt Mode lane count limitation logic: + * When USB and DP share the same USB-C connector, hardware must allocate + * some lanes for USB data, limiting DP to maximum 2 lanes instead of 4. + * This ensures USB functionality remains available while DP is active. + */ + if (cmd.query_dp_alt.data.is_dp_alt_disable =3D=3D 0 && + cmd.query_dp_alt.data.is_usb && + cmd.query_dp_alt.data.is_dp4 =3D=3D 0) { + link_settings->lane_count =3D + MIN(LANE_COUNT_TWO, link_settings->lane_count); + } } =20 =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 115024E3785; Sat, 28 Feb 2026 17:35:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300128; cv=none; b=tuE2pFYClEaubA8pCW9KglmzTwF1OfTtVugRretlC8DJrWzQodafwbjmo9vTGT6VKjaf0kUoD68KuWdRh5RCWM86xWjjf9z/WHvzTVIl40FRSj0kCt326/Z+bOzJpE6dor5MN5I+MBba5nrLED0kJ6iLI1BNxkkJQVI2cDBBM8Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300128; c=relaxed/simple; bh=J6Mc6FQMD3ssfnVYyVPA+GPhArv1SfAYBOtYKv2Ql/0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pUqybuVzGD2Qtg7tFiiWBlHynOJ4zbaqZntmbi6nZ1B2Yeo6UkJ3ZbQk5RXISuWrpCkh/ldwZxhDGkbNR9RgIS9AIx4M8lwq1LoPbMg5iDCNT7yS+g1nIpgvnB0K7GxUTFTU5DrPxVviGpYUklRz2w1re5oLmNim0/ET+XIQa/U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kbJklaLt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kbJklaLt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C356CC19423; Sat, 28 Feb 2026 17:35:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300127; bh=J6Mc6FQMD3ssfnVYyVPA+GPhArv1SfAYBOtYKv2Ql/0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kbJklaLtHhfHQvbsl8tLNRcYSXN+nJypKk/MmNjCQ0Uy8MUlIln2opYVYLDzo0r5g E+tokjEVS0giTV1gaCL4NOm1HpTwI07ceZK0BGguPxW/GsqZYsOqjsNy29o+zT07jn FlozZz/HdBcPAkOPkEf3eKzu1+1ZUSR7BP3I3r8jezPCBjNDWXku9puK0aAqZ9YH+E YMDdn9+QDzkMEhvvHizgiNPDawoxMAcpPLyysiVnr+Fi1LU2LE5G7413s5oZIxUTFQ N/GjbbyeYDwOBDyq4DuunpbahTsPvTuiGOJBFlSOMa7RCwyG1o9stt1SubdIAKqMfx G+Rj2PxtEWALg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peichen Huang , Wenjing Liu , Chenyu Chen , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 144/844] drm/amd/display: Don't disable DPCD mst_en if sink connected Date: Sat, 28 Feb 2026 12:20:57 -0500 Message-ID: <20260228173244.1509663-145-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peichen Huang [ Upstream commit 9aeb31b2456452257ad1ff7ec566f21bab1f3e8a ] [WHY] User may connect mst dock with multi monitors and do quick unplug and plug in one of the monitor. This operatioin may create CSN from dock to display driver. Then display driver would disable and then enable mst link and also disable/enable DPCD mst_en bit in dock RX. However, when mst_en bit being disabled, if dock has another CSN message to transmit then the message would be removed because of the disabling of mst_en. In this case, the message is missing and it ends up no display in the replugged monitor. [HOW] Don't disable mst_en bit when link still has sink connected. Reviewed-by: Wenjing Liu Signed-off-by: Peichen Huang Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c b/drivers/gpu/= drm/amd/display/dc/link/link_dpms.c index 770c9cd128ae8..a36762915943b 100644 --- a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c +++ b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c @@ -1931,7 +1931,7 @@ static void disable_link_dp(struct dc_link *link, link->dc->hwss.edp_power_control(link, false); } =20 - if (signal =3D=3D SIGNAL_TYPE_DISPLAY_PORT_MST) + if (signal =3D=3D SIGNAL_TYPE_DISPLAY_PORT_MST && link->sink_count =3D=3D= 0) /* set the sink to SST mode after disabling the link */ enable_mst_on_sink(link, false); =20 @@ -2082,7 +2082,12 @@ static enum dc_status enable_link_dp(struct dc_state= *state, pipe_ctx->stream->signal =3D=3D SIGNAL_TYPE_DISPLAY_PORT && link->dc->debug.set_mst_en_for_sst) { enable_mst_on_sink(link, true); + } else if (link->dpcd_caps.is_mst_capable && + pipe_ctx->stream->signal =3D=3D SIGNAL_TYPE_DISPLAY_PORT) { + /* disable mst on sink */ + enable_mst_on_sink(link, false); } + if (pipe_ctx->stream->signal =3D=3D SIGNAL_TYPE_EDP) { /*in case it is not on*/ if (!link->dc->config.edp_no_power_sequencing) @@ -2380,9 +2385,9 @@ void link_set_dpms_off(struct pipe_ctx *pipe_ctx) if (pipe_ctx->stream->sink) { if (pipe_ctx->stream->sink->sink_signal !=3D SIGNAL_TYPE_VIRTUAL && pipe_ctx->stream->sink->sink_signal !=3D SIGNAL_TYPE_NONE) { - DC_LOG_DC("%s pipe_ctx dispname=3D%s signal=3D%x link=3D%d\n", __func__, + DC_LOG_DC("%s pipe_ctx dispname=3D%s signal=3D%x link=3D%d sink_count= =3D%d\n", __func__, pipe_ctx->stream->sink->edid_caps.display_name, - pipe_ctx->stream->signal, link->link_index); + pipe_ctx->stream->signal, link->link_index, link->sink_count); } } =20 @@ -2496,10 +2501,11 @@ void link_set_dpms_on( if (pipe_ctx->stream->sink) { if (pipe_ctx->stream->sink->sink_signal !=3D SIGNAL_TYPE_VIRTUAL && pipe_ctx->stream->sink->sink_signal !=3D SIGNAL_TYPE_NONE) { - DC_LOG_DC("%s pipe_ctx dispname=3D%s signal=3D%x link=3D%d\n", __func__, + DC_LOG_DC("%s pipe_ctx dispname=3D%s signal=3D%x link=3D%d sink_count= =3D%d\n", __func__, pipe_ctx->stream->sink->edid_caps.display_name, pipe_ctx->stream->signal, - link->link_index); + link->link_index, + link->sink_count); } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB9204E3797; Sat, 28 Feb 2026 17:35:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300129; cv=none; b=b7Jw6bVwoiRIL0KwA+VLTv3g3VjyQTAWiThTYyKqUHV9NUaFAd3YQATDvg+vB3VN3qqA0+ijW5Wh4bg9DZ9luDokr3Mm2alUEml+0x79etIwFzhKx6Btw132WUKnYbRRHa+HN3JK1+n5KvJk0r/iPlkya1Yca7+BrcN0f7DNCEo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300129; c=relaxed/simple; bh=iIt6d5bJBWv/HXppUH7hgW+elfsL6jgbAZ6J2R5Bz/A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BPGWNH41c4oMBOKdY/zVgcDHuxgWgd9YbKdZy88Me8QH8qeL8OSYd0hsZPu/iVFIfKrYyXiKcRpbbXWWWtL/J7VJvupuundW3UM+qOa5fmvTFjFnWDi60vJSsiGepd6xZf2iane/Va2wA+o7onttKwa6OftYM88a88yzAVM2W1Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lbq6Ihyo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lbq6Ihyo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2227C116D0; Sat, 28 Feb 2026 17:35:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300128; bh=iIt6d5bJBWv/HXppUH7hgW+elfsL6jgbAZ6J2R5Bz/A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lbq6Ihyo/DbmQ+SJIhkg2jsBvZxXZY6+XNGo9rBlRihmrSw0WQnKrTCscJcUMRbB8 HOm5ZqahRIQawG069ppAQp+IRj0PCkSf4v7NZcWVCfewyRlikEXBU3KjqxKKvBZLQx E4nM4iw/1ez6PvkF6XdX7MG4I0F3Rv4zXSXmUK3LvVKLk6hUBM378Nosl85Vm7zMO8 udjL4s/ujwXGH/6mlc1/0Ew4FISP5x8vFNLMCSyfG/lGm8oyGq0Crc5h4MDOGA1hcg I5uILN4P50BLyHOBbaNagMVUyuikCL37IQwopWglNRKY5uPntgIfQe/7QMOlbsm2MN wTR4E40ZsBbdw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Ujfalusi , Seppo Ingalsuo , Ranjani Sridharan , Bard Liao , Kai Vehmanen , Mark Brown , Sasha Levin Subject: [PATCH 6.19 145/844] ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET Date: Sat, 28 Feb 2026 12:20:58 -0500 Message-ID: <20260228173244.1509663-146-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Ujfalusi [ Upstream commit d96cb0b86d6e8bbbbfa425771606f6c1aebc318e ] There are message types when we would need to send a payload along with the LARGE_CONFIG_GET message to provide information to the firmware on what data is requested. Such cases are the ALSA Kcontrol related messages when the high level param_id tells only the type of the control, but the ID/index of the exact control is specified in the payload area. The caller must place the payload for TX before calling the set_get_data() and this payload will be sent alongside with the message to the firmware. The data area will be overwritten by the received data from firmware. Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-7-peter.ujfalusi@linux.i= ntel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/sof/ipc4.c | 44 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 42 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/ipc4.c b/sound/soc/sof/ipc4.c index a4a090e6724a6..20d723f48fff0 100644 --- a/sound/soc/sof/ipc4.c +++ b/sound/soc/sof/ipc4.c @@ -15,6 +15,7 @@ #include "sof-audio.h" #include "ipc4-fw-reg.h" #include "ipc4-priv.h" +#include "ipc4-topology.h" #include "ipc4-telemetry.h" #include "ops.h" =20 @@ -433,6 +434,23 @@ static int sof_ipc4_tx_msg(struct snd_sof_dev *sdev, v= oid *msg_data, size_t msg_ return ret; } =20 +static bool sof_ipc4_tx_payload_for_get_data(struct sof_ipc4_msg *tx) +{ + /* + * Messages that require TX payload with LARGE_CONFIG_GET. + * The TX payload is placed into the IPC message data section by caller, + * which needs to be copied to temporary buffer since the received data + * will overwrite it. + */ + switch (tx->extension & SOF_IPC4_MOD_EXT_MSG_PARAM_ID_MASK) { + case SOF_IPC4_MOD_EXT_MSG_PARAM_ID(SOF_IPC4_SWITCH_CONTROL_PARAM_ID): + case SOF_IPC4_MOD_EXT_MSG_PARAM_ID(SOF_IPC4_ENUM_CONTROL_PARAM_ID): + return true; + default: + return false; + } +} + static int sof_ipc4_set_get_data(struct snd_sof_dev *sdev, void *data, size_t payload_bytes, bool set) { @@ -444,6 +462,8 @@ static int sof_ipc4_set_get_data(struct snd_sof_dev *sd= ev, void *data, struct sof_ipc4_msg tx =3D {{ 0 }}; struct sof_ipc4_msg rx =3D {{ 0 }}; size_t remaining =3D payload_bytes; + void *tx_payload_for_get =3D NULL; + size_t tx_data_size =3D 0; size_t offset =3D 0; size_t chunk_size; int ret; @@ -469,10 +489,20 @@ static int sof_ipc4_set_get_data(struct snd_sof_dev *= sdev, void *data, =20 tx.extension |=3D SOF_IPC4_MOD_EXT_MSG_FIRST_BLOCK(1); =20 + if (sof_ipc4_tx_payload_for_get_data(&tx)) { + tx_data_size =3D min(ipc4_msg->data_size, payload_limit); + tx_payload_for_get =3D kmemdup(ipc4_msg->data_ptr, tx_data_size, + GFP_KERNEL); + if (!tx_payload_for_get) + return -ENOMEM; + } + /* ensure the DSP is in D0i0 before sending IPC */ ret =3D snd_sof_dsp_set_power_state(sdev, &target_state); - if (ret < 0) + if (ret < 0) { + kfree(tx_payload_for_get); return ret; + } =20 /* Serialise IPC TX */ mutex_lock(&sdev->ipc->tx_mutex); @@ -506,7 +536,15 @@ static int sof_ipc4_set_get_data(struct snd_sof_dev *s= dev, void *data, rx.data_size =3D chunk_size; rx.data_ptr =3D ipc4_msg->data_ptr + offset; =20 - tx_size =3D 0; + if (tx_payload_for_get) { + tx_size =3D tx_data_size; + tx.data_size =3D tx_size; + tx.data_ptr =3D tx_payload_for_get; + } else { + tx_size =3D 0; + tx.data_size =3D 0; + tx.data_ptr =3D NULL; + } rx_size =3D chunk_size; } =20 @@ -553,6 +591,8 @@ static int sof_ipc4_set_get_data(struct snd_sof_dev *sd= ev, void *data, =20 mutex_unlock(&sdev->ipc->tx_mutex); =20 + kfree(tx_payload_for_get); + return ret; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 09C243EBF04; Sat, 28 Feb 2026 17:35:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300130; cv=none; b=eGYiEspdPFpQBRk30xd+Yio2ijyTy2WVzcPnKaVKoU588L2BD60zE4ecP321oeIBOa49QG/5sF+gU3rh03RX3VNZIJCv5nz7QpbHtKUqS5HZZY39bx9SCMv+V85O6seVt2pKnl0WsnmVrDO/uzI0sULGtIwo3RLxHSejpjRaosU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300130; c=relaxed/simple; bh=t10jh7auqoVFgMP5n7zmmJ4OCC6qifmcq7N6D2hKXAw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jQQJTULXpLnJWVzFHVU7i+8ZWobDhDpVFwHIcr3lG8YwPBlj9Pe3C4BTr8BRyPV4X6j1OhscWRIu4JFKcihfZga6gQTA4gfCwjCnE3mZuenkXZ1HFLJJGZRnF006rvytFyJ4Y8vIQqQHEHFjewZUbsbFFTefMGCLjajFvAzDr5U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X+2VK+l6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X+2VK+l6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DCDAC116D0; Sat, 28 Feb 2026 17:35:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300129; bh=t10jh7auqoVFgMP5n7zmmJ4OCC6qifmcq7N6D2hKXAw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X+2VK+l6mUgtozbDWvCHxPo1sWomFjXyN+CoSsybAvwE2Fq2DKIUaNRph+GWwD+UW fwoiqLH/YHZV/wc2zJhSS3iK5ly3GgVLNc0D1kLZDHGyFjHs4VLGXkb2HLAkBna3uD o4ftCaYLxMjq+kYrnrf2L9ZZL1jgWQuyKYn2jWKb8LPf6UJd8kiyKRv4K7XdbejCV/ MX3YW7FMsF7WJ7pHXIhIbzLx1re8sJolJdVUyAQPMffknfysBV8wKIEW+UH0faji/A PqIQK0fjb9w3OJA+q50uiJWjHcvzda+refk5+zc5T0cwoLfMlsoLIpQSFaHPy9t5oS LMyMDXiWOe2DA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans Verkuil , Mauro Carvalho Chehab , Sasha Levin Subject: [PATCH 6.19 146/844] media: dvb-core: dmxdevfilter must always flush bufs Date: Sat, 28 Feb 2026 12:20:59 -0500 Message-ID: <20260228173244.1509663-147-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans Verkuil [ Upstream commit c4e620eccbef76aa5564ebb295e23d6540e27215 ] Currently the buffers are being filled until full, which works fine for the transport stream, but not when reading sections, those have to be returned to userspace immediately, otherwise dvbv5-scan will just wait forever. Add a 'flush' argument to dvb_vb2_fill_buffer to indicate whether the buffer must be flushed or wait until it is full. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/dvb-core/dmxdev.c | 8 ++++---- drivers/media/dvb-core/dvb_vb2.c | 5 +++-- include/media/dvb_vb2.h | 6 ++++-- 3 files changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxde= v.c index 8c6f5aafda1d6..17184b3674904 100644 --- a/drivers/media/dvb-core/dmxdev.c +++ b/drivers/media/dvb-core/dmxdev.c @@ -397,11 +397,11 @@ static int dvb_dmxdev_section_callback(const u8 *buff= er1, size_t buffer1_len, if (dvb_vb2_is_streaming(&dmxdevfilter->vb2_ctx)) { ret =3D dvb_vb2_fill_buffer(&dmxdevfilter->vb2_ctx, buffer1, buffer1_len, - buffer_flags); + buffer_flags, true); if (ret =3D=3D buffer1_len) ret =3D dvb_vb2_fill_buffer(&dmxdevfilter->vb2_ctx, buffer2, buffer2_len, - buffer_flags); + buffer_flags, true); } else { ret =3D dvb_dmxdev_buffer_write(&dmxdevfilter->buffer, buffer1, buffer1_len); @@ -452,10 +452,10 @@ static int dvb_dmxdev_ts_callback(const u8 *buffer1, = size_t buffer1_len, =20 if (dvb_vb2_is_streaming(ctx)) { ret =3D dvb_vb2_fill_buffer(ctx, buffer1, buffer1_len, - buffer_flags); + buffer_flags, false); if (ret =3D=3D buffer1_len) ret =3D dvb_vb2_fill_buffer(ctx, buffer2, buffer2_len, - buffer_flags); + buffer_flags, false); } else { if (buffer->error) { spin_unlock(&dmxdevfilter->dev->lock); diff --git a/drivers/media/dvb-core/dvb_vb2.c b/drivers/media/dvb-core/dvb_= vb2.c index 29edaaff7a5c9..7444bbc2f24d9 100644 --- a/drivers/media/dvb-core/dvb_vb2.c +++ b/drivers/media/dvb-core/dvb_vb2.c @@ -249,7 +249,8 @@ int dvb_vb2_is_streaming(struct dvb_vb2_ctx *ctx) =20 int dvb_vb2_fill_buffer(struct dvb_vb2_ctx *ctx, const unsigned char *src, int len, - enum dmx_buffer_flags *buffer_flags) + enum dmx_buffer_flags *buffer_flags, + bool flush) { unsigned long flags =3D 0; void *vbuf =3D NULL; @@ -306,7 +307,7 @@ int dvb_vb2_fill_buffer(struct dvb_vb2_ctx *ctx, } } =20 - if (ctx->nonblocking && ctx->buf) { + if (flush && ctx->buf) { vb2_set_plane_payload(&ctx->buf->vb, 0, ll); vb2_buffer_done(&ctx->buf->vb, VB2_BUF_STATE_DONE); list_del(&ctx->buf->list); diff --git a/include/media/dvb_vb2.h b/include/media/dvb_vb2.h index 8cb88452cd6c2..0fbbfc65157e6 100644 --- a/include/media/dvb_vb2.h +++ b/include/media/dvb_vb2.h @@ -124,7 +124,7 @@ static inline int dvb_vb2_release(struct dvb_vb2_ctx *c= tx) return 0; }; #define dvb_vb2_is_streaming(ctx) (0) -#define dvb_vb2_fill_buffer(ctx, file, wait, flags) (0) +#define dvb_vb2_fill_buffer(ctx, file, wait, flags, flush) (0) =20 static inline __poll_t dvb_vb2_poll(struct dvb_vb2_ctx *ctx, struct file *file, @@ -166,10 +166,12 @@ int dvb_vb2_is_streaming(struct dvb_vb2_ctx *ctx); * @buffer_flags: * pointer to buffer flags as defined by &enum dmx_buffer_flags. * can be NULL. + * @flush: flush the buffer, even if it isn't full. */ int dvb_vb2_fill_buffer(struct dvb_vb2_ctx *ctx, const unsigned char *src, int len, - enum dmx_buffer_flags *buffer_flags); + enum dmx_buffer_flags *buffer_flags, + bool flush); =20 /** * dvb_vb2_poll - Wrapper to vb2_core_streamon() for Digital TV --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC1694EA37D; Sat, 28 Feb 2026 17:35:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300130; cv=none; b=BFRBy+aha2vjl3+CknuUU5xzj6QSCfWtNOVht1p/F3Lj8S5CMVGRlIMZQyjzjlk2SAN6b2NHZOZ1Ci/E4UWRtQHrwytVQxZjj+Cf08irKkZIHdZjgpx0OlBwUxS3k3xn9BKS9AMIkF7UkutHmo2o5AvXpEvaKsCDLfcUXUDE2Vg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300130; c=relaxed/simple; bh=w45GHiWjNPrm28f3UB2SitASIEG08+jhtfcseUG+BY4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WFA6JqVEOcsfK7WKflm9g+fL03Y5uYykYdmLoZ7u7+6Qys2fZpF+zTIVQzBLI4YRdQgBHqJm7qLRifzgRVH730SUmMBjkrgCj2/Lo021aUXFdFhYIdyOqtfBY7OL0EbUlooBEpMPed6i5RPlcAw6TGDCeKkd2ALpji71DBYM5Zg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SpDyPkhg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SpDyPkhg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EFC05C19425; Sat, 28 Feb 2026 17:35:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300130; bh=w45GHiWjNPrm28f3UB2SitASIEG08+jhtfcseUG+BY4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SpDyPkhglY9G9ceGXVcEo9ywVO8QpGA5bQmkhJXJtwwZta7TDnAvT0g/5a5AuoWDm gWkeR1SaI6c0nQCA/wQX/b0+y6wM5vAZ//y4/bGaWDhTl8YdQmvyw/HYj16CZETZkd rvOY0IYAikcXAcS6eTsjAnPA7dh2cuTTi5lMOlMkkB9UVY2trb9M2lfepSSKZwAwqI AfVZyqJoFfH8PunYIOo6+qCF00VwWYQM2SjLuNApD0vGQNOkz7aXoE2uXu3Ww6cgVE XhA4MLtFQux5HZQRSt5W4iMgy5d9bqNNhCHeZK7Vd/DvPD+ylAiXylm5nud2DAWAJR 6z75IDYWNwUVA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jan Remmet , Bartosz Golaszewski , Sasha Levin Subject: [PATCH 6.19 147/844] gpio: pca953x: Add support for TCAL6408 TCAL6416 Date: Sat, 28 Feb 2026 12:21:00 -0500 Message-ID: <20260228173244.1509663-148-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jan Remmet [ Upstream commit a30a9cb9bca4296d25f253619883e7013b6be158 ] TCAL6408 and TCAL6416 supports latchable inputs and maskable interrupt. Tested on a TCAL6416, checked datasheets for the TCAL6408. They use the same programming model ad the NXP PCAL64xx, but support a lower supply power (1.08V to 3.6V) compared to PCAL (1.65V to 5.5V) Datasheet: https://www.ti.com/lit/ds/symlink/tcal6408.pdf Datasheet: https://www.ti.com/lit/ds/symlink/tcal6416.pdf Signed-off-by: Jan Remmet Link: https://lore.kernel.org/r/20251216-wip-jremmet-tcal6416rtw-v2-3-6516d= 98a9836@phytec.de Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpio/Kconfig | 4 ++-- drivers/gpio/gpio-pca953x.c | 6 ++++++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index bd185482a7fdf..3439e025ba1c6 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -1193,11 +1193,11 @@ config GPIO_PCA953X =20 8 bits: max7310, max7315, pca6107, pca9534, pca9538, pca9554, pca9556, pca9557, pca9574, tca6408, tca9554, xra1202, - pcal6408, pcal9554b, tca9538 + pcal6408, pcal9554b, tca9538, tcal6408 =20 16 bits: max7312, max7313, pca9535, pca9539, pca9555, pca9575, tca6416, pca6416, pcal6416, pcal9535, pcal9555a, max7318, - tca9539 + tca9539, tcal6416 =20 18 bits: tca6418 =20 diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index f93a3dbb2daaf..52e96cc5f67bb 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -126,6 +126,9 @@ static const struct i2c_device_id pca953x_id[] =3D { { "tca9539", 16 | PCA953X_TYPE | PCA_INT, }, { "tca9554", 8 | PCA953X_TYPE | PCA_INT, }, { "xra1202", 8 | PCA953X_TYPE }, + + { "tcal6408", 8 | PCA953X_TYPE | PCA_LATCH_INT, }, + { "tcal6416", 16 | PCA953X_TYPE | PCA_LATCH_INT, }, { } }; MODULE_DEVICE_TABLE(i2c, pca953x_id); @@ -1469,6 +1472,9 @@ static const struct of_device_id pca953x_dt_ids[] =3D= { { .compatible =3D "ti,tca9538", .data =3D OF_953X( 8, PCA_INT), }, { .compatible =3D "ti,tca9539", .data =3D OF_953X(16, PCA_INT), }, =20 + { .compatible =3D "ti,tcal6408", .data =3D OF_953X( 8, PCA_LATCH_INT), }, + { .compatible =3D "ti,tcal6416", .data =3D OF_953X(16, PCA_LATCH_INT), }, + { .compatible =3D "onnn,cat9554", .data =3D OF_953X( 8, PCA_INT), }, { .compatible =3D "onnn,pca9654", .data =3D OF_953X( 8, PCA_INT), }, { .compatible =3D "onnn,pca9655", .data =3D OF_953X(16, PCA_INT), }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92DE047CC85; Sat, 28 Feb 2026 17:35:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300131; cv=none; b=MiW0/1XSzQYNhDtXs9HQ8nG8aaoeP8dQDLFSW/o13fSqrerBtU9Anx7ZV3FIOb5CtKQcUKa33X6as3ECARijvoEKw0+EfF6Ho2gOWkZ/CIFNsri9OiDAgU3VD0sbOlJpoG/U6742ba+lOvI5tTLbBwz2edOXRSZUjD6kFoYRmQ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300131; c=relaxed/simple; bh=IsQH2GK7lrSZDfrhWKcM5PD+4pD16JHIZmz5ZCPkWUg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MCZ+PJEUat01fsu7gB7priuIlyWdh/8ZStUs8hNlTLlWZXwJ2J7vIXOr0BUzHJYaj+kWalX9RTpHagA3Z3ysAWDL7pUtGyyTS5uhJl5693J7aUs+ghpjzB5ZPAgTfdYm5Digp1J1LfQw2XDjRsQs2aoyrYo6KVJw5F6CgwBDj1Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PR76CM5A; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PR76CM5A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CAF27C19423; Sat, 28 Feb 2026 17:35:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300131; bh=IsQH2GK7lrSZDfrhWKcM5PD+4pD16JHIZmz5ZCPkWUg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PR76CM5AMDRcp01G/gOZbePaWjpH6C5+u4/9INLmF8M/jPS8pnc7m5h43H+mlra4n FFEzkk5nN0Rhu7TQ6v4W9FHwdW/oeCrycIgUNhx0YUxPzpnOKwHQaU/x0spxPRr7Kn N8jCKyBjH3mdVA7NaZBmRB0Bwms+iSONJ73TVhZNoINtrkheHSKn35Lhz0nbHDZjai EljZQq1QbF1abF68lU0F12S6lgAmXlA2DSh36+8u0tKuUIJIMah/M6qyYZFiAWXS2d +o75GyRWGzqh9k2erBoOp44z/Mgj+rLmYeC3BfgRIieP0P1NkmNFL/wt+GC2UcPNnJ sy04OYFzBbrHQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Deepak Kumar , Alain Volmat , Mark Brown , Sasha Levin Subject: [PATCH 6.19 148/844] spi: stm32: fix Overrun issue at < 8bpw Date: Sat, 28 Feb 2026 12:21:01 -0500 Message-ID: <20260228173244.1509663-149-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Deepak Kumar [ Upstream commit 1ac3be217c01d5df55ec5052f81e4f1708f46552 ] When SPI communication is suspended by hardware automatically, it could happen that few bits of next frame are already clocked out due to internal synchronization delay. To achieve a safe suspension, we need to ensure that each word must be at least 8 SPI clock cycles long. That's why, if bpw is less than 8 bits, we need to use midi to reach 8 SPI clock cycles at least. This will ensure that each word achieve safe suspension and prevent overrun condition. Signed-off-by: Deepak Kumar Signed-off-by: Alain Volmat Link: https://patch.msgid.link/20251218-stm32-spi-enhancements-v2-2-3b69901= ca9fe@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spi-stm32.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c index 2c804c1aef989..80986bd251d29 100644 --- a/drivers/spi/spi-stm32.c +++ b/drivers/spi/spi-stm32.c @@ -1906,11 +1906,12 @@ static void stm32h7_spi_data_idleness(struct stm32_= spi *spi, struct spi_transfer cfg2_clrb |=3D STM32H7_SPI_CFG2_MIDI; if ((len > 1) && (spi->cur_midi > 0)) { u32 sck_period_ns =3D DIV_ROUND_UP(NSEC_PER_SEC, spi->cur_speed); - u32 midi =3D min_t(u32, - DIV_ROUND_UP(spi->cur_midi, sck_period_ns), - FIELD_GET(STM32H7_SPI_CFG2_MIDI, - STM32H7_SPI_CFG2_MIDI)); + u32 midi =3D DIV_ROUND_UP(spi->cur_midi, sck_period_ns); =20 + if ((spi->cur_bpw + midi) < 8) + midi =3D 8 - spi->cur_bpw; + + midi =3D min_t(u32, midi, FIELD_MAX(STM32H7_SPI_CFG2_MIDI)); =20 dev_dbg(spi->dev, "period=3D%dns, midi=3D%d(=3D%dns)\n", sck_period_ns, midi, midi * sck_period_ns); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C8024F7975; Sat, 28 Feb 2026 17:35:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300132; cv=none; b=OANf57+sveXX4UyJfb1q4SACV/9lJ5RSZxMY7XLFQuEvE+XqSP7BzEfeufUp48lP0FlqA4NLG5bZ2avefUSFJwJkNvXQ9+MVX2YIYRDectQnGknqR4XKSYyZ6dCnWHo02khe9ZZUt5tODAeXe+ZCYUsT8csqNIhWGF8vYJhGa2o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300132; c=relaxed/simple; bh=BPLFLvaqaObh7NzmP5tmu5RVyOXfSPQMHDlcY7mRKAw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=arjfeok/18oQT7MuYJdYm534huM4CDnIIMpkrwu7QQhwnSXv+aMQE2qWONKDWSmSnO48SPnP2rNKBEkzq9q5eXY8Trstm3mv66RMpv/4ohX1B94lEQzjDZAF1rRXx6fmXMCXtfeQUKXutcSxdEvBRy66dyyPYpnYU8uQK68Has8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bfg/eAEU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bfg/eAEU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9488C19424; Sat, 28 Feb 2026 17:35:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300132; bh=BPLFLvaqaObh7NzmP5tmu5RVyOXfSPQMHDlcY7mRKAw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bfg/eAEUhhNcEkN5H7iFqCteje/mj5VND5pqI3QcNuu6sQ0XO2fjq8pJlhs4hpAsa Ku6iv2iLTF8mb/fNXRzVMLz97KAkThEco4PVsgHWp//36xnqbCwQYHqLVruhH1gyKS b/znckuLkY+z8NbjfdzOJe8afGp9uore4mWlSE9kLdm+ZlRCmcArNuizwViT4XevS1 woJiPzMJaXoyUXwwk6o0aXWNVI+Ub8Q+vZbujZLlzvb+IwjI+sjyTbcoo4I4d7nrlE CPXDKRozRNz774P0jLVUpNki0AoUAv8jjo6PGK+5U7ymPY2smOQvzq9250R/JYcOIq UgDhfiJE4wQIw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ren=C3=A9=20Rebe?= , Thomas Zimmermann , Sasha Levin Subject: [PATCH 6.19 149/844] drm/ast: Swap framebuffer writes on big-endian machines Date: Sat, 28 Feb 2026 12:21:02 -0500 Message-ID: <20260228173244.1509663-150-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ren=C3=A9 Rebe [ Upstream commit 50c26c301c5176cc8b431044390e10ec862b9b77 ] Swap the pixel data when writing to framebuffer memory on big-endian machines. Fixes incorrect output. Aspeed graphics does not appear to support big-endian framebuffers after AST2400, although the feature has been documented. There's a lengthy discussion at [1]. v5: - avoid restricted cast from __be16 (kernel test robot) Signed-off-by: Ren=C3=A9 Rebe Link: https://lore.kernel.org/dri-devel/20251202.170626.2134482663677806825= .rene@exactco.de/ # [1] Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20251212.210504.1355099120650239629.rene@exa= ctco.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/ast/ast_cursor.c | 11 ++++++++--- drivers/gpu/drm/ast/ast_mode.c | 11 +++++++++-- 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cur= sor.c index 2d3ad7610c2e9..7da0a2d463e6c 100644 --- a/drivers/gpu/drm/ast/ast_cursor.c +++ b/drivers/gpu/drm/ast/ast_cursor.c @@ -92,12 +92,17 @@ static void ast_set_cursor_image(struct ast_device *ast= , const u8 *src, unsigned int width, unsigned int height) { u8 __iomem *dst =3D ast_plane_vaddr(&ast->cursor_plane.base); - u32 csum; - - csum =3D ast_cursor_calculate_checksum(src, width, height); + u32 csum =3D ast_cursor_calculate_checksum(src, width, height); =20 /* write pixel data */ +#if defined(__BIG_ENDIAN) + unsigned int i; + + for (i =3D 0; i < AST_HWC_SIZE; i +=3D 2) + writew(swab16(*(const __u16 *)&src[i]), &dst[i]); +#else memcpy_toio(dst, src, AST_HWC_SIZE); +#endif =20 /* write checksum + signature */ dst +=3D AST_HWC_SIZE; diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index cd08990a10f93..57c6fbc3232b0 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -526,12 +526,18 @@ static int ast_primary_plane_helper_atomic_check(stru= ct drm_plane *plane, =20 static void ast_handle_damage(struct ast_plane *ast_plane, struct iosys_ma= p *src, struct drm_framebuffer *fb, - const struct drm_rect *clip) + const struct drm_rect *clip, + struct drm_format_conv_state *fmtcnv_state) { struct iosys_map dst =3D IOSYS_MAP_INIT_VADDR_IOMEM(ast_plane_vaddr(ast_p= lane)); =20 iosys_map_incr(&dst, drm_fb_clip_offset(fb->pitches[0], fb->format, clip)= ); + +#if defined(__BIG_ENDIAN) + drm_fb_swab(&dst, fb->pitches, src, fb, clip, !src[0].is_iomem, fmtcnv_st= ate); +#else drm_fb_memcpy(&dst, fb->pitches, src, fb, clip); +#endif } =20 static void ast_primary_plane_helper_atomic_update(struct drm_plane *plane, @@ -561,7 +567,8 @@ static void ast_primary_plane_helper_atomic_update(stru= ct drm_plane *plane, if (drm_gem_fb_begin_cpu_access(fb, DMA_FROM_DEVICE) =3D=3D 0) { drm_atomic_helper_damage_iter_init(&iter, old_plane_state, plane_state); drm_atomic_for_each_plane_damage(&iter, &damage) { - ast_handle_damage(ast_plane, shadow_plane_state->data, fb, &damage); + ast_handle_damage(ast_plane, shadow_plane_state->data, fb, &damage, + &shadow_plane_state->fmtcnv_state); } =20 drm_gem_fb_end_cpu_access(fb, DMA_FROM_DEVICE); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A8004F798E; Sat, 28 Feb 2026 17:35:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300133; cv=none; b=LYrHPnTdnLebJHSm3MtnKeaGOpZ0tHPbRppXPuHZvkYkXAeoKBGRS6ygZGpM4FaqEFnG4pPII/EOWI5FRcO0+MeUzt4CQCW5iYoltQ1GW5fsPevVnfUxJwMatw1T+ioT3HN7ml8/nBMeFVZZcR7JR35RokUxX3P9KvbpB1r98U0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300133; c=relaxed/simple; bh=70Z/ufDjf1kcofKyMtayteHWgkEdvEWGI2H+qggGxyE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NoXRuy4f8o6tV3qO6m1XqxPKmXnBz5SJLi5klyT+sFzVclVNd0NnKZpHyj+Kgz9hABygccujJWFP45wNPxNklP+sy/73FN960SIdqLQ5jXXQAqVy2Dd1qSfFxp12gMWMR3NDnbgKM3JplTGcnWf77vFirm7rtpDTQrSb1JiwJSE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VFsynSqH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VFsynSqH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92E1FC116D0; Sat, 28 Feb 2026 17:35:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300133; bh=70Z/ufDjf1kcofKyMtayteHWgkEdvEWGI2H+qggGxyE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VFsynSqH8myl8G//ZTeNUk20vLVsofpdNOQoDETfECZ5KaZuXOODtvGCXMH8hzGyb jwcOFTipPOn8LZCmtJ/k1FTx+MRdwaDAyJh72tN2Z8XGB6NS8s37pK5NOnI04dKsXj 9cClYF3SF/OL0X7qGrSt43djQZkXR3yBrYlulDgdEEMkYCjxR1n6LSovrv7lr0aB+F 819KLqIG8IJTQgd2NN6EDb4fZgIoZJyVLNQrt0q7QjmYrn4AQ6fcXDIqwWRPCr7qb2 5Kzk31X3nyvZxGXVP1RX1gYBGRUUak4qoNdy+pDLs0YlkuEgreKJm7+TPsTgr9uRcx 6q/2kGixZ1JFQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kailang Yang , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 150/844] ALSA: hda/realtek - Enable Mute LED for Lenovo platform Date: Sat, 28 Feb 2026 12:21:03 -0500 Message-ID: <20260228173244.1509663-151-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kailang Yang [ Upstream commit 5de5db35350d9c4def1de2ae273e224a4eee5ed1 ] Enable SPK Mute Led and Mic Mute Led for Lenovo platform. Signed-off-by: Kailang Yang Link: https://patch.msgid.link/8a99edffee044e13b6e348d1b69c2b57@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/hda/codecs/realtek/alc269.c | 57 +++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/a= lc269.c index 15203c5855eb5..1964494321006 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -1616,6 +1616,20 @@ static void alc295_fixup_hp_mute_led_coefbit11(struc= t hda_codec *codec, } } =20 +static void alc233_fixup_lenovo_coef_micmute_led(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct alc_spec *spec =3D codec->spec; + + if (action =3D=3D HDA_FIXUP_ACT_PRE_PROBE) { + spec->mic_led_coef.idx =3D 0x10; + spec->mic_led_coef.mask =3D 1 << 13; + spec->mic_led_coef.on =3D 0; + spec->mic_led_coef.off =3D 1 << 13; + snd_hda_gen_add_micmute_led_cdev(codec, coef_micmute_led_set); + } +} + static void alc285_fixup_hp_mute_led(struct hda_codec *codec, const struct hda_fixup *fix, int action) { @@ -1918,6 +1932,39 @@ static void alc280_fixup_hp_gpio2_mic_hotkey(struct = hda_codec *codec, } } =20 +/* GPIO2 =3D mic mute hotkey + * GPIO3 =3D mic mute LED + */ +static void alc233_fixup_lenovo_gpio2_mic_hotkey(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct alc_spec *spec =3D codec->spec; + + alc233_fixup_lenovo_coef_micmute_led(codec, fix, action); + if (action =3D=3D HDA_FIXUP_ACT_PRE_PROBE) { + alc_update_coef_idx(codec, 0x10, 1<<2, 1<<2); + if (alc_register_micmute_input_device(codec) !=3D 0) + return; + + spec->gpio_mask |=3D 0x04; + spec->gpio_dir |=3D 0x0; + snd_hda_codec_write_cache(codec, codec->core.afg, 0, + AC_VERB_SET_GPIO_UNSOLICITED_RSP_MASK, 0x04); + snd_hda_jack_detect_enable_callback(codec, codec->core.afg, + gpio2_mic_hotkey_event); + return; + } + + if (!spec->kb_dev) + return; + + switch (action) { + case HDA_FIXUP_ACT_FREE: + input_unregister_device(spec->kb_dev); + spec->kb_dev =3D NULL; + } +} + /* Line2 =3D mic mute hotkey * GPIO2 =3D mic mute LED */ @@ -3816,6 +3863,7 @@ enum { ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED, ALC288_FIXUP_SURFACE_SWAP_DACS, ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO, + ALC233_FIXUP_LENOVO_GPIO2_MIC_HOTKEY, }; =20 /* A special fixup for Lenovo C940 and Yoga Duet 7; @@ -6306,6 +6354,10 @@ static const struct hda_fixup alc269_fixups[] =3D { .type =3D HDA_FIXUP_FUNC, .v.func =3D alc288_fixup_surface_swap_dacs, }, + [ALC233_FIXUP_LENOVO_GPIO2_MIC_HOTKEY] =3D { + .type =3D HDA_FIXUP_FUNC, + .v.func =3D alc233_fixup_lenovo_gpio2_mic_hotkey, + }, }; =20 static const struct hda_quirk alc269_fixup_tbl[] =3D { @@ -7213,7 +7265,12 @@ static const struct hda_quirk alc269_fixup_tbl[] =3D= { SND_PCI_QUIRK(0x17aa, 0x3176, "ThinkCentre Station", ALC283_FIXUP_HEADSET= _MIC), SND_PCI_QUIRK(0x17aa, 0x3178, "ThinkCentre Station", ALC283_FIXUP_HEADSET= _MIC), SND_PCI_QUIRK(0x17aa, 0x31af, "ThinkCentre Station", ALC623_FIXUP_LENOVO_= THINKSTATION_P340), + SND_PCI_QUIRK(0x17aa, 0x3341, "Lenovo ThinkCentre M90 Gen4", ALC233_FIXUP= _LENOVO_GPIO2_MIC_HOTKEY), + SND_PCI_QUIRK(0x17aa, 0x3342, "Lenovo ThinkCentre M90 Gen4", ALC233_FIXUP= _LENOVO_GPIO2_MIC_HOTKEY), + SND_PCI_QUIRK(0x17aa, 0x3343, "Lenovo ThinkCentre M70 Gen4", ALC233_FIXUP= _LENOVO_GPIO2_MIC_HOTKEY), + SND_PCI_QUIRK(0x17aa, 0x3344, "Lenovo ThinkCentre M70 Gen4", ALC233_FIXUP= _LENOVO_GPIO2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x334b, "Lenovo ThinkCentre M70 Gen5", ALC283_FIXUP= _HEADSET_MIC), + SND_PCI_QUIRK(0x17aa, 0x334f, "Lenovo ThinkCentre M90a Gen5", ALC233_FIXU= P_LENOVO_GPIO2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x3384, "ThinkCentre M90a PRO", ALC233_FIXUP_LENOVO= _L2MH_LOW_ENLED), SND_PCI_QUIRK(0x17aa, 0x3386, "ThinkCentre M90a Gen6", ALC233_FIXUP_LENOV= O_L2MH_LOW_ENLED), SND_PCI_QUIRK(0x17aa, 0x3387, "ThinkCentre M70a Gen6", ALC233_FIXUP_LENOV= O_L2MH_LOW_ENLED), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 18FB6175A64; Sat, 28 Feb 2026 17:35:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300134; cv=none; b=m3UhnIlriwPLcwUJlMXgK4lbZGtHHn5dMjrGzcmIxbQWkujborMQTUxIJYsJAQ+kz+lnhbEKG1P7eztjb/Sj/4zlq1/FToW3Wout6zz46F2LzYMYBfMET8jRPpRXrO7uix3NpHx8nBOLfvNM4LhnqAjZXLJIABLI0WVKgr40Dk8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300134; c=relaxed/simple; bh=9GRg/vEWRTZndN1XDb01T9HHR2UThmDcPOMlOFyB4SY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=T7C8oWIPAv8XEE9pKr/bEm2xYJdIxBG7Lb5bNHOoEaaQxyUqQNGZGSSy9IRzQnq9K2OBzoz3DHXQPLnoKYP/RoJE88DjQrBdQ8PhnOhlzM0PQypefau5G87EovP9FAnfUEQr4E0FgM8EXiIlkwZG7yD94otjDzc6Mpv0xKxxRVo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H5oBOAsb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H5oBOAsb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69BA8C116D0; Sat, 28 Feb 2026 17:35:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300134; bh=9GRg/vEWRTZndN1XDb01T9HHR2UThmDcPOMlOFyB4SY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H5oBOAsbbu8cN9k2Bsrb4acI8AQ5sXAy5HRHqeil5Mn5xwPF1/U0AsPOnV1MP4Suw /btEgDLya1+KCjX1z9uF8RsLJHGFS36woYSb02mU9OnKI/V/5CU6ZuWgOjrhjyzH+0 7ND4CyBFnftMSwUwpD80yKJN4NvmLEwwemcYchYiOhjZrSvvXoP2ngzZBK1q7MPx6I Fj4txk/wRWtTvrKk+eyEdw6CpLW0SmHKQQuOH/7lzfZc/27C69K5Re/vQkqd0BDMg3 lA3S7UoPQ6Hl8DyrR7ne6sOPhiPz4ubzNCb4I7vGYpIHEkOaZc6ZlTosdcAKWKGvpe 98lfgU5NIhlhw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xiaolei Wang , =?UTF-8?q?Ma=C3=ADra=20Canal?= , Sasha Levin Subject: [PATCH 6.19 151/844] drm/v3d: Set DMA segment size to avoid debug warnings Date: Sat, 28 Feb 2026 12:21:04 -0500 Message-ID: <20260228173244.1509663-152-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Xiaolei Wang [ Upstream commit 9eb018828b1b30dfba689c060735c50fc5b9f704 ] When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=3D8290304] [max=3D65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/= 0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=3D--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8 Signed-off-by: Xiaolei Wang Link: https://patch.msgid.link/20251203130323.2247072-1-xiaolei.wang@windri= ver.com Signed-off-by: Ma=C3=ADra Canal Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/v3d/v3d_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c index e8a46c8bad8a2..f469de456f9bb 100644 --- a/drivers/gpu/drm/v3d/v3d_drv.c +++ b/drivers/gpu/drm/v3d/v3d_drv.c @@ -378,6 +378,8 @@ static int v3d_platform_drm_probe(struct platform_devic= e *pdev) if (ret) goto clk_disable; =20 + dma_set_max_seg_size(&pdev->dev, UINT_MAX); + v3d->va_width =3D 30 + V3D_GET_FIELD(mmu_debug, V3D_MMU_VA_WIDTH); =20 ident1 =3D V3D_READ(V3D_HUB_IDENT1); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED505175A80; Sat, 28 Feb 2026 17:35:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300135; cv=none; b=DvyPjUO1eY8Hg0CZ9FGuVB78WxCabkUjjyby9haCoj/VS0uEeiF4s0IFhy3dqSDYmYTT0koogMhlrzsfaMgLrCkSejyxNoKnGC/MSI50dafGJdqmFk+J3YFaLSDh7YjFUFdXGAEGjQufGcb/6ayK9viSkNBae9NzGL4omy0BdJ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300135; c=relaxed/simple; bh=K/186z1y6c+vK5de+7Iw8hyg8iSR5DBLjUV9OQvskRE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f88xt9C97gjIamkPLXnty2oy59MJGjJNv7m3Qx222AXxMKvTI6S05a+t+jqvwuZ5TEtO5ojsawipHlzBCtIFfrhlM+CzbIax04fjF4nDl7pwKga6Y3+kA6wk/jDULSjmvhzUjZcQ114Wpj5AaQfr8YDKagtiVt4wHW5Do1LzEeQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WmuzygYE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WmuzygYE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FD5BC19425; Sat, 28 Feb 2026 17:35:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300134; bh=K/186z1y6c+vK5de+7Iw8hyg8iSR5DBLjUV9OQvskRE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WmuzygYEy63shX9nEhF3wNBl0Vw0o3P/pxcNmIAGDDo4uXb80mkXEAxL0rrqMb+z4 mcFakPhASnLi6KX2axo4gUT8nOViggG6NJUPtqTqmuHSB08hIfHx3kY9OyeVMcPZqN sr/oJPh9QMNUnS3BOrMYPy1eKJb6pwwA5f26co9i6zN8T66RctPJeBpj/a0tPPesSw A4qV6/Nwgq/xtdhLEzIwamlvv1FynqmGrKbIgqM+K9lzpYeeTtmQYKsL7U415RTx/X FUaf8fS+Z3ycihykwEiEuJlZaVLu9Mvl190zsMvOyHcfMVQ0ionqEQaJoD68CSCJWL qhDI/Bmz0XiNw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans Verkuil , Sakari Ailus , Sasha Levin Subject: [PATCH 6.19 152/844] media: omap3isp: isp_video_mbus_to_pix/pix_to_mbus fixes Date: Sat, 28 Feb 2026 12:21:05 -0500 Message-ID: <20260228173244.1509663-153-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans Verkuil [ Upstream commit 44c03802a5191626996ee9db4bac090b164ca340 ] The isp_video_mbus_to_pix/pix_to_mbus functions did not take the last empty entry { 0, } of the formats array into account. As a result, isp_video_mbus_to_pix would accept code 0 and isp_video_pix_to_mbus would select code 0 if no match was found. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/ti/omap3isp/ispvideo.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/ti/omap3isp/ispvideo.c b/drivers/media/= platform/ti/omap3isp/ispvideo.c index 0e7f0bf2b3463..68e6a24be5614 100644 --- a/drivers/media/platform/ti/omap3isp/ispvideo.c +++ b/drivers/media/platform/ti/omap3isp/ispvideo.c @@ -148,12 +148,12 @@ static unsigned int isp_video_mbus_to_pix(const struc= t isp_video *video, pix->width =3D mbus->width; pix->height =3D mbus->height; =20 - for (i =3D 0; i < ARRAY_SIZE(formats); ++i) { + for (i =3D 0; i < ARRAY_SIZE(formats) - 1; ++i) { if (formats[i].code =3D=3D mbus->code) break; } =20 - if (WARN_ON(i =3D=3D ARRAY_SIZE(formats))) + if (WARN_ON(i =3D=3D ARRAY_SIZE(formats) - 1)) return 0; =20 min_bpl =3D pix->width * formats[i].bpp; @@ -191,7 +191,7 @@ static void isp_video_pix_to_mbus(const struct v4l2_pix= _format *pix, /* Skip the last format in the loop so that it will be selected if no * match is found. */ - for (i =3D 0; i < ARRAY_SIZE(formats) - 1; ++i) { + for (i =3D 0; i < ARRAY_SIZE(formats) - 2; ++i) { if (formats[i].pixelformat =3D=3D pix->pixelformat) break; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21F6747CC92; Sat, 28 Feb 2026 17:35:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300136; cv=none; b=GE2XD7CTICg3t3IokjqrXPksSiYQLC9fL5U+kJU8VplZbV9FNgjqQLkPFno/qlGe8avKq+0lbCjjqVFBaXuXS0S+3cXpXi4U22F7VubMYNBzwmGwpVEEEO/dspFDVaere449m3cGOHxMwMbH7mgHq1p8zDA3pHVdwy+bYVUu3yE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300136; c=relaxed/simple; bh=diWvckYIFXeOe6phtc9YGTOKJ+joKOgIt1D2BRCZP48=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bJ+lFs8U0H80x8SeVuH5CkJ1N6EocftPIgVpQXuzlzKqd2xRJKkxbzkCDWR9kzbHavP/FsTLlCxjHI1BjLvJW1+AMr5EIhUfU2rui66eJ4PTdwKhURsWfdkGhWtf+DntS+P0gAAXmHz152pbrVz8A9RjltmWc+XsoCxUnYMquoE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IOJeT4Mq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IOJeT4Mq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21F0EC19423; Sat, 28 Feb 2026 17:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300135; bh=diWvckYIFXeOe6phtc9YGTOKJ+joKOgIt1D2BRCZP48=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IOJeT4MqFws2Wx7mwFVMmdUkrEC8A3f+QPiKvKMNy8KLzbJWC9gYSFwPoFj9Wo7q9 HXwbq8r5xgy9yqqK9kjnfDjBWU9aiY+fg24GoNRqtsqxunhuWDEJiodyNq3eg4uq1q XLT7XhlS6tsMbHQ6SEYql+k5UXBhCWbZkLFZg0IKCKUeTKe3InfN8vvuSpo5+/VxWC V21Vs7T4nWhDC2M8DMtsDUZHZRFgipctr6BptH81FSANn9BcGOc6GY/WTC9swd4tgO 8X6YFuu0WzxhvmsV9Wfxg0vbylMI12jtP4ea369AhzJ/FbI61E45LPQoVAvEQKndqE RkNpFohRrofNQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans Verkuil , Sakari Ailus , Sasha Levin Subject: [PATCH 6.19 153/844] media: omap3isp: isppreview: always clamp in preview_try_format() Date: Sat, 28 Feb 2026 12:21:06 -0500 Message-ID: <20260228173244.1509663-154-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans Verkuil [ Upstream commit 17e1e1641f74a89824d4de3aa38c78daa5686cc1 ] If prev->input !=3D PREVIEW_INPUT_MEMORY the width and height weren't clamped. Just always clamp. This fixes a v4l2-compliance error: fail: v4l2-test-subdevs.cpp(171): fse.max_width =3D=3D ~0U || fse.max_heig= ht =3D=3D ~0U fail: v4l2-test-subdevs.cpp(270): ret && ret !=3D ENOTTY test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: FAIL Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../media/platform/ti/omap3isp/isppreview.c | 21 +++++++------------ 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/drivers/media/platform/ti/omap3isp/isppreview.c b/drivers/medi= a/platform/ti/omap3isp/isppreview.c index e383a57654de8..5c492b31b5160 100644 --- a/drivers/media/platform/ti/omap3isp/isppreview.c +++ b/drivers/media/platform/ti/omap3isp/isppreview.c @@ -1742,22 +1742,17 @@ static void preview_try_format(struct isp_prev_devi= ce *prev, =20 switch (pad) { case PREV_PAD_SINK: - /* When reading data from the CCDC, the input size has already - * been mangled by the CCDC output pad so it can be accepted - * as-is. - * - * When reading data from memory, clamp the requested width and - * height. The TRM doesn't specify a minimum input height, make + /* + * Clamp the requested width and height. + * The TRM doesn't specify a minimum input height, make * sure we got enough lines to enable the noise filter and color * filter array interpolation. */ - if (prev->input =3D=3D PREVIEW_INPUT_MEMORY) { - fmt->width =3D clamp_t(u32, fmt->width, PREV_MIN_IN_WIDTH, - preview_max_out_width(prev)); - fmt->height =3D clamp_t(u32, fmt->height, - PREV_MIN_IN_HEIGHT, - PREV_MAX_IN_HEIGHT); - } + fmt->width =3D clamp_t(u32, fmt->width, PREV_MIN_IN_WIDTH, + preview_max_out_width(prev)); + fmt->height =3D clamp_t(u32, fmt->height, + PREV_MIN_IN_HEIGHT, + PREV_MAX_IN_HEIGHT); =20 fmt->colorspace =3D V4L2_COLORSPACE_SRGB; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C45BA301EEA; Sat, 28 Feb 2026 17:35:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300136; cv=none; b=gI+ZbXUy+pA6Ons+mTwbW4v5W2wsrLl9o4IN9POH1cEsiZP7TWKFjuJ0RQNbJhyJ73tmfjEtxqHvGs4GDOsBBiKl889Zf8KTgqD9+RCsBfJ43gG5IbcEQfPWLFQu4lO3i0qxF8AOSwrofjb3zw+FFZUKax5B0sBeWpTcuCRYnns= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300136; c=relaxed/simple; bh=jxCt0uMfHKs951p72ivQYkem2ETitUUGW3QD0odWOgU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GgqwOynMD/u6bGQb/+yv6eZoIxZx2ft4w2vU5yyzpY19pj/tcnMGkVRR00wn2Skh5NoKw9i57+K55a8DHpd37BUESMBqC6KPd/K2QkETlnox2UIa1/bgqXE9n5MIAuTZRgGK6Zgz/YqeHH6y2GBnWr749G5ahKOSzsAneQwdXA0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BhdAuNtl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BhdAuNtl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F09D8C116D0; Sat, 28 Feb 2026 17:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300136; bh=jxCt0uMfHKs951p72ivQYkem2ETitUUGW3QD0odWOgU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BhdAuNtlxjtOLTbF/o+6uyYc2BtiCP86OFLrXf0z8QYvy9YB8AWCsQtHiG0g3EVX5 48Tvu9OKirE+qlD8AGUYoKy1pV5e8g+9UDqKfufFw/PDolxMim6tRNWlBq5HVlrCtm 8mWM92ctQMf0w84n7f2N5vn/zDEZj0kzHHfik0TH1DNby2mHuzvpuIbXX002L3cPEV cxYcrkTdV5yRYCUV/50DLt9aUw7tUC2OWmvKH83D7Ri5r/OEGOesZ4ZgO1jmPyPaBU KadAopWSHDyipX5n/dLA8exdD0k7Hs1ppc2dAFbBbgX3wbQuldn8GLHE/d4pntcdFd Cawuq4gt6Cf3A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans Verkuil , Sakari Ailus , Sasha Levin Subject: [PATCH 6.19 154/844] media: omap3isp: set initial format Date: Sat, 28 Feb 2026 12:21:07 -0500 Message-ID: <20260228173244.1509663-155-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans Verkuil [ Upstream commit 7575b8dfa91f82fcb34ffd5568ff415ac4685794 ] Initialize the v4l2_format to a default. Empty formats are not allowed in V4L2, so this fixes v4l2-compliance issues: fail: v4l2-test-formats.cpp(514): !pix.width || !pix.height test VIDIOC_G_FMT: FAIL Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/ti/omap3isp/ispvideo.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/media/platform/ti/omap3isp/ispvideo.c b/drivers/media/= platform/ti/omap3isp/ispvideo.c index 68e6a24be5614..eb33a776f27c9 100644 --- a/drivers/media/platform/ti/omap3isp/ispvideo.c +++ b/drivers/media/platform/ti/omap3isp/ispvideo.c @@ -1288,6 +1288,7 @@ static const struct v4l2_ioctl_ops isp_video_ioctl_op= s =3D { static int isp_video_open(struct file *file) { struct isp_video *video =3D video_drvdata(file); + struct v4l2_mbus_framefmt fmt; struct isp_video_fh *handle; struct vb2_queue *queue; int ret =3D 0; @@ -1330,6 +1331,13 @@ static int isp_video_open(struct file *file) =20 memset(&handle->format, 0, sizeof(handle->format)); handle->format.type =3D video->type; + handle->format.fmt.pix.width =3D 720; + handle->format.fmt.pix.height =3D 480; + handle->format.fmt.pix.pixelformat =3D V4L2_PIX_FMT_UYVY; + handle->format.fmt.pix.field =3D V4L2_FIELD_NONE; + handle->format.fmt.pix.colorspace =3D V4L2_COLORSPACE_SRGB; + isp_video_pix_to_mbus(&handle->format.fmt.pix, &fmt); + isp_video_mbus_to_pix(video, &fmt, &handle->format.fmt.pix); handle->timeperframe.denominator =3D 1; =20 handle->video =3D video; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1F01301F04; Sat, 28 Feb 2026 17:35:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300137; cv=none; b=MYy7G/Kql/BYuUvimK9Le1TTW2yyM6ic/s/mccnFGleBVgb19VLkoUK3DG1QklVKZMJm+9Tqh+YzB0QPh7TYPYT5msvHgH6yy67OHgGlSllI5O100J87J6CmBD3tYvaWrzIDQlTG1Y1T+ZC0qHdnHtst/patnZbx92GJjNvi0rg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300137; c=relaxed/simple; bh=hXFZmuqxr72Et5WWnpswSxvsRGJlQHJGxp3QLH3btng=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=j/fSsvYJ9XXco+5RNQPMWUs4aPAvub8n6nTYt5cTn78vto6zM2oSlXNR8VcWaaZ6n2ctMHvjobpJ36XJWtw0fWX+oWAVOOEhsaKV1Yd5ht7P4M9X+eC2UHsDfLmnOAVtQTohjgUUTUpJIsucQNEsX+EWhAHenu2mpQYgbDsYaNc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZJe8cTrp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZJe8cTrp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0CAEC19424; Sat, 28 Feb 2026 17:35:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300137; bh=hXFZmuqxr72Et5WWnpswSxvsRGJlQHJGxp3QLH3btng=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZJe8cTrpIMkZWWmpJriYT4v6UHOT5I3rbQdmmomfJw9CB7gwt2Id62JGkc8LMeuY9 lqAO+5ehnau60S88vSXRLJ3G6YgE2L0Qg/XCLelqQGahwx1/gmnBmqvmXnUuZ1BcSc MeK65BojeuOFCQegaMeI6fCNF/6cG6b+u5PU3pCUwkQQ96dVh/nQ6iIhe8LAevoBow fTDAU12rg363A2rLvMEPfmdvyXOltTWaqt8+9uzbWKI/AlAtHulZAABnFLCyUFehdW LiSFYiCTvQE7wfV6oAArjip0tM3ag4pFonxjGxhTFzRUo5wS85e+j7OEz7RQlhFrsN ok0ve/rlXhKgw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Brandon Brnich , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 155/844] media: chips-media: wave5: Fix conditional in start_streaming Date: Sat, 28 Feb 2026 12:21:08 -0500 Message-ID: <20260228173244.1509663-156-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Brandon Brnich [ Upstream commit b4e26c6fc1b3c225caf80d4a95c6f9fcbe959e17 ] When STREAMON(CAP) is called after STREAMON(OUT), the driver was failing to switch states from VPU_INST_STATE_OPEN to VPU_INST_STATE_INIT_SEQ and VPU_INST_STATE_PIC_RUN because the capture queue streaming boolean had not yet been set to true. This led to a hang in the encoder since the state was stuck in VPU_INST_STATE_OPEN. During the second call to start_streaming, the sequence initialization and frame buffer allocation should occur. Signed-off-by: Brandon Brnich Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c b/dri= vers/media/platform/chips-media/wave5/wave5-vpu-enc.c index 94fb5d7c87021..a11f0f7c7d7b0 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c @@ -1367,7 +1367,8 @@ static int wave5_vpu_enc_start_streaming(struct vb2_q= ueue *q, unsigned int count if (ret) goto return_buffers; } - if (inst->state =3D=3D VPU_INST_STATE_OPEN && m2m_ctx->cap_q_ctx.q.stream= ing) { + if (inst->state =3D=3D VPU_INST_STATE_OPEN && + (m2m_ctx->cap_q_ctx.q.streaming || q->type =3D=3D V4L2_BUF_TYPE_VIDEO= _CAPTURE_MPLANE)) { ret =3D initialize_sequence(inst); if (ret) { dev_warn(inst->dev->dev, "Sequence not found: %d\n", ret); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8F6247CC99; Sat, 28 Feb 2026 17:35:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300138; cv=none; b=b+GQIPdIznm+VwPlkIyMLuhVpxmEYprf2CI65pxlxs0Iv2Q5OTVn6zkFo7C6xWL5aMXxS3imtirCIBuNFhDsAYwMS1ISiERooTtez600rAkCOP9Lk11bJj7Ung0qC6pSwcAu0BwU2yxraRCyMjlgDt7/0JzkDLI9mzq+q1ru0VA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300138; c=relaxed/simple; bh=hFQSfyc2sFzPu99hh9iKoECuRF196fks64pjmsKHxFY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bt4wmoIS4lLHms1snFgjlXfMBZ0eIAsDvik6vPplOMUFX9ZGldCtPg8f4yHi4+CxrCFegYpToKPrpmB43+AeM6NkZOL7bKXWN3xPoeURvY4XAHBEIa8dGcib83hUMgeHWBY6QbtnZ2diSayZS3ArYGXlk1H+mNTI4efRe8ZmETo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JuviLNUM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JuviLNUM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0200C19423; Sat, 28 Feb 2026 17:35:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300138; bh=hFQSfyc2sFzPu99hh9iKoECuRF196fks64pjmsKHxFY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JuviLNUMXM/JZSMyaPdeSblguWZ8PH/VTHVLAREeUX9r7GMiYezUjBSCRQw8gpLXL 7dpeGvO8T7Cuti/p5G+vASCv//LSOBUmkgyKYwRrM+Gfrol/U+3BbFVwLDcOV9zxfB x9L1FpjIVM0z6aAqiQ8j+1PUD4tS8Uq1Y1ztlS+XRkalyecRwBcA/vWQMIo8jZdrUJ ZvRcfqTPdkyTy3fXyiQje/7nfET13sY8rCHboWBtr9ZjaARkSoUNk65hl2CaFqriMB zixLSsEph4zn878Wh0KOlOzZjECKS49sw6zBwl7FhTMpONtuMamxeOu4bmT2LolXXJ HqDSuv85WCp9Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Brandon Brnich , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 156/844] media: chips-media: wave5: Process ready frames when CMD_STOP sent to Encoder Date: Sat, 28 Feb 2026 12:21:09 -0500 Message-ID: <20260228173244.1509663-157-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Brandon Brnich [ Upstream commit 5da0380de41439ed64ed9a5218850db38544e315 ] CMD_STOP being sent to encoder before last job is executed by device_run can lead to an occasional dropped frame. Ensure that remaining ready buffers are drained by making a call to v4l2_m2m_try_schedule. Signed-off-by: Brandon Brnich Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c b/dri= vers/media/platform/chips-media/wave5/wave5-vpu-enc.c index a11f0f7c7d7b0..a254830e4009e 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c @@ -649,6 +649,8 @@ static int wave5_vpu_enc_encoder_cmd(struct file *file,= void *fh, struct v4l2_en =20 m2m_ctx->last_src_buf =3D v4l2_m2m_last_src_buf(m2m_ctx); m2m_ctx->is_draining =3D true; + + v4l2_m2m_try_schedule(m2m_ctx); break; case V4L2_ENC_CMD_START: break; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6349E36D9F0; Sat, 28 Feb 2026 17:35:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300139; cv=none; b=swS/5WtlRB6zAnyy5lto8NfY2Kb3krNN2c9sbQRTAXvj/rjDC+TodVqlKml2l2D6OLKN9mfN3o5BWR609zbzsjRDUZZBSpeuGnjArgA8SfwfZFkXFzLOTE4H0ifGzys45oHHPRGM13jeqGK668KrQ01xP68VW5YD9VlD1nw34TE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300139; c=relaxed/simple; bh=XLhhosNDhsVYiB5cqGxb2IWumSIAvhbevaDOB5YKtFo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GGPtko99yR7xADZBYJbblHYTLvxkLDR4phrEoruayDALD3yYOXSspiaCaVbMGJCfAZiZhNPPjAIfsIW1a8E2wMuKyTw4WyMFGap1xj8PaQycntBVjCjuX885Nz8eLOcU5Oq0LTWO5xslUWpoBcxkNSOB0jOjIoSNpk7XfkUZJJs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Nk/WeIUk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Nk/WeIUk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3237C19424; Sat, 28 Feb 2026 17:35:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300139; bh=XLhhosNDhsVYiB5cqGxb2IWumSIAvhbevaDOB5YKtFo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Nk/WeIUkcc2qP6ncHWmDU5HWGck5StQ34LZhGSNqppOoH/2LJTqoJHG+oZMe97LkH I2Ub7PJ+t1iERIOAF22c7WiBMr7NT8DRveoZh4QtbA15ddWRAkt3C52CTrAWS3AG2M z0GBtrj08bAaiv9vgroGoqMYyZC6BAkSrebAed66Yc6d9MvyCBfiPTdUyB86cummUt ENIXDxNYCySXIx1saX9JM3vHE4HhaU5hib07uFIiWXT+gX55A6DsJbCg+O3sparVZB hODbwOicE6q59OMqUQvYauYxB6x3Z+GAoSjogO3nLsYsglOh8oIcal06L+ZKuqLk7C 5P+yFo2RzffZw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Douglas Anderson , Sasha Levin Subject: [PATCH 6.19 157/844] drm/panel: edp: add BOE NV140WUM-T08 panel Date: Sat, 28 Feb 2026 12:21:10 -0500 Message-ID: <20260228173244.1509663-158-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit 349d4efadc1f831ebc0b872ba1e3a2b7dd58b72b ] Add powerseq timing info for the BOE NV140WUM-T08 panel used on Lenovo Thinkpad T14s gen 6 (Snapdragon X1 Elite) laptops. edid-decode (hex): 00 ff ff ff ff ff ff 00 09 e5 26 0c 00 00 00 00 0a 21 01 04 a5 1e 13 78 03 d6 62 99 5e 5a 8e 27 25 53 58 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 33 3f 80 dc 70 b0 3c 40 30 20 36 00 2e bc 10 00 00 1a 00 00 00 fd 00 28 3c 4c 4c 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 56 31 34 30 57 55 4d 2d 54 30 38 0a 00 fa Signed-off-by: Hans de Goede Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260105155134.83266-1-johannes.goede@oss.qu= alcomm.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/panel/panel-edp.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/pane= l-edp.c index 85dd3f4cb8e1c..679f4af5246d8 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -1730,6 +1730,12 @@ static const struct panel_delay delay_200_500_p2e100= =3D { .prepare_to_enable =3D 100, }; =20 +static const struct panel_delay delay_200_500_p2e200 =3D { + .hpd_absent =3D 200, + .unprepare =3D 500, + .prepare_to_enable =3D 200, +}; + static const struct panel_delay delay_200_500_e50 =3D { .hpd_absent =3D 200, .unprepare =3D 500, @@ -1977,6 +1983,7 @@ static const struct edp_panel_entry edp_panels[] =3D { EDP_PANEL_ENTRY('B', 'O', 'E', 0x0b56, &delay_200_500_e80, "NT140FHM-N47"= ), EDP_PANEL_ENTRY('B', 'O', 'E', 0x0b66, &delay_200_500_e80, "NE140WUM-N6G"= ), EDP_PANEL_ENTRY('B', 'O', 'E', 0x0c20, &delay_200_500_e80, "NT140FHM-N47"= ), + EDP_PANEL_ENTRY('B', 'O', 'E', 0x0c26, &delay_200_500_p2e200, "NV140WUM-T= 08"), EDP_PANEL_ENTRY('B', 'O', 'E', 0x0c93, &delay_200_500_e200, "Unknown"), EDP_PANEL_ENTRY('B', 'O', 'E', 0x0cb6, &delay_200_500_e200, "NT116WHM-N44= "), EDP_PANEL_ENTRY('B', 'O', 'E', 0x0cf2, &delay_200_500_e200, "NV156FHM-N4S= "), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 589FE36DA0F; Sat, 28 Feb 2026 17:35:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300140; cv=none; b=mczH7ESx9aGx+97IPw4tIkor4H09B3DIrnNXMSanIricarBxSgUho4Cgq99qihvVPefDz+b75OEY91zcVJYh8BFzxW3ZlZcYj6R0mz7oSJ1U150OEOPiY4DGMwAb+LyswTVGCN6OzwJsy5pUuAJr6Mn+1x8X1jRHiBrmkxZQUGI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300140; c=relaxed/simple; bh=NOzhfqd4DjmFiQKuS+a1GuPqV7fhkO86AfFKKYFbbyk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ekaOmkwjF63y6IYdQztI2KYHw4ce72GdMFVx36y6R+nn3stKcRbUoPsorJ3AH+NSXUZxKC5nQAYF1xsNfriKME3+QEUJwOwaV7lqVYP9DpmBye8nooERUGrfHEJa9V9d9X+cY01ZQMri+9Ok1xSB/aLIYXgJal3CCrfsQgVrboM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZSF9cS2u; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZSF9cS2u" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D08CC116D0; Sat, 28 Feb 2026 17:35:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300140; bh=NOzhfqd4DjmFiQKuS+a1GuPqV7fhkO86AfFKKYFbbyk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZSF9cS2usx58a+13SHSCUUa9cFRjBqA5enfSYsuMcoxiGmjBK/AtTjunty7opjczf 2HV6fj4NP68GVPj62W4iQm2TKkEmPT3Th/ESaD9MpmdeIuBlktzLPPr5Zx5aUZy21E +T5keVtCgP0wR+uR8W/WOadXk+w+QKEIEtWztXSlpu8YzC9qFMc0n10xTrlUQ3hsZF hiQCWKc2oDlbSv+XPVEsvnFApe+UZn+uim/GX/v64lqV0STr23SQVYEnQqf0wQUNHf L1M4RMM57MJo3euBx9sDSD3PUaIiN8MSOp6sWIc3rxUWWoulWXq7iCwJGzTwPFDHjF WHkWwk+varQ+g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nicolas Dufresne , AngeloGioacchino Del Regno , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 158/844] media: mediatek: vcodec: Don't try to decode 422/444 VP9 Date: Sat, 28 Feb 2026 12:21:11 -0500 Message-ID: <20260228173244.1509663-159-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicolas Dufresne [ Upstream commit 3e92d7e4935084ecdbdc88880cc4688618ae1557 ] This is not supported by the hardware and trying to decode these leads to LAT timeout errors. Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_= stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec= _stateless.c index d873159b9b306..9eef3ff2b1278 100644 --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_statele= ss.c +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_statele= ss.c @@ -502,6 +502,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl) mtk_v4l2_vdec_err(ctx, "VP9: bit_depth:%d", frame->bit_depth); return -EINVAL; } + + if (!(frame->flags & V4L2_VP9_FRAME_FLAG_X_SUBSAMPLING) || + !(frame->flags & V4L2_VP9_FRAME_FLAG_Y_SUBSAMPLING)) { + mtk_v4l2_vdec_err(ctx, "VP9: only 420 subsampling is supported"); + return -EINVAL; + } break; case V4L2_CID_STATELESS_AV1_SEQUENCE: seq =3D (struct v4l2_ctrl_av1_sequence *)hdr_ctrl->p_new.p; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92DD037144B; Sat, 28 Feb 2026 17:35:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300141; cv=none; b=f543UkjV13YiFYOCakvzrDQFgdaCWNUBS1nu85aeiUAUTawJyFdExwnWlgIIl4P1HbHbRd6vKP2FFHzj/x6FXoB9ZZIpr/ZyZgrtQEKYBuOw8G6EgalNSID0aeeuLZaaHPXh4Ze3/PROIZ2ZLUD7mdhtszOAY4aj4dCGeDF/Rbo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300141; c=relaxed/simple; bh=CrjC/KEYRFs2Rg659n4xEZHkQ8osnrjx1QCXppF2yaw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KpbjNAhSc8IvRsClWHXrk71fE3JD91sWUnvG7qVawcx4oxY30RsnqcpYinUTG0WvAxEPOJbtDJ0M8k0/9LPXk/O11efS/MxtEfvJNvfTgpNHK+ykSGb9U+UAcj09NZdNbYFaj7p49Ks+4375Yn5LfDxQcqRITBlaenJlCNstM2Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BFqvBve9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BFqvBve9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80C45C116D0; Sat, 28 Feb 2026 17:35:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300141; bh=CrjC/KEYRFs2Rg659n4xEZHkQ8osnrjx1QCXppF2yaw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BFqvBve9xmjtnybtmgp9IUmAwXktUCR8xLmEF9/fQEEGnthYiL63G+G9BDNGfUNC9 M+XpOAejOC+XkDZzUI3BYb+oybHvS87yODZvXmnWUL4qGRo8GGa97cc/QekRT3lyfs /Xg903rMgBHeDSEvTHc4vIG/IIAB+V/cZ/y49HZQ09XIHi5jUBkWhH/ByIetBkTJYX 3NUDiJ+6oNU6tCW92T9m1WEqZb/lm0sKe5M0x3rHjpo1lqaZISpsPse5+FGg+7VQ3g iec7UTNgDhii4Tpru2nQ2pVol0GEzwSJbHx68Mq8vt4rxMeZVxRTWU37ayYhwcXJEd ld4QCyxSbaMtA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tim Huang , Mario Limonciello , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 159/844] drm/amdgpu: add support for HDP IP version 6.1.1 Date: Sat, 28 Feb 2026 12:21:12 -0500 Message-ID: <20260228173244.1509663-160-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tim Huang [ Upstream commit e2fd14f579b841f54a9b7162fef15234d8c0627a ] This initializes HDP IP version 6.1.1. Reviewed-by: Mario Limonciello Signed-off-by: Tim Huang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/dr= m/amd/amdgpu/amdgpu_discovery.c index fa2a22dfa0487..f9e0e80c4c186 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c @@ -3059,6 +3059,7 @@ int amdgpu_discovery_set_ip_blocks(struct amdgpu_devi= ce *adev) case IP_VERSION(6, 0, 0): case IP_VERSION(6, 0, 1): case IP_VERSION(6, 1, 0): + case IP_VERSION(6, 1, 1): adev->hdp.funcs =3D &hdp_v6_0_funcs; break; case IP_VERSION(7, 0, 0): --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D4EC371461; Sat, 28 Feb 2026 17:35:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300142; cv=none; b=CL49fKV337AHl2s/dfuxF6mgBRTNILJoa9dGdN1zFkafR6OF46v0y0LPxljgAWjsk6Hqe9IAuDjbMna+k6e1PSIlalYxTLG4A8vPgqvvAZfmsv6qLrao1Ahk2CmytxyAUs2XlPbt+U8S5K6fGjdno+QX021Mv7TA9jkcmIMZYIU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300142; c=relaxed/simple; bh=btPV7Y2TMivWIgaVJU2GSYHzCWhw0jG0pCY16L+3Ha0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nmUjyb5ctLghpGIdbwuj3cIpXzxEcdAb24Vn/Sm6vpEs+cGGh9yDKHVyzCLZxJSHmbS5EsXnA5s72u0x92lOIudLnz6rU4LjO1U3G/de/+dSetveKlivRLy0xw2yy7Vc4RljdfL83epkwFzyucx6G52J9LNbapYtdD5g3Iwmr4Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O6PTN/Gy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O6PTN/Gy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76246C19425; Sat, 28 Feb 2026 17:35:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300142; bh=btPV7Y2TMivWIgaVJU2GSYHzCWhw0jG0pCY16L+3Ha0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O6PTN/GyxI9joeJK5kILaqfV+rYTvpomh5VlbitHvY9/Olaf7MOoCZRk/eVpz3Ykb jdCHpvJIGhcv5lm5WlmyoAj6183RIJ0KaZH/5meOAYSjHO5TzV6jSbUCW+5gTgPuaj BPuNo3/m8r47Y9ItSAe5fQxksjdr3dENwzJ54j/Dq7XUsN/V2pRxEKiQrqz5b8qZsJ Zws5D5rhudXDpn70aQAOKSZ97OY9y3iPwFCMp9ernV0z5b/OGVCxQucKzy85gTkSmR HSQyeFldeffvdBK3bkEVDz/x0ha5ITu8SVw/xHzqeClXvH7BebigI5E2PudCuhHw4b bEW/uGOIc8Kxg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nicholas Kazlauskas , Swapnil Patel , Chenyu Chen , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 160/844] drm/amd/display: Fix mismatched unlock for DMUB HW lock in HWSS fast path Date: Sat, 28 Feb 2026 12:21:13 -0500 Message-ID: <20260228173244.1509663-161-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicholas Kazlauskas [ Upstream commit af3303970da5ce5bfe6dffdd07f38f42aad603e0 ] [Why] The evaluation for whether we need to use the DMUB HW lock isn't the same as whether we need to unlock which results in a hang when the fast path is used for ASIC without FAMS support. [How] Store a flag that indicates whether we should use the lock and use that same flag to specify whether unlocking is needed. Reviewed-by: Swapnil Patel Signed-off-by: Nicholas Kazlauskas Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c b/driver= s/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c index e2763b60482a0..052d573408c3e 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c @@ -741,6 +741,7 @@ void hwss_build_fast_sequence(struct dc *dc, struct dce_hwseq *hws =3D dc->hwseq; struct pipe_ctx *current_pipe =3D NULL; struct pipe_ctx *current_mpc_pipe =3D NULL; + bool is_dmub_lock_required =3D false; unsigned int i =3D 0; =20 *num_steps =3D 0; // Initialize to 0 @@ -763,11 +764,12 @@ void hwss_build_fast_sequence(struct dc *dc, (*num_steps)++; } if (dc->hwss.dmub_hw_control_lock_fast) { + is_dmub_lock_required =3D dc_state_is_fams2_in_use(dc, context) || + dmub_hw_lock_mgr_does_link_require_lock(dc, stream->link); + block_sequence[*num_steps].params.dmub_hw_control_lock_fast_params.dc = =3D dc; block_sequence[*num_steps].params.dmub_hw_control_lock_fast_params.lock = =3D true; - block_sequence[*num_steps].params.dmub_hw_control_lock_fast_params.is_re= quired =3D - dc_state_is_fams2_in_use(dc, context) || - dmub_hw_lock_mgr_does_link_require_lock(dc, stream->link); + block_sequence[*num_steps].params.dmub_hw_control_lock_fast_params.is_re= quired =3D is_dmub_lock_required; block_sequence[*num_steps].func =3D DMUB_HW_CONTROL_LOCK_FAST; (*num_steps)++; } @@ -906,7 +908,7 @@ void hwss_build_fast_sequence(struct dc *dc, if (dc->hwss.dmub_hw_control_lock_fast) { block_sequence[*num_steps].params.dmub_hw_control_lock_fast_params.dc = =3D dc; block_sequence[*num_steps].params.dmub_hw_control_lock_fast_params.lock = =3D false; - block_sequence[*num_steps].params.dmub_hw_control_lock_fast_params.is_re= quired =3D dc_state_is_fams2_in_use(dc, context); + block_sequence[*num_steps].params.dmub_hw_control_lock_fast_params.is_re= quired =3D is_dmub_lock_required; block_sequence[*num_steps].func =3D DMUB_HW_CONTROL_LOCK_FAST; (*num_steps)++; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB8DB37147D; Sat, 28 Feb 2026 17:35:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300143; cv=none; b=sUh3ywEqO4vXJdMvl5h+j3HNihWgQP2BEDcEibInCenQPIwVblF0meu7F6jekKBqYMJDqAbntjKE27FNrwL0SnzvxaE842BnUboYkwhTQWlXudsMPs59Fhp8qwJcjr25Re6fct2imHDl6yrHTpSVbb7V6VHiDb+lXbnolMut704= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300143; c=relaxed/simple; bh=JWeOc0Lbdei6aIrRvm6tRFwtITZbAgHUhPg0VYB4LpI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eT/BzlUC3sdrH3mZ7IdyLnsHeqqtuigOKa+wLLffleLJ+k+JYNoHaadyB8Wo/aL7whKYFXGZAjahs824ZwuCMTRFBtOk3lv+SMkG/NLY8OOZExtr4veuLJ6MnGzzVL1sXbbx175p6F586M0b2W/7jpFCOec8hKpT9BgQMifvf/I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SClNR+qN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SClNR+qN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92626C19423; Sat, 28 Feb 2026 17:35:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300143; bh=JWeOc0Lbdei6aIrRvm6tRFwtITZbAgHUhPg0VYB4LpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SClNR+qNXfwZp/K1OB6/BxLiTupUizPsG7B2macYcAI1Uk1ijZtN53d2LCZ9tlo39 6i0Ahf7N8Hi55R6HuItmsY5ITiirSF0FvD0d9BqZmZvRWWdM/YRU04ofoNOFE3YeuD C24ki0083rL5uJPaysTjSy8ywVnD/zJmGl1bA6s/s37rceNGnnzHZMcC3H92pEyUbI EIdLB5eN3TU1hDwdjxaO9ekOpA/uPLCypNy5tj91CRnMsfPRLeEOAMNbISf3rICvyw DgCPuiLx6fFCVW3OeFwQq3yQD88WBshe2Vm1Cw/EXsHg+yArQTNJaLpQK4vjo/QoyZ 18qdHH+YSpQeA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Charlene Liu , Mohit Bawa , Chenyu Chen , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 161/844] drm/amd/display: Fix dsc eDP issue Date: Sat, 28 Feb 2026 12:21:14 -0500 Message-ID: <20260228173244.1509663-162-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Charlene Liu [ Upstream commit 878a4b73c11111ff5f820730f59a7f8c6fd59374 ] [why] Need to add function hook check before use Reviewed-by: Mohit Bawa Signed-off-by: Charlene Liu Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c b/dr= ivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c index 5896ce5511ab1..9f7087ac41f21 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c @@ -1797,6 +1797,9 @@ static void disable_vga_and_power_gate_all_controller= s( struct timing_generator *tg; struct dc_context *ctx =3D dc->ctx; =20 + if (dc->caps.ips_support) + return; + for (i =3D 0; i < dc->res_pool->timing_generator_count; i++) { tg =3D dc->res_pool->timing_generators[i]; =20 @@ -1873,13 +1876,16 @@ static void clean_up_dsc_blocks(struct dc *dc) /* disable DSC in OPTC */ if (i < dc->res_pool->timing_generator_count) { tg =3D dc->res_pool->timing_generators[i]; - tg->funcs->set_dsc_config(tg, OPTC_DSC_DISABLED, 0, 0); + if (tg->funcs->set_dsc_config) + tg->funcs->set_dsc_config(tg, OPTC_DSC_DISABLED, 0, 0); } /* disable DSC in stream encoder */ if (i < dc->res_pool->stream_enc_count) { se =3D dc->res_pool->stream_enc[i]; - se->funcs->dp_set_dsc_config(se, OPTC_DSC_DISABLED, 0, 0); - se->funcs->dp_set_dsc_pps_info_packet(se, false, NULL, true); + if (se->funcs->dp_set_dsc_config) + se->funcs->dp_set_dsc_config(se, OPTC_DSC_DISABLED, 0, 0); + if (se->funcs->dp_set_dsc_pps_info_packet) + se->funcs->dp_set_dsc_pps_info_packet(se, false, NULL, true); } /* disable DSC block */ if (dccg->funcs->set_ref_dscclk) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 81E4E372235; Sat, 28 Feb 2026 17:35:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300144; cv=none; b=hcxjzWiraEz2GnSaagwIcocHKX9lYadG6TVy1RfdJfWanj2Oxa6zfcmTxhP2fOk74U1M48jphR69ZLfpyqOgq62bhixLkMRLCzVYGctf0L+ZykbkYzw4B51w/AVE/sipVWkBtqMsXEm3a+udvqwGWbubbe96L4uWrFJvoV+64Ww= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300144; c=relaxed/simple; bh=VcPYe4j20vtqahNKHjlKZcdTbEXtbZLF6tHgSShtbXE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=opU5RAFo6ZIhsvKQIWCKYvJ1bBCWStdJqPNhvhjJSLar5ibrPs1Mbnma4fW36f9zsR8ScUYReMlwMTgJQI26YQsp0CzVjreds6jEcrv0AYcNhsYMEsge1tuWL/2FisvgJxx13TPA/E6XEv3GAr2j5sY6vjNkmzktnnYbCtX4Nlk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ovcZ+1Bt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ovcZ+1Bt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADC68C19424; Sat, 28 Feb 2026 17:35:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300144; bh=VcPYe4j20vtqahNKHjlKZcdTbEXtbZLF6tHgSShtbXE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ovcZ+1BtVEXvTx6Rx22Vme9evNItFb+1ExY4ub2YLAs29v9nv6iDqatvlJjSHDb5z T3auG9ceH0ZSdQb6XKukOboKsjSMiacULEqvTZ+JvoEcIqoBL3zbsMIjew4f2gFN7F 8UaVHYUNABjXQgXolt3d0brVdBuFnlnotAHwGKbOI6L+WlIniAZZ6wtufjujc02vsS JgnHImDqzi2luDpbWv8sX9tI9xjGXHqdImprI4l87zSPF8XvGdRrJ4qjfHz+J8UUJh Z4If9/LJ5IpM1UFbY5xjcKLV+ibZ/utO14849FMmvbK4tbYCNZzEbuqUjZXd2ynenR 9jVWLG52paVFw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alex Deucher , =?UTF-8?q?Timur=20Krist=C3=B3f?= , Sasha Levin Subject: [PATCH 6.19 162/844] drm/amdgpu: avoid a warning in timedout job handler Date: Sat, 28 Feb 2026 12:21:15 -0500 Message-ID: <20260228173244.1509663-163-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Alex Deucher [ Upstream commit c8cf9ddc549fb93cb5a35f3fe23487b1e6707e74 ] Only set an error on the fence if the fence is not signalled. We can end up with a warning if the per queue reset path signals the fence and sets an error as part of the reset, but fails to recover. Reviewed-by: Timur Krist=C3=B3f Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/= amdgpu/amdgpu_job.c index 7ccb724b2488d..aaf5477fcd7ac 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c @@ -147,7 +147,8 @@ static enum drm_gpu_sched_stat amdgpu_job_timedout(stru= ct drm_sched_job *s_job) dev_err(adev->dev, "Ring %s reset failed\n", ring->sched.name); } =20 - dma_fence_set_error(&s_job->s_fence->finished, -ETIME); + if (dma_fence_get_status(&s_job->s_fence->finished) =3D=3D 0) + dma_fence_set_error(&s_job->s_fence->finished, -ETIME); =20 if (amdgpu_device_should_recover_gpu(ring->adev)) { struct amdgpu_reset_context reset_context; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C435F341077; Sat, 28 Feb 2026 17:35:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300145; cv=none; b=RoAieJgIsPqPr9afxGlNfgbTZuonqfFl626EIxzQwwFu3WfZsde1Y+ZG7I6d2XkDdfrd4PsqvKmBfR9afriwahkJV9LGg6eDumgMWmvK81cdjna+TJya7KCskNEe4gWGvBiygCvJmijc13WphQAbIgN7yavnaeVe8/lo8rZipLc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300145; c=relaxed/simple; bh=oS4fknAdcl5oosDLqZRQcGl5uEH4C80criT2DF/0Hyg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=o2ocRD9BjJBU6zUZm5iHGlcd6bYBWyYR5GtdamvyHWrNsfBvrifnus/xLNlA2iQKiwBl/C/9mz/9/S8W9ZTZXp8KIdubqyjGLMKQgxPFA1xGYoX1dtnYGslggNF/f5Yeolb+Io02fDcTcY1FMGYHw4hoeiXfOI1E+T1tCzCEeD0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=owG+kbLM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="owG+kbLM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A9FDC2BC87; Sat, 28 Feb 2026 17:35:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300145; bh=oS4fknAdcl5oosDLqZRQcGl5uEH4C80criT2DF/0Hyg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=owG+kbLM5GOz/jEwiIaA8MKMuhA/XhGphl1VVZCpWKWP2aNJcWmWHFz600tWpgsfJ TjkPr+QyTkfArfDCayMauMGdUB4ClEl5Mi/HJTiUtz5ztZAXwGnhmgcmy1DUSAR8+u cw7vBVTgyyuTkbudmXJQNvACB+m9emJZ0uJa+c/T3UzI5xCM0Lko0OzGkS6He2oVMh 80Eu7ZgDFmfhoHrJl/NGAg9ULXCujZI+okHW17XLpATOldsvJy0LmpPUlMWXbjAFyo vvmW5EML5RB4pAqIdjtcYkHZzTaLgQPKErpHWIbABrCCr+zTgOyXe7Vsb6MUEx9EYO jr+pbQNhqkuKg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dmytro Laktyushkin , Charlene Liu , Chenyu Chen , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 163/844] drm/amd/display: Add signal type check for dcn401 get_phyd32clk_src Date: Sat, 28 Feb 2026 12:21:16 -0500 Message-ID: <20260228173244.1509663-164-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dmytro Laktyushkin [ Upstream commit c979d8db7b0f293111f2e83795ea353c8ed75de9 ] Trying to access link enc on a dpia link will cause a crash otherwise Reviewed-by: Charlene Liu Signed-off-by: Dmytro Laktyushkin Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c b/dr= ivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c index e1f5b1a34cde8..f04cbdb3d3814 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c @@ -916,10 +916,10 @@ static void dcn401_enable_stream_calc( pipe_ctx->stream->link->cur_link_settings.lane_count; uint32_t active_total_with_borders; =20 - if (dc->link_srv->dp_is_128b_132b_signal(pipe_ctx)) + if (dc->link_srv->dp_is_128b_132b_signal(pipe_ctx)) { *dp_hpo_inst =3D pipe_ctx->stream_res.hpo_dp_stream_enc->inst; - - *phyd32clk =3D get_phyd32clk_src(pipe_ctx->stream->link); + *phyd32clk =3D get_phyd32clk_src(pipe_ctx->stream->link); + } =20 if (dc_is_tmds_signal(pipe_ctx->stream->signal)) dcn401_calculate_dccg_tmds_div_value(pipe_ctx, tmds_div); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 77041373132; Sat, 28 Feb 2026 17:35:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300146; cv=none; b=PJx1xdozFPz2qKtTAj9IYLc6KaxEHQ+tzzF5QtCBa+kCN1UInq1KyBhqsMfUObZsV+BvYB+cjvJG9Rr8y71Zg4qg1MyQKaFklJ4xK6Li3CjyrPaaukceFG+S/3ZWyMG1tpwI4f9jd1nFAyrPjEWnV/yliMhpXVUhcpOvwMjLMFM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300146; c=relaxed/simple; bh=qaTnnGnv0qf7d3+3WaIFVnalRL3psPma1EcZJOwyL6o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tBJfvWLHslQcLlTU13ZxmqSU7kiUTefY2oP5aeB2YKYD7O4qYJUKyolAzN2Sat+8adMzOLFoqe0MmdkbHcfDyQef6JwfccfUZMqHLBW6pJtxZeFMkmBN6EbXgtRId+bGmq7GowUS+rgxkLAqB1dCnIOBbawhMkx2hOrcWjAXk2A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fhmyZyFQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fhmyZyFQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4B91C116D0; Sat, 28 Feb 2026 17:35:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300146; bh=qaTnnGnv0qf7d3+3WaIFVnalRL3psPma1EcZJOwyL6o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fhmyZyFQyvT8I/nWzrCULgAMEEOhLkK8knBROSlgMI5lPp4Sr0i2EUIpx1qbD6Ex7 pr5snq9Wm/W2pObcmk3qnhpyia8MhXu7gPcy3QpYUNVxDvqvPVsmbbfTpqmS0iXuO9 QVGJ+djHYdS8Xlt4kT/uyUD1gcjQCFd76Y/mA4a50uBqyKJi5lBXsBhuHbrmieIy1z uckVwDEl5Pofg8icinndPl1cLxINlaXOhhnL+KRXU/hy0SAoKye0dcCDsOIKavMkaX Nn4L69qyQtqGLwn3IzRIP4ZyF4nj6F2SK4n/NzsQnwQKtNz+SnCmFoUhH+KOWms0NY bdnZkVJ6uhA8Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Srinivasan Shanmugam , Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , Sasha Levin Subject: [PATCH 6.19 164/844] drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v4 Date: Sat, 28 Feb 2026 12:21:17 -0500 Message-ID: <20260228173244.1509663-165-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Srinivasan Shanmugam [ Upstream commit bd8150a1b3370a9f7761c5814202a3fe5a79f44f ] This commit simplifies the amdgpu_gem_va_ioctl function, key updates include: - Moved the logic for managing the last update fence directly into amdgpu_gem_va_update_vm. - Introduced checks for the timeline point to enable conditional replacement or addition of fences. v2: Addressed review comments from Christian. v3: Updated comments (Christian). v4: The previous version selected the fence too early and did not manage its reference correctly, which could lead to stale or freed fences being us= ed. This resulted in refcount underflows and could crash when updating GPU timelines. The fence is now chosen only after the VA mapping work is completed, an= d its reference is taken safely. After exporting it to the VM timeline syncob= j, the driver always drops its local fence reference, ensuring balanced refcou= nting and avoiding use-after-free on dma_fence. Crash signature: [ 205.828135] refcount_t: underflow; use-after-free. [ 205.832963] WARNING: CPU: 30 PID: 7274 at lib/refcount.c:28 refcount_wa= rn_saturate+0xbe/0x110 ... [ 206.074014] Call Trace: [ 206.076488] [ 206.078608] amdgpu_gem_va_ioctl+0x6ea/0x740 [amdgpu] [ 206.084040] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.089994] drm_ioctl_kernel+0x86/0xe0 [drm] [ 206.094415] drm_ioctl+0x26e/0x520 [drm] [ 206.098424] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.104402] amdgpu_drm_ioctl+0x4b/0x80 [amdgpu] [ 206.109387] __x64_sys_ioctl+0x96/0xe0 [ 206.113156] do_syscall_64+0x66/0x2d0 ... [ 206.553351] BUG: unable to handle page fault for address: ffffffffc0dfd= e90 ... [ 206.553378] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0 ... [ 206.553405] Call Trace: [ 206.553409] [ 206.553415] ? __pfx_drm_sched_fence_free_rcu+0x10/0x10 [gpu_sched] [ 206.553424] dma_fence_signal+0x30/0x60 [ 206.553427] drm_sched_job_done.isra.0+0x123/0x150 [gpu_sched] [ 206.553434] dma_fence_signal_timestamp_locked+0x6e/0xe0 [ 206.553437] dma_fence_signal+0x30/0x60 [ 206.553441] amdgpu_fence_process+0xd8/0x150 [amdgpu] [ 206.553854] sdma_v4_0_process_trap_irq+0x97/0xb0 [amdgpu] [ 206.554353] edac_mce_amd(E) ee1004(E) [ 206.554270] amdgpu_irq_dispatch+0x150/0x230 [amdgpu] [ 206.554702] amdgpu_ih_process+0x6a/0x180 [amdgpu] [ 206.555101] amdgpu_irq_handler+0x23/0x60 [amdgpu] [ 206.555500] __handle_irq_event_percpu+0x4a/0x1c0 [ 206.555506] handle_irq_event+0x38/0x80 [ 206.555509] handle_edge_irq+0x92/0x1e0 [ 206.555513] __common_interrupt+0x3e/0xb0 [ 206.555519] common_interrupt+0x80/0xa0 [ 206.555525] [ 206.555527] ... [ 206.555650] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0 ... [ 206.555667] Kernel panic - not syncing: Fatal exception in interrupt Link: https://patchwork.freedesktop.org/patch/654669/ Cc: Alex Deucher Cc: Christian K=C3=B6nig Suggested-by: Christian K=C3=B6nig Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian K=C3=B6nig Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 135 ++++++++++++++---------- 1 file changed, 82 insertions(+), 53 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/= amdgpu/amdgpu_gem.c index 5a93cbadc4f44..f30e32fbff99a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -112,47 +112,6 @@ amdgpu_gem_update_timeline_node(struct drm_file *filp, return 0; } =20 -static void -amdgpu_gem_update_bo_mapping(struct drm_file *filp, - struct amdgpu_bo_va *bo_va, - uint32_t operation, - uint64_t point, - struct dma_fence *fence, - struct drm_syncobj *syncobj, - struct dma_fence_chain *chain) -{ - struct amdgpu_bo *bo =3D bo_va ? bo_va->base.bo : NULL; - struct amdgpu_fpriv *fpriv =3D filp->driver_priv; - struct amdgpu_vm *vm =3D &fpriv->vm; - struct dma_fence *last_update; - - if (!syncobj) - return; - - /* Find the last update fence */ - switch (operation) { - case AMDGPU_VA_OP_MAP: - case AMDGPU_VA_OP_REPLACE: - if (bo && (bo->tbo.base.resv =3D=3D vm->root.bo->tbo.base.resv)) - last_update =3D vm->last_update; - else - last_update =3D bo_va->last_pt_update; - break; - case AMDGPU_VA_OP_UNMAP: - case AMDGPU_VA_OP_CLEAR: - last_update =3D fence; - break; - default: - return; - } - - /* Add fence to timeline */ - if (!point) - drm_syncobj_replace_fence(syncobj, last_update); - else - drm_syncobj_add_point(syncobj, chain, last_update, point); -} - static vm_fault_t amdgpu_gem_fault(struct vm_fault *vmf) { struct ttm_buffer_object *bo =3D vmf->vma->vm_private_data; @@ -761,16 +720,19 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, struct amdgpu_bo_va *bo_va, uint32_t operation) { - struct dma_fence *fence =3D dma_fence_get_stub(); + struct dma_fence *clear_fence =3D dma_fence_get_stub(); + struct dma_fence *last_update =3D NULL; int r; =20 if (!amdgpu_vm_ready(vm)) - return fence; + return clear_fence; =20 - r =3D amdgpu_vm_clear_freed(adev, vm, &fence); + /* First clear freed BOs and get a fence for that work, if any. */ + r =3D amdgpu_vm_clear_freed(adev, vm, &clear_fence); if (r) goto error; =20 + /* For MAP/REPLACE we also need to update the BO mappings. */ if (operation =3D=3D AMDGPU_VA_OP_MAP || operation =3D=3D AMDGPU_VA_OP_REPLACE) { r =3D amdgpu_vm_bo_update(adev, bo_va, false); @@ -778,13 +740,59 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, goto error; } =20 + /* Always update PDEs after we touched the mappings. */ r =3D amdgpu_vm_update_pdes(adev, vm, false); + if (r) + goto error; + + /* + * Decide which fence represents the "last update" for this VM/BO: + * + * - For MAP/REPLACE we want the PT update fence, which is tracked as + * either vm->last_update (for always-valid BOs) or bo_va->last_pt_upda= te + * (for per-BO updates). + * + * - For UNMAP/CLEAR we rely on the fence returned by + * amdgpu_vm_clear_freed(), which already covers the page table work + * for the removed mappings. + */ + switch (operation) { + case AMDGPU_VA_OP_MAP: + case AMDGPU_VA_OP_REPLACE: + if (bo_va && bo_va->base.bo) { + if (amdgpu_vm_is_bo_always_valid(vm, bo_va->base.bo)) { + if (vm->last_update) + last_update =3D dma_fence_get(vm->last_update); + } else { + if (bo_va->last_pt_update) + last_update =3D dma_fence_get(bo_va->last_pt_update); + } + } + break; + case AMDGPU_VA_OP_UNMAP: + case AMDGPU_VA_OP_CLEAR: + if (clear_fence) + last_update =3D dma_fence_get(clear_fence); + break; + default: + break; + } =20 error: if (r && r !=3D -ERESTARTSYS) DRM_ERROR("Couldn't update BO_VA (%d)\n", r); =20 - return fence; + /* + * If we managed to pick a more specific last-update fence, prefer it + * over the generic clear_fence and drop the extra reference to the + * latter. + */ + if (last_update) { + dma_fence_put(clear_fence); + return last_update; + } + + return clear_fence; } =20 int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, @@ -810,6 +818,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *d= ata, uint64_t vm_size; int r =3D 0; =20 + /* Validate virtual address range against reserved regions. */ if (args->va_address < AMDGPU_VA_RESERVED_BOTTOM) { dev_dbg(dev->dev, "va_address 0x%llx is in reserved area 0x%llx\n", @@ -843,6 +852,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *d= ata, return -EINVAL; } =20 + /* Validate operation type. */ switch (args->operation) { case AMDGPU_VA_OP_MAP: case AMDGPU_VA_OP_UNMAP: @@ -866,6 +876,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *d= ata, abo =3D NULL; } =20 + /* Add input syncobj fences (if any) for synchronization. */ r =3D amdgpu_gem_add_input_fence(filp, args->input_fence_syncobj_handles, args->num_syncobj_handles); @@ -888,6 +899,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *d= ata, goto error; } =20 + /* Resolve the BO-VA mapping for this VM/BO combination. */ if (abo) { bo_va =3D amdgpu_vm_bo_find(&fpriv->vm, abo); if (!bo_va) { @@ -900,6 +912,11 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *= data, bo_va =3D NULL; } =20 + /* + * Prepare the timeline syncobj node if the user requested a VM + * timeline update. This only allocates/looks up the syncobj and + * chain node; the actual fence is attached later. + */ r =3D amdgpu_gem_update_timeline_node(filp, args->vm_timeline_syncobj_out, args->vm_timeline_point, @@ -931,18 +948,30 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void = *data, default: break; } + + /* + * Once the VA operation is done, update the VM and obtain the fence + * that represents the last relevant update for this mapping. This + * fence can then be exported to the user-visible VM timeline. + */ if (!r && !(args->flags & AMDGPU_VM_DELAY_UPDATE) && !adev->debug_vm) { fence =3D amdgpu_gem_va_update_vm(adev, &fpriv->vm, bo_va, args->operation); =20 - if (timeline_syncobj) - amdgpu_gem_update_bo_mapping(filp, bo_va, - args->operation, - args->vm_timeline_point, - fence, timeline_syncobj, - timeline_chain); - else - dma_fence_put(fence); + if (timeline_syncobj && fence) { + if (!args->vm_timeline_point) { + /* Replace the existing fence when no point is given. */ + drm_syncobj_replace_fence(timeline_syncobj, + fence); + } else { + /* Attach the last-update fence at a specific point. */ + drm_syncobj_add_point(timeline_syncobj, + timeline_chain, + fence, + args->vm_timeline_point); + } + } + dma_fence_put(fence); =20 } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FD66373149; Sat, 28 Feb 2026 17:35:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300147; cv=none; b=bCI2YUor5pXvwC9Fa+RqcmpGX6Hqp4wy4EXtZEPmxaoBF5MQhyLUmKj/SxoVbk/VoD+g5Xgb8bdozqbp1/JlrvZNhLCR+bohMu8eUVcFtGQ1iPOjQqfu17JWZ7fIONDNaGNGUOvjqp6gV8tTCzJg0WYmu259u238GKWrx7VUxxM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300147; c=relaxed/simple; bh=wdudqbYngq88C0TzinB/h0Ifxxl/S8VyroMgpAofPbA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TGC24WDC0M51SeWi2lYEBqrwQBcAsjm9knEX3wPswx0tiqZyeNmjdQzg+8KN0FJ7gYJdkVhjw3aXBUeO2QLdwI+iswFKCP2rWpsU0pugvY1oD8t+9axGPD42Hya9fMJBEpkkH/W8ItWTkzOcE+Hl6R+cbL0nkkD9kzr129PPo08= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HxfO8uVi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HxfO8uVi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93FAFC19423; Sat, 28 Feb 2026 17:35:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300147; bh=wdudqbYngq88C0TzinB/h0Ifxxl/S8VyroMgpAofPbA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HxfO8uVi2iTHW5aDjiCxGS/NpH+7AEqSzq4XT92+yHAugrtAz8yLwZwPeq+AtMnQd AgePOv84CMnm1OsN5lWDBGKW/Zz94e8b9Ux1ZdnAC3Z9326eOlQqgNga8s64glvKkF h3jv/JmmnDu+CYNubdpbizNl7tfC5CZ4pmbogPW51cnpL7mCg/C08oUqnMUhzARVG8 UySPczB3fyxeFRoYDBfnGiUPm03wiyvl970TzUZk8n396oVThkDEo2VtcvbVX0rYnW 7B3THiWdjyKtV3cHuLZfuXw/1JB2xNPKvBciQqCOqPPCKgC71rNvnU6/bPmU/9zqZV CXa/rYxyFCLSg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Joey Bednar , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 165/844] HID: apple: Add "SONiX KN85 Keyboard" to the list of non-apple keyboards Date: Sat, 28 Feb 2026 12:21:18 -0500 Message-ID: <20260228173244.1509663-166-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Joey Bednar [ Upstream commit 7273acfd0aef106093a8ffa3b4973eb70e5a3799 ] The SoNiX KN85 keyboard identifies as the "Apple, Inc. Aluminium Keyboard" and is not recognized as a non-apple keyboard. Adding "SoNiX KN85 Keyboard" to the list of non-apple keyboards fixes the function keys. Signed-off-by: Joey Bednar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/hid-apple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c index 57da4f86a9fa7..233e367cce1d1 100644 --- a/drivers/hid/hid-apple.c +++ b/drivers/hid/hid-apple.c @@ -354,6 +354,7 @@ static const struct apple_key_translation swapped_fn_le= ftctrl_keys[] =3D { }; =20 static const struct apple_non_apple_keyboard non_apple_keyboards[] =3D { + { "SONiX KN85 Keyboard" }, { "SONiX USB DEVICE" }, { "SONiX AK870 PRO" }, { "Keychron" }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A064371465; Sat, 28 Feb 2026 17:35:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300148; cv=none; b=C8FHNUSzIDVyOpOjawalKVeg51W+rRKXtbqi6mUAX+qXdc3HSAu6i4fFpDHK+/MzqHnwmWMMMG7qD3cMRyUw4WuGeBBIClB/SnrGJSGTYtaUgQflIR3Oeb/0aCuJzs5++C8GgJQ3nXoFJZXUyC6yJUGWGfj9YBKMMoQXUAbBc9o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300148; c=relaxed/simple; bh=SV+RUt3egBAGzwVZAjSIayxnq11Eu6kohGuhg3MCPiM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QYgdRkoZdhpHI0OC12hesrs9JCbUnNTjpm3r0/l8QDuzEDiNiQehHpRO+GvLs596fHdqn0dad4xRl3GOis0WBkWk97tCleoRyPFnE4XxLD9fDvBRmg9eII/iaL5GTYigNfGWAtV1SUjlliK8V8qc7n2uwU9JzyIzciN2RlSoBsA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U0ynF0Lk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U0ynF0Lk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DAC8C19425; Sat, 28 Feb 2026 17:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300148; bh=SV+RUt3egBAGzwVZAjSIayxnq11Eu6kohGuhg3MCPiM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U0ynF0LkUsuHE0uvnygIGJRrS/ujkQzTXpLMXpCQezMYL2827lIpdlgO/JILKQDYM JHax5ZQRTnEQw2NrTtEo4Pv64pe2ykwzS+07rBuopMKu6nEMqmmFnSEqcdxz34TC/b zQd7pWQlbcGflrgt21KeuAKj969iHbSqAWwhz7+x6oAo5dyfMn4o5NZURlnjm0rUCE Kbmt6cNnFzyf3anTRespJCD/VGrCp6Fde/mebzXBDRxJReIDRgxzQyOXGQvtxavt4M dRFIB1IU3Rsxmq4K9KQIGbPRb0n702iPguazTNY5T8cGljabbFF6GKL5UmAAAxvNve zBafeF44WR5Jg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Tomasz=20Paku=C5=82a?= , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 166/844] HID: pidff: Do not set out of range trigger button Date: Sat, 28 Feb 2026 12:21:19 -0500 Message-ID: <20260228173244.1509663-167-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Tomasz Paku=C5=82a [ Upstream commit e01a029654f7fb67d7151365410aa22be4e63dbe ] Some games (mainly observed with Kylotonn's WRC Serises) set trigger button to a random value, or always the same one, out of range. I observed 307 and other values but, for example, my Moza R9 only exposes 128 buttons AND it's trigger button field is 8-bit. This causes errors to appear in dmesg. Only set the trigger button and trigger interval in the trigger button is in range of the field. Signed-off-by: Tomasz Paku=C5=82a Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/usbhid/hid-pidff.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c index 95377c5f63356..a4e700b40ba9b 100644 --- a/drivers/hid/usbhid/hid-pidff.c +++ b/drivers/hid/usbhid/hid-pidff.c @@ -523,9 +523,19 @@ static void pidff_set_effect_report(struct pidff_devic= e *pidff, pidff_set_duration(&pidff->set_effect[PID_DURATION], effect->replay.length); =20 - pidff->set_effect[PID_TRIGGER_BUTTON].value[0] =3D effect->trigger.button; - pidff_set_time(&pidff->set_effect[PID_TRIGGER_REPEAT_INT], - effect->trigger.interval); + /* Some games set this to random values that can be out of range */ + s32 trigger_button_max =3D + pidff->set_effect[PID_TRIGGER_BUTTON].field->logical_maximum; + if (effect->trigger.button <=3D trigger_button_max) { + pidff->set_effect[PID_TRIGGER_BUTTON].value[0] =3D + effect->trigger.button; + pidff_set_time(&pidff->set_effect[PID_TRIGGER_REPEAT_INT], + effect->trigger.interval); + } else { + pidff->set_effect[PID_TRIGGER_BUTTON].value[0] =3D 0; + pidff->set_effect[PID_TRIGGER_REPEAT_INT].value[0] =3D 0; + } + pidff->set_effect[PID_GAIN].value[0] =3D pidff->set_effect[PID_GAIN].field->logical_maximum; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61C99373BF6; Sat, 28 Feb 2026 17:35:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300149; cv=none; b=T/rnNZf2EE6f8US31GMo73a6SP3SB/vNbl/rhesEYcCJuKVa3Rku8Y2FYZ2T3EhZrau4uOSeQ3JYI7LWgGiZSj7aeCyjHv32u4g+MRwcBw1EgE/ndKqEAOm/OT2S2DiXDdQHFKoy9UnmCHIkRN56rq/azTVeklsEpBgnC6ErxeU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300149; c=relaxed/simple; bh=hkP8rxH0F6ii2fNCCVUvAtZjHRzD7vUzYkbdE0yLUZg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SP4JJ6JXbAXasRg0XAAX9seU483vbOZfEcdCq/s/bFak22oIVkZEzpTlnq1PcnXxHMNg1WQjFp4ELjAuizFYNXRYHiyxE7rZ9+VZreXKJL2tXuA4UEvDBl1IUBI3iyH3z6ShSdz6dUoov8hcsYVnP5hdWfTzOalB98NhXLcyg5U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JK+w/X4K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JK+w/X4K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4847BC19423; Sat, 28 Feb 2026 17:35:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300149; bh=hkP8rxH0F6ii2fNCCVUvAtZjHRzD7vUzYkbdE0yLUZg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JK+w/X4K16SbRCRY2Tku0zfw7benScw07G2vDDKJqnWzOeyV38C4wdlrPxI3YXjFx 5DCg1S4FANITkzNUjsydn4OQkHmNz3wDKCvGzrzhnL7ZEV+DqVWH/PfgDn8RHJGGj1 QrnIP/M893V0wVgpOSPndfns5M2+L5VLXZkJZGFEZQ0Bg8/jaoiXIxyvIbgnxOuQfP JqbcR/WpGlg4HlYLyR1/8l9CABaXejifU7HYL8HmjKClZELHguZWJd/HsgiaGfiHj8 VMixL0ShXNb4hMXTaESjrCV/sTEzyu286n3kTVkshBtdPFl+DAVrdfD1i6eegwApod cGjgilFlrjcCg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Brian Howard , Kris Fredrick , Andrei Shumailov , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 167/844] HID: multitouch: add quirks for Lenovo Yoga Book 9i Date: Sat, 28 Feb 2026 12:21:20 -0500 Message-ID: <20260228173244.1509663-168-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Brian Howard [ Upstream commit 822bc5b3744b0b2c2c9678aa1d80b2cf04fdfabf ] The Lenovo Yoga Book 9i is a dual-screen laptop, with a single composite USB device providing both touch and tablet interfaces for both screens. All inputs report through a single device, differentiated solely by report numbers. As there is no way for udev to differentiate the inputs based on USB vendor/product ID or interface numbers, custom naming is required to match against for downstream configuration. A firmware bug also results in an erroneous InRange message report being received after the stylus leaves proximity, blocking later touch events. Add required quirks for Gen 8 to Gen 10 models, including a new quirk providing for custom input device naming and dropping erroneous InRange reports. Signed-off-by: Brian Howard Tested-by: Brian Howard Tested-by: Kris Fredrick Reported-by: Andrei Shumailov Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D220386 Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-multitouch.c | 72 ++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+) diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 9c2bf584d9f6f..5a18cb41e6d79 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -841,6 +841,7 @@ #define USB_DEVICE_ID_LENOVO_X1_TAB3 0x60b5 #define USB_DEVICE_ID_LENOVO_X12_TAB 0x60fe #define USB_DEVICE_ID_LENOVO_X12_TAB2 0x61ae +#define USB_DEVICE_ID_LENOVO_YOGABOOK9I 0x6161 #define USB_DEVICE_ID_LENOVO_OPTICAL_USB_MOUSE_600E 0x600e #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D 0x608d #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019 0x6019 diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index b1c3ef1290587..f21850f7d89e4 100644 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -76,6 +76,7 @@ MODULE_LICENSE("GPL"); #define MT_QUIRK_DISABLE_WAKEUP BIT(21) #define MT_QUIRK_ORIENTATION_INVERT BIT(22) #define MT_QUIRK_APPLE_TOUCHBAR BIT(23) +#define MT_QUIRK_YOGABOOK9I BIT(24) =20 #define MT_INPUTMODE_TOUCHSCREEN 0x02 #define MT_INPUTMODE_TOUCHPAD 0x03 @@ -231,6 +232,7 @@ static void mt_post_parse(struct mt_device *td, struct = mt_application *app); #define MT_CLS_RAZER_BLADE_STEALTH 0x0112 #define MT_CLS_SMART_TECH 0x0113 #define MT_CLS_APPLE_TOUCHBAR 0x0114 +#define MT_CLS_YOGABOOK9I 0x0115 #define MT_CLS_SIS 0x0457 =20 #define MT_DEFAULT_MAXCONTACT 10 @@ -427,6 +429,14 @@ static const struct mt_class mt_classes[] =3D { .quirks =3D MT_QUIRK_NOT_SEEN_MEANS_UP | MT_QUIRK_ALWAYS_VALID | MT_QUIRK_CONTACT_CNT_ACCURATE, + }, + { .name =3D MT_CLS_YOGABOOK9I, + .quirks =3D MT_QUIRK_ALWAYS_VALID | + MT_QUIRK_FORCE_MULTI_INPUT | + MT_QUIRK_SEPARATE_APP_REPORT | + MT_QUIRK_HOVERING | + MT_QUIRK_YOGABOOK9I, + .export_all_inputs =3D true }, { } }; @@ -1576,6 +1586,38 @@ static void mt_report(struct hid_device *hid, struct= hid_report *report) if (rdata && rdata->is_mt_collection) return mt_touch_report(hid, rdata); =20 + /* Lenovo Yoga Book 9i requires consuming and dropping certain bogus repo= rts */ + if (rdata && rdata->application && + (rdata->application->quirks & MT_QUIRK_YOGABOOK9I)) { + + bool all_zero_report =3D true; + + for (int f =3D 0; f < report->maxfield && all_zero_report; f++) { + struct hid_field *fld =3D report->field[f]; + + for (int i =3D 0; i < fld->report_count; i++) { + unsigned int usage =3D fld->usage[i].hid; + + if (usage =3D=3D HID_DG_INRANGE || + usage =3D=3D HID_DG_TIPSWITCH || + usage =3D=3D HID_DG_BARRELSWITCH || + usage =3D=3D HID_DG_BARRELSWITCH2 || + usage =3D=3D HID_DG_CONTACTID || + usage =3D=3D HID_DG_TILT_X || + usage =3D=3D HID_DG_TILT_Y) { + + if (fld->value[i] !=3D 0) { + all_zero_report =3D false; + break; + } + } + } + } + + if (all_zero_report) + return; + } + if (field && field->hidinput && field->hidinput->input) input_sync(field->hidinput->input); } @@ -1772,6 +1814,30 @@ static int mt_input_configured(struct hid_device *hd= ev, struct hid_input *hi) break; } =20 + /* Lenovo Yoga Book 9i requires custom naming to allow differentiation in= udev */ + if (hi->report && td->mtclass.quirks & MT_QUIRK_YOGABOOK9I) { + switch (hi->report->id) { + case 48: + suffix =3D "Touchscreen Top"; + break; + case 56: + suffix =3D "Touchscreen Bottom"; + break; + case 20: + suffix =3D "Stylus Top"; + break; + case 40: + suffix =3D "Stylus Bottom"; + break; + case 80: + suffix =3D "Emulated Touchpad"; + break; + default: + suffix =3D ""; + break; + } + } + if (suffix) { hi->input->name =3D devm_kasprintf(&hdev->dev, GFP_KERNEL, "%s %s", hdev->name, suffix); @@ -2277,6 +2343,12 @@ static const struct hid_device_id mt_devices[] =3D { USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X12_TAB2) }, =20 + /* Lenovo Yoga Book 9i */ + { .driver_data =3D MT_CLS_YOGABOOK9I, + HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, + USB_VENDOR_ID_LENOVO, + USB_DEVICE_ID_LENOVO_YOGABOOK9I) }, + /* Logitech devices */ { .driver_data =3D MT_CLS_NSMU, HID_DEVICE(BUS_BLUETOOTH, HID_GROUP_MULTITOUCH_WIN_8, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29A36373C0F; Sat, 28 Feb 2026 17:35:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300150; cv=none; b=kwbvHPgQylXBRl7OgjCOP8siStLRCki8fphAGr1tJJjWwxUJ694NZD9rr/BSM5l6dgJ0r6F79ZOckGQSPqR85wCI9brEQRuP+mgIQxHTOUllJCdOhucikyF4mxNkMJtwrZPB77B6uP33qOkIBMqJEZLneLeyL4GID6xPbCq8Cl8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300150; c=relaxed/simple; bh=cLAisaLoAcnoaoTX3ZrNJXG1gYgYHnAZhB+sh2Pe5r8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bVbCEk+JCNlNiYCpg8bzYwUG1+DVBjz/yfOUC8QRB/eYFySUAVea3G8ecS3mu8XUTXP5lT/8WXkztpR3FzgYppzeZvMcxardxIP4WTEHleU66dsQD6vq6jNHFjkTxsxKJLvVXrsqI3tBn/6CUXe6ZCzTuQqOa3dTzzklhEVyB1o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LDorU3Un; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LDorU3Un" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EFF2C19424; Sat, 28 Feb 2026 17:35:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300150; bh=cLAisaLoAcnoaoTX3ZrNJXG1gYgYHnAZhB+sh2Pe5r8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LDorU3UnyUEDj8/NE2X1+ihuC7jIDtPMwm2KIvFQ+AoVTmtbItyJNoTKlZQQQFyDB du7VmO9RlaiCCsiSMoC18gFpEB/A421/PVaP2jvo9dBVMCwvHRVqeoY6Uyk3rPegQ9 KQT9D4o+RryeOUC0EPtzFBJ3pQmfCy5ayVuwNgFefzyDg2p84MrJASccKq62fA4R2m AvzjgyIrFRlXkxIISlRCxM+kmbam8vYCxiMqc96jZOE/VPKqGkJYPqT/L97IU85leQ O6xIAvMIU0+W2HQ3yr+e4EjJe2vC2/1tYFnbEXyjd+5WTfmO7qdT6HrWixxHDpUjVX ryX0po319N30A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: YuBiao Wang , Victor Skvortsov , Gavin Wan , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 168/844] drm/amdgpu: Skip loading SDMA_RS64 in VF Date: Sat, 28 Feb 2026 12:21:21 -0500 Message-ID: <20260228173244.1509663-169-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: YuBiao Wang [ Upstream commit 39c21b81112321cbe1267b02c77ecd2161ce19aa ] VFs use the PF SDMA ucode and are unable to load SDMA_RS64. Signed-off-by: YuBiao Wang Signed-off-by: Victor Skvortsov Reviewed-by: Gavin Wan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c b/drivers/gpu/drm/amd= /amdgpu/amdgpu_virt.c index 47a6ce4fdc744..292e2706286a1 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c @@ -1261,6 +1261,7 @@ bool amdgpu_virt_fw_load_skip_check(struct amdgpu_dev= ice *adev, uint32_t ucode_i || ucode_id =3D=3D AMDGPU_UCODE_ID_SDMA5 || ucode_id =3D=3D AMDGPU_UCODE_ID_SDMA6 || ucode_id =3D=3D AMDGPU_UCODE_ID_SDMA7 + || ucode_id =3D=3D AMDGPU_UCODE_ID_SDMA_RS64 || ucode_id =3D=3D AMDGPU_UCODE_ID_RLC_G || ucode_id =3D=3D AMDGPU_UCODE_ID_RLC_RESTORE_LIST_CNTL || ucode_id =3D=3D AMDGPU_UCODE_ID_RLC_RESTORE_LIST_GPM_MEM --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95DBD375229; Sat, 28 Feb 2026 17:35:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300151; cv=none; b=maKCkyZKyOE950iGOJtXfgi88jk537ynSYklZCTMYq7mXQi8sjazptdHE8pyJ2Z9BPeaWIgN7uAhzqR++xRgi7pPob/lo+RtS/pcW0T2bHDutedazzIsuKQze+xq5XurmO69g1vVkrAaNbvxNeHvgCIZZCPBzliV8gEW28fV/HU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300151; c=relaxed/simple; bh=302aLvXgp/oPLp+JscT6TVUhg+SAs0ZqBWkDb0adyH4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=r3ydlGLukaemaKOcrde/RuCbRxARQHVhPYELHDEQhPyM9Hh4S539OchGz7njaon3JHdktrnJEArEW+MY7c1MGRetRvToXVNHgruEwvO8GkPFpHVveDqd+HbiMZnzWivQU6fKU60b0MmK4kWtG/2R1+09DAK/UXEbPPGV87hHi30= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s1Bmultm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s1Bmultm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52466C116D0; Sat, 28 Feb 2026 17:35:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300151; bh=302aLvXgp/oPLp+JscT6TVUhg+SAs0ZqBWkDb0adyH4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s1Bmultm0oXTeJJtQCg5QkzgRPI2L81Noya1ItfWddDDAReQGzf0NJY5Tv4gBjOwT bG+EJdn6Df0jke6b38/6FIxt2ffvg1n2SXX3dkmkJAMdxa+gnBYn1EsVJRT1jo6ijn DwzhQtSMy2sUGgcpVqsTKz6hGFDrf8oOgoUbquW4WQWa1bj7BP1IwwSteXje/SsJtU rRrZE77FLquVqjhzk/X9/X0XrNmnR1cx/riaXb4Ip7mx+Hy1tLhFTWERWltAgYROGL SDXuHF2ZhQf2se54Y1wur+0NSNQhmI/pSwOU3kMCFfc6qKnubrTqpFzfl6Z7/Df9g7 cGqMIISSp01tQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dmytro Laktyushkin , Charlene Liu , Matthew Stewart , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 169/844] drm/amd/display: only power down dig on phy endpoints Date: Sat, 28 Feb 2026 12:21:22 -0500 Message-ID: <20260228173244.1509663-170-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dmytro Laktyushkin [ Upstream commit 0839d8d24e6f1fc2587c4a976f44da9fa69ae3d0 ] This avoids any issues with dpia endpoints Reviewed-by: Charlene Liu Signed-off-by: Dmytro Laktyushkin Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c b/dr= ivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c index f04cbdb3d3814..1ce61f0570201 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c @@ -287,6 +287,8 @@ void dcn401_init_hw(struct dc *dc) for (i =3D 0; i < dc->link_count; i++) { struct dc_link *link =3D dc->links[i]; =20 + if (link->ep_type !=3D DISPLAY_ENDPOINT_PHY) + continue; if (link->link_enc->funcs->is_dig_enabled && link->link_enc->funcs->is_dig_enabled(link->link_enc) && hws->funcs.power_down) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 62B18375240; Sat, 28 Feb 2026 17:35:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300152; cv=none; b=QnoR71+A0NBOvhvAuPPjXmGkEVMUWI6K5SWntBbaZvyOd9jC28MuOqYxNwAPjLE1aKbP7NVWdQqFr3X0T2YRqHzbZmrqxrMcoW+RtlN/ADU03rBcY6ilru46koqSTxkVfdHiT7c5iNbq5uKM8wSM2YfVd7NENPrrB8A7SckQGIM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300152; c=relaxed/simple; bh=8kH7fjcXz01elzl6DePsFy3ZBZZVGKgi8oVdueZK7DA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=a89/SMeZtt86O61llOmklCt6fArqAnueUz5L1+D9CtxNX/ZEB1Bj2dzIOA2Qy+2e13JFN8T9O5U2+Wej72HHxuqWCW17whLatn+0V8+RWwXH0LDE+KMU7BQZSksUDq4TOQVtXnqGbY6TbRL1TLmVN+CD7fuXpW6506DoXPIVNMw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QumqkXwD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QumqkXwD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F324C2BC87; Sat, 28 Feb 2026 17:35:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300152; bh=8kH7fjcXz01elzl6DePsFy3ZBZZVGKgi8oVdueZK7DA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QumqkXwD/EE1PXP1jn9gPV6Ur0NkXZgiVhCfNB1J8/8zB7yn7vkZBWJYw5AXrXTwD wBfY4O3XaoQuo7ycvMziCbSzNYaZKDxTnpVRdSvxzKllW0R0p4LPia3D6nk2DzJQ2/ bqZg5rtCN02gRAnXhtikzrHw8Gzqc+3eHqrVH/FMsk0wqKgTSZ+NFbPsgqECnIm7xj Hsp3fLsUYf0Iq+nLVuYeE+Z3zFmTp4HPl+bP5HUj6mN+FXz7Q3CCqwabXhpPKdWpct roMTCXr+b0E+NsCSStdF8c5S+nwoQLuUVnXlWSbhZN4aAW4iQWH2Q6PmBLR/9ilsNN VMH2kIOY0BX1A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nicholas Kazlauskas , Yihan Zhu , Matthew Stewart , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 170/844] drm/amd/display: Adjust PHY FSM transition to TX_EN-to-PLL_ON for TMDS on DCN35 Date: Sat, 28 Feb 2026 12:21:23 -0500 Message-ID: <20260228173244.1509663-171-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicholas Kazlauskas [ Upstream commit 75372d75a4e23783583998ed99d5009d555850da ] [Why] A backport of the change made for DCN401 that addresses an issue where we turn off the PHY PLL when disabling TMDS output, which causes the OTG to remain stuck. The OTG being stuck can lead to a hang in the DCHVM's ability to ACK invalidations when it thinks the HUBP is still on but it's not receiving global sync. The transition to PLL_ON needs to be atomic as there's no guarantee that the thread isn't pre-empted or is able to complete before the IOMMU watchdog times out. [How] Backport the implementation from dcn401 back to dcn35. There's a functional difference in when the eDP output is disabled in dcn401 code so we don't want to utilize it directly. Reviewed-by: Yihan Zhu Signed-off-by: Nicholas Kazlauskas Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../amd/display/dc/hwss/dcn35/dcn35_hwseq.c | 52 +++++++++++++++++++ .../amd/display/dc/hwss/dcn35/dcn35_hwseq.h | 3 ++ .../amd/display/dc/hwss/dcn35/dcn35_init.c | 2 +- 3 files changed, 56 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c b/driv= ers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c index cb2dfd34b5e2e..88542ca715573 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c @@ -1726,3 +1726,55 @@ void dcn35_program_cursor_offload_now(struct dc *dc,= const struct pipe_ctx *pipe { dc_dmub_srv_program_cursor_now(dc, pipe); } + +static void disable_link_output_symclk_on_tx_off(struct dc_link *link, enu= m dp_link_encoding link_encoding) +{ + struct dc *dc =3D link->ctx->dc; + struct pipe_ctx *pipe_ctx =3D NULL; + uint8_t i; + + for (i =3D 0; i < MAX_PIPES; i++) { + pipe_ctx =3D &dc->current_state->res_ctx.pipe_ctx[i]; + if (pipe_ctx->stream && pipe_ctx->stream->link =3D=3D link && pipe_ctx->= top_pipe =3D=3D NULL) { + pipe_ctx->clock_source->funcs->program_pix_clk( + pipe_ctx->clock_source, + &pipe_ctx->stream_res.pix_clk_params, + link_encoding, + &pipe_ctx->pll_settings); + break; + } + } +} + +void dcn35_disable_link_output(struct dc_link *link, + const struct link_resource *link_res, + enum signal_type signal) +{ + struct dc *dc =3D link->ctx->dc; + const struct link_hwss *link_hwss =3D get_link_hwss(link, link_res); + struct dmcu *dmcu =3D dc->res_pool->dmcu; + + if (signal =3D=3D SIGNAL_TYPE_EDP && + link->dc->hwss.edp_backlight_control && + !link->skip_implict_edp_power_control) + link->dc->hwss.edp_backlight_control(link, false); + else if (dmcu !=3D NULL && dmcu->funcs->lock_phy) + dmcu->funcs->lock_phy(dmcu); + + if (dc_is_tmds_signal(signal) && link->phy_state.symclk_ref_cnts.otg > 0)= { + disable_link_output_symclk_on_tx_off(link, DP_UNKNOWN_ENCODING); + link->phy_state.symclk_state =3D SYMCLK_ON_TX_OFF; + } else { + link_hwss->disable_link_output(link, link_res, signal); + link->phy_state.symclk_state =3D SYMCLK_OFF_TX_OFF; + } + /* + * Add the logic to extract BOTH power up and power down sequences + * from enable/disable link output and only call edp panel control + * in enable_link_dp and disable_link_dp once. + */ + if (dmcu !=3D NULL && dmcu->funcs->unlock_phy) + dmcu->funcs->unlock_phy(dmcu); + + dc->link_srv->dp_trace_source_sequence(link, DPCD_SOURCE_SEQ_AFTER_DISABL= E_LINK_PHY); +} diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.h b/driv= ers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.h index 1ff41dba556c0..e3459546a908a 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.h +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.h @@ -108,5 +108,8 @@ void dcn35_update_cursor_offload_pipe(struct dc *dc, co= nst struct pipe_ctx *pipe void dcn35_notify_cursor_offload_drr_update(struct dc *dc, struct dc_state= *context, const struct dc_stream_state *stream); void dcn35_program_cursor_offload_now(struct dc *dc, const struct pipe_ctx= *pipe); +void dcn35_disable_link_output(struct dc_link *link, + const struct link_resource *link_res, + enum signal_type signal); =20 #endif /* __DC_HWSS_DCN35_H__ */ diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c b/drive= rs/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c index 5a66c9db26709..81bd36f3381db 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c @@ -113,7 +113,7 @@ static const struct hw_sequencer_funcs dcn35_funcs =3D { .enable_lvds_link_output =3D dce110_enable_lvds_link_output, .enable_tmds_link_output =3D dce110_enable_tmds_link_output, .enable_dp_link_output =3D dce110_enable_dp_link_output, - .disable_link_output =3D dcn32_disable_link_output, + .disable_link_output =3D dcn35_disable_link_output, .z10_restore =3D dcn35_z10_restore, .z10_save_init =3D dcn31_z10_save_init, .set_disp_pattern_generator =3D dcn30_set_disp_pattern_generator, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66941375259; Sat, 28 Feb 2026 17:35:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300153; cv=none; b=T0mAgBuRvS24ist+txmRogn0js0bmJTv3SqrS2usc39mufgr5DqpVM420DLvPCAD6RkRHycIpHpgGBgECbi7rUFdy0kB1dSqHOPpA1zX4cK8QqH1R1fR19FLZwNuwUy9nwun2jHdeHbBjpcYfhjKJWVhE8y6QyU4wmQ+8kMmwq4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300153; c=relaxed/simple; bh=fXAX9LhA9WCCjvD4wbLPx91gxh6pb3yQ+Cj2hu0fIwQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=S2s7OX7MYiznmkzvEOvxX7srtncCjMEiRhewdAbHgwLLno7OwQ25QZxhVGAorKy7GLvK0X2V6h1yyYqX54pK16Lm3E0e9F+smGyHzWWOXguV44GwVVPVcAonUWGrGN5JxGcuBAurxO7ZnfT1g9gQ6zRvJ3maC4r52lYDr87K7aQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YPEQx86Q; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YPEQx86Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 876CBC116D0; Sat, 28 Feb 2026 17:35:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300153; bh=fXAX9LhA9WCCjvD4wbLPx91gxh6pb3yQ+Cj2hu0fIwQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YPEQx86QI+9uKU+IftChaMMk5/JmkRw1IN/VQYWUe00Vz6OZGDFKZeKYDtAZRAmxU A4m0SeYa6LGLTpI46VAGCoch+d9D5LoqkIbsHQFWnR9NDbA7lowJa2E0s2uVcxQwcx VDu3wDyvwYIoGYKUn218jOypGscTftYgHZJZVjF6P1/Z3v3WhJ5fTCEvIl5KuSv9gr jpPwUd1+FeWR0ujhEQzqZNN1Ur41Ab0vXYtBw2NS0BpcZ9/qvC62KwM5IWtyVhyiMR QaAnWjAWwkYgLOtgdjAckNbStUrH3BWTzFTnqsXEykI+vRlZhRbt9p5JXH2GAtAllA kRrEo1tW+Klsw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Matthew Brost , Niranjana Vishwanathapura , Sasha Levin Subject: [PATCH 6.19 171/844] drm/xe: Only toggle scheduling in TDR if GuC is running Date: Sat, 28 Feb 2026 12:21:24 -0500 Message-ID: <20260228173244.1509663-172-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Matthew Brost [ Upstream commit dd1ef5e2456558876244795bb22a4d90cb24f160 ] If the firmware is not running during TDR (e.g., when the driver is unloading), there's no need to toggle scheduling in the GuC. In such cases, skip this step. v4: - Bail on wait UC not running (Niranjana) Signed-off-by: Matthew Brost Reviewed-by: Niranjana Vishwanathapura Link: https://patch.msgid.link/20260110012739.2888434-4-matthew.brost@intel= .com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/xe/xe_guc_submit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc= _submit.c index f6ba2b0f074d2..ced13f17fb720 100644 --- a/drivers/gpu/drm/xe/xe_guc_submit.c +++ b/drivers/gpu/drm/xe/xe_guc_submit.c @@ -1304,7 +1304,7 @@ guc_exec_queue_timedout_job(struct drm_sched_job *drm= _job) if (exec_queue_reset(q)) err =3D -EIO; =20 - if (!exec_queue_destroyed(q)) { + if (!exec_queue_destroyed(q) && xe_uc_fw_is_running(&guc->fw)) { /* * Wait for any pending G2H to flush out before * modifying state @@ -1339,6 +1339,7 @@ guc_exec_queue_timedout_job(struct drm_sched_job *drm= _job) */ smp_rmb(); ret =3D wait_event_timeout(guc->ct.wq, + !xe_uc_fw_is_running(&guc->fw) || !exec_queue_pending_disable(q) || xe_guc_read_stopped(guc) || vf_recovery(guc), HZ * 5); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AE02375AAA; Sat, 28 Feb 2026 17:35:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300154; cv=none; b=WS+oe9YXndhrG4/FNWC5PZKUrAGCMOqa2llcnOnEUCGjvnwkx48xCdD5r0UujyBomAIgaajTYvsgrKRFWRhECoRXBNaAWSlqiM8Hc0Iy0gqGt8qrQFFb1vU3QAj5ACCr0DBFeqB1jWIanep0FUzG4CJ+YLq8jA47rQNdnkSIfPQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300154; c=relaxed/simple; bh=yoEPFfcmHdxtqhQ2El/9+sUZcm49FKqpE3/YUqjqnsY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Um4bav9odRQkscvoN0hx4QpXsdfBIv/eoV5ug4jPtNXcTSol1I4tRdzbj+1yrxiDbnE2/reeskLpE8hkd1wUvI8rY8p8oY24CyYE40OUVAlI9KlsGdeYPUf6Sak00UForjigaSJVnp+hJEd+YRYxWZDwGvQIWOpT/UUIThyb3bE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lVltmFnV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lVltmFnV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64ECDC19424; Sat, 28 Feb 2026 17:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300154; bh=yoEPFfcmHdxtqhQ2El/9+sUZcm49FKqpE3/YUqjqnsY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lVltmFnV+0Lv606/SoPb8CvShIE4mH/OrLaYoct4Ki6gKZFI4Lp9+Xfhiqxjg2zBt cRElWdSezErtJ+S9gq4QHuvvjdoyConX8JPLWPHYfS1VVxHIG4f+FZb9pVqVY2zVke Z2OioDurSRjTepB+qGALTs/p7yliOlY5CB7Fy6ZBG2fISt0AyQYTAcDm35qBdKkegf /7LADzKjK8WQC1eQnTRbY3WdBQSjMsVoDbf3DhmzjHqoZ9V/SUBWSuMV1pm1Yw0hmB WZQazaLoSZYNw/WxlJSLOe3cgBjVDthncInFzRCYxRitfjDLShKTdKTuFJnf1Uujhz IQZtM9+r18l9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sebastian Krzyszkowiak , Charles Keepax , Mark Brown , Sasha Levin Subject: [PATCH 6.19 172/844] ASoC: wm8962: Add WM8962_ADC_MONOMIX to "3D Coefficients" mask Date: Sat, 28 Feb 2026 12:21:25 -0500 Message-ID: <20260228173244.1509663-173-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sebastian Krzyszkowiak [ Upstream commit 66c26346ae30c883eef70acf9cf9054dfdb4fb2f ] This bit is handled by a separate control. Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260105-wm8962-l5-fixes-v1-1-f4f4eeacf089@p= uri.sm Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/codecs/wm8962.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index e9e317ce68982..1040740fc80f8 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -1760,7 +1760,7 @@ SND_SOC_BYTES("EQR Coefficients", WM8962_EQ24, 18), =20 =20 SOC_SINGLE("3D Switch", WM8962_THREED1, 0, 1, 0), -SND_SOC_BYTES_MASK("3D Coefficients", WM8962_THREED1, 4, WM8962_THREED_ENA= ), +SND_SOC_BYTES_MASK("3D Coefficients", WM8962_THREED1, 4, WM8962_THREED_ENA= | WM8962_ADC_MONOMIX), =20 SOC_SINGLE("DF1 Switch", WM8962_DF1, 0, 1, 0), SND_SOC_BYTES_MASK("DF1 Coefficients", WM8962_DF1, 7, WM8962_DF1_ENA), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FDE5375ACB; Sat, 28 Feb 2026 17:35:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300155; cv=none; b=kCldUj23yX1l4jigLvh0fsaGAE8t1YR67c1F1d1hprl6p1J3h8kzlCjH8GJeLO7VUicZjVL49K6OI7LkZxnYYUdvUQUiXzbljPQKP8QlYxkoTBT11Vs7JSVk8LYApRoVgQcMCtAVv5g9WwmMXHpYMwswYRU22VxutIPoCB4Se5I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300155; c=relaxed/simple; bh=pATswG/kTZy1LXGkjTLon4uSoyIvBh8iGU+Rtxrjz9Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fmEaSPhQxZmjd82D/jBitELs/DlZuGaJq25ciTmyI+/2ilzOOMlsouIMhkQ5pBo6j01Jyx524gv53HkpH9AYai6Jt5y0lg+VBRysGZBBoj47k5sPHigZW9/VQFSk7Nsyr+xqmsym4HilJFAafarzqhqSl5O66s1rOCr6a7bB3xU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CLC3034G; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CLC3034G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 549EBC19425; Sat, 28 Feb 2026 17:35:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300155; bh=pATswG/kTZy1LXGkjTLon4uSoyIvBh8iGU+Rtxrjz9Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CLC3034G1vHO2IK0FR4HTnU6V/oMsige2T7l62d5XK8K6FlLKakOXJkHw7ecxX0xM WoEMptbHkvW3HWIGpT/Glqv7/Bh/ohuyMn+R1hG8G5xHqCQK0un8RgNrovGJSfVe9u oJ+mPTrmEJLEjiP3qVJdvEbPSR1uDgWngVPSglRpM5ZP/ytJfGOzEXykn1TODLG1ai vf6Hsvk12sRWiUhcmupybEXdVTonBLL7g6QGgt0JthIbSr0B+Te1aJxvrVKk1WTsi2 0kP34N2LgPB/yapR06UEd9szsO+DyfpOHndEScKfhYtShJwtHz8Rj7ndjGvI/OQlU+ rsno74Iz04fzQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sebastian Krzyszkowiak , Charles Keepax , Mark Brown , Sasha Levin Subject: [PATCH 6.19 173/844] ASoC: wm8962: Don't report a microphone if it's shorted to ground on plug Date: Sat, 28 Feb 2026 12:21:26 -0500 Message-ID: <20260228173244.1509663-174-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sebastian Krzyszkowiak [ Upstream commit e590752119029d87ce46d725e11245a52d22e1fe ] This usually means that a TRS plug with no microphone pin has been plugged into a TRRS socket. Cases where a user is plugging in a microphone while pressing a button will be handled via incoming interrupt after the user releases the button, so the microphone will still be detected once it becomes usable. Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260105-wm8962-l5-fixes-v1-3-f4f4eeacf089@p= uri.sm Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/codecs/wm8962.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index 1040740fc80f8..bff8644674163 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -67,6 +67,8 @@ struct wm8962_priv { struct mutex dsp2_ena_lock; u16 dsp2_ena; =20 + int mic_status; + struct delayed_work mic_work; struct snd_soc_jack *jack; =20 @@ -3081,8 +3083,16 @@ static void wm8962_mic_work(struct work_struct *work) if (reg & WM8962_MICSHORT_STS) { status |=3D SND_JACK_BTN_0; irq_pol |=3D WM8962_MICSCD_IRQ_POL; + + /* Don't report a microphone if it's shorted right after + * plugging in, as this may be a TRS plug in a TRRS socket. + */ + if (!(wm8962->mic_status & WM8962_MICDET_STS)) + status =3D 0; } =20 + wm8962->mic_status =3D status; + snd_soc_jack_report(wm8962->jack, status, SND_JACK_MICROPHONE | SND_JACK_BTN_0); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FCBD47CC9B; Sat, 28 Feb 2026 17:35:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300156; cv=none; b=S4OLXm8LKT4zntLCfC1t3xmsSzpwPTAooZoWpHDN2AYT7jk02XfAIXfkYCYnp3QxSsONH7nGN7AKhE1AlYnvLyGgU3sjo3RJjlLHI/Chc1kBxLdUOlWD4nU/I3vmaI6plbyvqa2gtD41l4nH0b8Z/bXuUqJUcf47feT3b3JN/oA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300156; c=relaxed/simple; bh=PnUWV+2waipA/3l6Zw0FE24BqUwqTNTQo97COvz2/04=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kxQ/faBJ9Doxj+QNZVLfRpUae1MvY28xOpD6W30ZqYsoQc7CppISH5e6BG5W6p4ZzTr0KkjyHxiwuO/Wzd+TNx0R/wDZPjJeC7bxqDyIaddjKSkcqEshV26GXa7lGKitrCcfQBNwu8hfzeZ/6MLfUsRSS5suLkoLKy7AoVC/boM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i5bK7Zvm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="i5bK7Zvm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 460C2C19425; Sat, 28 Feb 2026 17:35:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300155; bh=PnUWV+2waipA/3l6Zw0FE24BqUwqTNTQo97COvz2/04=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i5bK7Zvmh73xxX27WKRUAz/2lH97AYrjwA17hPRusO8deg3v07p1thM/lAwkABwig Cb35WAEAqBu689RTpj/YD9qj5K1tH8WWg7+72A0AC5UKBd9GCTpnAltqoP4yrZr+4E RrIMPoOn3pgq7aBQDidEEKH5TS3qRWbyfv81/+DWRSAWU8UktpuT7yaJS5jeYXAhtr ovMbEpImpvJFfG9iTdNKoOO09FBxR812IYUjP9W9ZOd/tkZte+GPqIFfjWR0ZBjVlM 5WuPQTHTLroN9Gt1S1yGZxccUhI0b393+OS/ZwjDNcNdY4MVkR+N2LDntGNpris58o Fj+KV477GAZQg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miquel Raynal , Tudor Ambarus , Mark Brown , Sasha Levin Subject: [PATCH 6.19 174/844] spi: spi-mem: Limit octal DTR constraints to octal DTR situations Date: Sat, 28 Feb 2026 12:21:27 -0500 Message-ID: <20260228173244.1509663-175-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miquel Raynal [ Upstream commit 8618271887ca10ac5108fe7e1d82ba8f1b152cf9 ] In this helper, any operation with a single DTR cycle (like 1S-1S-8D) is considered requiring a duplicated command opcode. This is wrong as this constraint only applies to octal DTR operations (8D-8D-8D). Narrow the application of this constraint to the concerned bus interface. Note: none of the possible XD-XD-XD pattern, with X being one of {1, 2, 4} would benefit from this check either as there is only in octal DTR mode that a single clock edge would be enough to transmit the full opcode. Make sure the constraint of expecting two bytes for the command is applied to the relevant bus interface. Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20260109-winbond-v6-17-rc1-oddr-v2-3-1fff6a2= ddb80@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spi-mem.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index c8b2add2640e5..6c7921469b90b 100644 --- a/drivers/spi/spi-mem.c +++ b/drivers/spi/spi-mem.c @@ -178,8 +178,19 @@ bool spi_mem_default_supports_op(struct spi_mem *mem, if (op->data.swap16 && !spi_mem_controller_is_capable(ctlr, swap16)) return false; =20 - if (op->cmd.nbytes !=3D 2) - return false; + /* Extra 8D-8D-8D limitations */ + if (op->cmd.dtr && op->cmd.buswidth =3D=3D 8) { + if (op->cmd.nbytes !=3D 2) + return false; + + if ((op->addr.nbytes % 2) || + (op->dummy.nbytes % 2) || + (op->data.nbytes % 2)) { + dev_err(&ctlr->dev, + "Even byte numbers not allowed in octal DTR operations\n"); + return false; + } + } } else { if (op->cmd.nbytes !=3D 1) return false; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03B0B377015; Sat, 28 Feb 2026 17:35:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300157; cv=none; b=QcOtnYuNCcnxZgQnawE/FNFwA3N6RT3dm6oy+FlpCtOqG7kXjE4MP5H/qnl3xVvy4yvAZAblklhZAZmlgct+xLw+3xAsO+DbUnKLk8WBYPFtqpQasg3d6J/5959oRKS1M32/zxzjWCl28qOb2ocIB27dd2Q+iug4nZlLrhnPiuk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300157; c=relaxed/simple; bh=zWULn9MDL6zirfwsdCoQulTU0l7DWYPknygn01KfaaM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=k/0WaqsAJFMatb1k5H35Ot92YPecKxSxVcHyD4JF7Xen5JZpaMeNkyBbrm/2cpvBRdfNXqfYpXHJwAEWTvesWXkCwHw2TVYmUfVPHk7CZ8XhGzbPTrDu+JqikvCmcqZrD9BoPMJ3PC1vVcfaDsgYfiHxh90LTdgfUuek1Ijw/3Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r+HI5xBB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="r+HI5xBB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37DE1C2BCAF; Sat, 28 Feb 2026 17:35:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300156; bh=zWULn9MDL6zirfwsdCoQulTU0l7DWYPknygn01KfaaM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r+HI5xBBlbpoTsu1ForEF4g8Spu7RIPJnafRZA79cE0QCaCDl2NM0ymYjEZa6a+ks ktjHTlIGs/R/flvaAPWxWAxmBHRABbnfCFLS7wmE+tnreRN6TtJXSe/zVknQITKfrC XasuN/7e3aGbro9BiKADwKcw8aprj8D6ur8MhqCoPSSsUfXH7OIPwo5IrmZx1VrqFF aalyJ24TkFrpfMmC1eJIjaZJn6+ixYAKBd7EYfnjYHuFLFVEhkKP094UiS/TRV7JXS kxvJmUB749nMt2OkoO/1aJ44abfXqpcZz6zHCU+dIWp9ckww1JBGi76gdCG9o7s+uP npJB5PzbvT9TA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Waiman Long , Chen Ridong , Tejun Heo , Sasha Levin Subject: [PATCH 6.19 175/844] cgroup/cpuset: Don't fail cpuset.cpus change in v2 Date: Sat, 28 Feb 2026 12:21:28 -0500 Message-ID: <20260228173244.1509663-176-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Waiman Long [ Upstream commit 6e6f13f6d5095f3a432da421e78f4d7d51ef39c8 ] Commit fe8cd2736e75 ("cgroup/cpuset: Delay setting of CS_CPU_EXCLUSIVE until valid partition") introduced a new check to disallow the setting of a new cpuset.cpus.exclusive value that is a superset of a sibling's cpuset.cpus value so that there will at least be one CPU left in the sibling in case the cpuset becomes a valid partition root. This new check does have the side effect of failing a cpuset.cpus change that make it a subset of a sibling's cpuset.cpus.exclusive value. With v2, users are supposed to be allowed to set whatever value they want in cpuset.cpus without failure. To maintain this rule, the check is now restricted to only when cpuset.cpus.exclusive is being changed not when cpuset.cpus is changed. The cgroup-v2.rst doc file is also updated to reflect this change. Signed-off-by: Waiman Long Reviewed-by: Chen Ridong Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- Documentation/admin-guide/cgroup-v2.rst | 8 +++---- kernel/cgroup/cpuset.c | 30 ++++++++++++------------- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-= guide/cgroup-v2.rst index 7f5b59d95fce5..510df2461aff2 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -2561,10 +2561,10 @@ Cpuset Interface Files Users can manually set it to a value that is different from "cpuset.cpus". One constraint in setting it is that the list of CPUs must be exclusive with respect to "cpuset.cpus.exclusive" - of its sibling. If "cpuset.cpus.exclusive" of a sibling cgroup - isn't set, its "cpuset.cpus" value, if set, cannot be a subset - of it to leave at least one CPU available when the exclusive - CPUs are taken away. + and "cpuset.cpus.exclusive.effective" of its siblings. Another + constraint is that it cannot be a superset of "cpuset.cpus" + of its sibling in order to leave at least one CPU available to + that sibling when the exclusive CPUs are taken away. =20 For a parent cgroup, any one of its exclusive CPUs can only be distributed to at most one of its child cgroups. Having an diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index c06e2e96f79dc..dc3ac38c5d160 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -603,33 +603,31 @@ static inline bool cpusets_are_exclusive(struct cpuse= t *cs1, struct cpuset *cs2) =20 /** * cpus_excl_conflict - Check if two cpusets have exclusive CPU conflicts - * @cs1: first cpuset to check - * @cs2: second cpuset to check + * @trial: the trial cpuset to be checked + * @sibling: a sibling cpuset to be checked against + * @xcpus_changed: set if exclusive_cpus has been set * * Returns: true if CPU exclusivity conflict exists, false otherwise * * Conflict detection rules: * 1. If either cpuset is CPU exclusive, they must be mutually exclusive * 2. exclusive_cpus masks cannot intersect between cpusets - * 3. The allowed CPUs of one cpuset cannot be a subset of another's exclu= sive CPUs + * 3. The allowed CPUs of a sibling cpuset cannot be a subset of the new e= xclusive CPUs */ -static inline bool cpus_excl_conflict(struct cpuset *cs1, struct cpuset *c= s2) +static inline bool cpus_excl_conflict(struct cpuset *trial, struct cpuset = *sibling, + bool xcpus_changed) { /* If either cpuset is exclusive, check if they are mutually exclusive */ - if (is_cpu_exclusive(cs1) || is_cpu_exclusive(cs2)) - return !cpusets_are_exclusive(cs1, cs2); + if (is_cpu_exclusive(trial) || is_cpu_exclusive(sibling)) + return !cpusets_are_exclusive(trial, sibling); =20 /* Exclusive_cpus cannot intersect */ - if (cpumask_intersects(cs1->exclusive_cpus, cs2->exclusive_cpus)) + if (cpumask_intersects(trial->exclusive_cpus, sibling->exclusive_cpus)) return true; =20 - /* The cpus_allowed of one cpuset cannot be a subset of another cpuset's = exclusive_cpus */ - if (!cpumask_empty(cs1->cpus_allowed) && - cpumask_subset(cs1->cpus_allowed, cs2->exclusive_cpus)) - return true; - - if (!cpumask_empty(cs2->cpus_allowed) && - cpumask_subset(cs2->cpus_allowed, cs1->exclusive_cpus)) + /* The cpus_allowed of a sibling cpuset cannot be a subset of the new exc= lusive_cpus */ + if (xcpus_changed && !cpumask_empty(sibling->cpus_allowed) && + cpumask_subset(sibling->cpus_allowed, trial->exclusive_cpus)) return true; =20 return false; @@ -666,6 +664,7 @@ static int validate_change(struct cpuset *cur, struct c= puset *trial) { struct cgroup_subsys_state *css; struct cpuset *c, *par; + bool xcpus_changed; int ret =3D 0; =20 rcu_read_lock(); @@ -722,10 +721,11 @@ static int validate_change(struct cpuset *cur, struct= cpuset *trial) * overlap. exclusive_cpus cannot overlap with each other if set. */ ret =3D -EINVAL; + xcpus_changed =3D !cpumask_equal(cur->exclusive_cpus, trial->exclusive_cp= us); cpuset_for_each_child(c, css, par) { if (c =3D=3D cur) continue; - if (cpus_excl_conflict(trial, c)) + if (cpus_excl_conflict(trial, c, xcpus_changed)) goto out; if (mems_excl_conflict(trial, c)) goto out; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA78837702E; Sat, 28 Feb 2026 17:35:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300158; cv=none; b=BVeWQ0PyLJCXRhN8jotZcRn0PQgkKec9KnylzIlgwO5TEc2yvig5Zkc5fnNSM3DOZY8vRDqLql2ewJoIeSWUOxfE9f2A4FS1Wfr0KQAsXb3puflw2y52xEEjUuqBvu88UToajskXG1UQFyJziccN3szYfBvpoODxF7QCWYZImc8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300158; c=relaxed/simple; bh=fqo1tRZ40B/lwAWQfkdtK0n9wxzpxII4GRCGgGu/60k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Wu2O8GDA5kpHYjxLoqPKF+5jj/Qp3DRtTWfFOd888cZMqi3rYt28JdnjkuDJhTze3Eg9e8C7ClI41qpdDsQp9fo74jmTgwJsy1jz9PaN5CdNZEeG7Up6rHgtfvIb39t44yn8/OVod6iZQTG8zzxbGxHQkMbP0ZjroiD2gbune7M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RDZkWZq8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RDZkWZq8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27148C2BCB2; Sat, 28 Feb 2026 17:35:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300157; bh=fqo1tRZ40B/lwAWQfkdtK0n9wxzpxII4GRCGgGu/60k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RDZkWZq8qVLEuK/UM6LiESC/pfsSS945k9xJ7AizJKBN+hOQ1VgFUbQ1RYNfQPyXc Pazh2tg9EM9Qj/CK68iQpGKRU/Wkt4fhn977fqa1cg6yYJ7QIEXjew7o8+D691m9Bc parGengvTyW6Oy2G2lZTl9yNAZLcjRGy9B1rgCjB9Zoh9gweN3skAULBRb5SG3eg0f P2IWunfO2T3yohSHwG0Qy97RnXxuT/i5wZCSE3B3uL0Ibi9PFFBbL0dTkE9CHlJIta DYGP5uGMu5UnEO6TyEcAwzzXps7+x5RadqajdAdm0k4k6YHUeV0Xdx53GjoYbVOKJ0 ukNC4/D7wNvfw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Qian , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 176/844] media: amphion: Clear last_buffer_dequeued flag for DEC_CMD_START Date: Sat, 28 Feb 2026 12:21:29 -0500 Message-ID: <20260228173244.1509663-177-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Qian [ Upstream commit d85f3207d75df6d7a08be6526b15ff398668206c ] The V4L2_DEC_CMD_START command may be used to handle the dynamic source change, which will triggers an implicit decoder drain. The last_buffer_dequeued flag is set in the implicit decoder drain, so driver need to clear it to continue the following decoding flow. Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/amphion/vdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/amphion/vdec.c b/drivers/media/platform= /amphion/vdec.c index c0d2aabb9e0e3..f25dbcebdccf6 100644 --- a/drivers/media/platform/amphion/vdec.c +++ b/drivers/media/platform/amphion/vdec.c @@ -724,6 +724,7 @@ static int vdec_decoder_cmd(struct file *file, void *fh= , struct v4l2_decoder_cmd switch (cmd->cmd) { case V4L2_DEC_CMD_START: vdec_cmd_start(inst); + vb2_clear_last_buffer_dequeued(v4l2_m2m_get_dst_vq(inst->fh.m2m_ctx)); break; case V4L2_DEC_CMD_STOP: vdec_cmd_stop(inst); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1095375AC8; Sat, 28 Feb 2026 17:35:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300158; cv=none; b=CIslrpL82OACdka6+MmEdpt8/PVYfwTobnqAatf7KHMP3CgiTsLshDTddC2lKNEBuXrHL7y17i1Qbyx7Fg342IO6WnaPuT7ANRJ1YHyuwyq05Bk6XT3PIlKo1vveIxiaYLEEBhUDwEQvB0Qt3ZM3rNG4V7NcYP5R0Am+ePTgmYU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300158; c=relaxed/simple; bh=jpKIwh4BedLUAcItD23Wa7pLpbf3RV8K9IItLA6XWio=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uAJZ3129EfVtVwb9icmofFTwel3EoPkh6NndRf2rCVrWsuVnhia1VsEJw2/E0P/7bBnk+feZrtKhjhrgw4JNorks6kdR0Sq3IDu4p869k7I8k0j0kJOoRFLMvJf2lPPPeqasCarGYG9bPbgTLuC8F1g8/Qus2tLFWAGnQHv3YNw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Od3LX1vk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Od3LX1vk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14915C2BC87; Sat, 28 Feb 2026 17:35:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300158; bh=jpKIwh4BedLUAcItD23Wa7pLpbf3RV8K9IItLA6XWio=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Od3LX1vk33gmOhtM7VMUvuxHUYm+dEfyUEToUqmUGiO8H/tumdL+j3H98bRwyMYsB 1hUNa7Sg9zWPSd2fnyufa280G8UmzHPzAxr7kRllgGA/KTEp1n2wCsKpxbNgwnMoQQ y89hxqlG5ttLr3hGhoedHB3TsTmk/5B85N2n/dPCpQfkldYLw9eH2HZMmlcsjvFxRK 4bsqPgtmXjjR/EhswUpmgL+rKiLHuv5YJxB+NGXhNfPAC72T0Fuz90zJUYIeLrkvbg g3HPtHPPvGJU4wJooS6EMz2TBc6svdwdJEYu8/LSV9tGTvLAxzz4wG/1bmT6RHX86O u3383ybEqIX6Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tuo Li , Neil Armstrong , Sasha Levin Subject: [PATCH 6.19 177/844] drm/panel: Fix a possible null-pointer dereference in jdi_panel_dsi_remove() Date: Sat, 28 Feb 2026 12:21:30 -0500 Message-ID: <20260228173244.1509663-178-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tuo Li [ Upstream commit 95eed73b871111123a8b1d31cb1fce7e902e49ea ] In jdi_panel_dsi_remove(), jdi is explicitly checked, indicating that it may be NULL: if (!jdi) mipi_dsi_detach(dsi); However, when jdi is NULL, the function does not return and continues by calling jdi_panel_disable(): err =3D jdi_panel_disable(&jdi->base); Inside jdi_panel_disable(), jdi is dereferenced unconditionally, which can lead to a NULL-pointer dereference: struct jdi_panel *jdi =3D to_panel_jdi(panel); backlight_disable(jdi->backlight); To prevent such a potential NULL-pointer dereference, return early from jdi_panel_dsi_remove() when jdi is NULL. Signed-off-by: Tuo Li Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20251218120955.11185-1-islituo@gmail.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c b/drivers/gpu/dr= m/panel/panel-jdi-lpm102a188a.c index 23462065d726b..ea975170fafff 100644 --- a/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c +++ b/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c @@ -434,8 +434,10 @@ static void jdi_panel_dsi_remove(struct mipi_dsi_devic= e *dsi) int err; =20 /* only detach from host for the DSI-LINK2 interface */ - if (!jdi) + if (!jdi) { mipi_dsi_detach(dsi); + return; + } =20 err =3D jdi_panel_disable(&jdi->base); if (err < 0) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2072A379EE0; Sat, 28 Feb 2026 17:35:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300160; cv=none; b=iOjL4WLZgEXGrvjzX3hTa3ORNUEss/HE7OBY6ha/WtInnork9W/QI1YhUlsaJPhnlr7ztu8DmzztpPEJLrjveVC1bXhDpQdoTgCKuTKC5QBrlrCE2sOm70qLPIiPdNVbipaP5enLznBESJGICX8NvIezZEtnIsvbhe3ewUIYwRg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300160; c=relaxed/simple; bh=QY4r49LELkjFiPWcZ+H/+r+CW7E0L4Bmu3+i0NV0DQY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=G/aFO4JJXlHb8a/Tt9+RdQpsTFijLE+jsevomPIe4wfRtyCuFNdOa7bddyKvYERNIsHlOolpyMqFbhjHTFponSC862DwHli1a4U8teWZvn4nWbYawUKmcYFpiTW6hjpbVSTBAYTGIqVU6LrWDS01xWS79UW7QM8pEPV3Y9ZcA+A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AWUOK9tj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AWUOK9tj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6222C116D0; Sat, 28 Feb 2026 17:35:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300159; bh=QY4r49LELkjFiPWcZ+H/+r+CW7E0L4Bmu3+i0NV0DQY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AWUOK9tjKFgkuUFvGKzkeJrxUNf21eAPnW5dFd8bODD5qxTbxretdDFhD0uwJatLm S68wLNgJQ9sReujbxWWunWyV61kSG5KDO8p0z2H4nqtwSj3xapxdUTcT8pv28D9E+S cK75mY2X6hRP4JkbRZHSPYd8mw9+P9hpdWPZmPv8BldyVUQLQclTRVHdBSf8EWCnHZ sVxwUPCPjX7rnm2ZTgQJA5dT4rxBRdRcXiuSitec4WqwJeNH7x1/p9mi80Jaa/pVu9 79LO1+zMakXLysIz+UiWsKR74+XaoapHYofEe46yYhPEW4f9qyTRo3UyXZd8evQDCK NX1l4mNqoe3yQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thorsten Schmelzer , =?UTF-8?q?Niklas=20S=C3=B6derlund?= , Michael Tretter , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 178/844] media: adv7180: fix frame interval in progressive mode Date: Sat, 28 Feb 2026 12:21:31 -0500 Message-ID: <20260228173244.1509663-179-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Thorsten Schmelzer [ Upstream commit 90289b67c5c1d4c18784059b27460d292e16d208 ] The ADV7280-M may internally convert interlaced video input to progressive video. If this mode is enabled, the ADV7280-M delivers progressive video frames at the field rate of 50 fields per second (PAL) or 60 fields per second (NTSC). Fix the reported frame interval if progressive video is enabled. Signed-off-by: Thorsten Schmelzer Reviewed-by: Niklas S=C3=B6derlund Signed-off-by: Michael Tretter Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/adv7180.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c index 378f4e6af12cb..5cbc973df684d 100644 --- a/drivers/media/i2c/adv7180.c +++ b/drivers/media/i2c/adv7180.c @@ -507,6 +507,13 @@ static int adv7180_get_frame_interval(struct v4l2_subd= ev *sd, fi->interval.denominator =3D 25; } =20 + /* + * If the de-interlacer is active, the chip produces full video frames + * at the field rate. + */ + if (state->field =3D=3D V4L2_FIELD_NONE) + fi->interval.denominator *=3D 2; + return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CF73A379EF6; Sat, 28 Feb 2026 17:36:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300160; cv=none; b=vArxjm46h8Ic4PvdrU1riIknlxEavTrSSY1HLRbCdaqxKHkRnrnu0//hdGKK2gVxe7r9h5hxwDyS+rmiMa3DwEHKyOiv58OQcVcEuSaTYxUaZNkQ4//H9L9c3szL0167zXbJgTUP49QWFFX042qgnKcZXY9eAiO32RvsFoksEMs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300160; c=relaxed/simple; bh=TYqVDXtQ0/PIYnUvVHVN5F6H+dM+ladLlhiwnGNLqp8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=a75z6Bgi+ElPSaRbm7LMHaFGqH5zRimmiZ36bRy8ohGQlwUaqd68w6Gdb7gX1x1MtX8JN6c12vGuUx8SuYJUoeRZ7NtgCJjG9tgzPQnaUwLHYoPdA17Yem/A3n/TFg8FfLgNIx7as9J6wuF8borfjIDuShzuZmkFwK+lqRnJPyM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BiRmJ0b2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BiRmJ0b2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBFE0C19423; Sat, 28 Feb 2026 17:35:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300160; bh=TYqVDXtQ0/PIYnUvVHVN5F6H+dM+ladLlhiwnGNLqp8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BiRmJ0b2Sg2YNb/Z61iDtiAxY5jJCbMDyzOKhFXNtKgqfAAMyNhl8jwO/PJbbQqJr uP3tb1FGBjg7OieK/uBXGARZP0zC/AUfFCbQMkkIKuGjxOB7G05qacdEBsAsl5+zCy MHoG4+3oJCZNo/PV3ufKqewzqtgF10wbgaatnB+oH6YI2U3uW1q2UmmIZyOzlRMOrM OAR6SmNQAARtEWczR2HHO+KysabxBBrWmUrfevum+NDqWbU/PjgOiJO89uydkri7iC t29i42KXIy4O2Mn/o+4eoQvhcTpIdnqo8ZjkY781w/vCiojv8265+KUDRB5otxBwx8 6uy4J8aWITyDg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Szymon Wilczek , syzbot+405dcd13121ff75a9e16@syzkaller.appspotmail.com, Mike Isely , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 179/844] media: pvrusb2: fix URB leak in pvr2_send_request_ex Date: Sat, 28 Feb 2026 12:21:32 -0500 Message-ID: <20260228173244.1509663-180-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Szymon Wilczek [ Upstream commit a8333c8262aed2aedf608c18edd39cf5342680a7 ] When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails. Reported-by: syzbot+405dcd13121ff75a9e16@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D405dcd13121ff75a9e16 Signed-off-by: Szymon Wilczek Acked-by: Mike Isely Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c b/drivers/media/usb/pv= rusb2/pvrusb2-hdw.c index b32bb906a9de2..5807734ae26c6 100644 --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c @@ -3709,6 +3709,11 @@ status); "Failed to submit read-control URB status=3D%d", status); hdw->ctl_read_pend_flag =3D 0; + if (hdw->ctl_write_pend_flag) { + usb_unlink_urb(hdw->ctl_write_urb); + while (hdw->ctl_write_pend_flag) + wait_for_completion(&hdw->ctl_done); + } goto done; } } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C300947DD4D; Sat, 28 Feb 2026 17:36:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300161; cv=none; b=r3iMQq7X2bh123IP1V6MOykyRtA5w4rEHqokTmsaNIffDZMwre8MBHaWC1w4Q/SWMBa4h5Pg95gSxTtgu8mVSfBEAgaiHQWW84K6mfdeMUQqxrSAdEQq5Ib6vmxbw4PjsgSR1I1lhRNJzf7ZbdtDnNfGOcQmLml7bMx+90gRq0o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300161; c=relaxed/simple; bh=yKsvD2YtzuvtxDbpqNH9SY22GB/GFuAqSTj5wKz7q3Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MYxCZlsUdA8q2CjfHAY2oB8eL/0v25Am7j1+ErUTtLxnPGhqoqkz9ft6npob8Bt7weOLTnJBf625GxzZmUbThD9/Y+oNpSlBKzfVTZaJjY1UX+NPj6tXyh1/AWP1lig/WVLeiyvzZsSXA4QiMLu9pfVCTexG1fV94nP9tEfh5ck= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QZJMM+fm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QZJMM+fm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 056F4C19423; Sat, 28 Feb 2026 17:36:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300161; bh=yKsvD2YtzuvtxDbpqNH9SY22GB/GFuAqSTj5wKz7q3Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QZJMM+fmDXX7P/zNJwsLP1ZtgeRQHcpuyO12mZis4m1CEAxGxjPzeLc4T0KnJyNou Cfc1RUmGouWO6q/8kvVvHmuuTEblQyQxAlNorKR5U+GwIkwZ5rjC4Gin8+Stuqbwbe Wn/N4KGY+PXIqe6E0YscP622sJLG9tj0mkEKSxCGWOUMe84EaFVkEZ0fh69aeDUfDX 13pGCujt2aMGIDPzpzaJbs9jAF/LLkDxsVN6d47XxZsNTaMSOhQEDuBOea7NbiNzUe 6jCNyMO9MbDVDOOPQkXt38pm9NUEvwuVm//fff8Ye8UBBw00jVRJ3yPNOzc6jWyO6h ZQwpop7EJoYnQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kees Cook , Nathan Chancellor , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 180/844] media: solo6x10: Check for out of bounds chip_id Date: Sat, 28 Feb 2026 12:21:33 -0500 Message-ID: <20260228173244.1509663-181-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kees Cook [ Upstream commit 0fdf6323c35a134f206dcad5babb4ff488552076 ] Clang with CONFIG_UBSAN_SHIFT=3Dy noticed a condition where a signed type (literal "1" is an "int") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. Link: https://github.com/ClangBuiltLinux/linux/issues/2144 [1] Suggested-by: Nathan Chancellor Signed-off-by: Kees Cook Signed-off-by: Hans Verkuil [hverkuil: fix checkpatch warning for is_tw286x] Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/solo6x10/solo6x10-tw28.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/solo6x10/solo6x10-tw28.c b/drivers/media/pci= /solo6x10/solo6x10-tw28.c index 1b7c22a9bc94f..8f53946c67928 100644 --- a/drivers/media/pci/solo6x10/solo6x10-tw28.c +++ b/drivers/media/pci/solo6x10/solo6x10-tw28.c @@ -166,7 +166,7 @@ static const u8 tbl_tw2865_pal_template[] =3D { 0x64, 0x51, 0x40, 0xaf, 0xFF, 0xF0, 0x00, 0xC0, }; =20 -#define is_tw286x(__solo, __id) (!(__solo->tw2815 & (1 << __id))) +#define is_tw286x(__solo, __id) (!((__solo)->tw2815 & (1U << (__id)))) =20 static u8 tw_readbyte(struct solo_dev *solo_dev, int chip_id, u8 tw6x_off, u8 tw_off) @@ -686,6 +686,9 @@ int tw28_set_ctrl_val(struct solo_dev *solo_dev, u32 ct= rl, u8 ch, chip_num =3D ch / 4; ch %=3D 4; =20 + if (chip_num >=3D TW_NUM_CHIP) + return -EINVAL; + if (val > 255 || val < 0) return -ERANGE; =20 @@ -758,6 +761,9 @@ int tw28_get_ctrl_val(struct solo_dev *solo_dev, u32 ct= rl, u8 ch, chip_num =3D ch / 4; ch %=3D 4; =20 + if (chip_num >=3D TW_NUM_CHIP) + return -EINVAL; + switch (ctrl) { case V4L2_CID_SHARPNESS: /* Only 286x has sharpness */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5CDF37CB1B; Sat, 28 Feb 2026 17:36:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300162; cv=none; b=tUKdbvC8Ch4uaPxDCrRJBmH9405DeT2f6Ru9k5KKnKaDiDtJoheAMI62EJUdOC4mcy2v/dor520fYRdzukz2LaiW5qIU2WDu/OBriD7tWZfAXCzC6igbFa4CIdHzK1q9vFTPgfOnvqI3y06HesBoatfSpDr8mcqdJ3E5KY/QyLk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300162; c=relaxed/simple; bh=2/6HQfuQO/kySjY2/lJdcTulhRmwZNESNAzsv90qTx4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KJ1mx+tKxzCPWV9jQq4gEH3oJpApd0+fU3J7HBCo8AQnXLVH4H5c6worXXN8WVPW/UVz6cNKFaCieW8T2rrscFVtRf/Q1L9t+kmmAEaIVQqgIYkhn72noalILfc4c2zDwTDPVFk2PfaLIZavpHaPb5ufzLEdeFzPNnQGT2adNMw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I8SnaJvd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I8SnaJvd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9AEEC19423; Sat, 28 Feb 2026 17:36:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300162; bh=2/6HQfuQO/kySjY2/lJdcTulhRmwZNESNAzsv90qTx4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I8SnaJvdPmiG6X05bFC1H0zQ0JUSuhkincr+BWY1O6jXu4UWVUCfH+bTTkSPKAybM MDec1/kAgZsxrp6umRW3azO8NTC/fWm4zxn1R5ehMy2eZLxB7+22XewAWm7Jhobvxa xWy1wvTusyDieS/aNT3EjGLQHSF/WxA8lZoDixN/sC8PbgkrtlqzsfDhlyj8DTcvbs RJMnyWPsXdeD6qy+YjNOAt0BO/ZMxfuUt8kkhHtJXBYa8FiB/xZhf3XrpDVOY8Uzmv 3BJ54Mg2qr5Gcuihk3d/5i6Ld4Nq0Lqnd952tua52DPh6BcLMb6TEtVjHl/pRrd43Y oX+BGOcjc1hKw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 181/844] media: cx25821: Fix a resource leak in cx25821_dev_setup() Date: Sat, 28 Feb 2026 12:21:34 -0500 Message-ID: <20260228173244.1509663-182-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit 68cd8ac994cac38a305200f638b30e13c690753b ] Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources(). Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/cx25821/cx25821-core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/cx25821/cx25821-core.c b/drivers/media/pci/c= x25821/cx25821-core.c index 6627fa9166d30..a7336be444748 100644 --- a/drivers/media/pci/cx25821/cx25821-core.c +++ b/drivers/media/pci/cx25821/cx25821-core.c @@ -908,6 +908,7 @@ static int cx25821_dev_setup(struct cx25821_dev *dev) =20 if (!dev->lmmio) { CX25821_ERR("ioremap failed, maybe increasing __VMALLOC_RESERVE in page.= h\n"); + release_mem_region(dev->base_io_addr, pci_resource_len(dev->pci, 0)); cx25821_iounmap(dev); return -ENOMEM; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACC0337CB38; Sat, 28 Feb 2026 17:36:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300163; cv=none; b=LLwg9QtRrP1PttOO9Br04fOsneK7jEVJDra6fI1BD2/JWE78r+DDDAai1TkgoTBG14Xp4GYzySyQ1677cbxqbm6Z0rntP5UY9Jm9dexq5OY/LeEbEGTdR7xp33sYdvY1JOqogh3LNSK6WODN3vT/3w6S8pqjF8l/bC7IfH3i0vA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300163; c=relaxed/simple; bh=gPbdJqv4xljmyF8pHGB5Em8Jezw6VJqYoetBZ/ST+5k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pprP5Mu+DV5X1HpoPEZIs5KhEw/eOUG3VkNkBpILAVn3urL3sQn9FhLLJgbXG0hQFpYxUn/a0H24i1CUA7VaYDHMWeTo0nW7mnYZeh7twU5JBILvN0zqAYXKykONUP/LPtqTGDDn/VpmK0fzxXIPkWXhK9aanUVvrDQiRqctr4w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jSdGZ3gf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jSdGZ3gf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C62B3C116D0; Sat, 28 Feb 2026 17:36:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300163; bh=gPbdJqv4xljmyF8pHGB5Em8Jezw6VJqYoetBZ/ST+5k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jSdGZ3gfDTtyWjcmTi0xxa14Czgxs9H7tnS7SzEEVzmMiY3LYgL5KB44HEyNbXQCA 3TDyUt6i9Hq6kVqvEt1mTmMsADS3WwTMVFey3BIrbZxbJSxmXkgcLkHO1m5tgP+LVI BznSl5uzeFrrzs5lj355WQmKWiyzE146YI3V5DY/MkMMbcVrI6kyl8JUMMaKQF2S0b /KvQL16wKls7XsNepIdLQKlrrScl4JJY5N9SDebxMFtIdoqI43NOpckAOwBaRErIde z20zUvDCMR+vAqKefW4ym1lE5naKfB1ForvnDni1Pq/oNb5wNd+9+aoeaJyJfg0byC mqmbzjj2CVLPQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vladimir Zapolskiy , Bryan O'Donoghue , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 182/844] media: qcom: camss: Do not enable cpas fast ahb clock for SM8550 VFE lite Date: Sat, 28 Feb 2026 12:21:35 -0500 Message-ID: <20260228173244.1509663-183-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vladimir Zapolskiy [ Upstream commit a89e490ba3551823511588b7b3828d67f8b82954 ] The clock is needed to stream images over a full VFE IP on SM8550 CAMSS, and it should not be enabled, when an image stream is routed over any of two lite VFE IPs on the SoC. Signed-off-by: Vladimir Zapolskiy Acked-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/camss/camss.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/plat= form/qcom/camss/camss.c index fcc2b2c3cba07..757c548af485a 100644 --- a/drivers/media/platform/qcom/camss/camss.c +++ b/drivers/media/platform/qcom/camss/camss.c @@ -2704,12 +2704,11 @@ static const struct camss_subdev_resources vfe_res_= 8550[] =3D { /* VFE3 lite */ { .regulators =3D {}, - .clock =3D { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb_clk", "vfe_lite_ah= b", + .clock =3D { "gcc_axi_hf", "cpas_ahb", "vfe_lite_ahb", "vfe_lite", "cpas_ife_lite", "camnoc_axi" }, .clock_rate =3D { { 0 }, { 80000000 }, { 300000000, 400000000 }, - { 300000000, 400000000 }, { 400000000, 480000000 }, { 300000000, 400000000 }, { 300000000, 400000000 } }, @@ -2726,12 +2725,11 @@ static const struct camss_subdev_resources vfe_res_= 8550[] =3D { /* VFE4 lite */ { .regulators =3D {}, - .clock =3D { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb_clk", "vfe_lite_ah= b", + .clock =3D { "gcc_axi_hf", "cpas_ahb", "vfe_lite_ahb", "vfe_lite", "cpas_ife_lite", "camnoc_axi" }, .clock_rate =3D { { 0 }, { 80000000 }, { 300000000, 400000000 }, - { 300000000, 400000000 }, { 400000000, 480000000 }, { 300000000, 400000000 }, { 300000000, 400000000 } }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F10237D785; Sat, 28 Feb 2026 17:36:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300164; cv=none; b=B3B28Z7GkPS1WCM0LbEGAFSZdaCWjA/yC5IxCx13uX8/ndX0BqDC20pXyW6GKK3+O8S5Mvub3BQsgJpw+0cmAmuQQoPmS8xPnd8W4+gAV71FnsSsig/BnLMWFuJ05aN6gYbgAqmP5pHRT8D14+CKnjFCJIbye6g7jIHN7Gbe52I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300164; c=relaxed/simple; bh=7Ai5J78US4WCWcSIRNjDnWgArYAcRIXbS/AvosGatCg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=m2+ksEVdk3+yh+O0smj5lnmN/M9az/U/HKXPUnZBpMew60hMnD8d2H6josgZo3XktcQ5rDqQo8aVUZv8fycpmCJFCdIslPdeOic2o1m/xdybCkb7FxgF4wnQBbjkCEWb16EyAk5dTzFxEgsNP8YdoI0MuhxA+jlcVtEO6US+0+U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JneeB8i3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JneeB8i3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2A14C116D0; Sat, 28 Feb 2026 17:36:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300164; bh=7Ai5J78US4WCWcSIRNjDnWgArYAcRIXbS/AvosGatCg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JneeB8i3fPRibOYE+G/VG/XHgMafBL2fc9gt8GC9y9OvHeNaka1Ugdm9s2doquC07 R9N6LktihtZaUsBbh0xumNL6EMpy2QIPDZcWiGgWZLEbmXiIwhSDn4Dj/dm0YkLAS5 1Prx/UWdGRkaDDRa5n+4klh4MKnnUkGTOUhF4VVYbhYkMf2DngN2kjpD1+KfsJ6AeI L8KDfUtW7P10QjLlHzNygJ9AqI6H7ZAKqHRfafZJgx699Ut2oBahlqlc8zJb4vQDez YPBBZGpeeqlE4t09rbhK0AQJu5NRi3IK5olsXfiwxnbBgEFO8LGiKdaNevwB3BzG6J UWucalHExa6gw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sakari Ailus , "Yew, Chang Ching" , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 183/844] media: v4l2-async: Fix error handling on steps after finding a match Date: Sat, 28 Feb 2026 12:21:36 -0500 Message-ID: <20260228173244.1509663-184-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sakari Ailus [ Upstream commit 7345d6d356336c448d6b9230ed8704f39679fd12 ] Once an async connection is found to be matching with an fwnode, a sub-device may be registered (in case it wasn't already), its bound operation is called, ancillary links are created, the async connection is added to the sub-device's list of connections and removed from the global waiting connection list. Further on, the sub-device's possible own notifier is searched for possible additional matches. Fix these specific issues: - If v4l2_async_match_notify() failed before the sub-notifier handling, the async connection was unbound and its entry removed from the sub-device's async connection list. The latter part was also done in v4l2_async_match_notify(). - The async connection's sd field was only set after creating ancillary links in v4l2_async_match_notify(). It was however dereferenced in v4l2_async_unbind_subdev_one(), which was called on error path of v4l2_async_match_notify() failure. Signed-off-by: Sakari Ailus Tested-by: "Yew, Chang Ching" Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/v4l2-core/v4l2-async.c | 45 +++++++++++++++++++--------- 1 file changed, 31 insertions(+), 14 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core= /v4l2-async.c index ee884a8221fbd..1c08bba9ecb91 100644 --- a/drivers/media/v4l2-core/v4l2-async.c +++ b/drivers/media/v4l2-core/v4l2-async.c @@ -343,7 +343,6 @@ static int v4l2_async_match_notify(struct v4l2_async_no= tifier *notifier, struct v4l2_subdev *sd, struct v4l2_async_connection *asc) { - struct v4l2_async_notifier *subdev_notifier; bool registered =3D false; int ret; =20 @@ -389,6 +388,25 @@ static int v4l2_async_match_notify(struct v4l2_async_n= otifier *notifier, dev_dbg(notifier_dev(notifier), "v4l2-async: %s bound (ret %d)\n", dev_name(sd->dev), ret); =20 + return 0; + +err_call_unbind: + v4l2_async_nf_call_unbind(notifier, sd, asc); + list_del(&asc->asc_subdev_entry); + +err_unregister_subdev: + if (registered) + v4l2_device_unregister_subdev(sd); + + return ret; +} + +static int +v4l2_async_nf_try_subdev_notifier(struct v4l2_async_notifier *notifier, + struct v4l2_subdev *sd) +{ + struct v4l2_async_notifier *subdev_notifier; + /* * See if the sub-device has a notifier. If not, return here. */ @@ -404,16 +422,6 @@ static int v4l2_async_match_notify(struct v4l2_async_n= otifier *notifier, subdev_notifier->parent =3D notifier; =20 return v4l2_async_nf_try_all_subdevs(subdev_notifier); - -err_call_unbind: - v4l2_async_nf_call_unbind(notifier, sd, asc); - list_del(&asc->asc_subdev_entry); - -err_unregister_subdev: - if (registered) - v4l2_device_unregister_subdev(sd); - - return ret; } =20 /* Test all async sub-devices in a notifier for a match. */ @@ -445,6 +453,10 @@ v4l2_async_nf_try_all_subdevs(struct v4l2_async_notifi= er *notifier) if (ret < 0) return ret; =20 + ret =3D v4l2_async_nf_try_subdev_notifier(notifier, sd); + if (ret < 0) + return ret; + /* * v4l2_async_match_notify() may lead to registering a * new notifier and thus changing the async subdevs @@ -829,7 +841,11 @@ int __v4l2_async_register_subdev(struct v4l2_subdev *s= d, struct module *module) ret =3D v4l2_async_match_notify(notifier, v4l2_dev, sd, asc); if (ret) - goto err_unbind; + goto err_unlock; + + ret =3D v4l2_async_nf_try_subdev_notifier(notifier, sd); + if (ret) + goto err_unbind_one; =20 ret =3D v4l2_async_nf_try_complete(notifier); if (ret) @@ -853,9 +869,10 @@ int __v4l2_async_register_subdev(struct v4l2_subdev *s= d, struct module *module) if (subdev_notifier) v4l2_async_nf_unbind_all_subdevs(subdev_notifier); =20 - if (asc) - v4l2_async_unbind_subdev_one(notifier, asc); +err_unbind_one: + v4l2_async_unbind_subdev_one(notifier, asc); =20 +err_unlock: mutex_unlock(&list_lock); =20 sd->owner =3D NULL; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB60637D7A6; Sat, 28 Feb 2026 17:36:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300165; cv=none; b=XmI5X5WsFMM2wUYEgMi30VZYNZ0zyshFO0NOq7ofe8rqj2SJOnKjTuSw6sNp4bWyVPTWEA7z8V0KxoHkiCxXsUAZDYeAS7LqthPpRLILDoJWBqxxS2NXjaOaDcOdZ/LrA6tOLQhmeeWUfEb6WYOAy0IjISTF+FTHpUVwWgrL2rA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300165; c=relaxed/simple; bh=acyDod6XCOH+jKSFS/GSgVrZwDWwzJ9Uzixv95uaBJU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aqx4tWPnE2yhxTgaK3qeek92SfVtDApmWJIs+w/k8hNjZtj7rifuWZJTEcUWHLYwKzNrTvMm9sVrjj6KisqIRZL6FJJSO2GQISYjIC5ZJf43VfkcCPjRvNMzIRb06O24r3A2ruOxo/acx9f+oUeyyWTmjIuwLz32G2RO5o3tmKM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CyhI3CFR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CyhI3CFR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5F19C19423; Sat, 28 Feb 2026 17:36:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300165; bh=acyDod6XCOH+jKSFS/GSgVrZwDWwzJ9Uzixv95uaBJU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CyhI3CFRp3PTcFKe6MiKXeYKsuhmZgrsh13TIjhe9VeRGEghfl7XkOj8Re98yJue2 CbZQU5Oxjz5scWp1mQ0bDT9WF4zjfWxfpb7TDF2YR18jrUy2nEr62iOKgZeZgTcKXJ 5fiIcRk/IZdN+mdc2hpNT0HVtOz4doXQzVXRw16WWAeRnWPZh+6LGvRQu+L1QjqRzn d1H1lexLXpBvk+kHonxrOg5qBqPDzQ3OsD3JastnomuGFR13PO841umvD5OwJ9p0CB INnPSKjrJUjUtS+WbBHtryExz06WgqnnimQyOf239LdQf3nui+hub5eI1+h4zxxHgm rDM7vqaFjCKTA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Laurent Pinchart , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 184/844] media: mt9m114: Avoid a reset low spike during probe() Date: Sat, 28 Feb 2026 12:21:37 -0500 Message-ID: <20260228173244.1509663-185-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit 84359d0a5e3afce5e3e3b6562efadff690614d5b ] mt9m114_probe() requests the reset GPIO in output low state: sensor->reset =3D devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW); and then almost immediately afterwards calls mt9m114_power_on() which does: gpiod_set_value(sensor->reset, 1); fsleep(duration); gpiod_set_value(sensor->reset, 0); which means that if the reset pin was high before this code runs that it will very briefly be driven low because of passing GPIOD_OUT_LOW when requesting the GPIO only to be driven high again possibly directly after that. Such a very brief driving low of the reset pin may put the chip in a confused state. Request the GPIO in high (reset the chip) state instead to avoid this, turning the initial gpiod_set_value() in mt9m114_power_on() into a no-op. and the fsleep() ensures that it will stay high long enough to properly reset the chip. Reviewed-by: Laurent Pinchart Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/mt9m114.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/mt9m114.c b/drivers/media/i2c/mt9m114.c index 51ebbe7ae9969..554f25071cca6 100644 --- a/drivers/media/i2c/mt9m114.c +++ b/drivers/media/i2c/mt9m114.c @@ -2434,7 +2434,7 @@ static int mt9m114_probe(struct i2c_client *client) goto error_ep_free; } =20 - sensor->reset =3D devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW); + sensor->reset =3D devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); if (IS_ERR(sensor->reset)) { ret =3D PTR_ERR(sensor->reset); dev_err_probe(dev, ret, "Failed to get reset GPIO\n"); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D1E0D37D7A1; Sat, 28 Feb 2026 17:36:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300166; cv=none; b=aBGR+ahu9x71/FBWHvR/3c1BPZN+wb5FazQ7PBviZVzFWFryybXjK0ZvAMGe4uPFZ4t0oFDg/K9F/VTEMkggU+A+2l3SkfVO3BGy6qmKSf43aH2a/6wNiJyxeVqGQY1nc3iJVR8qTx7iQzq4mhTJBWdSAf2UU5T2ibilH7l+gMU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300166; c=relaxed/simple; bh=CYMxtiBY6+W5eiUXskeWyFEavQ9L2866Ci7dWzcUohk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NHcOKHJlOrBXX9clo3OXboWGMIDWaH7hRKkRs88lV3cXIi4nmRPsyylSY3Q55G7sF4PUAiVdj233Lp0GogCWyQbESMLvTLdH7pTxYBTXE7h89bnx2i9Z/pT+yE/ls11KMzHXINCgCtVb6IBvnMjs2OHtGsvNgJv/N63ZryBhk9M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JyQ1YbP1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JyQ1YbP1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB8A5C116D0; Sat, 28 Feb 2026 17:36:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300166; bh=CYMxtiBY6+W5eiUXskeWyFEavQ9L2866Ci7dWzcUohk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JyQ1YbP1x6Q8LyR8PlBkBMp6IXqaUxkdd5Lds1lI7iVBeaGqAuVi77oW/Wg/v1cg4 mZgnPIsFKdjnskpVvKfhf3Nax8Xm/iU1eZLq3bEEI5k24W36CySHftdg3KJoLV6CDC 5hGiCyLDDerECTwx8B5wuYUW+8Y2Mo1nkcyIlfkuyuNmybt1Cq42NaIQWB+JiNV50U ulRear1hfIgn4zerqxFBDw1InzgSVGyyycSRZ2imrCa/pw37NJrcuUUkTnlGV1AMzf bHSXKchnkj4GrtMFaI2ZHoMRgahrkDbXTtQcAdNZW6uk/8gE+yzJRUd9SId5X2vBoo DTCTnkZQhW7IQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Laurent Pinchart , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 185/844] media: mt9m114: Return -EPROBE_DEFER if no endpoint is found Date: Sat, 28 Feb 2026 12:21:38 -0500 Message-ID: <20260228173244.1509663-186-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit 437e1f6a960035166495a5117aacbc596115eeb6 ] With IPU# bridges, endpoints may only be created when the IPU bridge is initialized. This may happen after the sensor driver's first probe(). Reviewed-by: Laurent Pinchart Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/mt9m114.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/mt9m114.c b/drivers/media/i2c/mt9m114.c index 554f25071cca6..b1325e2cd1321 100644 --- a/drivers/media/i2c/mt9m114.c +++ b/drivers/media/i2c/mt9m114.c @@ -2360,11 +2360,17 @@ static int mt9m114_parse_dt(struct mt9m114 *sensor) struct fwnode_handle *ep; int ret; =20 + /* + * On ACPI systems the fwnode graph can be initialized by a bridge + * driver, which may not have probed yet. Wait for this. + * + * TODO: Return an error once bridge driver code will have moved + * to the ACPI core. + */ ep =3D fwnode_graph_get_next_endpoint(fwnode, NULL); - if (!ep) { - dev_err(&sensor->client->dev, "No endpoint found\n"); - return -EINVAL; - } + if (!ep) + return dev_err_probe(&sensor->client->dev, -EPROBE_DEFER, + "waiting for fwnode graph endpoint\n"); =20 sensor->bus_cfg.bus_type =3D V4L2_MBUS_UNKNOWN; ret =3D v4l2_fwnode_endpoint_alloc_parse(ep, &sensor->bus_cfg); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C48CA37E66C; Sat, 28 Feb 2026 17:36:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300167; cv=none; b=G1AtnuV0XuSdqiw2mYQoYs13FmSrgauiazJZBVp8dAaNf8s8HiNy9Vz0wfQ5//rIo0BxMm9KqTXhpd95C4br+nzkvkmDhsIu2k16DIAGITbtPvQEwaXmtxJr8rAsYsvGRDwjFtZ2CTL2iFxgdQY+/brhzQ+f6/LIcEsztccHKz0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300167; c=relaxed/simple; bh=qN7FlshoqMU79pI9pEyR07XAtSCL+xPGJYwlXEJa1Y4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=j+egkOyecVXmaB0gpGzsuTRWh+MZ574dfIQou6J5ktqo/fmp52zFwBNg1xSB4NAi3fmnwkxpFM24NXeLubEolsb029NZgvbCqWLR2Oj0QEb4PIQ6YjlwtiIr1wkScDAUjAQ4GjU78XqWYqN3NDYULUVd37fiP0CtAE6iDJtJAgI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZvWpVR9I; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZvWpVR9I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5B2CC19424; Sat, 28 Feb 2026 17:36:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300167; bh=qN7FlshoqMU79pI9pEyR07XAtSCL+xPGJYwlXEJa1Y4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZvWpVR9IVf5ioFbyEfbUqyCn2e/VPkukTirljmvl2NnPKQ8/i2ZRPPyjPqz5sJDSM gu83pNjgJvy2xD/DuyIFDaNzIxIqeTSMeaHf2GLKqpDIG6LWfuZVteMHkqz5wWPGUw CiECp0rJid3nhQci2cEaRivy17zlqPNZssd/ciSN1eD5GwXhDY9Xbh1UCUWXMIyWUV /m1x1aWg1XUzkRoGl/QoYXE1UaWdzkALpmDlstLJ4yRQScbbfQmSBzPDA+b54mZybO 1z8PRUSntOQOngNZtHZJnWZiG+zADqainhO7HJQWrYmob2aim2mAUPUdlN690vaWtL mFT8D+htOCgtw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 186/844] media: ipu6: Ensure stream_mutex is acquired when dealing with node list Date: Sat, 28 Feb 2026 12:21:39 -0500 Message-ID: <20260228173244.1509663-187-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sakari Ailus [ Upstream commit 779bdaad2abf718fb8116839e818e58852874b4d ] The ipu6 isys driver maintains the list of video buffer queues related to a stream (in ipu6 context streams on the same CSI-2 virtual channel) and this list is modified through VIDIOC_STREAMON and VIDIOC_STREAMOFF IOCTLs. Ensure the common mutex is acquired when accessing the linked list, i.e. the isys device context's stream_mutex. Add a lockdep assert to ipu6_isys_get_buffer_list() and switch to guard() while at it as the error handling becomes more simple this way. Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/intel/ipu6/ipu6-isys-queue.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/media/pci/intel/ipu6/ipu6-isys-queue.c b/drivers/media= /pci/intel/ipu6/ipu6-isys-queue.c index aa2cf7287477c..8f05987cdb4e7 100644 --- a/drivers/media/pci/intel/ipu6/ipu6-isys-queue.c +++ b/drivers/media/pci/intel/ipu6/ipu6-isys-queue.c @@ -3,6 +3,7 @@ * Copyright (C) 2013--2024 Intel Corporation */ #include +#include #include #include #include @@ -201,6 +202,8 @@ static int buffer_list_get(struct ipu6_isys_stream *str= eam, unsigned long flags; unsigned long buf_flag =3D IPU6_ISYS_BUFFER_LIST_FL_INCOMING; =20 + lockdep_assert_held(&stream->mutex); + bl->nbufs =3D 0; INIT_LIST_HEAD(&bl->head); =20 @@ -294,9 +297,8 @@ static int ipu6_isys_stream_start(struct ipu6_isys_vide= o *av, struct ipu6_isys_buffer_list __bl; int ret; =20 - mutex_lock(&stream->isys->stream_mutex); + guard(mutex)(&stream->isys->stream_mutex); ret =3D ipu6_isys_video_set_streaming(av, 1, bl); - mutex_unlock(&stream->isys->stream_mutex); if (ret) goto out_requeue; =20 @@ -637,10 +639,10 @@ static void stop_streaming(struct vb2_queue *q) mutex_lock(&av->isys->stream_mutex); if (stream->nr_streaming =3D=3D stream->nr_queues && stream->streaming) ipu6_isys_video_set_streaming(av, 0, NULL); + list_del(&aq->node); mutex_unlock(&av->isys->stream_mutex); =20 stream->nr_streaming--; - list_del(&aq->node); stream->streaming =3D 0; mutex_unlock(&stream->mutex); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C480437E689; Sat, 28 Feb 2026 17:36:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300168; cv=none; b=mWCBGO+qnOTOl30QATP6uGbpnQ9sKgO1x386eYxXzMblKtBId4cDQfZXjNwSA5bSb0jZU9CzI5IRe4lh6m+wRLRgnFzZy4ErpMkw6JzxnwST0TPxTuWKoU6IZkHuQHNDNxQAeMWxbPNzohTq43XHmQSae5eBSNOYtLqghGVc+Nk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300168; c=relaxed/simple; bh=LzAX4keYGhJEwLHuci/VXnQHyeXr+Kc++ARkRwna2Ds=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d7mEe8MVtZaS/QhmsvTtCyTrTnFR6RNQZHoz9fcGOWQJhSO1Q6eaVnxHWFP0T1Anhc9XTLnJUS6pt7RJTUhbsllJY7QMHpWSAfipZfGEXlscG3Vz7jaH5Q4TCEP8NbBmPuBS11uJIXxP2qGTDXBNeNxMZusTnId8u/DGcl5gs6Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qL6NXC8J; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qL6NXC8J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1103C19423; Sat, 28 Feb 2026 17:36:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300168; bh=LzAX4keYGhJEwLHuci/VXnQHyeXr+Kc++ARkRwna2Ds=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qL6NXC8JeL0XFsn0CfLOdNaH8wwBX3fH0SaKenGD4YxlNviorotIzWgDDOOBy3PVY rm/bfFk23xNBZbU15wsKAwt7Fid2Tzggdl2JJT5H0fbvItQB3YaQbNhUkdcdAIB1YK aU2qft/SWb/S4tyMdZQI3F/AVJiRJtkdgpuoSMx9b9VsPPbKEBpW1qhVSIvwvb2PRu fZBzjAhYuzwWhrXFDfxIp941bnDMdFBUbtQLs3CEmDPzAMi1G2wP/Y6oyIkXgPPN8g 05O7979pmW7Rw1W7ETYlWOJOAe0tgzZ1AcyQ1NPGtXBCp9uKAZP0GNHltdsJ2ezW8r eW6/HhykHjyLQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sakari Ailus , Bingbu Cao , Mehdi Djait , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 187/844] media: ipu6: Close firmware streams on streaming enable failure Date: Sat, 28 Feb 2026 12:21:40 -0500 Message-ID: <20260228173244.1509663-188-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sakari Ailus [ Upstream commit 5925a92cc70d10c7d3124923c36da09b9c1a6eeb ] When enabling streaming fails, the stream is stopped in firmware but not closed. Do this to release resources on firmware side. Signed-off-by: Sakari Ailus Reviewed-by: Bingbu Cao Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/intel/ipu6/ipu6-isys-video.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/intel/ipu6/ipu6-isys-video.c b/drivers/media= /pci/intel/ipu6/ipu6-isys-video.c index dec8f5ffcfa5f..919b77107cef7 100644 --- a/drivers/media/pci/intel/ipu6/ipu6-isys-video.c +++ b/drivers/media/pci/intel/ipu6/ipu6-isys-video.c @@ -1066,6 +1066,7 @@ int ipu6_isys_video_set_streaming(struct ipu6_isys_vi= deo *av, int state, =20 out_media_entity_stop_streaming_firmware: stop_streaming_firmware(av); + close_streaming_firmware(av); =20 return ret; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D89D137D7BB; Sat, 28 Feb 2026 17:36:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300169; cv=none; b=Qr/XtAF4mxsVgmnM37Q4GGFXVo879Kg6oN2HvZZ1fKR34wl3/Uxi8VVrC+PMov4AhFkRfsm59Cwlgt1JDIAUkcDz0dVNu2aPwzs8jjZox6Ov62WOu4aKtL09Nq6Ys7r5Jm1edIYS/1iUfH+JB4M81rX1fcHsmFUbH3VBXw6qoPw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300169; c=relaxed/simple; bh=t/qWvLiiZTN9YhktCj57n4lM8XQf8ni+1HTIecX0v1Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=acMsHo08Zjh8lPzQ+DGHo837hXDKsiKSA2owVRc6wJ/7FaIpnQhAYUhJ/0KUtgTkrEdWd4R2kobjm+eMPEQrQE2gf6RooToEvSo9BAB6BcM1IBFYJSfdZM3BoE3/t2DWNWyEaIYbY4p5/NkCKzmgbE64bMs2OQTx4DesSVfBu0s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QifdZsQN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QifdZsQN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6D8AC116D0; Sat, 28 Feb 2026 17:36:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300169; bh=t/qWvLiiZTN9YhktCj57n4lM8XQf8ni+1HTIecX0v1Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QifdZsQNmIG8cZyG44OKQ3h+DdbdH8q2u2DsKKx84czuMd2Iynel+ZDCgRxaFxQmN WiJ2uGLbuj0yZwHTXoSsxB3OOjfCrRwEvwLUYWDtu/j9vrDjZorUpAc1l9D1wbV3mD cEWoAz2Ifi7rgyTmfhoMfIIaZkD0sN2elBwWNU/jWVo4JWGYbfuKCgui4qFBLBq+Ss 18Bdt7SuwOfheSWWWs2C3JqiWsRJC/KBIPhCA9DS69gylXRsoj8WyExUSu2yk9jGz1 LnaGkqngvNbn/JKJC65iZ8/j5phd2irfISZlBoWcMKL72nv/+Nm01jDV35FAPhjS4Y QoVob4CNoXqug== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sakari Ailus , Bingbu Cao , Bingbu Cao , Mehdi Djait , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 188/844] media: ipu6: Always close firmware stream Date: Sat, 28 Feb 2026 12:21:41 -0500 Message-ID: <20260228173244.1509663-189-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sakari Ailus [ Upstream commit 2b08b7007e55bd1793a58478d3ecea4fd95849a5 ] Close the firmware stream even when disabling a stream on an upstream sub-device fails. This allows the firmware to release resources related to a stream that is stopped in any case. Suggested-by: Bingbu Cao Signed-off-by: Sakari Ailus Reviewed-by: Bingbu Cao Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/intel/ipu6/ipu6-isys-video.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/pci/intel/ipu6/ipu6-isys-video.c b/drivers/media= /pci/intel/ipu6/ipu6-isys-video.c index 919b77107cef7..54d861aca0088 100644 --- a/drivers/media/pci/intel/ipu6/ipu6-isys-video.c +++ b/drivers/media/pci/intel/ipu6/ipu6-isys-video.c @@ -1036,11 +1036,10 @@ int ipu6_isys_video_set_streaming(struct ipu6_isys_= video *av, int state, sd->name, r_pad->index, stream_mask); ret =3D v4l2_subdev_disable_streams(sd, r_pad->index, stream_mask); - if (ret) { + if (ret) dev_err(dev, "stream off %s failed with %d\n", sd->name, ret); - return ret; - } + close_streaming_firmware(av); } else { ret =3D start_stream_firmware(av, bl); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 88B6137F04A; Sat, 28 Feb 2026 17:36:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300170; cv=none; b=gy1hubwtD+DSvDw144djuy5wv0ikhv5qiCJbnLwCxba0NQA3aOrcObczbUOACxryrO2je5uqW9IU4wcx6ltNtXff+QIMFGMnDI/df8WaE8OD6wNAclvFwhKZivt6buOZcJWeMlN1THc3QrjiNNA5lD05JCeyaLRtKjrPgT9KfmY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300170; c=relaxed/simple; bh=kH2Q4tjC6AD30/OuYaSFbeXe/W8j/TLTaXSK7hAfnPg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QJ3cOmmmfPrN1QmZDiF+3Krv5WiXfnOUiGoQSesFqeYXIUCjx7ApxO/J33EA9tzeFYDJpurtPSlsZ54/wMtZNxRu7AESzUqNDBy0BctjquDPG9cDcQUOEc+GoqSPXp3xHYYD4Aq0E5IEPURVs6oqXmZGcZtqFp4LOpzZ4HHtEbw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Tt8D1Tu4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Tt8D1Tu4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1E13C19424; Sat, 28 Feb 2026 17:36:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300170; bh=kH2Q4tjC6AD30/OuYaSFbeXe/W8j/TLTaXSK7hAfnPg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Tt8D1Tu4yUI7eg4GKeLGszUwz6mS2s8mnmG1zOZni4zG14ZlbFULGnyooUjNXMmQj v9ZvYU1qDlv52sIRtmtVlSntCLtvTBtEdNfpGufmGXRe+GIJbxNTAgzf91jbkDTwnk +2bLgIBHIzmAw5yoLNWJU/G7E6+ortlPG0Jk94HBu4OkpP3ORx1jwmycNIX9yyM6TB VhlF7QtBmA02rcy0LCk7cMT8oOdekvbpxehHW36ELpRPv78+JguQNzmUuyzQaUPO8K zsLgCve34Ps4M/kMMGcChrH1uvOlG96+I0VMTEzn6nUoNxTQQVzw6du1r8tJan+jZ0 kBr2UeQSNEuxw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bharat Dev Burman , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 189/844] ALSA: hda/realtek: add HP Victus 16-e0xxx mute LED quirk Date: Sat, 28 Feb 2026 12:21:42 -0500 Message-ID: <20260228173244.1509663-190-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bharat Dev Burman [ Upstream commit 72919c57a055f6d7b79d66731dc398e9b433f47c ] HP Victus 16-e0xxx with ALC245 codec does not handle the toggling of the mute LED. This patch adds a quirk entry for subsystem ID 0x88eb using a new ALC245_FIXUP_HP_MUTE_LED_V2_COEFBIT fixup, enabling correct mute LED behavior. Signed-off-by: Bharat Dev Burman Link: https://patch.msgid.link/20260112184253.33376-1-bharat.singh7924@gmai= l.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/hda/codecs/realtek/alc269.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/a= lc269.c index 1964494321006..c9f59e62ee022 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -1551,6 +1551,22 @@ static void alc245_fixup_hp_mute_led_v1_coefbit(stru= ct hda_codec *codec, } } =20 +static void alc245_fixup_hp_mute_led_v2_coefbit(struct hda_codec *codec, + const struct hda_fixup *fix, + int action) +{ + struct alc_spec *spec =3D codec->spec; + + if (action =3D=3D HDA_FIXUP_ACT_PRE_PROBE) { + spec->mute_led_polarity =3D 0; + spec->mute_led_coef.idx =3D 0x0b; + spec->mute_led_coef.mask =3D 1 << 3; + spec->mute_led_coef.on =3D 1 << 3; + spec->mute_led_coef.off =3D 0; + snd_hda_gen_add_mute_led_cdev(codec, coef_mute_led_set); + } +} + /* turn on/off mic-mute LED per capture hook by coef bit */ static int coef_micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) @@ -3828,6 +3844,7 @@ enum { ALC287_FIXUP_YOGA7_14ARB7_I2C, ALC245_FIXUP_HP_MUTE_LED_COEFBIT, ALC245_FIXUP_HP_MUTE_LED_V1_COEFBIT, + ALC245_FIXUP_HP_MUTE_LED_V2_COEFBIT, ALC245_FIXUP_HP_X360_MUTE_LEDS, ALC287_FIXUP_THINKPAD_I2S_SPK, ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD, @@ -6165,6 +6182,10 @@ static const struct hda_fixup alc269_fixups[] =3D { .type =3D HDA_FIXUP_FUNC, .v.func =3D alc245_fixup_hp_mute_led_v1_coefbit, }, + [ALC245_FIXUP_HP_MUTE_LED_V2_COEFBIT] =3D { + .type =3D HDA_FIXUP_FUNC, + .v.func =3D alc245_fixup_hp_mute_led_v2_coefbit, + }, [ALC245_FIXUP_HP_X360_MUTE_LEDS] =3D { .type =3D HDA_FIXUP_FUNC, .v.func =3D alc245_fixup_hp_mute_led_coefbit, @@ -6654,6 +6675,7 @@ static const struct hda_quirk alc269_fixup_tbl[] =3D { SND_PCI_QUIRK(0x103c, 0x8898, "HP EliteBook 845 G8 Notebook PC", ALC285_F= IXUP_HP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x103c, 0x88d0, "HP Pavilion 15-eh1xxx (mainboard 88D0)", A= LC287_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x88dd, "HP Pavilion 15z-ec200", ALC285_FIXUP_HP_MU= TE_LED), + SND_PCI_QUIRK(0x103c, 0x88eb, "HP Victus 16-e0xxx", ALC245_FIXUP_HP_MUTE_= LED_V2_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8902, "HP OMEN 16", ALC285_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x890e, "HP 255 G8 Notebook PC", ALC236_FIXUP_HP_MU= TE_LED_COEFBIT2), SND_PCI_QUIRK(0x103c, 0x8919, "HP Pavilion Aero Laptop 13-be0xxx", ALC287= _FIXUP_HP_GPIO_LED), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6CE3437F065; Sat, 28 Feb 2026 17:36:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300171; cv=none; b=XOrxNoWaRhaSEn+Bv+AHMzbj35gDIAxYEmwrQvd9wvoeW9HF16BBzhwa8LtkSPGoCYrA7t/tbaQCFhRHMr7JDCvyW912vAyBIC3b5FF0g+Fi1K5dEYOxI5Q49PeN0uZSC5RUMyVIvC6xI0l5wmaj3dc74Xd0MC2XcntLlrW6lsw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300171; c=relaxed/simple; bh=odQ+4/bj/EP9KkzmwwS1nhiZpaJpBM5UhNg2PTpCOCk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WdlcnmqhlVgAZtfo3/10ZZe7tRiwkhTERIbsggp/Pnjo1JTbsgaUdim1AVwFvnHpHTPAL51d1yD050cqYK5bQQweI1QMFsSIkrJYPPaMXxat2P+ZYawSO9QF7lw2dHxAIEe4R9g+9cjeHf86K+KgHfc2VPwE9vZQHcish7FTE2w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cooa/S5v; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cooa/S5v" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADE98C19424; Sat, 28 Feb 2026 17:36:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300171; bh=odQ+4/bj/EP9KkzmwwS1nhiZpaJpBM5UhNg2PTpCOCk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cooa/S5v8iJJNuC9cbTFwNfJlgJkCN9TFxK3Y4hM0usXiAx6sARwAOH3ccV8jjRBy 6hu9rrZygQvGjUGDEJEfwm+tgNGwISoukCHrBBqrX4ZQ7sTxrzT3nzVZ6H1XEy46Va DIJb686yFyLFShDZjra2m9tDrRZR6xynkz49TlbnwLa0NZEl4MUaGB6I2s9kHxcEHE mmjtoF7kiG64pzyOybOGsuC+bQjmIrqOzyTZsemlVofqWl727lIVwLOc64WXhLfwU8 69uyPGjWnmWF5cf1SiKx+oZASo0dX4MP1FVkLf1DjfaeAvSIUOdWOZQ6eF9GJh5Heu 4OAaAaDWvJVdw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: fenugrec , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 190/844] ALSA: usb-audio: presonus s18xx uses little-endian Date: Sat, 28 Feb 2026 12:21:43 -0500 Message-ID: <20260228173244.1509663-191-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: fenugrec [ Upstream commit 3ce03297baff0ba116769044e4594fb324d4a551 ] Use __le32 types for USB control transfers Signed-off-by: fenugrec Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260111-preso_clean1-v2-1-44b4e5129a75@mail= .com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/usb/mixer_s1810c.c | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/sound/usb/mixer_s1810c.c b/sound/usb/mixer_s1810c.c index 6e09e074c0e7f..93510aa0dc5ef 100644 --- a/sound/usb/mixer_s1810c.c +++ b/sound/usb/mixer_s1810c.c @@ -82,13 +82,13 @@ * mixer and output but a different set for device. */ struct s1810c_ctl_packet { - u32 a; - u32 b; - u32 fixed1; - u32 fixed2; - u32 c; - u32 d; - u32 e; + __le32 a; + __le32 b; + __le32 fixed1; + __le32 fixed2; + __le32 c; + __le32 d; + __le32 e; }; =20 #define SC1810C_CTL_LINE_SW 0 @@ -118,7 +118,7 @@ struct s1810c_ctl_packet { * being zero and different f1/f2. */ struct s1810c_state_packet { - u32 fields[63]; + __le32 fields[63]; }; =20 #define SC1810C_STATE_48V_SW 58 @@ -140,14 +140,14 @@ snd_s1810c_send_ctl_packet(struct usb_device *dev, u3= 2 a, struct s1810c_ctl_packet pkt =3D { 0 }; int ret =3D 0; =20 - pkt.fixed1 =3D SC1810C_CMD_F1; - pkt.fixed2 =3D SC1810C_CMD_F2; + pkt.fixed1 =3D __cpu_to_le32(SC1810C_CMD_F1); + pkt.fixed2 =3D __cpu_to_le32(SC1810C_CMD_F2); =20 - pkt.a =3D a; - pkt.b =3D b; - pkt.c =3D c; - pkt.d =3D d; - pkt.e =3D e; + pkt.a =3D __cpu_to_le32(a); + pkt.b =3D __cpu_to_le32(b); + pkt.c =3D __cpu_to_le32(c); + pkt.d =3D __cpu_to_le32(d); + pkt.e =3D __cpu_to_le32(e); =20 ret =3D snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), SC1810C_CMD_REQ, @@ -176,8 +176,8 @@ snd_sc1810c_get_status_field(struct usb_device *dev, struct s1810c_state_packet pkt_in =3D { { 0 } }; int ret =3D 0; =20 - pkt_out.fields[SC1810C_STATE_F1_IDX] =3D SC1810C_SET_STATE_F1; - pkt_out.fields[SC1810C_STATE_F2_IDX] =3D SC1810C_SET_STATE_F2; + pkt_out.fields[SC1810C_STATE_F1_IDX] =3D __cpu_to_le32(SC1810C_SET_STATE_= F1); + pkt_out.fields[SC1810C_STATE_F2_IDX] =3D __cpu_to_le32(SC1810C_SET_STATE_= F2); ret =3D snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), SC1810C_SET_STATE_REQ, SC1810C_SET_STATE_REQTYPE, @@ -197,7 +197,7 @@ snd_sc1810c_get_status_field(struct usb_device *dev, return ret; } =20 - (*field) =3D pkt_in.fields[field_idx]; + (*field) =3D __le32_to_cpu(pkt_in.fields[field_idx]); (*seqnum)++; return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7EF1847DD69; Sat, 28 Feb 2026 17:36:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300172; cv=none; b=q9EVWgSILVf0bDIN/frcRkfB87MnOCw1ei25DAxl47q10K1ZrOfwchewDdKNiFLOiZ2vf1+gip6i76guLdX7Y3U/yDN0aNk52sT6Qo4g+fOIT6liOXRJblQGEbqbNF5xpCkf1g84vecQ9B+/jwvaQUyfIKruszUxBeDrbRMw/DQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300172; c=relaxed/simple; bh=BzE1gBPpCyLPPTAUrwMVtOT5vUOURwrYx36Nm0Pv+ho=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CCuVkMm4z4ORsSoR9+KnH3+TRwaNQlprz9N9eA3JuNbgRSwdXGYP5+jdksudcp7bwFILdiApK2G4aAupxOv/dDUa8W61xxgTnaRm9fGJRRYdXP8o4aScPapGAkYaMiABa8dccmaJ5cjFUT2Q3szH94zebddxMBMm2srwdeXf5Ic= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IL58wnAO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IL58wnAO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B569C19423; Sat, 28 Feb 2026 17:36:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300172; bh=BzE1gBPpCyLPPTAUrwMVtOT5vUOURwrYx36Nm0Pv+ho=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IL58wnAOIEtiIuy92TK6stXEWxhRADJzFi6EInF8cbxiCP6Y6gWRIDWEGlsms94XL 97UZbDJiAtdnnhAyqi7o+c/B9wE4W09eOmfGKhrmSesDNmfHlFOjW8Tb1DBiCP3xND wW8JdDTCwuyN78ZsRVOZYRa43TPv3DLfdpevhH5J5D9up03r2gQsKSjmbTJ2jOyPUS xAQa+1chO3XNsG3huENefMydCNXVeYp+9HJ2vJ53omO8Cd1u2PXf4SDY50d/3iPW7x hw02s9nSUD+DFrfKpijMrPCr/qRrGL3ujkzOlG+ZCAh6AT0/pBUr1VJiic4DBb7GLK Mo31n1m5pmaBg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Donet Tom , =?UTF-8?q?Christian=20K=C3=B6nig?= , Philip Yang , Felix Kuehling , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 191/844] drm/amdkfd: Relax size checking during queue buffer get Date: Sat, 28 Feb 2026 12:21:44 -0500 Message-ID: <20260228173244.1509663-192-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Donet Tom [ Upstream commit 42ea9cf2f16b7131cb7302acb3dac510968f8bdc ] HW-supported EOP buffer sizes are 4K and 32K. On systems that do not use 4K pages, the minimum buffer object (BO) allocation size is PAGE_SIZE (for example, 64K). During queue buffer acquisition, the driver currently checks the allocated BO size against the supported EOP buffer size. Since the allocated BO is larger than the expected size, this check fails, preventing queue creation. Relax the strict size validation and allow PAGE_SIZE-sized BOs to be used. Only the required 4K region of the buffer will be used as the EOP buffer and avoids queue creation failures on non-4K page systems. Acked-by: Christian K=C3=B6nig Suggested-by: Philip Yang Signed-off-by: Donet Tom Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c b/drivers/gpu/drm/amd/a= mdkfd/kfd_queue.c index 80c4fa2b0975d..2822c90bd7be4 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_queue.c @@ -275,8 +275,8 @@ int kfd_queue_acquire_buffers(struct kfd_process_device= *pdd, struct queue_prope =20 /* EOP buffer is not required for all ASICs */ if (properties->eop_ring_buffer_address) { - if (properties->eop_ring_buffer_size !=3D topo_dev->node_props.eop_buffe= r_size) { - pr_debug("queue eop bo size 0x%x not equal to node eop buf size 0x%x\n", + if (properties->eop_ring_buffer_size < topo_dev->node_props.eop_buffer_s= ize) { + pr_debug("queue eop bo size 0x%x is less than node eop buf size 0x%x\n", properties->eop_ring_buffer_size, topo_dev->node_props.eop_buffer_size); err =3D -EINVAL; @@ -284,7 +284,7 @@ int kfd_queue_acquire_buffers(struct kfd_process_device= *pdd, struct queue_prope } err =3D kfd_queue_buffer_get(vm, (void *)properties->eop_ring_buffer_add= ress, &properties->eop_buf_bo, - properties->eop_ring_buffer_size); + ALIGN(properties->eop_ring_buffer_size, PAGE_SIZE)); if (err) goto out_err_unreserve; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9905381CBF; Sat, 28 Feb 2026 17:36:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300173; cv=none; b=VGFYyT1S/WD0R6dlcicXNdDozq1UUS1wUjeCc0nD4NX3ZJwSZ3T6LfIKuWYlhxp+9yKhgikh27Got94cClGPS4vy7d0phRncEqMHZzC/ym+XjLDDosOnsA22RRpiML6dWM3K1nTkPRReyfzXKkOqeTCVrQYy5GtOqLDyCOcy3go= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300173; c=relaxed/simple; bh=eJtyVck8aATmjY54Z7ZJUhHhk9S7xobDAX5bxsj0qi0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=GszRTIbAsEXH5yCFlUlkZHa9N95OlxoUGdo9Zd7bFLTxlGLoreI0HiSAPKB7couX5pVetKv5B5/5+9AJvmKdHCpmv4mBsQAWqyJml1xCMvPhr80Pgza6hRTUOWq5hcBvxsGvEN3rMGWoLuc/RfBaCiJHwdKUAE0/nhO5ma4LB38= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y3pPVPRT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y3pPVPRT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5D2AC19424; Sat, 28 Feb 2026 17:36:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300173; bh=eJtyVck8aATmjY54Z7ZJUhHhk9S7xobDAX5bxsj0qi0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y3pPVPRTpQgda92c8qsQXnuPEhyA88PhIv59HNQ7WIjCqI7ZOimN4VPdPchq3kxS/ I21CSDjfB681YLbB6cF6GQJ+PA/SKlJ8AW19dEZfjNem8p3SmhKcAw87kOx9wYOOID Df7oMIgPWFeHTnq0LDUTEvix3/UoLpA6AeHyuiy8qXV+oJ3jCwxPKtyDsey7kHC06u wGA1LN+wIOCe4lQGu89389rf+0vzuAlb5aj+N0VUonOVQm5VWlqrqLa34iEe3M+TrQ NXp0ZmUSCw0ufPo785Peax2fXLGH43k251Rj/QES6uWU1D2xcbErLEYwh8xjq67QZp KFr1ckidEQlFA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Donet Tom , =?UTF-8?q?Christian=20K=C3=B6nig?= , Philip Yang , "Ritesh Harjani (IBM)" , Felix Kuehling , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 192/844] drm/amdkfd: Fix GART PTE for non-4K pagesize in svm_migrate_gart_map() Date: Sat, 28 Feb 2026 12:21:45 -0500 Message-ID: <20260228173244.1509663-193-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Donet Tom [ Upstream commit 6c160001661b6c4e20f5c31909c722741e14c2d8 ] In svm_migrate_gart_map(), while migrating GART mapping, the number of bytes copied for the GART table only accounts for CPU pages. On non-4K systems, each CPU page can contain multiple GPU pages, and the GART requires one 8-byte PTE per GPU page. As a result, an incorrect size was passed to the DMA, causing only a partial update of the GART table. Fix this function to work correctly on non-4K page-size systems by accounting for the number of GPU pages per CPU page when calculating the number of bytes to be copied. Acked-by: Christian K=C3=B6nig Reviewed-by: Philip Yang Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Donet Tom Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c b/drivers/gpu/drm/amd= /amdkfd/kfd_migrate.c index 6ada7b4af7c68..5086caac3fd06 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c @@ -61,7 +61,7 @@ svm_migrate_gart_map(struct amdgpu_ring *ring, u64 npages, *gart_addr =3D adev->gmc.gart_start; =20 num_dw =3D ALIGN(adev->mman.buffer_funcs->copy_num_dw, 8); - num_bytes =3D npages * 8; + num_bytes =3D npages * 8 * AMDGPU_GPU_PAGES_IN_CPU_PAGE; =20 r =3D amdgpu_job_alloc_with_ib(adev, &adev->mman.high_pr, AMDGPU_FENCE_OWNER_UNDEFINED, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D444B381CDD; Sat, 28 Feb 2026 17:36:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300174; cv=none; b=JtWyDIIHXzQ/X5nzkVQaMt7ESbQZkxMn4L8pBnhGCoQu+U4pElUYCHWF/cHeN8RkcPubGmVHZfBIy+PEPa0tm82NE9IWqGTF848trejKaRMuxCFDQWvwK6eCeUGcvxE6L/yWwzTH8OuTU3vb15Jbj7MaJ4gcDNc0kuE7XBx0wKo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300174; c=relaxed/simple; bh=T9FGvJhnf/Nzrx56iXUJ+P2/8aqv2CDO+boMUZgDRfw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KcEwZEwqLqqEReTFogD8SJrse1Y4NBzF7gLGWzxReYS8Sumxakz/1tJ4Gkf9BxSW6+waeHUoZaX+s2aKf4Cto3Hs6Opwffpy0XNEI4NXiq6LAuleR8R6G+OvvUIam2IJRpEkEtWfzXdxe3MXSizYg0/xrvRnSQPkocPWF5KytaI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oZU7meIA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oZU7meIA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7112C19425; Sat, 28 Feb 2026 17:36:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300174; bh=T9FGvJhnf/Nzrx56iXUJ+P2/8aqv2CDO+boMUZgDRfw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oZU7meIAVUCHRBfbjHzL1m3UCjtQEsAxQ1iimSberrQV+hR6e9RA6sQWJquUCcTFL 1Opsq9SBEDegttA0+0IvQ0tXGHQrUwTLpgEfo4RW7G9ljAlVpC2EF00OJ/y4umqoxt 1RujqgVOcPuEV6pPAczJtTZ79j4LaYsHV2ZLciItKh6S3scJrS4Jg4cKPi6DOEle21 yLP3vPmUHq06t3kBZLlHvjhmurfsQmjpHxiWPQcMexfkJ8IvRCrsge+IP8Mnnk9yOY q5qP4txteYC6v40rph8/on9KswYz4Bt9A9Q4BrAGDlQ4Oz+k6HmNbMXSKPRe/Aq3A1 pdEFFqAWF4nRw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xiao Kan <814091656@qq.com>, Xiao Kan , Maxime Ripard , Sasha Levin Subject: [PATCH 6.19 193/844] drm: Account property blob allocations to memcg Date: Sat, 28 Feb 2026 12:21:46 -0500 Message-ID: <20260228173244.1509663-194-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xiao Kan <814091656@qq.com> [ Upstream commit 26b4309a3ab82a0697751cde52eb336c29c19035 ] DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the = memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits. Signed-off-by: Xiao Kan <814091656@qq.com> Signed-off-by: Xiao Kan Link: https://patch.msgid.link/tencent_D12AA2DEDE6F359E1AF59405242FB7A5FD05= @qq.com Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/drm_property.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c index 596272149a359..3c88b5fbdf28c 100644 --- a/drivers/gpu/drm/drm_property.c +++ b/drivers/gpu/drm/drm_property.c @@ -562,7 +562,7 @@ drm_property_create_blob(struct drm_device *dev, size_t= length, if (!length || length > INT_MAX - sizeof(struct drm_property_blob)) return ERR_PTR(-EINVAL); =20 - blob =3D kvzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL); + blob =3D kvzalloc(sizeof(struct drm_property_blob) + length, GFP_KERNEL_A= CCOUNT); if (!blob) return ERR_PTR(-ENOMEM); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A37A63824C0; Sat, 28 Feb 2026 17:36:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300175; cv=none; b=tSn23x1c5ViCYQIc8o1TS3t91GlYnBlgH1FKyeRkZ+bqn1jbEeE6bdOBxSHTNM29Fq+MR/as0gIvOIFS+jfZVLqMqiotZUQoZC48Ypgqouyc9Pw8zB5Fgu0QO+YtEvN0ioG5WBq/Rcg4KiOSa+/1Qdq9V1P0l7zMStZxUrbwYgo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300175; c=relaxed/simple; bh=CGs+Yh1fzTOO0OdCToY9WGnEC+1GhZDEBJ9GM04t9O4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ab8cMhHwHjDfluYmxnwTW1coH1xZdK0NrgsL9hmd+L2b7VKwzhCWw0qpnGg/DQtb+igTxB0HUZbGxfWMyVUtMAnKNiAJ1DD5pat3xynrNlsDRcpWAgprvPzDo+h+xURK3F/eWT1CcsBnjbDg9huhvpRTcTaVPzjbMYHmN4Q9zv8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F28f7SgF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F28f7SgF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA3D3C116D0; Sat, 28 Feb 2026 17:36:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300175; bh=CGs+Yh1fzTOO0OdCToY9WGnEC+1GhZDEBJ9GM04t9O4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F28f7SgFhD13iG2Pa8XrX9vttbiUplnao0qjfAf/WdvWOIs1I0J2wXZdYAxOHcW/7 ONktl7JIVRZzJm7CatnZZIuhnYeFjUJ0xKtYPxxxpeLWh5VcnPWOMlPVHPxaEdbeV4 SNBQsr9EWVnJ9PozzBCZU5VaMRMn959ahLNN3+kXA0nzAQorOfvhbRz6kOSphyJuWN +TZJ2MkZp4CmOuz/caNwfVYubdC4cRJ7hR2VvUpc8OXABoIA/tqiE50kChGzcBNTWR m08iHf8RUnbiKShyIrgDAyTgF410SbFfV+IQkx6kDMu1FNfzWP+8DI+E5H0//QbS1Y 9sRVkOSIuPu7g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hugo Villeneuve , Biju Das , Sasha Levin Subject: [PATCH 6.19 194/844] drm: renesas: rz-du: mipi_dsi: fix kernel panic when rebooting for some panels Date: Sat, 28 Feb 2026 12:21:47 -0500 Message-ID: <20260228173244.1509663-195-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hugo Villeneuve [ Upstream commit 64aa8b3a60a825134f7d866adf05c024bbe0c24c ] Since commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L") we may get the following kernel panic, for some panels, when rebooting: systemd-shutdown[1]: Rebooting. Call trace: ... do_serror+0x28/0x68 el1h_64_error_handler+0x34/0x50 el1h_64_error+0x6c/0x70 rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P) mipi_dsi_device_transfer+0x44/0x58 mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4 ili9881c_unprepare+0x38/0x88 drm_panel_unprepare+0xbc/0x108 This happens for panels that need to send MIPI-DSI commands in their unprepare() callback. Since the MIPI-DSI interface is stopped at that point, rzg2l_mipi_dsi_host_transfer() triggers the kernel panic. Fix by moving rzg2l_mipi_dsi_stop() to new callback function rzg2l_mipi_dsi_atomic_post_disable(). With this change we now have the correct power-down/stop sequence: systemd-shutdown[1]: Rebooting. rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_post_disable(): entry reboot: Restarting system Suggested-by: Biju Das Signed-off-by: Hugo Villeneuve Tested-by: Biju Das Link: https://patch.msgid.link/20260112154333.655352-1-hugo@hugovil.com Signed-off-by: Biju Das Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c b/drivers/gpu/d= rm/renesas/rz-du/rzg2l_mipi_dsi.c index 3b52dfc0ea1e0..b164e3a62cc2f 100644 --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c @@ -646,6 +646,13 @@ static void rzg2l_mipi_dsi_atomic_disable(struct drm_b= ridge *bridge, =20 rzg2l_mipi_dsi_stop_video(dsi); rzg2l_mipi_dsi_stop_hs_clock(dsi); +} + +static void rzg2l_mipi_dsi_atomic_post_disable(struct drm_bridge *bridge, + struct drm_atomic_state *state) +{ + struct rzg2l_mipi_dsi *dsi =3D bridge_to_rzg2l_mipi_dsi(bridge); + rzg2l_mipi_dsi_stop(dsi); } =20 @@ -681,6 +688,7 @@ static const struct drm_bridge_funcs rzg2l_mipi_dsi_bri= dge_ops =3D { .atomic_pre_enable =3D rzg2l_mipi_dsi_atomic_pre_enable, .atomic_enable =3D rzg2l_mipi_dsi_atomic_enable, .atomic_disable =3D rzg2l_mipi_dsi_atomic_disable, + .atomic_post_disable =3D rzg2l_mipi_dsi_atomic_post_disable, .mode_valid =3D rzg2l_mipi_dsi_bridge_mode_valid, }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD3553824E7; Sat, 28 Feb 2026 17:36:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300176; cv=none; b=BWlNtmN9NWh63LbuNFbqdQFl5A8XBFVgO2Armqbbt0FSENM/uQRrYr8fJIxB1uvTRM4swaooj9m6ORo0A3CKEHU2/E2SCFeM0LQ4/56DPwPTMAh0RHFIVwb86dsxpkEp6TyYtBaHAHLAJJsAIYZHwnGeipj+s4FNEkrHUtRIjEc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300176; c=relaxed/simple; bh=qQVS1+SNYkHb2oV7rUK6aHfhX6IPuk23megtrKNAwwU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZRx6ttpXGOsfBmMvQW8IjImvQxxPTCbXkcHHt0NDDM/QpOjz3sNAhht8vQjXEApa3TnoaAMNVDtrVPaRVHb8rInyoYqOR6bKM/xqal2BfH1SlDI7rbC6U5kqjS/9JTwe/XtHvbUen6gg3f0ja7YG881IOmlnFLUvPTgikddJL9Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A3+S10jR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="A3+S10jR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A445AC2BC87; Sat, 28 Feb 2026 17:36:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300176; bh=qQVS1+SNYkHb2oV7rUK6aHfhX6IPuk23megtrKNAwwU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A3+S10jRLKEZZHm07vLOWPaa9VJYct4SEv+57+Nj2EdhGxguPDobZd+J1rJkJ09ir rc94Wszo5XlGkypMFJm9edRkKrGQS7rwV3ukwmU59vh1GIAbULebPo6UbyVSlrKI7y p6UX4bAgfvEt6irkE7sNarJj37FSVQa7zJPVuJlqK1wNizu/yHiuqwR5nG8WsmOWmp F2B2qlWT7n3FxDfLr2XYudj4k5kDvYu2XHULk0mxQc3BYFo8VwqZRZ1k4q+XeBLBdI yoZcyGk/wG0TJI5q45UJ2mkb77K5IjcZMfbW1m8kqiamBXiVtzy48+LvIlyNd7Ym5q l+uEQjA41UfEw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , kernel test robot , Nathan Chancellor , Arnd Bergmann , "Wei Liu (Microsoft)" , Nicolas Schier , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 195/844] hyper-v: Mark inner union in hv_kvp_exchg_msg_value as packed Date: Sat, 28 Feb 2026 12:21:48 -0500 Message-ID: <20260228173244.1509663-196-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Thomas Wei=C3=9Fschuh [ Upstream commit 1e5271393d777f6159d896943b4c44c4f3ecff52 ] The unpacked union within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/hyperv.h:361:2: error: field within 'struct hv_kvp_exc= hg_msg_value' is less aligned than 'union hv_kvp_exchg_msg_value::(anonymous at ./usr/i= nclude/linux/hyperv.h:361:2)' and is usually due to 'struct hv_kvp_exchg_msg_value' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 361 | union { | ^ With the recent changes to compile-test the UAPI headers in more cases, this warning in combination with CONFIG_WERROR breaks the build. Fix the warning. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512140314.DzDxpIVn-lkp@int= el.com/ Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-hea= ders-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/linux-kbuild/29b2e736-d462-45b7-a0a9-85f8d8a3= de56@app.fastmail.com/ Signed-off-by: Thomas Wei=C3=9Fschuh Acked-by: Wei Liu (Microsoft) Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260115-kbuild-alignment-vbox-v1-1-076aed16= 23ff@linutronix.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/uapi/linux/hyperv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux/hyperv.h b/include/uapi/linux/hyperv.h index aaa502a7bff46..1749b35ab2c21 100644 --- a/include/uapi/linux/hyperv.h +++ b/include/uapi/linux/hyperv.h @@ -362,7 +362,7 @@ struct hv_kvp_exchg_msg_value { __u8 value[HV_KVP_EXCHANGE_MAX_VALUE_SIZE]; __u32 value_u32; __u64 value_u64; - }; + } __attribute__((packed)); } __attribute__((packed)); =20 struct hv_kvp_msg_enumerate { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13174381CDB; Sat, 28 Feb 2026 17:36:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300178; cv=none; b=HGIGlMAGYUoVI40RuajkvI5edn16CC/fMY7gQmA9BQU+LXI2a96ePiALiai6ZsD8fv17llXJFGD7eskSB4fVbbuCrT3CxJgDRsZHjkRa9qNGSSMvW+w19bCX7th6cdHkqD6vSLAui0oMD3xxJgliKBfJzX/pI9Jec90YvLy7NW8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300178; c=relaxed/simple; bh=In2dEzgRQhkET1JyDUBYmQbxdy3S2uzNqXaE3eNgILw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ijr5VbehaV26+csiAdp0P3ZGp2On2hUxBmZzKWM1OsN6vzI3hJrTQsMviKFzgTY9yUG+hnvHL0Ituqcz8jtvaP5tENWMEhBDB81pU2BJ6fr29vpMtmjwvmaHXMcZgSIr7M6vZ1ONT7EhszM7bYg0cHJrnSukuBcoDkwQUi1MN+c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bg5Wq9Mq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bg5Wq9Mq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2139C116D0; Sat, 28 Feb 2026 17:36:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300177; bh=In2dEzgRQhkET1JyDUBYmQbxdy3S2uzNqXaE3eNgILw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bg5Wq9Mq5uGv23jbZJuV5d0kgOwejT/i4vJcbNulhdOg3zMr3SREI/oCoK4HihGOk NEYsNHoVAsRLtGxplHzWDQ8lWaVNDMxxEj9DFxUOduyexTc+122fAKVGm4MY/xrdZH pzH0trtVzu/00dzZz6IUb2ZRDAIkztQjxJwqkGogmv7DUwNQF2tSD6Zrm5z1KuhaCO lS/TVTzF+snQB/OVd4sZ2C+R7WBvcjMDFdPB+PTBIuib/LoJLPXj2qDoh2k0Y3ZV6v 35FflYydMxGnnkIO4H99s3vzF7kqpqo+RPh5xaa2nqGf4K4juOY5zIuYsDqdSdGQ9P eNBv18E2+JOXA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , kernel test robot , Nathan Chancellor , Arnd Bergmann , Nicolas Schier , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 196/844] virt: vbox: uapi: Mark inner unions in packed structs as packed Date: Sat, 28 Feb 2026 12:21:49 -0500 Message-ID: <20260228173244.1509663-197-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Thomas Wei=C3=9Fschuh [ Upstream commit c25d01e1c4f2d43f47af87c00e223f5ca7c71792 ] The unpacked unions within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/vbox_vmmdev_types.h:239:4: error: field u within 'struc= t vmmdev_hgcm_function_parameter32' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vm= mdev_types.h:223:2)' and is usually due to 'struct vmmdev_hgcm_function_parameter32' being pac= ked, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 239 | } u; | ^ ./usr/include/linux/vbox_vmmdev_types.h:254:6: error: field u within 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at = ./usr/include/linux/vbox_vmmdev_types.h:249:3)' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vm= mdev_types.h:251:4)' and is usually due to 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at = ./usr/include/linux/vbox_vmmdev_types.h:249:3)' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-a= ccess] With the recent changes to compile-test the UAPI headers in more cases, these warning in combination with CONFIG_WERROR breaks the build. Fix the warnings. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512140314.DzDxpIVn-lkp@int= el.com/ Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-hea= ders-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/linux-kbuild/29b2e736-d462-45b7-a0a9-85f8d8a3= de56@app.fastmail.com/ Signed-off-by: Thomas Wei=C3=9Fschuh Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260115-kbuild-alignment-vbox-v1-2-076aed16= 23ff@linutronix.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/uapi/linux/vbox_vmmdev_types.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/vbox_vmmdev_types.h b/include/uapi/linux/vb= ox_vmmdev_types.h index 6073858d52a2e..11f3627c3729b 100644 --- a/include/uapi/linux/vbox_vmmdev_types.h +++ b/include/uapi/linux/vbox_vmmdev_types.h @@ -236,7 +236,7 @@ struct vmmdev_hgcm_function_parameter32 { /** Relative to the request header. */ __u32 offset; } page_list; - } u; + } __packed u; } __packed; VMMDEV_ASSERT_SIZE(vmmdev_hgcm_function_parameter32, 4 + 8); =20 @@ -251,7 +251,7 @@ struct vmmdev_hgcm_function_parameter64 { union { __u64 phys_addr; __u64 linear_addr; - } u; + } __packed u; } __packed pointer; struct { /** Size of the buffer described by the page list. */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5653C36B5F9; Sat, 28 Feb 2026 17:36:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300179; cv=none; b=VLMsRBTt6qLvD1i47zQiZileDZ3qsizGjsO7Ek2WdF7dy/n3PrFrNbVT95+ciFdEfqmxWIgh05g3wvTNeB6PMw1c2TDYiRo0V81r9rlq5EOgD7j2QL9wrevkE9vCMpPuBX1nC/RQ2HD2q8c0TzI/x8qsz8blPBaKLzKdwA9bMJA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300179; c=relaxed/simple; bh=pT8x8zLiJMqCIFt8/Tq8tXTiE8oYOB5XkIngBKSYPcA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fMC69o6nO+mP6IBVBPQbtQOWaXPxssXwTGgbldgqw+drVCpGdkAdghQeY0WNH66PRbZWj14yoKowepg63OhOnFwpGSiHfNE9x50TaZfvVv1UUFr93AbX4ejntYXFydzrhCDoJaMjvr/LmIUvozXRP79M6eeMg59Z8V+4iSSnVO4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Gf2dLCBY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Gf2dLCBY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 316F6C19423; Sat, 28 Feb 2026 17:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300179; bh=pT8x8zLiJMqCIFt8/Tq8tXTiE8oYOB5XkIngBKSYPcA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Gf2dLCBYZ9x00Ps24hZrNyYiCf9UrZ70a8XXVbCFvZtQ8gdE7YzbFwxhZw4yrJGrq H02YRWGvKq0WTpzHMuw87bP4ta9Rj8G5TkcT25anJ50X03Xk8u1QD1OLrna4ABmqOf eGKHE9qZxFj73vYDW6K5NRsM+Ef1hgxVbJlrOr1tNs998nokaWGfqMbBCjMT6865jJ QyXMdrUXmySz9U2Mqer8oCQ+LB7MFq2bKz14icWBNVkHAmuH/ON4fCPKY5w2CPd4Vl lO/W2vlrp/51lzYPGMHU/TxhAfvhzz+Op40PWsCtUj0aILQnfTJO6KsRYoOxpLekQX TLjXTBefVDcIw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bard Liao , Liam Girdwood , Ranjani Sridharan , Mark Brown , Sasha Levin Subject: [PATCH 6.19 197/844] ASoC: soc-acpi-intel-arl-match: change rt722 amp endpoint to aggregated Date: Sat, 28 Feb 2026 12:21:50 -0500 Message-ID: <20260228173244.1509663-198-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bard Liao [ Upstream commit 08c09899960118ffb01417242e659eb6cc067d6a ] rt722 is aggregated with rt1320 amp in arl_rt722_l0_rt1320_l2 and it is the only audio configuration in the ARL platform. Set .aggregated =3D 1 to represent the fact and avoid unexpected issue. Signed-off-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20260119091749.1752088-2-yung-chuan.liao@lin= ux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../intel/common/soc-acpi-intel-arl-match.c | 23 +++++++++---------- 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/sound/soc/intel/common/soc-acpi-intel-arl-match.c b/sound/soc/= intel/common/soc-acpi-intel-arl-match.c index 6bf7a6250ddc3..c952f7d2b2c0e 100644 --- a/sound/soc/intel/common/soc-acpi-intel-arl-match.c +++ b/sound/soc/intel/common/soc-acpi-intel-arl-match.c @@ -45,23 +45,22 @@ static const struct snd_soc_acpi_endpoint spk_3_endpoin= t =3D { .group_id =3D 1, }; =20 -/* - * RT722 is a multi-function codec, three endpoints are created for - * its headset, amp and dmic functions. - */ -static const struct snd_soc_acpi_endpoint rt722_endpoints[] =3D { +static const struct snd_soc_acpi_endpoint jack_amp_g1_dmic_endpoints[] =3D= { + /* Jack Endpoint */ { .num =3D 0, .aggregated =3D 0, .group_position =3D 0, .group_id =3D 0, }, + /* Amp Endpoint, work as spk_l_endpoint */ { .num =3D 1, - .aggregated =3D 0, + .aggregated =3D 1, .group_position =3D 0, - .group_id =3D 0, + .group_id =3D 1, }, + /* DMIC Endpoint */ { .num =3D 2, .aggregated =3D 0, @@ -229,11 +228,11 @@ static const struct snd_soc_acpi_adr_device rt711_sdc= a_0_adr[] =3D { } }; =20 -static const struct snd_soc_acpi_adr_device rt722_0_single_adr[] =3D { +static const struct snd_soc_acpi_adr_device rt722_0_agg_adr[] =3D { { .adr =3D 0x000030025D072201ull, - .num_endpoints =3D ARRAY_SIZE(rt722_endpoints), - .endpoints =3D rt722_endpoints, + .num_endpoints =3D ARRAY_SIZE(jack_amp_g1_dmic_endpoints), + .endpoints =3D jack_amp_g1_dmic_endpoints, .name_prefix =3D "rt722" } }; @@ -394,8 +393,8 @@ static const struct snd_soc_acpi_link_adr arl_rt711_l0_= rt1316_l3[] =3D { static const struct snd_soc_acpi_link_adr arl_rt722_l0_rt1320_l2[] =3D { { .mask =3D BIT(0), - .num_adr =3D ARRAY_SIZE(rt722_0_single_adr), - .adr_d =3D rt722_0_single_adr, + .num_adr =3D ARRAY_SIZE(rt722_0_agg_adr), + .adr_d =3D rt722_0_agg_adr, }, { .mask =3D BIT(2), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1985236B60B; Sat, 28 Feb 2026 17:36:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300180; cv=none; b=J+HGlSMvIIzvWmHUzByh3G9ZtaJaJRfEj1fR/DcphRPoyeDMOhkBIwefNDBhJ8Q8ZF06GNlnNhVVd0vr6JYjMAxj7xfKd9P+K4BQEA4q0EjmbjNfNomdPi593Sem1FatlrfH+QZdNzqyMzuyY6b1yKYXLcf0OjAqbA8eCB/kwG0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300180; c=relaxed/simple; bh=8LwpH2G/OAuJqAxHNwAbNdqyYAbb/sILHyezwUQKXMA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cpwf7AWEe3JQyo3vU88Up0tG9r6fEi09EZNHDNo+ReJpWWqVJhxne3FjN7oFkrtqpWjoZaoxjrd9YPxh01RhFos+4/p9axCmBpz9Jz36g0EqlxMw4F+78qnsqJVFDjcA2ISe1ROebDRTB6drlUa3OzhXgNMF9a2qoMXY8b99iS8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eCxR/Lsm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eCxR/Lsm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38E7CC116D0; Sat, 28 Feb 2026 17:36:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300180; bh=8LwpH2G/OAuJqAxHNwAbNdqyYAbb/sILHyezwUQKXMA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eCxR/LsmjBEtKIy7kHRncLfyBTv8rN2cWacmfkpF8ME8gWrX9XEaNP2HD2iVwufyw D12FrRExcXwNRuO31vnOfXFkKaExaFkYjVXn6xAAzx98QQ68NUDl1MAiise5oDBNjZ fmPsvcGgkhX0RT9XfTLNzUwsWFjYJMc8OOP9KDU/YNdfijFHPHItbQ1gKMmn1Ff3t2 K+E4pN865vY3MNBsuz9nuIGsOjhC6RI6VCkuXFVNzkXI07JByOLDLd6e+LLIwKJ3PV xwduJZ1win9BSEugc31RGtkFK3Yo7wqq6Lz08BG0/TSRA3Z7PkgxKGQGMf+S0DKevS c1s87QxVyUHIg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bard Liao , Liam Girdwood , Ranjani Sridharan , Mark Brown , Sasha Levin Subject: [PATCH 6.19 198/844] ASoC: soc-acpi-intel-ptl-match: use aggregated endpoint in ptl_rt722_l0_rt1320_l23 Date: Sat, 28 Feb 2026 12:21:51 -0500 Message-ID: <20260228173244.1509663-199-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bard Liao [ Upstream commit 4fbd3b2ec04dc6ef93090ec24733a5c5671fb71f ] The rt722 amp and rt1320 amps are aggregated in this case. Signed-off-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20260119091749.1752088-3-yung-chuan.liao@lin= ux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/intel/common/soc-acpi-intel-ptl-match.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/common/soc-acpi-intel-ptl-match.c b/sound/soc/= intel/common/soc-acpi-intel-ptl-match.c index e297c8ecedb72..1055fb4838f61 100644 --- a/sound/soc/intel/common/soc-acpi-intel-ptl-match.c +++ b/sound/soc/intel/common/soc-acpi-intel-ptl-match.c @@ -383,6 +383,15 @@ static const struct snd_soc_acpi_link_adr ptl_rt721_l3= [] =3D { {}, }; =20 +static const struct snd_soc_acpi_adr_device rt722_0_agg_adr[] =3D { + { + .adr =3D 0x000030025d072201ull, + .num_endpoints =3D ARRAY_SIZE(jack_amp_g1_dmic_endpoints), + .endpoints =3D jack_amp_g1_dmic_endpoints, + .name_prefix =3D "rt722" + } +}; + static const struct snd_soc_acpi_adr_device rt722_0_single_adr[] =3D { { .adr =3D 0x000030025d072201ull, @@ -536,8 +545,8 @@ static const struct snd_soc_acpi_link_adr ptl_rt722_l3[= ] =3D { static const struct snd_soc_acpi_link_adr ptl_rt722_l0_rt1320_l23[] =3D { { .mask =3D BIT(0), - .num_adr =3D ARRAY_SIZE(rt722_0_single_adr), - .adr_d =3D rt722_0_single_adr, + .num_adr =3D ARRAY_SIZE(rt722_0_agg_adr), + .adr_d =3D rt722_0_agg_adr, }, { .mask =3D BIT(2), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 346023824F2; Sat, 28 Feb 2026 17:36:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300181; cv=none; b=EBvbt6q1ar1M1g7zRR+uI9giXFE9kT92CWh3Qc18KUK5HmtW/irETAH7Vtvyve0GoOqgStFm6jf9Mhzzbh6UBKFslsrYlPHh6a1KMEzt8xbyMsQ/O5xLvBHAb/XmnIy24XimT//H0xmuQjtcHvXm+c6V6GDWRijcnGerg8mYu7s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300181; c=relaxed/simple; bh=NVcdXUyZAGeiHyWCwEX/200rlonoP5QqXLbrmsrer9g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ljCIPbvZcFHcPuf/BifDBPbcgxgM17idScSye5rIpMiikfja9UJAWZNk2+H+L74wPxMAaByjFTvtGhwz7LDZFijDU7aB1kUz5ZZaXA+cNe8/m2nRJJz9ODdx+TDyQRu4L3+LfgYdPHwpu7IMjqr5MzlUCmCxKNOg/izKtRm671k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jlGXbYh9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jlGXbYh9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3ED5AC116D0; Sat, 28 Feb 2026 17:36:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300181; bh=NVcdXUyZAGeiHyWCwEX/200rlonoP5QqXLbrmsrer9g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jlGXbYh9smEOfMaTYib3TiS9hqLFqFDUTf5rVHaKc4QbRFCAbF6Ws+egF64OkbTho ymmXu1OEcQg7aTLUSYFOEaICApeDndLQqdtRNjh0om9AOJ0mCHC7mLHb2OP40tCmLk xRYXdUKl7kOMc7FFJY/8pFQ9QErJLIgDLIu9YJ5S5Bc8LZ7UJN97/hUt6Tq83RG8oM 7YnV1rzDAE4BoB+WdwQYMAEfrJMFgDIdkgZ3ZmmB6EGHHVmak/JKnmF5EJ6cw5YJpq nKfIHuoncS7nceb8RtoU5anfbjIF5Am6ThuGpHT2YjzWYSlTUA95COD/U4432zNaD8 EdvqX949WiLEg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bard Liao , =?UTF-8?q?P=C3=A9ter=20Ujfalusi?= , Liam Girdwood , Charles Keepax , Mark Brown , Sasha Levin Subject: [PATCH 6.19 199/844] ASoC: sdw_utils: remove dai registered check Date: Sat, 28 Feb 2026 12:21:52 -0500 Message-ID: <20260228173244.1509663-200-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Bard Liao [ Upstream commit 8d38c275f7ffe257d21bea224d4288eef183817d ] Checking for a registered DAI for non-existing endpoints causes the following error. The driver will always return -EPROBE_DEFER if the codec driver doesn't register the DAI of the unexist endpoint. Signed-off-by: Bard Liao Reviewed-by: P=C3=A9ter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260120065658.1806027-1-yung-chuan.liao@lin= ux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/sdw_utils/soc_sdw_utils.c | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/sound/soc/sdw_utils/soc_sdw_utils.c b/sound/soc/sdw_utils/soc_= sdw_utils.c index ccf149f949e8f..d03072cd13cb9 100644 --- a/sound/soc/sdw_utils/soc_sdw_utils.c +++ b/sound/soc/sdw_utils/soc_sdw_utils.c @@ -1421,29 +1421,14 @@ static int is_sdca_endpoint_present(struct device *= dev, const struct snd_soc_acpi_adr_device *adr_dev =3D &adr_link->adr_d[adr_in= dex]; const struct snd_soc_acpi_endpoint *adr_end; const struct asoc_sdw_dai_info *dai_info; - struct snd_soc_dai_link_component *dlc; - struct snd_soc_dai *codec_dai; struct sdw_slave *slave; struct device *sdw_dev; const char *sdw_codec_name; int ret, i; =20 - dlc =3D kzalloc(sizeof(*dlc), GFP_KERNEL); - if (!dlc) - return -ENOMEM; - adr_end =3D &adr_dev->endpoints[end_index]; dai_info =3D &codec_info->dais[adr_end->num]; =20 - dlc->dai_name =3D dai_info->dai_name; - codec_dai =3D snd_soc_find_dai_with_mutex(dlc); - if (!codec_dai) { - dev_warn(dev, "codec dai %s not registered yet\n", dlc->dai_name); - kfree(dlc); - return -EPROBE_DEFER; - } - kfree(dlc); - sdw_codec_name =3D _asoc_sdw_get_codec_name(dev, adr_link, adr_index); if (!sdw_codec_name) return -ENOMEM; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5A134383C7C; Sat, 28 Feb 2026 17:36:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300182; cv=none; b=Uj5BYcIbziaO8+nTbpKa8EgsWAipia4ZMpFU2v4ODp68pst0KxeOyPcyJr0v5B3yZioXUsRE+6Sygv9gI/YLk/aUtHGkBbNtN3Kw6bM6JkwJ916DLvZ3B4678Oox4W5PKmI4LZaIlIgIV5lw8CbcD/EeUVh87PNpdUorxM7nQRA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300182; c=relaxed/simple; bh=WHUnGgRldfIM6bif1WlpxyyS+cTfMtOobvgccwgeSaE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SiJr/Wo8Q2X3F3PPbHDgWaz5sJHy1Vp9cpjKrVTJyLd4e6d5lBeBm3wIQVhK/gtYuxORjckuNzEz/acW6GEjlDGgqaYqL2ypY9zViMx1nuHYW7Y/XnJSWvUsbutNCNiM6M7sAz6pmfjbpi6zyuOKm+iJjIoAp9A9MSlcVPtCe0k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ur5mcGcD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ur5mcGcD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59BE7C19423; Sat, 28 Feb 2026 17:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300181; bh=WHUnGgRldfIM6bif1WlpxyyS+cTfMtOobvgccwgeSaE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ur5mcGcDH3l28jFg9nCUgTpgGtp13SNz6OUmwk9zg4T4wwfzBwvvon6UnPd2QrxY8 2c7++Ewp7BSixq+2tWje/QDU02jY1yOHfwRFkcg+LXeQHMCD6uDzxWr+jnD7Vdo4Ff QDCKyvD5A51LkD9arMUHWThKspJjX7TA2Vcz1sd9+bLEJpm1n5jP9zrcjLNftRMYbQ 501KOWqwmijruCcpuJQMBd4ZoYDk7IypIk+p2WVQshT9Ci5oWvxx6pfVxEDoJEjUFu pxlpsBB4B+MTxy4m3D+bbVf+LTXtoaDYrHqta5V/GhwIBrIjfkCBXvVF5LchqSEWG3 jFGcNxKEdUCMw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ludovic Desroches , Manikandan Muralidharan , Sasha Levin Subject: [PATCH 6.19 200/844] drm/atmel-hlcdc: destroy properly the plane state in the reset callback Date: Sat, 28 Feb 2026 12:21:53 -0500 Message-ID: <20260228173244.1509663-201-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ludovic Desroches [ Upstream commit 81af99cbd9e4f238011af811d544fff75641fc25 ] If there is a plane state to destroy when doing a plane reset, destroy it using the atmel_hlcdc_plane_destroy_state() function. So we call __drm_atomic_helper_plane_destroy_state() and avoid code duplication. Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251218-lcd_cleanup_mainline-v2-8-df837aba8= 78f@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 52 +++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/= drm/atmel-hlcdc/atmel_hlcdc_plane.c index 92132be9823f1..0ffec44c6d317 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c @@ -1155,32 +1155,6 @@ static int atmel_hlcdc_plane_alloc_dscrs(struct drm_= plane *p, return -ENOMEM; } =20 -static void atmel_hlcdc_plane_reset(struct drm_plane *p) -{ - struct atmel_hlcdc_plane_state *state; - - if (p->state) { - state =3D drm_plane_state_to_atmel_hlcdc_plane_state(p->state); - - if (state->base.fb) - drm_framebuffer_put(state->base.fb); - - kfree(state); - p->state =3D NULL; - } - - state =3D kzalloc(sizeof(*state), GFP_KERNEL); - if (state) { - if (atmel_hlcdc_plane_alloc_dscrs(p, state)) { - kfree(state); - drm_err(p->dev, - "Failed to allocate initial plane state\n"); - return; - } - __drm_atomic_helper_plane_reset(p, &state->base); - } -} - static struct drm_plane_state * atmel_hlcdc_plane_atomic_duplicate_state(struct drm_plane *p) { @@ -1222,6 +1196,32 @@ static void atmel_hlcdc_plane_atomic_destroy_state(s= truct drm_plane *p, kfree(state); } =20 +static void atmel_hlcdc_plane_reset(struct drm_plane *p) +{ + struct atmel_hlcdc_plane_state *state; + struct atmel_hlcdc_dc *dc =3D p->dev->dev_private; + struct atmel_hlcdc_plane *plane =3D drm_plane_to_atmel_hlcdc_plane(p); + + if (p->state) { + atmel_hlcdc_plane_atomic_destroy_state(p, p->state); + p->state =3D NULL; + } + + state =3D kzalloc(sizeof(*state), GFP_KERNEL); + if (state) { + if (atmel_hlcdc_plane_alloc_dscrs(p, state)) { + kfree(state); + drm_err(p->dev, + "Failed to allocate initial plane state\n"); + return; + } + __drm_atomic_helper_plane_reset(p, &state->base); + } + + if (plane->layer.desc->layout.csc) + dc->desc->ops->lcdc_csc_init(plane, plane->layer.desc); +} + static const struct drm_plane_funcs layer_plane_funcs =3D { .update_plane =3D drm_atomic_helper_update_plane, .disable_plane =3D drm_atomic_helper_disable_plane, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53FF5383C96; Sat, 28 Feb 2026 17:36:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300183; cv=none; b=D5fEih1kHp6dknD/BBop9Hs7g8jf5ls9T5tGI6ZyIQJfhHtp+FZ2MG7ZLaeyDMlFq5IHg4+s6OxpT1oRr4Cdxi5lzeM0lARjDotBIiE+COxxf/w8Vf7sN8areXK1BbPi3zRU585gQnormdcFsPFK6qHvhBqezdMrmLcmDu3qlwA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300183; c=relaxed/simple; bh=R+0lSWu62ztSKkqYlqYFLtEriEBU/P90Io6XqdckvK0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sohcdzUwixoBsLnFjHjmtKpOSf2A0tTT6ucW34MeTinySQfQtEXLeko9N4JABxtZ3kkTGKHgZKncdlSdjhA8qRVGF6BsuwyE4+JgyNbNfmcxJhVJOAej+st2ISKtVOjrt093Y7H7KTRl2E3O40+/o0S6oA8uuJjg5Q7IoZh+sg4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Fh+j1ySR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Fh+j1ySR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 364B4C19424; Sat, 28 Feb 2026 17:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300183; bh=R+0lSWu62ztSKkqYlqYFLtEriEBU/P90Io6XqdckvK0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fh+j1ySRqgQL8NH8Or2zeh8jRiyUkEwlgfZwoK/3IBnkMSEgDLvcFcPWMZBmxDCCc hVIcOkmIZtKrUSaGxdO+bh4KLAPngohMs4t0pTHr1AzWsoOgF+UeplOkJNoEoHCb9M aoKi7EHg7Zui5+xCJagZSu1yZKt98Rdav8MbQPedMlxGKNiE0RVnb8P6V+/yW1fXYN tSGE7yk+9MkJtXw4d6iUaHfH9o5iV12GA2SdhypeiYYkutfCeuDTYjbcWuYHBCIpti 2ZrFSHr/7KVS81pqs2T+CE/Mz/3VH7bWoiEjHwm6vaY1mBIgIn3QEk04NhVCOnCcuX T9ZBHq2vaqoPQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Ujfalusi , Kai Vehmanen , Liam Girdwood , Ranjani Sridharan , Bjorn Helgaas , Takashi Iwai , Mark Brown , Sasha Levin Subject: [PATCH 6.19 201/844] PCI: Add Intel Nova Lake audio Device ID Date: Sat, 28 Feb 2026 12:21:54 -0500 Message-ID: <20260228173244.1509663-202-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Ujfalusi [ Upstream commit b190870e0e0cfb375c0d4da02761c32083f3644d ] Add Nova Lake (NVL) audio Device ID The ID will be used by HDA legacy, SOF audio stack and the driver to determine which audio stack should be used (intel-dsp-config). Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Acked-by: Bjorn Helgaas Acked-by: Takashi Iwai Link: https://patch.msgid.link/20260120193507.14019-2-peter.ujfalusi@linux.= intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/pci_ids.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index a9a089566b7cb..f2849ff1830b1 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -3143,6 +3143,7 @@ #define PCI_DEVICE_ID_INTEL_HDA_CML_S 0xa3f0 #define PCI_DEVICE_ID_INTEL_HDA_LNL_P 0xa828 #define PCI_DEVICE_ID_INTEL_S21152BB 0xb152 +#define PCI_DEVICE_ID_INTEL_HDA_NVL 0xd328 #define PCI_DEVICE_ID_INTEL_HDA_BMG 0xe2f7 #define PCI_DEVICE_ID_INTEL_HDA_PTL_H 0xe328 #define PCI_DEVICE_ID_INTEL_HDA_PTL 0xe428 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8428384509; Sat, 28 Feb 2026 17:36:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300184; cv=none; b=tWWavWZ6XDvouHCjVJ6s0VnWU5jvqDLVD1hRWNZ+RdhScmIGXFXZ8AxRAsZl5opNmfM7ccguq5VXejMoWhQtBJDrWPhkCqADKrvVgqv5nFhwNWLWR2lnUklmZlfpyat7I1rIF/RXhuTWbYw3fWIyq1P+MjbZracm69Y4Y9d1mEs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300184; c=relaxed/simple; bh=ToHTk5nEZDEhrHNfiY25UbIkntNkX+d0J0D4kp7GjNg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NoR9/5ZWEo/tDklOwyk3GZ1cBr34xgs5RW6102ynEie8RFGc77jCoMB6l/fVt4jJyBJ27Xjb9SXqies1SHHsMcObVV4fhnvvnw3sN8LN1S5tqFqKabCOvq7gz+YZgqjMqcTmdGLYPGT0ZgwMLVa4FoFIqNMGgj4XlkY8sImFtJE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PuXZyMbX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PuXZyMbX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7AFA5C19424; Sat, 28 Feb 2026 17:36:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300184; bh=ToHTk5nEZDEhrHNfiY25UbIkntNkX+d0J0D4kp7GjNg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PuXZyMbXpnJuTN+3nUWjL8BEqvRiumiUJM2Xl4LJ/FA4BfmvRQKgmWbOkOdKFRxQ9 kozaVEQDmMdw8e6/BqMElM8y24uBq7I7e+2dQ+xmKri+ngxGares/ybh3xr+UAD9AN Q8IN9p+28yrj+QCIAHG9Lq+Akha+LfuvicFtaPbs3jIehHYqd7TVUkyTxN9CzwQS7g Exe3w5QU2v6alDZnSUTkMlxcDnPXzcfvfGOQfs3AdrUH1o+D+drZRJH6mL9xS6Ggvg RaE8qLiQQ83nEWKTpXyPpYUo9Pr6cB4TcOnuAc0FNLnSJmH1a2BZRDJiXxU/5DnAmV O02ZM8zIIhVqw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Ujfalusi , Kai Vehmanen , Liam Girdwood , Ranjani Sridharan , Takashi Iwai , Mark Brown , Sasha Levin Subject: [PATCH 6.19 202/844] ALSA: hda: controllers: intel: add support for Nova Lake Date: Sat, 28 Feb 2026 12:21:55 -0500 Message-ID: <20260228173244.1509663-203-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Ujfalusi [ Upstream commit 7f428282fde34f06f3ab898b8a9081bf93a41f22 ] Add NVL to the PCI-ID list. Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Acked-by: Takashi Iwai Link: https://patch.msgid.link/20260120193507.14019-5-peter.ujfalusi@linux.= intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/hda/controllers/intel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/hda/controllers/intel.c b/sound/hda/controllers/intel.c index 1e8e3d61291a1..1b365e0772970 100644 --- a/sound/hda/controllers/intel.c +++ b/sound/hda/controllers/intel.c @@ -2551,6 +2551,7 @@ static const struct pci_device_id azx_ids[] =3D { /* Wildcat Lake */ { PCI_DEVICE_DATA(INTEL, HDA_WCL, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_LNL) }, /* Nova Lake */ + { PCI_DEVICE_DATA(INTEL, HDA_NVL, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_LNL) }, { PCI_DEVICE_DATA(INTEL, HDA_NVL_S, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_LNL)= }, /* Apollolake (Broxton-P) */ { PCI_DEVICE_DATA(INTEL, HDA_APL, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_BROXTO= N) }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC6D4384520; Sat, 28 Feb 2026 17:36:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300185; cv=none; b=J3eAlEK+pNi/O2hzG39iBkmW4dSPmuiB28Ledpa2T6UumO++3CK8e7PVs3aBx91JK5kH+rlIwW4MIAY4Qn0ThULoym16J7CipeqfYIxOm24FNQ2DQkN05TvQtYjgg9nL9SKYcZanMjrN71NORD1VfhlCi+8sxFOMgO9tydV+KMQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300185; c=relaxed/simple; bh=pUC00dQjKHBTt5nZppW0FFDjlsWQZo9tD2+ybHrc3VU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JRjZFyhVZ+89GWy7SuXtzRsiqZZh8L2UW7JWbHqe6T7N1kVar7IHOX/woUBodr5EE0KDU31NHb6J1WGO0jyf/roxdpDZJk+DLTUBQQ8/cMhTY6ulBKbcp3o9SBg7UpIxaw35jwjkcXyoeH3GyhgEATc1+skUS6b2VtpHkfeI428= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z4i4WcSM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z4i4WcSM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABC63C19423; Sat, 28 Feb 2026 17:36:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300185; bh=pUC00dQjKHBTt5nZppW0FFDjlsWQZo9tD2+ybHrc3VU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z4i4WcSMd1Rsb0XNJlQhRcFbpFGO4g4kZematVi4t9QiK1FDKvD4SwKXB3NP4EEgV Ue69EfDyolqitDRiZBJ2mXKFCK5nSZgOG9R8fl6ufY0dzBCtrgJLTMSKIKjTF602Ux 31tHrLAdi6sQPTAHh05//XC7Aq41izaJmqnEWfObL/ede8P9HfQdlX238oVuNyp/SD KCLzcyj1WrGwsbhWisQKUWV2CQTmWY1tkb/tXoyA3zdNR762tMy66F1ZlIxtOyQ0vs lkSx6dzSuTxZ26wy+l10ThrhupLyISLzY8w/zHA70JtwPKz1j2yGfdJmaCePahCFJs KTLQLaA7zb51g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ovidiu Bunea , Karen Chen , Matthew Stewart , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 203/844] drm/amd/display: Disable FEC when powering down encoders Date: Sat, 28 Feb 2026 12:21:56 -0500 Message-ID: <20260228173244.1509663-204-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ovidiu Bunea [ Upstream commit 8cee62904caf95e5698fa0f2d420f5f22b4dea15 ] [why & how] VBIOS DMCUB FW can enable FEC for capable eDPs, but S/W DC state is only updated for link0 when transitioning into OS with driver loaded. This causes issues when the eDP is immediately hidden and DIG0 is assigned to another link that does not support FEC. Driver will attempt to disable FEC but FEC enablement occurs based on the link state, which does not have fec_state updated since it is a different link. Thus, FEC disablement on DIG0 will get skipped and cause no light up. Reviewed-by: Karen Chen Signed-off-by: Ovidiu Bunea Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../amd/display/dc/hwss/dce110/dce110_hwseq.c | 24 ++++++++++++------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c b/dr= ivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c index 9f7087ac41f21..3d2673a22759a 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c @@ -59,6 +59,7 @@ #include "dc_state_priv.h" #include "dpcd_defs.h" #include "dsc.h" +#include "dc_dp_types.h" /* include DCE11 register header files */ #include "dce/dce_11_0_d.h" #include "dce/dce_11_0_sh_mask.h" @@ -1736,20 +1737,25 @@ static void power_down_encoders(struct dc *dc) int i; =20 for (i =3D 0; i < dc->link_count; i++) { - enum signal_type signal =3D dc->links[i]->connector_signal; - - dc->link_srv->blank_dp_stream(dc->links[i], false); + struct dc_link *link =3D dc->links[i]; + struct link_encoder *link_enc =3D link->link_enc; + enum signal_type signal =3D link->connector_signal; =20 + dc->link_srv->blank_dp_stream(link, false); if (signal !=3D SIGNAL_TYPE_EDP) signal =3D SIGNAL_TYPE_NONE; =20 - if (dc->links[i]->ep_type =3D=3D DISPLAY_ENDPOINT_PHY) - dc->links[i]->link_enc->funcs->disable_output( - dc->links[i]->link_enc, signal); + if (link->ep_type =3D=3D DISPLAY_ENDPOINT_PHY) + link_enc->funcs->disable_output(link_enc, signal); + + if (link->fec_state =3D=3D dc_link_fec_enabled) { + link_enc->funcs->fec_set_enable(link_enc, false); + link_enc->funcs->fec_set_ready(link_enc, false); + link->fec_state =3D dc_link_fec_not_ready; + } =20 - dc->links[i]->link_status.link_active =3D false; - memset(&dc->links[i]->cur_link_settings, 0, - sizeof(dc->links[i]->cur_link_settings)); + link->link_status.link_active =3D false; + memset(&link->cur_link_settings, 0, sizeof(link->cur_link_settings)); } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF1D7384537; Sat, 28 Feb 2026 17:36:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300186; cv=none; b=CKKtCD4n7Liz4Fl8tJBslAUJMeJWTKvvYHZACsk6HvqcyDWJ7ndNiW69600ogOBuTQY4KueovjoCn8nDvAEL7rvxYXZIwqC6pSj7vM3U8cLzixMLZTaqaeJIPxPEIT3pfUM7hmAGo0c3+T2yZ9fcLuocTJn6l5QfBOk75vHFKYE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300186; c=relaxed/simple; bh=gji0AlFxWedMciKFHPpWbLZYurZSn7rxo7+2jgIjW1A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=V+g23Cd1cVax7rYRKLxJk1K05RLjlm/lk/RbljYzAyI394gbr4BQ5J69DCd+kH9AtPheNuTsWfc8m5jqmF1OlDft/p52B0U97UM8EGH6W7q/GxJPwEOAqFTPI1RRe7CstMz9V5sge8rvIROkLdSn1uv0s/ia3rZSGY20mA/s7Bs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nOFXR+pb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nOFXR+pb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9255C19425; Sat, 28 Feb 2026 17:36:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300186; bh=gji0AlFxWedMciKFHPpWbLZYurZSn7rxo7+2jgIjW1A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nOFXR+pbo4IDiFx419d4ZSPbZfXmImwel0D6rFeT0f479jBJ8RlsMmZkhhKlmKr7V w9wxXx01D7g9TklzMALDMybu9IR+Dsg97m8jfMV+wvZYFdgcnFZHpwhkZQK2oAVJew FijtQrL9k02f/E5d6wpAuLyuzkK3QCIv2WYlpo9nr07Tv8TYqJVTjeilkpufes87A+ PiwcP1et2HTsohFPio/6O7LROb9GOwWWFBD+tGxW7viiourDjYub3Y6zNmMOZHVL8c FLmdXkXNGTpom9EWB/F/ZYj9IEy4wXl9TW3QnG/PVg9tlsftez+ET9350LvCMWVbwZ tv02VKDLI+r9A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nicholas Kazlauskas , "Ovidiu (Ovi) Bunea" , Matthew Stewart , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 204/844] drm/amd/display: Ensure link output is disabled in backend reset for PLL_ON Date: Sat, 28 Feb 2026 12:21:57 -0500 Message-ID: <20260228173244.1509663-205-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicholas Kazlauskas [ Upstream commit 4589712e0111352973131bad975023b25569287c ] [Why] We're missing the code to actually disable the link output when we have to leave the SYMCLK_ON but the TX remains OFF. [How] Port the code from DCN401 that detects SYMCLK_ON_TX_OFF and disable the link output when the backend is reset. Reviewed-by: Ovidiu (Ovi) Bunea Signed-off-by: Nicholas Kazlauskas Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c b/driv= ers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c index d1ecdb92b072b..20f700b59847c 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c @@ -546,8 +546,22 @@ static void dcn31_reset_back_end_for_pipe( if (pipe_ctx->stream_res.tg->funcs->set_odm_bypass) pipe_ctx->stream_res.tg->funcs->set_odm_bypass( pipe_ctx->stream_res.tg, &pipe_ctx->stream->timing); + /* + * TODO - convert symclk_ref_cnts for otg to a bit map to solve + * the case where the same symclk is shared across multiple otg + * instances + */ if (dc_is_hdmi_tmds_signal(pipe_ctx->stream->signal)) - pipe_ctx->stream->link->phy_state.symclk_ref_cnts.otg =3D 0; + link->phy_state.symclk_ref_cnts.otg =3D 0; + + if (pipe_ctx->top_pipe =3D=3D NULL) { + if (link->phy_state.symclk_state =3D=3D SYMCLK_ON_TX_OFF) { + const struct link_hwss *link_hwss =3D get_link_hwss(link, &pipe_ctx->li= nk_res); + + link_hwss->disable_link_output(link, &pipe_ctx->link_res, pipe_ctx->str= eam->signal); + link->phy_state.symclk_state =3D SYMCLK_OFF_TX_OFF; + } + } =20 set_drr_and_clear_adjust_pending(pipe_ctx, pipe_ctx->stream, NULL); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCAFF384D07; Sat, 28 Feb 2026 17:36:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300187; cv=none; b=hsCqLH/XaCGaoZC9AWQjWWA1CPD1F2UVhhW++Skv24urOMOF/VYPQOEDnTvfg7lcT/X7Sp8DKaybX+UF26oZqMdKaj62KwB91I74w2NAJRX5JDyP3F6pggLXNLzQV4KdeX9u63pYrVq2LCvGExtrPV0cEq30Xgys9N0EVuoCado= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300187; c=relaxed/simple; bh=XjtacgL7/bhtfQ8qS/l8MkMaUtIex8CljF574lMvNRc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mnEuFOAE9Bs+FifQ2sBSmxyUFfIEvN5p+nNbQR6e49PnFq9f+z/GM0/+vJsC/TQv5dOtuE3ub6TIQGyF3feBws6Jeuheo/johg5w2KSvqoE45Qp9gImb43nQTaa6+BcA107grFVn6f/CUeBc1cXn+0N29CkrbNfImtMgrQ+Oi20= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pA321doH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pA321doH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7203C19424; Sat, 28 Feb 2026 17:36:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300187; bh=XjtacgL7/bhtfQ8qS/l8MkMaUtIex8CljF574lMvNRc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pA321doHhCnrbzsgB0Fdp4pXCM5ESdV090qabh6pujw4jySH4jbJaS1ISd/CjkgpL 4hURXiOhMeDTHWXiwPsBf8VR6QSzxs08ZjIiPcjIjT3sdqynljgGMNRiujt1JbuJKK qflO6VSsV6YJcJqK3p14pU3D2YcCq0R02ZMixUag8dfRBXLAsBlrM7gohRVv/+6LE1 v4LQox7DRKuu0KF/JXxremQBH+GUDBcN3USJMZtfjhZCsNB/3w7kNP8yR0pvNOe7VA nH285StkbnTVdwjVdjbigwry6lPrRlHRIaNdXJWavk6N2BJhmZDKG/gFFWQ1j9xh4H lpEQEFryXPG4Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Wang, Sung-huai" , Nicholas Kazlauskas , Matthew Stewart , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 205/844] drm/amd/display: Revert "init dispclk from bootup clock for DCN314" Date: Sat, 28 Feb 2026 12:21:58 -0500 Message-ID: <20260228173244.1509663-206-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Wang, Sung-huai" [ Upstream commit bdc26342c49e1dc1afb48feeb20c9d74d15b784c ] [Why&How] This reverts commit f082daf08f2f. Due to the change, the display shows garbage on startup. We have an alternative solution for the original issue: d24203bb629f ("drm/amd/display: Re-check seamless boot can be enabled or no= t") Reviewed-by: Nicholas Kazlauskas Signed-off-by: Wang, Sung-huai Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../dc/clk_mgr/dcn314/dcn314_clk_mgr.c | 133 +----------------- .../dc/clk_mgr/dcn314/dcn314_clk_mgr.h | 5 - 2 files changed, 4 insertions(+), 134 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c= b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c index db687a13174d5..0cb37827a62b6 100644 --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c @@ -77,7 +77,6 @@ static const struct IP_BASE CLK_BASE =3D { { { { 0x00016C= 00, 0x02401800, 0, 0, 0, #undef DC_LOGGER #define DC_LOGGER \ clk_mgr->base.base.ctx->logger - #define regCLK1_CLK_PLL_REQ 0x0237 #define regCLK1_CLK_PLL_REQ_BASE_IDX 0 =20 @@ -88,70 +87,8 @@ static const struct IP_BASE CLK_BASE =3D { { { { 0x00016= C00, 0x02401800, 0, 0, 0, #define CLK1_CLK_PLL_REQ__PllSpineDiv_MASK 0x0000F000L #define CLK1_CLK_PLL_REQ__FbMult_frac_MASK 0xFFFF0000L =20 -#define regCLK1_CLK0_DFS_CNTL 0x0269 -#define regCLK1_CLK0_DFS_CNTL_BASE_IDX 0 -#define regCLK1_CLK1_DFS_CNTL 0x026c -#define regCLK1_CLK1_DFS_CNTL_BASE_IDX 0 -#define regCLK1_CLK2_DFS_CNTL 0x026f -#define regCLK1_CLK2_DFS_CNTL_BASE_IDX 0 -#define regCLK1_CLK3_DFS_CNTL 0x0272 -#define regCLK1_CLK3_DFS_CNTL_BASE_IDX 0 -#define regCLK1_CLK4_DFS_CNTL 0x0275 -#define regCLK1_CLK4_DFS_CNTL_BASE_IDX 0 -#define regCLK1_CLK5_DFS_CNTL 0x0278 -#define regCLK1_CLK5_DFS_CNTL_BASE_IDX 0 - -#define regCLK1_CLK0_CURRENT_CNT 0x02fb -#define regCLK1_CLK0_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK1_CURRENT_CNT 0x02fc -#define regCLK1_CLK1_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK2_CURRENT_CNT 0x02fd -#define regCLK1_CLK2_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK3_CURRENT_CNT 0x02fe -#define regCLK1_CLK3_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK4_CURRENT_CNT 0x02ff -#define regCLK1_CLK4_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK5_CURRENT_CNT 0x0300 -#define regCLK1_CLK5_CURRENT_CNT_BASE_IDX 0 - -#define regCLK1_CLK0_BYPASS_CNTL 0x028a -#define regCLK1_CLK0_BYPASS_CNTL_BASE_IDX 0 -#define regCLK1_CLK1_BYPASS_CNTL 0x0293 -#define regCLK1_CLK1_BYPASS_CNTL_BASE_IDX 0 #define regCLK1_CLK2_BYPASS_CNTL 0x029c #define regCLK1_CLK2_BYPASS_CNTL_BASE_IDX 0 -#define regCLK1_CLK3_BYPASS_CNTL 0x02a5 -#define regCLK1_CLK3_BYPASS_CNTL_BASE_IDX 0 -#define regCLK1_CLK4_BYPASS_CNTL 0x02ae -#define regCLK1_CLK4_BYPASS_CNTL_BASE_IDX 0 -#define regCLK1_CLK5_BYPASS_CNTL 0x02b7 -#define regCLK1_CLK5_BYPASS_CNTL_BASE_IDX 0 - -#define regCLK1_CLK0_DS_CNTL 0x0283 -#define regCLK1_CLK0_DS_CNTL_BASE_IDX 0 -#define regCLK1_CLK1_DS_CNTL 0x028c -#define regCLK1_CLK1_DS_CNTL_BASE_IDX 0 -#define regCLK1_CLK2_DS_CNTL 0x0295 -#define regCLK1_CLK2_DS_CNTL_BASE_IDX 0 -#define regCLK1_CLK3_DS_CNTL 0x029e -#define regCLK1_CLK3_DS_CNTL_BASE_IDX 0 -#define regCLK1_CLK4_DS_CNTL 0x02a7 -#define regCLK1_CLK4_DS_CNTL_BASE_IDX 0 -#define regCLK1_CLK5_DS_CNTL 0x02b0 -#define regCLK1_CLK5_DS_CNTL_BASE_IDX 0 - -#define regCLK1_CLK0_ALLOW_DS 0x0284 -#define regCLK1_CLK0_ALLOW_DS_BASE_IDX 0 -#define regCLK1_CLK1_ALLOW_DS 0x028d -#define regCLK1_CLK1_ALLOW_DS_BASE_IDX 0 -#define regCLK1_CLK2_ALLOW_DS 0x0296 -#define regCLK1_CLK2_ALLOW_DS_BASE_IDX 0 -#define regCLK1_CLK3_ALLOW_DS 0x029f -#define regCLK1_CLK3_ALLOW_DS_BASE_IDX 0 -#define regCLK1_CLK4_ALLOW_DS 0x02a8 -#define regCLK1_CLK4_ALLOW_DS_BASE_IDX 0 -#define regCLK1_CLK5_ALLOW_DS 0x02b1 -#define regCLK1_CLK5_ALLOW_DS_BASE_IDX 0 =20 #define CLK1_CLK2_BYPASS_CNTL__CLK2_BYPASS_SEL__SHIFT 0x0 #define CLK1_CLK2_BYPASS_CNTL__CLK2_BYPASS_DIV__SHIFT 0x10 @@ -248,8 +185,6 @@ void dcn314_init_clocks(struct clk_mgr *clk_mgr) { struct clk_mgr_internal *clk_mgr_int =3D TO_CLK_MGR_INTERNAL(clk_mgr); uint32_t ref_dtbclk =3D clk_mgr->clks.ref_dtbclk_khz; - struct clk_mgr_dcn314 *clk_mgr_dcn314 =3D TO_CLK_MGR_DCN314(clk_mgr_int); - struct clk_log_info log_info =3D {0}; =20 memset(&(clk_mgr->clks), 0, sizeof(struct dc_clocks)); // Assumption is that boot state always supports pstate @@ -265,9 +200,6 @@ void dcn314_init_clocks(struct clk_mgr *clk_mgr) dce_adjust_dp_ref_freq_for_ss(clk_mgr_int, clk_mgr->dprefclk_khz); else clk_mgr->dp_dto_source_clock_in_khz =3D clk_mgr->dprefclk_khz; - - dcn314_dump_clk_registers(&clk_mgr->boot_snapshot, &clk_mgr_dcn314->base.= base, &log_info); - clk_mgr->clks.dispclk_khz =3D clk_mgr->boot_snapshot.dispclk * 1000; } =20 void dcn314_update_clocks(struct clk_mgr *clk_mgr_base, @@ -278,7 +210,7 @@ void dcn314_update_clocks(struct clk_mgr *clk_mgr_base, struct clk_mgr_internal *clk_mgr =3D TO_CLK_MGR_INTERNAL(clk_mgr_base); struct dc_clocks *new_clocks =3D &context->bw_ctx.bw.dcn.clk; struct dc *dc =3D clk_mgr_base->ctx->dc; - int display_count; + int display_count =3D 0; bool update_dppclk =3D false; bool update_dispclk =3D false; bool dpp_clock_lowered =3D false; @@ -287,7 +219,6 @@ void dcn314_update_clocks(struct clk_mgr *clk_mgr_base, return; =20 display_count =3D dcn314_get_active_display_cnt_wa(dc, context); - /* * if it is safe to lower, but we are already in the lower state, we don'= t have to do anything * also if safe to lower is false, we just go in the higher state @@ -363,7 +294,7 @@ void dcn314_update_clocks(struct clk_mgr *clk_mgr_base, } =20 if (should_set_clock(safe_to_lower, new_clocks->dispclk_khz, clk_mgr_base= ->clks.dispclk_khz) && - (new_clocks->dispclk_khz > 0 || (safe_to_lower && display_count =3D= =3D 0))) { + (new_clocks->dispclk_khz > 0 || (safe_to_lower && display_count =3D=3D 0= ))) { int requested_dispclk_khz =3D new_clocks->dispclk_khz; =20 dcn314_disable_otg_wa(clk_mgr_base, context, safe_to_lower, true); @@ -374,7 +305,6 @@ void dcn314_update_clocks(struct clk_mgr *clk_mgr_base, =20 dcn314_smu_set_dispclk(clk_mgr, requested_dispclk_khz); clk_mgr_base->clks.dispclk_khz =3D new_clocks->dispclk_khz; - dcn314_disable_otg_wa(clk_mgr_base, context, safe_to_lower, false); =20 update_dispclk =3D true; @@ -462,65 +392,10 @@ bool dcn314_are_clock_states_equal(struct dc_clocks *= a, return true; } =20 - -static void dcn314_dump_clk_registers_internal(struct dcn35_clk_internal *= internal, struct clk_mgr *clk_mgr_base) -{ - struct clk_mgr_internal *clk_mgr =3D TO_CLK_MGR_INTERNAL(clk_mgr_base); - - // read dtbclk - internal->CLK1_CLK4_CURRENT_CNT =3D REG_READ(CLK1_CLK4_CURRENT_CNT); - internal->CLK1_CLK4_BYPASS_CNTL =3D REG_READ(CLK1_CLK4_BYPASS_CNTL); - - // read dcfclk - internal->CLK1_CLK3_CURRENT_CNT =3D REG_READ(CLK1_CLK3_CURRENT_CNT); - internal->CLK1_CLK3_BYPASS_CNTL =3D REG_READ(CLK1_CLK3_BYPASS_CNTL); - - // read dcf deep sleep divider - internal->CLK1_CLK3_DS_CNTL =3D REG_READ(CLK1_CLK3_DS_CNTL); - internal->CLK1_CLK3_ALLOW_DS =3D REG_READ(CLK1_CLK3_ALLOW_DS); - - // read dppclk - internal->CLK1_CLK1_CURRENT_CNT =3D REG_READ(CLK1_CLK1_CURRENT_CNT); - internal->CLK1_CLK1_BYPASS_CNTL =3D REG_READ(CLK1_CLK1_BYPASS_CNTL); - - // read dprefclk - internal->CLK1_CLK2_CURRENT_CNT =3D REG_READ(CLK1_CLK2_CURRENT_CNT); - internal->CLK1_CLK2_BYPASS_CNTL =3D REG_READ(CLK1_CLK2_BYPASS_CNTL); - - // read dispclk - internal->CLK1_CLK0_CURRENT_CNT =3D REG_READ(CLK1_CLK0_CURRENT_CNT); - internal->CLK1_CLK0_BYPASS_CNTL =3D REG_READ(CLK1_CLK0_BYPASS_CNTL); -} - -void dcn314_dump_clk_registers(struct clk_state_registers_and_bypass *regs= _and_bypass, +static void dcn314_dump_clk_registers(struct clk_state_registers_and_bypas= s *regs_and_bypass, struct clk_mgr *clk_mgr_base, struct clk_log_info *log_info) { - - struct dcn35_clk_internal internal =3D {0}; - - dcn314_dump_clk_registers_internal(&internal, clk_mgr_base); - - regs_and_bypass->dcfclk =3D internal.CLK1_CLK3_CURRENT_CNT / 10; - regs_and_bypass->dcf_deep_sleep_divider =3D internal.CLK1_CLK3_DS_CNTL / = 10; - regs_and_bypass->dcf_deep_sleep_allow =3D internal.CLK1_CLK3_ALLOW_DS; - regs_and_bypass->dprefclk =3D internal.CLK1_CLK2_CURRENT_CNT / 10; - regs_and_bypass->dispclk =3D internal.CLK1_CLK0_CURRENT_CNT / 10; - regs_and_bypass->dppclk =3D internal.CLK1_CLK1_CURRENT_CNT / 10; - regs_and_bypass->dtbclk =3D internal.CLK1_CLK4_CURRENT_CNT / 10; - - regs_and_bypass->dppclk_bypass =3D internal.CLK1_CLK1_BYPASS_CNTL & 0x000= 7; - if (regs_and_bypass->dppclk_bypass > 4) - regs_and_bypass->dppclk_bypass =3D 0; - regs_and_bypass->dcfclk_bypass =3D internal.CLK1_CLK3_BYPASS_CNTL & 0x000= 7; - if (regs_and_bypass->dcfclk_bypass > 4) - regs_and_bypass->dcfclk_bypass =3D 0; - regs_and_bypass->dispclk_bypass =3D internal.CLK1_CLK0_BYPASS_CNTL & 0x00= 07; - if (regs_and_bypass->dispclk_bypass > 4) - regs_and_bypass->dispclk_bypass =3D 0; - regs_and_bypass->dprefclk_bypass =3D internal.CLK1_CLK2_BYPASS_CNTL & 0x0= 007; - if (regs_and_bypass->dprefclk_bypass > 4) - regs_and_bypass->dprefclk_bypass =3D 0; - + return; } =20 static struct clk_bw_params dcn314_bw_params =3D { diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.h= b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.h index 0577eb527bc36..002c28e807208 100644 --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.h +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.h @@ -65,9 +65,4 @@ void dcn314_clk_mgr_construct(struct dc_context *ctx, =20 void dcn314_clk_mgr_destroy(struct clk_mgr_internal *clk_mgr_int); =20 - -void dcn314_dump_clk_registers(struct clk_state_registers_and_bypass *regs= _and_bypass, - struct clk_mgr *clk_mgr_base, struct clk_log_info *log_info); - - #endif //__DCN314_CLK_MGR_H__ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B729D384D1C; Sat, 28 Feb 2026 17:36:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300188; cv=none; b=n8AS/fLJDuAwQ7yjPJTo9JwaZmEpC1w3Z/WmULDvso2fGEsd5wXlTDyiomApYkGq2ZpFBzUVpWYfBGGxCgriRxgO6bMlOZdsv5idea3fmBOMtk1R67lbkJZolmsLHhyODQPueHrPfgIVp2k2it6V7ltmgQxi+86oSf/2FuaXncw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300188; c=relaxed/simple; bh=d/KTjjlDxSA0FL17SjDeVXUNReYvuVcoOwSy9+Uuh8c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=j055OGp7JvBkeOfJa69tdQVEcUA0F8CMy/F/+2vilcspQYJXZWWO+7Lo3ToBuQLOY6r8j8rF+QqXJy7mw6yx/L86N/z7mzXGuRFzMEoCak6b9Y1fpWxg8T+FUI1S7r2QER4lvvyhHUVzWlQQ/w8+s/2RLPd6fQq6YFJ++N0QFa8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dDRJ6WhH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dDRJ6WhH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0FCE2C19423; Sat, 28 Feb 2026 17:36:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300188; bh=d/KTjjlDxSA0FL17SjDeVXUNReYvuVcoOwSy9+Uuh8c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dDRJ6WhH6oRwWmxd99LcWJTlL5gz4xObjImlPVfipO4ppwY9ji4p7B7BE/E1xAdXq wFSIwmqnvJVIKBaPTwLj/gAfhTgYplYwrd41AFOJqOlb63htCMn91Ea9jQcM2Xw2vT qjSjnPAcJ9KxEbi+iasmDI5Bz/GINozVM+1YGbHvIYbTbVaeLjJ55ZxsBBh4oamZAz NQs2qRgrqOY6RNOXHs36Rz2n7pPhFxePR+S6toFKeiZQzTi6N814FQ0YqRGR0neCr3 QNBS+8Ic+2btFzzkOR90uSbsfjgZlLrz82hh0MGv0i8rfJd+WtyOLIZbEDt0aMzvcM LrayEztp2Im2g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ludovic Desroches , Manikandan Muralidharan , Sasha Levin Subject: [PATCH 6.19 206/844] drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback Date: Sat, 28 Feb 2026 12:21:59 -0500 Message-ID: <20260228173244.1509663-207-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ludovic Desroches [ Upstream commit f12352471061df83a36edf54bbb16284793284e4 ] After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm "egt_basic", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-1-79b615130= dc3@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/= drm/atmel-hlcdc/atmel_hlcdc_plane.c index 0ffec44c6d317..c0075894dc422 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c @@ -1190,8 +1190,7 @@ static void atmel_hlcdc_plane_atomic_destroy_state(st= ruct drm_plane *p, state->dscrs[i]->self); } =20 - if (s->fb) - drm_framebuffer_put(s->fb); + __drm_atomic_helper_plane_destroy_state(s); =20 kfree(state); } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9100E384D34; Sat, 28 Feb 2026 17:36:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300189; cv=none; b=l8JOE5n3Sx9DuYKFOVyZyU3FYkyl1LO8ZXES5kY9/v9yp9nliz6cHtN5hWjsV7Hwd1d29td9X1fXEAyLPGAghhPu16rIz0K9AHCLVfJjD45ZYZVvNWEHH5DtoR5tePyqMpo1JJoY/4DyzTfmlXuWhXDrN42tZbtjDWK1Quxp3YE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300189; c=relaxed/simple; bh=CtX7F1+uI6Vv4EUT1MpP0djRM3AlH1CCr5sbpgeLqKY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aAEWffqLHNSqXNqJas0CbETGT/5GAMTnFd3Qq1/ldQeKRwJ8V8KKkfvnZHP5/z1FxC8YrXswkUv9bW8KcGOxsv1DNXtjMCbyDLVutQnpMVe6gDx6PlYD5MAVSTOImcUBloHrhYlRUIWJuHTTYGcxP/rGE1qbtB8oTFGGD48Ushc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DF9B2e+9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DF9B2e+9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DFA7EC19423; Sat, 28 Feb 2026 17:36:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300189; bh=CtX7F1+uI6Vv4EUT1MpP0djRM3AlH1CCr5sbpgeLqKY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DF9B2e+9GA63cInla/HmKiWQYPIc2lOQKYdILNlnC/RNIBJPEqol6OdvXvQiaX1Su WdOYqTzvlC+DvBRqfTj7MaoMk/vKR1wregCbdqxrzLuNnfq2G06W24/RqaZhCAtECg IFLyc+rbN6lKFrGSvotbqcXB19cNrdy7uiURe+x4YVwEmXb+J+nW5dIz/OcW5fRpfD D6i7KemiNPIsH+96ZeHmVCLRPZyFD2X/NQTaCZLA9t9/nVMlBktHPbGe/0ge64hV/X x3ER13km0FgTuLm45vdDuzI0y39ZvUEiVxtJeBFwnuxcD4eYyW2bHzfJyu0zHuSbrH itl5bza7EBjdg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ludovic Desroches , Manikandan Muralidharan , Sasha Levin Subject: [PATCH 6.19 207/844] drm/atmel-hlcdc: don't reject the commit if the src rect has fractional parts Date: Sat, 28 Feb 2026 12:22:00 -0500 Message-ID: <20260228173244.1509663-208-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ludovic Desroches [ Upstream commit 06682206e2a1883354ed758c09efeb51f435adbd ] Don=E2=80=99t reject the commit when the source rectangle has fractional pa= rts. This can occur due to scaling: drm_atomic_helper_check_plane_state() calls drm_rect_clip_scaled(), which may introduce fractional parts while computing the clipped source rectangle. This does not imply the commit is invalid, so we should accept it instead of discarding it. Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251120-lcd_scaling_fix-v1-1-5ffc98557923@m= icrochip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/= drm/atmel-hlcdc/atmel_hlcdc_plane.c index c0075894dc422..ec1fb5f9549a2 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c @@ -79,8 +79,6 @@ drm_plane_state_to_atmel_hlcdc_plane_state(struct drm_pla= ne_state *s) return container_of(s, struct atmel_hlcdc_plane_state, base); } =20 -#define SUBPIXEL_MASK 0xffff - static uint32_t rgb_formats[] =3D { DRM_FORMAT_C8, DRM_FORMAT_XRGB4444, @@ -745,24 +743,15 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_= plane *p, if (ret || !s->visible) return ret; =20 - hstate->src_x =3D s->src.x1; - hstate->src_y =3D s->src.y1; - hstate->src_w =3D drm_rect_width(&s->src); - hstate->src_h =3D drm_rect_height(&s->src); + hstate->src_x =3D s->src.x1 >> 16; + hstate->src_y =3D s->src.y1 >> 16; + hstate->src_w =3D drm_rect_width(&s->src) >> 16; + hstate->src_h =3D drm_rect_height(&s->src) >> 16; hstate->crtc_x =3D s->dst.x1; hstate->crtc_y =3D s->dst.y1; hstate->crtc_w =3D drm_rect_width(&s->dst); hstate->crtc_h =3D drm_rect_height(&s->dst); =20 - if ((hstate->src_x | hstate->src_y | hstate->src_w | hstate->src_h) & - SUBPIXEL_MASK) - return -EINVAL; - - hstate->src_x >>=3D 16; - hstate->src_y >>=3D 16; - hstate->src_w >>=3D 16; - hstate->src_h >>=3D 16; - hstate->nplanes =3D fb->format->num_planes; if (hstate->nplanes > ATMEL_HLCDC_LAYER_MAX_PLANES) return -EINVAL; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D4E647DF8D; Sat, 28 Feb 2026 17:36:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300190; cv=none; b=jalxt6Umym0qeFGVGAR9L/EEWfDWyKXjDQS9gQGxFlzb7UmmEEw/YInjhhwkhAdypIRWq8rNyBsWI6YMRP6DTnYX2cRqCD9ucZvtV4JCaSoAIZqquLCxNl1pZtawJKV+u8rjixXYXUQQCAG+yCw33jt/XNy1eJsvF+QwQZcyBjs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300190; c=relaxed/simple; bh=izAzawfvB3pkXRT8YBMZCsjJaDUIZ/broNuKGcM473A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eSv4t3gnFlMw3Glw0lOD+hNFtCA+CqlEnin7HEFk+GY1Sui7nUmADGz6+uqO5YRDHKpISPT/bDNEkWZ8+3D9zkpWn0y9NmyeS7+Taao4U7sGjlcY3QvBhPJJLukFlaC2xVu5NIC060ZYsqICDj79VneJ870s/iAfIrjDq75cQ+U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kmcQCwOg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kmcQCwOg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9BCEC19423; Sat, 28 Feb 2026 17:36:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300190; bh=izAzawfvB3pkXRT8YBMZCsjJaDUIZ/broNuKGcM473A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kmcQCwOgjnUhkILpQywAbYG5Y+bwZPiaDceWVIbUWxEjxypPclFgzPxiu2udzoTYM ICtx2jFpAWkZXhAWl/iOk5zXVlhExqc/vKcSnrLYcrHvWhndzAb0plp3JS9HFUG1GA ViG22tYo4BGkT7ESga28CzwD3LHmPDN5ZUR2+J/iw4n8ue4vJ69u4PEed+Ljdt9iG9 L5Fg09dOBwFmdRu2inMLAqFlkgVTKF+psN0L2Hedwp4g+FaROKHRIqcdYGYZoNhHSp 3W7IhSvLv5L7L5B9RO4a2vDmjF1PxRQSWjt4ZEWnYsMrpeTwvGm3HhfOzLDpcQH0Mm lDPCB01f4KljA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ludovic Desroches , Manikandan Muralidharan , Sasha Levin Subject: [PATCH 6.19 208/844] drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release Date: Sat, 28 Feb 2026 12:22:01 -0500 Message-ID: <20260228173244.1509663-209-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ludovic Desroches [ Upstream commit bc847787233277a337788568e90a6ee1557595eb ] The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D BUG kmalloc-64 (Not tainted): Poison overwritten Reviewed-by: Manikandan Muralidharan Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara ---------------------------------------------------------------------------= -- 0xc611b344-0xc611b344 @offset=3D836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=3D0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=3D178 cpu=3D0 pid=3D29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=3D8 cpu=3D0 pid=3D169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=3D21 used=3D16 fp=3D0xc611b7c0 flags=3D0x200(workingset|zone=3D0) Object 0xc611b340 @offset=3D832 fp=3D0xc611b7c0 Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-2-79b615130= dc3@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/= drm/atmel-hlcdc/atmel_hlcdc_plane.c index ec1fb5f9549a2..e55e88d44e829 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c @@ -1160,8 +1160,7 @@ atmel_hlcdc_plane_atomic_duplicate_state(struct drm_p= lane *p) return NULL; } =20 - if (copy->base.fb) - drm_framebuffer_get(copy->base.fb); + __drm_atomic_helper_plane_duplicate_state(p, ©->base); =20 return ©->base; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 873FE386560; Sat, 28 Feb 2026 17:36:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300191; cv=none; b=Bfds5kR+tH2cq3ie0EU8+CgyomhmEosJforHb4IlvHjWLa4YjgepPuMgAlcoljWIebHvKQGJTiOmQ2sI7mgNSMID6X/EjVzyBdBFWcD6bpJg70yMk8ny/koVrSV/jOn20ovHHMtQGdluNAQkLaI3zIX3XawxS/pz6tkMRFfdcqM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300191; c=relaxed/simple; bh=GloLR+sZqazsOEMcwKjjsr0557JMWt8dkvyqSApCE9E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mKR2rA5jJFohgNS0mJaQbIFmu0FAl9darJrjBGC/zuLhdRLfYtf9lRFlgNSt7HvUuJ5xtyOYFMcdn7RB5qNALoIxUT5No3/Gd8KBzBfxEcoK9heXaRn3BVyDPca09G4oTEsOvWBa57mixQFd3Ltv4nyZspGXo91z7PrV1E/mF84= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RtdBTjAC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RtdBTjAC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9567BC2BC9E; Sat, 28 Feb 2026 17:36:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300191; bh=GloLR+sZqazsOEMcwKjjsr0557JMWt8dkvyqSApCE9E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RtdBTjACa/yFaXq/ju7AXSSRnYTKRNH+SNtM7zBIjVLMiVtbswf54hkk7lW7k5dvN l3do1peelqnl5fJrzf+p6sws8jEPN1HE7GWSpUoriADlC3ss5N9p2nq7Je4mEkshbC 7HgXdaw8/i69Qz7YsPOKz3UqUaspBDHhsFyd5w9lQsl5wotto+XN4ktfbZWJnr9mIR rOfiQg6Rq802UlN3oXmZ6vdBaj3NIsRPyv8cQZ0j6AikkwYSUkFAxHG4ewlU08kqr4 sZfzdMnxIT+ngwh2OuUF1eHc+A6gH3KQl7NkMPVay4vXVZflk4tK0kT/Z+IP+goLSt QH7FaJYzf+pLw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Rui Wang , Stefan Klug , Kieran Bingham , Laurent Pinchart , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 209/844] media: rkisp1: Fix filter mode register configuration Date: Sat, 28 Feb 2026 12:22:02 -0500 Message-ID: <20260228173244.1509663-210-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Rui Wang [ Upstream commit 5a50f2b61104d0d351b59ec179f67abab7870453 ] The rkisp1_flt_config() function performs an initial direct write to RKISP1_CIF_ISP_FILT_MODE without including the RKISP1_CIF_ISP_FLT_ENA bit, which clears the filter enable bit in the hardware. The subsequent read/modify/write sequence then reads back the register with the enable bit already cleared and cannot restore it, resulting in the filter being inadvertently disabled. Remove the redundant direct write. The read/modify/write sequence alone correctly preserves the existing enable bit state while updating the DNR mode and filter configuration bits. Signed-off-by: Rui Wang Reviewed-by: Stefan Klug Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260105171142.147792-2-rui.wang@ideasonboar= d.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/rockchip/rkisp1/rkisp1-params.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c b/drive= rs/media/platform/rockchip/rkisp1/rkisp1-params.c index c9f88635224cc..6442436a5e428 100644 --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c @@ -411,12 +411,6 @@ static void rkisp1_flt_config(struct rkisp1_params *pa= rams, rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_FILT_LUM_WEIGHT, arg->lum_weight); =20 - rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_FILT_MODE, - (arg->mode ? RKISP1_CIF_ISP_FLT_MODE_DNR : 0) | - RKISP1_CIF_ISP_FLT_CHROMA_V_MODE(arg->chr_v_mode) | - RKISP1_CIF_ISP_FLT_CHROMA_H_MODE(arg->chr_h_mode) | - RKISP1_CIF_ISP_FLT_GREEN_STAGE1(arg->grn_stage1)); - /* avoid to override the old enable value */ filt_mode =3D rkisp1_read(params->rkisp1, RKISP1_CIF_ISP_FILT_MODE); filt_mode &=3D RKISP1_CIF_ISP_FLT_ENA; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A4B2E384D1C; Sat, 28 Feb 2026 17:36:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300192; cv=none; b=bHQsdBXrUY8OAXqkZBn6Sno9Ip7xdkS+s43RB8aTp/OlQdNjo4bwhqx796EA3rQtdMue/fTdAjVo0EAAu+9sxSCPx/fKhFWAqp8SnX+hmaj2zRqAE/srMZAqvZFAmpgBIBXavxFxPI3lp+IyDuigooazHgRAswnKq2ylFB0nPd4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300192; c=relaxed/simple; bh=SP0u9Gsg4UblRpuMOu/Nb84B3XBOm4YoFltNxiA2j6A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JT9PuxveP4SsAy4aIap92YKRAN9Vmf6wvXIS47JffQp2G64OUcckF9B3FAf6Hxo9Amyt8KBmWYkVnKbNQlQKDTDdjccM4w3XYA/ukFirdyfB//2MP2j5Kwfz1XcGPk8yp0SM3V/x8qiSL9o9M5vAPkUPGjPSxZns+Jb5V40R3So= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iiMBySA/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iiMBySA/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE2E4C116D0; Sat, 28 Feb 2026 17:36:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300192; bh=SP0u9Gsg4UblRpuMOu/Nb84B3XBOm4YoFltNxiA2j6A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iiMBySA/y876JsZiza7sloLJTmSVtgQ/eAzX3JcLMBa2jlTsqCEQ5R9ZNpOp/WEue 4wQ07NXdBNIQgR2ucq7Jgru47XwVm654mNdxH4J29wGawix8zS6ERpBcVwA1Q9pCTz yE4NbWiX6Um06ylOWojQQyS5Wa+imR3VfcP/NY66B/wAs/zfX83PkAo6l/Vwef1uuW 31+6c+DEe8NJ/uTT3egCJTS4qZ2jo7ltJ8kQ6zqWfuaSnIPvOEaHBng/u1oPl45KeG xga9ERIZ5wNjl3KdjbFk2lWOkYriyulkiy1/OsR8FPAs6jvm3yAG8STcArFfVGpsgO xGbyXHRd2y8fg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Wang, Sung-huai" , Nicholas Kazlauskas , Matthew Stewart , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 210/844] drm/amd/display: Revert "init dispclk from bootup clock for DCN315" Date: Sat, 28 Feb 2026 12:22:03 -0500 Message-ID: <20260228173244.1509663-211-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Wang, Sung-huai" [ Upstream commit a625dc4989a2affb8f06e7b418bf30e1474b99c1 ] [Why&How] This reverts commit 14bb17cc37e0. Due to the change, the display shows garbage on startup. We have an alternative solution for the original issue: d24203bb629f ("drm/amd/display: Re-check seamless boot can be enabled or no= t") Reviewed-by: Nicholas Kazlauskas Signed-off-by: Wang, Sung-huai Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 90 +------------------ .../dc/clk_mgr/dcn315/dcn315_clk_mgr.h | 1 - 2 files changed, 3 insertions(+), 88 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c= b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c index 3a881451e9da4..c49268db85f68 100644 --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c @@ -40,7 +40,7 @@ #include "dm_helpers.h" =20 #include "dc_dmub_srv.h" -#include "reg_helper.h" + #include "logger_types.h" #undef DC_LOGGER #define DC_LOGGER \ @@ -48,43 +48,9 @@ =20 #include "link_service.h" =20 -#define MAX_INSTANCE 7 -#define MAX_SEGMENT 8 - -struct IP_BASE_INSTANCE { - unsigned int segment[MAX_SEGMENT]; -}; - -struct IP_BASE { - struct IP_BASE_INSTANCE instance[MAX_INSTANCE]; -}; - -static const struct IP_BASE CLK_BASE =3D { { { { 0x00016C00, 0x02401800, 0= , 0, 0, 0, 0, 0 } }, - { { 0x00016E00, 0x02401C00, 0, 0, 0, 0, 0, 0 } }, - { { 0x00017000, 0x02402000, 0, 0, 0, 0, 0, 0 } }, - { { 0x00017200, 0x02402400, 0, 0, 0, 0, 0, 0 } }, - { { 0x0001B000, 0x0242D800, 0, 0, 0, 0, 0, 0 } }, - { { 0x0001B200, 0x0242DC00, 0, 0, 0, 0, 0, 0 } } } }; - -#define regCLK1_CLK0_CURRENT_CNT 0x0314 -#define regCLK1_CLK0_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK1_CURRENT_CNT 0x0315 -#define regCLK1_CLK1_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK2_CURRENT_CNT 0x0316 -#define regCLK1_CLK2_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK3_CURRENT_CNT 0x0317 -#define regCLK1_CLK3_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK4_CURRENT_CNT 0x0318 -#define regCLK1_CLK4_CURRENT_CNT_BASE_IDX 0 -#define regCLK1_CLK5_CURRENT_CNT 0x0319 -#define regCLK1_CLK5_CURRENT_CNT_BASE_IDX 0 - #define TO_CLK_MGR_DCN315(clk_mgr)\ container_of(clk_mgr, struct clk_mgr_dcn315, base) =20 -#define REG(reg_name) \ - (CLK_BASE.instance[0].segment[reg ## reg_name ## _BASE_IDX] + reg ## reg_= name) - #define UNSUPPORTED_DCFCLK 10000000 #define MIN_DPP_DISP_CLK 100000 =20 @@ -172,7 +138,7 @@ static void dcn315_update_clocks(struct clk_mgr *clk_mg= r_base, if (dc->work_arounds.skip_clock_update) return; =20 - clk_mgr_base->clks.zstate_support =3D new_clocks->zstate_support; + display_count =3D dcn315_get_active_display_cnt_wa(dc, context); /* * if it is safe to lower, but we are already in the lower state, we don'= t have to do anything * also if safe to lower is false, we just go in the higher state @@ -185,7 +151,6 @@ static void dcn315_update_clocks(struct clk_mgr *clk_mg= r_base, } /* check that we're not already in lower */ if (clk_mgr_base->clks.pwr_state !=3D DCN_PWR_STATE_LOW_POWER) { - display_count =3D dcn315_get_active_display_cnt_wa(dc, context); /* if we can go lower, go lower */ if (display_count =3D=3D 0) { union display_idle_optimization_u idle_info =3D { 0 }; @@ -279,38 +244,9 @@ static void dcn315_update_clocks(struct clk_mgr *clk_m= gr_base, dc_wake_and_execute_dmub_cmd(dc->ctx, &cmd, DM_DMUB_WAIT_TYPE_WAIT); } =20 -static void dcn315_dump_clk_registers_internal(struct dcn35_clk_internal *= internal, struct clk_mgr *clk_mgr_base) -{ - struct clk_mgr_internal *clk_mgr =3D TO_CLK_MGR_INTERNAL(clk_mgr_base); - - // read dtbclk - internal->CLK1_CLK4_CURRENT_CNT =3D REG_READ(CLK1_CLK4_CURRENT_CNT); - - // read dcfclk - internal->CLK1_CLK3_CURRENT_CNT =3D REG_READ(CLK1_CLK3_CURRENT_CNT); - - // read dppclk - internal->CLK1_CLK1_CURRENT_CNT =3D REG_READ(CLK1_CLK1_CURRENT_CNT); - - // read dprefclk - internal->CLK1_CLK2_CURRENT_CNT =3D REG_READ(CLK1_CLK2_CURRENT_CNT); - - // read dispclk - internal->CLK1_CLK0_CURRENT_CNT =3D REG_READ(CLK1_CLK0_CURRENT_CNT); -} - static void dcn315_dump_clk_registers(struct clk_state_registers_and_bypas= s *regs_and_bypass, struct clk_mgr *clk_mgr_base, struct clk_log_info *log_info) { - struct dcn35_clk_internal internal =3D {0}; - - dcn315_dump_clk_registers_internal(&internal, clk_mgr_base); - - regs_and_bypass->dcfclk =3D internal.CLK1_CLK3_CURRENT_CNT / 10; - regs_and_bypass->dprefclk =3D internal.CLK1_CLK2_CURRENT_CNT / 10; - regs_and_bypass->dispclk =3D internal.CLK1_CLK0_CURRENT_CNT / 10; - regs_and_bypass->dppclk =3D internal.CLK1_CLK1_CURRENT_CNT / 10; - regs_and_bypass->dtbclk =3D internal.CLK1_CLK4_CURRENT_CNT / 10; return; } =20 @@ -657,32 +593,13 @@ static struct clk_mgr_funcs dcn315_funcs =3D { .get_dp_ref_clk_frequency =3D dce12_get_dp_ref_freq_khz, .get_dtb_ref_clk_frequency =3D dcn31_get_dtb_ref_freq_khz, .update_clocks =3D dcn315_update_clocks, - .init_clocks =3D dcn315_init_clocks, + .init_clocks =3D dcn31_init_clocks, .enable_pme_wa =3D dcn315_enable_pme_wa, .are_clock_states_equal =3D dcn31_are_clock_states_equal, .notify_wm_ranges =3D dcn315_notify_wm_ranges }; extern struct clk_mgr_funcs dcn3_fpga_funcs; =20 -void dcn315_init_clocks(struct clk_mgr *clk_mgr) -{ - struct clk_mgr_internal *clk_mgr_int =3D TO_CLK_MGR_INTERNAL(clk_mgr); - uint32_t ref_dtbclk =3D clk_mgr->clks.ref_dtbclk_khz; - struct clk_mgr_dcn315 *clk_mgr_dcn315 =3D TO_CLK_MGR_DCN315(clk_mgr_int); - struct clk_log_info log_info =3D {0}; - - memset(&(clk_mgr->clks), 0, sizeof(struct dc_clocks)); - // Assumption is that boot state always supports pstate - clk_mgr->clks.ref_dtbclk_khz =3D ref_dtbclk; // restore ref_dtbclk - clk_mgr->clks.p_state_change_support =3D true; - clk_mgr->clks.prev_p_state_change_support =3D true; - clk_mgr->clks.pwr_state =3D DCN_PWR_STATE_UNKNOWN; - clk_mgr->clks.zstate_support =3D DCN_ZSTATE_SUPPORT_UNKNOWN; - - dcn315_dump_clk_registers(&clk_mgr->boot_snapshot, &clk_mgr_dcn315->base.= base, &log_info); - clk_mgr->clks.dispclk_khz =3D clk_mgr->boot_snapshot.dispclk * 1000; -} - void dcn315_clk_mgr_construct( struct dc_context *ctx, struct clk_mgr_dcn315 *clk_mgr, @@ -743,7 +660,6 @@ void dcn315_clk_mgr_construct( /* Saved clocks configured at boot for debug purposes */ dcn315_dump_clk_registers(&clk_mgr->base.base.boot_snapshot, &clk_mgr->base.base, &log_info); - clk_mgr->base.base.clks.dispclk_khz =3D clk_mgr->base.base.boot_snapshot= .dispclk * 1000; =20 clk_mgr->base.base.dprefclk_khz =3D 600000; clk_mgr->base.base.dprefclk_khz =3D dcn315_smu_get_dpref_clk(&clk_mgr->ba= se); diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.h= b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.h index 642ae3d4a7909..ac36ddf5dd1af 100644 --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.h +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.h @@ -44,7 +44,6 @@ void dcn315_clk_mgr_construct(struct dc_context *ctx, struct pp_smu_funcs *pp_smu, struct dccg *dccg); =20 -void dcn315_init_clocks(struct clk_mgr *clk_mgr); void dcn315_clk_mgr_destroy(struct clk_mgr_internal *clk_mgr_int); =20 #endif //__DCN315_CLK_MGR_H__ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93277386EA3; Sat, 28 Feb 2026 17:36:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300193; cv=none; b=QwFFhaeFNassxPm6qRve21WSExnJuMYL4jDOF1YbU4N6LdMIQ4MJFN5oiuWKqRzRrgI7fWOS4OXESzU2ZM4FLXdzkefOs534sYNxcOi8CyH8KTCC3YY1lcbKXSPpnl2otnnJRJNqa3FrYa2yj/CRKD2DVOMmA7uqLf/MtyEZMm4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300193; c=relaxed/simple; bh=CMEbP+rdVxf9RR+AzjzYLeY+N4AES/ai99H2uz96kp0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=R6SSxMOquBjAxsxxtlUnNSSKkxHoB8h1AID4ZWRnJors3Et7IctrHr7ZCF+Sq1i7cdaCT1Szsd7672QR8Bmicv898HPfvMcfkHww9mVzl2v+2GjukyWW/3iO11GHyXXPHWdoOEWfhjwiFY4PLWcPXYlUfihKlv4kpmDwfuhZZw8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=L0hEPSo1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="L0hEPSo1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CAF31C19423; Sat, 28 Feb 2026 17:36:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300193; bh=CMEbP+rdVxf9RR+AzjzYLeY+N4AES/ai99H2uz96kp0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=L0hEPSo1v0lry+qNE7B/CDlZw8egP8TmCqVWT23XUJTSs++l6CK2qUHtY8XbLoB+4 fMytYHvX4yb4Ci9cZDczBM2/b9+Z67Lforg/uWAZkuK+SBCsrlFBIxqEec1wTCW/PO A7Q8gy7NpEHaYZjF5P+9Q9Gj5UvIIUJwA+Gq6VWrfTDFrGCm+ouhJRCHLh5HM9gnDU V227uk7qnPELrIbA1qSg6b0ftjWx766l766OM9RPKI6LiWU41MaoI3klKzLmRrYLIj QJTGoGKxCznzl3Ic6Plo44Y2OT1ykfFzXmGxQQa+oE27mVGjofFqLMdbAAQxs/NDvg xJLuu0YUwHgDQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gangliang Xie , Tao Zhou , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 211/844] drm/amdgpu: mark invalid records with U64_MAX Date: Sat, 28 Feb 2026 12:22:04 -0500 Message-ID: <20260228173244.1509663-212-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gangliang Xie [ Upstream commit 0028b86b52f7609e36af635ef6cb908925306233 ] set retired_page of invalid ras records to U64_MAX, and skip them when reading ras records Signed-off-by: Gangliang Xie Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/= amdgpu/amdgpu_ras.c index 6b069dc4bab06..ee4d08b0988d3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -2777,6 +2777,10 @@ static int amdgpu_ras_badpages_read(struct amdgpu_de= vice *adev, if (!data->bps[i].ts) continue; =20 + /* U64_MAX is used to mark the record as invalid */ + if (data->bps[i].retired_page =3D=3D U64_MAX) + continue; + bps[r].bp =3D data->bps[i].retired_page; r++; if (r >=3D count) @@ -3083,6 +3087,8 @@ static int __amdgpu_ras_restore_bad_pages(struct amdg= pu_device *adev, =20 if (amdgpu_ras_check_bad_page_unlock(con, bps[j].retired_page << AMDGPU_GPU_PAGE_SHIFT)) { + /* set to U64_MAX to mark it as invalid */ + data->bps[data->count].retired_page =3D U64_MAX; data->count++; data->space_left--; continue; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF6F2386EC6; Sat, 28 Feb 2026 17:36:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300194; cv=none; b=RD193UhHonhYj0H1I4U25lHjcHyhpfCYSjI6Dq3EXZxCUyJ6/FgTRkr8z1mX6wVraxc2uJ5tYRgRkCqK5cyQzH5ixbTvohF/9h9po+oIiJCHkJ5eynZn27ZXbvvXwkGgmSnnJkFiil5fLZUfM/ObEZc9zgd0d1yqCZ0xbGYtqMM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300194; c=relaxed/simple; bh=N17G3sxYWFycVNeydnt5jj9kJK1CfhUB6xGvl3w60Io=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H5Eh5UIiH64xHeJAJ+qjxHfiUQ0BtxsqCCccSvPl6eq1KdndnS8a0SALpWkwS8JKsle1dpQzH0Rt3CAp2sAZQMmKq1611v9EUz0dUU/4Lq0sHxAopHbwPXlS4xQ0M+czC5H4w+V/5jEFLhP9j6c5/yaNz1q/ZvUdfPo7BPzrS1k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XPzD1gCi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XPzD1gCi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B81C2C116D0; Sat, 28 Feb 2026 17:36:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300194; bh=N17G3sxYWFycVNeydnt5jj9kJK1CfhUB6xGvl3w60Io=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XPzD1gCiUPgO/+DEhv6tLAI6WQfNjUW5Rrj7YX3IpJAJZoUtTZROQcwD8ZWnvDjGN KB2b7rA5zyuxUbNSENjs4ZYlx9308N8cZsBMiPdAecAoCEUBj+cr8w2Snik6OySfU6 Zp61LS1zMmdcAdItjxbApXJpttug1ECkosmybs7aVPEThbPoprzdjrFX5qP3q1KNpy CshebIGZ2+Eq/NKnx+lGkpZJQ4+KzMJuJAL/LXv906oRvmJNacRz/43qmm8uzUi5Q3 jfRVlA8inNTeNtThRIAKpEQPEMWpXZx/m8fbKD4jSt1yTTiMIpDL3p/PNgGLpCgOuY is70FzFOU7Byw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thorsten Schmelzer , Michael Tretter , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 212/844] HID: multitouch: add eGalaxTouch EXC3188 support Date: Sat, 28 Feb 2026 12:22:05 -0500 Message-ID: <20260228173244.1509663-213-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thorsten Schmelzer [ Upstream commit 8e4ac86b2ddd36fe501e20ecfcc080e536df1f48 ] Add support for the for the EXC3188 touchscreen from eGalaxy. Signed-off-by: Thorsten Schmelzer Signed-off-by: Michael Tretter Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-multitouch.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 5a18cb41e6d79..6d8b64872cefe 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -437,6 +437,7 @@ #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_7349 0x7349 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_73F7 0x73f7 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001 0xa001 +#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C000 0xc000 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002 0xc002 =20 #define USB_VENDOR_ID_EDIFIER 0x2d99 diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index f21850f7d89e4..7daa8f6d81870 100644 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -2212,6 +2212,9 @@ static const struct hid_device_id mt_devices[] =3D { { .driver_data =3D MT_CLS_EGALAX_SERIAL, MT_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001) }, + { .driver_data =3D MT_CLS_EGALAX_SERIAL, + MT_USB_DEVICE(USB_VENDOR_ID_DWAV, + USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C000) }, { .driver_data =3D MT_CLS_EGALAX, MT_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002) }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84647386560; Sat, 28 Feb 2026 17:36:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300195; cv=none; b=gSCZ77qwhvRHQvrYrpQdjtMNUkIoMm/56iiLk1DwSAcx4psFvCgKYLVHE7FWsyQBFj+QCPndv0oNC9JskRpoOWES4V9UvKY1N13ZXRjSw316ZX8oSIDJJt/aEey85E4M4OSXEOvE3mXLgFNIPlt24x9DCmXbbY1zzPyDBIqDgVY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300195; c=relaxed/simple; bh=jITFQ1PQ11OQ6l1VM/aZkKEbbySKJs4wjKHSH7MykMo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OSBmgrYGzWKQLfF+yWAPAjEgsqKUYPbHynsWkyNzKCt49BPLsu+FkWWwqBSC1bpDpEZ6BbpYiHXdpUEhZEcly8GvN9uOhEhKmPlSvmkvUg7shp28jIyp6cor8Qf6itADTI9rfs+cX5B4sPNCEOyZXQYp8dl7fqPbsidc7p0eh3s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=udm5+xxE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="udm5+xxE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4969C19425; Sat, 28 Feb 2026 17:36:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300195; bh=jITFQ1PQ11OQ6l1VM/aZkKEbbySKJs4wjKHSH7MykMo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=udm5+xxEzxAUNgGx5JnX3An93+AEqEV4qRrW22jhrFdqBg/ypsGbftjMYvk/vaLff W1LLs0YZU1bQbXM0i4vAvADixO8jNpFi7jMqCDcDjy2bTL/vFcvBGZhvDfmhH0+Rk2 A/tvmeEzQYfaxT3MBqbjwh3YSQV7gqTL6CgE8IWUhifRunfKgs7bcskTl2yPQDnfXW GO/fDqZ5bOXJpQWBp5GiqZWIUwLgGJcgfFgQ/xsPCfGuUWnNW/Po9iv5aVHec/XFEr TDU+xpAc6/7TZOVkjEEzxFqnlrGwvleRABq+2e7XWB7M7gVRI03sVbDacIabLLmf31 wmtlaz8Y7yLSg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ricardo Ribalda , Laurent Pinchart , Lili Orosz , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 213/844] media: uvcvideo: Create an ID namespace for streaming output terminals Date: Sat, 28 Feb 2026 12:22:06 -0500 Message-ID: <20260228173244.1509663-214-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ricardo Ribalda [ Upstream commit 3d9f32e02c2ed85338be627de672e2b81b88a836 ] Some devices, such as the Grandstream GUV3100 and the LSK Meeting Eye for Business & Home, exhibit entity ID collisions between units and streaming output terminals. The UVC specification requires unit and terminal IDs to be unique, and uses the ID to reference entities: - In control requests, to identify the target entity - In the UVC units and terminals descriptors' bSourceID field, to identify source entities - In the UVC input header descriptor's bTerminalLink, to identify the terminal associated with a streaming interface Entity ID collisions break accessing controls and make the graph description in the UVC descriptors ambiguous. However, collisions where one of the entities is a streaming output terminal and the other entity is not a streaming terminal are less severe. Streaming output terminals have no controls, and, as they are the final entity in pipelines, they are never referenced in descriptors as source entities. They are referenced by ID only from innput header descriptors, which by definition only reference streaming terminals. For these reasons, we can work around the collision by giving streaming output terminals their own ID namespace. Do so by setting bit UVC_TERM_OUTPUT (15) in the uvc_entity.id field, which is normally never set as the ID is a 8-bit value. This ID change doesn't affect the entity name in the media controller graph as the name isn't constructed from the ID, so there should not be any impact on the uAPI. Although this change handles some ID collisions automagically, keep printing an error in uvc_alloc_new_entity() when a camera has invalid descriptors. Hopefully this message will help vendors fix their invalid descriptors. This new method of handling ID collisions includes a revert of commit 758dbc756aad ("media: uvcvideo: Use heuristic to find stream entity") that attempted to fix the problem urgently due to regression reports. Suggested-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Tested-by: Lili Orosz Co-developed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Link: https://patch.msgid.link/20251113210400.28618-1-laurent.pinchart@idea= sonboard.com Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/usb/uvc/uvc_driver.c | 54 ++++++++++++++++++------------ drivers/media/usb/uvc/uvcvideo.h | 3 +- 2 files changed, 35 insertions(+), 22 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc= _driver.c index ee4f54d683496..aa3e8d295e0f5 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -165,28 +165,17 @@ static struct uvc_entity *uvc_entity_by_reference(str= uct uvc_device *dev, return NULL; } =20 -static struct uvc_streaming *uvc_stream_by_id(struct uvc_device *dev, int = id) +static struct uvc_streaming *uvc_stream_for_terminal(struct uvc_device *de= v, + struct uvc_entity *term) { - struct uvc_streaming *stream, *last_stream; - unsigned int count =3D 0; + u16 id =3D UVC_HARDWARE_ENTITY_ID(term->id); + struct uvc_streaming *stream; =20 list_for_each_entry(stream, &dev->streams, list) { - count +=3D 1; - last_stream =3D stream; if (stream->header.bTerminalLink =3D=3D id) return stream; } =20 - /* - * If the streaming entity is referenced by an invalid ID, notify the - * user and use heuristics to guess the correct entity. - */ - if (count =3D=3D 1 && id =3D=3D UVC_INVALID_ENTITY_ID) { - dev_warn(&dev->intf->dev, - "UVC non compliance: Invalid USB header. The streaming entity has an i= nvalid ID, guessing the correct one."); - return last_stream; - } - return NULL; } =20 @@ -823,10 +812,12 @@ static struct uvc_entity *uvc_alloc_new_entity(struct= uvc_device *dev, u16 type, } =20 /* Per UVC 1.1+ spec 3.7.2, the ID is unique. */ - if (uvc_entity_by_id(dev, id)) { - dev_err(&dev->intf->dev, "Found multiple Units with ID %u\n", id); + if (uvc_entity_by_id(dev, UVC_HARDWARE_ENTITY_ID(id))) + dev_err(&dev->intf->dev, "Found multiple Units with ID %u\n", + UVC_HARDWARE_ENTITY_ID(id)); + + if (uvc_entity_by_id(dev, id)) id =3D UVC_INVALID_ENTITY_ID; - } =20 extra_size =3D roundup(extra_size, sizeof(*entity->pads)); if (num_pads) @@ -982,6 +973,7 @@ static int uvc_parse_standard_control(struct uvc_device= *dev, struct usb_host_interface *alts =3D dev->intf->cur_altsetting; unsigned int i, n, p, len; const char *type_name; + unsigned int id; u16 type; =20 switch (buffer[2]) { @@ -1120,8 +1112,28 @@ static int uvc_parse_standard_control(struct uvc_dev= ice *dev, return 0; } =20 + id =3D buffer[3]; + + /* + * Some devices, such as the Grandstream GUV3100, exhibit entity + * ID collisions between units and streaming output terminals. + * Move streaming output terminals to their own ID namespace by + * setting bit UVC_TERM_OUTPUT (15), above the ID's 8-bit value. + * The bit is ignored in uvc_stream_for_terminal() when looking + * up the streaming interface for the terminal. + * + * This hack is safe to enable unconditionally, as the ID is not + * used for any other purpose (streaming output terminals have + * no controls and are never referenced as sources in UVC + * descriptors). Other types output terminals can have controls, + * so limit usage of this separate namespace to streaming output + * terminals. + */ + if (type & UVC_TT_STREAMING) + id |=3D UVC_TERM_OUTPUT; + term =3D uvc_alloc_new_entity(dev, type | UVC_TERM_OUTPUT, - buffer[3], 1, 0); + id, 1, 0); if (IS_ERR(term)) return PTR_ERR(term); =20 @@ -2118,8 +2130,8 @@ static int uvc_register_terms(struct uvc_device *dev, if (UVC_ENTITY_TYPE(term) !=3D UVC_TT_STREAMING) continue; =20 - stream =3D uvc_stream_by_id(dev, term->id); - if (stream =3D=3D NULL) { + stream =3D uvc_stream_for_terminal(dev, term); + if (!stream) { dev_info(&dev->intf->dev, "No streaming interface found for terminal %u.", term->id); diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvi= deo.h index ed7bad31f75ca..3f2e832025e71 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -41,7 +41,8 @@ #define UVC_EXT_GPIO_UNIT 0x7ffe #define UVC_EXT_GPIO_UNIT_ID 0x100 =20 -#define UVC_INVALID_ENTITY_ID 0xffff +#define UVC_HARDWARE_ENTITY_ID(id) ((id) & 0xff) +#define UVC_INVALID_ENTITY_ID 0xffff =20 /* ------------------------------------------------------------------------ * Driver specific constants. --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F8033884AE; Sat, 28 Feb 2026 17:36:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300196; cv=none; b=vEe4N9guw/WRL96DloUJHwJZCG3rsYjTHvUPcnLRTEGC3FCVXymbcmWNMq2btKoB8sWCKLVDmu49aNs5CriwtV5aehMOgrCE9Y6Q4rmQ/KEOWx3X5s4WBwNy8WhrYwUKljS3F/kSbTjPhSDGR4zubcYR8w3klIxOCbPChiPsUkU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300196; c=relaxed/simple; bh=+3H8IVt5HZVV5uP2/2MSq726bFeBnOx18rf5R01kdFM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sXbE30End1welI0Ohqn3UJFh8YfTBXiuJFFUs8dqotXYSYlXnryHjcAnG54U9SnvMIbMEf1S7GIdZHFQ1cSaOLbYA3sC9PYTRqZCKTyNyf34ASPbhZSV8QaazxXf/GbXft7XHUpHBQ6tLyCZ73Qxwga1wjWxkFTvWsrJfkTUVu0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=icfm2Pxx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="icfm2Pxx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA8CEC19423; Sat, 28 Feb 2026 17:36:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300196; bh=+3H8IVt5HZVV5uP2/2MSq726bFeBnOx18rf5R01kdFM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=icfm2PxxE9EHdXpT0wm0GSjgySdSIUTAgO3F8z/eY7OWAtt2HQG/kATnZg08/lokQ YoCuQyIXmCodMi15dkL/aaaTRSb1i6SYsHTOfIIiHs7vmjTpG1Qe5mYftr5EQugILN Afbfb1F4gOttop3jnGH7nQl/OpkUBypfBT0Y9htlzkIDfNzPIOgxLp5DvbGQnr2WLk dS3E+F80V7I9Fk1dSIr1QGZtbgPE590EGtQq1t10hxirWX6IyFU3t+SLo9MD5LKra1 +U6QaDvXcc2Ha2ImoxAm38O0tXhUaxMuLhdIsple32/fB4Cy8lTACtO+FAjntXlGPo t9uPa6efeZQ3Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Phillips , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 214/844] HID: elecom: Add support for ELECOM HUGE Plus M-HT1MRBK Date: Sat, 28 Feb 2026 12:22:07 -0500 Message-ID: <20260228173244.1509663-215-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Phillips [ Upstream commit b8e5fdf0bd022cd5493a5987ef66f5a24f8352d8 ] New model in the ELECOM HUGE trackball line that has 8 buttons but the report descriptor specifies only 5. The HUGE Plus supports connecting via Bluetooth, 2.4GHz wireless USB dongle, and directly via a USB-C cable. Each connection type reports a different device id, 01AA for cable, 01AB for USB dongle, and 01AC for Bluetooth. This patch adds these device IDs and applies the fixups similar to the other ELECOM devices to get all 8 buttons working for all 3 connection types. For reference, the usbhid-dump output: 001:013:001:DESCRIPTOR 1769085639.598405 05 01 09 02 A1 01 85 01 09 01 A1 00 05 09 19 01 29 05 15 00 25 01 75 01 95 05 81 02 75 03 95 01 81 01 05 01 09 30 09 31 16 01 80 26 FF 7F 75 10 95 02 81 06 09 38 15 81 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 81 25 7F 75 08 95 01 81 06 C0 C0 05 0C 09 01 A1 01 85 02 15 01 26 8C 02 19 01 2A 8C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85 03 09 82 09 81 09 83 15 00 25 01 19 01 29 03 75 01 95 03 81 02 95 05 81 01 C0 06 01 FF 09 00 A1 01 85 08 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0 06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00 75 08 95 07 B1 02 C0 Signed-off-by: David Phillips Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/Kconfig | 1 + drivers/hid/hid-elecom.c | 16 ++++++++++++++++ drivers/hid/hid-ids.h | 3 +++ drivers/hid/hid-quirks.c | 3 +++ 4 files changed, 23 insertions(+) diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 920a64b66b25b..6ff4a3ad34cbf 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -369,6 +369,7 @@ config HID_ELECOM - EX-G Trackballs (M-XT3DRBK, M-XT3URBK) - DEFT Trackballs (M-DT1DRBK, M-DT1URBK, M-DT2DRBK, M-DT2URBK) - HUGE Trackballs (M-HT1DRBK, M-HT1URBK) + - HUGE Plus Trackball (M-HT1MRBK) =20 config HID_ELO tristate "ELO USB 4000/4500 touchscreen" diff --git a/drivers/hid/hid-elecom.c b/drivers/hid/hid-elecom.c index 2003d2dcda7cc..37d88ce57f671 100644 --- a/drivers/hid/hid-elecom.c +++ b/drivers/hid/hid-elecom.c @@ -5,6 +5,7 @@ * - EX-G Trackballs (M-XT3DRBK, M-XT3URBK, M-XT4DRBK) * - DEFT Trackballs (M-DT1DRBK, M-DT1URBK, M-DT2DRBK, M-DT2URBK) * - HUGE Trackballs (M-HT1DRBK, M-HT1URBK) + * - HUGE Plus Trackball (M-HT1MRBK) * * Copyright (c) 2010 Richard Nauber * Copyright (c) 2016 Yuxuan Shui @@ -123,12 +124,25 @@ static const __u8 *elecom_report_fixup(struct hid_dev= ice *hdev, __u8 *rdesc, */ mouse_button_fixup(hdev, rdesc, *rsize, 22, 30, 24, 16, 8); break; + case USB_DEVICE_ID_ELECOM_M_HT1MRBK: + case USB_DEVICE_ID_ELECOM_M_HT1MRBK_01AB: + case USB_DEVICE_ID_ELECOM_M_HT1MRBK_01AC: + /* + * Report descriptor format: + * 24: button bit count + * 28: padding bit count + * 22: button report size + * 16: button usage maximum + */ + mouse_button_fixup(hdev, rdesc, *rsize, 24, 28, 22, 16, 8); + break; } return rdesc; } =20 static const struct hid_device_id elecom_devices[] =3D { { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_BM084) = }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1MR= BK_01AC) }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XGL20DLBK) = }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_00F= B) }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_018= F) }, @@ -142,6 +156,8 @@ static const struct hid_device_id elecom_devices[] =3D { { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1URBK_019= B) }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK_010= D) }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK_011= C) }, + { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1MRBK) }, + { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1MRBK_01A= B) }, { } }; MODULE_DEVICE_TABLE(hid, elecom_devices); diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 6d8b64872cefe..85ab1ac511096 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -466,6 +466,9 @@ #define USB_DEVICE_ID_ELECOM_M_HT1URBK_019B 0x019b #define USB_DEVICE_ID_ELECOM_M_HT1DRBK_010D 0x010d #define USB_DEVICE_ID_ELECOM_M_HT1DRBK_011C 0x011c +#define USB_DEVICE_ID_ELECOM_M_HT1MRBK 0x01aa +#define USB_DEVICE_ID_ELECOM_M_HT1MRBK_01AB 0x01ab +#define USB_DEVICE_ID_ELECOM_M_HT1MRBK_01AC 0x01ac =20 #define USB_VENDOR_ID_DREAM_CHEEKY 0x1d34 #define USB_DEVICE_ID_DREAM_CHEEKY_WN 0x0004 diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c index 11438039cdb7f..3217e436c052c 100644 --- a/drivers/hid/hid-quirks.c +++ b/drivers/hid/hid-quirks.c @@ -420,6 +420,7 @@ static const struct hid_device_id hid_have_special_driv= er[] =3D { #if IS_ENABLED(CONFIG_HID_ELECOM) { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_BM084) = }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XGL20= DLBK) }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1MR= BK_01AC) }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_00F= B) }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_018= F) }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_00F= C) }, @@ -432,6 +433,8 @@ static const struct hid_device_id hid_have_special_driv= er[] =3D { { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1URBK_019= B) }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK_010= D) }, { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK_011= C) }, + { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1MRBK) }, + { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1MRBK_01A= B) }, #endif #if IS_ENABLED(CONFIG_HID_ELO) { HID_USB_DEVICE(USB_VENDOR_ID_ELO, 0x0009) }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 37F293884C7; Sat, 28 Feb 2026 17:36:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300197; cv=none; b=EQDc8Pmcou+RWzYiGxzBAkEmydiPv+xKuwIR0GtHs/MRQkHokUrYUeESQRBSIsJ3b0sDgeFp2vaEmhOHrobVwVk4sBdbpZGXpQwmPxvY7DVTLy0PYce+rVcMJonQt39JLh8es5G3D0OubFTLgkAwDGXhQs0CMk+qHnwalQ2vOiQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300197; c=relaxed/simple; bh=ihM/50EQk5ZYXzXdh2AxqEuLIbEdjM8Y4qOk8e9bSf0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pwW9o1/ANztsYZbYg62/KRwO4LHlaBiPx3oQuWL2E08l264Sdk40lsrz32JbIymXcqGVWccdThsaO0JjPIlyVB4AaTN3Nqpd9FTinay6wRm/YCv1CIC1Z7tY+F5FZnKU8/uN8hA7r6DKyHsTjJuX/sEE9NYY11TD7PIC3K/C5ns= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gFbmIxoV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gFbmIxoV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83B8DC19424; Sat, 28 Feb 2026 17:36:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300197; bh=ihM/50EQk5ZYXzXdh2AxqEuLIbEdjM8Y4qOk8e9bSf0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gFbmIxoVgeAoe0xvip0i86judlWrQq7JdvgVVSLu1jw1UBT8EJCzHh2CBMBMVVgb8 A94xbuvrGOzBogP5Yb5m1/dduaVFI2eLakpXtD0Qdnyv5DH1Iy5hF9vOkMEBr3ql9H Ntaa9+oXOsvyTABurM78CrDPf74At2mWDWnk+JxKrsREB8iW0CN3FnbX0By5HvbmVm sX/NI52j4BtFNuuQ62dIueTZesshkjBhJ8Wnwe/ZcabsM92VoA4wXgNq9bQjSE0Vzo 4EYOnMUiNBIMpr2cMsSp5KywguJGkKCJDv0Y7bLC/7NkuNWshoUzR7vQMmWY2Im/UF 82S6M8m/7oBNA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: gongqi <550230171hxy@gmail.com>, Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 215/844] ALSA: hda/conexant: Add headset mic fix for MECHREVO Wujie 15X Pro Date: Sat, 28 Feb 2026 12:22:08 -0500 Message-ID: <20260228173244.1509663-216-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: gongqi <550230171hxy@gmail.com> [ Upstream commit f2581ea2d9f30844c437e348a462027ea25c12e9 ] The headset microphone on the MECHREVO Wujie 15X Pro requires the CXT_FIXUP_HEADSET_MIC quirk to function properly. Add the PCI SSID (0x1d05:0x3012) to the quirk table. Signed-off-by: gongqi <550230171hxy@gmail.com> Link: https://patch.msgid.link/20260122155501.376199-5-550230171hxy@gmail.c= om Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/hda/codecs/conexant.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/hda/codecs/conexant.c b/sound/hda/codecs/conexant.c index 0c517378a6d28..f71123a475464 100644 --- a/sound/hda/codecs/conexant.c +++ b/sound/hda/codecs/conexant.c @@ -1134,6 +1134,7 @@ static const struct hda_quirk cxt5066_fixups[] =3D { SND_PCI_QUIRK_VENDOR(0x17aa, "Thinkpad/Ideapad", CXT_FIXUP_LENOVO_XPAD_AC= PI), SND_PCI_QUIRK(0x1c06, 0x2011, "Lemote A1004", CXT_PINCFG_LEMOTE_A1004), SND_PCI_QUIRK(0x1c06, 0x2012, "Lemote A1205", CXT_PINCFG_LEMOTE_A1205), + SND_PCI_QUIRK(0x1d05, 0x3012, "MECHREVO Wujie 15X Pro", CXT_FIXUP_HEADSET= _MIC), HDA_CODEC_QUIRK(0x2782, 0x12c3, "Sirius Gen1", CXT_PINCFG_TOP_SPEAKER), HDA_CODEC_QUIRK(0x2782, 0x12c5, "Sirius Gen2", CXT_PINCFG_TOP_SPEAKER), {} --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11FFC3446B0; Sat, 28 Feb 2026 17:36:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300198; cv=none; b=TJztsOGZjjHYGlQrPh8ljEioFRhwFQKsZj+dizRwFbtadS3EISXlmG0ySgRVALsWwM/KBTwxUbStrWlUOXHHIvejRxidjSBbwT6PmCxX4VhxfghYSA8+pGqlr7ejoSJ+HyTHCKzzokkmiNhP2EsAN8aDi459SA5jkTEmF+VY/rQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300198; c=relaxed/simple; bh=FvsW4QBgQq6gs/tk8hTh8nBELhR0NwkQ/WSSZ1LKiCU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XRUx+GjYrpeYEhCc+AF2Fkar0TL699T1sQQQ06pPiEJj+wcfxPccPxlUYT7HmrpbEU/jL4x6CSkwXwksSMD0xEW5I9i0/4XY+6WF7SiUxKxsLF6Bj4OsvOHX7PmPEx51lzcfApXI4U4Vi6yC8VC2s5m82W9pQdqzpkuGfOOVrE4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GfEUAHL4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GfEUAHL4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D4A1C116D0; Sat, 28 Feb 2026 17:36:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300197; bh=FvsW4QBgQq6gs/tk8hTh8nBELhR0NwkQ/WSSZ1LKiCU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GfEUAHL4QFnKfvC4h2nvYhyRtb6OCIgK8w8hXZHIORZjrwqgv7RkKd8bqwEX9BSiC z38xKwd6F7ldvNbXLfFri1ykm/4tJDzr/CMViTWMIKiQP3ge+6YzQBy0ILneqtULVT 1R0sgj6GwcrqBaCF4KIBwQf6n1R8TFl5/dq9k7X1Dl4BjpesRmHOfH7pPwH+mne3sc Eh2RwWiL5of4cxK4VekPMUlNT9vbO/mjmlqsYsPg9qRNN4R/d9tgl8pQxKZJ5DQnL2 htv2xmZEsglpooc2VkatoT4IHsPGctoFcaVUWCS4+QtQSrQWy1sCQJ1wY6OTHrpTx8 cMn/y6bx7pnHA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Damien Dagorn , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 216/844] ALSA: hda/realtek: fix LG Gram Style 14 speakers Date: Sat, 28 Feb 2026 12:22:09 -0500 Message-ID: <20260228173244.1509663-217-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Damien Dagorn [ Upstream commit cc051fbd7f40226cc407558bc97c5099513e8657 ] The LG Gram Style 14 (14Z90RS-G.AD77F, SSID 1854:0490) with Realtek ALC298 shows normal routing and volume changes, but internal speakers stay silent unless a userland HDA-verb workaround is applied. Add a dedicated quirk for the LG Gram Style 14 that programs the codec coefficient sequence used by the known workaround and enables the speaker amps only during playback. Tested-by: Damien Dagorn Signed-off-by: Damien Dagorn Link: https://lore.kernel.org/CAN59QMUhd4kHrkRoJA6VzEr2VKezN2yjHnANaQoZn2-B= nwe3bQ@mail.gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/hda/codecs/realtek/alc269.c | 170 ++++++++++++++++++++++++++++++ 1 file changed, 170 insertions(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/a= lc269.c index c9f59e62ee022..b6fae275919c6 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -1854,6 +1854,163 @@ static void alc298_samsung_v2_init_amps(struct hda_= codec *codec, spec->gen.pcm_playback_hook =3D alc298_samsung_v2_playback_hook; } =20 +/* LG Gram Style 14: program vendor coef sequence used by HDA-verb workaro= und */ +struct alc298_lg_gram_style_seq { + unsigned short verb; + unsigned short idx; + unsigned short val; +}; + +static void alc298_lg_gram_style_coef_write(struct hda_codec *codec, + unsigned int verb, + unsigned int idx, + unsigned int val) +{ + snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_COEF_INDEX, 0x23); + snd_hda_codec_write(codec, 0x20, 0, verb, idx); + snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_PROC_COEF, 0x00); + snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_PROC_COEF, val); + snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_PROC_COEF, 0xb011); +} + +static void alc298_lg_gram_style_run_seq(struct hda_codec *codec, + const struct alc298_lg_gram_style_seq *seq, + int seq_size) +{ + int i; + + for (i =3D 0; i < seq_size; i++) + alc298_lg_gram_style_coef_write(codec, seq[i].verb, + seq[i].idx, seq[i].val); +} + +/* Coef sequences derived from the HDA-verb workaround for this model. */ +static const struct alc298_lg_gram_style_seq alc298_lg_gram_style_preinit_= seq[] =3D { + { 0x420, 0x00, 0x01 }, +}; + +static const struct alc298_lg_gram_style_seq alc298_lg_gram_style_disable_= seq[] =3D { + { 0x423, 0xff, 0x00 }, + { 0x420, 0x3a, 0x80 }, +}; + +static const struct alc298_lg_gram_style_seq alc298_lg_gram_style_enable_s= eq[] =3D { + { 0x420, 0x3a, 0x81 }, + { 0x423, 0xff, 0x01 }, +}; + +static const struct alc298_lg_gram_style_seq alc298_lg_gram_style_init_seq= _38[] =3D { + { 0x423, 0xe1, 0x00 }, { 0x420, 0x12, 0x6f }, { 0x420, 0x14, 0x00 }, + { 0x420, 0x1b, 0x01 }, { 0x420, 0x1d, 0x01 }, { 0x420, 0x1f, 0xfe }, + { 0x420, 0x21, 0x00 }, { 0x420, 0x22, 0x10 }, { 0x420, 0x3d, 0x05 }, + { 0x420, 0x3f, 0x03 }, { 0x420, 0x50, 0x2c }, { 0x420, 0x76, 0x0e }, + { 0x420, 0x7c, 0x4a }, { 0x420, 0x81, 0x03 }, { 0x423, 0x99, 0x03 }, + { 0x423, 0xa4, 0xb5 }, { 0x423, 0xa5, 0x01 }, { 0x423, 0xba, 0x94 }, +}; + +static const struct alc298_lg_gram_style_seq alc298_lg_gram_style_init_seq= _39[] =3D { + { 0x423, 0xe1, 0x00 }, { 0x420, 0x12, 0x6f }, { 0x420, 0x14, 0x00 }, + { 0x420, 0x1b, 0x02 }, { 0x420, 0x1d, 0x02 }, { 0x420, 0x1f, 0xfd }, + { 0x420, 0x21, 0x01 }, { 0x420, 0x22, 0x10 }, { 0x420, 0x3d, 0x05 }, + { 0x420, 0x3f, 0x03 }, { 0x420, 0x50, 0x2c }, { 0x420, 0x76, 0x0e }, + { 0x420, 0x7c, 0x4a }, { 0x420, 0x81, 0x03 }, { 0x423, 0x99, 0x03 }, + { 0x423, 0xa4, 0xb5 }, { 0x423, 0xa5, 0x01 }, { 0x423, 0xba, 0x94 }, +}; + +static const struct alc298_lg_gram_style_seq alc298_lg_gram_style_init_seq= _3c[] =3D { + { 0x423, 0xe1, 0x00 }, { 0x420, 0x12, 0x6f }, { 0x420, 0x14, 0x00 }, + { 0x420, 0x1b, 0x01 }, { 0x420, 0x1d, 0x01 }, { 0x420, 0x1f, 0xfe }, + { 0x420, 0x21, 0x00 }, { 0x420, 0x22, 0x10 }, { 0x420, 0x3d, 0x05 }, + { 0x420, 0x3f, 0x03 }, { 0x420, 0x50, 0x2c }, { 0x420, 0x76, 0x0e }, + { 0x420, 0x7c, 0x4a }, { 0x420, 0x81, 0x03 }, { 0x423, 0xba, 0x8d }, +}; + +static const struct alc298_lg_gram_style_seq alc298_lg_gram_style_init_seq= _3d[] =3D { + { 0x423, 0xe1, 0x00 }, { 0x420, 0x12, 0x6f }, { 0x420, 0x14, 0x00 }, + { 0x420, 0x1b, 0x02 }, { 0x420, 0x1d, 0x02 }, { 0x420, 0x1f, 0xfd }, + { 0x420, 0x21, 0x01 }, { 0x420, 0x22, 0x10 }, { 0x420, 0x3d, 0x05 }, + { 0x420, 0x3f, 0x03 }, { 0x420, 0x50, 0x2c }, { 0x420, 0x76, 0x0e }, + { 0x420, 0x7c, 0x4a }, { 0x420, 0x81, 0x03 }, { 0x423, 0xba, 0x8d }, +}; + +struct alc298_lg_gram_style_amp_desc { + unsigned char nid; + const struct alc298_lg_gram_style_seq *init_seq; + int init_seq_size; +}; + +static const struct alc298_lg_gram_style_amp_desc alc298_lg_gram_style_amp= s[] =3D { + { 0x38, alc298_lg_gram_style_init_seq_38, + ARRAY_SIZE(alc298_lg_gram_style_init_seq_38) }, + { 0x39, alc298_lg_gram_style_init_seq_39, + ARRAY_SIZE(alc298_lg_gram_style_init_seq_39) }, + { 0x3c, alc298_lg_gram_style_init_seq_3c, + ARRAY_SIZE(alc298_lg_gram_style_init_seq_3c) }, + { 0x3d, alc298_lg_gram_style_init_seq_3d, + ARRAY_SIZE(alc298_lg_gram_style_init_seq_3d) }, +}; + +static void alc298_lg_gram_style_enable_amps(struct hda_codec *codec) +{ + struct alc_spec *spec =3D codec->spec; + int i; + + for (i =3D 0; i < spec->num_speaker_amps; i++) { + alc_write_coef_idx(codec, 0x22, alc298_lg_gram_style_amps[i].nid); + alc298_lg_gram_style_run_seq(codec, + alc298_lg_gram_style_enable_seq, + ARRAY_SIZE(alc298_lg_gram_style_enable_seq)); + } +} + +static void alc298_lg_gram_style_disable_amps(struct hda_codec *codec) +{ + struct alc_spec *spec =3D codec->spec; + int i; + + for (i =3D 0; i < spec->num_speaker_amps; i++) { + alc_write_coef_idx(codec, 0x22, alc298_lg_gram_style_amps[i].nid); + alc298_lg_gram_style_run_seq(codec, + alc298_lg_gram_style_disable_seq, + ARRAY_SIZE(alc298_lg_gram_style_disable_seq)); + } +} + +static void alc298_lg_gram_style_playback_hook(struct hda_pcm_stream *hinf= o, + struct hda_codec *codec, + struct snd_pcm_substream *substream, + int action) +{ + if (action =3D=3D HDA_GEN_PCM_ACT_OPEN) + alc298_lg_gram_style_enable_amps(codec); + if (action =3D=3D HDA_GEN_PCM_ACT_CLOSE) + alc298_lg_gram_style_disable_amps(codec); +} + +static void alc298_lg_gram_style_init_amps(struct hda_codec *codec) +{ + struct alc_spec *spec =3D codec->spec; + int i; + + spec->num_speaker_amps =3D ARRAY_SIZE(alc298_lg_gram_style_amps); + + for (i =3D 0; i < spec->num_speaker_amps; i++) { + alc_write_coef_idx(codec, 0x22, alc298_lg_gram_style_amps[i].nid); + alc298_lg_gram_style_run_seq(codec, + alc298_lg_gram_style_preinit_seq, + ARRAY_SIZE(alc298_lg_gram_style_preinit_seq)); + alc298_lg_gram_style_run_seq(codec, + alc298_lg_gram_style_disable_seq, + ARRAY_SIZE(alc298_lg_gram_style_disable_seq)); + alc298_lg_gram_style_run_seq(codec, + alc298_lg_gram_style_amps[i].init_seq, + alc298_lg_gram_style_amps[i].init_seq_size); + alc_write_coef_idx(codec, 0x89, 0x0); + } + + spec->gen.pcm_playback_hook =3D alc298_lg_gram_style_playback_hook; +} + static void alc298_fixup_samsung_amp_v2_2_amps(struct hda_codec *codec, const struct hda_fixup *fix, int action) { @@ -1868,6 +2025,13 @@ static void alc298_fixup_samsung_amp_v2_4_amps(struc= t hda_codec *codec, alc298_samsung_v2_init_amps(codec, 4); } =20 +static void alc298_fixup_lg_gram_style_14(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + if (action =3D=3D HDA_FIXUP_ACT_PROBE) + alc298_lg_gram_style_init_amps(codec); +} + static void gpio2_mic_hotkey_event(struct hda_codec *codec, struct hda_jack_callback *event) { @@ -3764,6 +3928,7 @@ enum { ALC298_FIXUP_SAMSUNG_AMP, ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS, ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS, + ALC298_FIXUP_LG_GRAM_STYLE_14, ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, ALC295_FIXUP_ASUS_MIC_NO_PRESENCE, @@ -5459,6 +5624,10 @@ static const struct hda_fixup alc269_fixups[] =3D { .type =3D HDA_FIXUP_FUNC, .v.func =3D alc298_fixup_samsung_amp_v2_4_amps }, + [ALC298_FIXUP_LG_GRAM_STYLE_14] =3D { + .type =3D HDA_FIXUP_FUNC, + .v.func =3D alc298_fixup_lg_gram_style_14 + }, [ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET] =3D { .type =3D HDA_FIXUP_VERBS, .v.verbs =3D (const struct hda_verb[]) { @@ -7406,6 +7575,7 @@ static const struct hda_quirk alc269_fixup_tbl[] =3D { SND_PCI_QUIRK(0x1854, 0x0488, "LG gram 16 (16Z90R)", ALC298_FIXUP_SAMSUNG= _AMP_V2_4_AMPS), SND_PCI_QUIRK(0x1854, 0x0489, "LG gram 16 (16Z90R-A)", ALC298_FIXUP_SAMSU= NG_AMP_V2_4_AMPS), SND_PCI_QUIRK(0x1854, 0x048a, "LG gram 17 (17ZD90R)", ALC298_FIXUP_SAMSUN= G_AMP_V2_4_AMPS), + SND_PCI_QUIRK(0x1854, 0x0490, "LG Gram Style 14 (14Z90RS)", ALC298_FIXUP_= LG_GRAM_STYLE_14), SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MACH-WX9", ALC256_FIXUP_HUAWEI_MACH= _WX9_PINS), SND_PCI_QUIRK(0x19e5, 0x320f, "Huawei WRT-WX9 ", ALC256_FIXUP_ASUS_MIC_NO= _PRESENCE), SND_PCI_QUIRK(0x19e5, 0x3212, "Huawei KLV-WX9 ", ALC256_FIXUP_ACER_HEADSE= T_MIC), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 002FA388EAF; Sat, 28 Feb 2026 17:36:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300199; cv=none; b=sr+fVsz0NnYi2FIZu44XMd5SFqYPrBmnFMql+USBsPJzrquuu+XS+pge0KAzDfQVaZYPRSYMx4t64B7InY3ktzppBPH3xvJY+8+OscNZiEhL6D3f7wM4u0EjF6mEtTTfgm1CPYIqgcbLw0W0lt/oHhE1ohMDpRCS4QwKCD/gGNY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300199; c=relaxed/simple; bh=PydTwEqeCbZg9HU66Qfhd+8E0cz2J+FcRHJw4mffmPo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P9Vs8c4/h7L7+ihvUuj/BUyBCogJASpAs38m3uQBz7uHKT33I+NrDxa2OmIS3hwkCXj+O6eZcpXK/ZdYDsVusck1LPXNTdTNVSw3fj4kfHGsPfUcoepV1/3ftP6FiJh5QyhYzsJcG8aaBwdJ56ODiIJ8y3t0oXwBY3BRFpyYclA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Uj73Vq80; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Uj73Vq80" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37132C19424; Sat, 28 Feb 2026 17:36:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300198; bh=PydTwEqeCbZg9HU66Qfhd+8E0cz2J+FcRHJw4mffmPo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Uj73Vq80Ln9lV6CbxcCvT3ss8eMFzEv27pUlM373mUfSQiNIx4iE9uANSlkplZPPk VM/sVlrnVJk1B6qGcLcE579Z7jVi8X7JBlZe/uiqj8iWBCTXZrBoEhCm5cJO84p1o7 8dYqNI71SdTQKxiOoKxM5DD196JvL8AxjQ9toHdyTNWZybtEhDcdvXh/btNIPSALoa J8gOStHavylnpF6n3nqdE+XnY6OB9ti/mSN2Uk0Lqtn42VdgFddeVq2D/0JFxsKqwP mzM/7ZtWW5i6TpBKeaTlHxZEnuRFpVoS9/SIxgG1eW3E6mBsaatRPGUO19ADw2sb6t EcPrZJNn8qxmg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Billy Tsai , Linus Walleij , Bartosz Golaszewski , Sasha Levin Subject: [PATCH 6.19 217/844] gpio: aspeed-sgpio: Change the macro to support deferred probe Date: Sat, 28 Feb 2026 12:22:10 -0500 Message-ID: <20260228173244.1509663-218-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Billy Tsai [ Upstream commit e18533b023ec7a33488bcf33140ce69bbba2894f ] Use module_platform_driver() to replace module_platform_driver_probe(). The former utilizes platform_driver_register(), which allows the driver to defer probing when it doesn't acquire the necessary resources due to probe order. In contrast, the latter uses __platform_driver_probe(), which includes the comment "Note that this is incompatible with deferred probing." Since our SGPIO driver requires access to the clock resource, the former is more suitable. Reviewed-by: Linus Walleij Signed-off-by: Billy Tsai Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-1-69cfd1631400@a= speedtech.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpio/gpio-aspeed-sgpio.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-aspeed-sgpio.c b/drivers/gpio/gpio-aspeed-sg= pio.c index 7622f9e9f54af..318cd0e397416 100644 --- a/drivers/gpio/gpio-aspeed-sgpio.c +++ b/drivers/gpio/gpio-aspeed-sgpio.c @@ -516,7 +516,7 @@ static const struct of_device_id aspeed_sgpio_of_table[= ] =3D { =20 MODULE_DEVICE_TABLE(of, aspeed_sgpio_of_table); =20 -static int __init aspeed_sgpio_probe(struct platform_device *pdev) +static int aspeed_sgpio_probe(struct platform_device *pdev) { u32 nr_gpios, sgpio_freq, sgpio_clk_div, gpio_cnt_regval, pin_mask; const struct aspeed_sgpio_pdata *pdata; @@ -611,11 +611,12 @@ static int __init aspeed_sgpio_probe(struct platform_= device *pdev) } =20 static struct platform_driver aspeed_sgpio_driver =3D { + .probe =3D aspeed_sgpio_probe, .driver =3D { .name =3D KBUILD_MODNAME, .of_match_table =3D aspeed_sgpio_of_table, }, }; =20 -module_platform_driver_probe(aspeed_sgpio_driver, aspeed_sgpio_probe); +module_platform_driver(aspeed_sgpio_driver); MODULE_DESCRIPTION("Aspeed Serial GPIO Driver"); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC2E3388ECD; Sat, 28 Feb 2026 17:36:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300199; cv=none; b=n9Qo7n32Bi/kbz+G/ap1jrKZFicElKSwJgcImxe11o6D8ip6mpr+7X6+La5V2VNL1aHK6+uyez6N3aZw0TzdErfYJ/fG33nRapgV0FZjOG88nYFIyFtfUl8XfoTPutGRO/1OpTgns8nLxOa3mFiBC8w8DWq+KxLGd638tPJ7Hrw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300199; c=relaxed/simple; bh=QBh4SxHLt1xI6PMRW4JLJQxEAh+26aoB97GHXl5dVXo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qxcycj1K3+uYY6eUzRs3vX8Hu7veYVbd68F+8WwG0993zMOx0SQTEoAEATcMIc65oGVHS6DmBZMZoQYBdMCGsEVfQaKZre1eC/vc6XkK6t6OSPQzHISpP8BwX/aPfmBlbY/OAUbIlgDcVtGCgPB/2RtfXpGWVQ1zI8PlDMPuehk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=et7cVMy1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="et7cVMy1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25369C19423; Sat, 28 Feb 2026 17:36:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300199; bh=QBh4SxHLt1xI6PMRW4JLJQxEAh+26aoB97GHXl5dVXo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=et7cVMy1T8TBu08dg1bodKi+XgxsNa5fJAx91XSAeh0wCicIQWgkW8m4JTZtjvcty 9cGaFAreQpDwnfTmGKWWG4N98MUy2JGYMSZXDmRNONEExRuYq+8biBKZ45TI1ZOhvc R0EYQWmu/BFPuJVwWVLpfXl3xw3iN96D/iC92wq2Kr0e2oA8dHN6fti96rq01UX6uj z6pQ36yIhzSEXy8lfT7C8CPM8NwT+kWqirat1jICmZjrwrjvmumcE3yO6T1XP3yzKZ K82HtkNOjbzP5NWtNsurBaTNz0VeLpzgvn9ax1ZfkG8KWulvriJE45namy1QhAv012 0tUBFCdXSuBlw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chen Ni , Mark Brown , Sasha Levin Subject: [PATCH 6.19 218/844] ASoC: sunxi: sun50i-dmic: Add missing check for devm_regmap_init_mmio Date: Sat, 28 Feb 2026 12:22:11 -0500 Message-ID: <20260228173244.1509663-219-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chen Ni [ Upstream commit 74823db9ba2e13f3ec007b354759b3d8125e462c ] Add check for the return value of devm_regmap_init_mmio() and return the error if it fails in order to catch the error. Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260127033250.2044608-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/sunxi/sun50i-dmic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/sunxi/sun50i-dmic.c b/sound/soc/sunxi/sun50i-dmic.c index bab1e29c99887..eddfebe166169 100644 --- a/sound/soc/sunxi/sun50i-dmic.c +++ b/sound/soc/sunxi/sun50i-dmic.c @@ -358,6 +358,9 @@ static int sun50i_dmic_probe(struct platform_device *pd= ev) =20 host->regmap =3D devm_regmap_init_mmio(&pdev->dev, base, &sun50i_dmic_regmap_config); + if (IS_ERR(host->regmap)) + return dev_err_probe(&pdev->dev, PTR_ERR(host->regmap), + "failed to initialise regmap\n"); =20 /* Clocks */ host->bus_clk =3D devm_clk_get(&pdev->dev, "bus"); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEB7638B062; Sat, 28 Feb 2026 17:36:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300201; cv=none; b=FT7TJTS1w/k+oPVxAicONCUYSf17bVUehln8vhKKcgK2FSxveEA4O8kDXAQWV4rHLzMdIWE1PwtlgBGJSQNU/IIR0emSaWFCY/9TpPjSjvOgE/a+dWOP5qAo1C0o6y9jcFBfVKnl/dZbJb6joyAEs36aNuFRePMMsWCw2BcdQ+g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300201; c=relaxed/simple; bh=0mcpErzsT89PNp6WTm45KtHOVA09y6/piPalN8kPFUA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MvOEOEC84hEAMqv7j5DFulDLMtAELpvZ0U0A2CR6bDaEV4SipAyWb2a+dwhEcW2PORryrHLXxmIJqZwZ5wIorF5bsh/7KS3CNLfsI69Ve27pdZ/pxP/MVjZnb6BWRG/+DNlI5uXRf+zVHWJ5DWUQX/SjuOm6VwjPDJ4dHyF72cg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eGwwT/kY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eGwwT/kY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F0795C116D0; Sat, 28 Feb 2026 17:36:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300200; bh=0mcpErzsT89PNp6WTm45KtHOVA09y6/piPalN8kPFUA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eGwwT/kYiEBj9ui7XcqMskFk3JQwbNBAmeug068vEp3lYzyJWj0xK4DYNu+z3SELf 6uaGwM9HlSaMobg92sinW1I4TYHBgXYULfg7OQP1loMyqKochAHpT5vaBhM2nhivZy a/43OGb+csz6WxAGfNDL5PSTBohmm6x94+P8qr+qM6V2EvwZznUP0aYOac6D+qsapl 0rbI/QrqZeEOvZViUAtaZAzkHZPXui33uog/v2GB5E8wqwOVLHfyg/zU6Hv5Y3TaIP oS9D5mniVBm01SBkSD1l1iNJuLxWUqCKWp72x9fIArPGUB0K0ijcgi1byoIErDXx3j Bt3ockaZqFcJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chin-Ting Kuo , Paul Menzel , Mark Brown , Sasha Levin Subject: [PATCH 6.19 219/844] spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/end Date: Sat, 28 Feb 2026 12:22:12 -0500 Message-ID: <20260228173244.1509663-220-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chin-Ting Kuo [ Upstream commit 53f826ff5e0e3ecb279862ca7cce1491b94bb017 ] spi_mem_dirmap_create() may reconfigure controller-wide settings, which can interfere with concurrent transfers to other devices sharing the same SPI controller but using different chip selects. Wrap the ->dirmap_create() callback with spi_mem_access_start() and spi_mem_access_end() to serialize access and prevent cross-CS interference during dirmap creation. This patch has been verified on a setup where a SPI TPM is connected to CS0 of a SPI controller, while a SPI NOR flash is connected to CS1 of the same controller. Without this patch, spi_mem_dirmap_create() for the SPI NOR flash interferes with ongoing SPI TPM data transfers, resulting in failure to create the TPM device. This was tested on an ASPEED AST2700 EVB. Signed-off-by: Chin-Ting Kuo Reviewed-by: Paul Menzel Link: https://patch.msgid.link/20260120123005.1392071-2-chin-ting_kuo@aspee= dtech.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spi-mem.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index 6c7921469b90b..965673bac98b9 100644 --- a/drivers/spi/spi-mem.c +++ b/drivers/spi/spi-mem.c @@ -719,9 +719,18 @@ spi_mem_dirmap_create(struct spi_mem *mem, =20 desc->mem =3D mem; desc->info =3D *info; - if (ctlr->mem_ops && ctlr->mem_ops->dirmap_create) + if (ctlr->mem_ops && ctlr->mem_ops->dirmap_create) { + ret =3D spi_mem_access_start(mem); + if (ret) { + kfree(desc); + return ERR_PTR(ret); + } + ret =3D ctlr->mem_ops->dirmap_create(desc); =20 + spi_mem_access_end(mem); + } + if (ret) { desc->nodirmap =3D true; if (!spi_mem_supports_op(desc->mem, &desc->info.op_tmpl)) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BDA3D38B082; Sat, 28 Feb 2026 17:36:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300201; cv=none; b=gRNsajZ4ilV+WsAM0imP09Wsi8ETjXLGB8IV+bbU82unyJwxxhjNmCCJNet2kI56Umzt2Z+yDnhdH2WWj5LLMq/eBYx0z2HYgZau3myGEQf73xxFD0SC0FS0Pnju3Orf+QXM/O9DSXNd5hnC0dYpU/sYXXU/wDdpTXQn1RN9LzU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300201; c=relaxed/simple; bh=RLrpuXOskdUjrMLmYKSnbBOc1+AQtLbjAOsyVcpzuZk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eIX6NvcFQeaL7XserOU6nq5gV8ttaPx2Re11CSOP8hMGUPY96ifhp3Ee/0aPwQhYRjNooqKcKVu6r+xzzbYR6IdNHUrGu1bjJaZsgwWl4d0m24rFCIuuzTqV0ArBOtibTI3Eu9UYt0xPRhvRqz+zcyQ2vm1K5xyogr8JdRG0EZ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=abzjlhUU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="abzjlhUU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD88FC19423; Sat, 28 Feb 2026 17:36:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300201; bh=RLrpuXOskdUjrMLmYKSnbBOc1+AQtLbjAOsyVcpzuZk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=abzjlhUUy3qfkjDyJOAmu8jeu57MqzyWXivGJbxO8AoQ/+ph8Ngb7V2kWTBzaO1De k27b8WGeWF9fkIROsDbkAMetqPgXbPNuHa0yXSZB1ehrTAIWB7ZEusAGXDMjUBejGP SRy1e/6DCr5DwJu6Zz+hJCT4EEAPbp0DcJ2dy+sV+hpQFWwi7hdRgNJ0mIsBW52SgV r9OQq7kiyPoE688V23AASOhGpZZuAYgAqrCeyf9E8hc+OX7hdCvdti2kGLSoy9+Ssv 0y6vM81BlcvWjE1yP1LPUOseI5OLLe460I3gDidR7cr7UGXmUa85M8DVxfZ84HYAem wioLeqDNqr9jw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Matthew Stewart , Aurabindo Pillai , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 220/844] drm/amd/display: Fix GFX12 family constant checks Date: Sat, 28 Feb 2026 12:22:13 -0500 Message-ID: <20260228173244.1509663-221-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Matthew Stewart [ Upstream commit bdad08670278829771626ea7b57c4db531e2544f ] Using >=3D, <=3D for checking the family is not always correct. Reviewed-by: Aurabindo Pillai Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gp= u/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 62622aa622066..209a6e5c713ca 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -11853,7 +11853,7 @@ static int dm_check_cursor_fb(struct amdgpu_crtc *n= ew_acrtc, * check tiling flags when the FB doesn't have a modifier. */ if (!(fb->flags & DRM_MODE_FB_MODIFIERS)) { - if (adev->family >=3D AMDGPU_FAMILY_GC_12_0_0) { + if (adev->family =3D=3D AMDGPU_FAMILY_GC_12_0_0) { linear =3D AMDGPU_TILING_GET(afb->tiling_flags, GFX12_SWIZZLE_MODE) =3D= =3D 0; } else if (adev->family >=3D AMDGPU_FAMILY_AI) { linear =3D AMDGPU_TILING_GET(afb->tiling_flags, SWIZZLE_MODE) =3D=3D 0; diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c b/driv= ers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c index f0946e67aef97..7474f1bc1d0b8 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c @@ -278,7 +278,7 @@ static int amdgpu_dm_plane_validate_dcc(struct amdgpu_d= evice *adev, if (!dcc->enable) return 0; =20 - if (adev->family < AMDGPU_FAMILY_GC_12_0_0 && + if (adev->family !=3D AMDGPU_FAMILY_GC_12_0_0 && format >=3D SURFACE_PIXEL_FORMAT_VIDEO_BEGIN) return -EINVAL; =20 @@ -901,7 +901,7 @@ int amdgpu_dm_plane_fill_plane_buffer_attributes(struct= amdgpu_device *adev, upper_32_bits(chroma_addr); } =20 - if (adev->family >=3D AMDGPU_FAMILY_GC_12_0_0) { + if (adev->family =3D=3D AMDGPU_FAMILY_GC_12_0_0) { ret =3D amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers(adev,= afb, format, rotation, plane_size, tiling_info, dcc, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D79D23446B0; Sat, 28 Feb 2026 17:36:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300202; cv=none; b=FFbCMDkAD28DJq6sain1ZyT8u++ZVeGYkXKiShDQaaZ5x6QjC1Qb9YVHmpmWTkLdwIvOZyCUovYKmjd82vpqecVLAPBAdc04DkkwbRMyieHbqzIaG9rTjPQjZAKLnvrNHCCzKNLlTf039m9KjDKtQbBzuzgk9tvIyZH8dxKGv6w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300202; c=relaxed/simple; bh=WG4TbpCWRD+5HcgHU/xkY1XnNJlL/COPZe4l64ukqVM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eZr+P8xGvRq9H8fooOvNvPfnSlv89R5arrdsAN6Y4pnVEbNSeVw07bHHBsvhfYOnMEFT0dDV+pVDqetkTO9wC1wEKrC3I53rVXvpffA9CBLusKF+uQnjpjLnSLNNKO0lPDJ+GLmPCciV4n0dbB4vJC1Rpmgc1266F3qZmHqCwGw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TK8tI5Ws; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TK8tI5Ws" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3988C116D0; Sat, 28 Feb 2026 17:36:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300202; bh=WG4TbpCWRD+5HcgHU/xkY1XnNJlL/COPZe4l64ukqVM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TK8tI5WsZYiQ3tVh/ExT6ZpOEEHchijcYIrt6Ac7ztpchlFwkCbvU+C12e+Hj5ciV 0fzJosvg6R3btKkx/Cb/kASy6dRvpyF+/fx32uwkayD3SI0Ti6RcszggYde9Jol7zx TSSXlBDCRiMKJTbp2fyCwiELnozcduQvkFItxlv7lqmm6ibkJcsu3Qy9A+St1Jdr2I 0Ulcaihb83lxCfaQh/ujeld+s6JMNzTQGsuHQWB63Ca8EyQ6mxeZIO/XloE+IGXEQx yF35+Gdby5J4U9SE2Cq08iBuG5ZuBanuNYJLtzpQLqvit4+wVZHPNqyOFDZ8hlglzM lL6fYXM9V99/w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhongwei , Wenjing Liu , Aurabindo Pillai , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 221/844] drm/amd/display: avoid dig reg access timeout on usb4 link training fail Date: Sat, 28 Feb 2026 12:22:14 -0500 Message-ID: <20260228173244.1509663-222-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhongwei [ Upstream commit 15b1d7b77e9836ff4184093163174a1ef28bbdd7 ] [Why] When usb4 link training fails, the dpia sym clock will be disabled and SYMC= LK source should be changed back to phy clock. In enable_streams, it is assumed that link training succeeded and will switch from refclk to phy clock. But phy clk here might not be on. Dig reg access timeout will occur. [How] When enable_stream is hit, check if link training failed for usb4. If it did, fall back to the ref clock to avoid reg access timeout. Reviewed-by: Wenjing Liu Signed-off-by: Zhongwei Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c b/driv= ers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c index c8ff8ae85a030..517d4c08d34c4 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c @@ -3058,9 +3058,17 @@ void dcn20_enable_stream(struct pipe_ctx *pipe_ctx) dccg->funcs->enable_symclk32_se(dccg, dp_hpo_inst, phyd32clk); } } else { - if (dccg->funcs->enable_symclk_se) - dccg->funcs->enable_symclk_se(dccg, stream_enc->stream_enc_inst, + if (dccg->funcs->enable_symclk_se && link_enc) { + if (link->ep_type =3D=3D DISPLAY_ENDPOINT_USB4_DPIA + && link->cur_link_settings.link_rate =3D=3D LINK_RATE_UNKNOWN + && !link->link_status.link_active) { + if (dccg->funcs->disable_symclk_se) + dccg->funcs->disable_symclk_se(dccg, stream_enc->stream_enc_inst, link_enc->transmitter - TRANSMITTER_UNIPHY_A); + } else + dccg->funcs->enable_symclk_se(dccg, stream_enc->stream_enc_inst, + link_enc->transmitter - TRANSMITTER_UNIPHY_A); + } } =20 if (dc->res_pool->dccg->funcs->set_pixel_rate_div) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E621338C591; Sat, 28 Feb 2026 17:36:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300204; cv=none; b=X31ypbe8jrJvFY/aa0RfVQM2+UWAWYT58GhwnnHvxm/O3iFEjSFKPVJr/7ev2FEEUZzmnnTXkQImdTZDXQ+5lX5mgdbEhMwSeORXb4bcD/Xgag294m87LDn1bbqpRq2I2+VZbZ0Wb/zMcT9XMXj2KsrQp8SUEha6Hj96I+4USyg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300204; c=relaxed/simple; bh=hP6cVlLON+uh6FuJSf/xYghLQsTOr3q/hDuSMfwlsow=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mSehLgx5rKxINaxScbiVeHEc1iPnizkA9QQHJbCA17sbl6Hm85VygEfPO96siil09ksdjGRyUFd7mKclPZg/klGMxjs+Oz7CdVqc21MgFFv0oKX6oCxBvIf+UZfAuKolel5lRZkc9zgLaq2DuYB16Jv7G6bv/P48+DZ2vZtbAJA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PQndlpQj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PQndlpQj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A9C2C19423; Sat, 28 Feb 2026 17:36:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300203; bh=hP6cVlLON+uh6FuJSf/xYghLQsTOr3q/hDuSMfwlsow=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PQndlpQjfUFg14dgTkcY0/XafVsc1PURH/YwPJn39+lXbVeN68XGJHiwKO0i6teiW Q58uh96TqslcUPZ4orrqd9Etr/w2sErwZpAtHJqy0ISj8LG++CdxUPc97/xF67F8a0 brZtkQHf1vo7DbwojFHUz5R9NyddrQBYrwglEyKo81zdTQF4RQ20MWOoH9AdOZLowP ihbqUDs3tk2JjYtkb2mWErYxjxJ57TgZwLQh9wejhOaDjzbwicFMSo9IDKMMUgP7Cj UPyaWB7qhvMgMIvuJ43LMQvXqDs9WLbcvccQlWyvim+ARQpvrjDTz/45fyAV8+Ikin KfNi1C50Ofm3A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Miquel Raynal (Schneider Electric)" , Wolfram Sang , Santhosh Kumar K , Mark Brown , Sasha Levin Subject: [PATCH 6.19 222/844] spi: cadence-qspi: Fix probe error path and remove Date: Sat, 28 Feb 2026 12:22:15 -0500 Message-ID: <20260228173244.1509663-223-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Miquel Raynal (Schneider Electric)" [ Upstream commit f18c8cfa4f1af2cf7d68d86989a7d6109acfa1bb ] The probe has been modified by many different users, it is hard to track history, but for sure its current state is partially broken. One easy rule to follow is to drop/free/release the resources in the opposite order they have been queried. Fix the labels, the order for freeing the resources, and add the missing DMA channel step. Replicate these changes in the remove path as well. Tested-by: Wolfram Sang Signed-off-by: Miquel Raynal (Schneider Electric) Tested-by: Santhosh Kumar K Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-8-f9c214= 19a3e6@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spi-cadence-quadspi.c | 44 ++++++++++++++++++------------- 1 file changed, 25 insertions(+), 19 deletions(-) diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-qu= adspi.c index b1cf182d65665..ab74808debe98 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -1891,7 +1891,7 @@ static int cqspi_probe(struct platform_device *pdev) ret =3D clk_prepare_enable(cqspi->clk); if (ret) { dev_err(dev, "Cannot enable QSPI clock.\n"); - goto probe_clk_failed; + goto disable_rpm; } =20 /* Obtain QSPI reset control */ @@ -1899,14 +1899,14 @@ static int cqspi_probe(struct platform_device *pdev) if (IS_ERR(rstc)) { ret =3D PTR_ERR(rstc); dev_err(dev, "Cannot get QSPI reset.\n"); - goto probe_reset_failed; + goto disable_clk; } =20 rstc_ocp =3D devm_reset_control_get_optional_exclusive(dev, "qspi-ocp"); if (IS_ERR(rstc_ocp)) { ret =3D PTR_ERR(rstc_ocp); dev_err(dev, "Cannot get QSPI OCP reset.\n"); - goto probe_reset_failed; + goto disable_clk; } =20 if (of_device_is_compatible(pdev->dev.of_node, "starfive,jh7110-qspi")) { @@ -1914,7 +1914,7 @@ static int cqspi_probe(struct platform_device *pdev) if (IS_ERR(rstc_ref)) { ret =3D PTR_ERR(rstc_ref); dev_err(dev, "Cannot get QSPI REF reset.\n"); - goto probe_reset_failed; + goto disable_clk; } reset_control_assert(rstc_ref); reset_control_deassert(rstc_ref); @@ -1956,7 +1956,7 @@ static int cqspi_probe(struct platform_device *pdev) if (ddata->jh7110_clk_init) { ret =3D cqspi_jh7110_clk_init(pdev, cqspi); if (ret) - goto probe_reset_failed; + goto disable_clk; } if (ddata->quirks & CQSPI_DISABLE_STIG_MODE) cqspi->disable_stig_mode =3D true; @@ -1964,7 +1964,7 @@ static int cqspi_probe(struct platform_device *pdev) if (ddata->quirks & CQSPI_DMA_SET_MASK) { ret =3D dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)); if (ret) - goto probe_reset_failed; + goto disable_clks; } } =20 @@ -1975,7 +1975,7 @@ static int cqspi_probe(struct platform_device *pdev) pdev->name, cqspi); if (ret) { dev_err(dev, "Cannot request IRQ.\n"); - goto probe_reset_failed; + goto disable_clks; } =20 cqspi_wait_idle(cqspi); @@ -2002,31 +2002,36 @@ static int cqspi_probe(struct platform_device *pdev) ret =3D cqspi_request_mmap_dma(cqspi); if (ret =3D=3D -EPROBE_DEFER) { dev_err_probe(&pdev->dev, ret, "Failed to request mmap DMA\n"); - goto probe_setup_failed; + goto disable_controller; } } =20 ret =3D spi_register_controller(host); if (ret) { dev_err(&pdev->dev, "failed to register SPI ctlr %d\n", ret); - goto probe_setup_failed; + goto release_dma_chan; } =20 if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) pm_runtime_put_autosuspend(dev); =20 return 0; -probe_setup_failed: - if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) - pm_runtime_disable(dev); + +release_dma_chan: + if (cqspi->rx_chan) + dma_release_channel(cqspi->rx_chan); +disable_controller: cqspi_controller_enable(cqspi, 0); -probe_reset_failed: +disable_clks: if (cqspi->is_jh7110) cqspi_jh7110_disable_clk(pdev, cqspi); - +disable_clk: if (pm_runtime_get_sync(&pdev->dev) >=3D 0) clk_disable_unprepare(cqspi->clk); -probe_clk_failed: +disable_rpm: + if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) + pm_runtime_disable(dev); + return ret; } =20 @@ -2044,18 +2049,19 @@ static void cqspi_remove(struct platform_device *pd= ev) cqspi_wait_idle(cqspi); =20 spi_unregister_controller(cqspi->host); - cqspi_controller_enable(cqspi, 0); =20 if (cqspi->rx_chan) dma_release_channel(cqspi->rx_chan); =20 - if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) - if (pm_runtime_get_sync(&pdev->dev) >=3D 0) - clk_disable(cqspi->clk); + cqspi_controller_enable(cqspi, 0); =20 if (cqspi->is_jh7110) cqspi_jh7110_disable_clk(pdev, cqspi); =20 + if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) + if (pm_runtime_get_sync(&pdev->dev) >=3D 0) + clk_disable(cqspi->clk); + if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) { pm_runtime_put_sync(&pdev->dev); pm_runtime_disable(&pdev->dev); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C97A38C5B4; Sat, 28 Feb 2026 17:36:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300205; cv=none; b=uLTuPC3YaUEb89vZSqpfR1B+16RszYY4W86lSOYPRWPYytKkXoh7WeP9TL2Xr5A79Fm2C7gULvQJjt0ZFAt2xmOQwafXRs/kYrkjIvVkVdU+FwAjaqAtOJiHPIbCh4QhcNNa9yuOh6rq5ZUR9Gg1/0SyuMgDy+N4YgVt3MuP2H4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300205; c=relaxed/simple; bh=b0bCWCCM+U5MnoXGr6BF/KjjFV15RPUhwQmlKKcJK9k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pfxMDElWE6hUCSozszRCiDcjDR8pyDm3OKzTZMVhNdAHC9nUQSfNhgfMaCETTE/wMKwQiq67iEOuscH49RScgLjTVQdQY0DAggVwi00c6IXAjr+iS3WXlGOXmKwT7uJwr7ELfvVbYyTke5CT90b6duN0FbFkmn+HO6aiYXvYpEo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pmirHJ/W; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pmirHJ/W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CA32C116D0; Sat, 28 Feb 2026 17:36:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300204; bh=b0bCWCCM+U5MnoXGr6BF/KjjFV15RPUhwQmlKKcJK9k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pmirHJ/W92wonBVbSrNHhkzHGMEEh7N+DGISiPLJ3jRyYgfEJwOyRNZp2/5ivLwI0 BM7VzAXftYn/nsgstz6oqzFud9drbsGNBoDDFqWQfAw/WRwwFmITc6NG0MkKWj0zuO E30YsfgG88Q1+gXYyX81pSXLUxjwOyyuRHqLdA79GRPkh43Wb2pouXz18peo2U0ooK qRKeS3SLgfXpLSbwUJ5m3zK4jSjTGAgorU+em2HzBW+L83sM7O5E/yxgTWAs3+PR62 dMkx9lWKlxADm1hQoXUpgBz5dyGO8oWxkc73BnDpsJWpwC9RdtRUekXE3c8PjAz4vO rALZ351sVQjzQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Jesse.Zhang" , =?UTF-8?q?Christian=20K=C3=B6nig?= , Jesse Zhang , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 223/844] drm/amdgpu: validate user queue size constraints Date: Sat, 28 Feb 2026 12:22:16 -0500 Message-ID: <20260228173244.1509663-224-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: "Jesse.Zhang" [ Upstream commit 8079b87c02e531cc91601f72ea8336dd2262fdf1 ] Add validation to ensure user queue sizes meet hardware requirements: - Size must be a power of two for efficient ring buffer wrapping - Size must be at least AMDGPU_GPU_PAGE_SIZE to prevent undersized allocati= ons This prevents invalid configurations that could lead to GPU faults or unexpected behavior. Reviewed-by: Christian K=C3=B6nig Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/am= d/amdgpu/amdgpu_userq.c index 58b26c78b6425..ab934723579c9 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c @@ -860,6 +860,17 @@ static int amdgpu_userq_input_args_validate(struct drm= _device *dev, drm_file_err(filp, "invalidate userq queue va or size\n"); return -EINVAL; } + + if (!is_power_of_2(args->in.queue_size)) { + drm_file_err(filp, "Queue size must be a power of 2\n"); + return -EINVAL; + } + + if (args->in.queue_size < AMDGPU_GPU_PAGE_SIZE) { + drm_file_err(filp, "Queue size smaller than AMDGPU_GPU_PAGE_SIZE\n"); + return -EINVAL; + } + if (!args->in.wptr_va || !args->in.rptr_va) { drm_file_err(filp, "invalidate userq queue rptr or wptr\n"); return -EINVAL; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEF6538B098; Sat, 28 Feb 2026 17:36:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300206; cv=none; b=uRGcFSzUb0Z1/ZHWcxz3Sy+o6xDYzgqPr/tfjwFGObdiZq8E7R08dhrZhqeckD3gjGe5OjJ0Z4snaHrPenb/oE3s/s9gD3HemLXKoU7nm70EtohOcrPI2MJ5SMD5CzdSWwgUFgX5thuHEME4yXTiifl7NVyPfkjGPKuyHlFJwYw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300206; c=relaxed/simple; bh=Hv4zTzC8AsZwjBE0dP/UIcpMsL4cPNvABgym2Z2/pp0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DRZVl+t8143LE69waZt2KisY9Snd2vgVLKb2min4cYy+5GiQY6s8zG86FQTZZcsRJPGBcr6FVAWyZK9OmPL6BkkP8qSkw81Y0hO4n2nbTp68YJN4Cd7IndDjm09V/5S/Wms60fGtIYlQLIeFROW0Xte4IOgsHIlwaRCWn/O59sk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q7C+NlKd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="q7C+NlKd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11488C19424; Sat, 28 Feb 2026 17:36:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300205; bh=Hv4zTzC8AsZwjBE0dP/UIcpMsL4cPNvABgym2Z2/pp0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q7C+NlKd4c0QR4XibfNHOlTrPA4sfuMh/kecbHuTJKCb69eJ9z599LgqGEAVZe0RF werc6iY+fqKtnuBXnksewuwS6zE3p1iUparRsaRCAGwVQrxefrIZrC6fdNfwdK4Ymj bCHnxg35ejl0Wk4MlnkeDOhA8GizJGqmAU1i2T95EtogkiorGwj7RPijb6/dD1joa9 1p/ENEevX4kOQ8WtkwBJ7+oQjtIHZ/5JT8yNFDsBiP9dlw3X/OZ3K/yXkLhBT/PhTB 4bebaYsFeV7mYdwm8KDaQmu2gsor1/k422NTID4WNhu3ovzEhX3N/CIABqQMoR2sxK kWni429JWprwQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Miquel Raynal (Schneider Electric)" , Wolfram Sang , Santhosh Kumar K , Mark Brown , Sasha Levin Subject: [PATCH 6.19 224/844] spi: cadence-qspi: Try hard to disable the clocks Date: Sat, 28 Feb 2026 12:22:17 -0500 Message-ID: <20260228173244.1509663-225-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Miquel Raynal (Schneider Electric)" [ Upstream commit 612227b392eed94a3398dc03334a84a699a82276 ] In the remove path, we should try hard to perform all steps as we simply cannot fail. The "no runtime PM" quirk must only alter the state of the RPM core, but the clocks should still be disabled if that is possible. Move the disable call outside of the RPM quirk. Tested-by: Wolfram Sang Signed-off-by: Miquel Raynal (Schneider Electric) Tested-by: Santhosh Kumar K Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-9-f9c214= 19a3e6@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spi-cadence-quadspi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-qu= adspi.c index ab74808debe98..51ed666a0fdd1 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -2040,6 +2040,7 @@ static void cqspi_remove(struct platform_device *pdev) const struct cqspi_driver_platdata *ddata; struct cqspi_st *cqspi =3D platform_get_drvdata(pdev); struct device *dev =3D &pdev->dev; + int ret =3D 0; =20 ddata =3D of_device_get_match_data(dev); =20 @@ -2059,8 +2060,10 @@ static void cqspi_remove(struct platform_device *pde= v) cqspi_jh7110_disable_clk(pdev, cqspi); =20 if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) - if (pm_runtime_get_sync(&pdev->dev) >=3D 0) - clk_disable(cqspi->clk); + ret =3D pm_runtime_get_sync(&pdev->dev); + + if (ret >=3D 0) + clk_disable(cqspi->clk); =20 if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) { pm_runtime_put_sync(&pdev->dev); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1A33938CFF0; Sat, 28 Feb 2026 17:36:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300207; cv=none; b=tbSBYLdbs+lu5mB1MrWLdk7YVFcsk19eYgkwNoBCaqaupb49Ln+0g+f2mfV92PnTwMjZ3BBvSAlPA54LpRVxCXcJvhs/bs6Vbx/AMZf0jaKGB+Vbty5QQTJY+B1mJvMpvXhlnjRPgEbqI6ND5ktXtIgdL5SRKq6hh3qM0/EfSu8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300207; c=relaxed/simple; bh=uokOkRCSMVLxsGu3rqxKfmFg2fGZyt7kKmsiD3KiJqM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SCYPXG+6ZehORA9leiAAh5JRFW3zWgDljpRaxj/t7y6YubmhlKkYwWGWq7hnPuUyRJRkbJakLbSezfseYkc59/XayMTpxQxfNBVjsDho+khCPsxAx2QCMLrpcgLNCMu715KIIk6WxClWpgXUjzjnSnCaCa+V5Sqlu5+mewjqyPE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lrXLm8y2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lrXLm8y2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 174CBC19423; Sat, 28 Feb 2026 17:36:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300206; bh=uokOkRCSMVLxsGu3rqxKfmFg2fGZyt7kKmsiD3KiJqM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lrXLm8y2/GtRcoh60QQKXwLxKBEHT98Of7Yz9or3NLqUrzO8oeFGme3Z/Ji9BRI+S 99KdACBB+TPL1fBbMBp7DppPi84i/0oFf46Pz1TecVJNE2/MYS8BweU4B3dkUNybed 69vGfV2rMr1JeLqtCeEnP95HzG82AXp4xzdAVi/T2DrSlRr+PINbUaNiUFiI2WmhjZ xFpqqILpnQ9x/i+v6iVq5RIT4PLOSVeOmiL77JEFQLdKThuYZo5dhZaPHvu50rTwDj m20TKDHNXfUpK73Zmu1SNDZlxeOXt7d1oFP1qE9u0BPSbuDn4lykulF3aD4zJi/IP0 qyA57hoiZ6a3g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jinzhou Su , Yang Wang , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 225/844] drm/amd/pm: Fix null pointer dereference issue Date: Sat, 28 Feb 2026 12:22:18 -0500 Message-ID: <20260228173244.1509663-226-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jinzhou Su [ Upstream commit 1197366cca89a4c44c541ddedb8ce8bf0757993d ] If SMU is disabled, during RAS initialization, there will be null pointer dereference issue here. Signed-off-by: Jinzhou Su Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c b/drivers/gpu/drm/am= d/pm/swsmu/amdgpu_smu.c index f51fa265230b3..2a0e826d0317d 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c @@ -618,6 +618,9 @@ int amdgpu_smu_ras_send_msg(struct amdgpu_device *adev,= enum smu_message_type ms struct smu_context *smu =3D adev->powerplay.pp_handle; int ret =3D -EOPNOTSUPP; =20 + if (!smu) + return ret; + if (smu->ppt_funcs && smu->ppt_funcs->ras_send_msg) ret =3D smu->ppt_funcs->ras_send_msg(smu, msg, param, read_arg); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD94938D009; Sat, 28 Feb 2026 17:36:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300207; cv=none; b=R/jPc4JgB9m9BaZTNF2gdo5+iVGMTCZPam8g0RkuMbE6SYKZZBSQB8VL4hjX6Zq6zAQHW7iaFe/PBbVJcRM8XmoTjytiO5R8m++/wzij5/W8Y6DgYxNW/L2+uEv5sNEOwDTG6CHrE/wYdC438+0RoN/W6NF6v7i8bNS0W/bKkh0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300207; c=relaxed/simple; bh=HrE32cZx8Wn5/h1pkvX3+n4NaaYqY4QP3DhxJjCs4u0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sLzph1+eguryzMHw5fy2Jtc9FnwYQEk52fqLIkfah6XV7HjLF9jLBkzwR31e1e/GhzpXt7Oz1XHO0rgN+WfYFZpXtAvL66AKXN1FbbiHrIrzCjGmT2xFShTn93YMkw0BrHb56frap0r/tqootcx2nbZH7yvOeBzr8ccfjaeKRPw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N+j7nzrj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N+j7nzrj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0588DC2BC9E; Sat, 28 Feb 2026 17:36:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300207; bh=HrE32cZx8Wn5/h1pkvX3+n4NaaYqY4QP3DhxJjCs4u0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N+j7nzrjMrJ7litxdXDLWSkLJTAzXJmyb2aDOQOAGhlkpgJVBsR6t1iQcH1YtkmEu XerC3hpLzfOolJacsDS/KfIizKpOC0KAhdB89wi+PGCDqaWYIcRdWmKeccU9UEDaq4 XFRQMvpZ/hoLWEFJIMM+7QM3TIhtky1Y+HJJ0HNdAE6GfDkGthkifzFG5GD21Xobs6 xBuwToZm1WltVGm3DEo7kZVs+RgjUvLod83KnWZ6wyDyo8G1s8EF70gfFR8oFu+IP3 K+3WxTggC4AprJ/Ad9zK3uihLS3teaocnMSbeN5jpdMG6bIv2MTxhQJBwuGxSg2eCY jBJ5sZvl627Ew== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chen Ni , Mark Brown , Sasha Levin Subject: [PATCH 6.19 226/844] ASoC: codecs: max98390: Check return value of devm_gpiod_get_optional() in max98390_i2c_probe() Date: Sat, 28 Feb 2026 12:22:19 -0500 Message-ID: <20260228173244.1509663-227-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chen Ni [ Upstream commit a1d14d8364eac2611fe1391c73ff0e5b26064f0e ] The devm_gpiod_get_optional() function may return an error pointer (ERR_PTR) in case of a genuine failure during GPIO acquisition, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the function call to catch such errors and propagate them to the probe function, ensuring the driver fails to load safely rather than proceeding with an invalid pointer. Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260130091904.3426149-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/codecs/max98390.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/codecs/max98390.c b/sound/soc/codecs/max98390.c index 3dd4dd94bc371..ff58805e97d17 100644 --- a/sound/soc/codecs/max98390.c +++ b/sound/soc/codecs/max98390.c @@ -1067,6 +1067,9 @@ static int max98390_i2c_probe(struct i2c_client *i2c) =20 reset_gpio =3D devm_gpiod_get_optional(&i2c->dev, "reset", GPIOD_OUT_HIGH); + if (IS_ERR(reset_gpio)) + return dev_err_probe(&i2c->dev, PTR_ERR(reset_gpio), + "Failed to get reset gpio\n"); =20 /* Power on device */ if (reset_gpio) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D2A7938CFEC; Sat, 28 Feb 2026 17:36:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300208; cv=none; b=EokAjhbq4tN9NXP+K/5zG5dXxRxhO7q8qrsEx+qvHXdXnTRbzLeYm7W82dlsisBnbyYlhIrtc0QpohTuJfHvActIqNLaqmCRYBPyic4JFHbsOszBtidhIIrvH/RfH8U+j1NieSA/H2eHhOoeEW0hYAPPHXaSkaISkm83U425Vtw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300208; c=relaxed/simple; bh=kpQBiKo3UidFW6K/ysDFz78+2sCdcuiynhFgU1tK/pA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HJszLEL+69FsCPac0TgBMKVByvLHSqsAzUbm643XTyjd46o7URs2SYnyljudGENSyzpKxwa2RqCPkji7QSxDYzvf4/YnU/5bAMT9nWlbVTdH1RlbFM8iEe1eZ4H1JE+Dq1ym47Fm/Ie7uGyENipeez9Zo2Y2idAShddCmddMuEM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Bs3cS5vC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Bs3cS5vC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D416EC116D0; Sat, 28 Feb 2026 17:36:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300208; bh=kpQBiKo3UidFW6K/ysDFz78+2sCdcuiynhFgU1tK/pA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Bs3cS5vCVEQnaxhgFJkgiwVmcbELgHzTyfdhHnvy5IGBB/EsZF22cy3+vevcS7b3c RIcf48Y6dd5JVG0wGtFFsh7eJzz8PPnOVd9/hg8pbxVKv78m6hNqRi3GslPNqnuDac 3JMN7A5yAGptJmBwuXh/mEQEvRK6mEfA+Bv06Q5WC2lo2Xk4veGYrADjtfk9Cid9HS 4yfDVR7hpiIyaPzUVTyvE/xAm9BCcRv9svysaWbNuu6Bg5nl9Iu9uOLjcbnd5LDdQf NE9v55G2GJKqBojvgMw66/qTGXfh38m2To8h0deyg5Z+/L2IAqVTEgIwa834nlac4I KlsfRa/Kkk1Yg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Robert McIntyre , Eugene Shalygin , Guenter Roeck , Sasha Levin Subject: [PATCH 6.19 227/844] hwmon: (asus-ec-sensors) add Pro WS TRX50-SAGE WIFI A Date: Sat, 28 Feb 2026 12:22:20 -0500 Message-ID: <20260228173244.1509663-228-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Robert McIntyre [ Upstream commit af7e57d444141ac9e77b57296d59c3e965c4c4fa ] Adding support for Pro WS TRX50-SAGE WIFI A, which is identical sensors-wise to Pro WS TRX50-SAGE WIFI Signed-off-by: Robert McIntyre Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20251213200531.259435-4-eugene.shalygin@gma= il.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- Documentation/hwmon/asus_ec_sensors.rst | 1 + drivers/hwmon/asus-ec-sensors.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/= asus_ec_sensors.rst index 232885f24430d..b5e1bc7ac0643 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -10,6 +10,7 @@ Supported boards: * PRIME X670E-PRO WIFI * PRIME Z270-A * Pro WS TRX50-SAGE WIFI + * Pro WS TRX50-SAGE WIFI A * Pro WS X570-ACE * Pro WS WRX90E-SAGE SE * ProArt X570-CREATOR WIFI diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensor= s.c index 61b18b88ee8ff..a1445799e23d8 100644 --- a/drivers/hwmon/asus-ec-sensors.c +++ b/drivers/hwmon/asus-ec-sensors.c @@ -793,6 +793,8 @@ static const struct dmi_system_id dmi_table[] =3D { &board_info_pro_art_x870E_creator_wifi), DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS TRX50-SAGE WIFI", &board_info_pro_ws_trx50_sage_wifi), + DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS TRX50-SAGE WIFI A", + &board_info_pro_ws_trx50_sage_wifi), DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS WRX90E-SAGE SE", &board_info_pro_ws_wrx90e_sage_se), DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS X570-ACE", --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C86938D8ED; Sat, 28 Feb 2026 17:36:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300209; cv=none; b=dcJoKQ+HPk4Bulm3avxJq/sYl8VLJT/shP4RcnfjXT6R5LQDRRkPp4BEY+4pS+Nz+Bl+TrpBLNYMPfkjVHVaHmNDrlMUXPyfRPiL5OsEVM1b40IFXOJkAnN1KGmQ2BmKahitv9nzxkhcjoEuqT6XXV6iiz5+m1+O2f0EqbfevwM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300209; c=relaxed/simple; bh=qFrL+5AJ5lSWHyUdcL93osAkU/wRQ815d3F1yiyPzqc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ESmdGY8smxwiwslpust7zjRirTdOWkHWPLJ1Em7bhM6Aqd0vW+pNlBgV9Ho7wdI6D8Vcgq2WeKdcduBmDDtecPSLjhU3eYkQ8Pv8LgninS++0C26HRX6R5Byrbg8sPkqGhx0h+eeoOgsX41pE+02ogmranITVd47H6mNoEDgMrk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LtFXyMCC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LtFXyMCC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4518C19425; Sat, 28 Feb 2026 17:36:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300209; bh=qFrL+5AJ5lSWHyUdcL93osAkU/wRQ815d3F1yiyPzqc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LtFXyMCCNYV6nMjfsg6OK0IO5eGb5E5kQ1Bg/QvHzg683Lzg+fNUP/b3S0R9O2maN QXrr3VUrtegwxaoQ+kQIT9PVOrB1SIGLlCt4OZ/H/yxzg0+91sjvKRsc6jIsU13e5u cU/hTH2DaRx8r06tCzD8eQES7xlZ1kJNiC0mUeMJ4Itgc+KrgJfB5eLaLtaNr7fX+k /XPV2SHS+vh75hOen1Ym53WK4gkans9+vP+sEQMut9fiDKD7+EFze9hgot27dSuB3u RFFyo5lfzeNCNsl5dhLvQ1NL4ynNRqLnQNG+f7NonTSla62zIksRUwi6k28z8llv6y xJUR2aYOpJa5Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Armin Wolf , =?UTF-8?q?Pali=20Roh=C3=A1r?= , Guenter Roeck , Sasha Levin Subject: [PATCH 6.19 228/844] hwmon: (dell-smm) Add support for Dell OptiPlex 7080 Date: Sat, 28 Feb 2026 12:22:21 -0500 Message-ID: <20260228173244.1509663-229-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Armin Wolf [ Upstream commit 46c3e87a79179454f741f797c274dd25f5c6125e ] The Dell OptiPlex 7080 supports the legacy SMM interface for reading sensors and performing fan control. Whitelist this machine so that this driver loads automatically. Closes: https://github.com/Wer-Wolf/i8kutils/issues/16 Signed-off-by: Armin Wolf Acked-by: Pali Roh=C3=A1r Link: https://lore.kernel.org/r/20260104000654.6406-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hwmon/dell-smm-hwmon.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c index 93143cfc157cf..038edffc1ac74 100644 --- a/drivers/hwmon/dell-smm-hwmon.c +++ b/drivers/hwmon/dell-smm-hwmon.c @@ -1325,6 +1325,13 @@ static const struct dmi_system_id i8k_dmi_table[] __= initconst =3D { DMI_MATCH(DMI_PRODUCT_NAME, "MP061"), }, }, + { + .ident =3D "Dell OptiPlex 7080", + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "OptiPlex 7080"), + }, + }, { .ident =3D "Dell OptiPlex 7060", .matches =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8560E38D90C; Sat, 28 Feb 2026 17:36:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300210; cv=none; b=MWV/wQNiFrcfPQ1fsUQMSPAHm1ecn56nEP25wj4/xonCAUVubFnSDctWccnD34AZO1EQ2JgeSQE66vxoFOx4cbNtfBHQIR5AgQSZovsSX/lT1q5O4LNme7kAIycm8gBP8weFrYJE4ecX9aF+O6QgSz3nTvI0H7n/029Sin0GLpI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300210; c=relaxed/simple; bh=pT+LdLV3yEuY57fuDBK1byh/uEypzVof9WiEIGMjNPk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=T4EPceZpQdvYd+GxoskhgOap60w4hm0rAenFk6ixYy5raHKw5t/eemtjs77QpAbZLJbUsJV3XQg7d9BmOihntBF0Nz/i/gtnayyUCIvn3qzclky/GU6zy9PMlZaQJCYbRot5ZUNwrzRixdJq5184j5a9q1CZiaGV8QMZtCHZf1Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hFnrKUxT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hFnrKUxT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3A61C19425; Sat, 28 Feb 2026 17:36:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300210; bh=pT+LdLV3yEuY57fuDBK1byh/uEypzVof9WiEIGMjNPk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hFnrKUxTLq0s7ZfHg6aFKD6rYXu/0VAzMm+RPvyHkMXBrj1TTbHHPajMrhiOQngY/ 0NxVSJXkrK//loGEgV5VbUra6kdsX5UrQJRk5FtQQxkgMjfBnvIhnZ4B1i4Eaifumm AjtABQwXpGjbJtWk3sfOHXAJRUHfFbWM1yNSOR8q7p0W4g+BHz44PPlZGfX6p+LUzw JOadpiZxxWoYghToxQINYGiYr7a2bhQ9h0grYsWkpspSdE4CotrV2/0OvQ264hWqpH HR9a66q2I5nfZp9vp5mC8qEGhJ0EjdnBi/EXfYBJYbeSQX1H3PsDDGR2IzMvunf37Q 53i6dwyaYsK0A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Denis Pauk , Marcus , Guenter Roeck , Sasha Levin Subject: [PATCH 6.19 229/844] hwmon: (nct6775) Add ASUS Pro WS WRX90E-SAGE SE Date: Sat, 28 Feb 2026 12:22:22 -0500 Message-ID: <20260228173244.1509663-230-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Denis Pauk [ Upstream commit 246167b17c14e8a5142368ac6457e81622055e0a ] Boards Pro WS WRX90E-SAGE SE has got a nct6775 chip, but by default there's no use of it because of resource conflict with WMI method. Add the board to the WMI monitoring list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D204807 Signed-off-by: Denis Pauk Tested-by: Marcus Link: https://lore.kernel.org/r/20251231155316.2048-1-pauk.denis@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hwmon/nct6775-platform.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hwmon/nct6775-platform.c b/drivers/hwmon/nct6775-platf= orm.c index c3a719aef1ace..555029dfe713f 100644 --- a/drivers/hwmon/nct6775-platform.c +++ b/drivers/hwmon/nct6775-platform.c @@ -1357,6 +1357,7 @@ static const char * const asus_msi_boards[] =3D { "Pro WS W680-ACE IPMI", "Pro WS W790-ACE", "Pro WS W790E-SAGE SE", + "Pro WS WRX90E-SAGE SE", "ProArt B650-CREATOR", "ProArt B660-CREATOR D4", "ProArt B760-CREATOR D4", --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B21947ECD3; Sat, 28 Feb 2026 17:36:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300211; cv=none; b=q/GkReCPLhUr7w+MSxk9SvGe0rNY1XQFqydKBcx8MHfNJzkRQ38YhHw+sA4UQ45la/xBvo8fpgxn2S23VCgd7moCGvFBT37YfIDL7yhRZNhyMx/wLtiqCYghQiWzGCdW8l/haGCyWUO94cju3fbpSgrT6uMNYAn8E8jOcJpUXd4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300211; c=relaxed/simple; bh=HF6QJLMj4durEMEEyikGQooFujvgeRlZgDckJosIKhI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZiPrz8mTBnbkBZCFkC/WzcFnJMer7CRvPbUVO97jGLBoh0ZBgMRqe+kHHFu/53h+sbMDWkhrXgdmzUPuAP897GUD1P4aPs78ID+ssPQv/wHCZklYKztnX7Ksk8F4d3NdsbemCML//KYjL27To2qGDcZaXJWGu/k4wTEyYvBsmcg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F5ozrEm7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F5ozrEm7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2067C19424; Sat, 28 Feb 2026 17:36:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300211; bh=HF6QJLMj4durEMEEyikGQooFujvgeRlZgDckJosIKhI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F5ozrEm7yI0GipWwvlgM0pryYHGPQyMjrPo42qK/dQhnhXlwgyrjFjssiPyIxPZ55 UwMVhJjJ4lM7N5sX+OEPF5++VOlegjufYtrkjzhhkweF2qQuEvPXqKMEO+aAC3qYLJ Z9E5tkjnECXJPdwoSDF4rISss7dbd22ImaivfzaNrIYmzcNhB3cjjaiqlXwq/A0jUY xijn+Gb47hthxeT3v13ej703/Ucjj7dvoM+37e2jTGihOt81j7gdqXuiSqjiadg/eu s9kgfYW4sUGPPS/YLWoWvf9dHOaEmXlx1NcI8ib/D4OmKZXe8H5CAyZvr6mtHY0Aef CKDviwXJV0G5w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Anj Duvnjak , Guenter Roeck , Sasha Levin Subject: [PATCH 6.19 230/844] hwmon: (nct6683) Add customer ID for ASRock Z590 Taichi Date: Sat, 28 Feb 2026 12:22:23 -0500 Message-ID: <20260228173244.1509663-231-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Anj Duvnjak [ Upstream commit c0fa7879c9850bd4597740a79d4fac5ebfcf69cc ] Add support for customer ID 0x1621 found on ASRock Z590 Taichi boards using the Nuvoton NCT6686D embedded controller. This allows the driver to instantiate without requiring the force=3D1 module parameter. Tested on two separate ASRock Z590 Taichi boards, both with EC firmware version 1.0 build 01/25/21. Signed-off-by: Anj Duvnjak Link: https://lore.kernel.org/r/20251222220942.10762-1-avian@extremenerds.n= et Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- Documentation/hwmon/nct6683.rst | 1 + drivers/hwmon/nct6683.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/Documentation/hwmon/nct6683.rst b/Documentation/hwmon/nct6683.= rst index 3e549ba95a15a..45eec9dd349aa 100644 --- a/Documentation/hwmon/nct6683.rst +++ b/Documentation/hwmon/nct6683.rst @@ -65,6 +65,7 @@ AMD BC-250 NCT6686D EC firmware version 1.0 build 07/28= /21 ASRock X570 NCT6683D EC firmware version 1.0 build 06/28/19 ASRock X670E NCT6686D EC firmware version 1.0 build 05/19/22 ASRock B650 Steel Legend WiFi NCT6686D EC firmware version 1.0 build 11/09= /23 +ASRock Z590 Taichi NCT6686D EC firmware version 1.0 build 01/25/21 MSI B550 NCT6687D EC firmware version 1.0 build 05/07/20 MSI X670-P NCT6687D EC firmware version 0.0 build 09/27/22 MSI X870E NCT6687D EC firmware version 0.0 build 11/13/24 diff --git a/drivers/hwmon/nct6683.c b/drivers/hwmon/nct6683.c index 6cda35388b24c..4a83804140386 100644 --- a/drivers/hwmon/nct6683.c +++ b/drivers/hwmon/nct6683.c @@ -181,6 +181,7 @@ superio_exit(int ioreg) #define NCT6683_CUSTOMER_ID_ASROCK2 0xe1b #define NCT6683_CUSTOMER_ID_ASROCK3 0x1631 #define NCT6683_CUSTOMER_ID_ASROCK4 0x163e +#define NCT6683_CUSTOMER_ID_ASROCK5 0x1621 =20 #define NCT6683_REG_BUILD_YEAR 0x604 #define NCT6683_REG_BUILD_MONTH 0x605 @@ -1242,6 +1243,8 @@ static int nct6683_probe(struct platform_device *pdev) break; case NCT6683_CUSTOMER_ID_ASROCK4: break; + case NCT6683_CUSTOMER_ID_ASROCK5: + break; default: if (!force) return -ENODEV; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 315F038F62E; Sat, 28 Feb 2026 17:36:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300212; cv=none; b=W7vfrS5bUE36C6z2ocfAd03EzN74Ldw+O2SQVs1NBdKr48PLoRuAdYPLSWnVptUJ5dmZir47Ry/aw9YRikh5RMX0AikzV34kRo4T5GtbrlO930HELOZr+XeHdWB0M/TA5CunynpvIY6tdRrsfvUY8ViK0mqTPh6lnDGvj2Bs9PE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300212; c=relaxed/simple; bh=e2nLUu8MmNd6l5CuMURTnwn6ibpsiDxSDRgNZmh8Gyc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fJraz6m8DfmM/KQpHhR2jAu+RTKN3OGXOxLMlc5+HezwuJPjQKm66alvNLtg5a2T5pA2luwVP7rhYImxUxiN8hRx3oROwHAgLccqj4UqyHWUjkhdtUaR+s5bfh8BSb77VqGW9TLA3R2enrV9bpbtmnLGafwL0i87CUE4R7XQQ5Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ofF4iSga; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ofF4iSga" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7CBE6C116D0; Sat, 28 Feb 2026 17:36:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300212; bh=e2nLUu8MmNd6l5CuMURTnwn6ibpsiDxSDRgNZmh8Gyc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ofF4iSgah7RrEpRPKkvUTXYquDKmhLH6BTvUUlTIQhF1iSB65/nMbi5ke5rkP43on z5KBxwWWdXksv2pv+VaxtyiYIZR3zfneIhGSjkXiAgmfjt+P8Dgx2hkYHjnUuNhs7w wepZMZ7XimFOFNE9ICeElaKpDfJrYtZ7fUoJ76POAnbyGxuz1/224LoM48SSXSwk3d re4O6lrBtAF0M0NzkO570euRvWfBDZQsvE1T4h9JS/fD7lB5f54RikehZUOOwiXchs 5hwVz/2lAFDS5dxKdwmcpGHeRR9X6FYiQxY5vhpLXF7OKKlAyT0TirBKmK9RAq7DRf pJeUfU4S2XLmQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Felix Gu , Guenter Roeck , Sasha Levin Subject: [PATCH 6.19 231/844] hwmon: (emc2305) Fix a resource leak in emc2305_of_parse_pwm_child Date: Sat, 28 Feb 2026 12:22:24 -0500 Message-ID: <20260228173244.1509663-232-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Felix Gu [ Upstream commit 2954ce672b7623478c1cfeb69e6a6e4042a3656e ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In emc2305_of_parse_pwm_child, it does not release the reference, causing a resource leak. Signed-off-by: Felix Gu Link: https://lore.kernel.org/r/tencent_738BA80BBF28F3440301EEE6F9E47016510= 5@qq.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hwmon/emc2305.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hwmon/emc2305.c b/drivers/hwmon/emc2305.c index ceae96c07ac45..67e82021da210 100644 --- a/drivers/hwmon/emc2305.c +++ b/drivers/hwmon/emc2305.c @@ -578,6 +578,7 @@ static int emc2305_of_parse_pwm_child(struct device *de= v, data->pwm_output_mask |=3D EMC2305_OPEN_DRAIN << ch; } =20 + of_node_put(args.np); return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5042438F65B; Sat, 28 Feb 2026 17:36:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300213; cv=none; b=afbpbkya8qobZeZZgqMT22oK0mwzPSTxwSXR+N5UbONSShQ3lWL07fQsAthIb0lZ26Z5pQ1ZdqZSilo3MuBH0C7eWXk51mNMn0REe4Y3POJ2mZ3zJR9c1Z8bsA8S8MCiVbfZqrYEYWfmzgQ9Uas2DoL9YpX5VzfWGIYNBGfgX0k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300213; c=relaxed/simple; bh=YXhinGD2EShjI+Ju96y5fdmzoeygDql3kCvvn3JTisw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PIeaF1PZzwOXwpiFsvS4P8bh8rzsGzIG9+5fWolZ4SS81lw2o1dxFKi9BaFacLw+zqzhpkNpxijIdQyha9O5g/SGeYF5M9M8DMHg1ZK7TYUb0ityGk0xvUeiK9oz8/lF7KQYtcg03gqPZ0iKZypD7pMlSlx7Q6AID4GseF66EhM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GZGczUG8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GZGczUG8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56356C116D0; Sat, 28 Feb 2026 17:36:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300212; bh=YXhinGD2EShjI+Ju96y5fdmzoeygDql3kCvvn3JTisw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GZGczUG8QAjwg395hLs6ICEvGHArEzbcUniKBpUuRivsdy7HJML5+ncBVtcCI5y8y 1v/c/DSCqKUs9f+ULJSbmoPsxGTx9GSQ5Y3xo+LAVsEeozoHhRDSZZAv4VO5UDJFeM Dn6ExIZz0o/Swaii3Li3YjzMmPIEhqiDYIB+oDf9TEJdZzwb0O/35Kl6sBtEkRUq4H 8tm12TEvE3HrAnA5SY+vl1N5JdpxfWEWMeYi0V6TmwIrmm111+NChbQZB8D2/EdQBg X8ZwNEi/JsKHOeIup39inq+nMPRp905oV10bJ2tJx5XlK3bAisqWSeTRa+lyOJP1mY 5Kn39wPhtLs4g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Ji-Ze Hong (Peter Hong)" , Guenter Roeck , Sasha Levin Subject: [PATCH 6.19 232/844] hwmon: (f71882fg) Add F81968 support Date: Sat, 28 Feb 2026 12:22:25 -0500 Message-ID: <20260228173244.1509663-233-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Ji-Ze Hong (Peter Hong)" [ Upstream commit e4a3d6f79c9933fece64368168c46d6cf5fc2e52 ] Add hardware monitoring support for the Fintek F81968 Super I/O chip. It is fully compatible with F81866. Several products share compatibility with the F81866. To better distinguish between them, ensure that the Product ID is displayed when the device is probed. Signed-off-by: Ji-Ze Hong (Peter Hong) Link: https://lore.kernel.org/r/20251223051040.10227-1-peter_hong@fintek.co= m.tw Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hwmon/f71882fg.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/hwmon/f71882fg.c b/drivers/hwmon/f71882fg.c index df83f9866fbcf..204059d2de6cd 100644 --- a/drivers/hwmon/f71882fg.c +++ b/drivers/hwmon/f71882fg.c @@ -51,6 +51,7 @@ #define SIO_F81866_ID 0x1010 /* Chipset ID */ #define SIO_F71858AD_ID 0x0903 /* Chipset ID */ #define SIO_F81966_ID 0x1502 /* Chipset ID */ +#define SIO_F81968_ID 0x1806 /* Chipset ID */ =20 #define REGION_LENGTH 8 #define ADDR_REG_OFFSET 5 @@ -2570,6 +2571,7 @@ static int __init f71882fg_find(int sioaddr, struct f= 71882fg_sio_data *sio_data) break; case SIO_F81866_ID: case SIO_F81966_ID: + case SIO_F81968_ID: sio_data->type =3D f81866a; break; default: @@ -2599,9 +2601,9 @@ static int __init f71882fg_find(int sioaddr, struct f= 71882fg_sio_data *sio_data) address &=3D ~(REGION_LENGTH - 1); /* Ignore 3 LSB */ =20 err =3D address; - pr_info("Found %s chip at %#x, revision %d\n", + pr_info("Found %s chip at %#x, revision %d, devid: %04x\n", f71882fg_names[sio_data->type], (unsigned int)address, - (int)superio_inb(sioaddr, SIO_REG_DEVREV)); + (int)superio_inb(sioaddr, SIO_REG_DEVREV), devid); exit: superio_exit(sioaddr); return err; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF38447ECD8; Sat, 28 Feb 2026 17:36:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300213; cv=none; b=DyKDqNTygTYF7gcu2TaKyDolNWUX5b2IjR5rdQ11+yG+uUJsIrKaB2YlU+2XdCTgrA/2RBTsRaMfSrfqBytEgAqyBPjvGHzjKOJ2hUNkeUfe2VvGaGFxNGfalcASgUSj7AYDqiRiQWO9X4d7Dwrj/uRl17VDx0uZd+Mj+uhRh2Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300213; c=relaxed/simple; bh=xThnOp80bagP+sxV1jx0SyaleSC/4bhcPbj9NQNTjhY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kZ8Vzq0l0w4RwT99JSkkBNKVIlD6nQlQB39P46TdC9Iesv6Yp/4M/eU8hQtCxizWPs8INwv9YKiMYNSxXXPP457qtKj5naVWnHNOMBjVq+VZy7gG+MUBVgEdBEVgxYQR9Ij8BlF6FXzlMT/Gkae8rWX6M7HBDuQNzt0sxprBjj4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=goUL80ki; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="goUL80ki" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F1EEC19423; Sat, 28 Feb 2026 17:36:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300213; bh=xThnOp80bagP+sxV1jx0SyaleSC/4bhcPbj9NQNTjhY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=goUL80ki8/WMsyp90OCRQUtfXRU2kEO7aGzwj8v5637QxL2zkLCvEPrXYMIoUltNt dAYfLHVdxUBG1ps+8h4rIlMM+4xAXJYLeD/01/vKGPH4SIlC9xwpuCTft6hIyzhXjE 44yBjikcTxMCjtsFnFADilKBY1q+TXJhkKbVUVuBLNWKKCsyvMXRQ3fRo7IDAzwxVo 3W4aQL6kBbDIzJ1Dgw6aGsz2gZ5NrG0wtbusA2JuGX97otjH9qiXfnAubcFxp6AqZG Uip7CG+v4p6HwiaFX+Qvu3xeBNe89nC858vkXeLExLDyOKXqW6dMfnk2/0KBREBQZi MnHy4rUGDHx6Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Felix Gu , Guenter Roeck , Sasha Levin Subject: [PATCH 6.19 233/844] hwmon: (nct7363) Fix a resource leak in nct7363_present_pwm_fanin Date: Sat, 28 Feb 2026 12:22:26 -0500 Message-ID: <20260228173244.1509663-234-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Felix Gu [ Upstream commit 4923bbff0bcffe488b3aa76829c829bd15b02585 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In nct7363_present_pwm_fanin, it does not release the reference, causing a resource leak. Signed-off-by: Felix Gu Link: https://lore.kernel.org/r/tencent_9717645269E4C07D3D131F52201E12E5E10= A@qq.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hwmon/nct7363.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hwmon/nct7363.c b/drivers/hwmon/nct7363.c index 71cef794835df..47fc1b4a0f3f9 100644 --- a/drivers/hwmon/nct7363.c +++ b/drivers/hwmon/nct7363.c @@ -349,6 +349,7 @@ static int nct7363_present_pwm_fanin(struct device *dev, if (ret) return ret; =20 + of_node_put(args.np); if (args.args[0] >=3D NCT7363_PWM_COUNT) return -EINVAL; data->pwm_mask |=3D BIT(args.args[0]); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB8163907BA; Sat, 28 Feb 2026 17:36:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300214; cv=none; b=pR0QinnQtfDK7nxCo8jMpvp5mi3ibRwa9tIzIrafLO2lhomw6IVORY3XKI9PFe5O/LOPmLrGUvP3w8agaEwT8IFHoMWcf+OfjThbLUsalWomcZEzPGsMs2Tiu1lsvmMlwJdwf/LwQU/DyYxJ/bwTWVjQnLfAgJ+m4MLOu0v/7+E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300214; c=relaxed/simple; bh=qY5I0Wy2aMCKfW2z+0xbRo/coKUmjewIAn8v5cgq4OI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G3Ocq6MXznmWrjenAO7e2eZCUH9asGIJHgyqDWpwwE+JKz91wznC/Npcdn+6x3IR3GqTmUrXnNtG5cmJzSNoxpoWHPXj12789MAzLPlKU5yKMdJTPPk9D63o+CMD/gOguti0ekXsx8ZUhYLlc1dhAjqLRBhlPI5EzZvJnqQvnLo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uzlI+9Xk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uzlI+9Xk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 062A8C116D0; Sat, 28 Feb 2026 17:36:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300214; bh=qY5I0Wy2aMCKfW2z+0xbRo/coKUmjewIAn8v5cgq4OI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uzlI+9XkVzMOtp5u84SQz5+AeAiVs9WByHaYFFfg2SWG11HXD+17LkdrPWo1MznDR B3/p797wMk0m4KyVpyz93EWoNKiVhXGgqB34yvm0dt/1xhZQ7SIqWEagWcEicjMiCX e4+DTGL18ZwO2FT9JPW3JNeSJiuIvf5VuiGlflGp0z4sauFgsPqHKaU2HpOmZ2pRZh z7ep7CaiEDiJyRUka4NOJIg4AnwqwT+86HL5wN7fk4/H9Hjm+atrqSEDGDWk61ZjN9 wNC1W34Mp8ItANkBXMY9F7wH8GybeMVjpf8/rYCqgN7Bi5tcVpf4vaftpjbmDqyq3u 6S/FcwZ94N1Vg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bastien Nocera , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 234/844] HID: logitech-hidpp: Add support for Logitech K980 Date: Sat, 28 Feb 2026 12:22:27 -0500 Message-ID: <20260228173244.1509663-235-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bastien Nocera [ Upstream commit af4fe07a9d963a72438ade96cf090e84b3399d0c ] Add support for the solar-charging Logitech K980 keyboard, over Bluetooth. Bolt traffic doesn't get routed through logitech-dj, so this code isn't triggered when Bolt is used. Signed-off-by: Bastien Nocera Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/hid-logitech-hidpp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hi= dpp.c index e871f1729d4b3..ca96102121b85 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -4666,6 +4666,8 @@ static const struct hid_device_id hidpp_devices[] =3D= { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb037) }, { /* MX Anywhere 3SB mouse over Bluetooth */ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) }, + { /* Slim Solar+ K980 Keyboard over Bluetooth */ + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb391) }, {} }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B9643907D3; Sat, 28 Feb 2026 17:36:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300215; cv=none; b=Lb/ibxQGIUx6JguLcpFlKoy06CryObpAdHIo6lVenRW4oux8kJlqP5oTyZSGOlrA3n4pa8Mo8D3qiaAXXz6N1J3GTsaGu6//YMLJEZpPHnFZdgiJtwJJGMtWqaH1yep/ayABmohvNDxGcPUUA3U7DNrtW6AzKvaG+doh3F6uvX0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300215; c=relaxed/simple; bh=YZAeivByqG0CxOjlVDNH88qy95Dk6/eIfkugnyP5LoI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=libv/HecNQKWSkClpFkS7Bo9tGilVv/Kny2f3zW11dXqs7TuqrTg2RXhN/6LvQFhvF2TOdmecyiGTbPffIKm0TB7xeNfJ/8itF8IQYepxc15j8v7OoSUJL7DMk2SflG+e74fhi6drhFvWp0E804KbHKOLqEGpbMiKayHElOe2YI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Lz+EG5Hw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Lz+EG5Hw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D88B2C19425; Sat, 28 Feb 2026 17:36:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300215; bh=YZAeivByqG0CxOjlVDNH88qy95Dk6/eIfkugnyP5LoI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Lz+EG5HwTnLdsyNbt98FYMfZ5p8cRRvNV84CZ1uCElRQCkFEGYuBznFwfYb3PZDjB CJ/EA6rr6yii+G6dbRVMFAN1kd6EtowS7nooYCmYkAOtjs0LUWKYQ+BIHVkE40GxVl 1S7pSVfNUEzSM9eQFbuPTtdIBURri3FnI1paICsnj5oSemxEy0nl32AAU5zACBVocV bRQxVNfqLCDGff2FvMZRGexdGsxoTShZjv5Pk3+7a2QABS+jy9boD570saTFCLzTu0 H3bh1YsrZiuW6iJ7RDROMEniAULB5qZ3Az5nVgUp9Chdg4FjGYVR5jiL5GifKoIpE5 PMKH2mvk1zlzA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hsieh Hung-En , Mark Brown , Sasha Levin Subject: [PATCH 6.19 235/844] ASoC: es8328: Add error unwind in resume Date: Sat, 28 Feb 2026 12:22:28 -0500 Message-ID: <20260228173244.1509663-236-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hsieh Hung-En [ Upstream commit 8232e6079ae6f8d3a61d87973cb427385aa469b9 ] Handle failures in the resume path by unwinding previously enabled resources. If enabling regulators or syncing the regcache fails, disable regulators and unprepare the clock to avoid leaking resources and leaving the device in a partially resumed state. Signed-off-by: Hsieh Hung-En Link: https://patch.msgid.link/20260130160017.2630-6-hungen3108@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/codecs/es8328.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/es8328.c b/sound/soc/codecs/es8328.c index 1e11175cfbbbf..47c6b0c218b2c 100644 --- a/sound/soc/codecs/es8328.c +++ b/sound/soc/codecs/es8328.c @@ -758,17 +758,23 @@ static int es8328_resume(struct snd_soc_component *co= mponent) es8328->supplies); if (ret) { dev_err(component->dev, "unable to enable regulators\n"); - return ret; + goto err_clk; } =20 regcache_mark_dirty(regmap); ret =3D regcache_sync(regmap); if (ret) { dev_err(component->dev, "unable to sync regcache\n"); - return ret; + goto err_regulators; } =20 return 0; + +err_regulators: + regulator_bulk_disable(ARRAY_SIZE(es8328->supplies), es8328->supplies); +err_clk: + clk_disable_unprepare(es8328->clk); + return ret; } =20 static int es8328_component_probe(struct snd_soc_component *component) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6385F390F67; Sat, 28 Feb 2026 17:36:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300216; cv=none; b=l2TPH0rIcLw3QvVJ8mi0gxG3ZAry5Qay3+punE88l9lSiKUbdNTs78ILUPq3reJHYN6DgRwJ0vhuperDvh/HeNimBhMUIPkrZLc56Xva8jG4wSiHLnHF55hNm9nPI1MA+r4TQAL3hkWxxZwhxbY/1t8/aYfNEwl/POJgUZsgOXQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300216; c=relaxed/simple; bh=t3tLolziVK0PAhfyxAfCkWSKHKRla6C4pF3dA1JR8Qc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZdJQxJlv5LhnsKQ0DRhxOyCZTOS9Sm6WR2MmUUgwp5ZDfvk+6bwevSRty45yBXaPRsu5duc36Jbv50nrNuSxJAugILp1hATusfoCFM5iw66A9sXjm2XTIitdapWKvq8u8+R3/RnSd9mV4r3bQ3QCOpw1BTRbTzbcqoyV0bqavYk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PQgHsnqm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PQgHsnqm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFF80C19423; Sat, 28 Feb 2026 17:36:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300216; bh=t3tLolziVK0PAhfyxAfCkWSKHKRla6C4pF3dA1JR8Qc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PQgHsnqmRFcnYpTv1bqdk8EIbLmyBZ0N34OQkZEnrbBu9D22nXbML67BjMocsXWks QKf9RqzeN2REqX9j5yD/kSqBbNV8ZaykRkqu4uq6S4Ko5hC2+PkYQt7g8BWlEfaLUY 8gzfxAysHU5BKx/ekv5ovflkmmjzTW1N3TlM0D+8dd7chh/4WKxNR/LNJluN8pjXB3 TQxRvpainRKBNKdVWsygAwym5Git/XxghitF8Y93OQcL5ASh5azeufcFg58MyOcr+e uRTfqNiu5snR4rD83VEVF2BQxWJ0cHgSWRvSzW5F3mUoeYz8FtFPHZt43K4s53JVrm GxDHSieabAODw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Samuel Dionne-Riel , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 236/844] ALSA: hda/realtek: Add quirk for Minisforum V3 SE Date: Sat, 28 Feb 2026 12:22:29 -0500 Message-ID: <20260228173244.1509663-237-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Samuel Dionne-Riel [ Upstream commit e3474301824926ecce1d45f2ede7ecdda9a35840 ] First, adding a generic quirk for Bass speaker DAC avoidance. This pattern (re-routing the bass speakers off of a DAC without volume control) seems common enough that having a "model" to match against and quickly use to verify may be worthwhile. The alc285_fixup_thinkpad_x1_gen7 routing was selected, amongst the different options, as it should allow tuning the ratio between both speaker set. The routing was verified using `hda-verb`, and picking either 0x00 or 0x01. Either routing made the volume of the bass speakers controllable. hda-verb /dev/snd/hwC1D0 0x17 SET_CONNECT_SEL 0x01 This likely will apply for the Minisforum V3, though there isn't a lot of information to confirm whether or not the identifiers are the same. This was verified on the Minisforum V3 SE, and the root cause (the bass speakers routing) was found out by using pink noise, and playing with the mixers. Signed-off-by: Samuel Dionne-Riel Link: https://patch.msgid.link/20260203010132.1981419-2-samuel@dionne-riel.= com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/hda/codecs/realtek/alc269.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/a= lc269.c index b6fae275919c6..82219f03b212c 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -4046,6 +4046,7 @@ enum { ALC288_FIXUP_SURFACE_SWAP_DACS, ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO, ALC233_FIXUP_LENOVO_GPIO2_MIC_HOTKEY, + ALC245_FIXUP_BASS_HP_DAC, }; =20 /* A special fixup for Lenovo C940 and Yoga Duet 7; @@ -6548,6 +6549,11 @@ static const struct hda_fixup alc269_fixups[] =3D { .type =3D HDA_FIXUP_FUNC, .v.func =3D alc233_fixup_lenovo_gpio2_mic_hotkey, }, + [ALC245_FIXUP_BASS_HP_DAC] =3D { + .type =3D HDA_FIXUP_FUNC, + /* Borrow the DAC routing selected for those Thinkpads */ + .v.func =3D alc285_fixup_thinkpad_x1_gen7, + }, }; =20 static const struct hda_quirk alc269_fixup_tbl[] =3D { @@ -7609,6 +7615,7 @@ static const struct hda_quirk alc269_fixup_tbl[] =3D { SND_PCI_QUIRK(0x1d72, 0x1947, "RedmiBook Air", ALC255_FIXUP_XIAOMI_HEADSE= T_MIC), SND_PCI_QUIRK(0x1e39, 0xca14, "MEDION NM14LNL", ALC233_FIXUP_MEDION_MTL_S= PK), SND_PCI_QUIRK(0x1ee7, 0x2078, "HONOR BRB-X M1010", ALC2XX_FIXUP_HEADSET_M= IC), + SND_PCI_QUIRK(0x1f4c, 0xe001, "Minisforum V3 (SE)", ALC245_FIXUP_BASS_HP_= DAC), SND_PCI_QUIRK(0x1f66, 0x0105, "Ayaneo Portable Game Player", ALC287_FIXUP= _CS35L41_I2C_2), SND_PCI_QUIRK(0x2014, 0x800a, "Positivo ARN50", ALC269_FIXUP_LIMIT_INT_MI= C_BOOST), SND_PCI_QUIRK(0x2039, 0x0001, "Inspur S14-G1", ALC295_FIXUP_CHROME_BOOK), @@ -7824,6 +7831,7 @@ static const struct hda_model_fixup alc269_fixup_mode= ls[] =3D { {.id =3D ALC285_FIXUP_HP_GPIO_AMP_INIT, .name =3D "alc285-hp-amp-init"}, {.id =3D ALC236_FIXUP_LENOVO_INV_DMIC, .name =3D "alc236-fixup-lenovo-inv= -mic"}, {.id =3D ALC2XX_FIXUP_HEADSET_MIC, .name =3D "alc2xx-fixup-headset-mic"}, + {.id =3D ALC245_FIXUP_BASS_HP_DAC, .name =3D "alc245-fixup-bass-hp-dac"}, {} }; #define ALC225_STANDARD_PINS \ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7863B390F8A; Sat, 28 Feb 2026 17:36:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300217; cv=none; b=hVE+W/j4lYTkxq2eXBdA4KDE4OTbep/l/HXzwTUHUdNyJlgLDuDfN5WpxmwwyYT8kSDzBUDsGZmMKC6PPHG8zbe+CJd+Wb72MEzmT9tTbbWu99AtnVZjgClIE+kzxlfZzSnkHkB6LJNnEeJPHzdpWc9NZ0EcDj+iDJYvhU6sl38= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300217; c=relaxed/simple; bh=Neu4bDaMUVs54Z9GAZOfeDqLijsmvrHj6nh6VZAND9E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FDu0dHY/Yy6fVieZZLdfk50sTN1L7IgFtY9pIZo4R28RHQ46weo8E5nUk1slHD+zhAYqLX0kXf3vmoao+eO3JcKbHmYbHqRr8B1UuB8umaDMUb0vBH3ROKe2DucaQKxnZCJ2KjEKfNxMjZvIiSgCCsTEgOGx/1/uUmKal4e5Bc0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KGpcebpf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KGpcebpf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A04EC19423; Sat, 28 Feb 2026 17:36:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300217; bh=Neu4bDaMUVs54Z9GAZOfeDqLijsmvrHj6nh6VZAND9E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KGpcebpfKzDiOtr20YhlM62tvb86EhDN7vG3KQUIrxFio7afBTnNWxCbkxgm0BYNt azBfns4SInjSMAXqESEcwyyq2yE4eDalONUmHVLyiNvcoPRZZE0KQeJqyzNycquw/z F2XrPs44pfxacPtshOkxHshDFq31RkGyH1q4Nn4T8zVgBImCNpQcBliTpG18iBEQ4+ SIFPrTbkjpEMUtOMEEvp7ze1yVeZdsIqj/ee8Y+YqtBC2OMjIYSbLJWzy3siSXzIWc xscRHa2PixGDqRAS6AbcHtPO0/1AqMmkPJhmuzDRIv3yj5kxvNbSyKOIOgtwtcYnzE I+qLinvTLAH8g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ren=C3=A9=20Rebe?= , Nathan Chancellor , Sasha Levin Subject: [PATCH 6.19 237/844] modpost: Amend ppc64 save/restfpr symnames for -Os build Date: Sat, 28 Feb 2026 12:22:30 -0500 Message-ID: <20260228173244.1509663-238-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ren=C3=A9 Rebe [ Upstream commit 3cd9763ce4ad999d015cf0734e6b968cead95077 ] Building a size optimized ppc64 kernel (-Os), gcc emits more FP save/restore symbols, that the linker generates on demand into the .sfpr section. Explicitly allow-list those in scripts/mod/modpost.c, too. They are needed for the amdgpu in-kernel floating point support. MODPOST Module.symvers ERROR: modpost: "_restfpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefi= ned! ERROR: modpost: "_restfpr_26" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefi= ned! ERROR: modpost: "_restfpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefi= ned! ERROR: modpost: "_savegpr1_27" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undef= ined! ERROR: modpost: "_savegpr1_25" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undef= ined! ERROR: modpost: "_restfpr_28" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefi= ned! ERROR: modpost: "_savegpr1_29" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undef= ined! ERROR: modpost: "_savefpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefi= ned! ERROR: modpost: "_savefpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefi= ned! ERROR: modpost: "_restfpr_15" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefi= ned! WARNING: modpost: suppressed 56 unresolved symbol warnings because there we= re too many) Signed-off-by: Ren=C3=A9 Rebe Link: https://patch.msgid.link/20251123.131330.407910684435629198.rene@exac= tco.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- scripts/mod/modpost.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 755b842f1f9b7..88ad227f87cd1 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -602,6 +602,10 @@ static int ignore_undef_symbol(struct elf_info *info, = const char *symname) /* Special register function linked on all modules during final link of = .ko */ if (strstarts(symname, "_restgpr0_") || strstarts(symname, "_savegpr0_") || + strstarts(symname, "_restgpr1_") || + strstarts(symname, "_savegpr1_") || + strstarts(symname, "_restfpr_") || + strstarts(symname, "_savefpr_") || strstarts(symname, "_restvr_") || strstarts(symname, "_savevr_") || strcmp(symname, ".TOC.") =3D=3D 0) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 194AF390F9E; Sat, 28 Feb 2026 17:36:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300218; cv=none; b=TqBRtsMP4J4t3vgBRRd9st9YuXvHtKodsCAySc2IaMtnaE8O4Aro+NJgZk0JyuNUewKCbI+YZrbBWNLE5fBkRzWi3MLLiUspkwQBN3fxGycwXNX1VJiL6eWklsyWebKUNTh0KT3CjpmvOITZ0aFNk8YLjnl9WN9fn+j2aSDQhpo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300218; c=relaxed/simple; bh=VOUULQOwwW+FhF7aXxZ7sghdhXsSCejxAEKrmsOSmFA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Yg4n6oAvcnBVG/6bdkY6GoTC7rk8ozvTcaPU9n76ySmTknl5UpAUpOvjdpuiLdaqepECA3nb1E4oqH16SKEFacBwcNGdsvG/Vi4feFYXmn6j5mDvBgFzTnsx5/cQQJi2uiGKzd+6nCi8bw9FlR3vKZMh/ttYgqySMR1NU1WBrYM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TIDVg9bY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TIDVg9bY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 644E8C116D0; Sat, 28 Feb 2026 17:36:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300218; bh=VOUULQOwwW+FhF7aXxZ7sghdhXsSCejxAEKrmsOSmFA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TIDVg9bYoUsR2WvnwSV7fRdwBaB7r2653JSXdXJmu/NNsNNaFqmFaKRnZyBLla/+3 0Actd7ciiTt49tcJ41YNfQdeASYsFmoTKkL5v+l9FITjXAPfp/LQi1bVIYAxbxYhrn uG0aW0hRm/rpCfSaWuu2Z/4cSxhCF4CWvuQ6OC/3eZYzHjDfWC5GaZDwkoXEzOTNGj XqAwJ6avlztbadNP7d8bcmJ66WStFrj9YFUjzbIkEf7kqiykXHOyNckccdM+NZzEbp +CPy0eDUcEHksSCUZjlNPkSWIOSGQCVv044I7uBhL3lw57vf3YDbNK1jBpkJKxf+s8 1qN9OAVNEldkg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?C=C3=A9dric=20Bellegarde?= , Mark Brown , Sasha Levin Subject: [PATCH 6.19 238/844] ASoC: qcom: q6asm: drop DSP responses for closed data streams Date: Sat, 28 Feb 2026 12:22:31 -0500 Message-ID: <20260228173244.1509663-239-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: C=C3=A9dric Bellegarde [ Upstream commit 8a066a81ee0c1b6cdbd81393536c3b2d19ccef25 ] 'Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responses after closing")' attempted to ignore DSP responses arriving after a stream had been closed. However, those responses were still handled, causing lockups. Fix this by unconditionally dropping all DSP responses associated with closed data streams. Signed-off-by: C=C3=A9dric Bellegarde Link: https://patch.msgid.link/20260102215225.609166-1-cedric.bellegarde@ad= ishatz.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/qcom/qdsp6/q6asm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/qcom/qdsp6/q6asm.c b/sound/soc/qcom/qdsp6/q6asm.c index e7295b7b24610..3c4a24c9dba22 100644 --- a/sound/soc/qcom/qdsp6/q6asm.c +++ b/sound/soc/qcom/qdsp6/q6asm.c @@ -638,7 +638,6 @@ static int32_t q6asm_stream_callback(struct apr_device = *adev, client_event =3D ASM_CLIENT_EVENT_CMD_OUT_FLUSH_DONE; break; case ASM_STREAM_CMD_OPEN_WRITE_V3: - case ASM_DATA_CMD_WRITE_V2: case ASM_STREAM_CMD_OPEN_READ_V3: case ASM_STREAM_CMD_OPEN_READWRITE_V2: case ASM_STREAM_CMD_SET_ENCDEC_PARAM: @@ -657,8 +656,9 @@ static int32_t q6asm_stream_callback(struct apr_device = *adev, break; case ASM_DATA_CMD_EOS: case ASM_DATA_CMD_READ_V2: + case ASM_DATA_CMD_WRITE_V2: /* response as result of close stream */ - break; + goto done; default: dev_err(ac->dev, "command[0x%x] not expecting rsp\n", result->opcode); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 018D5391890; Sat, 28 Feb 2026 17:36:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300219; cv=none; b=qfbgauisBUyN9x7V6RvBDXpPTkuICpOpisS1vYccw2VB42ImBtSrtJwKkmSEI7Nc/OUJ2qOcp8TESy1yXOwgvQid3p7rY7LfazAkpkUNIOUagcEmOB3yJs6FdwNNO1sJXMPtj4N/rCTLYlVTjFtTPUP5DeyWEvC4zKZq/DllJ6E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300219; c=relaxed/simple; bh=kuip02XYYUcT7Wff0IA+vk3H5TdO8JVrUUmowrLODW8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LLHBsErdI6iqULmoPDkcUDt+XZe1T1S5wqRot+Sor4+iOpbpZwqRRyhX80WcRG3KXGfaNLcFG1YTz6PSbAA+dcDt7Yogq/Q7jpwiFoBoZhxDDanLCUwsJ3ge4keRNe7b3DNA9HZmsKrPyI/R8Mf7eWoxqEe+QvQYh7DR1wHrh14= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bXi6gh+E; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bXi6gh+E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F1E9C116D0; Sat, 28 Feb 2026 17:36:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300218; bh=kuip02XYYUcT7Wff0IA+vk3H5TdO8JVrUUmowrLODW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bXi6gh+Esnq7j9rFXVmLzCZ9Nw/kq2I+uN43FDlsiwLpJWRw6GUUBWxpN5fI+Qikp Z8x9KakJZaMun/kd+V4iuVkfVF5RpeRGOBq8V91/GhV9b/5pGWbkXRBFGxwiqeVPQK jC0ajJcc5Rr6+vvNc2pv2yHsGow2S6h/jMoVEu7ITbxveaqCj2wVRpE3NozoPso8JC g5eCS58y+HTIH3ValG8B03BqiLBpuVIdT9kowMAtx1GwtIUvUyNtkpUHh1lg5W+muw G+/T9NJCgDzb3tuGc3p8gmnD8Sl32upYf65FwmxvJYUwGjY4uE7wXJuvxlZ5B0RkDP obGbNEjqKYf4Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ziyi Guo , Bartosz Golaszewski , Sasha Levin Subject: [PATCH 6.19 239/844] power: sequencing: fix missing state_lock in pwrseq_power_on() error path Date: Sat, 28 Feb 2026 12:22:32 -0500 Message-ID: <20260228173244.1509663-240-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ziyi Guo [ Upstream commit e1dccb485c2876ac1318f36ccc0155416c633a48 ] pwrseq_power_on() calls pwrseq_unit_disable() when the post_enable callback fails. However, this call is outside the scoped_guard(mutex, &pwrseq->state_lock) block that ends. pwrseq_unit_disable() has lockdep_assert_held(&pwrseq->state_lock), which will fail when called from this error path. Add the scoped_guard block to cover the post_enable callback and its error handling to ensure the lock is held when pwrseq_unit_disable() is called. Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260130182651.1576579-1-n7l8m4@u.northweste= rn.edu Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/power/sequencing/core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/power/sequencing/core.c b/drivers/power/sequencing/cor= e.c index 190564e559885..1fcf0af7cc0bb 100644 --- a/drivers/power/sequencing/core.c +++ b/drivers/power/sequencing/core.c @@ -914,8 +914,10 @@ int pwrseq_power_on(struct pwrseq_desc *desc) if (target->post_enable) { ret =3D target->post_enable(pwrseq); if (ret) { - pwrseq_unit_disable(pwrseq, unit); - desc->powered_on =3D false; + scoped_guard(mutex, &pwrseq->state_lock) { + pwrseq_unit_disable(pwrseq, unit); + desc->powered_on =3D false; + } } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B4A93918B4; Sat, 28 Feb 2026 17:37:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300220; cv=none; b=I0Yacqoz+/E/sLtIivRqXepovewEmPzbL1G9GCFKipcWWp/Jb39RxV24++52rHAzIzfmpV7haECB/QcRK2t++PZ3ZKRan7wC3y0kg/zd4wcpSQ+0cq8mqM+c9+TYdiPDG4HpZ0DOLjBFTV2z6ENV92p/Jttjxnuh9L08IktqCV8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300220; c=relaxed/simple; bh=HBtUASG2A6midTqyxuI2ibO+q8ZfngpiNs8bogOQx8g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N2wnMB+NqNupqGDGPw+HzYLUUnFU9DA+wZ7RPU8dygQLIDXFOvPMyYoqwvupc88oN2ZiisdEfLqmtFh59qZ1kof2eZKDifeF+rhkUiZSHExfkuoE9TB0Hn/gWqMcvVHHpkxtqXhHJ4wLs+PkM/iPct+FAY53iDqJdKKTc6V2r3w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Cr7/DPl9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Cr7/DPl9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E377C2BC87; Sat, 28 Feb 2026 17:36:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300220; bh=HBtUASG2A6midTqyxuI2ibO+q8ZfngpiNs8bogOQx8g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Cr7/DPl9WL/F1fEQIbgdCU4fr1Sn2Ku9Ro9Q+DqEeAf8dghHxEkjKD8HdcDwMBYsB PysvOcPxG9r1tswwXZcNoUWm49KmGfKQ6TnKBiFPIYybOIdisGssbZYRGbfvidCKWB 5l49scfcRDm2g8gEW+3EDP2XkjgPFYv9FPT+Q5uOE5bger3rkMQzI+UAI2OLlpMCLA 7Lz9u8YnaW1P72+TgWQdoXQdJUEKXUlQ7KS5Pzg39fdvCFUmt7CmeREtvWTiyz9+dX Ghx48eJu/esCA6hnw2AnXS+0JJpsbyjWA7LtNkq77DhGEOg9CRqg7bh+qfKMfHUo2a 9p7OkgttqLjAA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ranjani Sridharan , Bard Liao , Liam Girdwood , Mateusz Redzynia , Peter Ujfalusi , Mark Brown , Sasha Levin Subject: [PATCH 6.19 240/844] ASoC: SOF: Intel: hda: Fix NULL pointer dereference Date: Sat, 28 Feb 2026 12:22:33 -0500 Message-ID: <20260228173244.1509663-241-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ranjani Sridharan [ Upstream commit 16c589567a956d46a7c1363af3f64de3d420af20 ] If there's a mismatch between the DAI links in the machine driver and the topology, it is possible that the playback/capture widget is not set, especially in the case of loopback capture for echo reference where we use the dummy DAI link. Return the error when the widget is not set to avoid a null pointer dereference like below when the topology is broken. RIP: 0010:hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common] Signed-off-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Mateusz Redzynia Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260204081833.16630-10-peter.ujfalusi@linux= .intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/sof/intel/hda-dai.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/intel/hda-dai.c b/sound/soc/sof/intel/hda-dai.c index 883d0d3bae9ec..3c742d5351333 100644 --- a/sound/soc/sof/intel/hda-dai.c +++ b/sound/soc/sof/intel/hda-dai.c @@ -70,12 +70,22 @@ static const struct hda_dai_widget_dma_ops * hda_dai_get_ops(struct snd_pcm_substream *substream, struct snd_soc_dai *c= pu_dai) { struct snd_soc_dapm_widget *w =3D snd_soc_dai_get_widget(cpu_dai, substre= am->stream); - struct snd_sof_widget *swidget =3D w->dobj.private; + struct snd_sof_widget *swidget; struct snd_sof_dev *sdev; struct snd_sof_dai *sdai; =20 - sdev =3D widget_to_sdev(w); + /* + * this is unlikely if the topology and the machine driver DAI links matc= h. + * But if there's a missing DAI link in topology, this will prevent a NUL= L pointer + * dereference later on. + */ + if (!w) { + dev_err(cpu_dai->dev, "%s: widget is NULL\n", __func__); + return NULL; + } =20 + sdev =3D widget_to_sdev(w); + swidget =3D w->dobj.private; if (!swidget) { dev_err(sdev->dev, "%s: swidget is NULL\n", __func__); return NULL; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2160447ECF5; Sat, 28 Feb 2026 17:37:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300221; cv=none; b=ubLjJN67xeEaZSsDF5AYMfZdeuvdhFWEm99oZDDYFVcffKLjcbfk5C7Xj4alsITPUwCWbAKUCjXb58lBA63+4ShA0c0fvlMaE3NVkH0HuMj8JETi/3VJM10M8sYn4bDag4SUmGzltPBeoteR0lcEwWHK7el62lrPc1Ip+c1eH1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300221; c=relaxed/simple; bh=9DePG+3ApJLWUkuXD2BkxLNtgVIC0JyRLY+gVS8vJo4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qEYjw7c07qwqTdykxG3iuACy5w1ur9s6JRiPopGWhPcD0yPSI6anlxgHaG9F/dNigW6xdIykNQOd2jg0iO54D3Vn/VYupmaE8ecAwwKRlSzj/q+SV4igVucKCDLYyF+21Xd6Z6ahUCNrgPjMMSebS/ISCcEx3vzg2Jwwqbp15hQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EORSqVAz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EORSqVAz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 529BBC2BC87; Sat, 28 Feb 2026 17:37:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300221; bh=9DePG+3ApJLWUkuXD2BkxLNtgVIC0JyRLY+gVS8vJo4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EORSqVAzmXAe46sm31kE4d/8ZsPNCGPdeU1ANOzeW5JF0mm2gCd6QFOaP+YWkyiB2 FU+B8UKdicPRh8F3tVLCn9bT/DJ7fnBxo2z9ozCMrROojIl8qAApduM0S94AGQEU6t JNvy9IxMGofSpN1pt63L5nCsuPMyUUA/OeUhV9z0KFUiLyLlorIMkH+L1os70PMF7H vLrjAnwdsXJO5GfbXiO1PCDUCEwUdgrtZg22WXOKZYtP3FObQfDo2ba889AvPRIMcp 6Z8OHP0KrysttrMtHQ1DuFFaTTVvahM2w2NJxuta/wslHaCc8epV5gN0zZWz3l2I2r Ccbigfp4wSszw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Praveen Talari , Konrad Dybcio , Mark Brown , Sasha Levin Subject: [PATCH 6.19 241/844] spi: geni-qcom: Fix abort sequence execution for serial engine errors Date: Sat, 28 Feb 2026 12:22:34 -0500 Message-ID: <20260228173244.1509663-242-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Praveen Talari [ Upstream commit 96e041647bb0f9d92f95df1d69cb7442d7408b79 ] The driver currently skips the abort sequence for target mode when serial engine errors occur. This leads to improper error recovery as the serial engine may remain in an undefined state without proper cleanup, potentially causing subsequent operations to fail or behave unpredictably. Fix this by ensuring the abort sequence and DMA reset always execute during error recovery, as both are required for proper serial engine error handling. Co-developed-by: Konrad Dybcio Signed-off-by: Konrad Dybcio Signed-off-by: Praveen Talari Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260204162854.1206323-3-praveen.talari@oss.= qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spi-geni-qcom.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c index 5ab20d7955121..acfcf870efd84 100644 --- a/drivers/spi/spi-geni-qcom.c +++ b/drivers/spi/spi-geni-qcom.c @@ -160,24 +160,20 @@ static void handle_se_timeout(struct spi_controller *= spi, xfer =3D mas->cur_xfer; mas->cur_xfer =3D NULL; =20 - if (spi->target) { - /* - * skip CMD Cancel sequnece since spi target - * doesn`t support CMD Cancel sequnece - */ + /* The controller doesn't support the Cancel commnand in target mode */ + if (!spi->target) { + reinit_completion(&mas->cancel_done); + geni_se_cancel_m_cmd(se); + spin_unlock_irq(&mas->lock); - goto reset_if_dma; - } =20 - reinit_completion(&mas->cancel_done); - geni_se_cancel_m_cmd(se); - spin_unlock_irq(&mas->lock); + time_left =3D wait_for_completion_timeout(&mas->cancel_done, HZ); + if (time_left) + goto reset_if_dma; =20 - time_left =3D wait_for_completion_timeout(&mas->cancel_done, HZ); - if (time_left) - goto reset_if_dma; + spin_lock_irq(&mas->lock); + } =20 - spin_lock_irq(&mas->lock); reinit_completion(&mas->abort_done); geni_se_abort_m_cmd(se); spin_unlock_irq(&mas->lock); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1229436C9D7; Sat, 28 Feb 2026 17:37:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300222; cv=none; b=BpVjUgHuL50QA70FCXVMaYWizhw9nHDGGxWaFwu5hi9DWp0bzR4bt770aaq6AfZGAXkfJBp8077cxDguIqAxDfHS8FjW6BbB0RWM6Ojhws+HoV4CpfMPGO8kgK+YZhE1fP0h7hQlGh1VWTZPXaIIU/uvGEhg5hrdv8MlBQ70uBg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300222; c=relaxed/simple; bh=54uQwz80pIXJ6OnW5YNcTQCjGlRG3Xp7DvVpzKwXEs4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qumqs+OhHlS+YURg677PcMfHrNJTwtyjdS70kBstvUCpJvWaObtaeRkVGTeG1CjRCgUFZRptXIqOPt5ap7Y395xVW2TCVKS5QqBH/HF0f1tXMD9j6ZliPHlJcAFbRKnyLRD4uPoAOx9fOEcCNTc50vgsa3liej5LY2CFA/WACXY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZGQPnWsA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZGQPnWsA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48671C2BC87; Sat, 28 Feb 2026 17:37:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300222; bh=54uQwz80pIXJ6OnW5YNcTQCjGlRG3Xp7DvVpzKwXEs4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZGQPnWsABNG77AjLRqrZlFkLzLy4HetH/m5tDNYSRLAVESUhcfvfatMlnono7dB07 w8PvOLmaUYpHNv7tQp2KhE2a7bgPVYsSjIyjUG+YaQXG9vilqPuB/6GGlIU5obVvjY H3c1hOdLaTo9O0WUHvI+FcBJGXotn9DI5Fb8CTJ2JhDu9w7OzyEOzz5avO0j+GYXDU e4fXvZlowimkjw3gnuYUVj4u89fmeUSn/ZsO0HUEEOkY0Jh76W62CROu6bilN8mkN7 B8RJAZp5K304SIOQIxPEnENMlLxky1mDTNEmlSf8ZXu76svKmxmfGYuv5iTQznVzjb WvN64hdreU6GA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ziyi Guo , Frank Li , Mark Brown , Sasha Levin Subject: [PATCH 6.19 242/844] ASoC: fsl: imx-rpmsg: use snd_soc_find_dai_with_mutex() in probe Date: Sat, 28 Feb 2026 12:22:35 -0500 Message-ID: <20260228173244.1509663-243-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ziyi Guo [ Upstream commit 84faa91585fa22a161763f2fe8f84a602a196c87 ] imx_rpmsg_probe() calls snd_soc_find_dai() without holding client_mutex. However, snd_soc_find_dai() has lockdep_assert_held(&client_mutex) indicating callers must hold this lock, as the function iterates over the global component list. All other callers of snd_soc_find_dai() either hold client_mutex via the snd_soc_bind_card() path or use the snd_soc_find_dai_with_mutex() wrapper. Use snd_soc_find_dai_with_mutex() instead to fix the missing lock protection. Signed-off-by: Ziyi Guo Reviewed-by: Frank Li Link: https://patch.msgid.link/20260205052429.4046903-1-n7l8m4@u.northweste= rn.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/fsl/imx-rpmsg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/imx-rpmsg.c b/sound/soc/fsl/imx-rpmsg.c index 53f04d1f32806..76a8e68c1b620 100644 --- a/sound/soc/fsl/imx-rpmsg.c +++ b/sound/soc/fsl/imx-rpmsg.c @@ -145,7 +145,7 @@ static int imx_rpmsg_probe(struct platform_device *pdev) data->dai.ignore_pmdown_time =3D 1; =20 data->dai.cpus->dai_name =3D pdev->dev.platform_data; - cpu_dai =3D snd_soc_find_dai(data->dai.cpus); + cpu_dai =3D snd_soc_find_dai_with_mutex(data->dai.cpus); if (!cpu_dai) { ret =3D -EPROBE_DEFER; goto fail; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE4C436C9F3; Sat, 28 Feb 2026 17:37:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300222; cv=none; b=n0eJzumJCgv9qod613hiE/Qqf0LNuNUlgVbBkTfDPrZBIf2AT6sQqnUnBJOehWCcByp3ePd38jwENnSgCwywbOyXTYlmJuH6lKEHXtsz5UOTuw6jg/PxJXxL6nk+A+8ZWqMZaFbHyS9lMh7j3kAkcn0yxE1PJm8DMwVhBEs+i0w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300222; c=relaxed/simple; bh=wW3ULmAtSumJmGoZuT2w468/2kPh9PHltumcfbMtRxQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ThnyH/Fll05C/Qo0l4xPZsyrRH1CKw75EapBGG0PEaMrzScpBS4qSAprlBGfOFP9xecISsIFmjhksgCqpq5I2tBh1leI+8oIhzgAD8RSOZMTdF0k/ZQfGFqlUsZjCNpL6WFU/O1VxzjmoseRrqCJe55RDrRstCLD5EgywBuqnlQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g3KLeTgt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g3KLeTgt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3804DC19425; Sat, 28 Feb 2026 17:37:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300222; bh=wW3ULmAtSumJmGoZuT2w468/2kPh9PHltumcfbMtRxQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g3KLeTgtOSnJKEpnTgLot7HfXYWn3h3F8QgpmBx8lZ3osrmTobQV3tJSaU9tZi5h4 gP8Lg04sLbZ7p22+LAEBKW0EYH7Lf4UNvhkPjDVN6ptKYJqAIrdjAvsLCHZuu5CdwE 9ZUMpQX4gSXls2LFYELFjhQYr7yBT1n7Mju5KU3lgN/1Y4vQNn+xY+hm1c2XQArYnu y3ISx2zV2Rknqbz3aoMcZGx4GGw7Gf0/N0RsJGPdEqVAsqy1cNfD4w5+0Ds52KCuRx SrrC7+2O0SHUkWBPsKihEA9nlRu/t6XVoLiXz/dyKzuYDzuSkgAPT+H9/YS0+3pLI2 tHbovy2AF/imQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Illia Barbashyn <04baril@gmail.com>, Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 243/844] ALSA: hda/realtek - Enable mute LEDs on HP ENVY x360 15-es0xxx Date: Sat, 28 Feb 2026 12:22:36 -0500 Message-ID: <20260228173244.1509663-244-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Illia Barbashyn <04baril@gmail.com> [ Upstream commit ac1ff574bbc09a6c90f4fe8f9e6b8d66c983064c ] The mute and mic-mute LEDs on HP ENVY x360 Convertible 15-es0xxx (PCI SSID 103c:88b3) do not work with the current driver. This model requires a combination of COEFBIT and GPIO fixups to correctly control the LEDs. Introduce a new fixup function alc245_fixup_hp_envy_x360_mute_led and add a quirk to apply it. Signed-off-by: Illia Barbashyn <04baril@gmail.com> Link: https://patch.msgid.link/20260207221955.24132-1-04baril@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/hda/codecs/realtek/alc269.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/a= lc269.c index 82219f03b212c..c11312aa5ca76 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -1660,6 +1660,13 @@ static void alc285_fixup_hp_spectre_x360_mute_led(st= ruct hda_codec *codec, alc285_fixup_hp_gpio_micmute_led(codec, fix, action); } =20 +static void alc245_fixup_hp_envy_x360_mute_led(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + alc245_fixup_hp_mute_led_v1_coefbit(codec, fix, action); + alc245_fixup_hp_gpio_led(codec, fix, action); +} + static void alc236_fixup_hp_mute_led(struct hda_codec *codec, const struct hda_fixup *fix, int action) { @@ -3919,6 +3926,7 @@ enum { ALC285_FIXUP_HP_GPIO_LED, ALC285_FIXUP_HP_MUTE_LED, ALC285_FIXUP_HP_SPECTRE_X360_MUTE_LED, + ALC245_FIXUP_HP_ENVY_X360_MUTE_LED, ALC285_FIXUP_HP_BEEP_MICMUTE_LED, ALC236_FIXUP_HP_MUTE_LED_COEFBIT2, ALC236_FIXUP_HP_GPIO_LED, @@ -5575,6 +5583,10 @@ static const struct hda_fixup alc269_fixups[] =3D { .type =3D HDA_FIXUP_FUNC, .v.func =3D alc285_fixup_hp_spectre_x360_mute_led, }, + [ALC245_FIXUP_HP_ENVY_X360_MUTE_LED] =3D { + .type =3D HDA_FIXUP_FUNC, + .v.func =3D alc245_fixup_hp_envy_x360_mute_led, + }, [ALC285_FIXUP_HP_BEEP_MICMUTE_LED] =3D { .type =3D HDA_FIXUP_FUNC, .v.func =3D alc285_fixup_hp_beep, @@ -6848,6 +6860,7 @@ static const struct hda_quirk alc269_fixup_tbl[] =3D { SND_PCI_QUIRK(0x103c, 0x8895, "HP EliteBook 855 G8 Notebook PC", ALC285_F= IXUP_HP_SPEAKERS_MICMUTE_LED), SND_PCI_QUIRK(0x103c, 0x8896, "HP EliteBook 855 G8 Notebook PC", ALC285_F= IXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x8898, "HP EliteBook 845 G8 Notebook PC", ALC285_F= IXUP_HP_LIMIT_INT_MIC_BOOST), + SND_PCI_QUIRK(0x103c, 0x88b3, "HP ENVY x360 Convertible 15-es0xxx", ALC24= 5_FIXUP_HP_ENVY_X360_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x88d0, "HP Pavilion 15-eh1xxx (mainboard 88D0)", A= LC287_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x88dd, "HP Pavilion 15z-ec200", ALC285_FIXUP_HP_MU= TE_LED), SND_PCI_QUIRK(0x103c, 0x88eb, "HP Victus 16-e0xxx", ALC245_FIXUP_HP_MUTE_= LED_V2_COEFBIT), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A37F7394E01; Sat, 28 Feb 2026 17:37:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300223; cv=none; b=LtbVzGw1+QdZnLBBfw1VCJMFNVRA2yH/b1O3hHY45atTn1BO/8G3p52U5dAVUqQeepxgUEmJUPQnBDGABF5pyXxTrg236OacOPPWzkf1MB9Yuxq7zgGuIGrys1deWRQRyosA0ifaMN+GRw678TdgnYTCKEQBm5X48w0LKLUJ22s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300223; c=relaxed/simple; bh=AgNHeU7/fsv4RDKURY3GGZmyyuNmR+S/YrtV8q9lkis=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mMyM4nNy+PoBoqbCZvrDqmpSGFoGG4IZt02l3bQdLAMHvlip046ccSCzh59wjbAvjto3KNRcjuprpLixHCpjMOef3SPQwSPwl3Q9hFgNAKDS/k8ZDrFWbGmpzAzXmNmn5kmbY0qNp//MietcHEAK4zUwVHUjDtxNMAJCPkmQxRk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m25NIfD4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m25NIfD4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 106F5C116D0; Sat, 28 Feb 2026 17:37:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300223; bh=AgNHeU7/fsv4RDKURY3GGZmyyuNmR+S/YrtV8q9lkis=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m25NIfD4DXMwyB1eGqy2M2D2AMe2zV1pPbn1X9tmNOnWolpjuc1Ha+BcZPNr76XVJ PlDClRXwrxMMfq3oL18pR3fQ1MvPE3grj5dHfcC8LSjrk263QZ4N/L6RTIZVLm4308 HzdQcr3Rvw9o/wFQW6bhtalU5PmUmecGfvNwzT5WF1qI8yhISJc5HRkeMrrZziYat9 F4xHk52EmG4GB9DveHKoIsq+gAbFSHkXq4/jTUQh5+U5MEF7zLC/iXYIkh3lUbuWt3 YphPfsXwDHe6DAikCl3fFurxG9uHRyN47qNr6n0x3LydQapx47ubSMBCrfoqPxhFiM MlqbiDM/IxbOw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 244/844] ALSA: mixer: oss: Add card disconnect checkpoints Date: Sat, 28 Feb 2026 12:22:37 -0500 Message-ID: <20260228173244.1509663-245-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Takashi Iwai [ Upstream commit 084d5d44418148662365eced3e126ad1a81ee3e2 ] ALSA OSS mixer layer calls the kcontrol ops rather individually, and pending calls might be not always caught at disconnecting the device. For avoiding the potential UAF scenarios, add sanity checks of the card disconnection at each entry point of OSS mixer accesses. The rwsem is taken just before that check, hence the rest context should be covered by that properly. Link: https://patch.msgid.link/20260209121212.171430-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/core/oss/mixer_oss.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/sound/core/oss/mixer_oss.c b/sound/core/oss/mixer_oss.c index 8d2d46d03301b..f4ad0bfb4dac6 100644 --- a/sound/core/oss/mixer_oss.c +++ b/sound/core/oss/mixer_oss.c @@ -523,6 +523,8 @@ static void snd_mixer_oss_get_volume1_vol(struct snd_mi= xer_oss_file *fmixer, if (numid =3D=3D ID_UNKNOWN) return; guard(rwsem_read)(&card->controls_rwsem); + if (card->shutdown) + return; kctl =3D snd_ctl_find_numid(card, numid); if (!kctl) return; @@ -557,6 +559,8 @@ static void snd_mixer_oss_get_volume1_sw(struct snd_mix= er_oss_file *fmixer, if (numid =3D=3D ID_UNKNOWN) return; guard(rwsem_read)(&card->controls_rwsem); + if (card->shutdown) + return; kctl =3D snd_ctl_find_numid(card, numid); if (!kctl) return; @@ -618,6 +622,8 @@ static void snd_mixer_oss_put_volume1_vol(struct snd_mi= xer_oss_file *fmixer, if (numid =3D=3D ID_UNKNOWN) return; guard(rwsem_read)(&card->controls_rwsem); + if (card->shutdown) + return; kctl =3D snd_ctl_find_numid(card, numid); if (!kctl) return; @@ -656,6 +662,8 @@ static void snd_mixer_oss_put_volume1_sw(struct snd_mix= er_oss_file *fmixer, if (numid =3D=3D ID_UNKNOWN) return; guard(rwsem_read)(&card->controls_rwsem); + if (card->shutdown) + return; kctl =3D snd_ctl_find_numid(card, numid); if (!kctl) return; @@ -796,6 +804,8 @@ static int snd_mixer_oss_get_recsrc2(struct snd_mixer_o= ss_file *fmixer, unsigned if (uinfo =3D=3D NULL || uctl =3D=3D NULL) return -ENOMEM; guard(rwsem_read)(&card->controls_rwsem); + if (card->shutdown) + return -ENODEV; kctl =3D snd_mixer_oss_test_id(mixer, "Capture Source", 0); if (!kctl) return -ENOENT; @@ -839,6 +849,8 @@ static int snd_mixer_oss_put_recsrc2(struct snd_mixer_o= ss_file *fmixer, unsigned if (uinfo =3D=3D NULL || uctl =3D=3D NULL) return -ENOMEM; guard(rwsem_read)(&card->controls_rwsem); + if (card->shutdown) + return -ENODEV; kctl =3D snd_mixer_oss_test_id(mixer, "Capture Source", 0); if (!kctl) return -ENOENT; @@ -885,6 +897,8 @@ static int snd_mixer_oss_build_test(struct snd_mixer_os= s *mixer, struct slot *sl if (!info) return -ENOMEM; scoped_guard(rwsem_read, &card->controls_rwsem) { + if (card->shutdown) + return -ENODEV; kcontrol =3D snd_mixer_oss_test_id(mixer, name, index); if (kcontrol =3D=3D NULL) return 0; @@ -1006,6 +1020,8 @@ static int snd_mixer_oss_build_input(struct snd_mixer= _oss *mixer, if (snd_mixer_oss_build_test_all(mixer, ptr, &slot)) return 0; guard(rwsem_read)(&mixer->card->controls_rwsem); + if (mixer->card->shutdown) + return -ENODEV; kctl =3D NULL; if (!ptr->index) kctl =3D snd_mixer_oss_test_id(mixer, "Capture Source", 0); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FC9D394E1D; Sat, 28 Feb 2026 17:37:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300224; cv=none; b=b9ST9RWxWpvmu33XPYOcc6mCF4sZgv5BFN2121+9vFnl+9+EMA2IpasiUYOhMzY5NZFrflrSimwG9wMlBwyqTTqjbCEQYb8hIVZ4zxxqvQoiD5+uFCiiQvACGW2ltShh7M/weQoyUvqv3nJW0iw2rL34cv1zM8EM8IM9ohhhRdI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300224; c=relaxed/simple; bh=gxPyM4X4JordGtusy2n/qrvh83bBiJbA4cMFLCusdHs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UJhUjHrLtrYyKR0LUVGDwZrTgz1DEN8adVvgNbOgIGIzV1IFPtrlVMWBdCMph1tZTR1EXDex82kDQhZFk1AYT1NRkbQvcUWryYqsEMXY1aqJIiFis9DG2v3neKD0V299aBsh8CfanFyRoUugtnbAARE5I605dzyXQYiLcjE5Yxw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ERDrbgHj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ERDrbgHj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9987C19425; Sat, 28 Feb 2026 17:37:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300224; bh=gxPyM4X4JordGtusy2n/qrvh83bBiJbA4cMFLCusdHs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ERDrbgHjpfGVMdIGXPWPk1By2GkBMKDuGKVYFz7iKRw5MMT5WKtFvswfPPRBH7Lw7 3PWQqpmYJxx+IckeVN2l+6oN67DUtvsPxUa5VAXL+ALmM55lIEc8D41UBX4Miz6kg1 X23i6KY69A5IbBL5FducQjbIfuyfWJHAWNUVsrMVxTK5VB9AitoGCLxMzcQwuNXM5R senEFRh6ao5l7iQvxO1cic6V6aKfZG56adK59D1pLAKzTyQnJH3Fepku+LCiaMR4sd bF/nF9cpRU55UFFl6NufvVwULUTV5/K0lA2UZcIkrKIpEc7kWs8qzvB5Erpm18zqzl s0tBLKj+cbkNA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harin Lee , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 245/844] ALSA: ctxfi: Add quirk for SE-300PCIE variant (160b:0102) Date: Sat, 28 Feb 2026 12:22:38 -0500 Message-ID: <20260228173244.1509663-246-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harin Lee [ Upstream commit 3a92733e052753d87fdd56bd6f621f969be28447 ] Add quirk for the Onkyo SE-300PCIE variant with PCI subsystem ID (160b:0102). This variant (OK0011) was found in the official Windows driver packages. Also, reorder entries and fix the indentation to maintain consistency. Signed-off-by: Harin Lee Link: https://patch.msgid.link/20260208133001.680550-1-me@harin.net Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/pci/ctxfi/ctatc.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/sound/pci/ctxfi/ctatc.c b/sound/pci/ctxfi/ctatc.c index 227d8c8490e1f..a25a599fc5bec 100644 --- a/sound/pci/ctxfi/ctatc.c +++ b/sound/pci/ctxfi/ctatc.c @@ -52,18 +52,19 @@ static const struct snd_pci_quirk subsys_20k1_list[] = =3D { static const struct snd_pci_quirk subsys_20k2_list[] =3D { SND_PCI_QUIRK(PCI_VENDOR_ID_CREATIVE, PCI_SUBDEVICE_ID_CREATIVE_SB0760, "SB0760", CTSB0760), - SND_PCI_QUIRK(PCI_VENDOR_ID_CREATIVE, PCI_SUBDEVICE_ID_CREATIVE_SB1270, - "SB1270", CTSB1270), SND_PCI_QUIRK(PCI_VENDOR_ID_CREATIVE, PCI_SUBDEVICE_ID_CREATIVE_SB08801, "SB0880", CTSB0880), SND_PCI_QUIRK(PCI_VENDOR_ID_CREATIVE, PCI_SUBDEVICE_ID_CREATIVE_SB08802, "SB0880", CTSB0880), SND_PCI_QUIRK(PCI_VENDOR_ID_CREATIVE, PCI_SUBDEVICE_ID_CREATIVE_SB08803, "SB0880", CTSB0880), + SND_PCI_QUIRK(PCI_VENDOR_ID_CREATIVE, PCI_SUBDEVICE_ID_CREATIVE_SB1270, + "SB1270", CTSB1270), + SND_PCI_QUIRK(0x160b, 0x0101, "OK0010", CTOK0010), + SND_PCI_QUIRK(0x160b, 0x0102, "OK0010", CTOK0010), SND_PCI_QUIRK_MASK(PCI_VENDOR_ID_CREATIVE, 0xf000, PCI_SUBDEVICE_ID_CREATIVE_HENDRIX, "HENDRIX", CTHENDRIX), - SND_PCI_QUIRK(0x160b, 0x0101, "OK0010", CTOK0010), { } /* terminator */ }; =20 @@ -78,8 +79,8 @@ static const char *ct_subsys_name[NUM_CTCARDS] =3D { [CTSB0760] =3D "SB076x", [CTHENDRIX] =3D "Hendrix", [CTSB0880] =3D "SB0880", - [CTSB1270] =3D "SB1270", - [CTOK0010] =3D "OK0010", + [CTSB1270] =3D "SB1270", + [CTOK0010] =3D "OK0010", [CT20K2_UNKNOWN] =3D "Unknown", }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66D78394E39; Sat, 28 Feb 2026 17:37:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300225; cv=none; b=JUjktgJqBvaOEb0u4HPjEYDH57/s0T05Dv5KqKb+Tb+EZGSLXVk+dlAgbeYiswgjhb+eUk7x1Y4510HDV0aYI6EkwPXy52O6PYDCMxCWEqs/wsS5gw0gXkj+512tjsU3Kmt5XIBx8bJuv2NPbUrwZ9FXBJ0QUjQns9Lu9Zga50w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300225; c=relaxed/simple; bh=/yZCBkpeV0BRKG6Vz2LJomJytJ3XnnRPg8lfsfyM9Vs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lWGwlwl7YrK9D0H7k2yULCYCZwnUwNhLJHiuxza6f9F33HESMQFp3hiD6/Ri7kZk8dEZApDhR4rIMONLU8ESj//AjCspPA2SoAJzYA4U1pOgq2yGHRyRhYkevBd0TZnQD951Lc5lNPL4U1DozU7DkFAS1dg+UL1vTGvQp9PSiPc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XD8JYPZT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XD8JYPZT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6CF0C19423; Sat, 28 Feb 2026 17:37:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300225; bh=/yZCBkpeV0BRKG6Vz2LJomJytJ3XnnRPg8lfsfyM9Vs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XD8JYPZTGqZeJKrsyPQUijd8gsQwJ5GdVMiOS7EUsvi70bjNEKK3H3g4NooXwxa3t DjQwSfxs28hD1BlYnszxxwiXjXz1aI2r8f4aCnMphGo9f6AvRV4uOWaUZONWnisw2o EuYt146Pz+TVqZMmV4/peZFjbn1xSy1VDSLZkwghmo149KDlU3IVZclyUI9VfpZft7 BQozSXrF9zC0xXdQ8qoA6QsC3wnhw2qRocpYq/CBoUgkEetzGwRW444ReSE/ys606i 9etcSsHJZih8QY+AeNoH5fD0gssDoaLIy0Nh3Ui4Q/PD/vl3T3a+J3781HJfeByh3v m+0LzbaStmDcg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Qihang Guo , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 246/844] ALSA: usb-audio: Add DSD support for iBasso DC04U Date: Sat, 28 Feb 2026 12:22:39 -0500 Message-ID: <20260228173244.1509663-247-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Qihang Guo [ Upstream commit fe7cd89f0e29f0852316857b4861309f9b891370 ] Vendor ID 0x0661 is assigned to Hamamatsu Photonics K.K., but is used by iBasso for iBasso DC04U (0x0661:0x0883), which supports native DSD playback. This patch adds QUIRK_FLAG_DSD_RAW for iBasso DC04U, enabling native DSD playback (DSD_U32_BE). The change has been verified on Arch Linux using mpd and pw-cat. Signed-off-by: Qihang Guo Link: https://patch.msgid.link/TYYPR01MB14098529E0BD900921BE6F42CF465A@TYYP= R01MB14098.jpnprd01.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/usb/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index 4f9d19bf1ccac..7fabaeb3781a2 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -2235,6 +2235,8 @@ static const struct usb_audio_quirk_flags_table quirk= _flags_table[] =3D { DEVICE_FLG(0x0644, 0x806c, /* Esoteric XD */ QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY | QUIRK_FLAG_IFACE_DELAY | QUIRK_FLAG_FORCE_IFACE_RESET), + DEVICE_FLG(0x0661, 0x0883, /* iBasso DC04 Ultra */ + QUIRK_FLAG_DSD_RAW), DEVICE_FLG(0x06f8, 0xb000, /* Hercules DJ Console (Windows Edition) */ QUIRK_FLAG_IGNORE_CTL_ERROR), DEVICE_FLG(0x06f8, 0xd002, /* Hercules DJ Console (Macintosh Edition) */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 383F3395B65; Sat, 28 Feb 2026 17:37:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300226; cv=none; b=CZuSiNFwd118a7aPoOXTyJGYsNyKNFlxd8FdlgCOme7PnzZJ+CEHEJV2xhNkyYRAUPVBeyXPAjnj/hpALS9H3LL4e+2T72VSnVlIsmgWMVb4jYfAIDD6VwK7CipttdIN+XEd9X6yMuLdLiHHnoSA+67THjYh0932tOHdjHgJ0jw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300226; c=relaxed/simple; bh=6cByhZIvmeZBiTyBxKSnmX8affQe08Fb3O+dT5u/7HI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QVuRjjC1OvmuKK3OCmhukGYmo6sAeOhoShJl4Vn/r+cxlEz1CzfSLryBY/vVVXohg5kos1AYce+TCS/AxTBywWVLmhq5n1QtTKKQkJINIwS/kfRYJholssSKHlPQzucUY0AzlRCawpheh6ENSMBLC3eAIDb1HUu8GW/AK5CvyeA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UwrAef1e; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UwrAef1e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83F4BC116D0; Sat, 28 Feb 2026 17:37:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300226; bh=6cByhZIvmeZBiTyBxKSnmX8affQe08Fb3O+dT5u/7HI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UwrAef1ePWpjbPY+WbaBWIHlVOPnm6q+zr/XimTRlRm5ZUT21awXXjwE/DidfdQyQ Bup5iYGPJubWVireCBpRHfBHX0/rSiWEvs2OemKhbe0m0dOwzO4HMzz/iVhasfNShz iSpmFkB2DANHTIsZAItUF2zH68KVlYVFo8kji/a+YITR8LptNliCMaNP7yU7xb7ezV +qXefh385BcLRMGxJB+KF78tjDQXex62KnGnJQAaatjABNqGrNMNk/3xj8/yZBUE4q I98Q4Ao+TqCGpyg2o7VBgMpjOOeINzqKqkyD2M1w15M+SCdfsC9KPkPVRSYDqPLAfJ eMOndgOi7jLXA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lianqin Hu , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 247/844] ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio Date: Sat, 28 Feb 2026 12:22:40 -0500 Message-ID: <20260228173244.1509663-248-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lianqin Hu [ Upstream commit ac656d7d7c70f7c352c7652bc2bb0c1c8c2dde08 ] Setting up the interface when suspended/resumeing fail on this card. Adding a reset and delay quirk will eliminate this problem. usb 1-1: New USB device found, idVendor=3D001f, idProduct=3D0b21 usb 1-1: New USB device strings: Mfr=3D1, Product=3D2, SerialNumber=3D3 usb 1-1: Product: AB13X USB Audio usb 1-1: Manufacturer: Generic usb 1-1: SerialNumber: 20210926172016 Signed-off-by: Lianqin Hu Link: https://patch.msgid.link/TYUPR06MB6217522D0DB6E2C9DF46B56ED265A@TYUPR= 06MB6217.apcprd06.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/usb/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index 7fabaeb3781a2..86c329632e396 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -2146,6 +2146,8 @@ struct usb_audio_quirk_flags_table { =20 static const struct usb_audio_quirk_flags_table quirk_flags_table[] =3D { /* Device matches */ + DEVICE_FLG(0x001f, 0x0b21, /* AB13X USB Audio */ + QUIRK_FLAG_FORCE_IFACE_RESET | QUIRK_FLAG_IFACE_DELAY), DEVICE_FLG(0x03f0, 0x654a, /* HP 320 FHD Webcam */ QUIRK_FLAG_GET_SAMPLE_RATE | QUIRK_FLAG_MIC_RES_16), DEVICE_FLG(0x041e, 0x3000, /* Creative SB Extigy */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1443A395B7A; Sat, 28 Feb 2026 17:37:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300227; cv=none; b=FkjImo2Qi8IjQt8vv5RohPRPIsbW2//L88pcNPFvYkqWkchqRu7VVZuOtr0PMEFlUgwCIk46b4GHBxBAyBwhrVW/LmyQCyod/AZLg1Wkik05iz0m8aragjja9KF39R3xYM9x16pCHHDAhUmZbAN0Z0Zz51Pu/srAOcPIkw5DwFs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300227; c=relaxed/simple; bh=LyZ/27qtiTLH0I9CxW4AZjmAEqEIB2XWjddTJGCZlFQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bRb+Xpsig5A6YTRN9cy13D4WUWpEw0JRMpcgarhpOcUniURHOQ48IUPccLBiaZ1jUMgKZoqK85LbWAnJ+ebXXQ2MgLyKTzYff6XDeAMFW7NhLBFFPM0Wu5vc0ihxSg09yuLayXcIsJGp8MaDIKziE6JU/AgIeuoVwW3ObIXRN4c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R7418eiy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R7418eiy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5EE1BC116D0; Sat, 28 Feb 2026 17:37:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300227; bh=LyZ/27qtiTLH0I9CxW4AZjmAEqEIB2XWjddTJGCZlFQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R7418eiyEN1UZdKOzG8ymEHH/S94Fe+sAbKBV0kF9aaDzcjuLyiR7CRmULrph0mg7 nIZAJzK0eTlQ2ovBB2kuPvR9uUR6oUW+NwCKdagmlnW6akofZap8hMlhib+sQD+3Lb JYRzTJvZA6QpdTi4GgiQFw2QZlMqmX3sDF1/kcnF4zcsDAWYD8c2+ZUfy9+gd74+Nj SHENqzPmRQNvqco4htT7otvr4l+2yux3UhYSw1jg5uGElApssRjqZL5ZKNYU3h9s5x L2A9z7JWEBWG8NLn+2o5CyxObCO07S+4xlSUmvFD53S+cQtmJq02BfpMSwCbXrIMv3 kuIiKn15HRyZA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haotian Zhang , Dave Kleikamp , Sasha Levin Subject: [PATCH 6.19 248/844] jfs: Add missing set_freezable() for freezable kthread Date: Sat, 28 Feb 2026 12:22:41 -0500 Message-ID: <20260228173244.1509663-249-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haotian Zhang [ Upstream commit eb0cfcf265714b419cc3549895a00632e76732ae ] The jfsIOWait() thread calls try_to_freeze() but lacks set_freezable(), causing it to remain non-freezable by default. This prevents proper freezing during system suspend. Add set_freezable() to make the thread freezable as intended. Signed-off-by: Haotian Zhang Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/jfs/jfs_logmgr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c index b343c5ea11592..5b1c5da041630 100644 --- a/fs/jfs/jfs_logmgr.c +++ b/fs/jfs/jfs_logmgr.c @@ -2311,6 +2311,7 @@ int jfsIOWait(void *arg) { struct lbuf *bp; =20 + set_freezable(); do { spin_lock_irq(&log_redrive_lock); while ((bp =3D log_redrive_list)) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 040E647ECDF; Sat, 28 Feb 2026 17:37:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300228; cv=none; b=MSNvJtI34vidAJ+cRYPNsJd/u8WN7rT/+MA23oDv789cEkKq13ZduVzmuY0UZ7CcTwRDvaAt2ef+cEGICVFRtSDUSruChG9bFzPpUISXa49/JBxxuUUf3kMo/zRYhJg03U0t4xZxjdgLp6Phn29jH3YLN7Y7zrVRl/5wtHE8Qqc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300228; c=relaxed/simple; bh=lrmkfEUu4w0lrbRBiahKpHE0krA3exWJACHWwDbLqs0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=It2G13v/Xh7MNjFBasLJxbUuq2pSRYT/j0WgpTUuwuC7eQcSu+xBAiSk37uq6FfYus7ymQtTiDXywFlzrCQn1vYq7BMNw1s404U1oEw5u2J8D4mpV63VYYi/XwdKms4EHqUjLJWO7M7+P0EKeQN426c0nZ4Lh+f4Po5zCKgJJx4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TG85iRbI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TG85iRbI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38F19C116D0; Sat, 28 Feb 2026 17:37:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300227; bh=lrmkfEUu4w0lrbRBiahKpHE0krA3exWJACHWwDbLqs0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TG85iRbIS/BqqTLSV3+01yHlzRrmMdgcdbN/ryqAVEyZVMihp1LVKz8oPXLh56qpv jNhOP29zgzyyE+SS5FyVAiWtwyfAX3PiPXBdA5s2rqk61Nt7es6QmFBFe1e1AknH8z X5NJ5dh4rH3o2eVCCHUps4fDU5RZ9Iy+LHZ9wqC+yJGUvEZMEVBeOoqCCBkyDUNMVj RixbQp0PSsW4ubpklVf06DDqUtwQjnX3GskzFMPL0ipOPCbaPGNcmCnDx1JIevXdmr yosdvvQfFt4ho5XDk1TxSCm1GYKIA/wOyqd7MpDbdP0nAaoHo3wIG+VNdUHkz1jKS7 FiiKkwVjE3w1A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jori Koolstra , syzbot+9131ddfd7870623b719f@syzkaller.appspotmail.com, Dave Kleikamp , Sasha Levin Subject: [PATCH 6.19 249/844] jfs: nlink overflow in jfs_rename Date: Sat, 28 Feb 2026 12:22:42 -0500 Message-ID: <20260228173244.1509663-250-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jori Koolstra [ Upstream commit 9218dc26fd922b09858ecd3666ed57dfd8098da8 ] If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink =3D -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions. Signed-off-by: Jori Koolstra Reported-by: syzbot+9131ddfd7870623b719f@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=3D9131ddfd7870623b719f Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/jfs/namei.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c index 65a218eba8faf..7879c049632b3 100644 --- a/fs/jfs/namei.c +++ b/fs/jfs/namei.c @@ -1228,7 +1228,7 @@ static int jfs_rename(struct mnt_idmap *idmap, struct= inode *old_dir, jfs_err("jfs_rename: dtInsert returned -EIO"); goto out_tx; } - if (S_ISDIR(old_ip->i_mode)) + if (S_ISDIR(old_ip->i_mode) && old_dir !=3D new_dir) inc_nlink(new_dir); } /* @@ -1244,7 +1244,9 @@ static int jfs_rename(struct mnt_idmap *idmap, struct= inode *old_dir, goto out_tx; } if (S_ISDIR(old_ip->i_mode)) { - drop_nlink(old_dir); + if (new_ip || old_dir !=3D new_dir) + drop_nlink(old_dir); + if (old_dir !=3D new_dir) { /* * Change inode number of parent for moved directory --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 644CA397323; Sat, 28 Feb 2026 17:37:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300229; cv=none; b=HZiJZ4JU30wdx2s5u0kRPMLtZZfJFp/cpE4/cKemxZev1ELe1nxssTkRyYYwOuMGE76dJt3VXColIkpEjACM7ocd1d2VhI7DTBDI15Tu/T2DoupNOced+gSefPPvY3jSY+r4Luc/NymSI+QyOnkEYawtG33p3zSR3Wumu/FBv+U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300229; c=relaxed/simple; bh=8AXpm2e3DYVQcceKJcF6sK9d9mzDshF09g5BH3QvSVQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fZ09bgHk9M59KDiqBSbU/T7mgwBgpeMaMmklUEUAicS9KscZalpnb++ntmhLiWtHaaa0C6HXphS0r3grQIhrRTUnYO0qMRFYm+Yvtut4s3DS4m76f/JF2rCLBbH0kszGPFr7zRKCjdck1YnCJzl01U9/RUbes+RuhslXZqLpyvQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RygyuXdR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RygyuXdR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28B90C19423; Sat, 28 Feb 2026 17:37:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300229; bh=8AXpm2e3DYVQcceKJcF6sK9d9mzDshF09g5BH3QvSVQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RygyuXdRWcmJ3OKzCTxdRUqqOXoPD6cxszVEmB2p+ULD9x4qDQzpAb8Sucr6pgllO RgSaoCckxEv4L+LQlJoI+tjwUQv+unCsbxrEAs6eZY+nculHiRQjcp/OrY/Ymf6Eis RuXF6nK17YtFKkEdZ5SEurekrOKJKBBHNxV7EhLzNBvcCBj6U8zZxQRzYI+Wa+JG2h 4mU7eru2N0ZgGhB/dcH7ZF+bNYDTuC5rBZKLGSiIzqPNPu6TxM8+fUxkOLfEaGWm2n LKvP7VcjBhaXz6QGyW9tJWvLJ7SlEnHmCgC+jN4kNbT36dq6w4q1sVBIQW1tI7Wktm pW6XKKehUYAMg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Manivannan Sadhasivam , Manivannan Sadhasivam , Vincent Guittot , Frank Li , Shawn Lin , Sasha Levin Subject: [PATCH 6.19 250/844] PCI: dwc: Skip PME_Turn_Off broadcast and L2/L3 transition during suspend if link is not up Date: Sat, 28 Feb 2026 12:22:43 -0500 Message-ID: <20260228173244.1509663-251-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Manivannan Sadhasivam [ Upstream commit cfd2fdfd0a8da2e5bbfdc4009b9c4b8bf164c937 ] During system suspend, if the PCIe link is not up, then there is no need to broadcast PME_Turn_Off message and wait for L2/L3 transition. So skip them. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Tested-by: Vincent Guittot Reviewed-by: Frank Li Reviewed-by: Shawn Lin Link: https://patch.msgid.link/20251218-pci-dwc-suspend-rework-v2-1-5a7778c= 6094a@oss.qualcomm.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-designware-host.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pc= i/controller/dwc/pcie-designware-host.c index 372207c33a857..250725ced9026 100644 --- a/drivers/pci/controller/dwc/pcie-designware-host.c +++ b/drivers/pci/controller/dwc/pcie-designware-host.c @@ -1158,8 +1158,11 @@ static int dw_pcie_pme_turn_off(struct dw_pcie *pci) int dw_pcie_suspend_noirq(struct dw_pcie *pci) { u8 offset =3D dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); + int ret =3D 0; u32 val; - int ret; + + if (!dw_pcie_link_up(pci)) + goto stop_link; =20 /* * If L1SS is supported, then do not put the link into L2 as some @@ -1194,6 +1197,7 @@ int dw_pcie_suspend_noirq(struct dw_pcie *pci) */ udelay(1); =20 +stop_link: dw_pcie_stop_link(pci); if (pci->pp.ops->deinit) pci->pp.ops->deinit(&pci->pp); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 16422397335; Sat, 28 Feb 2026 17:37:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300230; cv=none; b=uWQVXRYwGW0DTJA2N6lxgU8z+qjfqEvn7ooMWsWehS0emo8EO67S3Z8iDgOPtgddDDJIKtSpdqV2UzIsC/Te2z2fIOzpAQTyRzAWC061V8HhhR8pBL27sngbERK1NId5omJpRODtxBjFlz9bM0+9i+Y2h7MUMCUxVnyDO0w2N/0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300230; c=relaxed/simple; bh=CqTb2ncDZyCvY79JtpCtWTkhOpSciKWJvwe2gLjveiU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ahCMDBGYjlaeDWfToxS4Q9IZ9gYMaVyVZ5qtiGan93XeAWlzq/DDBmUR9sX/iXZ2e9IOEpalhdmIXSxHNub9/BYfwMFf7YThv0y9b2XxXSE71zrS7mUBzudRAeQ6FhiDAM3s6Q+Hj4f38Vt5U92M94QjIGtVResZ6rIvipWiqIE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RVgvRl8r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RVgvRl8r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46242C19424; Sat, 28 Feb 2026 17:37:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300229; bh=CqTb2ncDZyCvY79JtpCtWTkhOpSciKWJvwe2gLjveiU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RVgvRl8r05+zhGH/DLg9CpaS3tRkb/XMYfRMrrlj8QE9y04YsUrYqHPlWy4VYGvp7 tbOUUvbm3E1OPEpiLVvCMhuIOU3vakeayNpzYtA2ZsD869BYStoqyPqK/7al+GH1DV rzEPIhGO5tFpsugItgOukYWXxwZVc/FXpXXXYowedUGtUBY61oECCWzHMX1TECjc8K z4fnCe2M7gx43KaVPVmQk+6gFKo3/IMGrlE5OklzQVftLcqfjMn+3ddGIiiEYnt/FU SfBL7u62+cLxqc6m4j2Pq99OJNjv3/NCOApLmc8tilELkBwhxEhVOCeuWVKgiiMLct BvNm7kRIJpBJg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Roman Peshkichev , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 251/844] wifi: rtw88: fix DTIM period handling when conf->dtim_period is zero Date: Sat, 28 Feb 2026 12:22:44 -0500 Message-ID: <20260228173244.1509663-252-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Roman Peshkichev [ Upstream commit 9f68fdcdc9dbf21be2a48feced90ff7f77d07443 ] The function rtw_set_dtim_period() accepted an 'int' dtim_period parameter, while mac80211 provides dtim_period as 'u8' in struct ieee80211_bss_conf. In IBSS (ad-hoc) mode mac80211 may set dtim_period to 0. The driver unconditionally wrote (dtim_period - 1) to REG_DTIM_COUNTER_ROOT, which resulted in 0xFF when dtim_period was 0. This caused delays in broadcast/multicast traffic processing and issues with ad-hoc operation. Convert the function parameter to u8 to match ieee80211_bss_conf and avoid the underflow by writing 0 when dtim_period is 0. Link: https://github.com/lwfinger/rtw88/issues/406 Signed-off-by: Roman Peshkichev Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251125180937.22977-1-roman.peshkichev@gmai= l.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw88/main.c | 4 ++-- drivers/net/wireless/realtek/rtw88/main.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wirele= ss/realtek/rtw88/main.c index d93d21656f26c..f72d12c3b2bc6 100644 --- a/drivers/net/wireless/realtek/rtw88/main.c +++ b/drivers/net/wireless/realtek/rtw88/main.c @@ -730,10 +730,10 @@ void rtw_set_rx_freq_band(struct rtw_rx_pkt_stat *pkt= _stat, u8 channel) } EXPORT_SYMBOL(rtw_set_rx_freq_band); =20 -void rtw_set_dtim_period(struct rtw_dev *rtwdev, int dtim_period) +void rtw_set_dtim_period(struct rtw_dev *rtwdev, u8 dtim_period) { rtw_write32_set(rtwdev, REG_TCR, BIT_TCR_UPDATE_TIMIE); - rtw_write8(rtwdev, REG_DTIM_COUNTER_ROOT, dtim_period - 1); + rtw_write8(rtwdev, REG_DTIM_COUNTER_ROOT, dtim_period ? dtim_period - 1 := 0); } =20 void rtw_update_channel(struct rtw_dev *rtwdev, u8 center_channel, diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wirele= ss/realtek/rtw88/main.h index 43ed6d6b42919..1ab70214ce36e 100644 --- a/drivers/net/wireless/realtek/rtw88/main.h +++ b/drivers/net/wireless/realtek/rtw88/main.h @@ -2226,7 +2226,7 @@ enum nl80211_band rtw_hw_to_nl80211_band(enum rtw_sup= ported_band hw_band) } =20 void rtw_set_rx_freq_band(struct rtw_rx_pkt_stat *pkt_stat, u8 channel); -void rtw_set_dtim_period(struct rtw_dev *rtwdev, int dtim_period); +void rtw_set_dtim_period(struct rtw_dev *rtwdev, u8 dtim_period); void rtw_get_channel_params(struct cfg80211_chan_def *chandef, struct rtw_channel_params *ch_param); bool check_hw_ready(struct rtw_dev *rtwdev, u32 addr, u32 mask, u32 target= ); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9F31346E70; Sat, 28 Feb 2026 17:37:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300230; cv=none; b=YSsuEBxXEODOCGHtB2Vx/Cj7ZimRcqF1DcSsi8I/LhxHAsy2I3QK69dukIPaWEs2riWZb0pEnaNGkxqPR6x3CUc/j3/nDokWocHq2xxbIY6j7FD2oCoSyj5VCscyEKbziDMtKCud+OYKVzFN1fYyVRlz0NmF5C74DfRPROb2blc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300230; c=relaxed/simple; bh=my6dfp/GlCwi863JA+wggFe1YwcrV031OmpqAIPoVt4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hdc0petmA/c7XedjFYb3lUS3Uk5boda86crH76K4ep1iOQwgVx5gAGmU8vrtOqFb/iEzAl4ABCDh80877BcA1KHaoFfB3gm1lV0K8aHK5qQNQNrXMjRd6rBqwAe8Shs2ZDOQ5sZgg6FYEcxd5iYFJImFMXhPJqCHho4Q1Agb5FU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EcjxBbNJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EcjxBbNJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 235A7C116D0; Sat, 28 Feb 2026 17:37:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300230; bh=my6dfp/GlCwi863JA+wggFe1YwcrV031OmpqAIPoVt4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EcjxBbNJNR0iQcy9C5pbsextZ+wSX/jo2f0F8/lXkIvFoLlcslAmFIvBFowmvAkXM L2oHMvTPL5vY6hyZEBcGu0gA5p1U3WdINL9Gw9mmcbKlPPE7iHtt19o3mBMRm1VFpn oGs4MunIntjSoTRT3nq1BSZ6ZdsLoLbbHCGlhpFNcCXy48brncDqlEeAHKMRvl4qNc yN5Uv2j8jsfSyrQqO28yLOIz3NiCydRSUfrG/9x0R8g2Elzs2M9L/PZQ7ZucSqQ0ky PC4hNbfI3svln64zucBswnTG6QD5+MBAsr8ViJ/HdpLoNFmmIrV6yxr7z5+WcRRtzg ZF7HuOHPhXsAw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jan Gerber , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 252/844] wifi: rtw89: 8852au: add support for TP TX30U Plus Date: Sat, 28 Feb 2026 12:22:45 -0500 Message-ID: <20260228173244.1509663-253-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jan Gerber [ Upstream commit a2f1fc9ab6fb0d5c9d701a516c342944258fb20e ] the device shows up like this and everything seams to work: Bus 004 Device 003: ID 3625:010d Realtek 802.11ax WLAN Adapter Signed-off-by: Jan Gerber Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251212005515.2059533-1-j@mailb.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/rtw8852au.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852au.c b/drivers/net/w= ireless/realtek/rtw89/rtw8852au.c index ca782469c455d..74a976c984ad8 100644 --- a/drivers/net/wireless/realtek/rtw89/rtw8852au.c +++ b/drivers/net/wireless/realtek/rtw89/rtw8852au.c @@ -60,6 +60,8 @@ static const struct usb_device_id rtw_8852au_id_table[] = =3D { .driver_info =3D (kernel_ulong_t)&rtw89_8852au_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0141, 0xff, 0xff, 0xff), .driver_info =3D (kernel_ulong_t)&rtw89_8852au_info }, + { USB_DEVICE_AND_INTERFACE_INFO(0x3625, 0x010d, 0xff, 0xff, 0xff), + .driver_info =3D (kernel_ulong_t)&rtw89_8852au_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x3625, 0x010f, 0xff, 0xff, 0xff), .driver_info =3D (kernel_ulong_t)&rtw89_8852au_info }, {}, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC6FA397C77; Sat, 28 Feb 2026 17:37:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300231; cv=none; b=ZwpHca5CEbS515Hkff7DBxTYSo7UdBhBwg9sU9mmdr+9g925SXgBOszBz5o9N+Nvh8qqB7aodWaQ4z2OxsIYJgQkWW40v+K8l3aT03pHOejLLhbs4jvoT4e3jMdR8EyfSCHc+hSduc+nogQZRN5iGqshbuNI3ILDYsD6TE4ikI8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300231; c=relaxed/simple; bh=PRhyiLXJEkJyR4tDp6iDYpalkIQVH02kJMwoKwrf8Oc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=D4gzV2SLylgmr8IeNdD1Vc/YQE/0LQPN1Z78YGhpfATAjg3L7Tc5cGdzsIfF07Bnii9R7oNa7N9C8cv54/1r1/jdMxa0NOMAUQRg1abOlb/5zwUo/YMz9msKBsPsZgWtgt5Gfc4Mgyqfs9lkTMUl+4z8cexuka6eTOoIpIWFWDo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nk2PAqRf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nk2PAqRf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3239C19423; Sat, 28 Feb 2026 17:37:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300231; bh=PRhyiLXJEkJyR4tDp6iDYpalkIQVH02kJMwoKwrf8Oc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nk2PAqRfJpD4Z48RZhB25E/5VeYCY8pwZFSFGfFlrku7VUiaeumGjlcr8UEMC4/Tx BB7z+583VPBsxDebS7yebJVAGeCa19dlN9lkfU4ECuKo6WlXIsIne/zm67CcwMw5lX PfXfVBa9RsVGvDeSJYscQG8HJKJOvXqGWr4d/SW8eQEVh4ryVKcHBj04i5hUOe2Mbz iUqu88u5G6ZFj1pkUshoxLU8kw8+NyQpwEJDWc+JGC6+zbKcpG8oZiSuqO/74zNm2d qaxaTH+79R1gVra4jkxl5OIKbLV7o+Vlb7bgfgkNoEp42CnF1EmAAZjaAWOmlzZKp+ rFTFk8tVh2TJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bitterblue Smith , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 253/844] wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode() Date: Sat, 28 Feb 2026 12:22:46 -0500 Message-ID: <20260228173244.1509663-254-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bitterblue Smith [ Upstream commit 44d1f624bbdd2d60319374ba85f7195a28d00c90 ] rtw8822b_set_antenna() can be called from userspace when the chip is powered off. In that case a WARNING is triggered in rtw8822b_config_trx_mode() because trying to read the RF registers when the chip is powered off returns an unexpected value. Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only when the chip is powered on. Acked-by: Ping-Ke Shih Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara ------------[ cut here ]------------ write RF mode table fail WARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constp= rop.0+0x835/0x840 [rtw88_8822b] CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1= -1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1 Tainted: [W]=3DWARN, [O]=3DOOT_MODULE, [E]=3DUNSIGNED_MODULE Hardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021 RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b] Call Trace: rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759= efa37c422b] rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a= 5ac850fb] ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ec= e90486cf3] nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83= d3dbda] ? netdev_run_todo+0x63/0x550 genl_family_rcv_msg_doit+0xfc/0x160 genl_rcv_msg+0x1aa/0x2b0 ? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7f= bca83d3dbda] ? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7= fbca83d3dbda] ? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7= fbca83d3dbda] ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 ? refill_obj_stock+0x12e/0x240 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? do_syscall_64+0x81/0x970 ? ksys_read+0x73/0xf0 ? do_syscall_64+0x81/0x970 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]--- Link: https://github.com/lwfinger/rtw88/issues/366 Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/fb9a3444-9319-4aa2-8719-35a6308bf568@gmail.c= om Signed-off-by: Sasha Levin --- drivers/net/wireless/realtek/rtw88/rtw8822b.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c b/drivers/net/wi= reless/realtek/rtw88/rtw8822b.c index 89b6485b229a8..4d88cc2f41485 100644 --- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c +++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c @@ -1005,7 +1005,8 @@ static int rtw8822b_set_antenna(struct rtw_dev *rtwde= v, hal->antenna_tx =3D antenna_tx; hal->antenna_rx =3D antenna_rx; =20 - rtw8822b_config_trx_mode(rtwdev, antenna_tx, antenna_rx, false); + if (test_bit(RTW_FLAG_POWERON, rtwdev->flags)) + rtw8822b_config_trx_mode(rtwdev, antenna_tx, antenna_rx, false); =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84923397C8E; Sat, 28 Feb 2026 17:37:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300232; cv=none; b=RuDmPkjwW8TGQ7I0CiLvbCDmADfHncBLekMiF3FHJbm2J6GkH3+nkbCZcl00xR048fj4gmt4DgX0jt8ikYn02Nf3FRdKe2F1lI9cSEVeB4/IqvcWVl6kxXPCrENobXoTfMIMVwynksz4AmrzKsM6ZrUIEosLKNraiNZfZ1IiCr0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300232; c=relaxed/simple; bh=Dt/wMIymTdav/UUeeLS7H4kMK41+6TdhOpRB1a3sCa0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=liNn3p7aSxaVAL/fhCu28kU3PBY/5iJnk9BiYOP46S+JZl35BbE0IbibD2jgF8AAqNL+AFGoPwq30P2SScmNh9P+RfDcFzL61F6dfcOd0PO3OZnjexa0/Db2CHhdqaf9c5LbJKmgn7UviS2n8CY3gvNWmUpXCQZl/yJa5xDMaoE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QTyPEZVA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QTyPEZVA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDCF0C19425; Sat, 28 Feb 2026 17:37:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300232; bh=Dt/wMIymTdav/UUeeLS7H4kMK41+6TdhOpRB1a3sCa0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QTyPEZVAQEyR/VJ9kSxmwKUu44Ggqk+QKlB/q0Vh0WiWC3bE3fRL12nfkatYboOML eU5gxGK5V0Gq9c1ASIBZvwd+8jzFANStVT6sDswWvpvv0phWQh8ie526xeJAaBRj1s qnLgKMerpuMMS07l/HCdtV4kdDo4FHr5T9t9Z27owsTEAO12MK8H+B/51e5gICZ355 GYSjqVvyB2K38bCnWhmn9ZqIYLFpzl6RDR6eIcT3iEvyHfHN+Xnr5qlDhWZczFUgMs WcmFjiGv1fQz1qjnNMlRx2XlfKWa5gUgscIBFez8eHTOyT8N6AjGsYA1NAif73wzTz 6HHur/5tx5lVg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hsiu-Ming Chang , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 254/844] wifi: rtw88: rtw8821cu: Add ID for Mercusys MU6H Date: Sat, 28 Feb 2026 12:22:47 -0500 Message-ID: <20260228173244.1509663-255-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hsiu-Ming Chang [ Upstream commit 77653c327e11c71c5363b18a53fbf2b92ed21da4 ] Add support for Mercusys MU6H AC650 High Gain Wireless Dual Band USB Adapter V1.30. It is based on RTL8811CU, usb device ID is 2c4e:0105. Signed-off-by: Hsiu-Ming Chang Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251205003245.5762-1-cges30901@gmail.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw88/rtw8821cu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821cu.c b/drivers/net/w= ireless/realtek/rtw88/rtw8821cu.c index 7a0fffc359e25..8cd09d66655db 100644 --- a/drivers/net/wireless/realtek/rtw88/rtw8821cu.c +++ b/drivers/net/wireless/realtek/rtw88/rtw8821cu.c @@ -37,6 +37,8 @@ static const struct usb_device_id rtw_8821cu_id_table[] = =3D { .driver_info =3D (kernel_ulong_t)&(rtw8821c_hw_spec) }, /* Edimax */ { USB_DEVICE_AND_INTERFACE_INFO(0x7392, 0xd811, 0xff, 0xff, 0xff), .driver_info =3D (kernel_ulong_t)&(rtw8821c_hw_spec) }, /* Edimax */ + { USB_DEVICE_AND_INTERFACE_INFO(0x2c4e, 0x0105, 0xff, 0xff, 0xff), + .driver_info =3D (kernel_ulong_t)&(rtw8821c_hw_spec) }, /* Mercusys */ {}, }; MODULE_DEVICE_TABLE(usb, rtw_8821cu_id_table); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B038398444; Sat, 28 Feb 2026 17:37:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300233; cv=none; b=ZryzZ3raVTyQBsGbHYZldqrtX28YiKX+ccxK3xnUQhp4Ye+8HowyEsFRbDg9fQpcrAV5uTCgMv+8O2S2shIOwB3JO40LSyM1pwNHl0cctlO9bFjSE424/IhjsAzwAoCqB1g4CcG+GBj/CzZARMPmfb+i7SwRXXD/WxmVs4YhvZk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300233; c=relaxed/simple; bh=X4EwNMlb1Dmanb2m8IMn07TlqZ8ZWIolvnkALcmQxTU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qOTR3Q9QPQey2H/+mVhnJCMDaHal9PSXP6BG0rZ93/XR5JcqrZbSmGA+y/kAykg/zxZtQJtFF+NID/RjZZe0JaeG/MEzVwzXbOoyGT8lgCzY4qRTO4SeFcsI4le2LQUtrpL8MIsWPhkOuuiat1AzSOnwvHwihMb8HnzIZai16Vw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=myLQ3GNR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="myLQ3GNR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC00FC19423; Sat, 28 Feb 2026 17:37:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300233; bh=X4EwNMlb1Dmanb2m8IMn07TlqZ8ZWIolvnkALcmQxTU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=myLQ3GNRp+PCE75W8nT20FOs4G9bWF8rJh2RbiyA5U1AYhn370Umh4n95efmAM5B5 e/6C2aj1cPlxBxn1OTOrI6JuUh/Xc4wRJwuZhda/FgGae2UxxJeXPqZd4EPCyrdrkP OnILpmUgQL7sQm/afQuCwyHTXiUTRMSwpvBvCza9YRuHwoNdeuV/PU16c+IpeGai9I vgLW/U5Nhd657GPKvJ0Wh7NLHnIzmZ7zR4ZBEZsNACbF8zGKdLjKqjW7epUAk8qhIV PGcr/gvfTVcHCLefspqON4HZpRA++9hYNdE1iqhcK2GetZV4+os3BR2TOiSvoL/nVa eESuVimerKIgQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jose Ignacio Tornos Martinez , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 255/844] wifi: rtw89: 8922a: set random mac if efuse contains zeroes Date: Sat, 28 Feb 2026 12:22:48 -0500 Message-ID: <20260228173244.1509663-256-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jose Ignacio Tornos Martinez [ Upstream commit 41be33d3efc120f6a2c02d12742655f2aa09e1b6 ] I have some rtl8922ae devices with no permanent mac stored in efuse. It could be properly saved and/or configured from user tools like NetworkManager, but it would be desirable to be able to initialize it somehow to get the device working by default. So, in the same way as with other devices, if the mac address read from efuse contains zeros, a random mac address is assigned to at least allow operation, and the user is warned about this in case any action needs to be considered. Signed-off-by: Jose Ignacio Tornos Martinez Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251126091905.217951-1-jtornosm@redhat.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/rtw8922a.c | 22 +++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw89/rtw8922a.c b/drivers/net/wi= reless/realtek/rtw89/rtw8922a.c index 4437279c554b0..4bcf20612a455 100644 --- a/drivers/net/wireless/realtek/rtw89/rtw8922a.c +++ b/drivers/net/wireless/realtek/rtw89/rtw8922a.c @@ -636,16 +636,30 @@ static int rtw8922a_read_efuse_rf(struct rtw89_dev *r= twdev, u8 *log_map) static int rtw8922a_read_efuse(struct rtw89_dev *rtwdev, u8 *log_map, enum rtw89_efuse_block block) { + struct rtw89_efuse *efuse =3D &rtwdev->efuse; + int ret; + switch (block) { case RTW89_EFUSE_BLOCK_HCI_DIG_PCIE_SDIO: - return rtw8922a_read_efuse_pci_sdio(rtwdev, log_map); + ret =3D rtw8922a_read_efuse_pci_sdio(rtwdev, log_map); + break; case RTW89_EFUSE_BLOCK_HCI_DIG_USB: - return rtw8922a_read_efuse_usb(rtwdev, log_map); + ret =3D rtw8922a_read_efuse_usb(rtwdev, log_map); + break; case RTW89_EFUSE_BLOCK_RF: - return rtw8922a_read_efuse_rf(rtwdev, log_map); + ret =3D rtw8922a_read_efuse_rf(rtwdev, log_map); + break; default: - return 0; + ret =3D 0; + break; + } + + if (!ret && is_zero_ether_addr(efuse->addr)) { + rtw89_info(rtwdev, "efuse mac address is zero, using random mac\n"); + eth_random_addr(efuse->addr); } + + return ret; } =20 #define THM_TRIM_POSITIVE_MASK BIT(6) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 76349398467; Sat, 28 Feb 2026 17:37:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300234; cv=none; b=jsNE+ZFMDWsQp5qFjHYhx8oT2/+7GoMggeQqyuNipFqOs6p2+Ec0+bXe79fVp6A6sqZtbxI2zfxXM+gRnpghk7MyBi+CBfqUk0Ego0c4f8g06WxrPNFrMO8lGh+xGBsN42IaGH3T+Y875n+hmcDmF2dRVumP5K4SIHMseb/XYvI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300234; c=relaxed/simple; bh=UDlJnTV66CJjH8HOAMGo31guaFxg4/+ILiI2ngvhWB4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aKYAt5x1UfthZ5mzvKdOeqfmUqSE1ae4ZdyzaTX7tKSEH2xhwCDbnWFaEYhKnoIskcdHfgmcsgeABiFpzBtViHJAlQtAakeUfJWOZIztIHgFPsRzuxnZEd+/vcJXWjokmEtHFRI8RVjb+VcRWf5iC+T0Yd+FjxPIuYjGtdrU3Q4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bAZKAFr0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bAZKAFr0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 855F2C2BCAF; Sat, 28 Feb 2026 17:37:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300234; bh=UDlJnTV66CJjH8HOAMGo31guaFxg4/+ILiI2ngvhWB4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bAZKAFr0NSl/XUAVe/nIotSbAFLcgTJA1obJigUMcNLnFGkR/6PIbyc+hv3ysRhVO QVQjWtfsc9Jga7jYBG91SefL1k84OaX6NOkzr6RpsNGEVga8HaV/EpWGNNWe102RdW EfhdQTKOvCFq/Dm9HH1D0W2PLu7xO8rj2FDtDELtteNQyJmMCxAh0RBfcZCJmEcNmR sMIAkHqNssmVzTiV4WCUeSj9Op8YE27rrNQTLzusxudCIl6qYL5ffbxUQQ7cbkO1t/ eu/EVtPYjlzYQ0tqTbUAECgr/+JxBzMV8pfcVBbNUaV7UUioc9hbcn2uMXRkFhdbVL Hd37Of/SWK3qA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zong-Zhe Yang , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 256/844] wifi: rtw89: ser: enable error IMR after recovering from L1 Date: Sat, 28 Feb 2026 12:22:49 -0500 Message-ID: <20260228173244.1509663-257-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zong-Zhe Yang [ Upstream commit f4de946bdb379f543e3a599f8f048d741ad4a58e ] After recovering from L1, explicitly enable error IMR to ensure next L1 SER (system error recovery) can work normally. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251223030651.480633-6-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/mac.c | 1 + drivers/net/wireless/realtek/rtw89/mac.h | 1 + drivers/net/wireless/realtek/rtw89/mac_be.c | 1 + drivers/net/wireless/realtek/rtw89/ser.c | 10 ++++++++++ 4 files changed, 13 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireles= s/realtek/rtw89/mac.c index d78fbe73e3657..b4c292c7e829d 100644 --- a/drivers/net/wireless/realtek/rtw89/mac.c +++ b/drivers/net/wireless/realtek/rtw89/mac.c @@ -7184,6 +7184,7 @@ const struct rtw89_mac_gen_def rtw89_mac_gen_ax =3D { .check_mac_en =3D rtw89_mac_check_mac_en_ax, .sys_init =3D sys_init_ax, .trx_init =3D trx_init_ax, + .err_imr_ctrl =3D err_imr_ctrl_ax, .hci_func_en =3D rtw89_mac_hci_func_en_ax, .dmac_func_pre_en =3D rtw89_mac_dmac_func_pre_en_ax, .dle_func_en =3D dle_func_en_ax, diff --git a/drivers/net/wireless/realtek/rtw89/mac.h b/drivers/net/wireles= s/realtek/rtw89/mac.h index 0007229d67537..a4ed1c545609e 100644 --- a/drivers/net/wireless/realtek/rtw89/mac.h +++ b/drivers/net/wireless/realtek/rtw89/mac.h @@ -1019,6 +1019,7 @@ struct rtw89_mac_gen_def { enum rtw89_mac_hwmod_sel sel); int (*sys_init)(struct rtw89_dev *rtwdev); int (*trx_init)(struct rtw89_dev *rtwdev); + void (*err_imr_ctrl)(struct rtw89_dev *rtwdev, bool en); void (*hci_func_en)(struct rtw89_dev *rtwdev); void (*dmac_func_pre_en)(struct rtw89_dev *rtwdev); void (*dle_func_en)(struct rtw89_dev *rtwdev, bool enable); diff --git a/drivers/net/wireless/realtek/rtw89/mac_be.c b/drivers/net/wire= less/realtek/rtw89/mac_be.c index 556e5f98e8d41..9b9e646487346 100644 --- a/drivers/net/wireless/realtek/rtw89/mac_be.c +++ b/drivers/net/wireless/realtek/rtw89/mac_be.c @@ -2601,6 +2601,7 @@ const struct rtw89_mac_gen_def rtw89_mac_gen_be =3D { .check_mac_en =3D rtw89_mac_check_mac_en_be, .sys_init =3D sys_init_be, .trx_init =3D trx_init_be, + .err_imr_ctrl =3D err_imr_ctrl_be, .hci_func_en =3D rtw89_mac_hci_func_en_be, .dmac_func_pre_en =3D rtw89_mac_dmac_func_pre_en_be, .dle_func_en =3D dle_func_en_be, diff --git a/drivers/net/wireless/realtek/rtw89/ser.c b/drivers/net/wireles= s/realtek/rtw89/ser.c index f99e179f7ff9f..7fdc69578da31 100644 --- a/drivers/net/wireless/realtek/rtw89/ser.c +++ b/drivers/net/wireless/realtek/rtw89/ser.c @@ -431,6 +431,14 @@ static void hal_send_m4_event(struct rtw89_ser *ser) rtw89_mac_set_err_status(rtwdev, MAC_AX_ERR_L1_RCVY_EN); } =20 +static void hal_enable_err_imr(struct rtw89_ser *ser) +{ + struct rtw89_dev *rtwdev =3D container_of(ser, struct rtw89_dev, ser); + const struct rtw89_mac_gen_def *mac =3D rtwdev->chip->mac_def; + + mac->err_imr_ctrl(rtwdev, true); +} + /* state handler */ static void ser_idle_st_hdl(struct rtw89_ser *ser, u8 evt) { @@ -552,6 +560,8 @@ static void ser_do_hci_st_hdl(struct rtw89_ser *ser, u8= evt) break; =20 case SER_EV_MAC_RESET_DONE: + hal_enable_err_imr(ser); + ser_state_goto(ser, SER_IDLE_ST); break; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4780839847D; Sat, 28 Feb 2026 17:37:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300235; cv=none; b=jmoYi0UIHzugRxMG71Vi0jmW3EQ3y4mRg8We5XYkU9I4W315amHp/+PKqpwrbsxqsP4wvtTIMLTOwsz6GhloHjxtT9pMV5Fmlk3gK6vuAC1cA+L0AklRUxBBeYDmYKpP/0vpHjNs5M9sKv3jCPK08BJMURJJ4QhcF08S3tbGu2c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300235; c=relaxed/simple; bh=zLXSp2DUbR19ppVFOb8GLP5YuAim+D6173r6sPqsfd4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uDcWJAINf4O9E2hKB5s1kUMgxnugHRdqfZFpKO1boQidqC2aXGW+gv9Hqh6Q0C6jIef1f9K6XXJthBIE28TvMWsH2cHt2RF1AaEwyVUe9iYQL34tDg/IFdO+eS3xSqnx7XtK3NjArR0cwpx+3esukioH1zZjAREuLLIOMxE9a38= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HCuJSsmm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HCuJSsmm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FBB2C19423; Sat, 28 Feb 2026 17:37:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300235; bh=zLXSp2DUbR19ppVFOb8GLP5YuAim+D6173r6sPqsfd4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HCuJSsmm2xmOszXdvMh7LqRe+dx7vPHbJ8+78eB8cBW/0E1cvgEfIgT7G0xEPE8BQ SDvkmcVzT/KaSrn4ToRGR3t2kjqyxe/U2ieOka4fCCEZxzi90n86bUcqcFujZyKqog 2W+HWI/l0ibhTt/d1s3aKQdWH8dSA9a1FNsJaXHifIjf0zgGdXY34XpIxmHQ7tOSv/ y1h9jHolZKmkykJtJVLc8qSZKdmYjwFaipZPMuXOtS9wQfxQCHjcmTa0tqAYoPkfl0 kQX6oUip//NA3Tk+J9E94E6x8319cy1ghmhE6ZHe46JhEH9Dm5urnw+jatxQly/sZd eE3CW9B3NeARg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chih-Kang Chang , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 257/844] wifi: rtw89: setting TBTT AGG number when mac port initialization Date: Sat, 28 Feb 2026 12:22:50 -0500 Message-ID: <20260228173244.1509663-258-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chih-Kang Chang [ Upstream commit 5e5f83fba48381098b26a8b2513a6d5fc5c66ccb ] When initializing mac port, needs to set TBTT AGG number to trigger TBTT related interrupts. Otherwise, after sending join info H2C command with disconnection mode, firmware will clear TBTT AGG number. Without the setting from mac port initialization after that, this port will not be able to transmit beacons. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251223030651.480633-12-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/mac.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireles= s/realtek/rtw89/mac.c index b4c292c7e829d..6734e5d5a5e22 100644 --- a/drivers/net/wireless/realtek/rtw89/mac.c +++ b/drivers/net/wireless/realtek/rtw89/mac.c @@ -4341,6 +4341,7 @@ static void rtw89_mac_bcn_drop(struct rtw89_dev *rtwd= ev, #define BCN_HOLD_DEF 200 #define BCN_MASK_DEF 0 #define TBTT_ERLY_DEF 5 +#define TBTT_AGG_DEF 1 #define BCN_SET_UNIT 32 #define BCN_ERLY_SET_DLY (10 * 2) =20 @@ -4644,6 +4645,16 @@ static void rtw89_mac_port_cfg_tbtt_early(struct rtw= 89_dev *rtwdev, B_AX_TBTTERLY_MASK, TBTT_ERLY_DEF); } =20 +static void rtw89_mac_port_cfg_tbtt_agg(struct rtw89_dev *rtwdev, + struct rtw89_vif_link *rtwvif_link) +{ + const struct rtw89_mac_gen_def *mac =3D rtwdev->chip->mac_def; + const struct rtw89_port_reg *p =3D mac->port_base; + + rtw89_write16_port_mask(rtwdev, rtwvif_link, p->tbtt_agg, + B_AX_TBTT_AGG_NUM_MASK, TBTT_AGG_DEF); +} + static void rtw89_mac_port_cfg_bss_color(struct rtw89_dev *rtwdev, struct rtw89_vif_link *rtwvif_link) { @@ -4904,6 +4915,7 @@ int rtw89_mac_port_update(struct rtw89_dev *rtwdev, s= truct rtw89_vif_link *rtwvi rtw89_mac_port_cfg_bcn_hold_time(rtwdev, rtwvif_link); rtw89_mac_port_cfg_bcn_mask_area(rtwdev, rtwvif_link); rtw89_mac_port_cfg_tbtt_early(rtwdev, rtwvif_link); + rtw89_mac_port_cfg_tbtt_agg(rtwdev, rtwvif_link); rtw89_mac_port_cfg_bss_color(rtwdev, rtwvif_link); rtw89_mac_port_cfg_mbssid(rtwdev, rtwvif_link); rtw89_mac_port_cfg_func_en(rtwdev, rtwvif_link, true); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA816398DA3; Sat, 28 Feb 2026 17:37:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300236; cv=none; b=qVJsKozXRQl1EAiWVkdEE//HEaA7YjoL8kESDYcVX2RdIwfgOp09CamOeQVXKVRMtb4lE/+WFbMzTBlPk9UjTdHLnUHffdUzTK1j38kvUB9maNL5mNxfGiB9KPNJJKRIwTxzADw9VxUsaLk7/vmhmmFXjhUcW6U+R1HskkonX5c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300236; c=relaxed/simple; bh=mE/essJse7VBB1BowCp7eNSfFoAK4XIAvuKvzT78N2Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rzDoQ7HA0vUFbJxJ0UiVDtyunmfkasqh2Ent1FxucVdIwP9F7WSE7cohIWUqeR4phXrr9qQxuOw9PyN0+8r+QcZYQy/6g0lPeC4uMlAiPVxx7FNXSehvCQuOWpqw6EQ8sES+Y6HaWy/7psyQddcqfjio8iyEkvkl2aNMGQsA4vs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cbYgvvPh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cbYgvvPh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39412C19425; Sat, 28 Feb 2026 17:37:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300235; bh=mE/essJse7VBB1BowCp7eNSfFoAK4XIAvuKvzT78N2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cbYgvvPhi7xIoT5kUc8bgRygmbzQDPUbOMS49T/21w2JKSGCyGEUPbpjNupwf+Agt fO0TentJM7ZXuaej4jgIvWv0UFychP7eSwYqD93/2Og2EhXkzehJUh11ZKdqFqg+Sr mI1WWJeafZbw490BtgYSCtfw34vMJ6LOqZljl/HC5pbaWRTvm+4iaugqjHtwkUPLzJ RbjcC5kA3+RCYiG1dtCjDHfxVJZDTJzUrwxcgcEUNDGIUVR1l8ih3VfZXRH+X0Z75h /ajILXmYuy/l9P3Vgdg3Je7sNBNxGw5cbVLaTRTg0gCh6N7SJatOKOY25VImgXfVgo 6hflD35oCtCqA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chih-Kang Chang , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 258/844] wifi: rtw89: mcc: reset probe counter when receiving beacon Date: Sat, 28 Feb 2026 12:22:51 -0500 Message-ID: <20260228173244.1509663-259-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chih-Kang Chang [ Upstream commit 1b40c1c7571fcf926095ed92f25bd87900bdc8ed ] For BE chips, needs to transmit QoS null data periodically to ensure the connection with AP in GC+STA mode. However, in environments with interference, the Qos null data might fail to transmit successfully. Therefore, when receive the beacon from AP will reset the QoS null data failure counter to avoid unnecessary disconnection. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251223030651.480633-13-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/chan.c | 5 ++++- drivers/net/wireless/realtek/rtw89/mac80211.c | 1 + 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtw89/chan.c b/drivers/net/wirele= ss/realtek/rtw89/chan.c index 86f1b39a967fe..8fe6a7ef738f7 100644 --- a/drivers/net/wireless/realtek/rtw89/chan.c +++ b/drivers/net/wireless/realtek/rtw89/chan.c @@ -2608,17 +2608,20 @@ bool rtw89_mcc_detect_go_bcn(struct rtw89_dev *rtwd= ev, static void rtw89_mcc_detect_connection(struct rtw89_dev *rtwdev, struct rtw89_mcc_role *role) { + struct rtw89_vif_link *rtwvif_link =3D role->rtwvif_link; struct ieee80211_vif *vif; bool start_detect; int ret; =20 ret =3D rtw89_core_send_nullfunc(rtwdev, role->rtwvif_link, true, false, RTW89_MCC_PROBE_TIMEOUT); - if (ret) + if (ret && + READ_ONCE(rtwvif_link->sync_bcn_tsf) =3D=3D rtwvif_link->last_sync_bc= n_tsf) role->probe_count++; else role->probe_count =3D 0; =20 + rtwvif_link->last_sync_bcn_tsf =3D READ_ONCE(rtwvif_link->sync_bcn_tsf); if (role->probe_count < RTW89_MCC_PROBE_MAX_TRIES) return; =20 diff --git a/drivers/net/wireless/realtek/rtw89/mac80211.c b/drivers/net/wi= reless/realtek/rtw89/mac80211.c index f39ca1c2ed100..d08eac3d99266 100644 --- a/drivers/net/wireless/realtek/rtw89/mac80211.c +++ b/drivers/net/wireless/realtek/rtw89/mac80211.c @@ -127,6 +127,7 @@ static int __rtw89_ops_add_iface_link(struct rtw89_dev = *rtwdev, rtwvif_link->reg_6ghz_power =3D RTW89_REG_6GHZ_POWER_DFLT; rtwvif_link->rand_tsf_done =3D false; rtwvif_link->detect_bcn_count =3D 0; + rtwvif_link->last_sync_bcn_tsf =3D 0; =20 rcu_read_lock(); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5202398DC9; Sat, 28 Feb 2026 17:37:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300237; cv=none; b=SF5+poME3mYRYbSZwzW4Hj2COy07Neg49yYwD+gP6t1hOJ4ZWbk7e81rYcffOc7Menr1N9tVRq1jsUojUB8oBqvqWdj8KDSrag7Tttbpxqb95mxTR5Jy3k0D7r5VSwpRYAJ6/b1zhWLL0NW/fmAP9Be5idIRdJTWZiHQK/9Bz2A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300237; c=relaxed/simple; bh=DSeS++EwEDiKiYQ08hrhNvl4zKjplGTpvpcRwe/cWmg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ljczYxmdApKxX7eUfjtM6AJ8oKzvWOFXWUmVeRo8qRrcq9bvDz23hHX4jXaJYkkkfTLtFECyMJOSiVLNvn6wgO+6rgDAXvgRiMyhrEVio4Ss0/FCCnJciH9/gLEUSZ16DWHHDbTH+s/Qf/9eaEE3oEh0USoVMo3dwbKNKu13gbI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ctstjHpC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ctstjHpC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1150CC19423; Sat, 28 Feb 2026 17:37:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300236; bh=DSeS++EwEDiKiYQ08hrhNvl4zKjplGTpvpcRwe/cWmg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ctstjHpC2V3ZMPp62+TLBDh7rfKTWrNJhyalWCeBzR6e1TQL7R8V644RYnBeDqaH5 SLmcFA4S0kyq2D2Obkb7zIGt70GbJuS6vXJ7AUFDEctsFBeJyUSN3U54i2DZdHk6vD itvqzB7pXtdIq6fZT1qp/KStjcDWUsltcf0Vbc+UIqyWKEPxulSsbCY1hx2DNIE0EE rom1Xn/8ICeK/e1FriLzqPKyFPA0Gtpdc3G8LHXG9tm2lKAXObIwMLp9SHCUvRBYmL q1y9ZEvwAq61o+PEVM4LUM5hR1f4kWXg4zKw6gE9Uc4+W5rSe+3x82tpWgW7jKaJYu XY3V6Y8YMZc4A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bitterblue Smith , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 259/844] wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band() Date: Sat, 28 Feb 2026 12:22:52 -0500 Message-ID: <20260228173244.1509663-260-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bitterblue Smith [ Upstream commit 2ba12401cc1f2d970fa2e7d5b15abde3f5abd40d ] Simplify the code by using device managed memory allocations. This also fixes a memory leak in rtw_register_hw(). The supported bands were not freed in the error path. Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*"). Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/1aa7fdef-2d5b-4a31-a4e9-fac8257ed30d@gmail.c= om Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw88/main.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wirele= ss/realtek/rtw88/main.c index f72d12c3b2bc6..6f35357e73246 100644 --- a/drivers/net/wireless/realtek/rtw88/main.c +++ b/drivers/net/wireless/realtek/rtw88/main.c @@ -1661,11 +1661,13 @@ static u16 rtw_get_max_scan_ie_len(struct rtw_dev *= rtwdev) static void rtw_set_supported_band(struct ieee80211_hw *hw, const struct rtw_chip_info *chip) { - struct rtw_dev *rtwdev =3D hw->priv; struct ieee80211_supported_band *sband; + struct rtw_dev *rtwdev =3D hw->priv; + struct device *dev =3D rtwdev->dev; =20 if (chip->band & RTW_BAND_2G) { - sband =3D kmemdup(&rtw_band_2ghz, sizeof(*sband), GFP_KERNEL); + sband =3D devm_kmemdup(dev, &rtw_band_2ghz, sizeof(*sband), + GFP_KERNEL); if (!sband) goto err_out; if (chip->ht_supported) @@ -1674,7 +1676,8 @@ static void rtw_set_supported_band(struct ieee80211_h= w *hw, } =20 if (chip->band & RTW_BAND_5G) { - sband =3D kmemdup(&rtw_band_5ghz, sizeof(*sband), GFP_KERNEL); + sband =3D devm_kmemdup(dev, &rtw_band_5ghz, sizeof(*sband), + GFP_KERNEL); if (!sband) goto err_out; if (chip->ht_supported) @@ -1690,13 +1693,6 @@ static void rtw_set_supported_band(struct ieee80211_= hw *hw, rtw_err(rtwdev, "failed to set supported band\n"); } =20 -static void rtw_unset_supported_band(struct ieee80211_hw *hw, - const struct rtw_chip_info *chip) -{ - kfree(hw->wiphy->bands[NL80211_BAND_2GHZ]); - kfree(hw->wiphy->bands[NL80211_BAND_5GHZ]); -} - static void rtw_vif_smps_iter(void *data, u8 *mac, struct ieee80211_vif *vif) { @@ -2320,10 +2316,7 @@ EXPORT_SYMBOL(rtw_register_hw); =20 void rtw_unregister_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw) { - const struct rtw_chip_info *chip =3D rtwdev->chip; - ieee80211_unregister_hw(hw); - rtw_unset_supported_band(hw, chip); rtw_debugfs_deinit(rtwdev); rtw_led_deinit(rtwdev); } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9289D347FCC; Sat, 28 Feb 2026 17:37:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300237; cv=none; b=Yd2nFgFfQePqu2UuQzc4zXTq/vJRSkQLunozBd0I4I6zU4WV7p0vBot5LYsaYsU7lD1dwHh7KNFdn8Tmfe8wBmYRtZXpNxcxNpBcx+qH+ToWWuxm6DcPdqF3bc+r0aFjd3uNoSw7CetilHaOm52fPkwVGV8GUV8y8RuflR8mkl0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300237; c=relaxed/simple; bh=awD29nvx2aphOkit+4HOtUSGi40fwC+8DL/sgkv8urc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OfZr3A0zfGVbFZXmFcWHx4yQ/y1TxJDQKACTNGYDUHobGpRgwmOGdqetSinJtYtD/cH5a6e0sEhI4S0PSaNSbxXzKmU79CLHDu1JoJ4CaAhAmIVissY/5x23GcSvmMk/GMCJF2aqmItGUNYalb8Q2UVaOPT+HldycEgazZhXazs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rSBh/ovp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rSBh/ovp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF21EC19425; Sat, 28 Feb 2026 17:37:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300237; bh=awD29nvx2aphOkit+4HOtUSGi40fwC+8DL/sgkv8urc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rSBh/ovpr2/PF5kPXWO8w9r75am40nOCgNUAUHVWLaE/tSDA83BWhKap/pKoyIjHO tP7TewFEKJnkBVqRILZOEmtsB6QK9/23jBAhMqaGPQ/7TKvlXTuEOuz9u/o23prYsb EUg6VJ2PrLyj4+RqKxtHLp7bgMtJqD3kgMCzS3I8aGK9lCt1fKWgTm16XsrvpM4leV HlGtprjvC7mozEWTGDgTXarEmSgrMpArEtMGvvyZ46mt2KUcyqQaAWjG750kbDrrmy HkiuxP0TQWFnXMYaUpscWMvNfC0pbjYY+THPLXG99DgUzj1CBLaP6N7ocIYu5GmIq6 V85IWnh0cNK4A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bitterblue Smith , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 260/844] wifi: rtw88: Fix inadvertent sharing of struct ieee80211_supported_band data Date: Sat, 28 Feb 2026 12:22:53 -0500 Message-ID: <20260228173244.1509663-261-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bitterblue Smith [ Upstream commit fcac0f23d4d20b11014a39f8e2527cdc12ec9c82 ] Internally wiphy writes to individual channels in this structure, so we must not share one static definition of channel list between multiple device instances, because that causes hard to debug breakage. For example, with two rtw88 driven devices in the system, channel information may get incoherent, preventing channel use. Copied from commit 0ae36391c804 ("wifi: rtw89: Fix inadverent sharing of struct ieee80211_supported_band data"). Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/e94ad653-2b6d-4284-a33c-8c694f88955b@gmail.c= om Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw88/main.c | 34 +++++++++++++++++++---- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wirele= ss/realtek/rtw88/main.c index 6f35357e73246..dde2ea6a00e06 100644 --- a/drivers/net/wireless/realtek/rtw88/main.c +++ b/drivers/net/wireless/realtek/rtw88/main.c @@ -1658,16 +1658,41 @@ static u16 rtw_get_max_scan_ie_len(struct rtw_dev *= rtwdev) return len; } =20 +static struct ieee80211_supported_band * +rtw_sband_dup(struct rtw_dev *rtwdev, + const struct ieee80211_supported_band *sband) +{ + struct ieee80211_supported_band *dup; + + dup =3D devm_kmemdup(rtwdev->dev, sband, sizeof(*sband), GFP_KERNEL); + if (!dup) + return NULL; + + dup->channels =3D devm_kmemdup_array(rtwdev->dev, sband->channels, + sband->n_channels, + sizeof(*sband->channels), + GFP_KERNEL); + if (!dup->channels) + return NULL; + + dup->bitrates =3D devm_kmemdup_array(rtwdev->dev, sband->bitrates, + sband->n_bitrates, + sizeof(*sband->bitrates), + GFP_KERNEL); + if (!dup->bitrates) + return NULL; + + return dup; +} + static void rtw_set_supported_band(struct ieee80211_hw *hw, const struct rtw_chip_info *chip) { struct ieee80211_supported_band *sband; struct rtw_dev *rtwdev =3D hw->priv; - struct device *dev =3D rtwdev->dev; =20 if (chip->band & RTW_BAND_2G) { - sband =3D devm_kmemdup(dev, &rtw_band_2ghz, sizeof(*sband), - GFP_KERNEL); + sband =3D rtw_sband_dup(rtwdev, &rtw_band_2ghz); if (!sband) goto err_out; if (chip->ht_supported) @@ -1676,8 +1701,7 @@ static void rtw_set_supported_band(struct ieee80211_h= w *hw, } =20 if (chip->band & RTW_BAND_5G) { - sband =3D devm_kmemdup(dev, &rtw_band_5ghz, sizeof(*sband), - GFP_KERNEL); + sband =3D rtw_sband_dup(rtwdev, &rtw_band_5ghz); if (!sband) goto err_out; if (chip->ht_supported) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87ABC359A78; Sat, 28 Feb 2026 17:37:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300238; cv=none; b=oukA/FaMH+luBNwA1ND2E6jYHqLC4mHQRJ2Hl5Yp8ZMY9CqHjp7MVtmZTHizUN2HYxjvoyB17hxqii1wwnTs2PlGCh4OikuMtjnIIgxMm8wCobunzyvMDw1oPHZixbMtLK1Td/PjeyTURs77H1a8p82orLXG4HBzKtqzLnma36E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300238; c=relaxed/simple; bh=5aKzeXcYaYo4MCLQ1Ws0WHCxrUeX6gnyX7HcxQxb8KA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rm96ciCUdgvUIkg9W5ZBWmhv9DrDf3GXqBA/Pj3pjFk1M+uLFFrJUNEJGnyqjipWctetTpU7l9jo2y0nQvJhxNL160fptKP8zaDsHITKBtqde71ubc26hkFrhjp/0U4prFSd1sEe6TgAZIbXg4jbfI3ZMP6Ya0a3O9oWpUtJi60= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ETiRpB33; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ETiRpB33" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB47AC19424; Sat, 28 Feb 2026 17:37:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300238; bh=5aKzeXcYaYo4MCLQ1Ws0WHCxrUeX6gnyX7HcxQxb8KA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ETiRpB33UY4ZskLNZ4SXjSsPuR/b7iX+bfi9UrpcaMNTLPyBzksKaKV5z/zEhuEvV QmFsRmUDwRuFzasBQX2I6cTyvCcITtcgRWlG0Tk8obohOUDeiFYnNRls+upxhSpOar 1uvRm4+61/5p9ktodqjJdJNWgbumgDDJJokbqF8jsK/FF85ZdUv16GSupELyBXcBQV Zf9iPxyvyy7IrieB9PJJ/Cn5FKGdNwgl6fipX0ZpaerbkO8mL4WLkdJB79P7yQtphm 5GO1YI2U3FTh9uFBgWNfkId5ShzVKy+8mNeohNPxOxR4KtmvVoR2WZrzhmeAH6LwcN acKR47ytYelBg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , Manivannan Sadhasivam , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.19 261/844] PCI: cadence: Avoid signed 64-bit truncation and invalid sort Date: Sat, 28 Feb 2026 12:22:54 -0500 Message-ID: <20260228173244.1509663-262-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit 0297dce758a021ccf2c0f4e164d5403ef722961c ] The cdns_pcie_host_dma_ranges_cmp() element comparison function used by list_sort() is of type list_cmp_func_t, so it returns a 32-bit int. cdns_pcie_host_dma_ranges_cmp() computes a resource_size_t difference that may be a 64-bit value, and truncating that difference to a 32-bit return value may change the sign and result in an invalid sort order. Avoid the truncation and invalid sort order by returning -1, 0, or 1. Signed-off-by: Ian Rogers Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251209223756.2321578-1-irogers@google.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../controller/cadence/pcie-cadence-host-common.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c b/dr= ivers/pci/controller/cadence/pcie-cadence-host-common.c index 15415d7f35ee9..2b0211870f02a 100644 --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c @@ -173,11 +173,21 @@ int cdns_pcie_host_dma_ranges_cmp(void *priv, const s= truct list_head *a, const struct list_head *b) { struct resource_entry *entry1, *entry2; + u64 size1, size2; =20 entry1 =3D container_of(a, struct resource_entry, node); entry2 =3D container_of(b, struct resource_entry, node); =20 - return resource_size(entry2->res) - resource_size(entry1->res); + size1 =3D resource_size(entry1->res); + size2 =3D resource_size(entry2->res); + + if (size1 > size2) + return -1; + + if (size1 < size2) + return 1; + + return 0; } EXPORT_SYMBOL_GPL(cdns_pcie_host_dma_ranges_cmp); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66E50359A97; Sat, 28 Feb 2026 17:37:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300239; cv=none; b=RHN0MPl62EcIA1pjYwLr62wVUW7FKFpnbFLqAEicRt4UDLGXTQcY4LDrsgKA/rbHh+sgQPs87RwiocFk19tarpAIIFfT3WhW1wI+Bf37ybatY7/EMzUX5bW6rrUZ0Ul4EHaxzhBsHVKoCXbxtp0cORObNfWQbU2bW0VGy58ggP4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300239; c=relaxed/simple; bh=Gz1ludxEEJFQWEbjaRhIszl1VzZqmuMRqS+le7z7d1g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tmT7atDxw/bE6S9KqPuBY4xjZbGgXGPFL3vQG16nqXFTtSp1tz9jCvl+31NGabYymWCAqHG7fYBJspmN7feEwuXZpuGJIRb4Q5Gsr3wVRFADLGsfBy94AzWYT9zVIDTClSQiVZTK+pk9O1lujtqbgfdkj1Ydth1k7VRG3CK6Cek= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FBoMmttw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FBoMmttw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB3EDC19423; Sat, 28 Feb 2026 17:37:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300239; bh=Gz1ludxEEJFQWEbjaRhIszl1VzZqmuMRqS+le7z7d1g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FBoMmttwkbhRjeCra74iYYp/AK1N/IeSARZ1fn/+5ycuabq8oqncAwNMSkL7OcP8G krLhckHvf2dLsdsEf03+vR0nLG0R86fvjude+toblkPC+EOzocNRH+Kd7sXsNr+/0V 4gIrGMBfnmZZdz3fqCpq0WrXNZH0hANMx5IJHfBiEi3AUXCsqIWc+tTeiPhNBhEL9V qa9o6ZpmFYTzHWuSDC1A7KtXAuNjVHkCd12KgUNc66lHGI2QA7BpqfBSjpJXSk1rKs Tt1llSiY6eYvw4G1ImqoGwO84+xqa3gm9RGPdUJCwos+t73MUHxEiVKdvcIj9i8WI1 tbyUdLX9G3Xpw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zong-Zhe Yang , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 262/844] wifi: rtw89: regd: 6 GHz power type marks default when inactive Date: Sat, 28 Feb 2026 12:22:55 -0500 Message-ID: <20260228173244.1509663-263-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zong-Zhe Yang [ Upstream commit 8c96752d99c0b094af68317a8c701b09bd0862d9 ] When inactive, 6 GHz power type has been assigned to the default one, but missed to mark the local control variable, dflt, true. Then, this might let some 6 GHz power info of disconnected APs keep being taken into account under certain cases. So, mark default when inactive. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251229030926.27004-12-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/regd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/realtek/rtw89/regd.c b/drivers/net/wirele= ss/realtek/rtw89/regd.c index 209d84909f885..c3425ed44732e 100644 --- a/drivers/net/wireless/realtek/rtw89/regd.c +++ b/drivers/net/wireless/realtek/rtw89/regd.c @@ -1142,6 +1142,7 @@ static int rtw89_reg_6ghz_power_recalc(struct rtw89_d= ev *rtwdev, } } else { rtwvif_link->reg_6ghz_power =3D RTW89_REG_6GHZ_POWER_DFLT; + dflt =3D true; } =20 rcu_read_unlock(); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AA2739A4A2; Sat, 28 Feb 2026 17:37:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300240; cv=none; b=M3n2wSs8uf7avnKPulhnv9O/YL9Y2rJHVZVHyMoSy9Myg90r4ahRL5Y+y5tqmptCqz7kAL9iNRxnV+tvpFncg2SGrXRwNI9dhtxkTKtN0xKOSpoZFiTOPmjK07NUE2Nx01+PzJBhHiGux9yHHkH3C+7SACWtCtbFNudnQHFYaxw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300240; c=relaxed/simple; bh=cHUYixm8h1kdxcHkyLLsIHClUhF9li/px0bV+qqgbyA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BPq2e4+4JjHJ+bI+Nt1GjPka3XJXRWIi6epCyz4sJ8DlTvRDKIjzNPIxw+n2TjUPHgQCW1EkCOXgSZ2AZJJ1LzNN1Qu5solwSNhib7VzyNT79+DOsY1x3InIaASGR9EK6vbIC+VZ9Z1MLykv3gM2J4Ho+HKjS67J17m8Jxtjovc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t7+prBhl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="t7+prBhl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8421EC19424; Sat, 28 Feb 2026 17:37:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300240; bh=cHUYixm8h1kdxcHkyLLsIHClUhF9li/px0bV+qqgbyA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=t7+prBhlBNwuoZTm2q4BgwydfWKcZcT+iTCj1Kw36bk+ahvGUSAOTe/I1cXSnL8PG tvilIqylBni/0GunyfAHvQMUGUx4ldG9naUZhNRquSuUiRex9k54g+NcEa2J7YdwD3 CpG6oMHHieqTzSpCWm9HDZ+yILi8iuGJjFMa9pQgmf8/HIQlmGtVzdkSakqx21bYTU wQ47REJmMP6F97m8vcq3hj3QzDVJiSEx4cIKCb2/OFN5j0Pm7fTDraASjCKw+urrjv +OcQ5gVaeTAjbhh97fbDVbsbiJ6WXq0DVRRWgN60Ee/xqUXW3erjTWm/5dKgYNYbOd JYC689jQTG0RA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Daniel Gomez , Mikulas Patocka , Sasha Levin Subject: [PATCH 6.19 263/844] dm: replace -EEXIST with -EBUSY Date: Sat, 28 Feb 2026 12:22:56 -0500 Message-ID: <20260228173244.1509663-264-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Daniel Gomez [ Upstream commit b13ef361d47f09b7aecd18e0383ecc83ff61057e ] The -EEXIST error code is reserved by the module loading infrastructure to indicate that a module is already loaded. When a module's init function returns -EEXIST, userspace tools like kmod interpret this as "module already loaded" and treat the operation as successful, returning 0 to the user even though the module initialization actually failed. This follows the precedent set by commit 54416fd76770 ("netfilter: conntrack: helper: Replace -EEXIST by -EBUSY") which fixed the same issue in nf_conntrack_helper_register(). Affected modules: * dm_cache dm_clone dm_integrity dm_mirror dm_multipath dm_pcache * dm_vdo dm-ps-round-robin dm_historical_service_time dm_io_affinity * dm_queue_length dm_service_time dm_snapshot Signed-off-by: Daniel Gomez Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-exception-store.c | 2 +- drivers/md/dm-log.c | 2 +- drivers/md/dm-path-selector.c | 2 +- drivers/md/dm-target.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/md/dm-exception-store.c b/drivers/md/dm-exception-stor= e.c index c3799757bf4a0..88f119a0a2ae0 100644 --- a/drivers/md/dm-exception-store.c +++ b/drivers/md/dm-exception-store.c @@ -116,7 +116,7 @@ int dm_exception_store_type_register(struct dm_exceptio= n_store_type *type) if (!__find_exception_store_type(type->name)) list_add(&type->list, &_exception_store_types); else - r =3D -EEXIST; + r =3D -EBUSY; spin_unlock(&_lock); =20 return r; diff --git a/drivers/md/dm-log.c b/drivers/md/dm-log.c index 9d85d045f9d9d..bced5a783ee33 100644 --- a/drivers/md/dm-log.c +++ b/drivers/md/dm-log.c @@ -121,7 +121,7 @@ int dm_dirty_log_type_register(struct dm_dirty_log_type= *type) if (!__find_dirty_log_type(type->name)) list_add(&type->list, &_log_types); else - r =3D -EEXIST; + r =3D -EBUSY; spin_unlock(&_lock); =20 return r; diff --git a/drivers/md/dm-path-selector.c b/drivers/md/dm-path-selector.c index d0b883fabfeb6..2b0ac200f1c02 100644 --- a/drivers/md/dm-path-selector.c +++ b/drivers/md/dm-path-selector.c @@ -107,7 +107,7 @@ int dm_register_path_selector(struct path_selector_type= *pst) =20 if (__find_path_selector_type(pst->name)) { kfree(psi); - r =3D -EEXIST; + r =3D -EBUSY; } else list_add(&psi->list, &_path_selectors); =20 diff --git a/drivers/md/dm-target.c b/drivers/md/dm-target.c index 8fede41adec00..1fd41289de367 100644 --- a/drivers/md/dm-target.c +++ b/drivers/md/dm-target.c @@ -88,7 +88,7 @@ int dm_register_target(struct target_type *tt) if (__find_target_type(tt->name)) { DMERR("%s: '%s' target already registered", __func__, tt->name); - rv =3D -EEXIST; + rv =3D -EBUSY; } else { list_add(&tt->list, &_targets); } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30E5C39A4BF; Sat, 28 Feb 2026 17:37:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300241; cv=none; b=R4TN3uot5s3tksctquw1tOW8iHpVjB37VGuVtICt6T5B43AErZeABbkcBMKNzid/p0SzAa+iVn0OiXgyJ4jTbq4QcEAR98CEQTHAd073paDipo77Xt0V+tVMIhFubEwNPe23D6Drwt0Z6LVUXk0vzQz25sS1j6dIZ7S4zjn2aok= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300241; c=relaxed/simple; bh=I0fX+1jlFcw8DChdJT+PT3wBtP0zl/D7Tnn20vE+W3Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tS4aDKZubH/GmMkBxEurlYu1KD1/fN3bk/PGB3MAZfzEKmh2igzN8h5zmnY4Mexa+Vf4L24cgSDMsxgKS4G28kgL0hAhj+3NL5neMjfccVwPNQ9Lpg+36IBo/Oyn89pcyvmcQPxkdoe1RhtaTC01uRdKZoEX3ndJ0SB4jCmC380= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VU2fEvhb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VU2fEvhb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F8FBC19424; Sat, 28 Feb 2026 17:37:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300241; bh=I0fX+1jlFcw8DChdJT+PT3wBtP0zl/D7Tnn20vE+W3Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VU2fEvhbTg0z4P10AnMNzb2lBaGSVeMgxgbf1fH8XQmOt8KfnDYnyEpdQLt5owVJn M1QMdm/PPrQoUCsGkR1hg8rq6j+/jOdhvzgqFYIBednXmWfd+CHR+ic92aqabDhGNd dFlN375t5ETatzA6nK4FiU4g9v+2YpnM7rA//uuW7HS+jHmoF/bMe0n/6D7RLo+CEM 5Z0vWfv8fjRLQ2kyvf5HOtkw8IyjuFH37Q9X6PANNyPKFYSuE1M7Y/azP/NK1fpBuh u3j1b6bXKqPPXZBqNvv3H57R6uKSH+xcKs2gyD/KZhqNoB31Y4VYxslF2kcqH3JfWq 519j/RUqFDKtQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ding Hui , Christoph Hellwig , Mikulas Patocka , Sasha Levin Subject: [PATCH 6.19 264/844] dm: remove fake timeout to avoid leak request Date: Sat, 28 Feb 2026 12:22:57 -0500 Message-ID: <20260228173244.1509663-265-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ding Hui [ Upstream commit f3a9c95a15d2f4466acad5c68faeff79ca5e9f47 ] Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seco= nds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables = this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 = ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_trans= port_iscsi] [ 862.245264] Call Trace: [ 862.245587] [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts. Signed-off-by: Ding Hui Reviewed-by: Christoph Hellwig Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-rq.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c index a6ca92049c10e..5e08546696145 100644 --- a/drivers/md/dm-rq.c +++ b/drivers/md/dm-rq.c @@ -278,8 +278,7 @@ static void dm_complete_request(struct request *rq, blk= _status_t error) struct dm_rq_target_io *tio =3D tio_from_request(rq); =20 tio->error =3D error; - if (likely(!blk_should_fake_timeout(rq->q))) - blk_mq_complete_request(rq); + blk_mq_complete_request(rq); } =20 /* --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F27F39A4D9; Sat, 28 Feb 2026 17:37:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300242; cv=none; b=A9qfN+VePCQZ1V4J5cE+jeF9wJJiI7MltwoTP1ugU8r+f4h79EPFemVxBYga7yQgSBDhOu/zo+ZRipKEdZITyQ5d+QxO4LS5kt7SBFkYpwaoJigKqP77oW11oo3GgRiL6XqZ+jKa1bTRfNr3ckCdYU+1j/rmoyO0FCEsKJRy4gE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300242; c=relaxed/simple; bh=7WF87rg+N5704HtLLt4Zw6BhvH/rHV8xtWtJnZp89eg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=upCp+zzeRhpf2Yfw60WXq0W3aUE4sfo2a3vXhPMEJXejbs3qBl3jRr68hDmw1u939xjzmBl1qsXN+eTuCWrYmrGML3jyu7u+DKE861tkdwSdcsCzA0lw1/NNag4rL95zGxYSlXvB+iUj8HvZhKWr/ONa9GSZ5w//VSiwnWyWjq0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ud5VG2j9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ud5VG2j9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A32AC19423; Sat, 28 Feb 2026 17:37:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300242; bh=7WF87rg+N5704HtLLt4Zw6BhvH/rHV8xtWtJnZp89eg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ud5VG2j9gRK1CUHg21bjgJBpjq9cZ1WudIVGo8Mq/9K42mpILqY+6S/DLzqQI5Zw7 ws9TT0KXriHx+qXLVq5CpOyKghDxx9kva3Jq9jVdXo71Ojb5E3gMt9AXA7naZM19hA Lo5UBZH6s9/KQz59QhlUPM77OBBFktXNIZ1sumqAQp8ONDHrbGaeHVNLeVmCsSP430 eQ+O4w9fv/C3qnRdP37JknPzp8N7QKCN6jpstAgJzYTL/2Lz9/kIh601jVcqWk+BxO xo17iZU45dTsvyzkiWI5uVg7N1rLvxDOPMNEEYtUWJ6YzZjg/SAtGXrsDGl2Om81EM xmE7oPnpMoX7A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alexander Grest , Mostafa Saleh , Nicolin Chen , Jacob Pan , Will Deacon , Sasha Levin Subject: [PATCH 6.19 265/844] iommu/arm-smmu-v3: Improve CMDQ lock fairness and efficiency Date: Sat, 28 Feb 2026 12:22:58 -0500 Message-ID: <20260228173244.1509663-266-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexander Grest [ Upstream commit df180b1a4cc51011c5f8c52c7ec02ad2e42962de ] The SMMU CMDQ lock is highly contentious when there are multiple CPUs issuing commands and the queue is nearly full. The lock has the following states: - 0: Unlocked - >0: Shared lock held with count - INT_MIN+N: Exclusive lock held, where N is the # of shared waiters - INT_MIN: Exclusive lock held, no shared waiters When multiple CPUs are polling for space in the queue, they attempt to grab the exclusive lock to update the cons pointer from the hardware. If they fail to get the lock, they will spin until either the cons pointer is updated by another CPU. The current code allows the possibility of shared lock starvation if there is a constant stream of CPUs trying to grab the exclusive lock. This leads to severe latency issues and soft lockups. Consider the following scenario where CPU1's attempt to acquire the shared lock is starved by CPU2 and CPU0 contending for the exclusive lock. CPU0 (exclusive) | CPU1 (shared) | CPU2 (exclusive) | `cmdq->lock` Reviewed-by: Mostafa Saleh Reviewed-by: Nicolin Chen Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara -------------------------------------------------------------------------- trylock() //takes | | | 0 | shared_lock() | | INT_MIN | fetch_inc() | | INT_MIN | no return | | INT_MIN + 1 | spins // VAL >=3D 0 | | INT_MIN + 1 unlock() | spins... | | INT_MIN + 1 set_release(0) | spins... | | 0 see[NOTE] (done) | (sees 0) | trylock() // takes | 0 | *exits loop* | cmpxchg(0, INT_MIN) | 0 | | *cuts in* | INT_MIN | cmpxchg(0, 1) | | INT_MIN | fails // !=3D 0 | | INT_MIN | spins // VAL >=3D 0 | | INT_MIN | *starved* | | INT_MIN [NOTE] The current code resets the exclusive lock to 0 regardless of the state of the lock. This causes two problems: 1. It opens the possibility of back-to-back exclusive locks and the downstream effect of starving shared lock. 2. The count of shared lock waiters are lost. To mitigate this, we release the exclusive lock by only clearing the sign bit while retaining the shared lock waiter count as a way to avoid starving the shared lock waiters. Also deleted cmpxchg loop while trying to acquire the shared lock as it is not needed. The waiters can see the positive lock count and proceed immediately after the exclusive lock is released. Exclusive lock is not starved in that submitters will try exclusive lock first when new spaces become available. Reviewed-by: Mostafa Saleh Reviewed-by: Nicolin Chen Signed-off-by: Alexander Grest Signed-off-by: Jacob Pan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 31 ++++++++++++++------- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/ar= m/arm-smmu-v3/arm-smmu-v3.c index d16d35c78c068..7a6aea3b61c11 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -487,20 +487,26 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_de= vice *smmu) */ static void arm_smmu_cmdq_shared_lock(struct arm_smmu_cmdq *cmdq) { - int val; - /* - * We can try to avoid the cmpxchg() loop by simply incrementing the - * lock counter. When held in exclusive state, the lock counter is set - * to INT_MIN so these increments won't hurt as the value will remain - * negative. + * When held in exclusive state, the lock counter is set to INT_MIN + * so these increments won't hurt as the value will remain negative. + * The increment will also signal the exclusive locker that there are + * shared waiters. */ if (atomic_fetch_inc_relaxed(&cmdq->lock) >=3D 0) return; =20 - do { - val =3D atomic_cond_read_relaxed(&cmdq->lock, VAL >=3D 0); - } while (atomic_cmpxchg_relaxed(&cmdq->lock, val, val + 1) !=3D val); + /* + * Someone else is holding the lock in exclusive state, so wait + * for them to finish. Since we already incremented the lock counter, + * no exclusive lock can be acquired until we finish. We don't need + * the return value since we only care that the exclusive lock is + * released (i.e. the lock counter is non-negative). + * Once the exclusive locker releases the lock, the sign bit will + * be cleared and our increment will make the lock counter positive, + * allowing us to proceed. + */ + atomic_cond_read_relaxed(&cmdq->lock, VAL > 0); } =20 static void arm_smmu_cmdq_shared_unlock(struct arm_smmu_cmdq *cmdq) @@ -527,9 +533,14 @@ static bool arm_smmu_cmdq_shared_tryunlock(struct arm_= smmu_cmdq *cmdq) __ret; \ }) =20 +/* + * Only clear the sign bit when releasing the exclusive lock this will + * allow any shared_lock() waiters to proceed without the possibility + * of entering the exclusive lock in a tight loop. + */ #define arm_smmu_cmdq_exclusive_unlock_irqrestore(cmdq, flags) \ ({ \ - atomic_set_release(&cmdq->lock, 0); \ + atomic_fetch_andnot_release(INT_MIN, &cmdq->lock); \ local_irq_restore(flags); \ }) =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3879839B949; Sat, 28 Feb 2026 17:37:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300243; cv=none; b=Vk3xK8isTtne374pkg/sD/u/D2CG9iOMnhwUwvLXpj7yPWLMU7SCiMbuRRm0EXQGADuNkdLibS93qOfn3LyGa8j/tz9w9a/KV9W+sWAvxbNjlxggVCoOUU4TKmeXh7joAb/w5QycyGJsZfLaBYcZVzimpu+ziFFDan1/NTmkDs0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300243; c=relaxed/simple; bh=1eJRIi7rZxnG0yH3rK9b/31SZFamPACMOK8xQRNA2Kc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MCrbFCujg9oNy1lkSyU7cKEkkfSCyIk/vxH/y6GBUo1Y9o9dszHjRVzZZXi4wSqYYgFqxhQcevqrITtmcikgRO1t7DKVgeSCgEEKkjwSNYBvnPhUoPkpQ3nBLf9tuw9K/fF2ypKISqFbbZECP3/yiuAZkSMAO37PwM/oS3P3hUc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=igZzlX/3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="igZzlX/3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 776F0C19423; Sat, 28 Feb 2026 17:37:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300243; bh=1eJRIi7rZxnG0yH3rK9b/31SZFamPACMOK8xQRNA2Kc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=igZzlX/3e8YEEW5RBFXzViJKsxIuZ+/8QgbnxSg9TcDFpcljDKqPjQBwrRcTKcwO8 SplpjvZvZXvzJoKKqT6LJPZBawC/5sMk8Ar6zc89thoZf439wAXhauanPjqhD+MBBi zexuL2+hEbv748Rm/XekBekyjCqWJ9KssfAVuKDkYJ/LQr8/4vwIqfWqExMvibS3Tq UJbBkKKVj02HXlDtOwtqNrPwBCA4oSyVgjnV6H0J0FA0BZU1AoLOdOyog40KGAjW09 W7mU3h6Mu/de0Sc2Kt3sMMKXFaQs3dWHL5EEIKkJR8VrmbhVt+gksLM/4nRVZ+hw6K ee70c/mmZKi6Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Slark Xiao , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 266/844] net: wwan: mhi: Add network support for Foxconn T99W760 Date: Sat, 28 Feb 2026 12:22:59 -0500 Message-ID: <20260228173244.1509663-267-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Slark Xiao [ Upstream commit 915a5f60ad947e8dd515d2cc77a96a14dffb3f15 ] T99W760 is designed based on Qualcomm SDX35 chip. It use similar architecture with SDX72/SDX75 chip. So we need to assign initial link id for this device to make sure network available. Signed-off-by: Slark Xiao Link: https://patch.msgid.link/20260105022646.10630-1-slark_xiao@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wwan/mhi_wwan_mbim.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wwan/mhi_wwan_mbim.c b/drivers/net/wwan/mhi_wwan_m= bim.c index f8bc9a39bfa30..1d7e3ad900c12 100644 --- a/drivers/net/wwan/mhi_wwan_mbim.c +++ b/drivers/net/wwan/mhi_wwan_mbim.c @@ -98,7 +98,8 @@ static struct mhi_mbim_link *mhi_mbim_get_link_rcu(struct= mhi_mbim_context *mbim static int mhi_mbim_get_link_mux_id(struct mhi_controller *cntrl) { if (strcmp(cntrl->name, "foxconn-dw5934e") =3D=3D 0 || - strcmp(cntrl->name, "foxconn-t99w640") =3D=3D 0) + strcmp(cntrl->name, "foxconn-t99w640") =3D=3D 0 || + strcmp(cntrl->name, "foxconn-t99w760") =3D=3D 0) return WDS_BIND_MUX_DATA_PORT_MUX_ID; =20 return 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 094EF39B963; Sat, 28 Feb 2026 17:37:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300244; cv=none; b=PqR9dxosGMdqqWyNYrAwsNXhTnX3hsywf6J8G76vD5t7qj0MNSg7RDWXjWNvEXW+D+/gf8I42qt2BlLB+5Qliis10XNuuujWhFndCCDC8irxmQVyAptCwomliafTRxPiFTjkMI2HRkji/ekECiDCH57OnzFUty2/mGs98HoAQgU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300244; c=relaxed/simple; bh=Ihsn2/ioBdssasUkisvqXnV86eTduIcwn1rgT7gK7f8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qlIwhOcB/9fXiX8hIXrCzhQfyU31CEHRVmtsBXMIzmo7Ghkl4o0NRTLQ3Phk7OiSqBxjLGAvqGDWvlmJli1t5BAat2yLYKXlzO2ieOPV66uQFR/iZrSHFXijRlvDqm3wtPmN1vbcK6s/3tyUELrW4DxRjPjme/VAA6UdXatJCBE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IViXweEp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IViXweEp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53B4EC19424; Sat, 28 Feb 2026 17:37:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300243; bh=Ihsn2/ioBdssasUkisvqXnV86eTduIcwn1rgT7gK7f8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IViXweEpGuy+iUlAZDB77Elqqo7G09w+OrB68hvchWO4YbEh7wMrFekzpAMyGkb28 pzyqa/6QELfyvc0djFwYjqQ1xRF8LSntncHOdhr4oLf5e9ua+keSbZ6dMvZ5+TIduM n8hh81j1/wDefOBfIDi63rhDYDZjX9VMm/yW9z5xH8vpj41WJqUIGsRVlSiRFZe3JI iphb2XHLPR2LIKNF4ErbjD8a1oOmkwrUcGFVs1uLexLfeIXWYk11rc20GaNxoFSV1l JGgD2PZZIEpJHqWHwIQqu49LsAqyYVD5CTQooUdFREBgWkWvtvIQQnkOM8XH158nsD KdsBUG6XildCA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kuan-Chung Chen , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 267/844] wifi: rtw89: fix potential zero beacon interval in beacon tracking Date: Sat, 28 Feb 2026 12:23:00 -0500 Message-ID: <20260228173244.1509663-268-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kuan-Chung Chen [ Upstream commit eb57be32f438c57c88d6ce756101c1dfbcc03bba ] During fuzz testing, it was discovered that bss_conf->beacon_int might be zero, which could result in a division by zero error in subsequent calculations. Set a default value of 100 TU if the interval is zero to ensure stability. Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251231090647.56407-11-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/core.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wirele= ss/realtek/rtw89/core.c index 53d32f3137ebe..c5934e4eff711 100644 --- a/drivers/net/wireless/realtek/rtw89/core.c +++ b/drivers/net/wireless/realtek/rtw89/core.c @@ -2787,7 +2787,7 @@ static void rtw89_core_bcn_track_assoc(struct rtw89_d= ev *rtwdev, =20 rcu_read_lock(); bss_conf =3D rtw89_vif_rcu_dereference_link(rtwvif_link, true); - beacon_int =3D bss_conf->beacon_int; + beacon_int =3D bss_conf->beacon_int ?: 100; dtim =3D bss_conf->dtim_period; rcu_read_unlock(); =20 @@ -2817,9 +2817,7 @@ static void rtw89_core_bcn_track_reset(struct rtw89_d= ev *rtwdev) memset(&rtwdev->bcn_track, 0, sizeof(rtwdev->bcn_track)); } =20 -static void rtw89_vif_rx_bcn_stat(struct rtw89_dev *rtwdev, - struct ieee80211_bss_conf *bss_conf, - struct sk_buff *skb) +static void rtw89_vif_rx_bcn_stat(struct rtw89_dev *rtwdev, struct sk_buff= *skb) { #define RTW89_APPEND_TSF_2GHZ 384 #define RTW89_APPEND_TSF_5GHZ 52 @@ -2828,7 +2826,7 @@ static void rtw89_vif_rx_bcn_stat(struct rtw89_dev *r= twdev, struct ieee80211_rx_status *rx_status =3D IEEE80211_SKB_RXCB(skb); struct rtw89_beacon_stat *bcn_stat =3D &rtwdev->phystat.bcn_stat; struct rtw89_beacon_track_info *bcn_track =3D &rtwdev->bcn_track; - u32 bcn_intvl_us =3D ieee80211_tu_to_usec(bss_conf->beacon_int); + u32 bcn_intvl_us =3D ieee80211_tu_to_usec(bcn_track->beacon_int); u64 tsf =3D le64_to_cpu(mgmt->u.beacon.timestamp); u8 wp, num =3D bcn_stat->num; u16 append; @@ -2836,6 +2834,10 @@ static void rtw89_vif_rx_bcn_stat(struct rtw89_dev *= rtwdev, if (!RTW89_CHK_FW_FEATURE(BEACON_TRACKING, &rtwdev->fw)) return; =20 + /* Skip if not yet associated */ + if (!bcn_intvl_us) + return; + switch (rx_status->band) { default: case NL80211_BAND_2GHZ: @@ -2923,7 +2925,7 @@ static void rtw89_vif_rx_stats_iter(void *data, u8 *m= ac, pkt_stat->beacon_rate =3D desc_info->data_rate; pkt_stat->beacon_len =3D skb->len; =20 - rtw89_vif_rx_bcn_stat(rtwdev, bss_conf, skb); + rtw89_vif_rx_bcn_stat(rtwdev, skb); } =20 if (!ether_addr_equal(bss_conf->addr, hdr->addr1)) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D549939B97D; Sat, 28 Feb 2026 17:37:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300244; cv=none; b=tBXKN1rVVSU49M40Wo9paBcEKwKvUs6lgKZIfdJYc6/YbPDkpeq6X0IOVesMHEo4erxd0VDlLm7pKCVr+MItUvVIQ8LOBfu9FsypzCGRjHTIRyRDIBuYhI/orKjXh5ZcoTiQu5fwOMauvfNvRpM+x89Apdy/7SsaKVPZP1rGwvE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300244; c=relaxed/simple; bh=nzItiEz8QVYN0Ia+mYqox2oKSRk3JCPx68U3AHsJe1w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hN3cEZvKNMjBfEK2rN5qU5gSNJNRJhbMwvuIuWqBvjC5un31OD0BpP0ki82Nf649BZdwmUqAKUC3sAUDLTuHBh6mnEgRIbm6BrTZvCzWYxLqxjYt1pkZKt2y/Lz67ZnW45jTkGdjPuwAc2hKmD8+Dijvc8XDAlaugPlIwUz61tQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p5KW0X4N; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p5KW0X4N" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2ED3DC19423; Sat, 28 Feb 2026 17:37:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300244; bh=nzItiEz8QVYN0Ia+mYqox2oKSRk3JCPx68U3AHsJe1w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p5KW0X4NAOm1XgmrL/tHUukxDBfAh+4LwfOQTw1nYNZCSg/1R67pjevxZb0pJdVr/ /wtFfrR6Ln4AgkgAOXBIkfH6NjlhCI97qCk2zB6xIcdOjYCiOD1420XJu4fqPa0vI6 e8vB7LDmfNqiDqQYSl1qberfUa2U52VUlsUJ3ffuJJvHJuSUeLSGG/nBBr8Py19e8U W3gvCqTjjRE08fiMNTjBlBWA8yKXcOhqLAQkiRY455V8iDLyf2I9g4EwfrU27nu1uA eSYz/ZWdr6M4503YhQ2VXBiC6k5jEjc5Z0qTltbQg8e81F8TdOasBDHa2VeagaiPsy mLVk5krfzZUNw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Wander Lairson Costa , Tomas Glozar , Sasha Levin Subject: [PATCH 6.19 268/844] rtla: Fix NULL pointer dereference in actions_parse Date: Sat, 28 Feb 2026 12:23:01 -0500 Message-ID: <20260228173244.1509663-269-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wander Lairson Costa [ Upstream commit a0890f9dbd24b302d327fe7dad9b9c5be0e278aa ] The actions_parse() function uses strtok() to tokenize the trigger string, but does not check if the returned token is NULL before passing it to strcmp(). If the trigger parameter is an empty string or contains only delimiter characters, strtok() returns NULL, causing strcmp() to dereference a NULL pointer and crash the program. This issue can be triggered by malformed user input or edge cases in trigger string parsing. Add a NULL check immediately after the strtok() call to validate that a token was successfully extracted before using it. If no token is found, the function now returns -1 to indicate a parsing error. Signed-off-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20260106133655.249887-13-wander@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/tracing/rtla/src/actions.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/tracing/rtla/src/actions.c b/tools/tracing/rtla/src/acti= ons.c index 8945aee58d511..15986505b4376 100644 --- a/tools/tracing/rtla/src/actions.c +++ b/tools/tracing/rtla/src/actions.c @@ -141,6 +141,8 @@ actions_parse(struct actions *self, const char *trigger= , const char *tracefn) =20 strcpy(trigger_c, trigger); token =3D strtok(trigger_c, ","); + if (!token) + return -1; =20 if (strcmp(token, "trace") =3D=3D 0) type =3D ACTION_TRACE_OUTPUT; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0CFA39C216; Sat, 28 Feb 2026 17:37:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300245; cv=none; b=mc/XLyviSMi9p4rmLyeaDOo5AewJh1kJzultlWGVauyofvxprSsHoDPBXOiXYeed1cmyUXrShFtrvUchQ8vDz3QFGohU/DVgmfZQ+bqV+BuzeSfyEajjSBFT8WPsdeqGLELbFkXr3/WHSlgfKfdRTybNOyTFdHhKyrYFdLM3O8I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300245; c=relaxed/simple; bh=vGJ+ODU1O2pnF5slHFB5e8eITxNGC7zuB7JpGnFop2I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JUwyHPNB/2+TR18lmx1Sce6AEO1F7RE7QQ/A7evtrIVm85dCYKAotKg+GhtdpaWOdQubyrmqMh7JHIQjpaIRzJw2f/WdPPX2tZesC+LxW89hqO7jgWlxrt4s3VUurdJHTh7/DrggLhMH5YKmj5f9AhwSf5wC7hV/FrKy3wfANIs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IGKTcSzg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IGKTcSzg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06FF6C19423; Sat, 28 Feb 2026 17:37:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300245; bh=vGJ+ODU1O2pnF5slHFB5e8eITxNGC7zuB7JpGnFop2I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IGKTcSzghzwwou9FxEQcM8yOo6bt8g+uPfAC6O7WNbzZkJu8WLw/0GZ2GTX7W3BOY jvPRL9j87tyL4G/W6KRenoB6zEqfzm/nLt+3H9oU2lmZmBME9Xw77Q5toZ2DuDzyK+ uHPtna0JKyGn2saX9tOF4klUPmBOxNm0IrRtWA/xRjciZQFBJRhRvqSwNz2SYgRDKs p0gnpo9BmiOJ7t38XBqA0LYj70EBR3KX0se+3OH+UAxG9E6WdNZzpA/P/8i1/kiaNl gjU0P9uiquZny+CurVfiOCta08Abn9EAum5xi8wyKiB/IZwRdDzOrhI11Ncljy4VRR OcEi/BvMN3VRQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Szymon Wilczek , syzbot+67969ab6a2551c27f71b@syzkaller.appspotmail.com, Johannes Berg , Sasha Levin Subject: [PATCH 6.19 269/844] wifi: libertas: fix WARNING in usb_tx_block Date: Sat, 28 Feb 2026 12:23:02 -0500 Message-ID: <20260228173244.1509663-270-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Szymon Wilczek [ Upstream commit d66676e6ca96bf8680f869a9bd6573b26c634622 ] The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse. Reported-by: syzbot+67969ab6a2551c27f71b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D67969ab6a2551c27f71b Signed-off-by: Szymon Wilczek Link: https://patch.msgid.link/20251221155806.23925-1-swilczek.lx@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/marvell/libertas/if_usb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/w= ireless/marvell/libertas/if_usb.c index b3c4040257a67..924ab93b7b671 100644 --- a/drivers/net/wireless/marvell/libertas/if_usb.c +++ b/drivers/net/wireless/marvell/libertas/if_usb.c @@ -426,6 +426,8 @@ static int usb_tx_block(struct if_usb_card *cardp, uint= 8_t *payload, uint16_t nb goto tx_ret; } =20 + usb_kill_urb(cardp->tx_urb); + usb_fill_bulk_urb(cardp->tx_urb, cardp->udev, usb_sndbulkpipe(cardp->udev, cardp->ep_out), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C62D639C234; Sat, 28 Feb 2026 17:37:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300246; cv=none; b=pB3f2GnWGHHJYgDflm8MSLt7iCJ7TDcdQhtAh/AZpSX2eZHctoul+1iv2+N9XeFJiHTHdgT76xWIWMWS5gs/+kAJB4aapz84JuUMdE7ilRelAhYzknwbBE8itGcGCHxkEanzuXtGgp8KLCUWlXij5VZvYn3m2osSv8lXnqUNdjM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300246; c=relaxed/simple; bh=YJsLExZqQcIZWzMl0Y0AJkAaHe6Xs7lXlNrP0xCnjDc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uhRO1l3f7x0Hen3BNtKriQA03Txrow58d1kjReNmKTJ757HTtV6KN6FzSwzBRBtVtMcAJqfbtrHHO+SrfUAe1w4RSGkyMqW61yKCqRmJ9VDmQqPLykAim9zM4q0nBv5uqFcE/kdc1goiWpO4RRX/Fl+tetQMny+DzdOMcC3THJA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rPHLM8Gc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rPHLM8Gc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 068F8C19423; Sat, 28 Feb 2026 17:37:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300246; bh=YJsLExZqQcIZWzMl0Y0AJkAaHe6Xs7lXlNrP0xCnjDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rPHLM8GcAfUKHm3ZjTXAh6PI9bYpDzWRGfZNlsnFlJTt27mk32xGWBDV9Pm8SuZZ/ ctEme623TcIslSjiNuMqG+jbZD4H4U+rKh0YTGBTA2WJIvxUYqNUr9HpeM6uTCGAta cUf3JRbskBBAGYW1ojW3UXkhLdmpwUTL65aiq+4WEcV7lQ+pP1ymPCMK119H8DyRT5 nhoK4WU6sD4iitM2587ZMlaX0oOX/S45v3NAsc1L/2Ogfslu43zPS/xeJrxKoK0f/S V4zf+JjX8s3NaC6bJmSsAjtqGTXn5o2t4l6p/vTjtwH9qEURfuzdtHK1s7giKSRbxJ 8p62eYl4833/A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ankit Soni , Vasant Hegde , Joerg Roedel , Sasha Levin Subject: [PATCH 6.19 270/844] iommu/amd: move wait_on_sem() out of spinlock Date: Sat, 28 Feb 2026 12:23:03 -0500 Message-ID: <20260228173244.1509663-271-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ankit Soni [ Upstream commit d2a0cac10597068567d336e85fa3cbdbe8ca62bf ] With iommu.strict=3D1, the existing completion wait path can cause soft lockups under stressed environment, as wait_on_sem() busy-waits under the spinlock with interrupts disabled. Move the completion wait in iommu_completion_wait() out of the spinlock. wait_on_sem() only polls the hardware-updated cmd_sem and does not require iommu->lock, so holding the lock during the busy wait unnecessarily increases contention and extends the time with interrupts disabled. Signed-off-by: Ankit Soni Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iommu/amd/iommu.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index 0f9045ce93af1..c5f7e003d01c9 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -1180,7 +1180,12 @@ static int wait_on_sem(struct amd_iommu *iommu, u64 = data) { int i =3D 0; =20 - while (*iommu->cmd_sem !=3D data && i < LOOP_TIMEOUT) { + /* + * cmd_sem holds a monotonically non-decreasing completion sequence + * number. + */ + while ((__s64)(READ_ONCE(*iommu->cmd_sem) - data) < 0 && + i < LOOP_TIMEOUT) { udelay(1); i +=3D 1; } @@ -1432,14 +1437,13 @@ static int iommu_completion_wait(struct amd_iommu *= iommu) raw_spin_lock_irqsave(&iommu->lock, flags); =20 ret =3D __iommu_queue_command_sync(iommu, &cmd, false); + raw_spin_unlock_irqrestore(&iommu->lock, flags); + if (ret) - goto out_unlock; + return ret; =20 ret =3D wait_on_sem(iommu, data); =20 -out_unlock: - raw_spin_unlock_irqrestore(&iommu->lock, flags); - return ret; } =20 @@ -3115,13 +3119,18 @@ static void iommu_flush_irt_and_complete(struct amd= _iommu *iommu, u16 devid) raw_spin_lock_irqsave(&iommu->lock, flags); ret =3D __iommu_queue_command_sync(iommu, &cmd, true); if (ret) - goto out; + goto out_err; ret =3D __iommu_queue_command_sync(iommu, &cmd2, false); if (ret) - goto out; + goto out_err; + raw_spin_unlock_irqrestore(&iommu->lock, flags); + wait_on_sem(iommu, data); -out: + return; + +out_err: raw_spin_unlock_irqrestore(&iommu->lock, flags); + return; } =20 static inline u8 iommu_get_int_tablen(struct iommu_dev_data *dev_data) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE6AB39C22C; Sat, 28 Feb 2026 17:37:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300247; cv=none; b=Akm2n7rqUa4ZcAp8sAerXs1gLY0pDRXXae8JXa4vI4qkvd//zLmqVfEgivjcrmCaE9/a1VWguShdJiJxv4384BVzccnqzIZx1ZPJE0das16PuZ2nx9paeyWVNr+2SMlwzYsDhA9R0QPnOa20kLtJLX9Jyx10ESKWvINDJpFQB2c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300247; c=relaxed/simple; bh=jOUKICtjarUdH2jwSIzpvfw1DpKiGcF8oJMBxay09/s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qwhPVTDkVy3/1Rx/rIEodVHzeblJiFq8ZiCABbcjpGSIrL4On1mFKz8U0KrVdvSb77YdD/Ssn9WKK0tq8XeycKuDZ8eXvka43w+BklV8cke0veIFrsPh5TDtU1ejpHlBacJXalxDZG+nR+eypBDXmV6fEesV637pONhBg/rp6Fs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gbNgusUv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gbNgusUv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA0DEC19423; Sat, 28 Feb 2026 17:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300247; bh=jOUKICtjarUdH2jwSIzpvfw1DpKiGcF8oJMBxay09/s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gbNgusUvoyX8Y+sjbGNsrgZIpo8Dh2A/Ro9jia93sReFchwHppv3PumlxQZcUsoWE j8M3Bd+skCM0+sLBUNjcmJ7rrjkt/aIGTkwIPiAJuO7xe2XWPLj7c52Im9dHE9QhPn caoQzjQHHk3hnqosw9SebONevklrtm/il/qdc99VjJkyClaEn+1iCnzXFK6VtvYC+h gJNwo2wQhIXFC7dNQavgPN9HGAB1hE4367mysXj6nVXZG8OrKwXJuNT70vsPARyBqI Y5YB83iEm1LDr7DDMZ+UD8p2++NdkbwW0ebryOhBLNPPBiIOu3vhEG49w89p/Qe0Ap iUTUFubP4vItw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zenm Chen , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 271/844] wifi: rtw89: Add support for MSI AX1800 Nano (GUAX18N) Date: Sat, 28 Feb 2026 12:23:04 -0500 Message-ID: <20260228173244.1509663-272-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zenm Chen [ Upstream commit 3116f287b81fe777a00b93ab07ec3c270093b185 ] Add the ID 0db0:f0c8 to the table to support an additional RTL8832BU adapter: MSI AX1800 Nano (GUAX18N). Compile tested only. Link: https://github.com/morrownr/rtl8852bu-20250826/pull/2 Signed-off-by: Zenm Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260112004358.5516-1-zenmchen@gmail.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/rtw8852bu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852bu.c b/drivers/net/w= ireless/realtek/rtw89/rtw8852bu.c index 980d17ef68d0a..84cd3ec971f98 100644 --- a/drivers/net/wireless/realtek/rtw89/rtw8852bu.c +++ b/drivers/net/wireless/realtek/rtw89/rtw8852bu.c @@ -54,6 +54,8 @@ static const struct usb_device_id rtw_8852bu_id_table[] = =3D { .driver_info =3D (kernel_ulong_t)&rtw89_8852bu_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x0db0, 0x6931, 0xff, 0xff, 0xff), .driver_info =3D (kernel_ulong_t)&rtw89_8852bu_info }, + { USB_DEVICE_AND_INTERFACE_INFO(0x0db0, 0xf0c8, 0xff, 0xff, 0xff), + .driver_info =3D (kernel_ulong_t)&rtw89_8852bu_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3327, 0xff, 0xff, 0xff), .driver_info =3D (kernel_ulong_t)&rtw89_8852bu_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x3574, 0x6121, 0xff, 0xff, 0xff), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7ED0539D335; Sat, 28 Feb 2026 17:37:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300248; cv=none; b=WIdDcYcZseIUK7NyOSc7NkfSxqx5luTAp8XJUM78WpndJPcLlNCN82XOpvY+9d+4UlhhGpl57qZUAEVXC82+HMgjP9iCb8+hhFNU9Vu2LaFn33XPFO4c+axV9e+BRq0M/BqNemlb/6T0C1YECyliGmfSnyBlwZrO6ipymwWjE3M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300248; c=relaxed/simple; bh=ait0UnyhWWr6Thg9BUSixOwDijx3Xm4bJINamHlf2ao=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lrMTS0v8RBMAfP0QxT2UfaTt0P9OJlz7GJztWxqTkkhpbWRHK61UNQLHyD4aavYjvvZ1S7pCx1YHW78MjQWa3CZYG5Pr27LOIr0nfXCoS8/6XQt7b4mgvsjHtTW9TGroEFdQQg2tijfAdviiXUX9df1gd0FqRWyX2/4Nhgabyu4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ue33K5Ms; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ue33K5Ms" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2D65C19425; Sat, 28 Feb 2026 17:37:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300248; bh=ait0UnyhWWr6Thg9BUSixOwDijx3Xm4bJINamHlf2ao=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ue33K5Mslj/9WAQyXZAYcq90tvypHN06tvFbr8/RrK1cxvZIARCLJ3ks+hrhPk2kl SY8QmcbvioEryxFQq4GYLPBxLVB3xRFD5SePtzCNxHLtqV3RH148JLgvBwyOXj+Ot5 vuU26UyHHKFonBJ9j7XWTLjKogc3M1xXVid5akNNr0nYTOc2T8Qb3IqMAqmlxhuCrw PHUEDlhVpYzstkb0Sm484U1hploero6QTPcETvcx46nTDlLh8/8PIk3Sxrg82hJ8xL XeSbYlPPENhau6Rgf91gxRK5ThetgDK9ChdpMh569m4FUsXMPGgiBXmK7aec43y99n 8Q6rDyoFuvypw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zenm Chen , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 272/844] wifi: rtw89: Add support for D-Link VR Air Bridge (DWA-F18) Date: Sat, 28 Feb 2026 12:23:05 -0500 Message-ID: <20260228173244.1509663-273-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zenm Chen [ Upstream commit 292c0bc8acb687de7e83fc454bb98af19187b6bf ] Add the ID 2001:3323 to the table to support an additional RTL8832AU adapter: D-Link VR Air Bridge (DWA-F18). Compile tested only. Link: https://github.com/morrownr/rtw89/pull/44 Signed-off-by: Zenm Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260112004759.6028-1-zenmchen@gmail.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/rtw8852au.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852au.c b/drivers/net/w= ireless/realtek/rtw89/rtw8852au.c index 74a976c984ad8..ccdbcc178c2a4 100644 --- a/drivers/net/wireless/realtek/rtw89/rtw8852au.c +++ b/drivers/net/wireless/realtek/rtw89/rtw8852au.c @@ -52,6 +52,8 @@ static const struct usb_device_id rtw_8852au_id_table[] = =3D { .driver_info =3D (kernel_ulong_t)&rtw89_8852au_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3321, 0xff, 0xff, 0xff), .driver_info =3D (kernel_ulong_t)&rtw89_8852au_info }, + { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3323, 0xff, 0xff, 0xff), + .driver_info =3D (kernel_ulong_t)&rtw89_8852au_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x332c, 0xff, 0xff, 0xff), .driver_info =3D (kernel_ulong_t)&rtw89_8852au_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x013f, 0xff, 0xff, 0xff), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BF9339D34F; Sat, 28 Feb 2026 17:37:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300249; cv=none; b=fKTi056lZTkz7iq72W9Bgnu4PnqJ9sSxjjnEZaSaoxrn0yXflsz+3NXXBr19AqAxikpUCF6bjyOtaiim5ZlMOFwmVwEmnX0DeqNyDTWDF1JNnF+8kEAXx3+55O63M6w7EwVgfGTvMUUAWGjhwIQLlCjsV8B0fCegQaLrhXMcibo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300249; c=relaxed/simple; bh=5KRHBfRBp3ra/uV/XDPasv1VEFlqT+4bdi3ItZYYhNI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HzpCl3Nc8PIC1/g00caLaHm1YWaDfwoTx2F7F08rE7R/fPEfMp9ZZcxUg9GEIfWu0B2KghBvz8mNn+zMyd+2lKoCB4v5A+SgdkJNTeYRBP+6BRAoy7tfU9Vxkfz8GnAsb588oRo/Ywg/zVkFmqdZLC92C47O50kYlHnifvcszEQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RiIIbey9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RiIIbey9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4B60C116D0; Sat, 28 Feb 2026 17:37:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300249; bh=5KRHBfRBp3ra/uV/XDPasv1VEFlqT+4bdi3ItZYYhNI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RiIIbey9uiFjDpxYtMew9vudeyzDqsentPT+2X/ZVqD4PFw6JJ/dXWz/PYLzaWxy/ 3S582mo/DEH0yZPk3epcXZCw/1nJ5n5o+BnAPyGEYO+UR8OZZzL+ow7FQM3gz/ICI/ NTz78aYRUowVj/AAy5EV3f2Va5vDJCt/I6r688h2hNRqhxRqVeCHYvQuzhmIhWGrAM qij+1pTSi8DrxxfOVcF+u0/v0DlS9P0Jr2aRhuVLBE0uxtzNZDFC+bmTTiXx3KDieH jpW0TGhT2M06bVgxn3InpI8Jsz9gGa9Z2cVzoyy2Hda131dNFf4Cbf0zTscv0mmDgl +i6OUHG3MiA3w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 273/844] wifi: rtw89: pci: validate sequence number of TX release report Date: Sat, 28 Feb 2026 12:23:06 -0500 Message-ID: <20260228173244.1509663-274-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ping-Ke Shih [ Upstream commit 957eda596c7665f2966970fd1dcc35fe299b38e8 ] Hardware rarely reports abnormal sequence number in TX release report, which will access out-of-bounds of wd_ring->pages array, causing NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1) Call Trace: rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)] rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)] net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/cor= e/dev.c:6759 handle_softirqs+0xbe/0x290 kernel/softirq.c:601 ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)] __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423 rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)] ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0 irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314 ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202 ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220 kthread+0xea/0x110 kernel/kthread.c:376 ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287 ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 To prevent crash, validate rpp_info.seq before using. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-2-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/pci.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireles= s/realtek/rtw89/pci.c index a66fcdb0293b6..093960d7279f8 100644 --- a/drivers/net/wireless/realtek/rtw89/pci.c +++ b/drivers/net/wireless/realtek/rtw89/pci.c @@ -604,11 +604,16 @@ static void rtw89_pci_release_rpp(struct rtw89_dev *r= twdev, void *rpp) =20 info->parse_rpp(rtwdev, rpp, &rpp_info); =20 - if (rpp_info.txch =3D=3D RTW89_TXCH_CH12) { + if (unlikely(rpp_info.txch =3D=3D RTW89_TXCH_CH12)) { rtw89_warn(rtwdev, "should no fwcmd release report\n"); return; } =20 + if (unlikely(rpp_info.seq >=3D RTW89_PCI_TXWD_NUM_MAX)) { + rtw89_warn(rtwdev, "invalid seq %d\n", rpp_info.seq); + return; + } + tx_ring =3D &rtwpci->tx.rings[rpp_info.txch]; wd_ring =3D &tx_ring->wd_ring; txwd =3D &wd_ring->pages[rpp_info.seq]; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C3F047F2FF; Sat, 28 Feb 2026 17:37:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300250; cv=none; b=Rce2sY6rJ9iWjKRuERQXObrwPMcrO/+TWlYIAxdsKYSxdiy7kOD9i9uO5Ldh0ohQ0iOWYv5lUP5jdFjRqnA5cgqt5fv9ISdmY7+E6y2Lqko9rhqhH89xmwoNLX0umrDIR8T82ETMZITfx2WnNP0PKCyK2lXIIZ9ikm/hMotrDEY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300250; c=relaxed/simple; bh=FCb30k1Yk5xOQOk0x/m/+4XhFlQeC+CWlzsrZHCYduM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TvTBGDHaQxUVrRFz3a7m+M8MiDyjkNqyqTAZox60jbGCgRySMwXSoM2QURe4iZRCQ68M890J5SBwZhZRGaEGCQsLrO4hDYXOiKPHW/RLA4hKjso8piyMZsi6dq7/P3b9gKsZ+grSWMbGsk8x5QPSX1DmJEUmWw65YBhOojbCdWs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QT1/8tEc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QT1/8tEc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B155C19425; Sat, 28 Feb 2026 17:37:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300249; bh=FCb30k1Yk5xOQOk0x/m/+4XhFlQeC+CWlzsrZHCYduM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QT1/8tEc0gAVrD7zwd75xy+liT6uPe1HTfDuyF04v61x2YA/GqGPhoSDxGRcmKuQ/ 9/qKm1sHxM5wJdXC+z7/B0gKp5QjVpBXdxJY/2Z5akK6+FX966WyjrQYDTcxkB86Ie iVPgcUsVcNJiHblomOsekU1R/eGiDWhBTO6yNxWTbfm1287IsjhDVnoJ4CbQYFw41F CU2SJ3W6Cjobwrxu9aw9ClGCqWje6YWj+wsjpfsa3lzhtIMPFQ5x0Jx1voa2YMhcrW yYfb2yvvIKR2QXS3asZ3MVBw0PVOnbLZ3h5jwU816MaPIil7yg9ArCRPhaJrZ6FoXv cpcao/PzQiGtw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 274/844] wifi: rtw89: mac: correct page number for CSI response Date: Sat, 28 Feb 2026 12:23:07 -0500 Message-ID: <20260228173244.1509663-275-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ping-Ke Shih [ Upstream commit aa2a44d0d22d45d659b9f01638809b1735e46cff ] For beamforming procedure, hardware reserve memory page for CSI response. The unit of register is (value - 1), so add one accordingly as expected. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-7-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/mac_be.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtw89/mac_be.c b/drivers/net/wire= less/realtek/rtw89/mac_be.c index 9b9e646487346..dee5ff71b75fe 100644 --- a/drivers/net/wireless/realtek/rtw89/mac_be.c +++ b/drivers/net/wireless/realtek/rtw89/mac_be.c @@ -1175,7 +1175,7 @@ static int resp_pktctl_init_be(struct rtw89_dev *rtwd= ev, u8 mac_idx) =20 reg =3D rtw89_mac_reg_by_idx(rtwdev, R_BE_RESP_CSI_RESERVED_PAGE, mac_idx= ); rtw89_write32_mask(rtwdev, reg, B_BE_CSI_RESERVED_START_PAGE_MASK, qt_cfg= .pktid); - rtw89_write32_mask(rtwdev, reg, B_BE_CSI_RESERVED_PAGE_NUM_MASK, qt_cfg.p= g_num); + rtw89_write32_mask(rtwdev, reg, B_BE_CSI_RESERVED_PAGE_NUM_MASK, qt_cfg.p= g_num + 1); =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAA4E39DB9B; Sat, 28 Feb 2026 17:37:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300250; cv=none; b=HJGfFa6LL/iXeJivmNQ4bJZ0/FMlboo6YRJGjY18mr+VNTF02VWIvDjRML69py6AUXliU7IQ0ai/00KBxpvkWCnbAh6KpNnsTTertrAiI9ylrs/+JxNzrS264OEnO+nFgZdiVaQylzJso4i4L7OQsBH47ouvcltV+pinyLhykHM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300250; c=relaxed/simple; bh=718sXwywzZnOib7WcAyrJJQedrPJtHdSSi9N3MuPfcQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=km6+G4oxYEpMCvA1J1IvqenmTMkNPU86BiV9L4QH5+J6pwEJumdBrwf9i0PxGPRZn9bn0XCFBJDRfQTVY20xHlFUQJjs4HeCuIr3iyuPGhbUvs1NN8erBwnYoqJcBPdbutg4QvbrsdaGtdaaKu00AktatLL7hhe39d1tgP44w0k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ALxapURR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ALxapURR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32764C19425; Sat, 28 Feb 2026 17:37:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300250; bh=718sXwywzZnOib7WcAyrJJQedrPJtHdSSi9N3MuPfcQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ALxapURRpqyNHK16qUQbFvTTUBWTqP1s+1SI1VuarLFLZDAN04N1q9iRJBZHXFoOZ MFBmotDDYyV7+Fd/8SfykkI6htKHwgMKUlrt9cIaA2myt2J1I/Wak8ikgzOHXpGSt6 F2AYqEJwX6ET5BVXPEtUWmER16+UQbY1zZmwl2jN64mGWGildR1IWC/5KMPpb/aSXe ZzDgvJCx0bDPX4SGf9nAuliyn85r6apQjnbU0vOR1bwVJmTnfWOV3Ps+Gx785UNFJn f0HWRN/F1cwg1h0/ePInDCXJlKFKYo42VyQ6O+2p27dbqjlakQ1A+O4YUuAo/UbDRf aLmFwduk2X8PA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chin-Yen Lee , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 275/844] wifi: rtw89: wow: add reason codes for disassociation in WoWLAN mode Date: Sat, 28 Feb 2026 12:23:08 -0500 Message-ID: <20260228173244.1509663-276-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chin-Yen Lee [ Upstream commit 2fd8f953f25173d14981d8736b6f5bfcd757e51b ] Some APs disconnect clients by sending a Disassociation frame rather than a Deauthentication frame. Since these frames use different reason codes in WoWLAN mode, this commit adds support for handling Disassociation to prevent missed disconnection events. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-3-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/wow.c | 4 ++++ drivers/net/wireless/realtek/rtw89/wow.h | 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/wow.c b/drivers/net/wireles= s/realtek/rtw89/wow.c index 46aba4cb2ee9e..534966b4d9c43 100644 --- a/drivers/net/wireless/realtek/rtw89/wow.c +++ b/drivers/net/wireless/realtek/rtw89/wow.c @@ -809,6 +809,10 @@ static void rtw89_wow_show_wakeup_reason(struct rtw89_= dev *rtwdev) =20 reason =3D rtw89_read8(rtwdev, wow_reason_reg); switch (reason) { + case RTW89_WOW_RSN_RX_DISASSOC: + wakeup.disconnect =3D true; + rtw89_debug(rtwdev, RTW89_DBG_WOW, "WOW: Rx disassoc\n"); + break; case RTW89_WOW_RSN_RX_DEAUTH: wakeup.disconnect =3D true; rtw89_debug(rtwdev, RTW89_DBG_WOW, "WOW: Rx deauth\n"); diff --git a/drivers/net/wireless/realtek/rtw89/wow.h b/drivers/net/wireles= s/realtek/rtw89/wow.h index d2ba6cebc2a6b..71e07f482174f 100644 --- a/drivers/net/wireless/realtek/rtw89/wow.h +++ b/drivers/net/wireless/realtek/rtw89/wow.h @@ -33,6 +33,7 @@ enum rtw89_wake_reason { RTW89_WOW_RSN_RX_PTK_REKEY =3D 0x1, RTW89_WOW_RSN_RX_GTK_REKEY =3D 0x2, + RTW89_WOW_RSN_RX_DISASSOC =3D 0x4, RTW89_WOW_RSN_RX_DEAUTH =3D 0x8, RTW89_WOW_RSN_DISCONNECT =3D 0x10, RTW89_WOW_RSN_RX_MAGIC_PKT =3D 0x21, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B54C939DBB9; Sat, 28 Feb 2026 17:37:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300251; cv=none; b=e9PfMNV9ZePvaAWIr3z+sfmFAy+vKDvNU7mh8TGzgZiwjdTNMv3Y02hyWFRlBXL10KLLrLzQqK6hYme7YLkUbhYA8Sh2YXaKFBVqLrA8aQ1N9LbBxtseBgUpx4by7lIrY9MejgEBgQLGBPYlvWgk0CSJT0tqvyiM6W2uaAqG9Lg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300251; c=relaxed/simple; bh=lFIQsHIrqvNn21gjj9XgQaLlMHDAjX6d1NCnweCJJc8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jySEppH6GmyeuxglNL8CvgiNzRSwg88LyW/J4Am/nk4afK0gGYlpUlb+NJo5laqpHqDORl0fTjqHcKHIktVq+Bj0o99dFHDlpN363fsqGmL/o3mBeZHZ7dk47PqPXfeUuZeMyNZpR0ISiRPaOIBm4jPU2+IOvZPiR02SaTEuIOs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hFA2Mxyn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hFA2Mxyn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D1A6C19425; Sat, 28 Feb 2026 17:37:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300251; bh=lFIQsHIrqvNn21gjj9XgQaLlMHDAjX6d1NCnweCJJc8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hFA2Mxyn/HIVaf8SeK5d0hjaKyTLKbgNT38NVqfj/K7rve8VZpDiONTO+6sWxI6N2 6wQgwX0PtYlqHKi++cAxgKQTo9Qq6HxLTIGGRtcYrNxB2LshXeLy4MAIzoyzpEKgMd XyHrBGZFbTdBj5DFzR93bxfgADtW880aUIap9nKXyGweQyZ3+Vl9jUIJuK8YmlolNZ WJa95aO56TbqlT7AKo1oFBmhIYOwG8McONEZnwErtO7k7g3gqRgvKXOMgbzL5JlPQo /f+0v7cDc/4CiaHtUG3lWNeZWlrg8rWbuwFbOE8sIFBPHV1k3CksbwfTZOr/rrR0zv 9+hb312txZtrg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shawn Lin , Manivannan Sadhasivam , Sasha Levin Subject: [PATCH 6.19 276/844] PCI: dw-rockchip: Disable BAR 0 and BAR 1 for Root Port Date: Sat, 28 Feb 2026 12:23:09 -0500 Message-ID: <20260228173244.1509663-277-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shawn Lin [ Upstream commit b5d712e5b87fc56ff838684afb1bae359eb8069f ] Some Rockchip PCIe Root Ports report bogus size of 1GiB for the BAR memories and they cause below resource allocation issue during probe. pci 0000:00:00.0: [1d87:3588] type 01 class 0x060400 PCIe Root Port pci 0000:00:00.0: BAR 0 [mem 0x00000000-0x3fffffff] pci 0000:00:00.0: BAR 1 [mem 0x00000000-0x3fffffff] pci 0000:00:00.0: ROM [mem 0x00000000-0x0000ffff pref] ... pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: assigned pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: can't assign; no space pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: failed to assign pci 0000:00:00.0: ROM [mem 0xf0200000-0xf020ffff pref]: assigned pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: releasing pci 0000:00:00.0: ROM [mem 0xf0200000-0xf020ffff pref]: releasing pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: assigned pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: can't assign; no space pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: failed to assign Since there is no use of the Root Port BAR memories, disable both of them. Signed-off-by: Shawn Lin [mani: reworded the description and comment] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/1766570461-138256-1-git-send-email-shawn.lin= @rock-chips.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-dw-rockchip.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/co= ntroller/dwc/pcie-dw-rockchip.c index bf8ec3ca6f689..a3daac74d3f18 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -80,6 +80,8 @@ #define PCIE_LINKUP_MASK GENMASK(17, 16) #define PCIE_LTSSM_STATUS_MASK GENMASK(5, 0) =20 +#define PCIE_TYPE0_HDR_DBI2_OFFSET 0x100000 + struct rockchip_pcie { struct dw_pcie pci; void __iomem *apb_base; @@ -292,6 +294,8 @@ static int rockchip_pcie_host_init(struct dw_pcie_rp *p= p) if (irq < 0) return irq; =20 + pci->dbi_base2 =3D pci->dbi_base + PCIE_TYPE0_HDR_DBI2_OFFSET; + ret =3D rockchip_pcie_init_irq_domain(rockchip); if (ret < 0) dev_err(dev, "failed to init irq domain\n"); @@ -302,6 +306,10 @@ static int rockchip_pcie_host_init(struct dw_pcie_rp *= pp) rockchip_pcie_configure_l1ss(pci); rockchip_pcie_enable_l0s(pci); =20 + /* Disable Root Ports BAR0 and BAR1 as they report bogus size */ + dw_pcie_writel_dbi2(pci, PCI_BASE_ADDRESS_0, 0x0); + dw_pcie_writel_dbi2(pci, PCI_BASE_ADDRESS_1, 0x0); + return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7944439EE0A; Sat, 28 Feb 2026 17:37:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300252; cv=none; b=StddXXUD6oJADDkQbErf29lhY6D9Lq7bOixYtJeM+OSj371jqG6NWDj0k7NOa0JUxUhWPEuqf66rL2Ik2nTNbukivLigGugEx+A8Ve5hkNQlPjsYBumldXGkSd+o3rc1r53Fofy1k3nXMp3W71QZxAlkmuccx1BFVw33B/NJ9os= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300252; c=relaxed/simple; bh=mhbAl8sJyvyAjf4RPrZXtW5aXsE0+cHJpp8tFN+sMJw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eYr5q9eHC6WON1s1IHk1V+fJsrXxRatVcUekMxHo96LzcsrG7RRlpfm1/5O3sVDrgH8WhlsRDTMwHdKdPZIYo23Rd53HI3BYPHYTiWHeCO7KXaJviec5P5ZQrO6vxlmkq+m14klvn0jRKVfaF8OUnd5lzO6MT8DyHcd8ixG3hdo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F2jVH27t; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F2jVH27t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC1B4C116D0; Sat, 28 Feb 2026 17:37:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300252; bh=mhbAl8sJyvyAjf4RPrZXtW5aXsE0+cHJpp8tFN+sMJw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F2jVH27tCiRnK4HhYW4PdEbGd88Yn8W8SopGSXUjX8/ynJAKetYchns0Sd+DiNaXp 32pYLMxUeD7lihm62223Pw0T8T3XnGBPV23opjrBptCGwc80mMY90tSG+8NR6QZVu8 P5WCdMhuG7ac8rBQ76zGzB6Qk/MxQLz5DF3dmwf45a/9aEMa1QEgN1+FhA5QsrKtzB Gz1BEOpHswypWo23KPrBQnNDECyY3FH2PfLPe7/5B4qGw5lOQDcJLjXgY1TexFE3SK GC/ZI9E0H8i28/Zls7QrVVe9O1BUI62HUclz1o2mSegyifM47oUjSyuGklzApmCskZ ZiRPC20OVC6+g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 277/844] wifi: rtw89: disable EHT protocol by chip capabilities Date: Sat, 28 Feb 2026 12:23:10 -0500 Message-ID: <20260228173244.1509663-278-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ping-Ke Shih [ Upstream commit 7fd36ffedeedc97c44a10249a3f12d471bb2dc26 ] For certain chip models, EHT protocol is disabled, and driver must follow the capabilities. Otherwise, chips become unusable. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-5-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/core.c | 2 +- drivers/net/wireless/realtek/rtw89/core.h | 1 + drivers/net/wireless/realtek/rtw89/fw.h | 4 ++++ drivers/net/wireless/realtek/rtw89/mac.c | 5 +++++ 4 files changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wirele= ss/realtek/rtw89/core.c index c5934e4eff711..4b86a7c4fe329 100644 --- a/drivers/net/wireless/realtek/rtw89/core.c +++ b/drivers/net/wireless/realtek/rtw89/core.c @@ -5238,7 +5238,7 @@ static void rtw89_init_eht_cap(struct rtw89_dev *rtwd= ev, u8 val, val_mcs13; int sts =3D 8; =20 - if (chip->chip_gen =3D=3D RTW89_CHIP_AX) + if (chip->chip_gen =3D=3D RTW89_CHIP_AX || hal->no_eht) return; =20 if (hal->no_mcs_12_13) diff --git a/drivers/net/wireless/realtek/rtw89/core.h b/drivers/net/wirele= ss/realtek/rtw89/core.h index 92636cfc5ca58..a032a20d4c23b 100644 --- a/drivers/net/wireless/realtek/rtw89/core.h +++ b/drivers/net/wireless/realtek/rtw89/core.h @@ -5039,6 +5039,7 @@ struct rtw89_hal { bool support_cckpd; bool support_igi; bool no_mcs_12_13; + bool no_eht; =20 atomic_t roc_chanctx_idx; u8 roc_link_index; diff --git a/drivers/net/wireless/realtek/rtw89/fw.h b/drivers/net/wireless= /realtek/rtw89/fw.h index cedb4a47a769c..ba7c332911310 100644 --- a/drivers/net/wireless/realtek/rtw89/fw.h +++ b/drivers/net/wireless/realtek/rtw89/fw.h @@ -42,6 +42,10 @@ struct rtw89_c2hreg_phycap { #define RTW89_C2HREG_PHYCAP_W0_BW GENMASK(31, 24) #define RTW89_C2HREG_PHYCAP_W1_TX_NSS GENMASK(7, 0) #define RTW89_C2HREG_PHYCAP_W1_PROT GENMASK(15, 8) +#define RTW89_C2HREG_PHYCAP_W1_PROT_11N 1 +#define RTW89_C2HREG_PHYCAP_W1_PROT_11AC 2 +#define RTW89_C2HREG_PHYCAP_W1_PROT_11AX 3 +#define RTW89_C2HREG_PHYCAP_W1_PROT_11BE 4 #define RTW89_C2HREG_PHYCAP_W1_NIC GENMASK(23, 16) #define RTW89_C2HREG_PHYCAP_W1_WL_FUNC GENMASK(31, 24) #define RTW89_C2HREG_PHYCAP_W2_HW_TYPE GENMASK(7, 0) diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireles= s/realtek/rtw89/mac.c index 6734e5d5a5e22..fbce71cd5a05c 100644 --- a/drivers/net/wireless/realtek/rtw89/mac.c +++ b/drivers/net/wireless/realtek/rtw89/mac.c @@ -3061,6 +3061,7 @@ static int rtw89_mac_setup_phycap_part0(struct rtw89_= dev *rtwdev) struct rtw89_efuse *efuse =3D &rtwdev->efuse; struct rtw89_mac_c2h_info c2h_info =3D {}; struct rtw89_hal *hal =3D &rtwdev->hal; + u8 protocol; u8 tx_nss; u8 rx_nss; u8 tx_ant; @@ -3108,6 +3109,10 @@ static int rtw89_mac_setup_phycap_part0(struct rtw89= _dev *rtwdev) rtw89_debug(rtwdev, RTW89_DBG_FW, "TX path diversity=3D%d\n", hal->tx_pat= h_diversity); rtw89_debug(rtwdev, RTW89_DBG_FW, "Antenna diversity=3D%d\n", hal->ant_di= versity); =20 + protocol =3D u32_get_bits(phycap->w1, RTW89_C2HREG_PHYCAP_W1_PROT); + if (protocol < RTW89_C2HREG_PHYCAP_W1_PROT_11BE) + hal->no_eht =3D true; + return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA90C39EE33; Sat, 28 Feb 2026 17:37:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300253; cv=none; b=FspHICaRWdKQpdNfZgzPeMhVKO6VAgeDgVz6sSCycByPIFxSFwwY5B1JUhOdPuHbRqUCH2ZqWWVZK8x7HAksnA8W7p7jwKvXhxEqPxr0QXIrx1E9llYvFxvzaqgzQX5k0v5Qo6JDHh5i3D7phWuM1RKw2inTDWXjZqmwg6+DWLU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300253; c=relaxed/simple; bh=lcDeFNBWSFo8oY08B/UekAKMABrcudq9S4nux/vEcbQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hNLkc4Cw0rmVT/g6DhX4aT8fA+5NkkPCsjDjxYBWLLti8M2LJglyiAzG7DdNdA2EeuD/XI2xbg5gkawtv2I1TVtTB/GsrJRIB/o9RNeSqPL+acLnxTh1oJA8IiF1Y7QgWtMferUuLSbGyEqK3YmqS4VgJRJun8tq2a1eQmkQE9E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E0oiCI3M; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E0oiCI3M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A11BFC116D0; Sat, 28 Feb 2026 17:37:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300253; bh=lcDeFNBWSFo8oY08B/UekAKMABrcudq9S4nux/vEcbQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E0oiCI3MJIc7esWBPOswR2UiOD3La9Zg0abhD5PWK+fWnMzRCGmalwjuE9hIHzcUW 80EFL9am3t1WOPilOXk8RR9RrEFaeTiCKaCHbfmlTfjvIrYz2rRY40XubTS7l9S3Dx i6gpXhLebccd4VRpzZTGSX3j9lG7BjDaAthM592rG15g/75rG8MY55XTm8IsdeQqjA T9+Gti4kMK7FIBn9IYUS2ghXdwbKIcinDhD6VejB3GiwTbPQFfxdTYvR04a40IDdgL D0GwLzPwX5wvfO3ETaZQrt9jtCAlTCMYvc7ms3NqC9ZVlDCfOLrKpXPE6IYh27rXKS 3vXSpD7d5voOg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ross Vandegrift , Baochen Qiang , Mark Pearson , Jeff Johnson , Sasha Levin Subject: [PATCH 6.19 278/844] wifi: ath11k: add pm quirk for Thinkpad Z13/Z16 Gen1 Date: Sat, 28 Feb 2026 12:23:11 -0500 Message-ID: <20260228173244.1509663-279-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ross Vandegrift [ Upstream commit 4015b1972763d7d513172276e51439f37e622a92 ] Z16 Gen1 has the wakeup-from-suspend issues from [1] but was never added to the appropriate quirk list. I've tested this patch on top of 6.18.2, it fixes the issue for me on 21D4 Mark Pearson provided the other product IDs covering the second Z16 Gen1 and both Z13 Gen1 identifiers. They share the same firmware, and folks in the bugzilla report do indeed see the problem on Z13. [1] - https://bugzilla.kernel.org/show_bug.cgi?id=3D219196 Signed-off-by: Ross Vandegrift Reviewed-by: Baochen Qiang Tested-by: Mark Pearson Reviewed-by: Mark Pearson Link: https://patch.msgid.link/wj7o2kmb7g54stdjvxp2hjqrnutnq3jbf4s2uh4ctvml= xdq7tf@nbkj2ebakhrd Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/ath/ath11k/core.c | 28 ++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/= ath/ath11k/core.c index 06b4df2370e95..78a1b0edd8b45 100644 --- a/drivers/net/wireless/ath/ath11k/core.c +++ b/drivers/net/wireless/ath/ath11k/core.c @@ -994,6 +994,34 @@ static const struct dmi_system_id ath11k_pm_quirk_tabl= e[] =3D { DMI_MATCH(DMI_PRODUCT_NAME, "21F9"), }, }, + { + .driver_data =3D (void *)ATH11K_PM_WOW, + .matches =3D { /* Z13 G1 */ + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "21D2"), + }, + }, + { + .driver_data =3D (void *)ATH11K_PM_WOW, + .matches =3D { /* Z13 G1 */ + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "21D3"), + }, + }, + { + .driver_data =3D (void *)ATH11K_PM_WOW, + .matches =3D { /* Z16 G1 */ + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "21D4"), + }, + }, + { + .driver_data =3D (void *)ATH11K_PM_WOW, + .matches =3D { /* Z16 G1 */ + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "21D5"), + }, + }, {} }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9210148032D; Sat, 28 Feb 2026 17:37:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300254; cv=none; b=OlReT7mLgMfq5S7NIRAIhwgefv/PY/ZhGA3Wwy9nHtiy7bouF9pJm152VaWF6dXMMBuxA46guNzPYmWGYc1hh/V7sWhb+Kp3+iWnUx8X+yJgitDJAqpxAOxYvHacsnDIFDN1fMIrjHCnQEo4DosN4ls2O1gzKvSYTgDM8cDBQdM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300254; c=relaxed/simple; bh=CgdJkVn+mWXtfvFOcJ9EKUqPHf17hvlYvkTrqvxh6AI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p2Cde2khUb1kuJ509j8Y02sxdFXIDJlel/2qEHtvMH7Lie9G5ZgfeFrKF6d/WQCu5LfzT2cnw1I1M169ddvkfLwH3IsvWQyndbS8pBOcDTDP2rxvPSJ2aq8n0yMRzbfVN/L8dr8TDkhqrcVkLdnUVpGVELmNadi37EOTEWcPPj4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eyQojtHJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eyQojtHJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE0F1C19424; Sat, 28 Feb 2026 17:37:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300254; bh=CgdJkVn+mWXtfvFOcJ9EKUqPHf17hvlYvkTrqvxh6AI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eyQojtHJbHX2SW5o/jC9dXgb6cbDSZb/O+bQszEvMVZx002eALxZI2VQhLPHhx1Uj lOH1zwHvY4zfVv5yWVjKeJ9D6HommUxA97cPGLcSawtLzhKQgWhI0V0tsMYMGSUpjc aY6sQGADWP211tVKbx5071mmJkTMFVUGAHBg+SKbo5LgUIP5vroth3YYSchfn+uhxc vb+vXiijIYl+UPK8t5zFNyJ4YViyJmOJbUGwfuaWkr8x2drMPOBkI0zGqUpCD3zk5R 55NikfTOvSthRne+bTm/pd2XF4OJkFrw/ZDS2WjdnM+4h68BuvuVzw20cs3yWYqUBO P+VYSz00PAXKw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Qian Zhang , Baochen Qiang , Jeff Johnson , Sasha Levin Subject: [PATCH 6.19 279/844] wifi: ath11k: Fix failure to connect to a 6 GHz AP Date: Sat, 28 Feb 2026 12:23:12 -0500 Message-ID: <20260228173244.1509663-280-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Qian Zhang [ Upstream commit 0bc8c48de6f06c0cac52dde024ffda4433de6234 ] STA fails to connect to a 6 GHz AP with the following errors: ath11k_pci 0000:01:00.0: failed to handle chan list with power type 1 wlp1s0: deauthenticating from c8:a3:e8:dd:41:e3 by local choice (Reason: 3= =3DDEAUTH_LEAVING) ath11k_reg_handle_chan_list() treats the update as redundant and returns -EINVAL. That causes the connection attempt to fail. Avoid unnecessary validation during association. Apply the regulatory redundant check only when the power type is IEEE80211_REG_UNSET_AP, which only occurs during core initialization. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_L= ITE-3.6510.41 Signed-off-by: Qian Zhang Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260108034607.812885-1-qian.zhang@oss.qualc= omm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/ath/ath11k/reg.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/a= th/ath11k/reg.c index d62a2014315a0..49b79648752cf 100644 --- a/drivers/net/wireless/ath/ath11k/reg.c +++ b/drivers/net/wireless/ath/ath11k/reg.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: BSD-3-Clause-Clear /* * Copyright (c) 2018-2019 The Linux Foundation. All rights reserved. - * Copyright (c) 2021-2025 Qualcomm Innovation Center, Inc. All rights res= erved. + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. */ #include =20 @@ -926,8 +926,11 @@ int ath11k_reg_handle_chan_list(struct ath11k_base *ab, */ if (ab->default_regd[pdev_idx] && !ab->new_regd[pdev_idx] && !memcmp((char *)ab->default_regd[pdev_idx]->alpha2, - (char *)reg_info->alpha2, 2)) - goto retfail; + (char *)reg_info->alpha2, 2) && + power_type =3D=3D IEEE80211_REG_UNSET_AP) { + ath11k_reg_reset_info(reg_info); + return 0; + } =20 /* Intersect new rules with default regd if a new country setting was * requested, i.e a default regd was already set during initialization --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A0D7B39F53B; Sat, 28 Feb 2026 17:37:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300255; cv=none; b=jgn9Bft4n1EZ7jiYKKon1x3SEDtUn0HLXiPA1NumjPLBjpY9Uhfg6o5nsg3C72Ni0pwcpvZHZDR7f4ErqSUMr42ju3tkuFCglv7p85/sFE5wz0yAMdMHVYnacSnMyzQEn5QlOpdHrdCKwIEcIJaoW6LCmrXwr0zXAIY1LIU6CBo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300255; c=relaxed/simple; bh=N4rOEOuxRopNQ2bu29DKEsZGH+R7k0QZK6UImoKM7Vk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WqXBLMoaYL6HZrrKQUEmXAfT5hkjJkDyoAaYvkxw7OWPEHr+G/SZ1y753em1yoDuB0qyvX/4qJ8r3jjXVoZt7cZTJtH7KGWI1D1Bdtsdx4ZZxPjeMKYDh1NUVJsI7o5R6q+QJIjS+EEjid3ZspcAaaQCM38m72LHPS68TUR+u1c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fpUqmxnX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fpUqmxnX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A85A0C2BC87; Sat, 28 Feb 2026 17:37:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300255; bh=N4rOEOuxRopNQ2bu29DKEsZGH+R7k0QZK6UImoKM7Vk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fpUqmxnX6eWLVddGpShAh4hm0f84VmnElkxQXs7Vfd6oS6suFNEtQrwPExXVBSAzt r5gUd16ldMgjRoHigtGwTeG4In8zLuIuQ3Dd8mgmkIPXPqaETTpTjCrhXfV5QoF5mE GcpLzLK691o4wT8F2cvq5MSObGsQUfAWhwh7WI3AdRm4mQotqbmliWRYF9k1MbLzZa azc9WsR9eiyDQzqn78CLqVh2ukJl+OkB5pBgdpQ2Om75crCUKCeifjXcMRdrcs2Qfj zdSJ5g/eqdcMy9piDLRKr0pffYJ1X5kt0v4WEjltmv15Z2w4QOApQNSBE+7PKoN4QV 6F/9IrU806QGw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Baochen Qiang , Vasanthakumar Thiagarajan , Jeff Johnson , Sasha Levin Subject: [PATCH 6.19 280/844] wifi: ath12k: fix preferred hardware mode calculation Date: Sat, 28 Feb 2026 12:23:13 -0500 Message-ID: <20260228173244.1509663-281-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Baochen Qiang [ Upstream commit 7f852de0003219c431a6f2ffd951fd82a4673660 ] For single pdev device like WCN7850/QCC2072, preferred_hw_mode is initialized to WMI_HOST_HW_MODE_SINGLE. Later when firmware sends supported modes to host, each mode is compared with the initial one and if the priority of the new mode is higher, update the parameter and store mode capability. For WCN7850, this does not result in issue, as one of the supported mode indeed has a higher priority. However the only available mode of QCC2072 at this stage is WMI_HOST_HW_MODE_SINGLE, which fails the comparison, hence mode capability is not stored. Subsequently driver initialization fails. Fix it by accepting a mode with the same priority. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SIL= ICONZ-1.115823.3 Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-4-fc8ce1e= 43969@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/ath/ath12k/wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/a= th/ath12k/wmi.c index 3ce5fcb0e4600..12f4d378f50d4 100644 --- a/drivers/net/wireless/ath/ath12k/wmi.c +++ b/drivers/net/wireless/ath/ath12k/wmi.c @@ -4545,7 +4545,7 @@ static int ath12k_wmi_hw_mode_caps(struct ath12k_base= *soc, =20 pref =3D soc->wmi_ab.preferred_hw_mode; =20 - if (ath12k_hw_mode_pri_map[mode] < ath12k_hw_mode_pri_map[pref]) { + if (ath12k_hw_mode_pri_map[mode] <=3D ath12k_hw_mode_pri_map[pref]) { svc_rdy_ext->pref_hw_mode_caps =3D *hw_mode_caps; soc->wmi_ab.preferred_hw_mode =3D mode; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F36839F557; Sat, 28 Feb 2026 17:37:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300256; cv=none; b=VgwLSPpo/BQXXO8fCBggsGuKUJOjfh87y7KWnope8ZV8pFgJB/qG83RpMAdHBFfs3XHLwmEBZAlwYg+UnQKpF/ufLYiVylctObMlcMYvpxraZujvkgvIqXqgi4pcDfYZ1HQ7hJbX52dGH0KBKmqcZ4PldW9ZNfqq91XcarV6vxQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300256; c=relaxed/simple; bh=qAzAVjQg2F7q+HOQT07q23f09EcjIIYvY67EeBdClVU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rtc+hNxyO6p8Jx2XNplb9rVitP0Kc+JfuNyXsKR0Rf7EH5zrMii5X10smhtVc2x5unPgNHVu2umBn5U7pP0uEKd7xyx/w/nDCn/VYe9/enZQgpLQEfycDilYYaafAAmq9y4fvqATKMDN+BoPMj2erYR9wbTRJGPB0gTBfp23/nQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aoYojGtS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aoYojGtS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC518C116D0; Sat, 28 Feb 2026 17:37:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300256; bh=qAzAVjQg2F7q+HOQT07q23f09EcjIIYvY67EeBdClVU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aoYojGtSwuoqzQ3CA+Y5+iSW1TTj9DOXV7oGSUhSq/kM87NwXvF2geBE/SypHZx3n dCPPp3YvCSif1x6+mAJk5zP2+ObJGoMDgJ3sySSDJUaTingD4ohJVW66LmbHL+lEXC xAuDCRurUnvkQEzOVgObiq1J67AyoF0ndoil+brda2L3QoWRytXVYIkQmGd/yy+Fvn XWCG/QxMW0eW/4QRvjsUtugV0zfa57MkZs+EUgDdDQMygkd46oOKMORTeDV3YyfR2P lTt0jWoK4U7Ht2jBOI7GFhjiGrNEFescfYu8siOnO3G8VHZnQM5KkG8v8D8JRVT1M2 QCtzWMUAtmzeQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Baochen Qiang , Vasanthakumar Thiagarajan , Jeff Johnson , Sasha Levin Subject: [PATCH 6.19 281/844] wifi: ath12k: fix mac phy capability parsing Date: Sat, 28 Feb 2026 12:23:14 -0500 Message-ID: <20260228173244.1509663-282-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Baochen Qiang [ Upstream commit b5151c9b6e3a347416a4b4b55fc00195526d8771 ] Currently ath12k_pull_mac_phy_cap_svc_ready_ext() assumes only one band supported in each phy, hence it skips 5 GHz band if 2 GHz band support is detected. This does not work for device which gets only one phy but has both bands supported, such as QCC2072. Change to check each band individually to fix this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SIL= ICONZ-1.115823.3 Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-6-fc8ce1e= 43969@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/ath/ath12k/wmi.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/a= th/ath12k/wmi.c index 12f4d378f50d4..1613492b38350 100644 --- a/drivers/net/wireless/ath/ath12k/wmi.c +++ b/drivers/net/wireless/ath/ath12k/wmi.c @@ -496,6 +496,7 @@ ath12k_pull_mac_phy_cap_svc_ready_ext(struct ath12k_wmi= _pdev *wmi_handle, struct ath12k_band_cap *cap_band; struct ath12k_pdev_cap *pdev_cap =3D &pdev->cap; struct ath12k_fw_pdev *fw_pdev; + u32 supported_bands; u32 phy_map; u32 hw_idx, phy_idx =3D 0; int i; @@ -519,14 +520,19 @@ ath12k_pull_mac_phy_cap_svc_ready_ext(struct ath12k_w= mi_pdev *wmi_handle, return -EINVAL; =20 mac_caps =3D wmi_mac_phy_caps + phy_idx; + supported_bands =3D le32_to_cpu(mac_caps->supported_bands); + + if (!(supported_bands & WMI_HOST_WLAN_2GHZ_CAP) && + !(supported_bands & WMI_HOST_WLAN_5GHZ_CAP)) + return -EINVAL; =20 pdev->pdev_id =3D ath12k_wmi_mac_phy_get_pdev_id(mac_caps); pdev->hw_link_id =3D ath12k_wmi_mac_phy_get_hw_link_id(mac_caps); - pdev_cap->supported_bands |=3D le32_to_cpu(mac_caps->supported_bands); + pdev_cap->supported_bands |=3D supported_bands; pdev_cap->ampdu_density =3D le32_to_cpu(mac_caps->ampdu_density); =20 fw_pdev =3D &ab->fw_pdev[ab->fw_pdev_count]; - fw_pdev->supported_bands =3D le32_to_cpu(mac_caps->supported_bands); + fw_pdev->supported_bands =3D supported_bands; fw_pdev->pdev_id =3D ath12k_wmi_mac_phy_get_pdev_id(mac_caps); fw_pdev->phy_id =3D le32_to_cpu(mac_caps->phy_id); ab->fw_pdev_count++; @@ -535,10 +541,12 @@ ath12k_pull_mac_phy_cap_svc_ready_ext(struct ath12k_w= mi_pdev *wmi_handle, * band to band for a single radio, need to see how this should be * handled. */ - if (le32_to_cpu(mac_caps->supported_bands) & WMI_HOST_WLAN_2GHZ_CAP) { + if (supported_bands & WMI_HOST_WLAN_2GHZ_CAP) { pdev_cap->tx_chain_mask =3D le32_to_cpu(mac_caps->tx_chain_mask_2g); pdev_cap->rx_chain_mask =3D le32_to_cpu(mac_caps->rx_chain_mask_2g); - } else if (le32_to_cpu(mac_caps->supported_bands) & WMI_HOST_WLAN_5GHZ_CA= P) { + } + + if (supported_bands & WMI_HOST_WLAN_5GHZ_CAP) { pdev_cap->vht_cap =3D le32_to_cpu(mac_caps->vht_cap_info_5g); pdev_cap->vht_mcs =3D le32_to_cpu(mac_caps->vht_supp_mcs_5g); pdev_cap->he_mcs =3D le32_to_cpu(mac_caps->he_supp_mcs_5g); @@ -548,8 +556,6 @@ ath12k_pull_mac_phy_cap_svc_ready_ext(struct ath12k_wmi= _pdev *wmi_handle, WMI_NSS_RATIO_EN_DIS_GET(mac_caps->nss_ratio); pdev_cap->nss_ratio_info =3D WMI_NSS_RATIO_INFO_GET(mac_caps->nss_ratio); - } else { - return -EINVAL; } =20 /* tx/rx chainmask reported from fw depends on the actual hw chains used, @@ -565,7 +571,7 @@ ath12k_pull_mac_phy_cap_svc_ready_ext(struct ath12k_wmi= _pdev *wmi_handle, pdev_cap->rx_chain_mask_shift =3D find_first_bit((unsigned long *)&pdev_cap->rx_chain_mask, 32); =20 - if (le32_to_cpu(mac_caps->supported_bands) & WMI_HOST_WLAN_2GHZ_CAP) { + if (supported_bands & WMI_HOST_WLAN_2GHZ_CAP) { cap_band =3D &pdev_cap->band[NL80211_BAND_2GHZ]; cap_band->phy_id =3D le32_to_cpu(mac_caps->phy_id); cap_band->max_bw_supported =3D le32_to_cpu(mac_caps->max_bw_supported_2g= ); @@ -585,7 +591,7 @@ ath12k_pull_mac_phy_cap_svc_ready_ext(struct ath12k_wmi= _pdev *wmi_handle, le32_to_cpu(mac_caps->he_ppet2g.ppet16_ppet8_ru3_ru0[i]); } =20 - if (le32_to_cpu(mac_caps->supported_bands) & WMI_HOST_WLAN_5GHZ_CAP) { + if (supported_bands & WMI_HOST_WLAN_5GHZ_CAP) { cap_band =3D &pdev_cap->band[NL80211_BAND_5GHZ]; cap_band->phy_id =3D le32_to_cpu(mac_caps->phy_id); cap_band->max_bw_supported =3D --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A2E6480331; Sat, 28 Feb 2026 17:37:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300257; cv=none; b=dqFgNVfATGyXjUQx9/S7q+PHl0zMyir9DzL3zaFppUef6LxCnz83AcQLY4oHM/EeTcAQwrgDSCWNxk3zodg3yv3nWU1xE4a0PpuARii6QdvANL3slxrIv9GWQoDGbUEiUB48g8LyEs/o6CxNIraH5xd/jTeMM8syuAEKnjvgviA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300257; c=relaxed/simple; bh=S+vAKVZSypWTg0uCfcPyfYz9RZ+EQOAVcvk32yYo9cg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sKn/71VL0qiDkgcrn4wshWeotxVNSZOz4tFwXAPM0jwPjQczWTa+TisHswmc+x+4Cn3C6Ywb+C/4K4jUQMjTweAQt6VHTZaxQEDR4vCZTQOUMHPQmDWDhiKF7QTyB5yrJHssH7B3xUe8t/yCiFoNtO7RUTZ4AcoJ88nwNY1pr7A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=epxD7boY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="epxD7boY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9FFCEC19424; Sat, 28 Feb 2026 17:37:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300257; bh=S+vAKVZSypWTg0uCfcPyfYz9RZ+EQOAVcvk32yYo9cg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=epxD7boYJe050N2t3OkFg+OV/iCg59y7ilpXlwNe9ny05VWsxFPSVF4j5Rv/T65Lq RiP8zc3yThjh7Ut5Uu0Yi3sHUOzXlrfPy9CcaMPSI+i7XoPlUSl3UaGJV86ZlVlslo c3L2dBNydZyY6kr7ZJ+SWLAM7rT4z5h+qMJVKLjBWN+EAHkZ2JsiNMNzLNShzvbyu0 FAfZzKj+TS/3Mf4Cw2dsBAFXgN2WLfQCSAFFjelVduod32YsDp+tsw9Lt+xfNoE6gn t3VFrBIg9wprCfxakaiYUJdhUYZ+h+T4lN1f+nSJOXyHEc7JtNgjHmtsX8mRx1vBPG IgYOalBna5hcg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miri Korenblit , Johannes Berg , Sasha Levin Subject: [PATCH 6.19 282/844] wifi: cfg80211: allow only one NAN interface, also in multi radio Date: Sat, 28 Feb 2026 12:23:15 -0500 Message-ID: <20260228173244.1509663-283-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miri Korenblit [ Upstream commit e69fda4d07701373354e52b0321bd40311d743d0 ] According to Wi-Fi Aware (TM) 4.0 specification 2.8, A NAN device can have one NAN management interface. This applies also to multi radio devices. The current code allows a driver to support more than one NAN interface, if those are not in the same radio. Fix it. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260107135129.fdaecec0fe8a.I246b5ba6e9da3ec= 1481ff197e47f6ce0793d7118@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/wireless/core.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/net/wireless/core.c b/net/wireless/core.c index a04f96dc9a1d7..16ccf6fb28b21 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -661,12 +661,8 @@ int wiphy_verify_iface_combinations(struct wiphy *wiph= y, c->limits[j].max > 1)) return -EINVAL; =20 - /* Only a single NAN can be allowed, avoid this - * check for multi-radio global combination, since it - * hold the capabilities of all radio combinations. - */ - if (!combined_radio && - WARN_ON(types & BIT(NL80211_IFTYPE_NAN) && + /* Only a single NAN can be allowed */ + if (WARN_ON(types & BIT(NL80211_IFTYPE_NAN) && c->limits[j].max > 1)) return -EINVAL; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 665A939FE9B; Sat, 28 Feb 2026 17:37:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300258; cv=none; b=ezdC333u2t78ZJZksM1FS6QBFhbkK8PS61VseklJvCberYJ2S8LerHYZlZZcrGCrkOkv/+lAhPHMHMjzvXo7Nlsgrpfy44FEkCSIDO2eDC9y3zc6yiS/IHFSuf9l82CFgAW7ydAb/i/oWgZc41JxcMx5oSkTCOuFqK7YmMp1VC8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300258; c=relaxed/simple; bh=uOGOIZr61Qo5YmxJYttOr2GDOKOLciM0HyzmGKXTOvM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fOjWaSsqa6ayj9eyQ2MLe5q25PSaEFWgs2YraSvZTeyvAr7JYI3bqbM+jgyVQdu70K3XtPWcOw+CZeanw8nzGkIjxz5Nmmf7cFUO4Babd8KdeTiOAAp1+FcX1SAfU3x+WyM5aHF8MynPPHwi0TFEkLEu/Pt2pU9wdOfvamId6Yo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X0/koyQe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X0/koyQe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B994C19423; Sat, 28 Feb 2026 17:37:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300258; bh=uOGOIZr61Qo5YmxJYttOr2GDOKOLciM0HyzmGKXTOvM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X0/koyQezxYN2sa92X37FggHeqElmUfxTZHK6wSWfpwCQmf/IeOui19hFApmuItQP +KwWKkIgKffruoGKo8jeW6ZfGxv5RakLI2l/Rl06DFi7b8eYPOeJKE5/1UAU6Vx/m0 ++afw9wuZ4t6YUoD7QQMc+xOVY+zD89+2vBnuZ97rHLcSXzdTLdpNT+cSbMMD+ZWnU I/0IA7qrtDDOFoZCpnYZJE6emVvqE6kcfImUFhFmd4N3/Y2MgT5CXYDWoSL0uon2C8 pLc0EQnlxcRO4FnRyNW1QCUyv0RUtqZ1YQNnjyLzT7OUTir0etkwQLkBGHDfGscLHP xHJmhR6vOHLiw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 283/844] ipv6: annotate data-races in ip6_multipath_hash_{policy,fields}() Date: Sat, 28 Feb 2026 12:23:16 -0500 Message-ID: <20260228173244.1509663-284-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit 03e9d91dd64e2f5ea632df5d59568d91757efc4d ] Add missing READ_ONCE() when reading sysctl values. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/net/ipv6.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/net/ipv6.h b/include/net/ipv6.h index 6a933690e0ff5..e759a00dbde19 100644 --- a/include/net/ipv6.h +++ b/include/net/ipv6.h @@ -1010,11 +1010,11 @@ static inline int ip6_default_np_autolabel(struct n= et *net) #if IS_ENABLED(CONFIG_IPV6) static inline int ip6_multipath_hash_policy(const struct net *net) { - return net->ipv6.sysctl.multipath_hash_policy; + return READ_ONCE(net->ipv6.sysctl.multipath_hash_policy); } static inline u32 ip6_multipath_hash_fields(const struct net *net) { - return net->ipv6.sysctl.multipath_hash_fields; + return READ_ONCE(net->ipv6.sysctl.multipath_hash_fields); } #else static inline int ip6_multipath_hash_policy(const struct net *net) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3322739FEAB; Sat, 28 Feb 2026 17:37:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300259; cv=none; b=uzrqLIKG0u00YRqGG6utPCtHsxUBTp8Txp8quCrxaV71Lz3gVF/o2qvGf1GcFSLeWtLvMg3wixQxZ/mxLb3yPoGz7+zu3/GwirU0UBGKkdpt/EJ4O5QqOqmEpbjRmdMhyRMZPszVL3bCAHBcMOzDOMuVVw/u7vaWmTfMbcDmNL4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300259; c=relaxed/simple; bh=tXbNfB7hO5F8+9n9dk0VgnOyhPu7iYznsXMvifmgdsY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TrghWg5FoxJBBEcXZyWm61nFI/dhKaZJEBgzz+GJM8uSuvo4IMTjzaYMtYQQXTleqBzBOfga+Vuv/V2wyHaM2tPl1KRYo7g6dFlcIEGlZkf3LRE8md4ynp+qLFftYUAGSPc3DuL3irR2v8B6ZuVSvLgo8yXnBry00791lts/YXk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Oogm0o/5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Oogm0o/5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67BFBC116D0; Sat, 28 Feb 2026 17:37:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300259; bh=tXbNfB7hO5F8+9n9dk0VgnOyhPu7iYznsXMvifmgdsY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Oogm0o/5Fzus8glYH4cNFR4rQTpyLqIetbLVBkReBd05jQoKEI6ql777C2gCCoAwe zPBgGXUZF51QZUNyoJxWuvtlhf8RXhVx7W2Ibwsn9sbU02FZw0/OMehaOAbSvkHQGL GL39WiHBeTS6byvQwmhJMKUOEAKukeMCNCJMhTtTaH3opXVfHbaCWwEFYsjoDn/4OP Ya539hGSSgFzsqUdq90ObOG6y5yDsX795txBUeoRcoEvBaShVW0kkceDhEnvO07ElI +u8ODZzfmozR/QA/yDu1CPkbIunH4XPLeEGWxD4K4Ogqv2k18v0SmZcpQbtNblU2AM YSY9SsV8J/vIw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 284/844] ipv6: annotate data-races over sysctl.flowlabel_reflect Date: Sat, 28 Feb 2026 12:23:17 -0500 Message-ID: <20260228173244.1509663-285-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit 5ade47c974b46eb2a1279185962a0ffa15dc5450 ] Add missing READ_ONCE() when reading ipv6.sysctl.flowlabel_reflect, as its value can be changed under us. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/ipv6/af_inet6.c | 4 ++-- net/ipv6/icmp.c | 3 ++- net/ipv6/tcp_ipv6.c | 3 ++- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c index d3534bdb805da..56d453a598ec6 100644 --- a/net/ipv6/af_inet6.c +++ b/net/ipv6/af_inet6.c @@ -224,8 +224,8 @@ static int inet6_create(struct net *net, struct socket = *sock, int protocol, inet6_set_bit(MC6_LOOP, sk); inet6_set_bit(MC6_ALL, sk); np->pmtudisc =3D IPV6_PMTUDISC_WANT; - inet6_assign_bit(REPFLOW, sk, net->ipv6.sysctl.flowlabel_reflect & - FLOWLABEL_REFLECT_ESTABLISHED); + inet6_assign_bit(REPFLOW, sk, READ_ONCE(net->ipv6.sysctl.flowlabel_reflec= t) & + FLOWLABEL_REFLECT_ESTABLISHED); sk->sk_ipv6only =3D net->ipv6.sysctl.bindv6only; sk->sk_txrehash =3D READ_ONCE(net->core.sysctl_txrehash); =20 diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c index 55b1aa75ab802..0f41ca6f3d83e 100644 --- a/net/ipv6/icmp.c +++ b/net/ipv6/icmp.c @@ -953,7 +953,8 @@ static enum skb_drop_reason icmpv6_echo_reply(struct sk= _buff *skb) tmp_hdr.icmp6_type =3D type; =20 memset(&fl6, 0, sizeof(fl6)); - if (net->ipv6.sysctl.flowlabel_reflect & FLOWLABEL_REFLECT_ICMPV6_ECHO_RE= PLIES) + if (READ_ONCE(net->ipv6.sysctl.flowlabel_reflect) & + FLOWLABEL_REFLECT_ICMPV6_ECHO_REPLIES) fl6.flowlabel =3D ip6_flowlabel(ipv6_hdr(skb)); =20 fl6.flowi6_proto =3D IPPROTO_ICMPV6; diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c index 280fe59785598..4ae664b05fa91 100644 --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -1085,7 +1085,8 @@ static void tcp_v6_send_reset(const struct sock *sk, = struct sk_buff *skb, txhash =3D inet_twsk(sk)->tw_txhash; } } else { - if (net->ipv6.sysctl.flowlabel_reflect & FLOWLABEL_REFLECT_TCP_RESET) + if (READ_ONCE(net->ipv6.sysctl.flowlabel_reflect) & + FLOWLABEL_REFLECT_TCP_RESET) label =3D ip6_flowlabel(ipv6h); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 241203A1268; Sat, 28 Feb 2026 17:37:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300260; cv=none; b=Qq/FeSfcScfMI2/B45EiZZ2BHX67sNKfdlDGZStVKvdsmNMc9qQIs7k5wXmK2vBTBrh5+pk3VZUrPatvgDM9NX6Zk9Av2i8iX72o/nk3ZEAjZq7evBf3aEgNZpkdjnmEtqYJZWfXCfjMwkuPAevL/8SANEKZckENPXwMdoXk6dI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300260; c=relaxed/simple; bh=BS2TOG+Wj/1JLc3EtCMlB5kiFK4v3d8bC635VveQl0w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F0hALcwSYPrkmkesR7kAYhFotp+N3J77nfveh4Xf0CzWTbPZR4yruGLP1R06BkgP1kwRLe/YGcY//2Eqlv5BWC/bHUOTs0L+rMrJ9RpiJnHOmztL8YJPuK9OlFZmVC2JuMtxCcCUCAzwTJEr+LK0KIVIdXtPXBNhch8o59uN6Fg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sQOPiLq/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sQOPiLq/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BBE1C116D0; Sat, 28 Feb 2026 17:37:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300260; bh=BS2TOG+Wj/1JLc3EtCMlB5kiFK4v3d8bC635VveQl0w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sQOPiLq/9le/cXbDdctWCaTmnvdW2vhJ6pXI1ELVwsLv15GA+Q3KvhMQeRFr9FvnO FgiQVwnyEIZT0MOXfrUnP2pJXOL5siy9CZQ6lt0HFLne+Wio8iwthIXITQ4i47jdto fc5KL6a+N7lC8byUZfXMkZbKSF+Uqh34TDuRyafA/KFEuF3S8sh0ZzGMJBDSfBKxtf UFFiGnkixm9QWPUw5FO3Y+X91uHu6BrRjinvCkNaiYSa3fsPzw9036UFfPKCCzDy80 FewJZiaW9Uu2P0U/jclwtX61FDOC4vp5p3mDEgrbWXWJ6N9fOeXB/Wvjf3IbJiHuI2 vMtY0d0PVRuuQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 285/844] ipv6: annotate data-races in net/ipv6/route.c Date: Sat, 28 Feb 2026 12:23:18 -0500 Message-ID: <20260228173244.1509663-286-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit f062e8e25102324364aada61b8283356235bc3c1 ] sysctls are read while their values can change, add READ_ONCE() annotations. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-9-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/ipv6/route.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index e3a260a5564ba..cd229974b7974 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -2895,7 +2895,7 @@ static void rt6_do_update_pmtu(struct rt6_info *rt, u= 32 mtu) =20 dst_metric_set(&rt->dst, RTAX_MTU, mtu); rt->rt6i_flags |=3D RTF_MODIFIED; - rt6_update_expires(rt, net->ipv6.sysctl.ip6_rt_mtu_expires); + rt6_update_expires(rt, READ_ONCE(net->ipv6.sysctl.ip6_rt_mtu_expires)); } =20 static bool rt6_cache_allowed_for_pmtu(const struct rt6_info *rt) @@ -3256,8 +3256,8 @@ static unsigned int ip6_default_advmss(const struct d= st_entry *dst) rcu_read_lock(); =20 net =3D dst_dev_net_rcu(dst); - if (mtu < net->ipv6.sysctl.ip6_rt_min_advmss) - mtu =3D net->ipv6.sysctl.ip6_rt_min_advmss; + mtu =3D max_t(unsigned int, mtu, + READ_ONCE(net->ipv6.sysctl.ip6_rt_min_advmss)); =20 rcu_read_unlock(); =20 @@ -3359,10 +3359,10 @@ struct dst_entry *icmp6_dst_alloc(struct net_device= *dev, static void ip6_dst_gc(struct dst_ops *ops) { struct net *net =3D container_of(ops, struct net, ipv6.ip6_dst_ops); - int rt_min_interval =3D net->ipv6.sysctl.ip6_rt_gc_min_interval; - int rt_elasticity =3D net->ipv6.sysctl.ip6_rt_gc_elasticity; - int rt_gc_timeout =3D net->ipv6.sysctl.ip6_rt_gc_timeout; - unsigned long rt_last_gc =3D net->ipv6.ip6_rt_last_gc; + int rt_min_interval =3D READ_ONCE(net->ipv6.sysctl.ip6_rt_gc_min_interval= ); + int rt_elasticity =3D READ_ONCE(net->ipv6.sysctl.ip6_rt_gc_elasticity); + int rt_gc_timeout =3D READ_ONCE(net->ipv6.sysctl.ip6_rt_gc_timeout); + unsigned long rt_last_gc =3D READ_ONCE(net->ipv6.ip6_rt_last_gc); unsigned int val; int entries; =20 @@ -5008,7 +5008,7 @@ void rt6_sync_down_dev(struct net_device *dev, unsign= ed long event) }; struct net *net =3D dev_net(dev); =20 - if (net->ipv6.sysctl.skip_notify_on_dev_down) + if (READ_ONCE(net->ipv6.sysctl.skip_notify_on_dev_down)) fib6_clean_all_skip_notify(net, fib6_ifdown, &arg); else fib6_clean_all(net, fib6_ifdown, &arg); @@ -6408,6 +6408,7 @@ void fib6_rt_update(struct net *net, struct fib6_info= *rt, void fib6_info_hw_flags_set(struct net *net, struct fib6_info *f6i, bool offload, bool trap, bool offload_failed) { + u8 fib_notify_on_flag_change; struct sk_buff *skb; int err; =20 @@ -6419,8 +6420,9 @@ void fib6_info_hw_flags_set(struct net *net, struct f= ib6_info *f6i, WRITE_ONCE(f6i->offload, offload); WRITE_ONCE(f6i->trap, trap); =20 + fib_notify_on_flag_change =3D READ_ONCE(net->ipv6.sysctl.fib_notify_on_fl= ag_change); /* 2 means send notifications only if offload_failed was changed. */ - if (net->ipv6.sysctl.fib_notify_on_flag_change =3D=3D 2 && + if (fib_notify_on_flag_change =3D=3D 2 && READ_ONCE(f6i->offload_failed) =3D=3D offload_failed) return; =20 @@ -6432,7 +6434,7 @@ void fib6_info_hw_flags_set(struct net *net, struct f= ib6_info *f6i, */ return; =20 - if (!net->ipv6.sysctl.fib_notify_on_flag_change) + if (!fib_notify_on_flag_change) return; =20 skb =3D nlmsg_new(rt6_nlmsg_size(f6i), GFP_KERNEL); @@ -6529,7 +6531,7 @@ static int ipv6_sysctl_rtcache_flush(const struct ctl= _table *ctl, int write, return ret; =20 net =3D (struct net *)ctl->extra1; - delay =3D net->ipv6.sysctl.flush_delay; + delay =3D READ_ONCE(net->ipv6.sysctl.flush_delay); fib6_run_gc(delay <=3D 0 ? 0 : (unsigned long)delay, net, delay > 0); return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 166E63A1285; Sat, 28 Feb 2026 17:37:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300261; cv=none; b=nWQTHPxjIHiXf2HWgJthGc+7tqNA7OYY/TWvHJychPCP4bCqHLnuuk51LiTTxUcMSFg+Fl7nE9cu2avbPAEVeKae8Rs09XkqXxPoWOzpOKw48Y0urUSrN2lPYjPtQKtO6nSplMV5XeladQjJX+pPAJTo2wju5+t2Gfmt0fbAbnI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300261; c=relaxed/simple; bh=W15cyp0xaAgC3j6Km803kuRKxO/r6w2fW0XBj3f2/Ds=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VFR4BrcP5WcYt1H+7hFbOmB3PlBQRL8NG8DVB8Sw5z9qJRskcabKQIbjBQ0nHTVAgfkiRFQx75fArTEWgfppQECow0WiPIBeyCANFclNX03VcVeUYnsUwR73VBzVEHElSfuKFhOE5jYFqqBG3Zl80L97RJKemezOgWuZ0DUYPWY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=psVkRRKC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="psVkRRKC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B143C116D0; Sat, 28 Feb 2026 17:37:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300261; bh=W15cyp0xaAgC3j6Km803kuRKxO/r6w2fW0XBj3f2/Ds=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=psVkRRKCTJ0OkgZJYmmooUq1qVLdixRe5qBK58GHdiZQrxf0O1OgS7qeZgv/JPTDT sKLCg+Zwb4B4nZhcg8tsaouxc/0y7chQ9hKfIWzV25NnPc5bhJLu8XV3hnvFAbSe1M swUAKmv+xEkUjnVSPLmNdS7JWBS3tAXwwsbcuHBwoXMt5IXI9ZdT9FdcavpujWFBaH ctCXTI3vRAs/Y9KLzz13dCxzejM+lDC65aAOu1ZnNU5xGIGjMOr+GC0O4AawolVsj2 is3qv1fgA5UflaPMkBmd4E3N94HWXgpg9z4CLF66eDOKepZqKJwocmhOqBwbppyABc PKfkMss4AmTZg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 286/844] ipv6: exthdrs: annotate data-race over multiple sysctl Date: Sat, 28 Feb 2026 12:23:19 -0500 Message-ID: <20260228173244.1509663-287-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit 978b67d28358b0b4eacfa94453d1ad4e09b123ad ] Following four sysctls can change under us, add missing READ_ONCE(). - ipv6.sysctl.max_dst_opts_len - ipv6.sysctl.max_dst_opts_cnt - ipv6.sysctl.max_hbh_opts_len - ipv6.sysctl.max_hbh_opts_cnt Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-8-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/ipv6/exthdrs.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c index a23eb8734e151..54088fa0c09d0 100644 --- a/net/ipv6/exthdrs.c +++ b/net/ipv6/exthdrs.c @@ -314,7 +314,7 @@ static int ipv6_destopt_rcv(struct sk_buff *skb) } =20 extlen =3D (skb_transport_header(skb)[1] + 1) << 3; - if (extlen > net->ipv6.sysctl.max_dst_opts_len) + if (extlen > READ_ONCE(net->ipv6.sysctl.max_dst_opts_len)) goto fail_and_free; =20 opt->lastopt =3D opt->dst1 =3D skb_network_header_len(skb); @@ -322,7 +322,8 @@ static int ipv6_destopt_rcv(struct sk_buff *skb) dstbuf =3D opt->dst1; #endif =20 - if (ip6_parse_tlv(false, skb, net->ipv6.sysctl.max_dst_opts_cnt)) { + if (ip6_parse_tlv(false, skb, + READ_ONCE(net->ipv6.sysctl.max_dst_opts_cnt))) { skb->transport_header +=3D extlen; opt =3D IP6CB(skb); #if IS_ENABLED(CONFIG_IPV6_MIP6) @@ -1049,11 +1050,12 @@ int ipv6_parse_hopopts(struct sk_buff *skb) } =20 extlen =3D (skb_transport_header(skb)[1] + 1) << 3; - if (extlen > net->ipv6.sysctl.max_hbh_opts_len) + if (extlen > READ_ONCE(net->ipv6.sysctl.max_hbh_opts_len)) goto fail_and_free; =20 opt->flags |=3D IP6SKB_HOPBYHOP; - if (ip6_parse_tlv(true, skb, net->ipv6.sysctl.max_hbh_opts_cnt)) { + if (ip6_parse_tlv(true, skb, + READ_ONCE(net->ipv6.sysctl.max_hbh_opts_cnt))) { skb->transport_header +=3D extlen; opt =3D IP6CB(skb); opt->nhoff =3D sizeof(struct ipv6hdr); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E6F823A126A; Sat, 28 Feb 2026 17:37:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300262; cv=none; b=ezNnIx8FS4rmpHnTi+wzcPTQfjLfnAmKbhAuWTFdFF0oOohCaghOMVSz1vtckvG5zOcICqqG/Uy8s8Z0pZKN3gIc+EOwGg8EOUFWMmAsZAUAXxNMShSdCfLse9v4r/SPCVJ6tKhODAS6x2glHNqzPxDlaYCSmtzNHw1IdqEGJiI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300262; c=relaxed/simple; bh=FZbg55rE1QtyCEP+zmNsooQMQIyxlLzDzWk3m6u9kuc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=etGMm8vCAqsbCCBObpm/Z5te+Ss4eke821FH94aQZrF5CkK/LW+q0A/ncMuqWZ7P3X9N4zuJTzAQ0e/RJ+f5kqBcbj0hX5p2wLROGAHke98pJpTuqkX8JfQYloXwj9ku2U+isZZwhoXyeDis7614jOHkBHDLUOcLDdFEOBca2cw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WbyTYbKq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WbyTYbKq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D2BCC116D0; Sat, 28 Feb 2026 17:37:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300261; bh=FZbg55rE1QtyCEP+zmNsooQMQIyxlLzDzWk3m6u9kuc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WbyTYbKqsWyLpMsu1glt9sr2+sfgaY/5xOYWo7OrpjP2Gk188u6eBuk530ZjMX5k3 a72cqSQXHnrN6WVWLiApiIYSQhTE1CfyNIL5/AF5IMimwQmjZ/Zxb+aJ7kYz2xCXfz C7HucETBuq8OYtsVsRhLX1iCATnsX6w9sVEqnBPA/yEV6qBanQp5/HqKdH4POI9FS+ 1f2UnFYbiEnSYGjVEZTVuBM5RuJNPP/nlHaH2OfhyD3+JyIAfR5Mr4UZMdbpKAX5Ij 3zye576bIYvaiZDj/wcMGa+WouQW62/ItZ49NOaD3WK5vnDTXKFm6FVS7MqAhtowh5 5MxCHBE5M/rWQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Li Chen , Theodore Ts'o , Sasha Levin Subject: [PATCH 6.19 287/844] ext4: mark group add fast-commit ineligible Date: Sat, 28 Feb 2026 12:23:20 -0500 Message-ID: <20260228173244.1509663-288-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li Chen [ Upstream commit 89b4336fd5ec78f51f9d3a1d100f3ffa3228e604 ] Fast commits only log operations that have dedicated replay support. Online resize via EXT4_IOC_GROUP_ADD updates the superblock and group descriptor metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when ext4_ioctl_group_add() adds new block groups. This forces those transactions to fall back to a full commit, ensuring that the filesystem geometry updates are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_ADD safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=3D/dev/zero of=3D/root/fc_resize.img bs=3D1M count=3D0 seek=3D256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /m= nt/fc_resize 2. Ran a helper that issues EXT4_IOC_GROUP_ADD on the mounted filesystem and checked the resize ineligible reason: ./group_add_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows "Resize": > 0. 3. Fsynced a file on the resized filesystem and verified that the fast commit stats report at least one ineligible commit: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info shows fc stats ineligible > 0. Signed-off-by: Li Chen Link: https://patch.msgid.link/20251211115146.897420-5-me@linux.beauty Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ext4/ioctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index 7ce0fc40aec2f..5109b005e0286 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -966,6 +966,7 @@ static long ext4_ioctl_group_add(struct file *file, =20 err =3D ext4_group_add(sb, input); if (EXT4_SB(sb)->s_journal) { + ext4_fc_mark_ineligible(sb, EXT4_FC_REASON_RESIZE, NULL); jbd2_journal_lock_updates(EXT4_SB(sb)->s_journal); err2 =3D jbd2_journal_flush(EXT4_SB(sb)->s_journal, 0); jbd2_journal_unlock_updates(EXT4_SB(sb)->s_journal); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EAC583A2AF2; Sat, 28 Feb 2026 17:37:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300263; cv=none; b=WaCBH7PRkvYGp2vc8vvsXb6jfLYZEm8HWGjCvYhfkxL7M09Eq1TM2f6Gds+RFQFX5ZGT4i4JT5+dkCg2TKdu0nCqah9jmStnsux6+OXE2YGZXF7Attsc0k5Z1CWSTGoCVilGOx4Iq5hjCaglo9HxuDpes1mzt2zaAPh2zPKlboE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300263; c=relaxed/simple; bh=4Cwt2EojoRzLmJ1xvBNGTc8dzSl8uMY6zNPA2+D+51U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JK4C+Q5He3UDA2ZY8ErViItGs6d1Z5r8tZLHdEgXTCw6zg6GW3JVcsfvqYBhDO0zINsPyaumhi5wpPQHfjLSV1yma5fOHsVQsMDB3VurzYwgBeoPMSggDVA26/v6Krgd5vtLolqv/2U+ixUhvTlmoK8J+FIlUO+/SVYd4BiubBI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MeTGDh8f; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MeTGDh8f" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B1B8C116D0; Sat, 28 Feb 2026 17:37:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300262; bh=4Cwt2EojoRzLmJ1xvBNGTc8dzSl8uMY6zNPA2+D+51U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MeTGDh8fZ1jJx9FmX1CbUJ5SELOk54xMy5Qu4Haam/XiBnw79iOu0z0rygBF9ojEL i/z8u3qfRpQnWDB1d6i8LnNCwxF6GQHniXcXnnfarBaocHfNKjRl/6D/1a73vv13pY 8Vk0c9QtOOpyesdi2jhg7MEoV3IaKg09yc+sr0NGrPT+WgqS5nDxvtrDqN8FLCHjyh paI4UNBUkPlM1cZ6fgcUjnHd7MX3zhPdsYwh327Atulop4+jXvqdKYilMRAp6+GAWo /LpvTuJtNP50Py64/u5juZ3d2iZ5zCmhkj79MLfiuHUnMPRuSCApvVg4ZYJlmefolP qxZoWE+6bCMOw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Baokun Li , Zhang Yi , Jan Kara , Theodore Ts'o , Sasha Levin Subject: [PATCH 6.19 288/844] ext4: move ext4_percpu_param_init() before ext4_mb_init() Date: Sat, 28 Feb 2026 12:23:21 -0500 Message-ID: <20260228173244.1509663-289-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Baokun Li [ Upstream commit 270564513489d98b721a1e4a10017978d5213bff ] When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the `DOUBLE_CHECK` macro defined, the following panic is triggered: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpu_counter_add_batch+0x13/0xa0 Call Trace: ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads and validates the block bitmap. When the validation fails, ext4_mark_group_bitmap_corrupted() attempts to update sbi->s_freeclusters_counter. However, this percpu_counter has not been initialized yet at this point, which leads to the panic described above. Fix this by moving the execution of ext4_percpu_param_init() to occur before ext4_mb_init(), ensuring the per-CPU counters are initialized before they are used. Signed-off-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20251209133116.731350-1-libaokun@huaweicloud= .com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ext4/super.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 87205660c5d02..5c2e931d8a533 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -5604,6 +5604,10 @@ static int __ext4_fill_super(struct fs_context *fc, = struct super_block *sb) clear_opt2(sb, MB_OPTIMIZE_SCAN); } =20 + err =3D ext4_percpu_param_init(sbi); + if (err) + goto failed_mount5; + err =3D ext4_mb_init(sb); if (err) { ext4_msg(sb, KERN_ERR, "failed to initialize mballoc (%d)", @@ -5619,10 +5623,6 @@ static int __ext4_fill_super(struct fs_context *fc, = struct super_block *sb) sbi->s_journal->j_commit_callback =3D ext4_journal_commit_callback; =20 - err =3D ext4_percpu_param_init(sbi); - if (err) - goto failed_mount6; - if (ext4_has_feature_flex_bg(sb)) if (!ext4_fill_flex_info(sb)) { ext4_msg(sb, KERN_ERR, @@ -5704,8 +5704,8 @@ failed_mount8: __maybe_unused failed_mount6: ext4_mb_release(sb); ext4_flex_groups_free(sbi); - ext4_percpu_param_destroy(sbi); failed_mount5: + ext4_percpu_param_destroy(sbi); ext4_ext_release(sb); ext4_release_system_zone(sb); failed_mount4a: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15A403A2B13; Sat, 28 Feb 2026 17:37:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300264; cv=none; b=XUAucoupCi6CHVtX9fihlwETGlTaXwSYr+zLV/SLIy3XW+QPzqDyloBKwEcDC7Qh3yO6qSRBNx0hVcBc2vMaCH8jfxLKe9YQH1QrEXT5+44YkKa6Q/cylPaqMQjcp9im1tcED7bfPpNGu1LGlITX7qTDBBXCWvXHOzeovqViqoU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300264; c=relaxed/simple; bh=zcsAsMU11jRd8t8/cx8CVmfm1W2kXBYAncOXj+P4M9o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B2qiP6dqno/cOgza6NzPsGP5/94dYqO1IDyyihcN5ZN6Dks9gOZI29FDm/LuFdrJzjflWlm5cU9ctqRvU369PivdJGJC/BwQPDTxMPQmGHXwS2tbtO//ShsMTVAAgLfpUi8q4zPDg4XhUaMQajn1eqKA7MpQN8dRQwQ35FPxRjU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gMFZ8Iag; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gMFZ8Iag" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F230C19424; Sat, 28 Feb 2026 17:37:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300263; bh=zcsAsMU11jRd8t8/cx8CVmfm1W2kXBYAncOXj+P4M9o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gMFZ8IagNACZXFDnOL9BPz4tDMJklTM5VmT8dmw1LIvhWgiuXawK96uFeWCPMMM0u zm8JOlLsquDw5161EaWuzI9VzkgG9cl3A7kefvcjAYZxG/EWDrbldmA3yQcm1rNJlA RJQaMdIgrBuubcDOeQrAu4pwe5yrZ035vSj7fAcDfmba6/JHUeblF5zRu8KwKlHlZc Y7Ut9JYtm/1nkc4ktk3lVjx+ZqoetgSNrcTqvjpMNfubDsoCD8gS/sPKibM1DPm4Dp IOjpzUoAcL/3SjS65nExIbL5JKY9bWGctA92+6yFQrNtAg06GPyMoMkCQj9eGPpSE6 /j8yLJC7qgPnw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Li Chen , Theodore Ts'o , Sasha Levin Subject: [PATCH 6.19 289/844] ext4: mark group extend fast-commit ineligible Date: Sat, 28 Feb 2026 12:23:22 -0500 Message-ID: <20260228173244.1509663-290-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li Chen [ Upstream commit 1f8dd813a1c771b13c303f73d876164bc9b327cc ] Fast commits only log operations that have dedicated replay support. EXT4_IOC_GROUP_EXTEND grows the filesystem to the end of the last block group and updates the same on-disk metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when EXT4_IOC_GROUP_EXTEND grows the filesystem. This forces those transactions to fall back to a full commit, ensuring that the group extension changes are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_EXTEND safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=3D/dev/zero of=3D/root/fc_resize.img bs=3D1M count=3D0 seek=3D256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /m= nt/fc_resize 2. Extended the filesystem to the end of the last block group using a helper that calls EXT4_IOC_GROUP_EXTEND on the mounted filesystem and checked fc_info: ./group_extend_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows the "Resize" ineligible reason increased. 3. Fsynced a file on the resized filesystem and confirmed that the fast commit ineligible counter incremented for the resize transaction: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info Signed-off-by: Li Chen Link: https://patch.msgid.link/20251211115146.897420-6-me@linux.beauty Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ext4/ioctl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index 5109b005e0286..e5e197ac7d88b 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -1612,6 +1612,8 @@ static long __ext4_ioctl(struct file *filp, unsigned = int cmd, unsigned long arg) =20 err =3D ext4_group_extend(sb, EXT4_SB(sb)->s_es, n_blocks_count); if (EXT4_SB(sb)->s_journal) { + ext4_fc_mark_ineligible(sb, EXT4_FC_REASON_RESIZE, + NULL); jbd2_journal_lock_updates(EXT4_SB(sb)->s_journal); err2 =3D jbd2_journal_flush(EXT4_SB(sb)->s_journal, 0); jbd2_journal_unlock_updates(EXT4_SB(sb)->s_journal); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E29EF480344; Sat, 28 Feb 2026 17:37:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300265; cv=none; b=MIA61EBdnoAt7Sy7s6OLAtdcSC+ohoXAEUs1FaS8oWt20VnStdC1jharfiJX/Tm9PWniajwoWjztRXWrx87cCFq27J09Woh0/Cek/ORvpooyqUGU86gRDRiT+pquKU8H1tx7dDETV31RBHA4vUHGhmqpY6TZnFm1RfHBPDb1d7c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300265; c=relaxed/simple; bh=SKznDw+zv8hk4XVrg19OWTArrehnlIBvaSZw+NYYqQo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dElatXuRNrcx8j7jgqwI5UZCOMfeVv5PzdroXKGBHBITDR7KgGKAtOMGKzafd3OUO4+E8jsoj3EVYi127IwNrfYILQqDGSSWj3jmdVdBFROhSw3a4SU1erXcndqRFs0QOfonLyDsRHI603ZF4TjHA/SA/u5ABSNWUj2WH9d68Is= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TXj1vy/3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TXj1vy/3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1522C2BC87; Sat, 28 Feb 2026 17:37:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300264; bh=SKznDw+zv8hk4XVrg19OWTArrehnlIBvaSZw+NYYqQo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TXj1vy/3P1U1WvuNkzXVx1fRDj7VtyTowL8RR1VrhuP7RJLJymFtfeBlpPRWjtz5C NnCy/p75hIB5CHbVXvKthwVncQOLzqKTbFJBHV3TJdGt+Dx/L6k+YMdAhdNLvtS9eg EDUZZ2C7b1LTzXQXRMLIdjHntUd2ZzNiN/si7/pHm/sVgE/GhFA8gx8tFkJPgMql74 TRuAYAl77En3Jm/mXFgiyvn2r7RsNB7lwd38MtuFs7eDsgCFDbL4YV9xsUJWI7+LTo m3o17lALER+C3f9dXUCDLXiM25e2dDsgEbpzV+nB61ChD2B8maX7aL0UAeykjFV9lM xzj6zI8nB8Bng== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhang Yi , Jan Kara , Baokun Li , Ojaswin Mujoo , Theodore Ts'o , Sasha Levin Subject: [PATCH 6.19 290/844] ext4: use reserved metadata blocks when splitting extent on endio Date: Sat, 28 Feb 2026 12:23:23 -0500 Message-ID: <20260228173244.1509663-291-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhang Yi [ Upstream commit 01942af95ab6c9d98e64ae01fdc243a03e4b973f ] When performing buffered writes, we may need to split and convert an unwritten extent into a written one during the end I/O process. However, we do not reserve space specifically for these metadata changes, we only reserve 2% of space or 4096 blocks. To address this, we use EXT4_GET_BLOCKS_PRE_IO to potentially split extents in advance and EXT4_GET_BLOCKS_METADATA_NOFAIL to utilize reserved space if necessary. These two approaches can reduce the likelihood of running out of space and losing data. However, these methods are merely best efforts, we could still run out of space, and there is not much difference between converting an extent during the writeback process and the end I/O process, it won't increase the risk of losing data if we postpone the conversion. Therefore, also use EXT4_GET_BLOCKS_METADATA_NOFAIL in ext4_convert_unwritten_extents_endio() to prepare for the buffered I/O iomap conversion, which may perform extent conversion during the end I/O process. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20260105014522.1937690-2-yi.zhang@huaweiclou= d.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ext4/extents.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 18b39eed75267..418c4351ef40c 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3809,6 +3809,8 @@ ext4_convert_unwritten_extents_endio(handle_t *handle= , struct inode *inode, * illegal. */ if (ee_block !=3D map->m_lblk || ee_len > map->m_len) { + int flags =3D EXT4_GET_BLOCKS_CONVERT | + EXT4_GET_BLOCKS_METADATA_NOFAIL; #ifdef CONFIG_EXT4_DEBUG ext4_warning(inode->i_sb, "Inode (%ld) finished: extent logical block %l= lu," " len %u; IO logical block %llu, len %u", @@ -3816,7 +3818,7 @@ ext4_convert_unwritten_extents_endio(handle_t *handle= , struct inode *inode, (unsigned long long)map->m_lblk, map->m_len); #endif path =3D ext4_split_convert_extents(handle, inode, map, path, - EXT4_GET_BLOCKS_CONVERT, NULL); + flags, NULL); if (IS_ERR(path)) return path; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C18F73A3517; Sat, 28 Feb 2026 17:37:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300265; cv=none; b=fvT/T0ZZsf5HyKa08R1D91MyslcZhg272r4ItCw79gmxv6J1ZsIpWrlCla42aqMd+3kYiFbnDzVx4Ym6u9zigqVwQ8QJutllWmuT0dzxblSgVwR+OEZtFWYnscTyiDKIKTFTD2B6Z925UX6j/yNj23NloqowW175tjE/LS+m4MM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300265; c=relaxed/simple; bh=on/aqGeJbNw8FM9p0WkiZd/V+zdZqbfsc57tB34OKOg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lQqzsbymw67TvLMlNAs1wZ63ZcvuPn8cIE9kKnNyUu/ZIftm7jKbOyR2rbrcDxxiJCJoQl4BTctwFgg0hbuenkTHM0onC4JjhDSnSrz4lVOL4MoITScVOuWeOKjnOHTlCXrXEV87PbIPUhL4gkD+DCP2IJFSKrNmlxqpFhOD+Zs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HGIeG1Ml; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HGIeG1Ml" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13FA1C19423; Sat, 28 Feb 2026 17:37:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300265; bh=on/aqGeJbNw8FM9p0WkiZd/V+zdZqbfsc57tB34OKOg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HGIeG1MlvVGH350+a4R0LYICTBfB3GPsrzxlOCj6VdN2NqZfWMkG4ucGF8gI/t2fD Z1qgWy2lalTIbxtDV8jxe/blNE2pWZpBedNaEtveGn5WZEN2Fk3l/zthkjBmniKfuX x4VAiGR1siwO+F3QDJQM9WY1765bCK8etRCH9JzO6Ke465LxW8DycKXecwOSFfifI5 XBL5H2gLwPUWz0UzHE8I7VvZdgCdqvHZ1trGk63TTVA2ZCi/AgbDsGxc23zhVsRJaC ZBVPKP8TlD+U2IgCAwNkWadd6sTv2gUkTN8+XqSU3xAz8obFiisfChkMAbQqaNVmOd Q7Mb535WoNjcw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yuto Hamaguchi , Florian Westphal , Sasha Levin Subject: [PATCH 6.19 291/844] netfilter: nf_conntrack: Add allow_clash to generic protocol handler Date: Sat, 28 Feb 2026 12:23:24 -0500 Message-ID: <20260228173244.1509663-292-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yuto Hamaguchi [ Upstream commit 8a49fc8d8a3e83dc51ec05bcd4007bdea3c56eec ] The upstream commit, 71d8c47fc653711c41bc3282e5b0e605b3727956 ("netfilter: conntrack: introduce clash resolution on insertion race"), sets allow_clash=3Dtrue in the UDP/UDPLITE protocol handler but does not set it in the generic protocol handler. As a result, packets composed of connectionless protocols at each layer, such as UDP over IP-in-IP, still drop packets due to conflicts during connt= rack insertion. To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_ge= neric. Signed-off-by: Yuto Hamaguchi Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/netfilter/nf_conntrack_proto_generic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/netfilter/nf_conntrack_proto_generic.c b/net/netfilter/nf_= conntrack_proto_generic.c index e831637bc8ca8..cb260eb3d012c 100644 --- a/net/netfilter/nf_conntrack_proto_generic.c +++ b/net/netfilter/nf_conntrack_proto_generic.c @@ -67,6 +67,7 @@ void nf_conntrack_generic_init_net(struct net *net) const struct nf_conntrack_l4proto nf_conntrack_l4proto_generic =3D { .l4proto =3D 255, + .allow_clash =3D true, #ifdef CONFIG_NF_CONNTRACK_TIMEOUT .ctnl_timeout =3D { .nlattr_to_obj =3D generic_timeout_nlattr_to_obj, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D555C3A353D; Sat, 28 Feb 2026 17:37:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300266; cv=none; b=VX5pCGpJANNKTVoRX2Jck6NpQl5Icjv+XuU0okjyQwzDynZNz3T1B09LmXlJYYijfDr672yP3ahzbXUZqyP8Ogk8a/ORZnrMxATdfESwLZHug75H//YMhazYQ//X0eNBab22jRjt6C8srG5KCKAtsKZ/QNjSsvwZnFzYIXtc+jw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300266; c=relaxed/simple; bh=pFE7KMqNgpCOcihLdheVtz6wir2jtJW5f5QbLKUawRM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Qr/eB5ceiQ3effC7l+9YpZ31ceVls7K1OhhUwIhaO7HomdKKlsZ0igbl6JqZKwtIFspuUZM8xIYljqsfh0rUk0FYWC7QYp/DdRiwbJnDjspOw7EgLuZ/ovD3t8HoEmYfxqGGT7UvMN6C+z84hf3UExp8IHNVxBKwTNMGh/tO68E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sORh0V0r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sORh0V0r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9BBFC19424; Sat, 28 Feb 2026 17:37:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300266; bh=pFE7KMqNgpCOcihLdheVtz6wir2jtJW5f5QbLKUawRM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sORh0V0rclTfo1N39C84nhfl+1o7Hw7maohE7KXDqsjFy0+UQscesJ7ItOqc0EnOS dzcadjpLP/FkjjvbVaxksSJVHvcFRfgbxN54mbB8+w2kDc3Ym4E6NMWnQUNWc7g+w/ dflNAK0Mi/6VhN1I3/EccgfazEEbNAq94XefzqUpZ+RlCtBbli7PG7Z+jBwoMmZuw/ E0pNGnuBIaDvZxNhhFxxEckBlIr2BVLGqUccTo8HNzNfrsGzNwr+WJw58acKApxsbV SL5BF1d2TKZIuYaQshHKSnofumynd5pna+X5gGFtoSOV+rVfzUvWWMvb9ghEx8Gc4y s2tqkynWq2NpQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Florian Westphal , sungzii , Sasha Levin Subject: [PATCH 6.19 292/844] netfilter: xt_tcpmss: check remaining length before reading optlen Date: Sat, 28 Feb 2026 12:23:25 -0500 Message-ID: <20260228173244.1509663-293-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Florian Westphal [ Upstream commit 735ee8582da3d239eb0c7a53adca61b79fb228b3 ] Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attem= pts to index op[i+1]. In the case where i + 1 =3D=3D optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload). Reported-by: sungzii Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/netfilter/xt_tcpmss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/netfilter/xt_tcpmss.c b/net/netfilter/xt_tcpmss.c index 37704ab017992..0d32d4841cb32 100644 --- a/net/netfilter/xt_tcpmss.c +++ b/net/netfilter/xt_tcpmss.c @@ -61,7 +61,7 @@ tcpmss_mt(const struct sk_buff *skb, struct xt_action_par= am *par) return (mssval >=3D info->mss_min && mssval <=3D info->mss_max) ^ info->invert; } - if (op[i] < 2) + if (op[i] < 2 || i =3D=3D optlen - 1) i++; else i +=3D op[i+1] ? : 1; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F7F435AC12; Sat, 28 Feb 2026 17:37:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300267; cv=none; b=HLbY0DGb5HJQWFEU512FrvHJm3zfwL/6EUwtjti/KpDuVhucpXl4RCrKbcykhRzUoL/BcTkv4Mc52DsIMkHHWgDOxsbefs/9zMW0Xz4zDBRzjz5nqpd5MADMO3IKzKqTp0+MVTQqCbiQQ/RQtL9C47nxQiAv1CNRtHxwkMa7vRc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300267; c=relaxed/simple; bh=cSWzlnpqidfMV0fh8o4QeLP6rReA62/EY2yPIuusBFI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bOiA68J+bqgkFxZ0iSPCzOUYtrIfk2YZZqGUR6907MpQNjNw1ANK2173yKwW6j4GV1JN/R3VvhKB2obl9MLztegU/s36XwDKCQXUO7szT/yGdUSy4EYdeIkqwazymGWGVLuTcJLlN1Eoww0yypISjLI3phY0L22U5viDSGWuOeo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SbpZxkBV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SbpZxkBV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7F5EC19423; Sat, 28 Feb 2026 17:37:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300267; bh=cSWzlnpqidfMV0fh8o4QeLP6rReA62/EY2yPIuusBFI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SbpZxkBVdKKeNWqS+9ShxxaCAWG6r+2snkB83D3liHvNO1qulfl+WCDN+NnYpt1wP xa7eGaenOk/TTymHbZM/mX1s/cDxa/iaQumHplt7eHV9qle7sQETr5B5KMPAshq99k uBGnXgYiO/G8hEJvrGK6YmWjkRrA5wQqIrGCIvvJ5YFDbh2uyHUk+TgGNJYtzgkY1x aF2ILVgNCoDo4rfUTS2Vo8C5Hk3Tc/8M3DmMlOL+3Jw4sMwwhwEuzYL6jJyQf1PyYr JPP4wfd/na7Qe7crXvt0T0MNvwy5iUkOOEDAA/ECN27HRDPc1jF4EjQ2m0GBL3awq2 l4nvRO6kCWYVA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Brian Masney , kernel test robot , Stafford Horne , Sasha Levin Subject: [PATCH 6.19 293/844] openrisc: define arch-specific version of nop() Date: Sat, 28 Feb 2026 12:23:26 -0500 Message-ID: <20260228173244.1509663-294-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Brian Masney [ Upstream commit 0dfffa5479d6260d04d021f69203b1926f73d889 ] When compiling a driver written for MIPS on OpenRISC that uses the nop() function, it fails due to the following error: drivers/watchdog/pic32-wdt.c: Assembler messages: drivers/watchdog/pic32-wdt.c:125: Error: unrecognized instruction `nop' The driver currently uses the generic version of nop() from include/asm-generic/barrier.h: #ifndef nop #define nop() asm volatile ("nop") #endif Let's fix this on OpenRISC by defining an architecture-specific version of nop(). This was tested by performing an allmodconfig openrisc cross compile on an aarch64 host. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601180236.BVy480We-lkp@int= el.com/ Signed-off-by: Brian Masney Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/openrisc/include/asm/barrier.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/openrisc/include/asm/barrier.h b/arch/openrisc/include/as= m/barrier.h index 7538294721bed..8e592c9909023 100644 --- a/arch/openrisc/include/asm/barrier.h +++ b/arch/openrisc/include/asm/barrier.h @@ -4,6 +4,8 @@ =20 #define mb() asm volatile ("l.msync" ::: "memory") =20 +#define nop() asm volatile ("l.nop") + #include =20 #endif /* __ASM_BARRIER_H */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 89B0E35AC38; Sat, 28 Feb 2026 17:37:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300268; cv=none; b=RZHZrxyDOStT6rWAsCzojctsCPiYVHFjz1GchM7JWyUPRtCkpgDTelQq3ItVUAGQJY5ORzx47s+nGZh6iurfmdRtr3JpLrOO940FmQk+EM9TYhevY/AJ/aS3O5/Va97QqHjRUVpdFp19HuAQ8Wc2IhOK/MQ1wUp3ZQmzf8HjDCs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300268; c=relaxed/simple; bh=Smv77XQEJ5/xq6cT/QFfKDsGNU3NpzZ+gFapQgA2lqQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rH/1c6gyciWUw7ca7tShRrfN9vYVrW5tmFXMCPM38fb7dcVyB3Ch2Y78k/YXVfTCPruXPJpwlr4mW95W6B8ZEaTEBRngDF75Xd2FpZit2VpR+JLiREqymEPMakBDLvGQvAmKowFElTxbImmK2mDwpHGG2XyXnF3VboqiUqTR2BM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VgKAycxY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VgKAycxY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B85ACC116D0; Sat, 28 Feb 2026 17:37:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300268; bh=Smv77XQEJ5/xq6cT/QFfKDsGNU3NpzZ+gFapQgA2lqQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VgKAycxY70Eyyk5bZaNN0zy9GbRZheJwklgxori7bb4M1CpZJK3WtzKAMdEtP0Gu+ QBaS/uTbp4dmmruS8tPUuRggXADmxK3cVFwl9ka6Ua1wjZ0L0cITjvHe7NgmFy/7YZ vS0skvFN5GqkGsuhJtiAlcUUj8pFJHkuNFU61MpntU5twF9Wmy/Q3XspvAVbO6VXBb d2/A6L3VDxiN8GeyQ4vWzMgzq7mt0dtZuZZABqUirx4NRr0ffRPbz1JVX4NXJZPwLC QAdL2PPIzlSraVKbtSSFAboPrhja3c6CS65LF2zxvj2Jn2fkY1rbJ7AI37aZJ26NXK FBOZah8xQYD5w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mingj Ye , Hayes Wang , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 294/844] net: usb: r8152: fix transmit queue timeout Date: Sat, 28 Feb 2026 12:23:27 -0500 Message-ID: <20260228173244.1509663-295-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mingj Ye [ Upstream commit 833dcd75d54f0bf5aa0a0781ff57456b421fbb40 ] When the TX queue length reaches the threshold, the netdev watchdog immediately detects a TX queue timeout. This patch updates the trans_start timestamp of the transmit queue on every asynchronous USB URB submission along the transmit path, ensuring that the network watchdog accurately reflects ongoing transmission activity. Signed-off-by: Mingj Ye Reviewed-by: Hayes Wang Link: https://patch.msgid.link/20260120015949.84996-1-insyelu@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/usb/r8152.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 2f3baa5f6e9c9..6b107cf5f37bd 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -2449,6 +2449,8 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct= tx_agg *agg) ret =3D usb_submit_urb(agg->urb, GFP_ATOMIC); if (ret < 0) usb_autopm_put_interface_async(tp->intf); + else + netif_trans_update(tp->netdev); =20 out_tx_fill: return ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 964FC3A4414; Sat, 28 Feb 2026 17:37:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300269; cv=none; b=UaaXqZCOevlnOwOkeaNl1z7/3jf8+XQEwXDwKNFOuL82dMUTEz2mZtfMv23lGEVUHrmZllqwEt/YkDjp7jZPLKZBCfMIWNoy27HfkEGV3waLjkV5eITsp065PWRybYfGDsHKyf7PabM1wE4ffloNJFvPBuO151GQS3zU92fwLUc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300269; c=relaxed/simple; bh=1q1EO47DTeDmZ2QDAtWP7XcJKLHjRpu8B3ciVouXU6I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F7XMT6KXz0CUtwGpe19Lvd95MlRt07/AaJ6QXa8omxdiobHYoFfQznxMGV5lWhv3GDCNZq+ZrIfdk57vsaWsyT5AXNql9Pp4uUEJYqWyIpJArppaxw/AztZQa8RWc+fd/HU99aVPWGzFIUvvkR/X+GmjKNY/gfWk2EHafxAqrNk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NS2RLEMR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NS2RLEMR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABF68C19425; Sat, 28 Feb 2026 17:37:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300269; bh=1q1EO47DTeDmZ2QDAtWP7XcJKLHjRpu8B3ciVouXU6I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NS2RLEMRZrAAzn26OQH99fe5AtmI803rzoA2R46yVAlKr2Foac45G+rP/5nKCIUm5 ryQiMooSN3UHoqNJa9kfsFNcEmGT1oye8YzrkUg0eHaRVlnedY2pTx6D2vRIuZcbZD v45Ls7B5ZFTjanvwuGmikfuPkw49148kReK5hrdxlETfVnie5+IAqxkc2Ui6GiYkMS t9Gj4qCy3IF6B1rLfxi7WPFi6ePvKEi6ONNtqZPz031XLxHyfNtrQMgGWUSeZhZwQ8 xXoyiniu9i1fpHMQCD63LohywrOG29Ot9PjAgMf/pFCa4NiXGkNqoB6Ohj4+zu0Dfa r3qb63Pgc1KHg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Richard Zhu , Manivannan Sadhasivam , Alexander Stein , Frank Li , Sasha Levin Subject: [PATCH 6.19 295/844] PCI: imx6: Add CLKREQ# override to enable REFCLK for i.MX95 PCIe Date: Sat, 28 Feb 2026 12:23:28 -0500 Message-ID: <20260228173244.1509663-296-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Richard Zhu [ Upstream commit 27a064aba2da6bc58fc36a6b8e889187ae3bf89d ] The CLKREQ# is an open drain, active low signal that is driven low by the card to request reference clock. It's an optional signal added in PCIe CEM r4.0, sec 2. Thus, this signal wouldn't be driven low if it's not exposed on the slot. On the i.MX95 EVK board, REFCLK to the host and endpoint is gated by this CLKREQ# signal. So if the CLKREQ# signal is not driven by the endpoint, it will gate the REFCLK to host too, leading to operational failure. Hence, enable the REFCLK on this SoC by enabling the CLKREQ# override using imx95_pcie_clkreq_override() helper during probe. This override should only be cleared when the CLKREQ# signal is exposed on the slot. Signed-off-by: Richard Zhu [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Tested-by: Alexander Stein Reviewed-by: Frank Li Link: https://patch.msgid.link/20251015030428.2980427-11-hongxing.zhu@nxp.c= om Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pci-imx6.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller= /dwc/pci-imx6.c index f28e335bbbfaf..dd69af0f195ff 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -52,6 +52,8 @@ #define IMX95_PCIE_REF_CLKEN BIT(23) #define IMX95_PCIE_PHY_CR_PARA_SEL BIT(9) #define IMX95_PCIE_SS_RW_REG_1 0xf4 +#define IMX95_PCIE_CLKREQ_OVERRIDE_EN BIT(8) +#define IMX95_PCIE_CLKREQ_OVERRIDE_VAL BIT(9) #define IMX95_PCIE_SYS_AUX_PWR_DET BIT(31) =20 #define IMX95_PE0_GEN_CTRL_1 0x1050 @@ -706,6 +708,22 @@ static int imx7d_pcie_enable_ref_clk(struct imx_pcie *= imx_pcie, bool enable) return 0; } =20 +static void imx95_pcie_clkreq_override(struct imx_pcie *imx_pcie, bool ena= ble) +{ + regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_1, + IMX95_PCIE_CLKREQ_OVERRIDE_EN, + enable ? IMX95_PCIE_CLKREQ_OVERRIDE_EN : 0); + regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_1, + IMX95_PCIE_CLKREQ_OVERRIDE_VAL, + enable ? IMX95_PCIE_CLKREQ_OVERRIDE_VAL : 0); +} + +static int imx95_pcie_enable_ref_clk(struct imx_pcie *imx_pcie, bool enabl= e) +{ + imx95_pcie_clkreq_override(imx_pcie, enable); + return 0; +} + static int imx_pcie_clk_enable(struct imx_pcie *imx_pcie) { struct dw_pcie *pci =3D imx_pcie->pci; @@ -1916,6 +1934,7 @@ static const struct imx_pcie_drvdata drvdata[] =3D { .core_reset =3D imx95_pcie_core_reset, .init_phy =3D imx95_pcie_init_phy, .wait_pll_lock =3D imx95_pcie_wait_for_phy_pll_lock, + .enable_ref_clk =3D imx95_pcie_enable_ref_clk, }, [IMX8MQ_EP] =3D { .variant =3D IMX8MQ_EP, @@ -1972,6 +1991,7 @@ static const struct imx_pcie_drvdata drvdata[] =3D { .core_reset =3D imx95_pcie_core_reset, .wait_pll_lock =3D imx95_pcie_wait_for_phy_pll_lock, .epc_features =3D &imx95_pcie_epc_features, + .enable_ref_clk =3D imx95_pcie_enable_ref_clk, .mode =3D DW_PCIE_EP_TYPE, }, }; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C3D23A442E; Sat, 28 Feb 2026 17:37:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300270; cv=none; b=cJ/WNhhZ4Vaqrp3CtzPefcBVtQdq3KQ/v3wvxG++rWTn3j4pevwWfKD3BUdDfxCvD7ZqWmbpUQAI9N2Anyl1giXMRsxvBQ+rQKdB/bOKDs6PZ6LCMjUwxSJDvoEFVhNPHSYZ6oxjjRzo3r+D3CFg/LcKfED1wDXN8P1xxe+rFoE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300270; c=relaxed/simple; bh=bJq2LZ/QHMgMd9+Pf3DGjsGyDKmiuUdJu/6wChtH6Vg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=R44kulU6forg9T5kLErbmRZi6oz5nYg166oi4ODBfRqTlDxgtlfl8pVmb59Hc+dszhJiN5muOwzL00MwkySp63/nIqEIqeLb3ZyjpZfVjMkW9gAf2cDKKJ1SzbM3a893JlLlxj53rG0GV9XH7dxpl5eh0gx0tHpn5wzgddsWIXM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=krd5snGX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="krd5snGX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B552BC19425; Sat, 28 Feb 2026 17:37:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300270; bh=bJq2LZ/QHMgMd9+Pf3DGjsGyDKmiuUdJu/6wChtH6Vg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=krd5snGXchRFuJxYUiTbf3bitRcX2Ypgny81OwTOdr3J1cz9P4CPVp2n43+zIKJuW W6MKWHwFXkItFVq8JXOLpwhXVaF8AR/ursGqEAa2uTepzrVirzXDSWQ4/PuKZ4JJAV m/1rBWvwSzhCUfGZuSQDvM78LznQ4eBc2mXyppLWwVoO3IL7aCEHxN4sTxbq1Tk7A7 0GdhshPTrPb83TEtxNAO182qx8cgL81ufhbn5uTiYdctG4c8d5E4GHuE72rGkf2YPs WufQ+xR7vdKS99ZdwpBfviTaU/isUTOf1icJZC2kqwpB7JWEMlUbWn5GLbxhoyf8n5 lDKw/HQz6n2OA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ilan Peer , Miri Korenblit , Sasha Levin Subject: [PATCH 6.19 296/844] wifi: iwlwifi: mld: Handle rate selection for NAN interface Date: Sat, 28 Feb 2026 12:23:29 -0500 Message-ID: <20260228173244.1509663-297-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ilan Peer [ Upstream commit dbbeebece03050cd510073ce89fee83844e06b00 ] Frames transmitted over a NAN interface might not have channel information assigned to them. In such cases assign the lowest OFDM to the frame. Signed-off-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251110180612.72046f98f878.Ib784931fffd0747= acd9d7bb22eabbbec5282733e@changeid Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/intel/iwlwifi/mld/tx.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/wireless/intel/iwlwifi/mld/tx.c b/drivers/net/wire= less/intel/iwlwifi/mld/tx.c index 3b4b575aadaa5..e3fb4fc4f452e 100644 --- a/drivers/net/wireless/intel/iwlwifi/mld/tx.c +++ b/drivers/net/wireless/intel/iwlwifi/mld/tx.c @@ -345,6 +345,11 @@ u8 iwl_mld_get_lowest_rate(struct iwl_mld *mld, =20 iwl_mld_get_basic_rates_and_band(mld, vif, info, &basic_rates, &band); =20 + if (band >=3D NUM_NL80211_BANDS) { + WARN_ON(vif->type !=3D NL80211_IFTYPE_NAN); + return IWL_FIRST_OFDM_RATE; + } + sband =3D mld->hw->wiphy->bands[band]; for_each_set_bit(i, &basic_rates, BITS_PER_LONG) { u16 hw =3D sband->bitrates[i].hw_value; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 323073A3517; Sat, 28 Feb 2026 17:37:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300271; cv=none; b=imWT7WsTcgpSMl3ZwoUk0of9tdTAr0zYWwrYQ0BirOdGFu7qDsT72F6nECNPO19FGYa2JLbdXr4UCNfWHdu8rc6lXAOsuarsxHCKDfMpKI7Ml8tzpt7wtuct0MeZ1r5F64n86M0wFHdstRs78BHiTPmsaDMBuS4gJ3Wt6zF09zU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300271; c=relaxed/simple; bh=J9hh2TDRS52hjtfXWjezCpSO0luovuop9OjDEah+r/g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eZ7IhBI7/I6PB3x5QiwFAAPN8Hiv4/+YX5w4p2Vpl6Di3ckbtrYb3WHM2j4b/8Ir2y5VkrnSm031eV7T0h8uCqbtE+FqPhNYE/gWz47FZflM+BPJ05OC0O9HvCoEuwotnb/deYgTePfHnEtneJCHJNnw9mtnztlxDSuv1FPUf6I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=avt9UWA1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="avt9UWA1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F17EC2BC87; Sat, 28 Feb 2026 17:37:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300271; bh=J9hh2TDRS52hjtfXWjezCpSO0luovuop9OjDEah+r/g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=avt9UWA1X74I+QscRvM5ISxL6K+aHtBOocfbRT8TgsBKy/0hjjZ4A7MCgzhv9krlV J6rQxBgpPasy5EL3cxEKcXIDAr4a3FYfl78liFAmbvdMvY2ta10MorJe0Fj2GShxkT kxzEEpRUHopG2w5Q3NA8KpBgeenPjegy4u2M7MTGMYYYJ1B065oCzHuLmiS9akA0EQ 5gxboTWZFNLq2rOwe58+Dgm/6NjCZY1GC36aS8VFrOrMDtRmxlbSY5Ez5MxTm4+hOe UF5/AY+AhB4kmwtD/jZ4bGhSgyogeBI1p8+vuUPDIMLLdiGHXE3fKBR8zpxnIctDLP HdDDepXo0WAWg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miri Korenblit , Sasha Levin Subject: [PATCH 6.19 297/844] wifi: iwlwifi: mvm: check the validity of noa_len Date: Sat, 28 Feb 2026 12:23:30 -0500 Message-ID: <20260228173244.1509663-298-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miri Korenblit [ Upstream commit 1e3fb3c4a8e6c581d0f4533dba887fabf53d607d ] Validate iwl_probe_resp_data_notif::noa_attr::len_low since we are using its value to determine the noa_len, which is later used for the NoA attribute. Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251110150012.99b663d9b424.I206fd54c990ca9e= 1160b9b94fa8be44e67bcc1b9@changeid Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c b/drivers/ne= t/wireless/intel/iwlwifi/mvm/mac-ctxt.c index 867807abde664..49ffc4ecee855 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c @@ -1761,6 +1761,20 @@ void iwl_mvm_probe_resp_data_notif(struct iwl_mvm *m= vm, =20 mvmvif =3D iwl_mvm_vif_from_mac80211(vif); =20 + /* + * len_low should be 2 + n*13 (where n is the number of descriptors. + * 13 is the size of a NoA descriptor). We can have either one or two + * descriptors. + */ + if (IWL_FW_CHECK(mvm, notif->noa_active && + notif->noa_attr.len_low !=3D 2 + + sizeof(struct ieee80211_p2p_noa_desc) && + notif->noa_attr.len_low !=3D 2 + + sizeof(struct ieee80211_p2p_noa_desc) * 2, + "Invalid noa_attr.len_low (%d)\n", + notif->noa_attr.len_low)) + return; + new_data =3D kzalloc(sizeof(*new_data), GFP_KERNEL); if (!new_data) return; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F3DF63A4CE5; Sat, 28 Feb 2026 17:37:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300272; cv=none; b=H60Avz757yVhGNLIZhHkL2q20+HiVCvpgO/W4NFDO9sKe0Ua2i06WyWN7EG/Nilf2u4/9JXOxFZNWxxa6AJH65sWAhfZF92Zw3uCChOnAo2hBVvGt2S4TTHdc4awx/4dKj1ccuTsBNFLrjwUzwSLHqahsAIaQzqiz2e7ikkCZG4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300272; c=relaxed/simple; bh=RzstUXFG7JLCuxr8fK6201BQ2AMv30CU3hWOpQjt/BA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oH6ThO1eBcC4Bqkj54XvekdLrlgtC68ERvhF+QRtXXn+zg1hgIK18sR9Upb92lDsShcARMNURp3mLC2N/rBkq8YGLu7xhVIh9yW5G6709SJTY19kCjBjvuDeqiS3UQBWUzr3sdpMLLsUMLBmF03yXGZI39mX1SMGsY6L7j63rcg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eg6QI1Qt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eg6QI1Qt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E793C116D0; Sat, 28 Feb 2026 17:37:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300271; bh=RzstUXFG7JLCuxr8fK6201BQ2AMv30CU3hWOpQjt/BA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eg6QI1QtDWVEEd/ot9k+7zzHmd0Kbc8HMQqwyqDbqznJhBGKSg5PNq6zjiF6AcyrA z0gmwteFKucUPrgG8ejeGV8/VZTROJo69Rml9Bpy7vJt1YIGvA1ZCKFcCy3VesTUJa oseOyYofb8VYmuJtRoJF6TvSkYLKpOmmn1ETGVZCcGzPh/5s8rdRAB2uLSrcXIyIVs I8v/GV+h1O8w95PgmCzuDcfcXW8jW0cGSSK2WxCMDBHeSXV6/CRa0OQLzXvfM1VPdm VSFwzQrNvBxfa3uLoiqLaT1mAr5MUvlOPYFoL4GDncVDDKYHM1kc4GAozgoUf2YELb CkwZXPeffBtFw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Miri Korenblit , Sasha Levin Subject: [PATCH 6.19 298/844] wifi: iwlwifi: fix 22000 series SMEM parsing Date: Sat, 28 Feb 2026 12:23:31 -0500 Message-ID: <20260228173244.1509663-299-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit 58192b9ce09b0f0f86e2036683bd542130b91a98 ] If the firmware were to report three LMACs (which doesn't exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is an overrun of the array. Reject such and use IWL_FW_CHECK instead of WARN_ON in this function. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251110150012.16e8c2d70c26.Iadfcc1aedf43c51= 75b3f0757bea5aa232454f1ac@changeid Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/intel/iwlwifi/fw/smem.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/fw/smem.c b/drivers/net/wir= eless/intel/iwlwifi/fw/smem.c index 90fd69b4860c1..344ddde85b189 100644 --- a/drivers/net/wireless/intel/iwlwifi/fw/smem.c +++ b/drivers/net/wireless/intel/iwlwifi/fw/smem.c @@ -6,6 +6,7 @@ */ #include "iwl-drv.h" #include "runtime.h" +#include "dbg.h" #include "fw/api/commands.h" =20 static void iwl_parse_shared_mem_22000(struct iwl_fw_runtime *fwrt, @@ -17,7 +18,9 @@ static void iwl_parse_shared_mem_22000(struct iwl_fw_runt= ime *fwrt, u8 api_ver =3D iwl_fw_lookup_notif_ver(fwrt->fw, SYSTEM_GROUP, SHARED_MEM_CFG_CMD, 0); =20 - if (WARN_ON(lmac_num > ARRAY_SIZE(mem_cfg->lmac_smem))) + /* Note: notification has 3 entries, but we only expect 2 */ + if (IWL_FW_CHECK(fwrt, lmac_num > ARRAY_SIZE(fwrt->smem_cfg.lmac), + "FW advertises %d LMACs\n", lmac_num)) return; =20 fwrt->smem_cfg.num_lmacs =3D lmac_num; @@ -26,7 +29,8 @@ static void iwl_parse_shared_mem_22000(struct iwl_fw_runt= ime *fwrt, fwrt->smem_cfg.rxfifo2_size =3D le32_to_cpu(mem_cfg->rxfifo2_size); =20 if (api_ver >=3D 4 && - !WARN_ON_ONCE(iwl_rx_packet_payload_len(pkt) < sizeof(*mem_cfg))) { + !IWL_FW_CHECK(fwrt, iwl_rx_packet_payload_len(pkt) < sizeof(*mem_cfg), + "bad shared mem notification size\n")) { fwrt->smem_cfg.rxfifo2_control_size =3D le32_to_cpu(mem_cfg->rxfifo2_control_size); } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 041E33A4D13; Sat, 28 Feb 2026 17:37:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300273; cv=none; b=teCruZ0zdueeo9B/G9LeXjOmkabLAT1arzXf35eyZNhZFeOyDzE9tKD0cwM2F8kibk4POqWAgRDCck66qfOIYxZi6W5sXVdOkJmr/m4NPAAfK8GFla8wUJA7S9lS2EZMKovHR/ggyPDMHregzVe/sQZCHusa7ZQ9hP2NuIGLARQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300273; c=relaxed/simple; bh=fDYPcimZDZhPGyE2cEZ+FxCWO3FkJ2vofv7HgYRbTFQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jy8SNduusTcrS3I1pVt2Qkx6zc7uScDi81qh4JryTe2uH42oB5y9yNYv3fjMlP6ao+8uoGanzJfGzSIFPfFird+XNf70iB7MHRAOgyU2mQZloE/S0CZc1i4kwdZ6xOApq6LfeocEmhrzc5sDkuLMT+7L6LqMNgHFabUVMen1DnQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TvZki4Q4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TvZki4Q4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24628C2BC87; Sat, 28 Feb 2026 17:37:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300272; bh=fDYPcimZDZhPGyE2cEZ+FxCWO3FkJ2vofv7HgYRbTFQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TvZki4Q4nXV3dETx1LsvyRYgxBHZSqa2UWkFRCAmifWVKUlw8jQk6CFGyFXtVJ8Bf 9VCy4bgwivzKM3pmnCtp88cCT3qtZWw1ai0TuKMZ5HQJuAClVzMeOA+ukzLo7gX4wP 62inojGDY6958imEGCYy6fKD8rNSFgDv24wqw7o3aQRx+RzZjcJwBBujBi3OCso8g1 XubS5k3muWzn4tYEpMOijeqjwZ4c7fZGoGMHDUSQifpUWSaAvbhDLnwJSgr+6PO+xU tXC9ExGi4k5/bYQzWKviTlP8ixuDRKHZ3rvySlwJQF+J3UUKWLf2v9g/XVuiJriQh1 NWbGTXgAC5L+A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miri Korenblit , Johannes Berg , Sasha Levin Subject: [PATCH 6.19 299/844] wifi: iwlwifi: mld: fix chandef start calculation Date: Sat, 28 Feb 2026 12:23:32 -0500 Message-ID: <20260228173244.1509663-300-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miri Korenblit [ Upstream commit d2fcdf36554316cc51f7928b777944738d06e332 ] A link pair in which both links are in 5 GHz can be used for EMLSR only if they are separated enough. To check this condition we calculate the start and the end of the chandefs of both links in the pair and do some checks. But the calculation of the start/end of the chandef is currently done by subtracting/adding half the bandwidth from/to the control channel's center frequency, when it should really be subtracted/added from/to the center frequency of the entire chandef. Fix the wrong calculation. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260111193638.2138fdb99bd5.I4d2e5957b22482a= 57b1d6ca444e90fcf73bf2cab@changeid Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/intel/iwlwifi/mld/mlo.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mlo.c b/drivers/net/wir= eless/intel/iwlwifi/mld/mlo.c index c6b151f269216..1efefc737248f 100644 --- a/drivers/net/wireless/intel/iwlwifi/mld/mlo.c +++ b/drivers/net/wireless/intel/iwlwifi/mld/mlo.c @@ -844,9 +844,9 @@ iwl_mld_emlsr_pair_state(struct ieee80211_vif *vif, if (c_low->chan->center_freq > c_high->chan->center_freq) swap(c_low, c_high); =20 - c_low_upper_edge =3D c_low->chan->center_freq + + c_low_upper_edge =3D c_low->center_freq1 + cfg80211_chandef_get_width(c_low) / 2; - c_high_lower_edge =3D c_high->chan->center_freq - + c_high_lower_edge =3D c_high->center_freq1 - cfg80211_chandef_get_width(c_high) / 2; =20 if (a->chandef->chan->band =3D=3D NL80211_BAND_5GHZ && --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCA633A59E3; Sat, 28 Feb 2026 17:37:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300273; cv=none; b=CXxS/nqeNKmZBH5Fv4f0mvgN3xmaS3vejo/gkI9YmpNByo4oGPyoIF7mdK166i+lbYmpuk2GaJRe47Jfuv2zQYbQJ1bNY24JgIaa/qoFFhxJEUXin1Zz+mRGUknofT8Vu68T7q3tMq2eytZhkoJPIUYcTwKl0exxGHl7AA9RLcA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300273; c=relaxed/simple; bh=gJvoOS1G0SEBpK4bqZ8aDz5SyzG1f22OCR2LHiixi40=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p+Cymq/AJm21vLKrLjgC8uB7eDofqlTdRM294oIp6eUpwwCf6pzc9ek8ymfcmdg6aXwp6hEzS5aN7rBanBLU3ZV2rufOSEUK47O0HMgeYLHZQXHtee5xjWDDyEqmHWucOUXdbAunQkFsDaLFJnD8wGsvvNeONUdtW0DIRgGObms= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qT8/897L; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qT8/897L" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBBF5C2BCAF; Sat, 28 Feb 2026 17:37:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300273; bh=gJvoOS1G0SEBpK4bqZ8aDz5SyzG1f22OCR2LHiixi40=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qT8/897LhbaKSNP9pdDB3E3Sh4KaFMpJ/BYeBI5avwBPsZyT6piOyeNUtpD2yj5qk 8iUMYU/oUnFL6dYWnQZffq2HCGOdHwu/+FhuegP6khdCuU7TNlqhqbVXIr73eMFaaI N+vQvNxNUkOWeZv6IU1uk4bh4KJW3fPCJLicnrOU8iaF/S/QlE4gffhxDAg/FgPNRg SobXwY94dhWHhVgkqrKM5Lv8qyA7jx1N5iLf+oybrPrcUzP3FDkxZfmVc64aFA6dB7 jsPozlAsk2gt638MX3Wm7kQVviqW9LYM5G1moET8tuc7tKlteHltiLmRQtz1UZCOu3 ok6ymL3bMQLmA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nidhish A N , Miri Korenblit , Sasha Levin Subject: [PATCH 6.19 300/844] wifi: iwlwifi: mld: Fix primary link selection logic Date: Sat, 28 Feb 2026 12:23:33 -0500 Message-ID: <20260228173244.1509663-301-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nidhish A N [ Upstream commit 7a749db26cab2334d5b356ac31e6f1147c7682da ] When assigning emlsr.primary with emlsr.selected_primary we are checking if BIT(mld_vif->emlsr.selected_links) are a part of vif->active_links. This is incorrect as emlsr.selected_links is a bitmap of possibly two selected links. Therefore, performing the BIT() operation on it does not yield any meaningful result and almost always leads to incorrect primary link selection. Additionally, we cannot rely on vif->active_links at this stage of the link switch flow because it contains both the removed links and also the newly added links. For example, if we had selected links in the past (0x11) and we now select links because of TTLM/debugfs (0x100), vif->active_links will now be (0x111) and primary link will be 0, while 0 is not even an active link. Thus, we create our own bitmap of final active links. Signed-off-by: Nidhish A N Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260111193638.38b2e14e3a20.Ie81a88dfff0c5d2= becedabab8398702808f6b1bf@changeid Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../net/wireless/intel/iwlwifi/mld/mac80211.c | 23 ++++++++++++------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c b/drivers/ne= t/wireless/intel/iwlwifi/mld/mac80211.c index cd0dce8de8569..3a1b5bfb9ed66 100644 --- a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c +++ b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c @@ -984,7 +984,9 @@ int iwl_mld_assign_vif_chanctx(struct ieee80211_hw *hw, { struct iwl_mld *mld =3D IWL_MAC80211_GET_MLD(hw); struct iwl_mld_link *mld_link =3D iwl_mld_link_from_mac80211(link); - unsigned int n_active =3D iwl_mld_count_active_links(mld, vif); + struct iwl_mld_link *temp_mld_link; + struct iwl_mld_vif *mld_vif =3D iwl_mld_vif_from_mac80211(vif); + u16 final_active_links =3D 0; int ret; =20 lockdep_assert_wiphy(mld->wiphy); @@ -992,10 +994,7 @@ int iwl_mld_assign_vif_chanctx(struct ieee80211_hw *hw, if (WARN_ON(!mld_link)) return -EINVAL; =20 - /* if the assigned one was not counted yet, count it now */ if (!rcu_access_pointer(mld_link->chan_ctx)) { - n_active++; - /* Track addition of non-BSS link */ if (ieee80211_vif_type_p2p(vif) !=3D NL80211_IFTYPE_STATION) { ret =3D iwl_mld_emlsr_check_non_bss_block(mld, 1); @@ -1016,17 +1015,25 @@ int iwl_mld_assign_vif_chanctx(struct ieee80211_hw = *hw, =20 rcu_assign_pointer(mld_link->chan_ctx, ctx); =20 - if (n_active > 1) { - struct iwl_mld_vif *mld_vif =3D iwl_mld_vif_from_mac80211(vif); + /* We cannot rely on vif->active_links at this stage as it contains + * both the removed links and the newly added links. + * Therefore, we create our own bitmap of the final active links, + * which does not include the removed links. + */ + for_each_mld_vif_valid_link(mld_vif, temp_mld_link) { + if (rcu_access_pointer(temp_mld_link->chan_ctx)) + final_active_links |=3D BIT(link_id); + } =20 + if (hweight16(final_active_links) > 1) { /* Indicate to mac80211 that EML is enabled */ vif->driver_flags |=3D IEEE80211_VIF_EML_ACTIVE; mld_vif->emlsr.last_entry_ts =3D jiffies; =20 - if (vif->active_links & BIT(mld_vif->emlsr.selected_links)) + if (final_active_links =3D=3D mld_vif->emlsr.selected_links) mld_vif->emlsr.primary =3D mld_vif->emlsr.selected_primary; else - mld_vif->emlsr.primary =3D __ffs(vif->active_links); + mld_vif->emlsr.primary =3D __ffs(final_active_links); =20 iwl_dbg_tlv_time_point(&mld->fwrt, IWL_FW_INI_TIME_ESR_LINK_UP, NULL); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 894343A59FB; Sat, 28 Feb 2026 17:37:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300274; cv=none; b=pV9j3/1b77FqK3JO/cpAGED/h/4hY3ml/pTINzTJNiW5VZ5HZxSjqROqA429pf/jLy/YW0T37yYFH0gXrzRm5/y9+VlfWS+05oLQiahxzRK1uFPMGf6s4xLEKt3+OndnDqkGJZ63CY2XU8DjqVmqeGjsWaoYC8mB3fS/WbkxHVg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300274; c=relaxed/simple; bh=e3ZXd0XXxi0wpZ4x26jBB6Oe3mMb01vU4qY4HNeryYw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bQXZ+35vDowg2Bjv3z4g5otkQ4GkWBAiOwr5XPjPk9ThFWOIML/20AA/auBeTgIISn/pMj5ufOB/Ui+ZTA8G5ENPDwttHDgTfSxAL9VNonwlfRWKrrOo7NIl7nla+tLqmTflcVaZ/AQbQ0r/9WEv62u7nLWmYWaWrHCXcCt6800= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cOZnsK2K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cOZnsK2K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C340FC19423; Sat, 28 Feb 2026 17:37:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300274; bh=e3ZXd0XXxi0wpZ4x26jBB6Oe3mMb01vU4qY4HNeryYw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cOZnsK2KCTG9UN79TBPdr2xG4oY8ZL1EmKK02mXiDVJ4BDaoMTwnV7TKWu1fQQorN NqScjvAhjscD48lYOR4rWeBJ9hT4URfeHZ1OAfntg0x1Y0pqSiWcGSyeUhDIiS39Gn tEUoO7PI/wcvhK5vS9D3vdUMuO0IKRRaA9Fl94tbd9tsyfrHsCksXmj/PGY6iNGIJU T3mUisSEld1hfVVKBZtQIHtGAthYv4/0Pk4oBjGl+I4cMLl+uBRPcPMFYKDK5WSav0 qD7+8Cbl1TQtwS1HKCvVCBwpCsU29V/8tFn6l7A0b8nN28IL7D3jiN0N5Xiam/xRKF w7MNCja5LR7Dw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Gui-Dong Han , Danilo Krummrich , Sasha Levin Subject: [PATCH 6.19 301/844] driver core: faux: stop using static struct device Date: Sat, 28 Feb 2026 12:23:34 -0500 Message-ID: <20260228173244.1509663-302-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Greg Kroah-Hartman [ Upstream commit 61b76d07d2b46a86ea91267d36449fc78f8a1f6e ] faux_bus_root should not have been a static struct device, but rather a dynamically created structure so that lockdep and other testing tools do not trip over it (as well as being the right thing overall to do.) Fix this up by making it properly dynamic. Reported-by: Gui-Dong Han Closes: https://lore.kernel.org/lkml/CALbr=3DLYKJsj6cbrDLA07qioKhWJcRj+gW8= =3Dbq5=3D4ZvpEe2c4Yg@mail.gmail.com/ Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/2026012145-lapping-countless-ef81@gregkh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/base/faux.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/base/faux.c b/drivers/base/faux.c index 21dd02124231a..23d7258172325 100644 --- a/drivers/base/faux.c +++ b/drivers/base/faux.c @@ -29,9 +29,7 @@ struct faux_object { }; #define to_faux_object(dev) container_of_const(dev, struct faux_object, fa= ux_dev.dev) =20 -static struct device faux_bus_root =3D { - .init_name =3D "faux", -}; +static struct device *faux_bus_root; =20 static int faux_match(struct device *dev, const struct device_driver *drv) { @@ -152,7 +150,7 @@ struct faux_device *faux_device_create_with_groups(cons= t char *name, if (parent) dev->parent =3D parent; else - dev->parent =3D &faux_bus_root; + dev->parent =3D faux_bus_root; dev->bus =3D &faux_bus_type; dev_set_name(dev, "%s", name); device_set_pm_not_required(dev); @@ -236,9 +234,15 @@ int __init faux_bus_init(void) { int ret; =20 - ret =3D device_register(&faux_bus_root); + faux_bus_root =3D kzalloc(sizeof(*faux_bus_root), GFP_KERNEL); + if (!faux_bus_root) + return -ENOMEM; + + dev_set_name(faux_bus_root, "faux"); + + ret =3D device_register(faux_bus_root); if (ret) { - put_device(&faux_bus_root); + put_device(faux_bus_root); return ret; } =20 @@ -256,6 +260,6 @@ int __init faux_bus_init(void) bus_unregister(&faux_bus_type); =20 error_bus: - device_unregister(&faux_bus_root); + device_unregister(faux_bus_root); return ret; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DE5F3A5A1C; Sat, 28 Feb 2026 17:37:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300275; cv=none; b=YLrinaLd/LBWZRMQD8aMR7G2gVLUirHKSvMNvMA1jjjIswfW91lfw8reyn2uLhJNfPs1tudscXtOdMTkY+ro+KM8fzxFNg3wwIdhnS9nhSshOnaBLNLAsVl/K/fNZHGqrDBHu85OBPZTMsZVI16twc6lL2RgVx55+LmrjqbHdCE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300275; c=relaxed/simple; bh=MMSSer0k20ovm9AVm12BbD48NnYmwBswdSk0nVSpXXA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LrYit72RtRXB33HQY/apX9jGW1Wd1Zgv/hoa+tZAzl1sbtVBeba3KqpkBJ4WFiYZTv7/98Hh+sIeg/+ujWN7jpxThEZPiZs2jmKzizYDEtQT9qjJMrwPjD0CcTYdU8Ss8wUlbBWManIH3EhCmEXrSbes9tks9/g5eVwOGiQ5e7o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jWodSM1c; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jWodSM1c" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE701C19423; Sat, 28 Feb 2026 17:37:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300275; bh=MMSSer0k20ovm9AVm12BbD48NnYmwBswdSk0nVSpXXA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jWodSM1c9Xfa5qfN476g2fZsJHXfnyd51MI34WtEVksOsnrSu1nGXRvoyn0vY1MzM RDc+eu1StzCno5RjtjixU5NYEYyMAAajw31kJLYMyHAJmdEJL1nkg8ARTnCCSTx26n mPc0kTJgjVEWUq8PPH+lKTN+Z7dzCu74usIeK5H5bbqFjrQjv4PTJ5sHGIbYrk/O8L JGentsoOehwduKhZZdgBNOTTk4FucWUtDYbaOKpLQWjtUydBd8ZnuJhnGxSnmnnLjg kTIRClojFD9Y859p7A+LA4BixpXcgOXo7JJafrGTfhVtTvzKXM6J1NatnEVK0Ra0ay ov7Uo9lnIxyow== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shin-Yi Lin , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 302/844] wifi: rtw89: Add default ID 28de:2432 for RTL8832CU Date: Sat, 28 Feb 2026 12:23:35 -0500 Message-ID: <20260228173244.1509663-303-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shin-Yi Lin [ Upstream commit 5f65ebf9aaf00c7443252136066138435ec03958 ] Add 28de:2432 for RTL8832CU-based adapters that use this default ID. Signed-off-by: Shin-Yi Lin Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260114014906.21829-1-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/rtw8852cu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852cu.c b/drivers/net/w= ireless/realtek/rtw89/rtw8852cu.c index 2708b523ca141..3b9825c92a0d9 100644 --- a/drivers/net/wireless/realtek/rtw89/rtw8852cu.c +++ b/drivers/net/wireless/realtek/rtw89/rtw8852cu.c @@ -46,6 +46,8 @@ static const struct usb_device_id rtw_8852cu_id_table[] = =3D { .driver_info =3D (kernel_ulong_t)&rtw89_8852cu_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x0db0, 0x991d, 0xff, 0xff, 0xff), .driver_info =3D (kernel_ulong_t)&rtw89_8852cu_info }, + { USB_DEVICE_AND_INTERFACE_INFO(0x28de, 0x2432, 0xff, 0xff, 0xff), + .driver_info =3D (kernel_ulong_t)&rtw89_8852cu_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x35b2, 0x0502, 0xff, 0xff, 0xff), .driver_info =3D (kernel_ulong_t)&rtw89_8852cu_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x35bc, 0x0101, 0xff, 0xff, 0xff), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3019F3A6960; Sat, 28 Feb 2026 17:37:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300276; cv=none; b=iXcJoKg6R3hnxuMaZDi5KLr7G44bmpSdJP8Attx1L7SmmTTnqABpUBQ5448/O8MfO6Ha9QMBSTB8JW0Wn4WAyTIxpGLcDgm3hkYYXqRCA1VAOJ3+YcguPzFAsRRH3BY0Dq8EwMM2u8Bpuhet6uQxmQzK6fjOsiakixDTeElysZY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300276; c=relaxed/simple; bh=uI126Z1WtTNezlLB3PPjgMNZ2JlP6lOGG8iNb1PxktY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SJd3QYYxiQxCvJ1qx5o+rJqEV2x3pEYzU+Xy7pQL2Ce+MshLAu7WC2xbxbOiNkkWxihpj7ZnVE4p8nZKrsi/BZBlnRbEHiUd+OGKdiRB04OXQRACGk+lK4ULUuEzgpuozDfk4AQ9DrJFj4mVezsH64n6O6y7si7QiwpK2PeRf+c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Kf9Jmkut; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Kf9Jmkut" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8460AC19425; Sat, 28 Feb 2026 17:37:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300276; bh=uI126Z1WtTNezlLB3PPjgMNZ2JlP6lOGG8iNb1PxktY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kf9Jmkut1Qscl1IioL/JnbUDjxBsSTiHnRjb/MWkqGuC1GAPcKJpXEPSsSu5D+TWC +uflZpY12esiDU0aqru7Q6bsRAGrUf6iZQAciffwGJ1UvDfZobs9IWVHjCZ67HbGR6 GvsHDnU7GREZl1AYt40GmrwPAD0CQGqq9cw8Xwe5JY6Fxfo8Z5cPLgpg4FHBQV+9J4 0tGGrSzxdYkMPSyWUzJTgb8HIxJlUjCJEQ+Z7R7+60Uy9914OGDdPNCt2xB7m0HTYF RcnXLVhufjtjADXdqHbVjWZdEhYSpQziCE6DydRwnbwOGFzpqWYdULoTEJDufR/Qcg vzWS9ydwxm11w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Po-Hao Huang , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 303/844] wifi: rtw89: fix unable to receive probe responses under MLO connection Date: Sat, 28 Feb 2026 12:23:36 -0500 Message-ID: <20260228173244.1509663-304-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Po-Hao Huang [ Upstream commit 6f6d7a325fbde4f025ee1b1277f6f44727e21223 ] During MLO connections, A1 of the probe responses we received are in link address, these frames will then be dropped by mac80211 due to not matching the MLD address in ieee80211_scan_accept_presp(). Fix this by using MLD address to scan when not using random MAC address. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260114013950.19704-13-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/fw.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless= /realtek/rtw89/fw.c index 7b9d9989e5170..2f68a04cc028f 100644 --- a/drivers/net/wireless/realtek/rtw89/fw.c +++ b/drivers/net/wireless/realtek/rtw89/fw.c @@ -8114,6 +8114,7 @@ int rtw89_hw_scan_start(struct rtw89_dev *rtwdev, struct cfg80211_scan_request *req =3D &scan_req->req; const struct rtw89_chan *chan =3D rtw89_chan_get(rtwdev, rtwvif_link->chanctx_idx); + struct ieee80211_vif *vif =3D rtwvif_link_to_vif(rtwvif_link); struct rtw89_vif *rtwvif =3D rtwvif_link->rtwvif; struct rtw89_chanctx_pause_parm pause_parm =3D { .rsn =3D RTW89_CHANCTX_PAUSE_REASON_HW_SCAN, @@ -8142,6 +8143,8 @@ int rtw89_hw_scan_start(struct rtw89_dev *rtwdev, if (req->flags & NL80211_SCAN_FLAG_RANDOM_ADDR) get_random_mask_addr(mac_addr, req->mac_addr, req->mac_addr_mask); + else if (ieee80211_vif_is_mld(vif)) + ether_addr_copy(mac_addr, vif->addr); else ether_addr_copy(mac_addr, rtwvif_link->mac_addr); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 044203A697F; Sat, 28 Feb 2026 17:37:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300277; cv=none; b=qSpe+kk31ETXHq6QrUwMkW2pt3hDfubr9pjtvxy96oR9mwxgjG0LQ38U5qeRfvaHT+Y6sF6roZsFsa2jJO5tazx0TVbZE9MNFwMdp7g2kwq7vPn2GoCl11c6K7X7o6rTjq3bPZDZeJMTmgnUDwJYApTkyeLuRGGX3wZiOSuIZPU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300277; c=relaxed/simple; bh=uAQHOJwY6yHG0F4UleYU7O5AEtJGqzbnVcSUfGuXGDQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=upF8lsViQY1FAl+OrJJtMUImLviqxA477Zey0Q0Aer/qDYD1eqJLXAS1erqculSTft28GEJ0CVAVy/OmjlI7c267vQgwCG/8ekOPkxiRkKxTn0U+LW6+HeqbS6rvxFrjlwuh8VOyxUvwv/k2Bp7+RpRpiJA7bF4ayTwQe9RZnwI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jWDXpmcg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jWDXpmcg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56928C116D0; Sat, 28 Feb 2026 17:37:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300276; bh=uAQHOJwY6yHG0F4UleYU7O5AEtJGqzbnVcSUfGuXGDQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jWDXpmcgaaYbbTZ3uc6F7CCk7pZA3V0XjgxgW31KyIex7GwSo+tp707J3ghnxfoxb f5rEvuBOwkogRLFMcOutJ0LT6sakejUJbv3TAP/sEILRtuJECQjOwFHCQL3ptEv1QH fu7Ui2mxNwB9Apj8eWSOwid3HGtbjtNMuOKdp4CN9JdFfRYtYbocU3YevKhx7vr28v 5ohS0kmMhzgfWjsGZVLsIWmGvdx8BRQhgZftOdIbL0R9nOb0yyMvXJgmNASFw8mgAG 5DmVWuNgv1Gt1B75LaXSZThByVt7marEkiGMJmCLl48Sqio6tXaFmMp18MAzhz3OWZ tvcwbV3AxjbDA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Po-Hao Huang , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 304/844] wifi: rtw89: 8922a: add digital compensation for 2GHz Date: Sat, 28 Feb 2026 12:23:37 -0500 Message-ID: <20260228173244.1509663-305-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Po-Hao Huang [ Upstream commit 8da7e88682d58a7c2e2c2101e49d3c9c9ac481b0 ] This fixes transmit power too low under 2GHz connection. Previously we missed the settings of 2GHz, add the according calibrated tables. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260117044157.2392958-10-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/rtw8922a.c | 57 +++++++++++++++---- 1 file changed, 47 insertions(+), 10 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw89/rtw8922a.c b/drivers/net/wi= reless/realtek/rtw89/rtw8922a.c index 4bcf20612a455..52da0fa02da01 100644 --- a/drivers/net/wireless/realtek/rtw89/rtw8922a.c +++ b/drivers/net/wireless/realtek/rtw89/rtw8922a.c @@ -1770,6 +1770,32 @@ static int rtw8922a_ctrl_rx_path_tmac(struct rtw89_d= ev *rtwdev, } =20 #define DIGITAL_PWR_COMP_REG_NUM 22 +static const u32 rtw8922a_digital_pwr_comp_2g_s0_val[][DIGITAL_PWR_COMP_RE= G_NUM] =3D { + {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320, + 0x0D05091D, 0x14D50FA0, 0x00000000, 0x01010000, 0x00000101, + 0x01010101, 0x02020201, 0x02010000, 0x03030202, 0x00000303, + 0x03020101, 0x06060504, 0x01010000, 0x06050403, 0x01000606, + 0x05040202, 0x07070706}, + {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320, + 0x0D05091D, 0x14D50FA0, 0x00000000, 0x01010100, 0x00000101, + 0x01000000, 0x01010101, 0x01010000, 0x02020202, 0x00000404, + 0x03020101, 0x04040303, 0x02010000, 0x03030303, 0x00000505, + 0x03030201, 0x05050303}, +}; + +static const u32 rtw8922a_digital_pwr_comp_2g_s1_val[][DIGITAL_PWR_COMP_RE= G_NUM] =3D { + {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320, + 0x0D05091D, 0x14D50FA0, 0x01010000, 0x01010101, 0x00000101, + 0x01010100, 0x01010101, 0x01010000, 0x02020202, 0x01000202, + 0x02020101, 0x03030202, 0x02010000, 0x05040403, 0x01000606, + 0x05040302, 0x07070605}, + {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320, + 0x0D05091D, 0x14D50FA0, 0x00000000, 0x01010100, 0x00000101, + 0x01010000, 0x02020201, 0x02010100, 0x03030202, 0x01000404, + 0x04030201, 0x05050404, 0x01010100, 0x04030303, 0x01000505, + 0x03030101, 0x05050404}, +}; + static const u32 rtw8922a_digital_pwr_comp_val[][DIGITAL_PWR_COMP_REG_NUM]= =3D { {0x012C0096, 0x044C02BC, 0x00322710, 0x015E0096, 0x03C8028A, 0x0BB80708, 0x17701194, 0x02020100, 0x03030303, 0x01000303, @@ -1784,7 +1810,7 @@ static const u32 rtw8922a_digital_pwr_comp_val[][DIGI= TAL_PWR_COMP_REG_NUM] =3D { }; =20 static void rtw8922a_set_digital_pwr_comp(struct rtw89_dev *rtwdev, - bool enable, u8 nss, + u8 band, u8 nss, enum rtw89_rf_path path) { static const u32 ltpc_t0[2] =3D {R_BE_LTPC_T0_PATH0, R_BE_LTPC_T0_PATH1}; @@ -1792,14 +1818,25 @@ static void rtw8922a_set_digital_pwr_comp(struct rt= w89_dev *rtwdev, u32 addr, val; u32 i; =20 - if (nss =3D=3D 1) - digital_pwr_comp =3D rtw8922a_digital_pwr_comp_val[0]; - else - digital_pwr_comp =3D rtw8922a_digital_pwr_comp_val[1]; + if (nss =3D=3D 1) { + if (band =3D=3D RTW89_BAND_2G) + digital_pwr_comp =3D path =3D=3D RF_PATH_A ? + rtw8922a_digital_pwr_comp_2g_s0_val[0] : + rtw8922a_digital_pwr_comp_2g_s1_val[0]; + else + digital_pwr_comp =3D rtw8922a_digital_pwr_comp_val[0]; + } else { + if (band =3D=3D RTW89_BAND_2G) + digital_pwr_comp =3D path =3D=3D RF_PATH_A ? + rtw8922a_digital_pwr_comp_2g_s0_val[1] : + rtw8922a_digital_pwr_comp_2g_s1_val[1]; + else + digital_pwr_comp =3D rtw8922a_digital_pwr_comp_val[1]; + } =20 addr =3D ltpc_t0[path]; for (i =3D 0; i < DIGITAL_PWR_COMP_REG_NUM; i++, addr +=3D 4) { - val =3D enable ? digital_pwr_comp[i] : 0; + val =3D digital_pwr_comp[i]; rtw89_phy_write32(rtwdev, addr, val); } } @@ -1808,7 +1845,7 @@ static void rtw8922a_digital_pwr_comp(struct rtw89_de= v *rtwdev, enum rtw89_phy_idx phy_idx) { const struct rtw89_chan *chan =3D rtw89_chan_get(rtwdev, RTW89_CHANCTX_0); - bool enable =3D chan->band_type !=3D RTW89_BAND_2G; + u8 band =3D chan->band_type; u8 path; =20 if (rtwdev->mlo_dbcc_mode =3D=3D MLO_1_PLUS_1_1RF) { @@ -1816,10 +1853,10 @@ static void rtw8922a_digital_pwr_comp(struct rtw89_= dev *rtwdev, path =3D RF_PATH_A; else path =3D RF_PATH_B; - rtw8922a_set_digital_pwr_comp(rtwdev, enable, 1, path); + rtw8922a_set_digital_pwr_comp(rtwdev, band, 1, path); } else { - rtw8922a_set_digital_pwr_comp(rtwdev, enable, 2, RF_PATH_A); - rtw8922a_set_digital_pwr_comp(rtwdev, enable, 2, RF_PATH_B); + rtw8922a_set_digital_pwr_comp(rtwdev, band, 2, RF_PATH_A); + rtw8922a_set_digital_pwr_comp(rtwdev, band, 2, RF_PATH_B); } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E19DA3A699C; Sat, 28 Feb 2026 17:37:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300278; cv=none; b=MISx5dhRt8W2NkUc13QikSYrLjZJYiynhDk+7Pyo0XEaqiyWLyUvTMJgTQQh2YI5tdLBwMWZmp4pwYncPPgqpaM3/IN72kHvhvlO5CZeRpXCLIF9QzN/drdzpcSARh8byWJXtInhtygilUivkZTx3DQQioj4aELcIoHmTNpUuXI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300278; c=relaxed/simple; bh=+YxQHjKhLtTGO6HRhizQj9yMP6s21GyiiQzAmsMI/iI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ARaxmXfd79rbWAKlQ0gGqcu1rxXZ5uooEwGDiKA4GZ+Hfb2cIRxumrOmeULr75uk+ET2A9QkfT7yu+N1iUtNv/X2AO6rqF7CjZcay4G9kYUS6VCMQGlzd4b/3sYPnNAWydIGrepNaS2NpO574rKkaT3HpSZu9i+5mxrLkQBwsW4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QpvFIPp5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QpvFIPp5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A966C2BC87; Sat, 28 Feb 2026 17:37:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300277; bh=+YxQHjKhLtTGO6HRhizQj9yMP6s21GyiiQzAmsMI/iI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QpvFIPp5DNitKYUHrZBmCrYvQeGc49r4+kAy+rMSoJOFdm6c9yoBwhXkgbNwbu6+/ zI2aoukXu8CEym029RxuvVA/lOaTABsw2KOHVXZIoW5r3OcSapx/3voXzZEtDJqaCr cQc3JOmOsdP13dY4UjImPHc/oF9BvS+wrHuHnEFyjsIyWrEP54unXXTP5CxJd4tGB1 Hw2oA9ACI1NXSZdMtF4wq3tCg3xMJvOT6633J2x21lP1duWe7uac4o46c+0JplHKCn 4O3EbpjgRlAU4mwUxJDUhgKY/Lxx4UWPmirx6lwiKbTKI9E5EarvJRcED1dcqkkJo3 F674Xmhe+RzhA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gerd Rausch , Allison Henderson , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 305/844] net/rds: No shortcut out of RDS_CONN_ERROR Date: Sat, 28 Feb 2026 12:23:38 -0500 Message-ID: <20260228173244.1509663-306-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gerd Rausch [ Upstream commit ad22d24be635c6beab6a1fdd3f8b1f3c478d15da ] RDS connections carry a state "rds_conn_path::cp_state" and transitions from one state to another and are conditional upon an expected state: "rds_conn_path_transition." There is one exception to this conditionality, which is "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop" regardless of what state the condition is currently in. But as soon as a connection enters state "RDS_CONN_ERROR", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING" via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change"). A subsequent "rds_tcp_reset_callbacks" can then transition the state to "RDS_CONN_RESETTING" with a shutdown-worker queued. That'll trip up "rds_conn_init_shutdown", which was never adjusted to handle "RDS_CONN_RESETTING" and subsequently drops the connection with the dreaded "DR_INV_CONN_STATE", which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever. So we do two things here: a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code. b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again." Signed-off-by: Gerd Rausch Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260122055213.83608-2-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/rds/connection.c | 2 ++ net/rds/tcp_listen.c | 5 ----- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/net/rds/connection.c b/net/rds/connection.c index 68bc88cce84ec..ad8027e6f54ef 100644 --- a/net/rds/connection.c +++ b/net/rds/connection.c @@ -382,6 +382,8 @@ void rds_conn_shutdown(struct rds_conn_path *cp) if (!rds_conn_path_transition(cp, RDS_CONN_UP, RDS_CONN_DISCONNECTING) && !rds_conn_path_transition(cp, RDS_CONN_ERROR, + RDS_CONN_DISCONNECTING) && + !rds_conn_path_transition(cp, RDS_CONN_RESETTING, RDS_CONN_DISCONNECTING)) { rds_conn_path_error(cp, "shutdown called in state %d\n", diff --git a/net/rds/tcp_listen.c b/net/rds/tcp_listen.c index 820d3e20de195..27b6107ddc28d 100644 --- a/net/rds/tcp_listen.c +++ b/net/rds/tcp_listen.c @@ -59,9 +59,6 @@ void rds_tcp_keepalive(struct socket *sock) * socket and force a reconneect from smaller -> larger ip addr. The reason * we special case cp_index 0 is to allow the rds probe ping itself to its= elf * get through efficiently. - * Since reconnects are only initiated from the node with the numerically - * smaller ip address, we recycle conns in RDS_CONN_ERROR on the passive s= ide - * by moving them to CONNECTING in this function. */ static struct rds_tcp_connection *rds_tcp_accept_one_path(struct rds_connection *= conn) @@ -86,8 +83,6 @@ struct rds_tcp_connection *rds_tcp_accept_one_path(struct= rds_connection *conn) struct rds_conn_path *cp =3D &conn->c_path[i]; =20 if (rds_conn_path_transition(cp, RDS_CONN_DOWN, - RDS_CONN_CONNECTING) || - rds_conn_path_transition(cp, RDS_CONN_ERROR, RDS_CONN_CONNECTING)) { return cp->cp_transport_data; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E23683A7152; Sat, 28 Feb 2026 17:37:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300279; cv=none; b=PC2OFK0fIIAlIfTBxeomPVaU9+URiBCwbEvi495yJIF85yGw+SUYDI6Z30HIB/gzJAKMaGPfD9O7lJDO7KBupzRhq+EMxIrawm38ZT0yskgRkhbSODVnAlsmlFtdd/dbPGcM2iMItlAvYffRdS8mThVqZU9MkcuksC/xu11jfTM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300279; c=relaxed/simple; bh=HN4EfW9F7yvRr7y8ctW1zUJ0R/d77Dw9QTlI2qKEDIE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IvJSWkbJRRG4xiPewtWs0LN4pTiVHZ616rnmQFjpjeg9Qdh1slzc8CzevBDATOiwBL7PqXl3I5qt/1phsYE5Dwl2kGgpYeYYKwe+OX3+XcWpmSjMXEDpFhu1BZhBSyOsW3qHmlAQUlJ++vqVX5OvGo738TiGNX+b+/rnp35G0QY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HSdR9kr3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HSdR9kr3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 134B3C19425; Sat, 28 Feb 2026 17:37:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300278; bh=HN4EfW9F7yvRr7y8ctW1zUJ0R/d77Dw9QTlI2qKEDIE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HSdR9kr3p72r6jldzzmapB3qdyzFdFvdiPSlh1pnu+w+KRCYBbQhNxWboXaWTU9f+ fMlynGOgbd5P1LSKUQx4SUEzpAVR0+yqMxJQl/EE5cLW/Q9Vbbec1qiPlIVfg/sARf Rc+hHRL2WTXx+3c/Piw0XoW3EHzHitc8fwrJ/wgUoRCwkTzFZ8lQ8G3OFaCG5532v8 fx1tkEg76ET9h4T/DLxwLOU6BjFSYLHen2ETxIBNmpmlV7l+0ZdXpCISRrtvCkwZR0 X3DVVBD5N28RPyVLkhQlC1qINs6E2532d7uA/pN7oaZiSaV76t7IaztaVaRVcmfhBS tz4/MrYnJ3XcA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ojaswin Mujoo , Zhang Yi , Jan Kara , Theodore Ts'o , Sasha Levin Subject: [PATCH 6.19 306/844] ext4: propagate flags to convert_initialized_extent() Date: Sat, 28 Feb 2026 12:23:39 -0500 Message-ID: <20260228173244.1509663-307-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ojaswin Mujoo [ Upstream commit 3fffa44b6ebf65be92a562a5063303979385a1c9 ] Currently, ext4_zero_range passes EXT4_EX_NOCACHE flag to avoid caching extents however this is not respected by convert_initialized_extent(). Hence, modify it to accept flags from the caller and to pass the flags on to other extent manipulation functions it calls. This makes sure the NOCACHE flag is respected throughout the code path. Also, we no longer explicitly pass CONVERT_UNWRITTEN as the caller takes care of this. Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Signed-off-by: Ojaswin Mujoo Link: https://patch.msgid.link/07008fbb14db727fddcaf4c30e2346c49f6c8fe0.176= 9149131.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ext4/extents.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 418c4351ef40c..986e85902d06a 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3857,6 +3857,7 @@ static struct ext4_ext_path * convert_initialized_extent(handle_t *handle, struct inode *inode, struct ext4_map_blocks *map, struct ext4_ext_path *path, + int flags, unsigned int *allocated) { struct ext4_extent *ex; @@ -3882,11 +3883,11 @@ convert_initialized_extent(handle_t *handle, struct= inode *inode, =20 if (ee_block !=3D map->m_lblk || ee_len > map->m_len) { path =3D ext4_split_convert_extents(handle, inode, map, path, - EXT4_GET_BLOCKS_CONVERT_UNWRITTEN, NULL); + flags, NULL); if (IS_ERR(path)) return path; =20 - path =3D ext4_find_extent(inode, map->m_lblk, path, 0); + path =3D ext4_find_extent(inode, map->m_lblk, path, flags); if (IS_ERR(path)) return path; depth =3D ext_depth(inode); @@ -4298,7 +4299,7 @@ int ext4_ext_map_blocks(handle_t *handle, struct inod= e *inode, if ((!ext4_ext_is_unwritten(ex)) && (flags & EXT4_GET_BLOCKS_CONVERT_UNWRITTEN)) { path =3D convert_initialized_extent(handle, - inode, map, path, &allocated); + inode, map, path, flags, &allocated); if (IS_ERR(path)) err =3D PTR_ERR(path); goto out; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B885C3A716D; Sat, 28 Feb 2026 17:37:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300279; cv=none; b=eE4EKbwF99M3LtKrWKRXKmv60Nob62hHDCQo4TVV9gdww6ZHyN0EM1PcLSnlpRhkeniIr0wgC+Ws6qLPkL9TJIDk/i8wTCUPRQoszCZepXE5ANHBXXgmd9Sr6qzrounrvcR6oSIk/hEnIIJiP/0UKwIZcN6bHpgyzq3ldNFjS6w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300279; c=relaxed/simple; bh=W2Zu8bffyf0YcmUgY9hYpsOx4Ln8hzrk78JdvpIjSgY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oz8Km5R5vsIEumaQbndkVy1rq8HaLORVrFx5ZtuYAVOSPjzNPdhV8FJDScknxJEl8BHRsL6x4/6lzY6r4bGYNwF4z1Zqe6Qu1jcqa1RZYTwEA0WNZiqEPXp8vJGCBfwTtL0HsrGYh9YkdfPExV44oeWllhpfL8oXbmOijdAejXc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RQpM+pYV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RQpM+pYV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 135A0C116D0; Sat, 28 Feb 2026 17:37:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300279; bh=W2Zu8bffyf0YcmUgY9hYpsOx4Ln8hzrk78JdvpIjSgY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RQpM+pYVbRT6FqMJpYlfMI3pS626lKYtNmQQW/DikHT+pNZy8NhBin2DznHEyye+p onVUl8YxqLJ/QoilQLFP4WrEARdj+ZDUOMoMRmpB++JjPqFLtIMDytaTXelESg8jwI /MeHzGVPlwcO6xSDjQp+FwTqz6CwivBenA9nsKg1L66OK2rs8a8Wncj+Zue4jDWGKN Nm94qBbWqb9ZDjNx1JA2Thh3V4fJ+9BeLT3nHaXQeQQUMG5ndentQhPBapw0uDADVT R5XYA8NIqMehtqyUA+b7izkJR/DfEK7ISrLPhUVR1+oKbg1diQnvkdXl6xGNR7xyIG +MpG6rYcTjp/Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 307/844] gro: change the BUG_ON() in gro_pull_from_frag0() Date: Sat, 28 Feb 2026 12:23:40 -0500 Message-ID: <20260228173244.1509663-308-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit cbe41362be2c27e0237a94a404ae413cec9c2ad9 ] Replace the BUG_ON() which never fired with a DEBUG_NET_WARN_ON_ONCE() $ scripts/bloat-o-meter -t vmlinux.1 vmlinux.2 add/remove: 2/2 grow/shrink: 1/1 up/down: 370/-254 (116) Function old new delta gro_try_pull_from_frag0 - 196 +196 napi_gro_frags 771 929 +158 __pfx_gro_try_pull_from_frag0 - 16 +16 __pfx_gro_pull_from_frag0 16 - -16 dev_gro_receive 1514 1464 -50 gro_pull_from_frag0 188 - -188 Total: Before=3D22565899, After=3D22566015, chg +0.00% Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260122045720.1221017-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/core/gro.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/gro.c b/net/core/gro.c index 482fa7d7f5981..ef61695fbdbb6 100644 --- a/net/core/gro.c +++ b/net/core/gro.c @@ -417,7 +417,7 @@ static void gro_pull_from_frag0(struct sk_buff *skb, in= t grow) { struct skb_shared_info *pinfo =3D skb_shinfo(skb); =20 - BUG_ON(skb->end - skb->tail < grow); + DEBUG_NET_WARN_ON_ONCE(skb->end - skb->tail < grow); =20 memcpy(skb_tail_pointer(skb), NAPI_GRO_CB(skb)->frag0, grow); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCB3C48094E; Sat, 28 Feb 2026 17:38:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300280; cv=none; b=V+6QIXJ+N/lvINxN84qiMhx8aAdq2j9mVvtuy9YptwpSe7xOHJRzBl83NDv8CXO+OjeOSR3VK5S1SMCRzmpYYztf04RoPYyiaZnvmCgTf+e6B7mdumJFR9mB2kaSrwGUeKicaigDynOo7+IeJtaRmch0QH/BnFtq4HTBFArv7XI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300280; c=relaxed/simple; bh=fT5XQ90LQsVw7mKPiPlUtlk1NvZ5frplEmUQTEt3UJc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kZU4pokG9MsC6RpDSyZJ/sED/QoaLF1lMe347VCYGKYhxGGTakkp/yEdJXkp8PU6T+YcCZtbiPUzouJj0eUUm+Y/4UljhjBgZIdmr7SsYr3WjBrasiYwFK/uvn6ohB4RAJfoTzjrkNDEnCe4EwNAJbUwljTvgrBh0wfEHq29IgY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C7YYrYTy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C7YYrYTy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE5A9C116D0; Sat, 28 Feb 2026 17:37:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300280; bh=fT5XQ90LQsVw7mKPiPlUtlk1NvZ5frplEmUQTEt3UJc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C7YYrYTydMBoVB5vh6rRImfEJdB6P5BC1QdL4vBsu41ZC+dEz66nql07xnDUEW5aD bcePb3YQ9jN7PR23rjtcaPD4LDjvVdn/n84Uh24IA/ecZNeBY+BHvr8vDW8f3dKMJP vqkofC6LeOvVO9+c3La2LdCCUKoczevrjTSIBGIVuBllXOpUNrBOdf35WxN9VnV4Hl 605IQCrmedMMrCMt/P8ycgJMzZKPs0PH0ad+sv8gKbI1y9flz+SqMN0Egc2EaRcmpV T+ssYALQIf36RNWzUa4Or9iGVCmFsCnrg1dhsJrMWi3WOV4bnJoERDngn0oSJu32+p uTd3YkpkiYuqg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , David Ahern , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 308/844] ipv4: igmp: annotate data-races around idev->mr_maxdelay Date: Sat, 28 Feb 2026 12:23:41 -0500 Message-ID: <20260228173244.1509663-309-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit e4faaf65a75f650ac4366ddff5dabb826029ca5a ] idev->mr_maxdelay is read and written locklessly, add READ_ONCE()/WRITE_ONCE() annotations. While we are at it, make this field an u32. Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20260122172247.2429403-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/inetdevice.h | 2 +- net/ipv4/igmp.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h index 5730ba6b1cfaf..dccbeb25f7014 100644 --- a/include/linux/inetdevice.h +++ b/include/linux/inetdevice.h @@ -38,11 +38,11 @@ struct in_device { struct ip_mc_list *mc_tomb; unsigned long mr_v1_seen; unsigned long mr_v2_seen; - unsigned long mr_maxdelay; unsigned long mr_qi; /* Query Interval */ unsigned long mr_qri; /* Query Response Interval */ unsigned char mr_qrv; /* Query Robustness Variable */ unsigned char mr_gq_running; + u32 mr_maxdelay; u32 mr_ifc_count; struct timer_list mr_gq_timer; /* general query timer */ struct timer_list mr_ifc_timer; /* interface change timer */ diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c index 7182f1419c2a4..0adc993c211d7 100644 --- a/net/ipv4/igmp.c +++ b/net/ipv4/igmp.c @@ -227,7 +227,7 @@ static void igmp_start_timer(struct ip_mc_list *im, int= max_delay) =20 static void igmp_gq_start_timer(struct in_device *in_dev) { - int tv =3D get_random_u32_below(in_dev->mr_maxdelay); + int tv =3D get_random_u32_below(READ_ONCE(in_dev->mr_maxdelay)); unsigned long exp =3D jiffies + tv + 2; =20 if (in_dev->mr_gq_running && @@ -1009,7 +1009,7 @@ static bool igmp_heard_query(struct in_device *in_dev= , struct sk_buff *skb, max_delay =3D IGMPV3_MRC(ih3->code)*(HZ/IGMP_TIMER_SCALE); if (!max_delay) max_delay =3D 1; /* can't mod w/ 0 */ - in_dev->mr_maxdelay =3D max_delay; + WRITE_ONCE(in_dev->mr_maxdelay, max_delay); =20 /* RFC3376, 4.1.6. QRV and 4.1.7. QQIC, when the most recently * received value was zero, use the default or statically --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FE183A863A; Sat, 28 Feb 2026 17:38:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300281; cv=none; b=ND45PDY4pFtIoavZFwrYxKFVCHDckYmTvmTepdAVS7Szxv3Ug4I1/I/4DdTxtxZkoJOLa8VSOL3lVvamrud4j6azck8e9Bw4s63pp1I9mlIY8eM/FWBmnXB5n1qwXBL4VwGh+npxUg7FT8IRZhUOtvGQwdDZ5fqZ3zcsZPm+Eg8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300281; c=relaxed/simple; bh=BGncQb5x7RGPy68kLJLDGKM8UoTTb59cykGAb1XIhao=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IPOr6Nv4V9xVqCnuL4z81DPdrGjtAft6T3hUQvaHFucDn8CBLYYZ/N94ewKFaiYQlfwEY6VlDY2GAus1Ex8TTsMVJt7MRA3UsbAN5P13zzFw2h3O+rUHX+ocN31ipRIVHOoITO127h9Po96ZkFtdqAPVbi/wTMM23LPCO9U4EVs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=akVmLizy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="akVmLizy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF93EC116D0; Sat, 28 Feb 2026 17:38:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300281; bh=BGncQb5x7RGPy68kLJLDGKM8UoTTb59cykGAb1XIhao=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=akVmLizyMPM1OT6FsIHZ2D55GpQQ2/qMzxIQbSxQNBCwhtWcb1qFvodrwrGK3BFCa AueRygnIR3SVVLOiMgKTaKUJpVpXIp2loDJnggCD+WdAV28Ffbf5cYMXLYebqGrrdE +z4BBy7JR6QEgG198i2Xl1/KEGEavpU8upp3Bvmsoo9ZykYIgamtt+xdWZsNKX1Ukc 9TJvATsynPDC6Oz00BRfpvBXn4FKXGj1k1hriCBn3L2vrXQhKdCnGi7xQ5tV/iyU6L aslimDebJTwlGM+XW7YeoP8PsFHiKiTJBmUBoodOsnsGUkj5nidIZaZgnp7uMmOygb LFNfzp82lwLpg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jijie Shao , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 309/844] net: hns3: extend HCLGE_FD_AD_QID to 11 bits Date: Sat, 28 Feb 2026 12:23:42 -0500 Message-ID: <20260228173244.1509663-310-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jijie Shao [ Upstream commit 878406d4d6ef85c37fab52074771cc916e532c16 ] Currently, HCLGE_FD_AD_QID has only 10 bits and supports a maximum of 1023 queues. However, there are actually scenarios where the queue_id exceeds 1023. This patch adds an additional bit to HCLGE_FD_AD_QID to ensure that queue_id greater than 1023 are supported. Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260123094756.3718516-2-shaojijie@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 5 +++-- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 +++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h b/drive= rs/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h index 416e02e7b995f..bc333d8710ac1 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h @@ -727,8 +727,8 @@ struct hclge_fd_tcam_config_3_cmd { =20 #define HCLGE_FD_AD_DROP_B 0 #define HCLGE_FD_AD_DIRECT_QID_B 1 -#define HCLGE_FD_AD_QID_S 2 -#define HCLGE_FD_AD_QID_M GENMASK(11, 2) +#define HCLGE_FD_AD_QID_L_S 2 +#define HCLGE_FD_AD_QID_L_M GENMASK(11, 2) #define HCLGE_FD_AD_USE_COUNTER_B 12 #define HCLGE_FD_AD_COUNTER_NUM_S 13 #define HCLGE_FD_AD_COUNTER_NUM_M GENMASK(19, 13) @@ -741,6 +741,7 @@ struct hclge_fd_tcam_config_3_cmd { #define HCLGE_FD_AD_TC_OVRD_B 16 #define HCLGE_FD_AD_TC_SIZE_S 17 #define HCLGE_FD_AD_TC_SIZE_M GENMASK(20, 17) +#define HCLGE_FD_AD_QID_H_B 21 =20 struct hclge_fd_ad_config_cmd { u8 stage; diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/driv= ers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c index b8e2aa19f9e61..a90f1a91f9973 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c @@ -5679,11 +5679,13 @@ static int hclge_fd_ad_config(struct hclge_dev *hde= v, u8 stage, int loc, hnae3_set_field(ad_data, HCLGE_FD_AD_TC_SIZE_M, HCLGE_FD_AD_TC_SIZE_S, (u32)action->tc_size); } + hnae3_set_bit(ad_data, HCLGE_FD_AD_QID_H_B, + action->queue_id >=3D HCLGE_TQP_MAX_SIZE_DEV_V2 ? 1 : 0); ad_data <<=3D 32; hnae3_set_bit(ad_data, HCLGE_FD_AD_DROP_B, action->drop_packet); hnae3_set_bit(ad_data, HCLGE_FD_AD_DIRECT_QID_B, action->forward_to_direct_queue); - hnae3_set_field(ad_data, HCLGE_FD_AD_QID_M, HCLGE_FD_AD_QID_S, + hnae3_set_field(ad_data, HCLGE_FD_AD_QID_L_M, HCLGE_FD_AD_QID_L_S, action->queue_id); hnae3_set_bit(ad_data, HCLGE_FD_AD_USE_COUNTER_B, action->use_counter); hnae3_set_field(ad_data, HCLGE_FD_AD_COUNTER_NUM_M, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9E2B3A865A; Sat, 28 Feb 2026 17:38:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300282; cv=none; b=FGOCOC8x3JPy9tHuPR5bKCqIzyTNmVbcNbFeIJlyesLBMnbyThOpYRPtgnzQTP8YjVl7jvapGN9OufA5W0SmC+XeB1ThmhqCwQ0SQpmatnTAXWhMrIa/G4KfG9h1YOXjh6wXaJ09zlHvZ2LFsHbnnKRwjv9Jkt9R8gH/L7o37Lg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300282; c=relaxed/simple; bh=cCmpW99VXVHVkFwH3lnV6jCzgBk2MGwqqDOjBzoTaGw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mL/NbnMF7vLbmLWbqjFG2Odnkww4yA+fCbd9CO5Qj5r5+gr8ghA1RjWR9/NdT0Rrdd/RHc53I1v9F6wK1Uqyv68L26E/hDG1bCqO5sr5oAl2bMAXI+tvJqFHbVPaOkaGeUou8rs0L/Fa4BcUFuwb8eq9LiZhOtj7fHtXPcraxt8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fxGbF83T; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fxGbF83T" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5CC3C19425; Sat, 28 Feb 2026 17:38:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300282; bh=cCmpW99VXVHVkFwH3lnV6jCzgBk2MGwqqDOjBzoTaGw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fxGbF83TlGKWIazsyyWnytvMv9WYcmz/4NVAI1eXB0b5lfkUeKG2aY1he2RiLbtS3 /VnyUJeRrleoOzJrIg6D3OdR9r1/1ev7RmbpFphuxL2vqnFGb0+dX2bxGzFk8gQZSi 7pSdnhmBGVvZQQkU+cR7hLBC3W7qz7jY/FKz+Up6kQMYow9p2aheZtcWkHcz5AETwP FOUNpWN9OyRG7t64CAdirwVvynJ2oBIuqW48WF9OVUsOtt1BCptdFiBHOmwTam0zlY DzXODppNAwNt5EM+mHRDZKpGHgOVk6Ur1fe0mHsbi3l/uNb7GA0qg8iPP0uN+TJj/T mcTV1ciAXlVwg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Pagadala Yesu Anjaneyulu , Johannes Berg , Miri Korenblit , Sasha Levin Subject: [PATCH 6.19 310/844] wifi: cfg80211: treat deprecated INDOOR_SP_AP_OLD control value as LPI mode Date: Sat, 28 Feb 2026 12:23:43 -0500 Message-ID: <20260228173244.1509663-311-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pagadala Yesu Anjaneyulu [ Upstream commit fd5bfcf430ea2fdbb3e78fd0b82ceb0ab02b72ee ] Although value 4 (INDOOR_SP_AP_OLD) is deprecated in IEEE standards, existing APs may still use this control value. Since this value is based on the old specification, we cannot trust such APs implement proper power controls. Therefore, move IEEE80211_6GHZ_CTRL_REG_INDOOR_SP_AP_OLD case from SP_AP to LPI_AP power type handling to prevent potential power limit violations. Signed-off-by: Pagadala Yesu Anjaneyulu Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260111163601.6b5a36d3601e.I1704ee575fd25ed= b0d56f48a0a3169b44ef72ad0@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/net/cfg80211.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 2900202588a54..39a04776705eb 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -10147,9 +10147,9 @@ cfg80211_6ghz_power_type(u8 control, u32 client_fla= gs) case IEEE80211_6GHZ_CTRL_REG_LPI_AP: case IEEE80211_6GHZ_CTRL_REG_INDOOR_LPI_AP: case IEEE80211_6GHZ_CTRL_REG_AP_ROLE_NOT_RELEVANT: + case IEEE80211_6GHZ_CTRL_REG_INDOOR_SP_AP_OLD: return IEEE80211_REG_LPI_AP; case IEEE80211_6GHZ_CTRL_REG_SP_AP: - case IEEE80211_6GHZ_CTRL_REG_INDOOR_SP_AP_OLD: return IEEE80211_REG_SP_AP; case IEEE80211_6GHZ_CTRL_REG_VLP_AP: return IEEE80211_REG_VLP_AP; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8CB063A8E10; Sat, 28 Feb 2026 17:38:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300283; cv=none; b=mn8E9vbHI5pw7kfl23VuaHqodKAoA2RtRRDbp0tm5tAyxt/Ve6mz+BzI1lPPB0YYwWXfgyV3FK8jUUEU3+PVK7+gDYA7t4yN+rgA/+T/N95fJJlYwg5k3AOO95UplrfR+RePOa+KkxJT/4Qx4EIrUK7PlswvtJpLXGNm6a2cXb4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300283; c=relaxed/simple; bh=LA3/TqVyfM6rXtgOiZo+UUq4qe5bn3h1BzNRYOGH/Ro=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LsDABlZHZ1WvBjwbl+a+QbF620hi5+szIgzXaQVeTwKI5LUs5Y3Z7iRscOhJB321UYtnl/DjE45gl/6v1T3k80bedRCs0Lgy+HB7AC68gtjgBl+LmZp9d1GYxYDk1mS2fKFv+tuH0w1AEkmxM2sdCihhS+MTgMPRdldCwuG0rVA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o/B/WxTt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o/B/WxTt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7991C19423; Sat, 28 Feb 2026 17:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300283; bh=LA3/TqVyfM6rXtgOiZo+UUq4qe5bn3h1BzNRYOGH/Ro=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o/B/WxTtxq8iyVmldY4MpFB4xvhjSOFBQBEL9AC/FlYv15P4KiNC+Tt38N24EJQDp BDsOURMpBcm4nzSyP31dD3dnID3HwiQ4QndcKZgy7C+C86IoF0PXi9r//Vjjg0a1kE OhfbRO6PIvESbGCcDM8TxVXyC3odG37lmEh9raOa/Re8RWLNnJMYMPmRk/frnCpWBa i8Iq9dk0XSMw4DEPYypgpOKcv749DHnnqJhVCynubDRTaybCHb3HGk9krQWOzT9iSe c42I/3qAHAD9iqu021gfxDk9hqY+3nYUEDNLMWt5tsrbLMEdqne44ze9iAxiHi6tK/ KzYKgT5t6W+3g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ziyi Guo , Stanislaw Gruszka , Johannes Berg , Sasha Levin Subject: [PATCH 6.19 311/844] wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power() Date: Sat, 28 Feb 2026 12:23:44 -0500 Message-ID: <20260228173244.1509663-312-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ziyi Guo [ Upstream commit e31fa691d0b1c07b6094a6cf0cce894192c462b3 ] il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex. However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. All other callers of il_set_tx_power() properly acquire the mutex: - il_bg_scan_completed() acquires mutex at common.c:1683 - il_mac_config() acquires mutex at common.c:5006 - il3945_commit_rxon() and il4965_commit_rxon() are called via work queues that hold the mutex (like il4965_bg_alive_start) Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260125194039.1196488-1-n7l8m4@u.northweste= rn.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/intel/iwlegacy/4965-mac.c b/drivers/net/w= ireless/intel/iwlegacy/4965-mac.c index 3588dec75ebdd..57fa866efd9f8 100644 --- a/drivers/net/wireless/intel/iwlegacy/4965-mac.c +++ b/drivers/net/wireless/intel/iwlegacy/4965-mac.c @@ -4606,7 +4606,9 @@ il4965_store_tx_power(struct device *d, struct device= _attribute *attr, if (ret) IL_INFO("%s is not in decimal form.\n", buf); else { + mutex_lock(&il->mutex); ret =3D il_set_tx_power(il, val, false); + mutex_unlock(&il->mutex); if (ret) IL_ERR("failed setting tx power (0x%08x).\n", ret); else --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 645FC3A8E2E; Sat, 28 Feb 2026 17:38:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300284; cv=none; b=gUnJHf83KGei3ohXe2DWYkjy/hsSLUDGzLeBWTuj01LvvtzNmfg0rjVPrG49Rqg48sUeH6CeGjNQ8I4j0wxhmOm1TO4aiJN7k42UgBCokBgClKp/CUiM/m++AjDR0Dx0jgwnubdr8Sr1XusZGN570Ht0QhY1IxsATf0YQ25FKUc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300284; c=relaxed/simple; bh=xRWtLbm0zjBdLRyDSj+VAA8imS9R2w3IqEL1uvlgr3c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VLDDpVQWuHM3j73XP/u7+BoTTT6XVLNFjscDfhGOjP6mP+T3vevOV6FoApu4RbAqW8zwhI/dILFLekyun50Z+w/S3SMqSoemgJ3sN10WassfQjJ8v4ufDbc4pYo3sfVokj4ngfpwIxhsJ4+53ajIf4VxKr7dvWpf1489BYY3IdU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Vjd62ETT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Vjd62ETT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9864FC116D0; Sat, 28 Feb 2026 17:38:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300284; bh=xRWtLbm0zjBdLRyDSj+VAA8imS9R2w3IqEL1uvlgr3c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Vjd62ETTXD6YDw+ZhsapA499u2jnmRNjvDDe+eTYOwrpI8JmLug2wUYFdzLouhg5C BJ/ftYNF4/fEx96yL3j3n0jCWsE2dDU3XUvYRJBNdNjKU2kjH9ZRT3MyExA92fvXOT Y4GTLD0UDc3pO6jqB4B8G3Bem3MwPJ0aRhsbqHZh88doY1aAhOjUlGpFioO6doggZv LnScZ0y2MGzoCfpWXkrHBVpLANou4WY9tdPnYTT5h2THkNwlffdnMtZsj8h7AtAnFR FnENsUKaUq+YCfYt0ahVk4C/7gArkA8mwWhPajta0xRL+stYIokoVufkG2FYEOTnnx T2mG06W/tdD3g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ziyi Guo , Stanislaw Gruszka , Johannes Berg , Sasha Levin Subject: [PATCH 6.19 312/844] wifi: iwlegacy: add missing mutex protection in il3945_store_measurement() Date: Sat, 28 Feb 2026 12:23:45 -0500 Message-ID: <20260228173244.1509663-313-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ziyi Guo [ Upstream commit 4dd1dda65265ecbc9f43ffc08e333684cf715152 ] il3945_store_measurement() calls il3945_get_measurement() which internally calls il_send_cmd_sync() without holding il->mutex. However, il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. Other sysfs store functions in the same file properly acquire the mutex: - il3945_store_flags() acquires mutex at 3945-mac.c:3110 - il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144 Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260125193005.1090429-1-n7l8m4@u.northweste= rn.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c b/drivers/net/w= ireless/intel/iwlegacy/3945-mac.c index 104748fcdc33e..54991f31c52c5 100644 --- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c +++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c @@ -3224,7 +3224,9 @@ il3945_store_measurement(struct device *d, struct dev= ice_attribute *attr, =20 D_INFO("Invoking measurement of type %d on " "channel %d (for '%s')\n", type, params.channel, buf); + mutex_lock(&il->mutex); il3945_get_measurement(il, ¶ms, type); + mutex_unlock(&il->mutex); =20 return count; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 298E5480955; Sat, 28 Feb 2026 17:38:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300285; cv=none; b=ZPHLLOV/w29rx9u9Cqq5VprV81/n2Z2XE5xyLhs0JsCqdX6GNKrs4dl4EjqxL64w6VKCnpNs/I1Q9iR7P4Oc/97IVBXcksOEwN5SPd2EcSHBzVAHIWW3W0R/XkNPZ8uWEK1xwgj9dEGcuCcBxfYprIt79s/FsHYkDrCYj2uDQDU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300285; c=relaxed/simple; bh=WLc9+IuJ4Y6+DvZ7a5Qw5UhvfVOKCcCk+tw0ilC13LI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Zg2FssfQ0dEw2nnnrludeZe0+xEA5BLMpFpmsHakPlDkDBsYElIzA/SaLxOItaIQHxi7lx6GOGUaFkcNbvAaOqLpWgci+G1xnyjzeaJXpC2d5vmFYtuQC7zpGcNcJZ93vxWX5N9cNzJIG3ooj9agEeC8XJv2ZIJq6dA/ySzTbKc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lD5GRwkB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lD5GRwkB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8906CC116D0; Sat, 28 Feb 2026 17:38:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300285; bh=WLc9+IuJ4Y6+DvZ7a5Qw5UhvfVOKCcCk+tw0ilC13LI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lD5GRwkBi7TvozRmMTFz/By6L/aBmK7qe6RqSE/dwYKLxnAzuzLeDVltKV1JAZmvg jO3GEh8NMHcNRzLxZP1yCOj+3nqek2pGGVDGQXaBN1PXzAVjzeoSuw1A91X2+W5Dmd VsPRJ91dq2Y4dN+wyW54XY/I0KJV+NEbi6CFuD7+vzfuNfp0N6cDw9UInBhZXmoN2P tx3awMVRVi37fBIjs2HILgaOVw98V/hoRAv+RQf+N1iCgiJBa9FmYtYoVuuMt4A6fo GmjUEiowA9bTvV8XFEylJDN83Gbnagbr/PGz3n75YVXYkz+cdZ77JYRFCR0mDJCVTi IMNyttwZe4+BQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 313/844] wifi: rtw89: pci: validate release report content before using for RTL8922DE Date: Sat, 28 Feb 2026 12:23:46 -0500 Message-ID: <20260228173244.1509663-314-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ping-Ke Shih [ Upstream commit 5f93d611b33a05bd03d6843c8efe8cb6a1992620 ] The commit 957eda596c76 ("wifi: rtw89: pci: validate sequence number of TX release report") does validation on existing chips, which somehow a release report of SKB becomes malformed. As no clear cause found, add rules ahead for RTL8922DE to avoid crash if it happens. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260123013957.16418-11-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/pci.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireles= s/realtek/rtw89/pci.c index 093960d7279f8..b8135cf15d13c 100644 --- a/drivers/net/wireless/realtek/rtw89/pci.c +++ b/drivers/net/wireless/realtek/rtw89/pci.c @@ -604,8 +604,10 @@ static void rtw89_pci_release_rpp(struct rtw89_dev *rt= wdev, void *rpp) =20 info->parse_rpp(rtwdev, rpp, &rpp_info); =20 - if (unlikely(rpp_info.txch =3D=3D RTW89_TXCH_CH12)) { - rtw89_warn(rtwdev, "should no fwcmd release report\n"); + if (unlikely(rpp_info.txch >=3D RTW89_TXCH_NUM || + info->tx_dma_ch_mask & BIT(rpp_info.txch))) { + rtw89_warn(rtwdev, "should no release report on txch %d\n", + rpp_info.txch); return; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B6C23AAB9E; Sat, 28 Feb 2026 17:38:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300286; cv=none; b=lxfIRZmcxkscIGyrnL/XcLSVz4dqRGdWbPbTPRh2cSclFuxCHhfl7gAX7SE4z26jI5mlM8cVWe/amdhsnOOe7NRIteQvpP46fazUvRlEERcLY474jaV1SxommVWzuKvlOETJI4e905V+1LMsggOKgp0Wqchk4m7zEMlH3Pr9ujY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300286; c=relaxed/simple; bh=8SNhOOm44b/ACAd188vKHovcDjXTTfUaUnS/ehVfOZ8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OznX9SoN/PqsQcGgVhSOS5cQnCpx3/JSBpL8s5h24YyRbdbr/itKy3wlwT5B/0g+MFqUHNIyKIVz+vPBh6t+mxQhE/xNhGAqrqqZvSCb+T2umQ+A16H9q2L4SBNMG58KerzQXru8BVpg7TIR+HHdI0j3uefFMpsIK6ZG18tZLC8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HD1YugXR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HD1YugXR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FD3AC19423; Sat, 28 Feb 2026 17:38:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300286; bh=8SNhOOm44b/ACAd188vKHovcDjXTTfUaUnS/ehVfOZ8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HD1YugXRKcyL463Pv18PMhg/f1hbrsxxbxGJK7PHq7aY9HJvxErYAurzPr2gEeE5K 9oPSWUGo+w8YpgBwOd7FP0+s8v0jCRXmk99i6BOOK/BxjvmVkyhuv84BAnm7m5bQlX iH/BYfoMDGHt8FFzJRSXecfgMKHyhIY1TsZcKg6ePQ9qRmTN0rAmUgj/8/Wb+LtFfZ WrZXti4AfTNaVQkjUeYWcwZxTMPVeH2VTnF1+yiFgNds7XwLzI9q3zq9WEw6/7VW4h xpv7ySCPNt644RuiaT/5/HmFgkbyiBKhDULcWYXLcMP0Pp1gNTbFkpTrdEBEm5ZVEt xQdj2CLwOXT0A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kuniyuki Iwashima , syzbot+d24f940f770afda885cf@syzkaller.appspotmail.com, Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 314/844] ipv4: fib: Annotate access to struct fib_alias.fa_state. Date: Sat, 28 Feb 2026 12:23:47 -0500 Message-ID: <20260228173244.1509663-315-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit 6e84fc395e90465f1418f582a9f7d53c87ab010e ] syzbot reported that struct fib_alias.fa_state can be modified locklessly by RCU readers. [0] Let's use READ_ONCE()/WRITE_ONCE() properly. [0]: BUG: KCSAN: data-race in fib_table_lookup / fib_table_lookup write to 0xffff88811b06a7fa of 1 bytes by task 4167 on cpu 0: fib_alias_accessed net/ipv4/fib_lookup.h:32 [inline] fib_table_lookup+0x361/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811b06a7fa of 1 bytes by task 4168 on cpu 1: fib_alias_accessed net/ipv4/fib_lookup.h:31 [inline] fib_table_lookup+0x338/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 4168 Comm: syz.4.206 Not tainted syzkaller #0 PREEMPT(vo= luntary) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 10/25/2025 Reported-by: syzbot+d24f940f770afda885cf@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69783ead.050a0220.c9109.0013.GAE@goo= gle.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260127043528.514160-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/ipv4/fib_lookup.h | 6 ++++-- net/ipv4/fib_trie.c | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/net/ipv4/fib_lookup.h b/net/ipv4/fib_lookup.h index f9b9e26c32c19..0b72796dd1ad3 100644 --- a/net/ipv4/fib_lookup.h +++ b/net/ipv4/fib_lookup.h @@ -28,8 +28,10 @@ struct fib_alias { /* Don't write on fa_state unless needed, to keep it shared on all cpus */ static inline void fib_alias_accessed(struct fib_alias *fa) { - if (!(fa->fa_state & FA_S_ACCESSED)) - fa->fa_state |=3D FA_S_ACCESSED; + u8 fa_state =3D READ_ONCE(fa->fa_state); + + if (!(fa_state & FA_S_ACCESSED)) + WRITE_ONCE(fa->fa_state, fa_state | FA_S_ACCESSED); } =20 /* Exported by fib_semantics.c */ diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c index 7e2c17fec3fc4..1308213791f19 100644 --- a/net/ipv4/fib_trie.c +++ b/net/ipv4/fib_trie.c @@ -1280,7 +1280,7 @@ int fib_table_insert(struct net *net, struct fib_tabl= e *tb, new_fa->fa_dscp =3D fa->fa_dscp; new_fa->fa_info =3D fi; new_fa->fa_type =3D cfg->fc_type; - state =3D fa->fa_state; + state =3D READ_ONCE(fa->fa_state); new_fa->fa_state =3D state & ~FA_S_ACCESSED; new_fa->fa_slen =3D fa->fa_slen; new_fa->tb_id =3D tb->tb_id; @@ -1745,7 +1745,7 @@ int fib_table_delete(struct net *net, struct fib_tabl= e *tb, =20 fib_remove_alias(t, tp, l, fa_to_delete); =20 - if (fa_to_delete->fa_state & FA_S_ACCESSED) + if (READ_ONCE(fa_to_delete->fa_state) & FA_S_ACCESSED) rt_cache_flush(cfg->fc_nlinfo.nl_net); =20 fib_release_info(fa_to_delete->fa_info); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D1B93AABB8; Sat, 28 Feb 2026 17:38:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300287; cv=none; b=H900LtCZaWdWfAur8J5do0Dcb8Xr0MI+x29e/rSR0W6bxKd/BMKkTzENKuiEY4eCKhnMXOaPvS275cWWf2FG+LxGi5Md3gFZvvLdJyRDa6nS8JqEFF6jOJcthVUcG8n2zeK/kU9Xz43ssvsb7QhCTte+EzKSTloeJuGeWa1NKJw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300287; c=relaxed/simple; bh=jCoQKAR6k1i8Hx+P3D47Wg+xVrA55HN2Kfj9GS8+HI0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FtTIvrFATV/5Llqrv5iRoS4XxB/pBCBjJj0IxyvadDOvO0T+pAL3KaJK6VMNNvX9UDymPmRefQkdfokYc43wXd9EMR0X2v1Z+gpFVV0LXFqd7DIEvLHMBwMJ5S3KsTaQWIENfNs6Qk8MVpkxHmwcgt6/WLuHwA/urULDzLQvWJE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qpdr4er/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qpdr4er/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 599BAC116D0; Sat, 28 Feb 2026 17:38:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300286; bh=jCoQKAR6k1i8Hx+P3D47Wg+xVrA55HN2Kfj9GS8+HI0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qpdr4er/flADCQ3qsPm7j3JfsLX5BSAl73peW7VxXkXtwhWuawfIsqMEcDXl3BwlF AkhtKRJOFlcu2bzzuNDJ6kqJkPmAK0CJIbfgI3L8ye8UQC/mXejtQNDyI25mKuprmN Avtt7mN1qM7iMjlKUp9S5ufOwo4Jgp3MkTq3fvaibHnh9tISkyUpTFE6y9W9bDplI1 pftnEEodMHyML7JfpuDTMF8Ym97PNIcbLupnHnpIJAxV3bCAQYXhgFfAP2pxivWq9v qYHPiJcMbtwiDJ2tRFddhPX/mn2R0O1rIy1eICIofz16G3oJKRuel0IFd4ilBPaCf8 c96J3UsiiiW+Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bluecross , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 315/844] Bluetooth: btusb: Add support for MediaTek7920 0489:e158 Date: Sat, 28 Feb 2026 12:23:48 -0500 Message-ID: <20260228173244.1509663-316-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bluecross [ Upstream commit 2630bcc8343a9d2a38dc1793068e6754b3156811 ] Add support for MediaTek7920 0489:e158 /sys/kernel/debug/usb/devices reports for that device: T: Bus=3D03 Lev=3D01 Prnt=3D01 Port=3D02 Cnt=3D03 Dev#=3D 5 Spd=3D480 Mx= Ch=3D 0 D: Ver=3D 2.10 Cls=3Def(misc ) Sub=3D02 Prot=3D01 MxPS=3D64 #Cfgs=3D 1 P: Vendor=3D0489 ProdID=3De158 Rev=3D 1.00 S: Manufacturer=3DMediaTek Inc. S: Product=3DWireless_Device S: SerialNumber=3D000000000 C:* #Ifs=3D 3 Cfg#=3D 1 Atr=3De0 MxPwr=3D100mA A: FirstIf#=3D 0 IfCount=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 I:* If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D125us E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 512 Ivl=3D0ms E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 512 Ivl=3D0ms I:* If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms I: If#=3D 1 Alt=3D 6 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 63 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 63 Ivl=3D1ms I:* If#=3D 2 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3D(none) E: Ad=3D8a(I) Atr=3D03(Int.) MxPS=3D 64 Ivl=3D125us E: Ad=3D0a(O) Atr=3D03(Int.) MxPS=3D 64 Ivl=3D125us I: If#=3D 2 Alt=3D 1 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3D(none) E: Ad=3D8a(I) Atr=3D03(Int.) MxPS=3D 512 Ivl=3D125us E: Ad=3D0a(O) Atr=3D03(Int.) MxPS=3D 512 Ivl=3D125us Signed-off-by: Andrew Elatsev Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 80ccfa8fd982a..ef08567a7487c 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -639,6 +639,8 @@ static const struct usb_device_id quirks_table[] =3D { BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x13d3, 0x3622), .driver_info =3D BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x0489, 0xe158), .driver_info =3D BTUSB_MEDIATEK | + BTUSB_WIDEBAND_SPEECH }, =20 /* Additional MediaTek MT7921 Bluetooth devices */ { USB_DEVICE(0x0489, 0xe0c8), .driver_info =3D BTUSB_MEDIATEK | --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 424753AB423; Sat, 28 Feb 2026 17:38:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300288; cv=none; b=en9vsjQ7b9koMPXVkSzdrSqRZFi2rF5VhuwGsNPTM5yFq4k1FLftL6BRSNlKU4Tv9DSRCYz56hAHzhOhBk2McFQhjf9ZSnJ9yL83RdEEyb6IijQIWNvlJuvIALV9FuXW8IbvuxpUMUIlHs8Ot61xG1g3F1zqFpM78dAaVlOGHN0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300288; c=relaxed/simple; bh=5JgT2L3Zry9ZaKOHywsRUBM87mU0XvTZ6LuSRBXw7Wo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HZojLLZn1Ls1CB7/QeYotiu+RWqTb8JSJYhkYhvKmM1RJGVtU5ylkhPnuoidRhRj68NnwJJ886cbY6eNk+1nPmJAqo7nnmBAIElknvkO0McygGfAnvwrMIF1NR8hXCS5VnPa0WQ+aF+JCJ2XpHzBVkJ75m49pzBXsfiOjm7QwhY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pqu2AXX2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pqu2AXX2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 343B1C19424; Sat, 28 Feb 2026 17:38:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300287; bh=5JgT2L3Zry9ZaKOHywsRUBM87mU0XvTZ6LuSRBXw7Wo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pqu2AXX2z1/9vgGerB7yc+mWCvxVae20TEpzy26NiR1XLcZguGbxiVkRanZCU8tVA 0GJA4uwu4BwfnzjeYwvQrmwd2tEjWE8JUjwrakCJvAwFHZ6aJKxgxSWpJ8v6TGkLkF OGGAgJCZRNrCvSj4gdAWoxUfJZdEh4K+JEMI8wGEEiqGvbnfXWXUPB6Y0eOh1IOsR/ UC3mne5VyY08BpcIuCgCo6F3Asse2twNplmZwjG7AfTF5rg5QbpN1wEplIUXBNNRTL TXXhqxl0t1cUCNrDQc9Oh9No4cYFr3Ve6Vi/wZAnKB52QJy4dCBuqLvUmIDDrW5HmD sdTcVVrIHi3+Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shuai Zhang , Dmitry Baryshkov , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 316/844] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw Date: Sat, 28 Feb 2026 12:23:49 -0500 Message-ID: <20260228173244.1509663-317-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shuai Zhang [ Upstream commit fce1a9244a0f85683be8530e623bc729f24c5067 ] On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw and cannot be controlled by the host. As a result, in case of a firmware crash, the host cannot trigger a cold reset. Instead, the BT controller performs a warm restart on its own, without reloading the firmware. This leads to the controller remaining in IBS_WAKE state, while the host expects it to be in sleep mode. The mismatch causes HCI reset commands to time out. Additionally, the driver does not clear internal flags QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence. If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag is not cleared, so only the first SSR generates a coredump. Tell the driver that the BT controller has undergone a proper restart seque= nce: - Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR. - Add a 50ms delay to allow the controller to complete its warm reset. - Reset tx_idle_timer to prevent the host from entering TX sleep mode. - Clear memcoredump_flag to allow multiple coredump captures. Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set, which indicates that BT_EN is defined in DTS and cannot be toggled. Refer to the comment in include/net/bluetooth/hci.h for details on HCI_QUIRK_NON_PERSISTENT_SETUP. Reviewed-by: Dmitry Baryshkov Signed-off-by: Shuai Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/bluetooth/hci_qca.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 888176b0faa90..a3c217571c3c4 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1653,6 +1653,39 @@ static void qca_hw_error(struct hci_dev *hdev, u8 co= de) skb_queue_purge(&qca->rx_memdump_q); } =20 + /* + * If the BT chip's bt_en pin is connected to a 3.3V power supply via + * hardware and always stays high, driver cannot control the bt_en pin. + * As a result, during SSR (SubSystem Restart), QCA_SSR_TRIGGERED and + * QCA_IBS_DISABLED flags cannot be cleared, which leads to a reset + * command timeout. + * Add an msleep delay to ensure controller completes the SSR process. + * + * Host will not download the firmware after SSR, controller to remain + * in the IBS_WAKE state, and the host needs to synchronize with it + * + * Since the bluetooth chip has been reset, clear the memdump state. + */ + if (!hci_test_quirk(hu->hdev, HCI_QUIRK_NON_PERSISTENT_SETUP)) { + /* + * When the SSR (SubSystem Restart) duration exceeds 2 seconds, + * it triggers host tx_idle_delay, which sets host TX state + * to sleep. Reset tx_idle_timer after SSR to prevent + * host enter TX IBS_Sleep mode. + */ + mod_timer(&qca->tx_idle_timer, jiffies + + msecs_to_jiffies(qca->tx_idle_delay)); + + /* Controller reset completion time is 50ms */ + msleep(50); + + clear_bit(QCA_SSR_TRIGGERED, &qca->flags); + clear_bit(QCA_IBS_DISABLED, &qca->flags); + + qca->tx_ibs_state =3D HCI_IBS_TX_AWAKE; + qca->memdump_state =3D QCA_MEMDUMP_IDLE; + } + clear_bit(QCA_HW_ERROR_EVENT, &qca->flags); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCCA53AB43B; Sat, 28 Feb 2026 17:38:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300288; cv=none; b=c/bzYksHblhAuXRba0wkTJJQDIMTwxnlAy0mBS4iI6XunifeWgu1tzhlC/vIpacEHzMvBA/AKwDBnZGgeS57iVtI9xf5AtuXPnnk38iEti9NMMqlqcfUvQMbRF4yeFoddcLGcXLcn4+nXBRwa+Vy8N+Jnkb16FSUtE8mtsOSZIY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300288; c=relaxed/simple; bh=+FuiE37p1GIm7r8cnuNB6Z3inMMRPCWdZVfvrWDVax0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QTMSD1xONsKwLVuxlxfKhEtYXX/xhjfGROav+jtxKWWnrxFHIhurl12wOBb6TuHgTWWSlJ2TT1pZhU55r0YUsYs2gFFys8M3p5RCPfgoxrv2aHQd/XYS6RdNJpdzk4vRoZwUou6Rz1KFbX+RRyFGU6JbMezULdfPrgZKfi34VRQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rVIlfmK1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rVIlfmK1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23A1CC116D0; Sat, 28 Feb 2026 17:38:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300288; bh=+FuiE37p1GIm7r8cnuNB6Z3inMMRPCWdZVfvrWDVax0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rVIlfmK1/km97MXnmPUK7MlzBlJDwZBhWzegXScOacqMJCYkpejFYHtmXYNCQw+bn usi8pnu17Zx526bOeEynuRvGz7J1DFbhmOlzJZWsWyJSjFNndW3FE3hfxCiXrPHaWe 8EP/BGb6UrAx1uhlQznO8JW23FCEuNTwqSbjSaWIWK7OrwnJRXP9NHvRZHCX+2RaUe meZEKX/cdBpB4fUI0VHUtXaU09ukttiyVS6UyQBGXjSdAEOGV2Y/L2eHO82awQPWj9 dbW2B4e4E+f8YOahdJY10hl92XJFmuSJdd197Og+bkog8vKf61YGIPsj2Q3SJsi/EF zZG1Dpuc4dfdw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Stefan=20S=C3=B8rensen?= , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 317/844] Bluetooth: hci_conn: Set link_policy on incoming ACL connections Date: Sat, 28 Feb 2026 12:23:50 -0500 Message-ID: <20260228173244.1509663-318-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Stefan S=C3=B8rensen [ Upstream commit 4bb091013ab0f2edfed3f58bebe658a798cbcc4d ] The connection link policy is only set when establishing an outgoing ACL connection causing connection idle modes not to be available on incoming connections. Move the setting of the link policy to the creation of the connection so all ACL connection will use the link policy set on the HCI device. Signed-off-by: Stefan S=C3=B8rensen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/bluetooth/hci_conn.c | 1 + net/bluetooth/hci_sync.c | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index 5a4374ccf8e84..98f0461b3dd7d 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -1002,6 +1002,7 @@ static struct hci_conn *__hci_conn_add(struct hci_dev= *hdev, int type, switch (type) { case ACL_LINK: conn->pkt_type =3D hdev->pkt_type & ACL_PTYPE_MASK; + conn->link_policy =3D hdev->link_policy; conn->mtu =3D hdev->acl_mtu; break; case LE_LINK: diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index cbc3a75d73262..334eb4376a266 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -6897,8 +6897,6 @@ static int hci_acl_create_conn_sync(struct hci_dev *h= dev, void *data) =20 conn->attempt++; =20 - conn->link_policy =3D hdev->link_policy; - memset(&cp, 0, sizeof(cp)); bacpy(&cp.bdaddr, &conn->dst); cp.pscan_rep_mode =3D 0x02; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB9FF3AB45D; Sat, 28 Feb 2026 17:38:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300289; cv=none; b=ezjSAoCycPOa/rp6/rol5KHh/i+UDYB9khlp4F1GYsdUl/xRBJslqS4DeIW7NUKYpQgJ5X6lCmE0dnoZkt6BCb8meG7HwNnJxRLMcGeWByL0yMeB7+58XaRwOzyghzWCmEaNjRY7wezIfGOZ6vveXIn+znkHiVMoux5HG1qQi2Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300289; c=relaxed/simple; bh=eRepZaOczSFY2csbs4wBiKgRnSPTFjNzmPSi9otYBP8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Dsd+6IXkk9ev56hQI3VnBYbtiYNdeMBanusVPH6/Lp8W7JqJB9xEBmC5CVhBdeVVxeJeysAqPAeNoTHlUoUZZxyit5dmv0iGow2GhkBhYMtvdvWTbir6aaqOPljFQE4SBVATv5rL04VWIo5s6EyeyH9OWJZyu2p3H9Otq663jN8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r6RmttdN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="r6RmttdN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0045DC19423; Sat, 28 Feb 2026 17:38:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300289; bh=eRepZaOczSFY2csbs4wBiKgRnSPTFjNzmPSi9otYBP8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r6RmttdN08BWSBJSNymbVQDKWP2+3lO8U7c/R5uIQQvJNdSh41APDAW35BIt7UB0G LjoCV/Ni0aQdXMo29NCpA8uK4d5C3fV1PjbmB1Lb8TJ2qzNsbMOdSxjzvMx195u/qI q7P/Yp0eL5pZzKJJhaY1KEXA0NnQON5vno/0bfQubunFPqZYZGnknIYwzG7dYeDki+ qVKSLFY/JPLyXmZumiqSe4P7Kcy5MhJm3P4dW7Otth2z0tXl4vfoyjEkbnTSnRnfxx /carbagUWThn4Hyn8CV8/zbAqQRFBj9G89C2SOjq0ySiO9TWXwgDxQ/zotdfwEr1k3 a+iG+PQDQmjAQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Techie Ernie , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 318/844] Bluetooth: btusb: Add USB ID 0489:e112 for Realtek 8851BE Date: Sat, 28 Feb 2026 12:23:51 -0500 Message-ID: <20260228173244.1509663-319-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Techie Ernie [ Upstream commit e07094a51ad8faf98ea64320799ce550828e97cd ] Add USB ID 0489:e112 for the Realtek 8851BE Bluetooth adapter. Without this entry, the device is not handled correctly by btusb and Blueto= oth fails to initialise. Adding the ID enables proper Realtek initialization for Bluetooth to work o= n various motherboards using this Bluetooth adapter. The device identifies as: Bus 001 Device XXX: ID 0489:e112 Foxconn / Hon Hai Bluetooth Radio Tested on Realtek 8851BE. Bluetooth works after this change is made. Signed-off-by: Techie Ernie Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index ef08567a7487c..66e266e93cc12 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -521,6 +521,8 @@ static const struct usb_device_id quirks_table[] =3D { { USB_DEVICE(0x0bda, 0xb850), .driver_info =3D BTUSB_REALTEK }, { USB_DEVICE(0x13d3, 0x3600), .driver_info =3D BTUSB_REALTEK }, { USB_DEVICE(0x13d3, 0x3601), .driver_info =3D BTUSB_REALTEK }, + { USB_DEVICE(0x0489, 0xe112), .driver_info =3D BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, =20 /* Realtek 8851BU Bluetooth devices */ { USB_DEVICE(0x3625, 0x010b), .driver_info =3D BTUSB_REALTEK | --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82CCC3ABCEB; Sat, 28 Feb 2026 17:38:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300290; cv=none; b=AFPZqZQIgnNqLRDaPWGTHky4WoV+B1Sda7crfaMGl3Q9aqzsAVoaFUZIxdbwNlwJJBnFwTPTgnc+lA4GQMe9LM78DTno8U1bjJVsWfm9OT9lmX34MvoYrMHfr0t8gj3wleep6hpM3McJp2+uQ8Y8Ip+3q18oMJNA7Paq1feewWs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300290; c=relaxed/simple; bh=5CmZ0ezQLskFJVxiDwB6Jj+vIZnoq5Jpd3GF+gEM7EQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sC09uVTFq9PgRW3tLcN3L58wMF9NV9rggMJA6hEPvlqfIXRAeUKzaXWhkvh4gzck1XHqh+fc3kpuVSh1hFMHAlkS1IW4XeLCbFOezfw0O+mRI0s49Vi4u2upgZZgwkrLCquwLdE8GPAe9ALRymQh3gj+H3cE0mqpouGv3YBmCR8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G33OQ2n1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="G33OQ2n1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE2D3C19425; Sat, 28 Feb 2026 17:38:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300290; bh=5CmZ0ezQLskFJVxiDwB6Jj+vIZnoq5Jpd3GF+gEM7EQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G33OQ2n1lSZmBLdcXWKiP80X+a3j9Z5dOK1kf1TaEnTKq/ifiyh6RvbkdzO+lOcN4 NrNNgFkuQzlK1QSthXidq6z9sVO6kYVPYrHPw4FZLeB9BXEqXToE96GjOqXC47QNeK 1IJ74OBUyAqduyNXUzua9T1CBDyj8pVP2BTKeQ3EJyuKpYXfagEliuIFe1lpM04kUF qVaAJTonGw/UInKZehyXCihPo9tYwlnihu850Gm1mWd0x57n22G0T/Yikwvdx1rN3Z kLKDSZU2JnnbFhNVmj54npomRJgqkXv/SA6wWNS1/phrDNL3dmSFnRlJ3Cy4FuRhLf 1UrqCQydZJ/Vg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Stefan=20S=C3=B8rensen?= , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 319/844] Bluetooth: hci_conn: use mod_delayed_work for active mode timeout Date: Sat, 28 Feb 2026 12:23:52 -0500 Message-ID: <20260228173244.1509663-320-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Stefan S=C3=B8rensen [ Upstream commit 49d0901e260739de2fcc90c0c29f9e31e39a2d9b ] hci_conn_enter_active_mode() uses queue_delayed_work() with the intention that the work will run after the given timeout. However, queue_delayed_work() does nothing if the work is already queued, so depending on the link policy we may end up putting the connection into idle mode every hdev->idle_timeout ms. Use mod_delayed_work() instead so the work is queued if not already queued, and the timeout is updated otherwise. Signed-off-by: Stefan S=C3=B8rensen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/bluetooth/hci_conn.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index 98f0461b3dd7d..dc085856f5e91 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -2620,8 +2620,8 @@ void hci_conn_enter_active_mode(struct hci_conn *conn= , __u8 force_active) =20 timer: if (hdev->idle_timeout > 0) - queue_delayed_work(hdev->workqueue, &conn->idle_work, - msecs_to_jiffies(hdev->idle_timeout)); + mod_delayed_work(hdev->workqueue, &conn->idle_work, + msecs_to_jiffies(hdev->idle_timeout)); } =20 /* Drop all connection on the device */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 613453ABD0A; Sat, 28 Feb 2026 17:38:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300291; cv=none; b=sgSeOKNXs+nhfObVtMPnNQRCX3oocMt/wYWXGpclXTHtJdDZtC5v2FjULJwuRLhxXHNQNJYiRbTnmJ2ai0LkTEOT2s745fWEZM+s8S1ZIOOp48u9eK2QY0y3HFn1wHsvjs8rTCW8BZAWSHQcIcmrSqsIdra6uCzVRq4WEFPrnZo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300291; c=relaxed/simple; bh=/c2Zp8efhi18hryIrBHeyeq9oPtW96tZTXhAbEHQHFs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L7BvGDnT1YgSMgVGl8/8th599aaYN790Qy8qc0a+jH3pcDkkcl7ojdnh+j0hrodFn4K5GwEhzfS0fHU6MpiMsuZ+XGQjYMXR/MWnAqZ4myYlVeE0rjC4Wm8rd9rTvwXZd02rtSfeseF1p1OSnxVuwonhLr2+L/1t9ymAZ65C4Sc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A3Tx6ltU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="A3Tx6ltU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9B40C19423; Sat, 28 Feb 2026 17:38:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300291; bh=/c2Zp8efhi18hryIrBHeyeq9oPtW96tZTXhAbEHQHFs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A3Tx6ltUaZkRnL9EuLsvb+/wYkIoan+dLU5EXcNqBRa7oRaBxNww0sRftF4PM3Qbo 0+VZU1XR8m0DIMg+EDYCpfW2NI769ZtsBCdn3W32sb7+47Ci6+tX0/aDc7z87d9NBg NKd8kUl1M7kz9PQDlr9unyN63MbvHaolcE59N7WyuttxKTEVbTUUyQDBiPLAgiz+MR OBAuuX4OiLn1fVFgwh+i0BICFzDMZZTR8exN8Bp0Ko0ERC5/5Ky1MPbroBgFabLgRc GbCv+8l7XneZUnco4YQHM7LKYmAzarzwWmhmGF+mAkFSUU4kcjabMpMecv8WNm+cSV Bymw5sW5FqNIg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shell Chen , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 320/844] Bluetooth: btusb: Add new VID/PID for RTL8852CE Date: Sat, 28 Feb 2026 12:23:53 -0500 Message-ID: <20260228173244.1509663-321-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shell Chen [ Upstream commit d9f7c39c6b7548bd70519b241b6c2d1bcc658d4b ] Add VID:PID 13d3:3612 to the quirks_table. This ID pair is found in the Realtek RTL8852CE PCIe module in an ASUS TUF A14 2025 (FA401KM) laptop. Tested on aforementioned laptop. The device info from /sys/kernel/debug/usb/devices is listed as below. T: Bus=3D03 Lev=3D01 Prnt=3D01 Port=3D04 Cnt=3D01 Dev#=3D 2 Spd=3D12 Mx= Ch=3D 0 D: Ver=3D 1.00 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 MxPS=3D64 #Cfgs=3D 1 P: Vendor=3D13d3 ProdID=3D3612 Rev=3D 0.00 S: Manufacturer=3DRealtek S: Product=3DBluetooth Radio S: SerialNumber=3D00e04c000001 C:* #Ifs=3D 2 Cfg#=3D 1 Atr=3De0 MxPwr=3D500mA I:* If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D1ms E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms I:* If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms I: If#=3D 1 Alt=3D 6 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 63 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 63 Ivl=3D1ms Signed-off-by: Shell Chen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 66e266e93cc12..f177569978d36 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -561,6 +561,8 @@ static const struct usb_device_id quirks_table[] =3D { BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x13d3, 0x3592), .driver_info =3D BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x13d3, 0x3612), .driver_info =3D BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x0489, 0xe122), .driver_info =3D BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83F673AC600; Sat, 28 Feb 2026 17:38:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300292; cv=none; b=p4mN08bprZ/hgGKXsClEiDrF1Ni29UMEjcBmwwRtl8VXpAXDVJQN9bmoytbfTApSWy4pjW7E1jhUmfhLz4PjIiO7Ak4k+PEqDMoaOYtoo20rZKv/GxqNVxv/1OkP9Zlef4j2CvFS4dw7pH3WymnL+2JobI8LkiBztLjBSudUiVg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300292; c=relaxed/simple; bh=Fuk0VkTbDtCRNIW9UwQry52EKbge60CQXU3QbaxKbjE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=e4YHI3tugh5FwsCvgegovgfnoFzT7UR+51s5JJygz5jgVFoyBkiocY1RCsjbbwleIu5Ej25vIAdSF/bP1LVRdQCjb5SQxNjF5BEI/EpzwTZBKTtPTfR6GCfay9XbvStvDwyhirRLstwwtq5Qp0FOUUjXJQbJzeqBkC+KdMmBW2E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QnH1Ot3A; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QnH1Ot3A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 888BFC19423; Sat, 28 Feb 2026 17:38:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300292; bh=Fuk0VkTbDtCRNIW9UwQry52EKbge60CQXU3QbaxKbjE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QnH1Ot3AXU0KcLWUygNhgFpcg7bB88VlJRDdp0wk0JQ1U5I1iMKA4+0XVbMp4Noxo 3eDIJuRg3CPSTFpy00Jibwt2h266UWYcADh4oAMLaBo2Us+rYoFsH1PugL0wjnlW6a DnbqLjuXlCTPFgtW3PGV+ZXt0LYFHGcm153dKjh75mLjDhBVSIxb1DBcbadhJLQMU7 VloUQ0sZ5NBpZBrmCgzMZEkfRfXrU6023BTvK/g/QfmxDPciZ2rr36+U5EWI/NgtSW ID2w6w1xDAujk7UkDcXoqsnQ8Cte0jxKYqySKUl3igqNDZlcOHMbNF3nnE9XqVbpa0 S2vB1kLyYE91Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jacopo Scannella , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 321/844] Bluetooth: btusb: Add device ID for Realtek RTL8761BU Date: Sat, 28 Feb 2026 12:23:54 -0500 Message-ID: <20260228173244.1509663-322-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jacopo Scannella [ Upstream commit cc6383d4f0cf6127c0552f94cae517a06ccc6b17 ] Add USB device ID 0x2c0a:0x8761 to the btusb driver fo the Realtek RTL8761BU Bluetooth adapter. Reference: https://www.startech.com/en-us/networking-io/av53c1-usb-bluetooth Signed-off-by: Jacopo Scannella Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index f177569978d36..a41bb1e2a279a 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -781,6 +781,7 @@ static const struct usb_device_id quirks_table[] =3D { =20 /* Additional Realtek 8723BU Bluetooth devices */ { USB_DEVICE(0x7392, 0xa611), .driver_info =3D BTUSB_REALTEK }, + { USB_DEVICE(0x2c0a, 0x8761), .driver_info =3D BTUSB_REALTEK }, =20 /* Additional Realtek 8723DE Bluetooth devices */ { USB_DEVICE(0x0bda, 0xb009), .driver_info =3D BTUSB_REALTEK }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39DD73AC616; Sat, 28 Feb 2026 17:38:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300293; cv=none; b=G+TL/9UTfqqvNecPeJvKgmruHsGqGBS9tp5fKN8eJVr3fJJxJ9dM5vWkRLJdtrl3WrUScdFpFxE3uGHCzeqcXMxnEzLmnWtS9mluUtR/N+IeM7Iyov06hfGyvnL6wBUPKKs3/2PyRhPcmSYZ7pYbODAFj4+ZIWYTxGRDNB4unGo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300293; c=relaxed/simple; bh=iBDXLbaRLhBUSeiye2udkHyAyFZG9CUC0CKCq+tjCA0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YDY1QU1tlhV/UYbCKl4bIrocvwV4qqRzFDKSm7fcKufw68c37S2g1YuJMSegXKNK5wf9vF6cYTAq3cyb1NjU8OExgB25/JSbtHAwhX/wfBaPw+cnD9ZxAZA8Xgp0xMIAgVsjCoVIRspd66MpHkAkMEAbubQ3Zm+6S03clD4w2jI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=b3ItAufy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="b3ItAufy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 649BBC19425; Sat, 28 Feb 2026 17:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300293; bh=iBDXLbaRLhBUSeiye2udkHyAyFZG9CUC0CKCq+tjCA0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=b3ItAufy8Z8AsONSg69sBoBG+itWNRiJHSBeQa1rLIUoGrynCYpHiJMSNBtzRsPdw Z0uhEP+1YBrpKJ56Iy3cCHjMUJ1y5PexO8ZYQDepjyFRe9QwDL3Vu3DLFLJbLCA8CQ FG2RyhJME0QQSPgEvpmLN0+0wxVqgRDqEwC77FP3iKbAbgWSnBiHRmzcEvK+t939tf +PEfnQRtBfCChNSVlUiG8ccTZAOGQtzbcl/4Zpr3dV4T7TlHF4+HSlQQKsXK9Om7oW fw8DqXTNckcW2RrmVf0Zmtb7tHI9j8M62o49UxhkdjOpNkVuZG54hBu0xVRY/HBfIX JDZlOCG5Vu1Uw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Geetha sowjanya , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 322/844] octeontx2-af: Workaround SQM/PSE stalls by disabling sticky Date: Sat, 28 Feb 2026 12:23:55 -0500 Message-ID: <20260228173244.1509663-323-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Geetha sowjanya [ Upstream commit 70e9a5760abfb6338d63994d4de6b0778ec795d6 ] NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky =E2=86=92 non-sticky transition path that can deadlock P= SE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations. Signed-off-by: Geetha sowjanya Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260127125147.1642-1-gakula@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c b/drivers/= net/ethernet/marvell/octeontx2/af/rvu_nix.c index 2f485a930edd1..49f7ff5eddfc8 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c @@ -4938,12 +4938,18 @@ static int rvu_nix_block_init(struct rvu *rvu, stru= ct nix_hw *nix_hw) /* Set chan/link to backpressure TL3 instead of TL2 */ rvu_write64(rvu, blkaddr, NIX_AF_PSE_CHANNEL_LEVEL, 0x01); =20 - /* Disable SQ manager's sticky mode operation (set TM6 =3D 0) + /* Disable SQ manager's sticky mode operation (set TM6 =3D 0, TM11 =3D 0) * This sticky mode is known to cause SQ stalls when multiple - * SQs are mapped to same SMQ and transmitting pkts at a time. + * SQs are mapped to same SMQ and transmitting pkts simultaneously. + * NIX PSE may deadlock when there are any sticky to non-sticky + * transmission. Hence disable it (TM5 =3D 0). */ cfg =3D rvu_read64(rvu, blkaddr, NIX_AF_SQM_DBG_CTL_STATUS); - cfg &=3D ~BIT_ULL(15); + cfg &=3D ~(BIT_ULL(15) | BIT_ULL(14) | BIT_ULL(23)); + /* NIX may drop credits when condition clocks are turned off. + * Hence enable control flow clk (set TM9 =3D 1). + */ + cfg |=3D BIT_ULL(21); rvu_write64(rvu, blkaddr, NIX_AF_SQM_DBG_CTL_STATUS, cfg); =20 ltdefs =3D rvu->kpu.lt_def; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39CBF3AC633; Sat, 28 Feb 2026 17:38:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300294; cv=none; b=JSYTKwcB7F0F4jDKnx4IGwzQijmTjcxU0sKfrv4wtvFlDqGeTv0BtWSZ782x5l+llVtti9j17NPCieAasQQnhIZuidJZaScKyOtHtlDRy24FVsiSpNppuIWDMnxs2SG0wkJ67m+FzWb74XqSRkCKkViGbP5mpH/q6/QbOgQWkXA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300294; c=relaxed/simple; bh=r2xgP5PyfmenROj68v9m+9bJzfof5h81AA6cs0O7Ns4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CEeVq5BJYqFQcOXkE8/mfE0pvH/mJwrm0MuUlRarWt+nspSiW1yUNQh39KoYE1W4VCLH9bwS4RyO1Wt40lYF9jcLVORS0Ax4eqc5Ia7V1Dx+actfXiMfeMC02XRZHTPNTK3LPwMQV3+UVr2hSUQt+y9ms9p2iDPA4OrFngVMvBo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bQbmkhjO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bQbmkhjO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 589D4C19423; Sat, 28 Feb 2026 17:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300293; bh=r2xgP5PyfmenROj68v9m+9bJzfof5h81AA6cs0O7Ns4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bQbmkhjOhnf4ariIISrIgX+KwBAPaKRsG040Lymq5ykRx7BKFhz0fNozVPav+4fhF 5qoeUMWxq+Y/DvcucyG/QWtLOMFwZUTOiPgPARkG5g4zIYwwNJI8gsWAyuPbnWxM8V TjYpUlahHqs8Rjjjv9TZ6dizHwKKMNKFUcZQ5m+eRrhLYI7+wN69HTVCbQFHwXYSlO zg55zFGDK+0Y1qdjcAU9kERYjeiPt2SgkX8qzk3a7RGyWQApcz9XwfsL47DIko+oI1 IuwJMwobhjOAtSDRH6Dwv5E0ZhJuW0TG9wQZuRgSQoyUjj32xJQk1P319oLl4/SLqH ICx3CqJEKfbkg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Marek=20Beh=C3=BAn?= , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 323/844] net: sfp: add quirk for Lantech 8330-265D Date: Sat, 28 Feb 2026 12:23:56 -0500 Message-ID: <20260228173244.1509663-324-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Marek Beh=C3=BAn [ Upstream commit 86a8e8e0ddbc3d14c799536eb888180b84d002f3 ] Similar to Lantech 8330-262D-E, the Lantech 8330-265D also reports 2500MBd instead of 3125MBd. Also, all 8330-265D report normal RX_LOS in EEPROM, but some signal inverted RX_LOS. We therefore need to ignore RX_LOS on these modules. Signed-off-by: Marek Beh=C3=BAn Link: https://patch.msgid.link/20260128170044.15576-1-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/phy/sfp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c index 3e023723887c4..43aefdd8b70f7 100644 --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -532,9 +532,13 @@ static const struct sfp_quirk sfp_quirks[] =3D { SFP_QUIRK("HUAWEI", "MA5671A", sfp_quirk_2500basex, sfp_fixup_ignore_tx_fault), =20 - // Lantech 8330-262D-E can operate at 2500base-X, but incorrectly report - // 2500MBd NRZ in their EEPROM + // Lantech 8330-262D-E and 8330-265D can operate at 2500base-X, but + // incorrectly report 2500MBd NRZ in their EEPROM. + // Some 8330-265D modules have inverted LOS, while all of them report + // normal LOS in EEPROM. Therefore we need to ignore LOS entirely. SFP_QUIRK_S("Lantech", "8330-262D-E", sfp_quirk_2500basex), + SFP_QUIRK("Lantech", "8330-265D", sfp_quirk_2500basex, + sfp_fixup_ignore_los), =20 SFP_QUIRK_S("UBNT", "UF-INSTANT", sfp_quirk_ubnt_uf_instant), =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF9A43AD881; Sat, 28 Feb 2026 17:38:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300294; cv=none; b=UU3G9UNe0nDIGB0vtmb7bRELLr8AYTRdxN/oBxv4UgZPWHerbkof5mjR/Y697+87pzxWzGnoAncbg08Y8ILxyq9+3BApdZFhcAGy5bS7IR0/Cfrwt0K3kY2bk1RlUHGoO6jBozkJxRCkVvEJiQ6JGHMlRdZiNCVTV/QWkl66yMA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300294; c=relaxed/simple; bh=MLL1IeJSDw80UpFR24o8SSn6YlKqRQGw8sYJByuFDmE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cCFTTQ01CIJEKXxpO/wOWmBTovYsGUc9GffNzh8hIL5f025LE7fCDEzm0uerJyFMhMS2yRSHpIcNMa+ePZ4V5Kxw/8pHEZA+bICMexHxkqeLsSw34r6+Z1/cMqgIt9nFsB/yG2gu8oaYYmCJBY7xJDHULouZhZ7hpcOXEELGN58= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QTQNVPHP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QTQNVPHP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34C8CC116D0; Sat, 28 Feb 2026 17:38:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300294; bh=MLL1IeJSDw80UpFR24o8SSn6YlKqRQGw8sYJByuFDmE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QTQNVPHPZbtfp1p0/mfXpCM+IesOnRuxxhyXVVAE35XDKLuPlVwCX7U0gRQe13mkN hEMeVs5N7NSlzf6tvh6ti3csoMdLeSoN/qJ+mN3BsNivHOnl8gbjCBFYyV4iR+cdp0 qSYO5NcOJpOvPk3vSdiIjUzSSUhfiL0GWqVomjcf9eB6xnrj/YwAcKVpUvRtDgmxcw UZsLl6WzQNEjeZzijH/za+f0swS3B6bGyHmXdavHOSiiByIGNCCWjULQqGaDy9rUak TF/E5K5fBRWZ5My/O806KNssCBSeGbH4TZWO2DOtfROhTiE3b/52HPfBKCbed1WWPo YeHwBwHpgdCZg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dian-Syuan Yang , Ping-Ke Shih , Sasha Levin Subject: [PATCH 6.19 324/844] wifi: rtw89: pci: restore LDO setting after device resume Date: Sat, 28 Feb 2026 12:23:57 -0500 Message-ID: <20260228173244.1509663-325-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dian-Syuan Yang [ Upstream commit af1e82232b988f8fc6d635c60609765e49221a64 ] The LDO (Low Dropout Regulator) setting is missing after suspend/resume in some platforms, and it will cause card loss. Therefore, reconfigure this setting to avoid it. Signed-off-by: Dian-Syuan Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260127085036.44060-6-pkshih@realtek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/realtek/rtw89/pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireles= s/realtek/rtw89/pci.c index b8135cf15d13c..fb4469a76bc03 100644 --- a/drivers/net/wireless/realtek/rtw89/pci.c +++ b/drivers/net/wireless/realtek/rtw89/pci.c @@ -4605,6 +4605,7 @@ static int __maybe_unused rtw89_pci_resume(struct dev= ice *dev) rtw89_write32_clr(rtwdev, R_AX_PCIE_PS_CTRL_V1, B_AX_SEL_REQ_ENTR_L1); } + rtw89_pci_hci_ldo(rtwdev); rtw89_pci_l2_hci_ldo(rtwdev); =20 rtw89_pci_basic_cfg(rtwdev, true); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04DDC3AD8A4; Sat, 28 Feb 2026 17:38:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300296; cv=none; b=YHgjRetOxa1GD8OqyETI6drjt9uiHl3UeKq4gshRo6k6tTZHMkUHT0c5KaVlg/ZGfjcQ6uiirVrRQBfWFxnywXcPcPlFgdKC7rO9lChuEOGZOjOo5i76Wuvs5MfO2Ja6D50tn312iv0pGC5PGeQjinmpXrA07XGUdH75kc9Uki8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300296; c=relaxed/simple; bh=nqBfQ2Y2Nm4bSX0ZnklbWYblVGiOeektzk4kKoB/Oss=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LFj2CQRR1XT8Q8jI0o1ggc1L5rejrwzGOz43FnDuTWmORHGqLi+Fy6A+iZK9M2waE9rUZ1EsN92IHSH1Sj5+Lo7SA5DCMOd+nSuI7dWEL4zMJvMEgWpPKSujtotXGvGSSTJLEtUtx+eBXo8zgq/M3IoWmhnDvCDItSvTZ16Fqb0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KfLsSW1W; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KfLsSW1W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 125A4C19423; Sat, 28 Feb 2026 17:38:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300295; bh=nqBfQ2Y2Nm4bSX0ZnklbWYblVGiOeektzk4kKoB/Oss=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KfLsSW1WILuK4vx+h6cjH2w6nq2OX44GlGsnNBk3Yjv+9agD0EA68SzFpgYlAQK/m pag8kmKiOAGWRi/OMVvqqggNJvlzP2mSNhFiE4ya2OJKtSpW4GwTnrEERJ3iCXXB3m RDLZSbKWNFOjNgIMCXICxzjjtu6kfAOdpnyhGi6sXBEj5ZUkLbPKBwwprhk1fHmAEN scvAkYkWIM9RWFNM007PdINBUPHkWfJhTzP8F3Kw7CmobndOxKGASo/jjHFV4CN3Bl Vv7+3d6glwNRg4DrbZFeU68RiSlvqEh+CzCJqYjOtDVRCgmpYU5WmRBgZaGf6icYIz 3y98HwpG95W6g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ziyi Guo , Baochen Qiang , Jeff Johnson , Sasha Levin Subject: [PATCH 6.19 325/844] wifi: ath10k: fix lock protection in ath10k_wmi_event_peer_sta_ps_state_chg() Date: Sat, 28 Feb 2026 12:23:58 -0500 Message-ID: <20260228173244.1509663-326-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ziyi Guo [ Upstream commit 820ba7dd6859ef8b1eaf6014897e7aa4756fc65d ] ath10k_wmi_event_peer_sta_ps_state_chg() uses lockdep_assert_held() to assert that ar->data_lock should be held by the caller, but neither ath10k_wmi_10_2_op_rx() nor ath10k_wmi_10_4_op_rx() acquire this lock before calling this function. The field arsta->peer_ps_state is documented as protected by ar->data_lock in core.h, and other accessors (ath10k_peer_ps_state_disable, ath10k_dbg_sta_read_peer_ps_state) properly acquire this lock. Add spin_lock_bh()/spin_unlock_bh() around the peer_ps_state update, and remove the lockdep_assert_held() to be aligned with new locking, following the pattern used by other WMI event handlers in the driver. Signed-off-by: Ziyi Guo Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260123175611.767731-1-n7l8m4@u.northwester= n.edu [removed excess blank line] Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/ath/ath10k/wmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/a= th/ath10k/wmi.c index b4aad6604d6d9..ce22141e5efd9 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -5289,8 +5289,6 @@ ath10k_wmi_event_peer_sta_ps_state_chg(struct ath10k = *ar, struct sk_buff *skb) struct ath10k_sta *arsta; u8 peer_addr[ETH_ALEN]; =20 - lockdep_assert_held(&ar->data_lock); - ev =3D (struct wmi_peer_sta_ps_state_chg_event *)skb->data; ether_addr_copy(peer_addr, ev->peer_macaddr.addr); =20 @@ -5305,7 +5303,9 @@ ath10k_wmi_event_peer_sta_ps_state_chg(struct ath10k = *ar, struct sk_buff *skb) } =20 arsta =3D (struct ath10k_sta *)sta->drv_priv; + spin_lock_bh(&ar->data_lock); arsta->peer_ps_state =3D __le32_to_cpu(ev->peer_ps_state); + spin_unlock_bh(&ar->data_lock); =20 exit: rcu_read_unlock(); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CF0103AC616; Sat, 28 Feb 2026 17:38:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300296; cv=none; b=GyzM738V69J0ACS9yaSWFdn/j/z8JRjzzE3jABHH5qARJL+Ba7TuvEwRk2YzkOvw9iQqy+bwUmVdqV6Fi/FDQIHHeQ3/xbvDaJz85GLERicQQPGeIYRiUDssTTx4G4X4zLAi8S/oanz/SquE9EwEIiXaiw/fCCPP9N4O2AdH0V0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300296; c=relaxed/simple; bh=ZzOY2QlqWAp4Qat/4E/iQvMtW9oNsInxHa5TgouFuZI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Osanl4hzyJwrb4a9U3eAID/Cy2J0pXU0HfbEh6gCPSk1S2a0Eicuj7pKN0qCrG9P+ay/iCtiCOEbny9kwdqHiYkmWb+e3pyU16qAWCm28oze0OCqfCn4cNZHzrqc29JqtWzHdl2ocypBt6oyXjiNzKygy9yxX3txhBeRW1Yg3Qc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OgDPclcX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OgDPclcX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00152C116D0; Sat, 28 Feb 2026 17:38:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300296; bh=ZzOY2QlqWAp4Qat/4E/iQvMtW9oNsInxHa5TgouFuZI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OgDPclcX5RVFfPL0k8eazEDcNUyNVAHftXZkOiWpRQCCBxJzVnwolzAmAiScEty9c 4dv1EtoUuNiGUpDaDJ0h9IomZvTYXSnSyhhE2ntwIG0qaBR9PyiaoL6mEm8JXO5Xqf DYIwrVzFBwPsHh9GRqLYagwvpO73IMyKgN0OuZ7P07Xdh27ZETQADvVg9TvE5Q2Gd7 L8Fqe8UXNAKPRaAjK3fhgXOxGvfRy6HoCT40fP8ZqnVmZQ8vZK+CuTtIyRpreNPUK2 2Xen0RkqISnu4SDup8rwWAPEJY9LQqH3TNSXhk63jRQmdxcpBpKB7htZzM5EMTYWbY ytb+KMGMATR7g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Joe Damato , Michael Chan , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 326/844] bnxt_en: Allow ntuple filters for drops Date: Sat, 28 Feb 2026 12:23:59 -0500 Message-ID: <20260228173244.1509663-327-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Joe Damato [ Upstream commit 61cef6454cfbb9fcdbe41401fb53895f86603081 ] It appears that in commit 7efd79c0e689 ("bnxt_en: Add drop action support for ntuple"), bnxt gained support for ntuple filters for packet drops. However, support for this does not seem to work in recent kernels or against net-next: % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1 rmgr: Cannot insert RX class rule: Operation not supported Cannot insert classification rule The issue is that the existing code uses ethtool_get_flow_spec_ring_vf, which will return a non-zero value if the ring_cookie is set to RX_CLS_FLOW_DISC, which then causes bnxt_add_ntuple_cls_rule to return -EOPNOTSUPP because it thinks the user is trying to set an ntuple filter for a vf. Fix this by first checking that the ring_cookie is not RX_CLS_FLOW_DISC. After this patch, ntuple filters for drops can be added: % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1 Added rule with ID 0 % ethtool -n eth0 44 RX rings available Total 1 rules Filter: 0 Rule Type: UDP over IPv4 Src IP addr: 1.1.1.1 mask: 0.0.0.0 Dest IP addr: 0.0.0.0 mask: 255.255.255.255 TOS: 0x0 mask: 0xff Src port: 0 mask: 0xffff Dest port: 0 mask: 0xffff Action: Drop Reviewed-by: Michael Chan Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260131003042.2570434-1-joe@dama.to Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/ne= t/ethernet/broadcom/bnxt/bnxt_ethtool.c index 068e191ede19e..c76a7623870be 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c @@ -1346,16 +1346,17 @@ static int bnxt_add_ntuple_cls_rule(struct bnxt *bp, struct bnxt_l2_filter *l2_fltr; struct bnxt_flow_masks *fmasks; struct flow_keys *fkeys; - u32 idx, ring; + u32 idx; int rc; - u8 vf; =20 if (!bp->vnic_info) return -EAGAIN; =20 - vf =3D ethtool_get_flow_spec_ring_vf(fs->ring_cookie); - ring =3D ethtool_get_flow_spec_ring(fs->ring_cookie); - if ((fs->flow_type & (FLOW_MAC_EXT | FLOW_EXT)) || vf) + if (fs->flow_type & (FLOW_MAC_EXT | FLOW_EXT)) + return -EOPNOTSUPP; + + if (fs->ring_cookie !=3D RX_CLS_FLOW_DISC && + ethtool_get_flow_spec_ring_vf(fs->ring_cookie)) return -EOPNOTSUPP; =20 if (flow_type =3D=3D IP_USER_FLOW) { @@ -1481,7 +1482,7 @@ static int bnxt_add_ntuple_cls_rule(struct bnxt *bp, if (fs->ring_cookie =3D=3D RX_CLS_FLOW_DISC) new_fltr->base.flags |=3D BNXT_ACT_DROP; else - new_fltr->base.rxq =3D ring; + new_fltr->base.rxq =3D ethtool_get_flow_spec_ring(fs->ring_cookie); __set_bit(BNXT_FLTR_VALID, &new_fltr->base.state); rc =3D bnxt_insert_ntp_filter(bp, new_fltr, idx); if (!rc) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC45E3AE0ED; Sat, 28 Feb 2026 17:38:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300297; cv=none; b=tHO4YbjqbtWSgvRTQM2smvp/nes3wUt78xU4BEi7GaMjbYo60eYx/hjJNzqF4avxx6XRGwq/zKBtu4ii9QGWViM6ZIvqFF2ADKN0vJirk9gCyhvI/LmKVLzqGW6JY+CmAUL17LY5a1IeQy4VffyBKH/Y877hIOjQt/I4P+vVXlo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300297; c=relaxed/simple; bh=F8Ybvyi6GeD2bc1+/+CcnyLiv8/CjxRPhCgmqh0qwCI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TVlyBsdkMbwsxhwb2pz0u46D4gfy5XhxBAei3yURKMcKz/v357w44MRUDdZuwUZPkJEiSsNIJS5a7cQXXlz3g0v6AgnVknGX0eIqv5WEv6dWVlqs3d62HF8gxkH52LeoTm7BxmJZOlb4meclhy5+a13Fyh/L5LXedHlYNpkKNQs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qhvssaVk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qhvssaVk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E41C7C2BC9E; Sat, 28 Feb 2026 17:38:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300297; bh=F8Ybvyi6GeD2bc1+/+CcnyLiv8/CjxRPhCgmqh0qwCI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qhvssaVkSq6cmcrVk5D/2JjJgdUSzVJhrx8MfS50PqTIMF0xxuKxnlZCQRzXn+7tT PmubXykSLaq1ugU+8qXx30LyuCnpJHuouT9nuN8XFhsWeK5tiJhK4upLclqChdJj++ EimfOymextc33t1XtuMtWNu6Boon5ObNAgqpImav1/dr4g5tJGPSNgw0VOWVMo8dZx p2eQbB7w58NZSzoy9biJH4mT/FVdkgQPDStXT0E+2sr/JUoYSmXsNopPmYHf1mLpqM lOBpdWpse0VbJB/JdsMKfQ8n17SBMW9lYZNeHayAgPC4ow90vaBX9IH9UiCzyapckc ezcFC1DBVSLlg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Woodhouse , Babis Chalios , Takahiro Itazuri , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 327/844] ptp: ptp_vmclock: add 'VMCLOCK' to ACPI device match Date: Sat, 28 Feb 2026 12:24:00 -0500 Message-ID: <20260228173244.1509663-328-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Woodhouse [ Upstream commit ed4d23ed469ca14d47670c0384f6ae6c4ff060a5 ] As we finalised the spec, we spotted that vmgenid actually says that the _HID is supposed to be hypervisor-specific. Although in the 13 years since the original vmgenid doc was published, nobody seems to have cared about using _HID to distinguish between implementations on different hypervisors, and we only ever use the _CID. For consistency, match the _CID of "VMCLOCK" too. Signed-off-by: David Woodhouse Signed-off-by: Babis Chalios Tested-by: Takahiro Itazuri Link: https://patch.msgid.link/20260130173704.12575-6-itazur@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/ptp/ptp_vmclock.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/ptp/ptp_vmclock.c b/drivers/ptp/ptp_vmclock.c index b3a83b03d9c14..cbbfc494680c7 100644 --- a/drivers/ptp/ptp_vmclock.c +++ b/drivers/ptp/ptp_vmclock.c @@ -591,6 +591,7 @@ static int vmclock_probe(struct platform_device *pdev) =20 static const struct acpi_device_id vmclock_acpi_ids[] =3D { { "AMZNC10C", 0 }, + { "VMCLOCK", 0 }, {} }; MODULE_DEVICE_TABLE(acpi, vmclock_acpi_ids); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF93E3AE0FF; Sat, 28 Feb 2026 17:38:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300298; cv=none; b=YH/kggDo21Y1laS41i8pree3tDUXItwZbUHyrn7mS0d6n2lwk8g1I2DYzP3+Bl/hokStWSCfeavWVd9nXvj/3nnCU0smZ2nCkEwTTcJKUKiWR0TutQMI+lEn4pH/CVkwtYmIDbrjcKz9B4DV5yyeegqyyYshWO799nWx9kadrBU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300298; c=relaxed/simple; bh=waZC0sqlFxLnN6MicwwPXP13l/tZFkfFMAngKrbv+pk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mwEwd6NOEpoYwNKUk+1pUIzLA6fg8e8uF+YFCf6Gq+PhvAZ8I0ufH/pocCU1sdUr3B4ZoKRWI+/DZn8gtTVr1vjZMUhvjYq8Kzp776JJEf1jdp1evKO8DkvYrIZUiFlTNriqJmLWO0K1yHl3YLa6RQYEjtKBN0w80SQQM44Fhh8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Pku0/fjo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Pku0/fjo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB679C19425; Sat, 28 Feb 2026 17:38:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300298; bh=waZC0sqlFxLnN6MicwwPXP13l/tZFkfFMAngKrbv+pk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Pku0/fjoIb85F2s9ykB4KzZMnG1PLEe+BKTqi9LRK0dyoNLsz+vQ/7Wjtiv8fxbGV ml03rX7oZ5MBkYPIRP4Po8zhT4hi691hcOtS/Gpe/CfQ59RRSm3B0ojgifRrd7UAQa bzJFoiXeLuz6llfqJg9qNFDfmA33lcqDrBk8dt/2pDGwaXKP9J/dCIKpC+to29lMxN ZBGd9ggpxQnOQVeXJwYFPauU06W/kPYGAVxhkIgfU9sDxZhFeIG1ad4WrOn78rE/LM B/OyQHykbiDnqqUatzmgSQdl5uVPyOvO4VDu+oRQ1Avtcw7OgcEnjqTSNF11BO0VbQ IM7xfjxbrdY4w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Nelson-Moore , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 328/844] net: usb: sr9700: remove code to drive nonexistent multicast filter Date: Sat, 28 Feb 2026 12:24:01 -0500 Message-ID: <20260228173244.1509663-329-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Nelson-Moore [ Upstream commit 9a9424c756feee9ee6e717405a9d6fa7bacdef08 ] Several registers referenced in this driver's source code do not actually exist (they are not writable and read as zero in my testing). They exist in this driver because it originated as a copy of the dm9601 driver. Notably, these include the multicast filter registers - this causes the driver to not support multicast packets correctly. Remove the multicast filter code and register definitions. Instead, set the chip to receive all multicast filter packets when any multicast addresses are in the list. Reviewed-by: Simon Horman (from v1) Signed-off-by: Ethan Nelson-Moore Link: https://patch.msgid.link/20260203013924.28582-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/usb/Kconfig | 1 - drivers/net/usb/sr9700.c | 25 ++++--------------------- drivers/net/usb/sr9700.h | 7 +------ 3 files changed, 5 insertions(+), 28 deletions(-) diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index 856e648d804e0..da0f6a138f4fc 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -319,7 +319,6 @@ config USB_NET_DM9601 config USB_NET_SR9700 tristate "CoreChip-sz SR9700 based USB 1.1 10/100 ethernet devices" depends on USB_USBNET - select CRC32 help This option adds support for CoreChip-sz SR9700 based USB 1.1 10/100 Ethernet adapters. diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c index 820c4c5069792..a5d364fbc3639 100644 --- a/drivers/net/usb/sr9700.c +++ b/drivers/net/usb/sr9700.c @@ -18,7 +18,6 @@ #include #include #include -#include #include =20 #include "sr9700.h" @@ -265,31 +264,15 @@ static const struct ethtool_ops sr9700_ethtool_ops = =3D { static void sr9700_set_multicast(struct net_device *netdev) { struct usbnet *dev =3D netdev_priv(netdev); - /* We use the 20 byte dev->data for our 8 byte filter buffer - * to avoid allocating memory that is tricky to free later - */ - u8 *hashes =3D (u8 *)&dev->data; /* rx_ctl setting : enable, disable_long, disable_crc */ u8 rx_ctl =3D RCR_RXEN | RCR_DIS_CRC | RCR_DIS_LONG; =20 - memset(hashes, 0x00, SR_MCAST_SIZE); - /* broadcast address */ - hashes[SR_MCAST_SIZE - 1] |=3D SR_MCAST_ADDR_FLAG; - if (netdev->flags & IFF_PROMISC) { + if (netdev->flags & IFF_PROMISC) rx_ctl |=3D RCR_PRMSC; - } else if (netdev->flags & IFF_ALLMULTI || - netdev_mc_count(netdev) > SR_MCAST_MAX) { - rx_ctl |=3D RCR_RUNT; - } else if (!netdev_mc_empty(netdev)) { - struct netdev_hw_addr *ha; - - netdev_for_each_mc_addr(ha, netdev) { - u32 crc =3D ether_crc(ETH_ALEN, ha->addr) >> 26; - hashes[crc >> 3] |=3D 1 << (crc & 0x7); - } - } + else if (netdev->flags & IFF_ALLMULTI || !netdev_mc_empty(netdev)) + /* The chip has no multicast filter */ + rx_ctl |=3D RCR_ALL; =20 - sr_write_async(dev, SR_MAR, SR_MCAST_SIZE, hashes); sr_write_reg_async(dev, SR_RCR, rx_ctl); } =20 diff --git a/drivers/net/usb/sr9700.h b/drivers/net/usb/sr9700.h index ea2b4de621c86..c479908f7d823 100644 --- a/drivers/net/usb/sr9700.h +++ b/drivers/net/usb/sr9700.h @@ -104,9 +104,7 @@ #define WCR_LINKEN (1 << 5) /* Physical Address Reg */ #define SR_PAR 0x10 /* 0x10 ~ 0x15 6 bytes for PAR */ -/* Multicast Address Reg */ -#define SR_MAR 0x16 /* 0x16 ~ 0x1D 8 bytes for MAR */ -/* 0x1e unused */ +/* 0x16 --> 0x1E unused */ /* Phy Reset Reg */ #define SR_PRR 0x1F #define PRR_PHY_RST (1 << 0) @@ -161,9 +159,6 @@ /* parameters */ #define SR_SHARE_TIMEOUT 1000 #define SR_EEPROM_LEN 256 -#define SR_MCAST_SIZE 8 -#define SR_MCAST_ADDR_FLAG 0x80 -#define SR_MCAST_MAX 64 #define SR_TX_OVERHEAD 2 /* 2bytes header */ #define SR_RX_OVERHEAD 7 /* 3bytes header + 4crc tail */ =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0BECA3AF380; Sat, 28 Feb 2026 17:38:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300300; cv=none; b=SHUFOX2pMGQs8i7Pp8zSsXpNfDkSbbQ8MxvOSiWKnPXG1tK7zYWjecmBcoH0Ea13ZBIQBHKFZDpiMXfsyn5rYoB4T9JFcF5ky273EyGYQ5oqgUwP9QJOprlDos/tvQPedTU82LplzF+ZqKxf7SS6MMJdRJVE7FPl5ckvricwNfQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300300; c=relaxed/simple; bh=cpgrSgAkJnKPCIz0KN2av2PGQbA/IqX1Sa5PRbhWHEg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cNfu2eXcvhKfXBpSkabBriFBQfDccLjNu14hxPGvv1JjZYHwy0gCotnoAYWj64T1p1IOpfQsmcAu5plftVfa0AGbWvAb8XB3CThxXmHjWF2DXWLitn2t89Xxs7WEt3B01BkOoPfKpcz/g9SiRBqM0mT3h9G/5H3JFpVKKZr9CHE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qaBXCobQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qaBXCobQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D63AEC116D0; Sat, 28 Feb 2026 17:38:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300299; bh=cpgrSgAkJnKPCIz0KN2av2PGQbA/IqX1Sa5PRbhWHEg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qaBXCobQSqi5aj/zbV9lHB4uZnFU7zoKtUTGboABiRkvF/pf09+tZSZqLNOjk936f 6asvcNwOezqcS6xzRqsU9KNd2gdPSlloSru1P6CIwNfFvbcH6t62qNUOd9AMtrLyaW EteMU4Am19miYNgpHWmvd95cgTFsY/M8SCxd9xPm+i6Tibz574k5zrVESI0n0uTpHM +8N5e7rTDKDKZCI94M1EkNe/O5OgXrKy2loSOZTar8iEctgZ4dCd2y5dzuEhf8aIDl YP5MpOREGmmI7owA66sRKJBJJmB/hSoRbPplasMf+TN/hlPBOxZ2a2tP7cqtcLuMwB e/CMPeIacKZ0w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnd Bergmann , Bobby Eshleman , Stefano Garzarella , Bryan Tan , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 329/844] vmw_vsock: bypass false-positive Wnonnull warning with gcc-16 Date: Sat, 28 Feb 2026 12:24:02 -0500 Message-ID: <20260228173244.1509663-330-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann [ Upstream commit e25dbf561e03c0c5e36228e3b8b784392819ce85 ] The gcc-16.0.1 snapshot produces a false-positive warning that turns into a build failure with CONFIG_WERROR: In file included from arch/x86/include/asm/string.h:6, from net/vmw_vsock/vmci_transport.c:10: In function 'vmci_transport_packet_init', inlined from '__vmci_transport_send_control_pkt.constprop' at net/vmw_v= sock/vmci_transport.c:198:2: arch/x86/include/asm/string_32.h:150:25: error: argument 2 null where non-n= ull expected because argument 3 is nonzero [-Werror=3Dnonnull] 150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ arch/x86/include/asm/string_32.h:150:25: note: in a call to built-in functi= on '__builtin_memcpy' net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ This seems relatively harmless, and it so far the only instance of this warning I have found. The __vmci_transport_send_control_pkt function is called either with wait=3DNULL or with one of the type values that pass 'wait' into memcpy() here, but not from the same caller. Replacing the memcpy with a struct assignment is otherwise the same but avoids the warning. Signed-off-by: Arnd Bergmann Reviewed-by: Bobby Eshleman Reviewed-by: Stefano Garzarella Reviewed-by: Bryan Tan Link: https://patch.msgid.link/20260203163406.2636463-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/vmw_vsock/vmci_transport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c index 7eccd6708d664..aca3132689cf1 100644 --- a/net/vmw_vsock/vmci_transport.c +++ b/net/vmw_vsock/vmci_transport.c @@ -161,7 +161,7 @@ vmci_transport_packet_init(struct vmci_transport_packet= *pkt, =20 case VMCI_TRANSPORT_PACKET_TYPE_WAITING_READ: case VMCI_TRANSPORT_PACKET_TYPE_WAITING_WRITE: - memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); + pkt->u.wait =3D *wait; break; =20 case VMCI_TRANSPORT_PACKET_TYPE_REQUEST2: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6D253AF395; Sat, 28 Feb 2026 17:38:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300300; cv=none; b=lg8VEhY/1kV6uyM5k9O3XVC8mNf0teDyxOA/csH1tS2WRqnUTxRBWN4bzHgatEnMGUwZHgp7NyEO4D2LXWnxGzETsnZy5x3qMh2kFFJ/czYtRLexOQnQtE+kpp32geSmaCm0bZYYlFFKwy9TBYp6zv6ep9SN32QgAS0lc9tv7C0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300300; c=relaxed/simple; bh=7ozLu9srNkLFIb6bnDfwaHxmOfjHap/v3IqrRMFdmy0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QVvFuQtT+tydUvRJqNhHHBo+Fpo/0ADect7dtx7MyIXl+Z4rQ4Dsqg0DrC9/dOhWiK2neQJSapGngKvmJn0omufOizItRrckmWw9wSIKYXby7cj6yLoYmCjbJz8Ddln44a/bLQu3fw2unfUxN+UJzRZBBzSR3wTZapes5BiXws8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZK+F8Ju0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZK+F8Ju0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1D90C19423; Sat, 28 Feb 2026 17:38:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300300; bh=7ozLu9srNkLFIb6bnDfwaHxmOfjHap/v3IqrRMFdmy0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZK+F8Ju0XiXZnVMy8dGTcOLTwcBoTXDkVmNvtuA0ovHLkzTU6o12bFVo3dOfBDLbE oQNc8hrVZCoLNisnj/oY/tIshWd6+Zyi/KSBwom7inr7N+GDZLolsqTZsPHS3Nz6o7 gQZwXf8DzQMiH8YI7KRXLyJTptouUoWr+0G2HUFG0ZFUxvGGHnE9rwZaC7oEJy0Ff2 cFZcDzBko2ICvTDOevQbSu+A9uwBsQZ6NHxEEIrSp9ae7wWnfLut4phzLIbsxDkTgn AetZ3BanGZqxYdzXdWmxclv0/bFywv0DvdsAl2Quzut9irFZn+hJu+Hp/PWCUovx5A fB+NTiXIdJ8Wg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?H=C3=A5kon=20Bugge?= , Allison Henderson , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 330/844] net/rds: Clear reconnect pending bit Date: Sat, 28 Feb 2026 12:24:03 -0500 Message-ID: <20260228173244.1509663-331-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: H=C3=A5kon Bugge [ Upstream commit b89fc7c2523b2b0750d91840f4e52521270d70ed ] When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever. Signed-off-by: H=C3=A5kon Bugge Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260203055723.1085751-6-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/rds/connection.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/rds/connection.c b/net/rds/connection.c index ad8027e6f54ef..dbfea6fa11260 100644 --- a/net/rds/connection.c +++ b/net/rds/connection.c @@ -429,6 +429,8 @@ void rds_conn_shutdown(struct rds_conn_path *cp) * to the conn hash, so we never trigger a reconnect on this * conn - the reconnect is always triggered by the active peer. */ cancel_delayed_work_sync(&cp->cp_conn_w); + + clear_bit(RDS_RECONNECT_PENDING, &cp->cp_flags); rcu_read_lock(); if (!hlist_unhashed(&conn->c_hash_node)) { rcu_read_unlock(); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AB9343AF3B0; Sat, 28 Feb 2026 17:38:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300301; cv=none; b=kMAsZnsF+QE0KrQl4l0r8WLAAk6DKhsOq7OYRWAlrawa1eV9XBpC7Ps6otXD7qGPv30rKiqvxQgQ+aD4hKqO4Wfat/bFz/2TXYVdZMr4fGRSeedvqy5QDnZb143M9eT7c40gVGa3F3g10SLUj+KALxiGzAHGLZ++a8cjBwLfPkE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300301; c=relaxed/simple; bh=/OMTTSzkMuyg7MouPley8iAmlYs+K6zFTS1Ol+cCZYk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d9zGrJiADaJrt5GmNtbONbY6hWd3Dekkep697XWQBm4NVZQxCSUwPY/135s5BmOqU+zO5dkN2gcR5EEF4LXcECRddr0iI5rAVXGamn/JTNibx0aVCmjQvNuVn3znv+tRc1gUaQ+3ZgrGRvP2FI/rSqK8eLvBUq9lctNUjStVjy4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OW9WPEVK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OW9WPEVK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4316C19424; Sat, 28 Feb 2026 17:38:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300301; bh=/OMTTSzkMuyg7MouPley8iAmlYs+K6zFTS1Ol+cCZYk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OW9WPEVKr6M0AVfmYKGZko06nFeSAVFqDPVzboukrLmUnbK420XyDClDJYAkdwMi5 AU5gsC43wQQYPR/sLx+YbDCCScxacH5utyUP1ETIWrU29aR0zX7lC2g+MU2EcCNAu7 xwrY+Z4F8eeFxjgOVPh+qY1BoHUwVyxKbycngooVj+OgkjaNWIpqtJniqvaMJa2aKo wLwNuSW624tlnDLeqN4dMhcQLzGla2qalZ2oVjp8xiWWohqmt0nB7V5nWRT5AHQGPc U0qtsPpquagdqfhaxjROV+2z6Z2/Pu4dytw1tixctEniynJXzagG5EtStm6poTW2Hh uUFxgHlv5G2vw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alex Williamson , Patrick Bianchi , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.19 331/844] PCI: Mark ASM1164 SATA controller to avoid bus reset Date: Sat, 28 Feb 2026 12:24:04 -0500 Message-ID: <20260228173244.1509663-332-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alex Williamson [ Upstream commit beb2f81792a8a619e5122b6b24a374861309c54b ] User forums report issues when assigning ASM1164 SATA controllers to VMs, especially in configurations with multiple controllers. Logs show the device fails to retrain after bus reset. Reports suggest this is an issue across multiple platforms. The device indicates support for PM reset, therefore the device still has a viable function level reset mechanism. The reporting user confirms the device is well behaved in this use case with bus reset disabled. Reported-by: Patrick Bianchi Link: https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with= -two-identical-devices.149003/ Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260109000211.398300-1-alex.williamson@nvid= ia.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/quirks.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6df78efd7f6dc..538ad85cf7c30 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3791,6 +3791,16 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CAVIUM, 0xa10= 0, quirk_no_bus_reset); */ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TI, 0xb005, quirk_no_bus_reset); =20 +/* + * Reports from users making use of PCI device assignment with ASM1164 + * controllers indicate an issue with bus reset where the device fails to + * retrain. The issue appears more common in configurations with multiple + * controllers. The device does indicate PM reset support (NoSoftRst-), + * therefore this still leaves a viable reset method. + * https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with-t= wo-identical-devices.149003/ + */ +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ASMEDIA, 0x1164, quirk_no_bus_reset= ); + static void quirk_no_pm_reset(struct pci_dev *dev) { /* --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B6F483AFC83; Sat, 28 Feb 2026 17:38:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300302; cv=none; b=Aj0wSSUgZhxigou1xilqCL4Ihw3Dn/sbLSVDY4d9oe9jtVYA+WFYtPDqWI5qr/BWsn2Wz71C660/NNpiht0FtI4iZhlaJ7qRHyfFrHy896qQNsvmLxWleLH1FzgkTiP5scWK5E/s0D7wT0pvWUSte9a2AJdqt88UPthBIYGc8Js= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300302; c=relaxed/simple; bh=aijcopGcMNf6ly7LHvyf+1Uvz3pVBrbpfk0/UQrYOxA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EBPDObifBquJjKzWRgcUwx0rdS47JMrxEi/uGRFrlqt//Dej2VK46sj8Bx0jWOQKvT1no4lgsWqTkwkrEzGWLOfCOP/3/6sHTmAYqrldd4eoxIFCsOPNlbyUSElCVkta3zmR+J+VTE9hxo8fAimuWJ6V/OwGSpa8UA0iAxUD5aM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OyzPMp8D; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OyzPMp8D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D318CC19425; Sat, 28 Feb 2026 17:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300302; bh=aijcopGcMNf6ly7LHvyf+1Uvz3pVBrbpfk0/UQrYOxA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OyzPMp8D4IfARa8TYDHCN6rTk+tzQ5Ce+UHH8mbC4W8CLTefiLHC/EeJXJWBjsojl Xy5n33eMagxlBTWrQLS/emkm0367RaJ8UsLX+Y1DPp+s3D+s6s/pScPXvDfkuutve6 zI4/m4s/rkAgArGVm/y9jd/oiYwF/2494mGUxT/VqKJjtEBWwVMadgVjOGdGGmNWbS rqQ/nc0iVl67089mpwzpVTshKtkuu3yJxYk3QNe8dcjC/MnLWJcgDbKXImDsqPQ1LA FXVqg5NnOaIRX8L4TotO+7+b+uMMrz35SAz4KgvAYEC7a0zDnIYYIGhVCnR9DtRckN qkxjZZ4kbT8gQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lukas Wunner , Lucas Van , Bjorn Helgaas , Kuppuswamy Sathyanarayanan , Sasha Levin Subject: [PATCH 6.19 332/844] PCI/AER: Clear stale errors on reporting agents upon probe Date: Sat, 28 Feb 2026 12:24:05 -0500 Message-ID: <20260228173244.1509663-333-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lukas Wunner [ Upstream commit e242d09b58e869f86071b7889acace4cff215935 ] Correctable and Uncorrectable Error Status Registers on reporting agents are cleared upon PCI device enumeration in pci_aer_init() to flush past events. They're cleared again when an error is handled by the AER driver. If an agent reports a new error after pci_aer_init() and before the AER driver has probed on the corresponding Root Port or Root Complex Event Collector, that error is not handled by the AER driver: It clears the Root Error Status Register on probe, but neglects to re-clear the Correctable and Uncorrectable Error Status Registers on reporting agents. The error will eventually be reported when another error occurs. Which is irritating because to an end user it appears as if the earlier error has just happened. Amend the AER driver to clear stale errors on reporting agents upon probe. Skip reporting agents which have not invoked pci_aer_init() yet to avoid using an uninitialized pdev->aer_cap. They're recognizable by the error bits in the Device Control register still being clear. Reporting agents may execute pci_aer_init() after the AER driver has probed, particularly when devices are hotplugged or removed/rescanned via sysfs. For this reason, it continues to be necessary that pci_aer_init() clears Correctable and Uncorrectable Error Status Registers. Reported-by: Lucas Van # off-list Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Lucas Van Reviewed-by: Kuppuswamy Sathyanarayanan Link: https://patch.msgid.link/3011c2ed30c11f858e35e29939add754adea7478.176= 9332702.git.lukas@wunner.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/pcie/aer.c | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c index 9472d86cef552..73cb6d587202c 100644 --- a/drivers/pci/pcie/aer.c +++ b/drivers/pci/pcie/aer.c @@ -1605,6 +1605,20 @@ static void aer_disable_irq(struct pci_dev *pdev) pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32); } =20 +static int clear_status_iter(struct pci_dev *dev, void *data) +{ + u16 devctl; + + /* Skip if pci_enable_pcie_error_reporting() hasn't been called yet */ + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &devctl); + if (!(devctl & PCI_EXP_AER_FLAGS)) + return 0; + + pci_aer_clear_status(dev); + pcie_clear_device_status(dev); + return 0; +} + /** * aer_enable_rootport - enable Root Port's interrupts when receiving mess= ages * @rpc: pointer to a Root Port data structure @@ -1626,9 +1640,19 @@ static void aer_enable_rootport(struct aer_rpc *rpc) pcie_capability_clear_word(pdev, PCI_EXP_RTCTL, SYSTEM_ERROR_INTR_ON_MESG_MASK); =20 - /* Clear error status */ + /* Clear error status of this Root Port or RCEC */ pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_STATUS, ®32); pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_STATUS, reg32); + + /* Clear error status of agents reporting to this Root Port or RCEC */ + if (reg32 & AER_ERR_STATUS_MASK) { + if (pci_pcie_type(pdev) =3D=3D PCI_EXP_TYPE_RC_EC) + pcie_walk_rcec(pdev, clear_status_iter, NULL); + else if (pdev->subordinate) + pci_walk_bus(pdev->subordinate, clear_status_iter, + NULL); + } + pci_read_config_dword(pdev, aer + PCI_ERR_COR_STATUS, ®32); pci_write_config_dword(pdev, aer + PCI_ERR_COR_STATUS, reg32); pci_read_config_dword(pdev, aer + PCI_ERR_UNCOR_STATUS, ®32); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD6EC3AFCA0; Sat, 28 Feb 2026 17:38:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300303; cv=none; b=K0zEI1GpAxqL23xDrZpfIf3Cf6bIsjCxBC7w367WngQWzwnb4jKgrnnOQxSqPh6ZVc3o1KA5JSmfAFM42t9Op4WLR+zjJ/v/P5CmtelwSGd2cYV4++B85XMFVULswUQ26vTZMeLDhG/P8e2w6ijgxAxLos7xBVwf4iSF1MC3XCM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300303; c=relaxed/simple; bh=v1LRChWIMI4mPhTCvMHCwHNjuYm7ObE7BiiAy/dqxkM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VPwHp9KIGE3x/th3USouaVzv7TYD3bRJuPQY6TLqgrH+tU25fQfesMbLJ+h09RyYxLSC8OjtF31p+RHojWkPBId0cSlYY95cBblJYHvI7gbkI6LMRiddbfWq9NbZjluqeNv/mxUQqsQsyYck9hVdG+MtLQTwf3zpn2KwSDE+usw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QjsbxKv+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QjsbxKv+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCC0FC116D0; Sat, 28 Feb 2026 17:38:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300303; bh=v1LRChWIMI4mPhTCvMHCwHNjuYm7ObE7BiiAy/dqxkM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QjsbxKv+X+s4y2ePrm77HSR3Xz+eVE2DaANQIvOhGmc0NCru3ZjZ5MDk20zEMJO+P p0Y2FPyskSPzhzk5PByYei7BUn2TUcyvAqYbnCoLpYcc2bf2fM5KXe1jtefN3gQxnR pFYrFS+I24wMAlcMigQQBs7eTZmuNkT9a4Ak3P7XBFh0OIZdvuUQehxrLNFuisNNk7 ejNBGQ6+rxwFpp35NtQZiiSis1C1aoCMcdv6n8xsuYlOmaYiC2qN4hg2jyYrJh6jbb lAWK0XtpGKFjBrUn++KzMnZPdbmDuYqAwHGEmGE7c7aFV1S9prU+PHsU2Qz7DDt+0e L9oYYeatabhgA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Keith Busch , Bjorn Helgaas , Dan Williams , Sasha Levin Subject: [PATCH 6.19 333/844] PCI: Fix pci_slot_lock () device locking Date: Sat, 28 Feb 2026 12:24:06 -0500 Message-ID: <20260228173244.1509663-334-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Keith Busch [ Upstream commit 1f5e57c622b4dc9b8e7d291d560138d92cfbe5bf ] Like pci_bus_lock(), pci_slot_lock() needs to lock the bridge device to prevent warnings like: pcieport 0000:e2:05.0: unlocked secondary bus reset via: pciehp_reset_slo= t+0x55/0xa0 Take and release the lock for the bridge providing the slot for the lock/trylock and unlock routines. Signed-off-by: Keith Busch Signed-off-by: Bjorn Helgaas Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260130165953.751063-3-kbusch@meta.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/pci.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index a05978f5cf2c7..41596bc72f1dc 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -5293,10 +5293,9 @@ static int pci_bus_trylock(struct pci_bus *bus) /* Do any devices on or below this slot prevent a bus reset? */ static bool pci_slot_resettable(struct pci_slot *slot) { - struct pci_dev *dev; + struct pci_dev *dev, *bridge =3D slot->bus->self; =20 - if (slot->bus->self && - (slot->bus->self->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET)) + if (bridge && (bridge->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET)) return false; =20 list_for_each_entry(dev, &slot->bus->devices, bus_list) { @@ -5313,7 +5312,10 @@ static bool pci_slot_resettable(struct pci_slot *slo= t) /* Lock devices from the top of the tree down */ static void pci_slot_lock(struct pci_slot *slot) { - struct pci_dev *dev; + struct pci_dev *dev, *bridge =3D slot->bus->self; + + if (bridge) + pci_dev_lock(bridge); =20 list_for_each_entry(dev, &slot->bus->devices, bus_list) { if (!dev->slot || dev->slot !=3D slot) @@ -5328,7 +5330,7 @@ static void pci_slot_lock(struct pci_slot *slot) /* Unlock devices from the bottom of the tree up */ static void pci_slot_unlock(struct pci_slot *slot) { - struct pci_dev *dev; + struct pci_dev *dev, *bridge =3D slot->bus->self; =20 list_for_each_entry(dev, &slot->bus->devices, bus_list) { if (!dev->slot || dev->slot !=3D slot) @@ -5338,12 +5340,18 @@ static void pci_slot_unlock(struct pci_slot *slot) else pci_dev_unlock(dev); } + + if (bridge) + pci_dev_unlock(bridge); } =20 /* Return 1 on successful lock, 0 on contention */ static int pci_slot_trylock(struct pci_slot *slot) { - struct pci_dev *dev; + struct pci_dev *dev, *bridge =3D slot->bus->self; + + if (bridge && !pci_dev_trylock(bridge)) + return 0; =20 list_for_each_entry(dev, &slot->bus->devices, bus_list) { if (!dev->slot || dev->slot !=3D slot) @@ -5368,6 +5376,9 @@ static int pci_slot_trylock(struct pci_slot *slot) else pci_dev_unlock(dev); } + + if (bridge) + pci_dev_unlock(bridge); return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD2523AFCB7; Sat, 28 Feb 2026 17:38:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300304; cv=none; b=k+F77sIO1zEhwQXsnlDX4N9AlARY6jtfGfbkqUag4/nCMaE9mzMTAnQ/ARE9/zNWlBrM4vF8DCQNFQI/aEzKN8DBv6e4z4Puwwg7scsxnhyNZrpv1w/D2RxvupuinO5QlLn+Kz8tekOVIFAKL9Vzy5iY7d1bHeoOsb/bvzP+7c8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300304; c=relaxed/simple; bh=GdWWcZDRSvnIM3rqIhAKkzmXIVXNAl+m2KMx6notem4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B/83F1CEgejDUdWHIqSbIfextPVeWAGX4YqHJpFWXtamcotbCCOFLpoxbUapOR3iaSpkcxE4kCMgCmi9lbwCpM3OYzsrwx3g+Y1b2gidKaS50iJKiGIxS455qu1+LfrZtGWgpmziMQL4TtIoEow9zUV101e/mZbcXlKi/TwmyVM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=J9Xv2qZg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="J9Xv2qZg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC69BC19425; Sat, 28 Feb 2026 17:38:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300304; bh=GdWWcZDRSvnIM3rqIhAKkzmXIVXNAl+m2KMx6notem4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=J9Xv2qZgpWFLuM7Ev4yFseYSTlrz9D9Ro01ZKzPHRdKc251KQG/LH2HfW/Mrx65Tf 5CRGTyI5RQq1pfAF3G51djBXoHqWgmt8a0+a/eIxVEHztbwlfVWW0cPrzYgr6bo8Mf 89DGuNnATA75BQrrlN3+rTexcfXrRhse7+zLkJBTDTZkFiwVHVLjsuJMSXdxe3S7Q4 bxlgj55se0UuCCzWIfAoGS7ZwPH1ZViO/gQEU2XyshRLfEUluQS+rx4arlfrMFNDPW BzCxAIQ0EhRdBSkSp6ipGsiifBoG29P+Nq1rJXMbXu+39ZT0H7H+er91lA1zqyV5Sf w7DJf5BUx64TA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Manivannan Sadhasivam , Bjorn Helgaas , Marek Szyprowski , Naresh Kamboju , Sasha Levin Subject: [PATCH 6.19 334/844] PCI: Enable ACS after configuring IOMMU for OF platforms Date: Sat, 28 Feb 2026 12:24:07 -0500 Message-ID: <20260228173244.1509663-335-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Manivannan Sadhasivam [ Upstream commit c41e2fb67e26b04d919257875fa954aa5f6e392e ] Platform, ACPI, or IOMMU drivers call pci_request_acs(), which sets 'pci_acs_enable' to request that ACS be enabled for any devices enumerated in the future. OF platforms called pci_enable_acs() for the first device before of_iommu_configure() called pci_request_acs(), so ACS was never enabled for that device (typically a Root Port). Call pci_enable_acs() later, from pci_dma_configure(), after of_dma_configure() has had a chance to call pci_request_acs(). Here's the call path, showing the move of pci_enable_acs() from pci_acs_init() to pci_dma_configure(), where it always happens after pci_request_acs(): pci_device_add pci_init_capabilities pci_acs_init - pci_enable_acs - if (pci_acs_enable) <-- previous test - ... device_add bus_notify(BUS_NOTIFY_ADD_DEVICE) iommu_bus_notifier iommu_probe_device iommu_init_device dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure of_dma_configure of_iommu_configure pci_request_acs pci_acs_enable =3D 1 <-- set + pci_enable_acs + if (pci_acs_enable) <-- new test + ... bus_probe_device device_initial_probe ... really_probe dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure ... pci_enable_acs Note that we will now call pci_enable_acs() twice for every device, first from the iommu_probe_device() path and again from the really_probe() path. Presumably that's not an issue since we also call dev->bus->dma_configure() twice. For the ACPI platforms, pci_request_acs() is called during ACPI initialization time itself, independent of the IOMMU framework. Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Tested-by: Marek Szyprowski Tested-by: Naresh Kamboju Link: https://patch.msgid.link/20260102-pci_acs-v3-1-72280b94d288@oss.qualc= omm.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/pci-driver.c | 8 ++++++++ drivers/pci/pci.c | 10 +--------- drivers/pci/pci.h | 1 + 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 7c2d9d5962586..301a9418e38e0 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -1650,6 +1650,14 @@ static int pci_dma_configure(struct device *dev) ret =3D acpi_dma_configure(dev, acpi_get_dma_attr(adev)); } =20 + /* + * Attempt to enable ACS regardless of capability because some Root + * Ports (e.g. those quirked with *_intel_pch_acs_*) do not have + * the standard ACS capability but still support ACS via those + * quirks. + */ + pci_enable_acs(to_pci_dev(dev)); + pci_put_host_bridge_device(bridge); =20 /* @drv may not be valid when we're called from the IOMMU layer */ diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 41596bc72f1dc..f21f6933c9b63 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1015,7 +1015,7 @@ static void pci_std_enable_acs(struct pci_dev *dev, s= truct pci_acs *caps) * pci_enable_acs - enable ACS if hardware support it * @dev: the PCI device */ -static void pci_enable_acs(struct pci_dev *dev) +void pci_enable_acs(struct pci_dev *dev) { struct pci_acs caps; bool enable_acs =3D false; @@ -3651,14 +3651,6 @@ bool pci_acs_path_enabled(struct pci_dev *start, void pci_acs_init(struct pci_dev *dev) { dev->acs_cap =3D pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ACS); - - /* - * Attempt to enable ACS regardless of capability because some Root - * Ports (e.g. those quirked with *_intel_pch_acs_*) do not have - * the standard ACS capability but still support ACS via those - * quirks. - */ - pci_enable_acs(dev); } =20 /** diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 36f32b8af6ab3..ecc67fbb159c4 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -957,6 +957,7 @@ static inline resource_size_t pci_resource_alignment(st= ruct pci_dev *dev, } =20 void pci_acs_init(struct pci_dev *dev); +void pci_enable_acs(struct pci_dev *dev); #ifdef CONFIG_PCI_QUIRKS int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags); int pci_dev_specific_enable_acs(struct pci_dev *dev); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E0093B0940; Sat, 28 Feb 2026 17:38:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300305; cv=none; b=rFOgC2Ew7iBSZXOWlulSnQY4kKkvYHFczO1rOwss2eGycYbgDNG7YiaapAM8zSHcOJnO6/TPbN4eWxUbIX1mMVe3wjJyPWOpPNpxDAw8s13fxcZzsmS/H0BdSOsMU5gyghhjR7jFSjIpXI0aEJrmK880Vdhu7xWxxKIM+9TdGv8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300305; c=relaxed/simple; bh=ATjiF+y6xyZCncjOO7dsiQtE8pP3E5WtbNbJ8vK1yTw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tJ1QuchWN0m9iewHPpDUYePSbbw2uEl4+o07tN7Wa4OCKkY3FW/M3utuyLL6rO5rPy2ikCmEm+pNxojtvLE3+ZuFLj33Pd5CzZhsCodDSIP27yqC+aFfxmoMB794z+tJNHieTPMkdf+lopBgYTZoREa5GPnoVThHORU1FRNpxRU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LOmZZ+XD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LOmZZ+XD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D75D8C19423; Sat, 28 Feb 2026 17:38:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300305; bh=ATjiF+y6xyZCncjOO7dsiQtE8pP3E5WtbNbJ8vK1yTw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LOmZZ+XDlEQ8EVD/PP6MjGk5sr0v5J3HYxoKMnJLLQfcAopBunu0PqLJC0aAWPIdK gyLiwJgcMvv+hh06ymSy882q09BScq2zyDcDCepiTRJOBciWR1sAGj2xsXuVFzKPKk f9pP4rrHyHEgRbK31gub75g1O50UCInneOG9ui++jROO8FuBt6HUQ3fYwgj1o8JG8L eZKCNdBAhIE1wKFxBNzCi3GUEpuXss3j8rRNroX0uYig85oePKkr7gVBdnxzNi1wKr 9NyyS8j/F8V1efDfJq9zMk+u5y6Vz7+hUxbAri4liADQYIjSJw8WaBIYhkFax6w00L xykXCbU4mr1GA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Krishna Chaitanya Chundru , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.19 335/844] PCI: Add ACS quirk for Qualcomm Hamoa & Glymur Date: Sat, 28 Feb 2026 12:24:08 -0500 Message-ID: <20260228173244.1509663-336-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Krishna Chaitanya Chundru [ Upstream commit 44d2f70b1fd72c339c72983fcffa181beae3e113 ] The Qualcomm Hamoa & Glymur Root Ports don't advertise an ACS capability, but they do provide ACS-like features to disable peer transactions and validate bus numbers in requests. Add an ACS quirk for Hamoa & Glymur. Signed-off-by: Krishna Chaitanya Chundru Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260109-acs_quirk-v1-1-82adf95a89ae@oss.qua= lcomm.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/quirks.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 538ad85cf7c30..4463a2da0441f 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5117,6 +5117,10 @@ static const struct pci_dev_acs_enabled { { PCI_VENDOR_ID_QCOM, 0x0401, pci_quirk_qcom_rp_acs }, /* QCOM SA8775P root port */ { PCI_VENDOR_ID_QCOM, 0x0115, pci_quirk_qcom_rp_acs }, + /* QCOM Hamoa root port */ + { PCI_VENDOR_ID_QCOM, 0x0111, pci_quirk_qcom_rp_acs }, + /* QCOM Glymur root port */ + { PCI_VENDOR_ID_QCOM, 0x0120, pci_quirk_qcom_rp_acs }, /* HXT SD4800 root ports. The ACS design is same as QCOM QDF2xxx */ { PCI_VENDOR_ID_HXT, 0x0401, pci_quirk_qcom_rp_acs }, /* Intel PCH root ports */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FD493B095E; Sat, 28 Feb 2026 17:38:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300306; cv=none; b=b6c6SjeexcbV/GFehd7NzyaFLhwL2ZkKkWb/Hc5QsGNhk/ZYly0Wy2eHnGs1+c9ZnP9gT4dd0Ni+btV3SS1CjZIIGV3/62G8Om+g5hnVooGQyO1qpJThdFd/AV/p5cKxMLeiAArrg6JYHniwKn/PoGKkv9O3248y0MazVVUFOPA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300306; c=relaxed/simple; bh=9fThhOT5K0o6OtqQqTxa5xfDf7abhccpMQ0273q90AQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L9m1K37k4z6KgQITPMzqaHXtoivDVKxJ5iiRe3ba5m+lPUj7MKO1QEmRy2lif12PsrY8DuARANFOGmot8uLcXLU/8wixZ9wfgHChVU5mZziH0W6Dehhpbd8aNWloByW8JQb+Bft+TX15lNZm5LoaWmIkDPrYHQxqYWwYT0hDzcQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fjHo1oEm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fjHo1oEm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B68D5C116D0; Sat, 28 Feb 2026 17:38:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300306; bh=9fThhOT5K0o6OtqQqTxa5xfDf7abhccpMQ0273q90AQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fjHo1oEmOb9Iezjpe9Yfb46oAEm2LxyJiQpqyIUbxlTjlD/r9y88kozDn3fb6lebX b6a/liOxrdQE42awwl3z41SzMITHZMaYklOrghOuXZGvD0Rk29rwcjYLe7OfqlQE82 FNnyuipHHlG8iXpmzlODn4AiuZmplKXkpBNEMm8ThtHXUttQL2l+b1pQJP/uEHV8IT dORks61G0DF3tJJmH4RpfuXAQ7LHE1FWJa58wCFHr1PM/9Ys6AhG0QlZM9My4vjjpB O8z8jtw8ZsnTpX14/NBcXKTkDx+53+G+DsdVBHIqkIkUBmNi12aEm6yHTMRsn/a9Gh Y097Koirle2wA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johnny-CC Chang , Bjorn Helgaas , Manivannan Sadhasivam , Sasha Levin Subject: [PATCH 6.19 336/844] PCI: Mark Nvidia GB10 to avoid bus reset Date: Sat, 28 Feb 2026 12:24:09 -0500 Message-ID: <20260228173244.1509663-337-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johnny-CC Chang [ Upstream commit c81a2ce6b6a844d1a57d2a69833a9d0f00403f00 ] After asserting Secondary Bus Reset to downstream devices via a GB10 Root Port, the link may not retrain correctly, e.g., the link may retrain with a lower lane count or config accesses to downstream devices may fail. Prevent use of Secondary Bus Reset for devices below GB10. Signed-off-by: Johnny-CC Chang [bhelgaas: drop pci_ids.h update (only used once), update commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251113084441.2124737-1-Johnny-CC.Chang@med= iatek.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/quirks.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 4463a2da0441f..90676cb2fd10b 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3748,6 +3748,14 @@ static void quirk_no_bus_reset(struct pci_dev *dev) dev->dev_flags |=3D PCI_DEV_FLAGS_NO_BUS_RESET; } =20 +/* + * After asserting Secondary Bus Reset to downstream devices via a GB10 + * Root Port, the link may not retrain correctly. + * https://lore.kernel.org/r/20251113084441.2124737-1-Johnny-CC.Chang@medi= atek.com + */ +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x22CE, quirk_no_bus_reset); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x22D0, quirk_no_bus_reset); + /* * Some NVIDIA GPU devices do not work with bus reset, SBR needs to be * prevented for those affected devices. --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 70DF43B0978; Sat, 28 Feb 2026 17:38:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300307; cv=none; b=RlRCEgZLkWPGpEAS48+o01A2V/vZspBKvtH0y7dt5OImCDltNeFI8UJa2zCBetfCAe8FOJjP4mAdT/0RAEaLJk1KoSVeKjk7j0v2rizj1yNzgtFWdUxs1q6zBGTgw8d9mRr18OLxUe/zVHSgRmCEn/whyN1XDx2VUraXWkBPiXY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300307; c=relaxed/simple; bh=qD7fVtheLLhwrPCrINYiMipFKUTRbQYSCMDZcsg+NHU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sK4Xkb3CaZ4BQNIftatlb+kRiR2DZsO8w5ugc2Xsf6Bim5CSnlxmOjHEO8/sXYK8Sbx7xhLDxdfM6EmBDceh4EVTtAdCs62ZSEb/9b5WvQ20THjCJ9znS+jyAjo6c4Vjk+3ALR40ZG7DQAYgaaR14DdYCOrdXmoqLCH6Ng5rT6w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QxD8rfh6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QxD8rfh6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6DC0C116D0; Sat, 28 Feb 2026 17:38:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300307; bh=qD7fVtheLLhwrPCrINYiMipFKUTRbQYSCMDZcsg+NHU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QxD8rfh6+PZov1ATwLBlYjdETWl2a9dQCaKtHZ6rX/1wFwIWw1Eim9RTJIUuGqgFF idI9ThhiXIkWI0kws5kLKYaBDk/M/1CdC9Y+F/mnI9qQdSKpJWWuOoV3rrsRzx55hm fmr37Bkc769Uzzoy/TE6PLDc5/nj1LCQ5SCwO6MsMfTKYaCVp8vJrIApuoXLUBYkdM cz3w2eI93H7BaDzmSvPuX53OULbuV8VH6nAjjGsd80Rjt/Z22vlTok2K9SjqlmEdKX jk0oGhOEcyulaPG+LfmRnCxrQR51lwmyEXAgjrukwFNye+fk3fGcj9p1lU7x4gjUoC 7Qc2OAGLu1/9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Adam Stylinski , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.19 337/844] PCI/bwctrl: Disable BW controller on Intel P45 using a quirk Date: Sat, 28 Feb 2026 12:24:10 -0500 Message-ID: <20260228173244.1509663-338-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ilpo J=C3=A4rvinen [ Upstream commit 46a9f70e93ef73860d1dbbec75ef840031f8f30a ] The commit 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") was found to lead to a boot hang on a Intel P45 system. Testing without setting Link Bandwidth Management Interrupt Enable (LBMIE) and Link Autonomous Bandwidth Interrupt Enable (LABIE) (PCIe r7.0, sec 7.5.3.7) in bwctrl allowed system to come up. P45 is a very old chipset and supports only up to gen2 PCIe, so not having bwctrl does not seem a huge deficiency. Add no_bw_notif in struct pci_dev and quirk Intel P45 Root Port with it. Reported-by: Adam Stylinski Link: https://lore.kernel.org/linux-pci/aUCt1tHhm_-XIVvi@eggsbenedict/ Signed-off-by: Ilpo J=C3=A4rvinen Signed-off-by: Bjorn Helgaas Tested-by: Adam Stylinski Link: https://patch.msgid.link/20260116131513.2359-1-ilpo.jarvinen@linux.in= tel.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/pcie/bwctrl.c | 3 +++ drivers/pci/quirks.c | 10 ++++++++++ include/linux/pci.h | 1 + 3 files changed, 14 insertions(+) diff --git a/drivers/pci/pcie/bwctrl.c b/drivers/pci/pcie/bwctrl.c index 36f939f23d34e..4ae92c9f912a8 100644 --- a/drivers/pci/pcie/bwctrl.c +++ b/drivers/pci/pcie/bwctrl.c @@ -250,6 +250,9 @@ static int pcie_bwnotif_probe(struct pcie_device *srv) struct pci_dev *port =3D srv->port; int ret; =20 + if (port->no_bw_notif) + return -ENODEV; + /* Can happen if we run out of bus numbers during enumeration. */ if (!port->subordinate) return -ENODEV; diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 90676cb2fd10b..fd86f72f54aef 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1359,6 +1359,16 @@ static void quirk_transparent_bridge(struct pci_dev = *dev) DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82380FB,= quirk_transparent_bridge); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TOSHIBA, 0x605, quirk_transparent_b= ridge); =20 +/* + * Enabling Link Bandwidth Management Interrupts (BW notifications) can ca= use + * boot hangs on P45. + */ +static void quirk_p45_bw_notifications(struct pci_dev *dev) +{ + dev->no_bw_notif =3D 1; +} +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e21, quirk_p45_bw_notific= ations); + /* * Common misconfiguration of the MediaGX/Geode PCI master that will reduce * PCI bandwidth from 70MB/s to 25MB/s. See the GXM/GXLV/GX1 datasheets diff --git a/include/linux/pci.h b/include/linux/pci.h index b5cc0c2b99065..e958ff7443356 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -406,6 +406,7 @@ struct pci_dev { user sysfs */ unsigned int clear_retrain_link:1; /* Need to clear Retrain Link bit manually */ + unsigned int no_bw_notif:1; /* BW notifications may cause issues */ unsigned int d3hot_delay; /* D3hot->D0 transition time in ms */ unsigned int d3cold_delay; /* D3cold->D0 transition time in ms */ =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 566C03B11CD; Sat, 28 Feb 2026 17:38:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300308; cv=none; b=dLZtR3dubwHeo5tRBIbTLzY4VeY8cGHESOaTGg08w5wzuwYyKLNop4+A12SXlZelROpzlo86O13AL6q5fl4vocIFA2PS/hL8Ph2n0QN1/4yGdApr4HQ7poObnFf6xwJnMOs5SIlNutBvYGZ3kuAp8n9MoNZDRgc400DpJNuyvDM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300308; c=relaxed/simple; bh=cNvj1NBc8cBn42kCKtjDzK2Ax93s/bISUV+sR8cKvBU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=did1ykZSoLjVfxO/Dkda+bQ+NMqoZ40vEwtaPetPIizge1nHBUroZurxg+3fVwDyPo5PnxVxCGtnKYAbj7Tah0ktg4XCeKwriUzmO3StfNDtP+FpFULgUT75DySj5L/bSYnZrnLjzLg8u6e+I9ZJEprYqOTCNarl3PoNSCo/PjQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qvBBcpx0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qvBBcpx0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98FFEC116D0; Sat, 28 Feb 2026 17:38:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300308; bh=cNvj1NBc8cBn42kCKtjDzK2Ax93s/bISUV+sR8cKvBU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qvBBcpx07QjLzlC5HdqTNprxkAJ3DTi6kYybmOVe5e2+kAmv9aE2qKyUlLL8bRv33 8mB+5mBFglLrLyyhSWtKaa3Y7cD3I1ihxLGPSfmj2LLMpDF9F7HZiCUB0e+8tzapQw npHQF0/kYH1HifiPeze6wfd3akLxjZNt/5rk7JYERCHeJxOcL+TsSprdr7b5i1n649 aoUoQw6sRfEF5+8EyM5/FsY02JcEBAOczBCqDDn1kMk0cLcd9kspSHy00cqnDBAxas NLZrd9ujhUZt8/i+DaBdYibDOF8beYJ1KiZieSZjq+DcPFRCkEHtSkZqyvkgKCe0+B oFCOU/QE8qYyg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnd Bergmann , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 338/844] myri10ge: avoid uninitialized variable use Date: Sat, 28 Feb 2026 12:24:11 -0500 Message-ID: <20260228173244.1509663-339-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann [ Upstream commit fd24173439c033ffb3c2a2628fcbc9cb65e62bdb ] While compile testing on less common architectures, I noticed that gcc-10 on s390 finds a bug that all other configurations seem to miss: drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_set= _multicast_list': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:391:25: error: 'cmd.data0'= is used uninitialized in this function [-Werror=3Duninitialized] 391 | buf->data0 =3D htonl(data->data0); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:25: error: '*((void *)= &cmd+4)' is used uninitialized in this function [-Werror=3Duninitialized] 392 | buf->data1 =3D htonl(data->data1); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_all= ocate_rings': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:13: error: 'cmd.data1'= is used uninitialized in this function [-Werror=3Duninitialized] 392 | buf->data1 =3D htonl(data->data1); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data1'= was declared here 1939 | struct myri10ge_cmd cmd; | ^~~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:393:13: error: 'cmd.data2'= is used uninitialized in this function [-Werror=3Duninitialized] 393 | buf->data2 =3D htonl(data->data2); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data2'= was declared here 1939 | struct myri10ge_cmd cmd; It would be nice to understand how to make other compilers catch this as well, but for the moment I'll just shut up the warning by fixing the undefined behavior in this driver. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260205162935.2126442-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../net/ethernet/myricom/myri10ge/myri10ge.c | 28 ++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net= /ethernet/myricom/myri10ge/myri10ge.c index 7be30a8df2685..2f0cdbd4e2ac9 100644 --- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c +++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c @@ -688,6 +688,9 @@ static int myri10ge_get_firmware_capabilities(struct my= ri10ge_priv *mgp) =20 /* probe for IPv6 TSO support */ mgp->features =3D NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_TSO; + cmd.data0 =3D 0, + cmd.data1 =3D 0, + cmd.data2 =3D 0, status =3D myri10ge_send_cmd(mgp, MXGEFW_CMD_GET_MAX_TSO6_HDR_SIZE, &cmd, 0); if (status =3D=3D 0) { @@ -806,6 +809,7 @@ static int myri10ge_update_mac_address(struct myri10ge_= priv *mgp, | (addr[2] << 8) | addr[3]); =20 cmd.data1 =3D ((addr[4] << 8) | (addr[5])); + cmd.data2 =3D 0; =20 status =3D myri10ge_send_cmd(mgp, MXGEFW_SET_MAC_ADDRESS, &cmd, 0); return status; @@ -817,6 +821,9 @@ static int myri10ge_change_pause(struct myri10ge_priv *= mgp, int pause) int status, ctl; =20 ctl =3D pause ? MXGEFW_ENABLE_FLOW_CONTROL : MXGEFW_DISABLE_FLOW_CONTROL; + cmd.data0 =3D 0, + cmd.data1 =3D 0, + cmd.data2 =3D 0, status =3D myri10ge_send_cmd(mgp, ctl, &cmd, 0); =20 if (status) { @@ -834,6 +841,9 @@ myri10ge_change_promisc(struct myri10ge_priv *mgp, int = promisc, int atomic) int status, ctl; =20 ctl =3D promisc ? MXGEFW_ENABLE_PROMISC : MXGEFW_DISABLE_PROMISC; + cmd.data0 =3D 0; + cmd.data1 =3D 0; + cmd.data2 =3D 0; status =3D myri10ge_send_cmd(mgp, ctl, &cmd, atomic); if (status) netdev_err(mgp->dev, "Failed to set promisc mode\n"); @@ -1946,6 +1956,8 @@ static int myri10ge_allocate_rings(struct myri10ge_sl= ice_state *ss) /* get ring sizes */ slice =3D ss - mgp->ss; cmd.data0 =3D slice; + cmd.data1 =3D 0; + cmd.data2 =3D 0; status =3D myri10ge_send_cmd(mgp, MXGEFW_CMD_GET_SEND_RING_SIZE, &cmd, 0); tx_ring_size =3D cmd.data0; cmd.data0 =3D slice; @@ -2238,12 +2250,16 @@ static int myri10ge_get_txrx(struct myri10ge_priv *= mgp, int slice) status =3D 0; if (slice =3D=3D 0 || (mgp->dev->real_num_tx_queues > 1)) { cmd.data0 =3D slice; + cmd.data1 =3D 0; + cmd.data2 =3D 0; status =3D myri10ge_send_cmd(mgp, MXGEFW_CMD_GET_SEND_OFFSET, &cmd, 0); ss->tx.lanai =3D (struct mcp_kreq_ether_send __iomem *) (mgp->sram + cmd.data0); } cmd.data0 =3D slice; + cmd.data1 =3D 0; + cmd.data2 =3D 0; status |=3D myri10ge_send_cmd(mgp, MXGEFW_CMD_GET_SMALL_RX_OFFSET, &cmd, 0); ss->rx_small.lanai =3D (struct mcp_kreq_ether_recv __iomem *) @@ -2312,6 +2328,7 @@ static int myri10ge_open(struct net_device *dev) if (mgp->num_slices > 1) { cmd.data0 =3D mgp->num_slices; cmd.data1 =3D MXGEFW_SLICE_INTR_MODE_ONE_PER_SLICE; + cmd.data2 =3D 0; if (mgp->dev->real_num_tx_queues > 1) cmd.data1 |=3D MXGEFW_SLICE_ENABLE_MULTIPLE_TX_QUEUES; status =3D myri10ge_send_cmd(mgp, MXGEFW_CMD_ENABLE_RSS_QUEUES, @@ -2414,6 +2431,8 @@ static int myri10ge_open(struct net_device *dev) =20 /* now give firmware buffers sizes, and MTU */ cmd.data0 =3D dev->mtu + ETH_HLEN + VLAN_HLEN; + cmd.data1 =3D 0; + cmd.data2 =3D 0; status =3D myri10ge_send_cmd(mgp, MXGEFW_CMD_SET_MTU, &cmd, 0); cmd.data0 =3D mgp->small_bytes; status |=3D @@ -2472,7 +2491,6 @@ static int myri10ge_open(struct net_device *dev) static int myri10ge_close(struct net_device *dev) { struct myri10ge_priv *mgp =3D netdev_priv(dev); - struct myri10ge_cmd cmd; int status, old_down_cnt; int i; =20 @@ -2491,8 +2509,13 @@ static int myri10ge_close(struct net_device *dev) =20 netif_tx_stop_all_queues(dev); if (mgp->rebooted =3D=3D 0) { + struct myri10ge_cmd cmd; + old_down_cnt =3D mgp->down_cnt; mb(); + cmd.data0 =3D 0; + cmd.data1 =3D 0; + cmd.data2 =3D 0; status =3D myri10ge_send_cmd(mgp, MXGEFW_CMD_ETHERNET_DOWN, &cmd, 0); if (status) @@ -2956,6 +2979,9 @@ static void myri10ge_set_multicast_list(struct net_de= vice *dev) =20 /* Disable multicast filtering */ =20 + cmd.data0 =3D 0; + cmd.data1 =3D 0; + cmd.data2 =3D 0; err =3D myri10ge_send_cmd(mgp, MXGEFW_ENABLE_ALLMULTI, &cmd, 1); if (err !=3D 0) { netdev_err(dev, "Failed MXGEFW_ENABLE_ALLMULTI, error status: %d\n", --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 255613B11E7; Sat, 28 Feb 2026 17:38:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300309; cv=none; b=WTVqiELCXOY190bpOCfhbyQDwhXsBdAjiYkeA4kLIGudQmRogca92KphJymlS7zy6wxr/OQY/Ie1mhgF47IKjvFBwxkfOc3AuVv/3xaIlnAvnCYRxhtj70Vz8vTnKRn8DGWXxRdBHODHEli4UJIcNs/LqFEnxBd09CmFsWvlAiA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300309; c=relaxed/simple; bh=mz3RJ5rgCVHrReDGadpyTqNtR9r3w3PV1eS+GmPEafk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=n+GlcH1Qy+jZ9+aMJ5dltFVx3O5ZVSj5TGXHr40aO4AoLd8bqZcPvjuVnSBQ4+y9Vb7Ks/M8dA66YC0DPU9jSv8zo0kAz5IFkgTrLUIwKCWE9xyKC26pbJdWaeIDi7Z0S5h2IZ8rOo4KBzyV+04CFRGBBNUnA2mOUmErvcgSLJM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X6YZh34N; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X6YZh34N" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 732F2C19424; Sat, 28 Feb 2026 17:38:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300309; bh=mz3RJ5rgCVHrReDGadpyTqNtR9r3w3PV1eS+GmPEafk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X6YZh34N9YOB1AJeRyp+R/M4uy7775OOz9OtkdqjVvD55CxxUb9mLqsnTFgZ+hau1 BBBPzekh59RyctPwZyDyGghTn7nX+xFhBzeKqJPmHIgzWXkuNX7sLvjaX1VyKyonmp GQ8X0J8wY0S66E5VGfmDNVVCRA/sNY3JXUncS0eI8txeE0rxm5kpt5SLrYTmLOgpIF 8ozHnInWHHuEYTsgz0cGeZuLvpA2sbETU4ngWAlr8RfxfQLrTY1Vof8YkuolcdEMp/ QwsH7FZawsYfvIgu6q89anN23KWkzSScyYpxTqY/uyDGkDg3iqphyqspheW9INAUOR aWQ3sqQyeSg8A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Carl Lee , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 339/844] nfc: nxp-nci: remove interrupt trigger type Date: Sat, 28 Feb 2026 12:24:12 -0500 Message-ID: <20260228173244.1509663-340-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Carl Lee [ Upstream commit 57be33f85e369ce9f69f61eaa34734e0d3bd47a7 ] For NXP NCI devices (e.g. PN7150), the interrupt is level-triggered and active high, not edge-triggered. Using IRQF_TRIGGER_RISING in the driver can cause interrupts to fail to trigger correctly. Remove IRQF_TRIGGER_RISING and rely on the IRQ trigger type configured via Device Tree. Signed-off-by: Carl Lee Link: https://patch.msgid.link/20260205-fc-nxp-nci-remove-interrupt-trigger= -type-v2-1-79d2ed4a7e42@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/nfc/nxp-nci/i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c index 049662ffdf972..6a5ce8ff91f0b 100644 --- a/drivers/nfc/nxp-nci/i2c.c +++ b/drivers/nfc/nxp-nci/i2c.c @@ -305,7 +305,7 @@ static int nxp_nci_i2c_probe(struct i2c_client *client) =20 r =3D request_threaded_irq(client->irq, NULL, nxp_nci_i2c_irq_thread_fn, - IRQF_TRIGGER_RISING | IRQF_ONESHOT, + IRQF_ONESHOT, NXP_NCI_I2C_DRIVER_NAME, phy); if (r < 0) nfc_err(&client->dev, "Unable to register IRQ handler\n"); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01B123B11D1; Sat, 28 Feb 2026 17:38:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300310; cv=none; b=in3+lxMwhnV14GJx9ZpToeqL1Qrdw9/FhtyibzKgpFjnqu/P1NXr4FmXJsUIWQaA3sKMCcVC8i0gokPPS/GBt/olVZDuolYsFn6+IHfYYOIAOkidAtE0/7hOJKhSkjQt72Hw+9jd5JuPuVFDW9kY/IMox9jf8mFpTHM3iG64GlY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300310; c=relaxed/simple; bh=ePR/Zj3d6jqJncBptWbqG1xkmpftdrwOe5ga0jt3hkc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QnG6l4fuH/3ehE4wq6VtCbcETlV1wJpTU9807nlLbFQzBakVW7sMw/qA5F27r7RCPFD3310ZwUZkjj/tu2mccoLbGqFrwrjmDkzFIjOPBZ4tjlK9RVHLYfiomCjdVbu+gdmZd6si825+DLGA+czXcuYh7p0gx0gLvvBE79Y6yp8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ej/la0UB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ej/la0UB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D43DC116D0; Sat, 28 Feb 2026 17:38:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300309; bh=ePR/Zj3d6jqJncBptWbqG1xkmpftdrwOe5ga0jt3hkc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ej/la0UBfB4oOI12cemG1zkLsJE3z12MGEtC0fC9m9Z8o9RZsal4hrTsqOH12bMRN l0AFQbxv1jfOsW24JCdwXbyzJkJJdpF/rERoWH758wqkKyMTGCy8e4YWChjfyTBaD2 kJr0Jm0GRPyFJ2d6bv7i0dabHELwdx8TlAOsJaJOS6aLHwD9mJr0psPVkai1m+I+rM g/AlCaY05AovFqMj+tq1JQCrhM7QCtnWZUXE+F2YwfXHUrZykCcfCtZiSHW0qm3EU/ F3U3QgUfyp36lqzMzpwMkbHK5Ez3nxO4VPNEopHFEIh34h6CJXusNIg9nF07DrNWzV PfUpx/oNXyJkQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Longfang Liu , Alex Williamson , Sasha Levin Subject: [PATCH 6.19 340/844] hisi_acc_vfio_pci: resolve duplicate migration states Date: Sat, 28 Feb 2026 12:24:13 -0500 Message-ID: <20260228173244.1509663-341-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Longfang Liu [ Upstream commit 8c6ac1730a977234dff74cc1753b4a953f59be7b ] In special scenarios involving duplicate migrations, after the first migration is completed, if the original VF device is used again and then migrated to another destination, the state indicating data migration completion for the VF device is not reset. This results in the second migration to the destination being skipped without performing data migration. After the modification, it ensures that a complete data migration is performed after the subsequent migration. Signed-off-by: Longfang Liu Link: https://lore.kernel.org/r/20260122020205.2884497-4-liulongfang@huawei= .com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/= pci/hisilicon/hisi_acc_vfio_pci.c index d1e8053640a98..8a05fb91929fb 100644 --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c @@ -1570,6 +1570,7 @@ static int hisi_acc_vfio_pci_open_device(struct vfio_= device *core_vdev) } hisi_acc_vdev->mig_state =3D VFIO_DEVICE_STATE_RUNNING; hisi_acc_vdev->dev_opened =3D true; + hisi_acc_vdev->match_done =3D 0; mutex_unlock(&hisi_acc_vdev->open_mutex); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AA263B1AF5; Sat, 28 Feb 2026 17:38:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300311; cv=none; b=LmndeAjcXMm62lnq9HQ/LBlEiDRODE2jbNR7CKz4ADVJRPcM416R2Nbu5WEhHAx1KCamQR0x1P3JHP3faH/QmD0Z7ASqq9hB6NJ75+Opgt9y4Ksg2INF3z7OLczT0FHUw4cS5520QuddNSRGgx5JEF+Jap2I5Acp0+UhXitzfpQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300311; c=relaxed/simple; bh=5rN1791otkXld9s0yk37EK1HmhIuksVPV/oWgb5wLiE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N/IV7jeej2eA+gdjK7HWDg2XBpvd6gTeGkwSHx4x+eCK+ndzBcUkJPqRLQsvMrhlufuj3SB6JkF30wsre5DRJAJ3ZeFePiJ1fcrSsYup+WBanIGBm7e+q8JLpnUaTPNc8QQmf8+ZrWyHCjPDvuIx/QHE4fBDwpDFhE9pTJWiY0s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gZEThMD1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gZEThMD1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A70BC19425; Sat, 28 Feb 2026 17:38:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300310; bh=5rN1791otkXld9s0yk37EK1HmhIuksVPV/oWgb5wLiE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gZEThMD1UFSRyIxZNo4LOoeLgyRT5n7bbFDd8foRNs6j0sntx8xIk1q6XeiLN08nq aXk/b5v+LPZbHY16bJjgEUVPuZm4NIaEp5eYUI7DAfzIxoQV/i+GlzRhql9YngShYP 54GhnS2A9m8oj2EgvA7dqLsatZ6Iohfiqcndst/MQGPZ0TV5m1nIv4yHBxjixZPaZg y3sHg/2jeSW0KYr5vF55xYZ26YLEPzhaYPR45Cj/C1ZnStMWxPb/sKP0PYXwXVdp/x mRo8NTpIs/2g4kf3VDdCzgwbm5+9iAt8sBtjnEYaWNysLtwQtMdVJnvCiHkQGSqX4u iaI+v/BMUsXgQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Md Haris Iqbal , Grzegorz Prajsner , Jack Wang , Leon Romanovsky , Sasha Levin Subject: [PATCH 6.19 341/844] RDMA/rtrs-clt: For conn rejection use actual err number Date: Sat, 28 Feb 2026 12:24:14 -0500 Message-ID: <20260228173244.1509663-342-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Md Haris Iqbal [ Upstream commit fc290630702b530c2969061e7ef0d869a5b6dc4f ] When the connection establishment request is rejected from the server side, then the actual error number sent back should be used. Signed-off-by: Md Haris Iqbal Link: https://patch.msgid.link/20260107161517.56357-10-haris.iqbal@ionos.com Reviewed-by: Grzegorz Prajsner Reviewed-by: Jack Wang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/infiniband/ulp/rtrs/rtrs-clt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/ulp/rtrs/rtrs-clt.c b/drivers/infiniband/ul= p/rtrs/rtrs-clt.c index 2b397a544cb93..8fa1d72bd20a4 100644 --- a/drivers/infiniband/ulp/rtrs/rtrs-clt.c +++ b/drivers/infiniband/ulp/rtrs/rtrs-clt.c @@ -1923,7 +1923,7 @@ static int rtrs_rdma_conn_rejected(struct rtrs_clt_co= n *con, struct rtrs_path *s =3D con->c.path; const struct rtrs_msg_conn_rsp *msg; const char *rej_msg; - int status, errno; + int status, errno =3D -ECONNRESET; u8 data_len; =20 status =3D ev->status; @@ -1945,7 +1945,7 @@ static int rtrs_rdma_conn_rejected(struct rtrs_clt_co= n *con, status, rej_msg); } =20 - return -ECONNRESET; + return errno; } =20 void rtrs_clt_close_conns(struct rtrs_clt_path *clt_path, bool wait) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1E8E3B1B16; Sat, 28 Feb 2026 17:38:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300312; cv=none; b=mzjBweF7ExaT7E4D8EVj67QzqO58JHdLbQFrgNc7+5M39V5Hd5pWsckV0HrvPrySo4yhrwfTCURNQg3KMM/1Q8lKywKLQtnC5F4G4ycOsEZLV0uUXbhPgndYd3OYupRaEm6L/wSPnTnqTRf6LIY9ARnKkPK2ZmCgTI5ZJNewtLk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300312; c=relaxed/simple; bh=1lQuTfa/eJydjZkTVhAkq5sataUOWFIScvI3T0Fsi8I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tre+ZMKN+ZZVd1AzOVe9376OZ3dzKvSijcKz5tBQ8kQMWhYF1OSVd1akccEVNWfg/RhXzU39HOY2JYogJ8K0dYkQv2/2uJOqIqXtE/70EKO3RCT++QFVOPC0tP9USYc2ZW1ZyhzPqwBoSnDWN4H8drO1Sv8Ux6MVoNgAVU5y/Ag= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XKrI1+Vz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XKrI1+Vz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F847C19423; Sat, 28 Feb 2026 17:38:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300311; bh=1lQuTfa/eJydjZkTVhAkq5sataUOWFIScvI3T0Fsi8I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XKrI1+Vz4Div1Bl+8TiadwS4ZjOdmW4L/FOqUFUWBej5isGbeTXy2x+qmjqyO9aSt z+UhtxcAFc6cXE1h00jyF4HFrGhrUpzwvN7N4AS7Iyr7kvka/N0T9dafbkRx+eHlTs HXyCcubtSd/eMj60SqC7uepfXVw9uYspq42Wu0TcOr23Uo+7Dz5jrxeT1T1YpEpfvD 2JeyZbYsA/tfikUPbIRAAxHEG1h5eN2OQaUpy0VoSxE+IuUGrh/2Y2oAqoe5hyHpzy /JgFT+rspK5JvhyJD/KYWpAmQodczAzRQnuxnM7UwdxLjkQN9mTHyzzyEGSxGQeqS8 RqHjSlHQNtkJg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Longfang Liu , Alex Williamson , Sasha Levin Subject: [PATCH 6.19 342/844] hisi_acc_vfio_pci: fix the queue parameter anomaly issue Date: Sat, 28 Feb 2026 12:24:15 -0500 Message-ID: <20260228173244.1509663-343-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Longfang Liu [ Upstream commit c3cbc276c2a33b04fc78a86cdb2ddce094cb3614 ] When the number of QPs initialized by the device, as read via vft, is zero, it indicates either an abnormal device configuration or an abnormal read result. Returning 0 directly in this case would allow the live migration operation to complete successfully, leading to incorrect parameter configuration after migration and preventing the service from recovering normal functionality. Therefore, in such situations, an error should be returned to roll back the live migration operation. Signed-off-by: Longfang Liu Link: https://lore.kernel.org/r/20260122020205.2884497-5-liulongfang@huawei= .com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/= pci/hisilicon/hisi_acc_vfio_pci.c index 8a05fb91929fb..2b8ac97cef2d2 100644 --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c @@ -426,7 +426,7 @@ static int vf_qm_check_match(struct hisi_acc_vf_core_de= vice *hisi_acc_vdev, ret =3D qm_get_vft(vf_qm, &vf_qm->qp_base); if (ret <=3D 0) { dev_err(dev, "failed to get vft qp nums\n"); - return ret; + return ret < 0 ? ret : -EINVAL; } =20 if (ret !=3D vf_data->qp_num) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B1D5D3B2321; Sat, 28 Feb 2026 17:38:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300312; cv=none; b=dMdrGw5HagTlmHC5IKtXO/NKJmGYE4ue0gNZjJRRmP+kP3BBy4Zmt/pOrT6e41ZzXhWxX1I1ApmyANZkLgJ9mIfqFCEjGeQLFIt44ZEqJ9T3VKI120PBps8lORWB3DD4bZle7WzoppFJop+RJSmJ+sOlsgcD+v/1XfpsoKfdbsE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300312; c=relaxed/simple; bh=FTnfptXU6GfqP6kpcpXunaUsnAH5Vacm9bOsUQdIZpo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ec9pohaNLusE2m3y6xywny4QlB1Tx4EqJqpzlQhf7dcHYeEE7E6dQAZvv5tCAGZn5oaT6n0/AOFTsma5xMg5nI1UdQf5fbt+XF75rKn2p3e8nVbo3yUxTWcyXiu45WZJ9lI4zJaXiVErR8EmyGgBpPr58osXL9mxULRVolz+N1Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ECx+igH+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ECx+igH+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CB35C19423; Sat, 28 Feb 2026 17:38:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300312; bh=FTnfptXU6GfqP6kpcpXunaUsnAH5Vacm9bOsUQdIZpo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ECx+igH+/J9EmzjLOWkOtitWu8Z9LBmBN/dMX/tRZvqVDPnNFfHzVpaP0Zejq13C/ FH1x2NhTd4X6iNG5EBWGqQ4mZNLFEBohJ7ZkeiFSxJwZ+agjmy481VMwwyYBJS/zSe 07UxG4aZwysF4YgOPyejE9DmS/L03Uiws7LgZrRZVpgQJrIFKqVSBnKYx4Z50Flrwv vtwXbmXF2ZrY+5eOHzryVxxCy8jdThE1jufTn1XB8r9bAujFqu2zqh0/I9j5xQtF4k dx+4q6hWaBkUG1+ynTY3ek4u+7LHlkUn5/VU92u/fwYixPxCluX3MkAx6JH4PzUgfV Z7eJFY0qMEdig== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tiwei Bie , Johannes Berg , Sasha Levin Subject: [PATCH 6.19 343/844] um: Preserve errno within signal handler Date: Sat, 28 Feb 2026 12:24:16 -0500 Message-ID: <20260228173244.1509663-344-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tiwei Bie [ Upstream commit f68b2d5a907b53eed99cf2efcaaae116df73c298 ] We rely on errno to determine whether a syscall has failed, so we need to ensure that accessing errno is async-signal-safe. Currently, we preserve the errno in sig_handler_common(), but it doesn't cover every possible case. Let's do it in hard_handler() instead, which is the signal handler we actually register. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20260106001228.1531146-2-tiwei.btw@antgroup.= com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/um/os-Linux/signal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c index 327fb3c52fc79..de372b936a804 100644 --- a/arch/um/os-Linux/signal.c +++ b/arch/um/os-Linux/signal.c @@ -36,7 +36,6 @@ void (*sig_info[NSIG])(int, struct siginfo *, struct uml_= pt_regs *, void *mc) =3D static void sig_handler_common(int sig, struct siginfo *si, mcontext_t *mc) { struct uml_pt_regs r; - int save_errno =3D errno; =20 r.is_user =3D 0; if (sig =3D=3D SIGSEGV) { @@ -50,8 +49,6 @@ static void sig_handler_common(int sig, struct siginfo *s= i, mcontext_t *mc) unblock_signals_trace(); =20 (*sig_info[sig])(sig, si, &r, mc); - - errno =3D save_errno; } =20 /* @@ -207,8 +204,11 @@ static void hard_handler(int sig, siginfo_t *si, void = *p) { ucontext_t *uc =3D p; mcontext_t *mc =3D &uc->uc_mcontext; + int save_errno =3D errno; =20 (*handlers[sig])(sig, (struct siginfo *)si, mc); + + errno =3D save_errno; } =20 void set_handler(int sig) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D16143B2347; Sat, 28 Feb 2026 17:38:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300313; cv=none; b=Q8AH8QBnDit0QFx2hjA3D5yv/KlqZvYgUysoP9taNYrC7EQqyeylGl0S5HZboBjQgOpIMWBxVW6b0TwoLRTFHvrFVSL5q1NdIcQMm0M6I72NLp8B3LR2N5V/6+sZ8Kv4Ho7Llery6BvpRkvvBX4YNVp5Ht1eLDjQc/XCdwyD4G8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300313; c=relaxed/simple; bh=40egpjyRHcRVLO2dddaJco3VVBOopW7krOiKVMOarSk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fAg78JTHnZXj2TzwjDPg7R31IIfV/XhM+KcxH+1zPSptbQHA94MhyqAYj1ZlLQ5CxxCHpMptlZz52BuQP7BqzQkgTN1Wzs/e7Aa2siN8zQv/JhncaPbY0F7f1+0VScz7o9+bckyPLCUUIFHYepedM+MCfT/WMTOXmtLW55QUQu4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cDeAcyhG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cDeAcyhG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB788C19424; Sat, 28 Feb 2026 17:38:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300313; bh=40egpjyRHcRVLO2dddaJco3VVBOopW7krOiKVMOarSk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cDeAcyhG0qvkfTXrCWa3uv/dvZZPXy37VYne41n2DvFM7meEIhHDa8zotWrg2fIt9 VQDLRt6BXjajDIWPbe6ytArk5jj/PhA+VfwPEv1UKibR7sRcSvHGhlboW8uV7jadhG h3hLliJWXAsUz2oD9dxlxxn5gNcWUKMs0eHLBeyBx0od7LQspqmALoy3w5x0VyzvOQ KLUGAIkdavCp02lTRh5WU+n0oXrwi1JeBVf3UtCC2IxGjWTfQaf60q5Vgs22yeXKIe piL6WuuzP9ptZiEcFsCqTBCgFX6r+xfsAUdYwxmB/4LqwHQc2QZjoSQhTJFMRfT2pf TybVvXNkq4+Pw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Henry Tseng , Damien Le Moal , Sasha Levin Subject: [PATCH 6.19 344/844] ata: libata: avoid long timeouts on hot-unplugged SATA DAS Date: Sat, 28 Feb 2026 12:24:17 -0500 Message-ID: <20260228173244.1509663-345-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Henry Tseng [ Upstream commit 151cabd140322205e27dae5c4bbf261ede0056e3 ] When a SATA DAS enclosure is connected behind a Thunderbolt PCIe switch, hot-unplugging the whole enclosure causes pciehp to tear down the PCI hierarchy before the SCSI layer issues SYNCHRONIZE CACHE and START STOP UNIT for the disks. libata still queues these commands and the AHCI driver tries to access the HBA registers even though the PCI channel is already offline. This results in a series of timeouts and error recovery attempts, e.g.: [ 824.778346] pcieport 0000:00:07.0: pciehp: Slot(14): Link Down [ 891.612720] ata8.00: qc timeout after 5000 msecs (cmd 0xec) [ 902.876501] ata8.00: qc timeout after 10000 msecs (cmd 0xec) [ 934.107998] ata8.00: qc timeout after 30000 msecs (cmd 0xec) [ 936.206431] sd 7:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=3DDID_BAD_TARGET driverbyte=3DDRIVER_OK ... [ 1006.298356] ata1.00: qc timeout after 5000 msecs (cmd 0xec) [ 1017.561926] ata1.00: qc timeout after 10000 msecs (cmd 0xec) [ 1048.791790] ata1.00: qc timeout after 30000 msecs (cmd 0xec) [ 1050.890035] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=3DDID_BAD_TARGET driverbyte=3DDRIVER_OK With this patch applied, the same hot-unplug looks like: [ 59.965496] pcieport 0000:00:07.0: pciehp: Slot(14): Link Down [ 60.002502] sd 7:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=3DDID_BAD_TARGET driverbyte=3DDRIVER_OK ... [ 60.103050] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=3DDID_BAD_TARGET driverbyte=3DDRIVER_OK In this test setup with two disks, the hot-unplug sequence shrinks from about 226 seconds (~3.8 minutes) between the Link Down event and the last SYNCHRONIZE CACHE failure to under a second. Without this patch the total delay grows roughly with the number of disks, because each disk gets its own SYNCHRONIZE CACHE and qc timeout series. If the underlying PCI device is already gone, these commands cannot succeed anyway. Avoid issuing them by introducing ata_adapter_is_online(), which checks pci_channel_offline() for PCI-based hosts. It is used from ata_scsi_find_dev() to return NULL, causing the SCSI layer to fail new commands with DID_BAD_TARGET immediately, and from ata_qc_issue() to bail out before touching the HBA registers. Since such failures would otherwise trigger libata error handling, ata_adapter_is_online() is also consulted from ata_scsi_port_error_handler(= ). When the adapter is offline, libata skips ap->ops->error_handler(ap) and completes error handling using the existing path, rather than running a full EH sequence against a dead adapter. With this change, SYNCHRONIZE CACHE and START STOP UNIT commands issued during hot-unplug fail quickly once the PCI channel is offline, without qc timeout spam or long libata EH delays. Suggested-by: Damien Le Moal Signed-off-by: Henry Tseng Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/ata/libata-core.c | 24 ++++++++++++++++++++++++ drivers/ata/libata-eh.c | 3 ++- drivers/ata/libata-scsi.c | 3 +++ drivers/ata/libata.h | 1 + 4 files changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 50dfce8d8bba0..db74417db75d9 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -2359,6 +2359,24 @@ static bool ata_dev_check_adapter(struct ata_device = *dev, return false; } =20 +bool ata_adapter_is_online(struct ata_port *ap) +{ + struct device *dev; + + if (!ap || !ap->host) + return false; + + dev =3D ap->host->dev; + if (!dev) + return false; + + if (dev_is_pci(dev) && + pci_channel_offline(to_pci_dev(dev))) + return false; + + return true; +} + static int ata_dev_config_ncq(struct ata_device *dev, char *desc, size_t desc_sz) { @@ -5135,6 +5153,12 @@ void ata_qc_issue(struct ata_queued_cmd *qc) qc->flags |=3D ATA_QCFLAG_ACTIVE; ap->qc_active |=3D 1ULL << qc->tag; =20 + /* Make sure the device is still accessible. */ + if (!ata_adapter_is_online(ap)) { + qc->err_mask |=3D AC_ERR_HOST_BUS; + goto sys_err; + } + /* * We guarantee to LLDs that they will have at least one * non-zero sg if the command is a data command. diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c index 258e657f3527c..b373cceb95d23 100644 --- a/drivers/ata/libata-eh.c +++ b/drivers/ata/libata-eh.c @@ -752,7 +752,8 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host= , struct ata_port *ap) spin_unlock_irqrestore(ap->lock, flags); =20 /* invoke EH, skip if unloading or suspended */ - if (!(ap->pflags & (ATA_PFLAG_UNLOADING | ATA_PFLAG_SUSPENDED))) + if (!(ap->pflags & (ATA_PFLAG_UNLOADING | ATA_PFLAG_SUSPENDED)) && + ata_adapter_is_online(ap)) ap->ops->error_handler(ap); else { /* if unloading, commence suicide */ diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 5f9abeb7b2a88..6b954efa9adb1 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -3094,6 +3094,9 @@ ata_scsi_find_dev(struct ata_port *ap, const struct s= csi_device *scsidev) { struct ata_device *dev =3D __ata_scsi_find_dev(ap, scsidev); =20 + if (!ata_adapter_is_online(ap)) + return NULL; + if (unlikely(!dev || !ata_dev_enabled(dev))) return NULL; =20 diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h index 60a675df61dc7..9b4e578ad07ec 100644 --- a/drivers/ata/libata.h +++ b/drivers/ata/libata.h @@ -94,6 +94,7 @@ extern int atapi_check_dma(struct ata_queued_cmd *qc); extern void swap_buf_le16(u16 *buf, unsigned int buf_words); extern bool ata_phys_link_online(struct ata_link *link); extern bool ata_phys_link_offline(struct ata_link *link); +bool ata_adapter_is_online(struct ata_port *ap); extern void ata_dev_init(struct ata_device *dev); extern void ata_link_init(struct ata_port *ap, struct ata_link *link, int = pmp); extern int sata_link_init_spd(struct ata_link *link); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6BD823B235B; Sat, 28 Feb 2026 17:38:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300314; cv=none; b=o2xCLLFH7+S+3cWcfh1fgtkrUbmf8KYRaMfKKS5VfWUin3zrr/3UfonE7Xt7otn69HukguwxVqXlVCzPv/7ReCagoLVyaY97QrJOCR5htGQFkiFu6fwlNoJiDiCfuUZsGzpzm1P5O8YPfB4pwwbASZ7hI7Kz4+bs2kdUf027sdA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300314; c=relaxed/simple; bh=Y/2l9a0EImw5OUV5SkHz9FR6Z5JnzcIkAUrT03bJTLw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tSHowOrUoqnZocieOif8kMDNzBVK3grqBmQv8CSAYf3QHxvGItiJjZbF2aHlNfEk4NQkf43/tGyyICwyAHktNiBWI5v1nU5ICi7aO0mVL35/kht0TKSc8j3TqFoO3qPIiplcHV6Rpu8sxlN+A4ncFh1QogoKug+D7gxVx2KViDE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TJkgRSOD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TJkgRSOD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAEADC19425; Sat, 28 Feb 2026 17:38:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300314; bh=Y/2l9a0EImw5OUV5SkHz9FR6Z5JnzcIkAUrT03bJTLw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TJkgRSOD2g9hSp+3Ba2ycLYQwlBig1sOKnfV590KRLs7bmeLJNpX74EzAPMZ0WQ5i ponS3RlV8AQGh9hIat7Uz3QwAArOXO8jmA/FFHxhJHdGRkZkDtsNkJnEjNPsfDaAiO SjaihvrGCROw0EJL0OYKX6mUB892yNwuHjGuVSnZq7V62jBk7uEnYfMdG1h7gQaRzy 9ckCKQL+CzWXKmFe8S9TztvXsWkMbIut00i5nsb4FDY/LdFB2GIapMbAgeFdJX3c+7 8JV3Sbp1KppcImU30PPuJQONQABo1fRnzy5JYUKULW/A7y2cogcbmaNWOjFRavSFAU Ebka6C+XcIdxg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Longfang Liu , Alex Williamson , Sasha Levin Subject: [PATCH 6.19 345/844] hisi_acc_vfio_pci: update status after RAS error Date: Sat, 28 Feb 2026 12:24:18 -0500 Message-ID: <20260228173244.1509663-346-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Longfang Liu [ Upstream commit 8be14dd48dfee0df91e511acceb4beeb2461a083 ] After a RAS error occurs on the accelerator device, the accelerator device will be reset. The live migration state will be abnormal after reset, and the original state needs to be restored during the reset process. Therefore, reset processing needs to be performed in a live migration scenario. Signed-off-by: Longfang Liu Link: https://lore.kernel.org/r/20260122020205.2884497-3-liulongfang@huawei= .com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/= pci/hisilicon/hisi_acc_vfio_pci.c index 2b8ac97cef2d2..e61df3fe0db99 100644 --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c @@ -1215,8 +1215,7 @@ static void hisi_acc_vf_pci_aer_reset_done(struct pci= _dev *pdev) if (hisi_acc_vdev->set_reset_flag) clear_bit(QM_RESETTING, &qm->misc_ctl); =20 - if (hisi_acc_vdev->core_device.vdev.migration_flags !=3D - VFIO_MIGRATION_STOP_COPY) + if (!hisi_acc_vdev->core_device.vdev.mig_ops) return; =20 mutex_lock(&hisi_acc_vdev->state_mutex); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F24E3B2B69; Sat, 28 Feb 2026 17:38:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300315; cv=none; b=bj8rPi/eTDXncGOjsbvG3MqtHkl5KJZtKkJWewJyrYzkzzjZ/x5MCk86gAVHmlniuU/oj9yV/0ojnIpqkGAQM/lucm+sl0iztLEkt/rlW6qZjBgLjDGhWsmmMCEf8jmOw5Enrq9t3Bs87D8yUeAVPXnUKgAKAZ7xQJWWMFWFWbg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300315; c=relaxed/simple; bh=W9Ht9061eXlsgXJAa/mgHZ9alCq4zRwr8EaSMiXPFq4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K/WOua1+nuTPd9vcaU2dCMcN9mM9TJA6Nks/G8busdloI+moelSxt46kYTjX4T9vhRH1y5nxq4cu5ljDfe0s/uhKjTHCFoCc3QGiuKzLI6PCQkttnEBLj5U91y30qZorTuQnt8NbaTApZnpl5GVcsukMohKvgSI0EAcR6/xsP6U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ASGh9P28; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ASGh9P28" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 918CEC116D0; Sat, 28 Feb 2026 17:38:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300315; bh=W9Ht9061eXlsgXJAa/mgHZ9alCq4zRwr8EaSMiXPFq4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ASGh9P28VGsDBnvuUViELcfFY4jFnNJriBW1cMgNdW/nZYF13naZHD+dT44DiV5B+ K/gtUu6Hpad7adx2SzenxkbUsMIdAgk/lDdDlKRWzBifyiQirZz4hEEggQUbkc5RQq ECYH0RhEjScEax3UL6fSENwXqIBfSXjVsU1PCbR8R7FomCT6SmYSI2etz78geHbEim lPIVg2DCkMFV/KFVwvYdzE9baYpsigZ0Z9cv+mmhNbXHdR2oyAU28c70Ah/7ivRcDh Nxsx9mqBecBQfM5jl1I17to9TTZbUAJE1mjBRnGrQNu4u8ziHRlbufNGLyg/ufg8GT kBx4F6pbcH4Bg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnd Bergmann , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 6.19 346/844] scsi: buslogic: Reduce stack usage Date: Sat, 28 Feb 2026 12:24:19 -0500 Message-ID: <20260228173244.1509663-347-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann [ Upstream commit e17f0d4cc006265dd92129db4bf9da3a2e4a4f66 ] Some randconfig builds run into excessive stack usage with gcc-14 or higher, which use __attribute__((cold)) where earlier versions did not do that: drivers/scsi/BusLogic.c: In function 'blogic_init': drivers/scsi/BusLogic.c:2398:1: error: the frame size of 1680 bytes is larg= er than 1536 bytes [-Werror=3Dframe-larger-than=3D] The problem is that a lot of code gets inlined into blogic_init() here. Two functions stick out, but they are a bit different: - blogic_init_probeinfo_list() actually uses a few hundred bytes of kernel stack, which is a problem in combination with other functions that also do. Marking this one as noinline means that the stack slots get get reused between function calls - blogic_reportconfig() has a few large variables, but whenever it is not inlined into its caller, the compiler is actually smart enough to reuse stack slots for these automatically, so marking it as noinline saves most of the stack space by itself. The combination of both of these should avoid the problem entirely. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260203163321.2598593-1-arnd@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/scsi/BusLogic.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c index a86d780d1ba40..026c3e617cb1c 100644 --- a/drivers/scsi/BusLogic.c +++ b/drivers/scsi/BusLogic.c @@ -920,7 +920,8 @@ static int __init blogic_init_fp_probeinfo(struct blogi= c_adapter *adapter) a particular probe order. */ =20 -static void __init blogic_init_probeinfo_list(struct blogic_adapter *adapt= er) +static noinline_for_stack void __init +blogic_init_probeinfo_list(struct blogic_adapter *adapter) { /* If a PCI BIOS is present, interrogate it for MultiMaster and @@ -1690,7 +1691,8 @@ static bool __init blogic_rdconfig(struct blogic_adap= ter *adapter) blogic_reportconfig reports the configuration of Host Adapter. */ =20 -static bool __init blogic_reportconfig(struct blogic_adapter *adapter) +static noinline_for_stack bool __init +blogic_reportconfig(struct blogic_adapter *adapter) { unsigned short alltgt_mask =3D (1 << adapter->maxdev) - 1; unsigned short sync_ok, fast_ok; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C5093B2B90; Sat, 28 Feb 2026 17:38:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300316; cv=none; b=SUMU5CNK1QH5dxaX+2i0Cs3NmsniQyr+pdqJRwonDYcJdVIal/VKKPrECjITVEUqmVrmiWu90a6csOOViAJAih9uW5NUaX6v+CGOYaHFmknJoJl/sFfhgSne6N0UbDkiyj75xXR+faq8UIXQ2DhaRIGRREeKpBvuHiIaG6JEFiA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300316; c=relaxed/simple; bh=r4lrx2nj3u2+CGFN1JGcpYkK+fPBSPbhx/8GeLZs6mg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Wv01DHMR52jB7+gsfshkyWcCLivrgiaNl1SUCMGTeOApuvVIjiCfb81Vkc/GgpEQFsYYndBWB8wzsLFpBoeapH2LjkxIk37A2/6jMOTY6WZJp3ZFPTjooWGASaWF5C7vtcBpn+IU0yAHDjTMBq+DcdOUPuN1c3GHF7vuwBFIvno= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YelTuJbl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YelTuJbl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E147C116D0; Sat, 28 Feb 2026 17:38:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300316; bh=r4lrx2nj3u2+CGFN1JGcpYkK+fPBSPbhx/8GeLZs6mg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YelTuJblD8CBDS12Jl1X3eA0Cb12WRokL7kKTYC2wGB1VQtNAucncVAp3XGDp1V2p 1JBuuD18onHjAK/hMiVqsdw0KUBykuQ7KWen0vRa/PQW+CyR63Dl8CiBwoLXG3IupT uELD2zWmBCGzbLWLxErTHunE2yoGCnRYA87lYK6yAQB0wCjjUi2sEKbe5ehiisj/cD 1jR6oV+ZQnepr6sewuVADVSvZPF1wkQq5E7snknbLx9BlcNMfOpBIcqvpqA2rMf1Rz Wfa5q1/Czf5IisfE1JnroaWkO/CvQUk+eAwE9jrJeoJuVgrVXGiOpNQzaHQ26vZfw4 W1PvpPLspdaXA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kommula Shiva Shankar , Jason Wang , Jason Gunthorpe , "Michael S. Tsirkin" , Sasha Levin Subject: [PATCH 6.19 347/844] vhost: fix caching attributes of MMIO regions by setting them explicitly Date: Sat, 28 Feb 2026 12:24:20 -0500 Message-ID: <20260228173244.1509663-348-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kommula Shiva Shankar [ Upstream commit 5145b277309f3818e2db507f525d19ac3b910922 ] Explicitly set non-cached caching attributes for MMIO regions. Default write-back mode can cause CPU to cache device memory, causing invalid reads and unpredictable behavior. Invalid read and write issues were observed on ARM64 when mapping the notification area to userspace via mmap. Signed-off-by: Kommula Shiva Shankar Acked-by: Jason Wang Reviewed-by: Jason Gunthorpe Signed-off-by: Michael S. Tsirkin Message-Id: <20260102065703.656255-1-kshankar@marvell.com> Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/vhost/vdpa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index 05a481e4c385a..b0179e8567aba 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -1527,6 +1527,7 @@ static int vhost_vdpa_mmap(struct file *file, struct = vm_area_struct *vma) if (vma->vm_end - vma->vm_start !=3D notify.size) return -ENOTSUPP; =20 + vma->vm_page_prot =3D pgprot_noncached(vma->vm_page_prot); vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP); vma->vm_ops =3D &vhost_vdpa_vm_ops; return 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C144480DE3; Sat, 28 Feb 2026 17:38:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300317; cv=none; b=ojXc6xQcoXLQhhe1HtQbLecSRK4aqEBtFtuuOg/4khgocIh/HFUl0C8N0NtWQKWKAyiyt7l1+68YyZNJdJ+kNs/nv+Xn7BG1NBezHegWrxCjKkjm3lyKl4gxfSmlVM7thpI54QO7hrObcuCpNd/cOmtlM21ZYkopMN1Bn8sK7Vc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300317; c=relaxed/simple; bh=vKFYXOQmrz68V3Mdx2r/LwhN9YLy57iFoBXg0zOps+I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X3GFzmCR1uZdhOyv+98UjV4aDLJY01RQza/ANgJD4BcdTZgJwVvv3UgH/7V2X05rpM9uQeQq8yTHnIqMusAB+u+pY0h4tEZyLyqJmr95OxFVlWR7PW6nzw76aG/UIDDBAPAacw82FjQPso3tR0XQjXByGhN9DqDfwvUCKi938tc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M29XGtyT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M29XGtyT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72E00C19424; Sat, 28 Feb 2026 17:38:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300317; bh=vKFYXOQmrz68V3Mdx2r/LwhN9YLy57iFoBXg0zOps+I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M29XGtyTDfFn0UekGRnNBIr1hNZKV1ta4SmoF3grcdu6jTS6jxN09/A4YjLgKhmic uOYI93M2svQv7JOrZ86TPwUfu8ix+TWIOXoCTujwWUW5WfUYJyWwOlOcT7m44y9k+U cdkc+I1vbtRyDsg2+vzIWHTJdQDIZErqO5FRmrtPS4Z9lZOUSJTvjOEykl7HgKUDJg Iy069Ex438vNPnnnTXXrMDGt+RO2fFX/l6FlqfubEIJyfLaXFqud5siEdw1fquxZp9 ROD9SsrDnNtUld0p9Saf2P1KgJwptCiMAuNNgBiBQJW/HyQXmixr/2z9Dc/1gdd4ed ICMCJyVrMkfhQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Keita Morisaki , Peter Wang , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 6.19 348/844] scsi: ufs: mediatek: Fix page faults in ufs_mtk_clk_scale() trace event Date: Sat, 28 Feb 2026 12:24:21 -0500 Message-ID: <20260228173244.1509663-349-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Keita Morisaki [ Upstream commit 9672ed3de7d772ceddd713c769c05e832fc69bae ] The ufs_mtk_clk_scale() trace event currently stores the address of the name string directly via __field(const char *, name). This pointer may become invalid after the module is unloaded, causing page faults when the trace buffer is subsequently accessed. This can occur because the MediaTek UFS driver can be configured as a loadable module (tristate in Kconfig), meaning the name string passed to the trace event may reside in module memory that becomes invalid after module unload. Fix this by using __string() and __assign_str() to copy the string contents into the ring buffer instead of storing the pointer. This ensures the trace data remains valid regardless of module state. This change increases the memory usage for each ftrace entry by a few bytes (clock names are typically 7-15 characters like "ufs_sel" or "ufs_sel_max_src") compared to storing an 8-byte pointer. Note that this change does not affect anything unless all of the following conditions are met: - CONFIG_SCSI_UFS_MEDIATEK is enabled - ftrace tracing is enabled - The ufs_mtk_clk_scale event is enabled in ftrace Signed-off-by: Keita Morisaki Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260202024526.122515-1-keita.morisaki@tier4= .jp Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/ufs/host/ufs-mediatek-trace.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/ufs/host/ufs-mediatek-trace.h b/drivers/ufs/host/ufs-m= ediatek-trace.h index b5f2ec3140748..0df8ac843379a 100644 --- a/drivers/ufs/host/ufs-mediatek-trace.h +++ b/drivers/ufs/host/ufs-mediatek-trace.h @@ -33,19 +33,19 @@ TRACE_EVENT(ufs_mtk_clk_scale, TP_ARGS(name, scale_up, clk_rate), =20 TP_STRUCT__entry( - __field(const char*, name) + __string(name, name) __field(bool, scale_up) __field(unsigned long, clk_rate) ), =20 TP_fast_assign( - __entry->name =3D name; + __assign_str(name); __entry->scale_up =3D scale_up; __entry->clk_rate =3D clk_rate; ), =20 TP_printk("ufs: clk (%s) scaled %s @ %lu", - __entry->name, + __get_str(name), __entry->scale_up ? "up" : "down", __entry->clk_rate) ); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29EBD3B3418; Sat, 28 Feb 2026 17:38:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300318; cv=none; b=AydGjPAcHiLjVsz1M0N/aQfSjumwGbrZYVHRQwPc6saLoKPKv8lUG9pBMeGZGU5nOjXat4CLu4cJcXJEbs36dxxcAf6kbsgd6fIizK9FPOnhpY9ctcQerZ/euQImNr2oDSOSEamfXHNgL/BkIjfYICIquKKoPvQq0wRQAY9T5Aw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300318; c=relaxed/simple; bh=RcdWu7BakA3IUxlBsPgkVxCtelqX2FgPXyoYVc88DP8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AtBL+D1iwk6d4hhP3lrIRttZzfLwSs99OJgNvKLh2+qdj9aQhFO/B+XlDGZKH9NgljwNzR+WwWA4lQqK+h8+Bq0ILftrayGkTjyatuR8c7ozP4Wzvf28Yg8FBf7TW46aCYiJtM+c4SjkLKDAmR3+UsrJ7/plLV+PkOMDZI9eozk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QsUkqrKu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QsUkqrKu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62D9BC4AF09; Sat, 28 Feb 2026 17:38:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300318; bh=RcdWu7BakA3IUxlBsPgkVxCtelqX2FgPXyoYVc88DP8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QsUkqrKuBifVIxxCh6TK062IgahDaC7/vuRe/GOtuIWHCt+g3ildgicaInzKLrqid 0DcOMnohpj1YDlDp81KRTR+A9o5K3JZhdG1bdaLcms0E1UTA/67OF+Q2QsU72tuvO1 yL/3eTD5MFjW6RXvtZksu6pMdw2fqfQc45XBz8uYHwcPNyZ3eWdzjOGLqWuzjyvj7V cJyTxtI/RqE/jjhMYt8KPxhbWyjfBLHpQHSfEUScMb8AuLqHwTwwzUBJa/eQBZqFXQ kLlfrl86YwzMjwf3LAMdpDlLVcW3lJmSghVIqtu/VxeRxkTDoI471Rm3HWi+QGp9jE jK+L171zOEEWA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sergey Matyukevich , Andy Chiu , Paul Walmsley , Sasha Levin Subject: [PATCH 6.19 349/844] riscv: vector: init vector context with proper vlenb Date: Sat, 28 Feb 2026 12:24:22 -0500 Message-ID: <20260228173244.1509663-350-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sergey Matyukevich [ Upstream commit ef3ff40346db8476a9ef7269fc9d1837e7243c40 ] The vstate in thread_struct is zeroed when the vector context is initialized. That includes read-only register vlenb, which holds the vector register length in bytes. Zeroed state persists until mstatus.VS becomes 'dirty' and a context switch saves the actual hardware values. This can expose the zero vlenb value to the user-space in early debug scenarios, e.g. when ptrace attaches to a traced process early, before any vector instruction except the first one was executed. Fix this by specifying proper vlenb on vector context init. Signed-off-by: Sergey Matyukevich Reviewed-by: Andy Chiu Tested-by: Andy Chiu Link: https://patch.msgid.link/20251214163537.1054292-3-geomatsi@gmail.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/riscv/kernel/vector.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c index 3ed071dab9d83..b112166d51e9f 100644 --- a/arch/riscv/kernel/vector.c +++ b/arch/riscv/kernel/vector.c @@ -111,8 +111,8 @@ bool insn_is_vector(u32 insn_buf) return false; } =20 -static int riscv_v_thread_zalloc(struct kmem_cache *cache, - struct __riscv_v_ext_state *ctx) +static int riscv_v_thread_ctx_alloc(struct kmem_cache *cache, + struct __riscv_v_ext_state *ctx) { void *datap; =20 @@ -122,13 +122,15 @@ static int riscv_v_thread_zalloc(struct kmem_cache *c= ache, =20 ctx->datap =3D datap; memset(ctx, 0, offsetof(struct __riscv_v_ext_state, datap)); + ctx->vlenb =3D riscv_v_vsize / 32; + return 0; } =20 void riscv_v_thread_alloc(struct task_struct *tsk) { #ifdef CONFIG_RISCV_ISA_V_PREEMPTIVE - riscv_v_thread_zalloc(riscv_v_kernel_cachep, &tsk->thread.kernel_vstate); + riscv_v_thread_ctx_alloc(riscv_v_kernel_cachep, &tsk->thread.kernel_vstat= e); #endif } =20 @@ -214,12 +216,14 @@ bool riscv_v_first_use_handler(struct pt_regs *regs) * context where VS has been off. So, try to allocate the user's V * context and resume execution. */ - if (riscv_v_thread_zalloc(riscv_v_user_cachep, ¤t->thread.vstate)) { + if (riscv_v_thread_ctx_alloc(riscv_v_user_cachep, ¤t->thread.vstate= )) { force_sig(SIGBUS); return true; } + riscv_v_vstate_on(regs); riscv_v_vstate_set_restore(current, regs); + return true; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 725FB3B343E; Sat, 28 Feb 2026 17:38:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300319; cv=none; b=Bw8q+Uc+O6w3OhaVf9OLg4YSwDjKV790meeVFG+xdSFPfTauvv96m38P8yb1yswqNtO2OBVqxsjeS71+bKhKpxgaXcSGklHxm7+q7VZwhrjLlSWsMP9d+KUvjudKozCG7UAkdrq0KoxjCarowG0ML2rrUHI66XXyrYLhUajnJbw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300319; c=relaxed/simple; bh=eJSxD8m6JPX70xqr8kY9rAV2Of6LboOOQtQM4nRT1nc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ccFBsIYN/tFNL2mv431XOD5rD5YL2+hwo0aZs9LFiFraOiLRZSLvakRiycfu0+P4S1lFg1OfAwXL0vdvTDJahXRPI7uKc/c8ZbxWAJ5Bjo0IL2eJlW5toGOakn64LrH47UIS3Bs+GpHYqqmx8iOZzF8+73xtPFBlSgyOxCTzlTg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=prrriFa0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="prrriFa0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53B51C19425; Sat, 28 Feb 2026 17:38:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300319; bh=eJSxD8m6JPX70xqr8kY9rAV2Of6LboOOQtQM4nRT1nc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=prrriFa0JHmcox3R0ZrqsZ4G4xWc8Jx1BL7wzjAbbtog7IgSYVvwiiHaxAv3tVUKu 6D8Oqr2J/aM0bRwUKLTeE2SB9ZOrv7YZS2zllQHyAiO4szhXni8I4afxPSIKCBPpwO yHt5UrpPEgXVJuX8iZleVnQJAQPbrYL6ZoFJH8HCnZj/Qpv/+5ZZQ1SBeHUkHhorIj lUVytm6Xh11QMsuH1pzfzHUxykX/OsCyEKC3qPHmXfjkUkwlHb3mplvBqV8NHD2Mop 3GvF0FwT3kxBQFEm8waWryexF2p6gxXzl1pDn63aE/2pdOOEWu3jyEgyvG3ntB57Wx tANewmctiChNA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Colin Lord , Masami Hiramatsu , Mathieu Desnoyers , "Steven Rostedt (Google)" , Sasha Levin Subject: [PATCH 6.19 350/844] tracing: Fix false sharing in hwlat get_sample() Date: Sat, 28 Feb 2026 12:24:23 -0500 Message-ID: <20260228173244.1509663-351-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Colin Lord [ Upstream commit f743435f988cb0cf1f521035aee857851b25e06d ] The get_sample() function in the hwlat tracer assumes the caller holds hwlat_data.lock, but this is not actually happening. The result is unprotected data access to hwlat_data, and in per-cpu mode can result in false sharing which may show up as false positive latency events. The specific case of false sharing observed was primarily between hwlat_data.sample_width and hwlat_data.count. These are separated by just 8B and are therefore likely to share a cache line. When one thread modifies count, the cache line is in a modified state so when other threads read sample_width in the main latency detection loop, they fetch the modified cache line. On some systems, the fetch itself may be slow enough to count as a latency event, which could set up a self reinforcing cycle of latency events as each event increments count which then causes more latency events, continuing the cycle. The other result of the unprotected data access is that hwlat_data.count can end up with duplicate or missed values, which was observed on some systems in testing. Convert hwlat_data.count to atomic64_t so it can be safely modified without locking, and prevent false sharing by pulling sample_width into a local variable. One system this was tested on was a dual socket server with 32 CPUs on each numa node. With settings of 1us threshold, 1000us width, and 2000us window, this change reduced the number of latency events from 500 per second down to approximately 1 event per minute. Some machines tested did not exhibit measurable latency from the false sharing. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260210074810.6328-1-clord@mykolab.com Signed-off-by: Colin Lord Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/trace/trace_hwlat.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/kernel/trace/trace_hwlat.c b/kernel/trace/trace_hwlat.c index 2f7b94e98317c..3fe274b84f1c2 100644 --- a/kernel/trace/trace_hwlat.c +++ b/kernel/trace/trace_hwlat.c @@ -102,9 +102,9 @@ struct hwlat_sample { /* keep the global state somewhere. */ static struct hwlat_data { =20 - struct mutex lock; /* protect changes */ + struct mutex lock; /* protect changes */ =20 - u64 count; /* total since reset */ + atomic64_t count; /* total since reset */ =20 u64 sample_window; /* total sampling window (on+off) */ u64 sample_width; /* active sampling portion of window */ @@ -193,8 +193,7 @@ void trace_hwlat_callback(bool enter) * get_sample - sample the CPU TSC and look for likely hardware latencies * * Used to repeatedly capture the CPU TSC (or similar), looking for potent= ial - * hardware-induced latency. Called with interrupts disabled and with - * hwlat_data.lock held. + * hardware-induced latency. Called with interrupts disabled. */ static int get_sample(void) { @@ -204,6 +203,7 @@ static int get_sample(void) time_type start, t1, t2, last_t2; s64 diff, outer_diff, total, last_total =3D 0; u64 sample =3D 0; + u64 sample_width =3D READ_ONCE(hwlat_data.sample_width); u64 thresh =3D tracing_thresh; u64 outer_sample =3D 0; int ret =3D -1; @@ -267,7 +267,7 @@ static int get_sample(void) if (diff > sample) sample =3D diff; /* only want highest value */ =20 - } while (total <=3D hwlat_data.sample_width); + } while (total <=3D sample_width); =20 barrier(); /* finish the above in the view for NMIs */ trace_hwlat_callback_enabled =3D false; @@ -285,8 +285,7 @@ static int get_sample(void) if (kdata->nmi_total_ts) do_div(kdata->nmi_total_ts, NSEC_PER_USEC); =20 - hwlat_data.count++; - s.seqnum =3D hwlat_data.count; + s.seqnum =3D atomic64_inc_return(&hwlat_data.count); s.duration =3D sample; s.outer_duration =3D outer_sample; s.nmi_total_ts =3D kdata->nmi_total_ts; @@ -832,7 +831,7 @@ static int hwlat_tracer_init(struct trace_array *tr) =20 hwlat_trace =3D tr; =20 - hwlat_data.count =3D 0; + atomic64_set(&hwlat_data.count, 0); tr->max_latency =3D 0; save_tracing_thresh =3D tracing_thresh; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0BEE1480DE3; Sat, 28 Feb 2026 17:38:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300320; cv=none; b=LA+E7XoeQFcqwg4JCOPC5pwPgLyB6UM5NIyKHlHHsvz9DwJQ0ctPJUOsXW3DBiFoeasbkeGj3Ysfcl/jUmv1fwgbc564E91izzkZRkQfn/wyFpaVz8FGiSgiU9/C51wR3FelPmj6ckn0Pnixo1ccxcAjfSkKDmLIV249pqzSqP0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300320; c=relaxed/simple; bh=LI3nJcniRFCBMxwaHH5p2OMkM78vXd6UDnApdfZt3/k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NbZdqtLCP5mVs5cfMy91e5QXq4wL8akRGG4C4hOqzBwpuXT8G5Vp6xp0E4dWPdCnSXaGd/t5aKCIF8j+30QTyz1twyO3jauPXENEG7o3KirNS7XLHhYVTbACyKG1n66VKdlrSTIXOX1ljfam94snREAqwBDQdyenOfKtQlFFBfc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O05iDDkp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O05iDDkp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59E15C116D0; Sat, 28 Feb 2026 17:38:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300319; bh=LI3nJcniRFCBMxwaHH5p2OMkM78vXd6UDnApdfZt3/k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O05iDDkpKH6Q14Zrqvme4z1ycd6n9rqgxfR/jfNS/HCc2CkwzFTrQ4GKzXlmYLSL6 QA0XCbxuLYm4dm/Id2vS7NXKAQmo93wfkhdnHBYC0G832EycRgo6910iaN4WQNGJuL /NwbolANTt5U6UzOLKX0bz1wMqBRv2dfgMNXx6G6f8iEmuKfBZL02bQfkpniUpsiH4 xdPgyn+ExofFV5uX7u2tQU3+ft69BDEYailR9ag2GH1A/4ydl25sgaRjOfB+nGVWn8 pn9lnhRNFRnFFutcLZs3zn/c81poNYPgZ26f8DL4OMzEVRILtXG4j7VYjXs5bHlveT Tz476QX7Ch5Gg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Iuliana Prodan , Mathieu Poirier , Sasha Levin Subject: [PATCH 6.19 351/844] remoteproc: imx_dsp_rproc: Skip RP_MBOX_SUSPEND_SYSTEM when mailbox TX channel is uninitialized Date: Sat, 28 Feb 2026 12:24:24 -0500 Message-ID: <20260228173244.1509663-352-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Iuliana Prodan [ Upstream commit d62e0e92e589c53c4320ed5914af5fe103f5ce7e ] Firmwares that do not use mailbox communication (e.g., the hello_world sample) leave priv->tx_ch as NULL. The current suspend logic unconditionally sends RP_MBOX_SUSPEND_SYSTEM, which is invalid without an initialized TX channel. Detect the no_mailboxes case early and skip sending the suspend message. Instead, proceed directly to the runtime PM suspend path, which is the correct behavior for firmwares that cannot respond to mailbox requests. Signed-off-by: Iuliana Prodan Link: https://lore.kernel.org/r/20251204122825.756106-1-iuliana.prodan@oss.= nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/remoteproc/imx_dsp_rproc.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_ds= p_rproc.c index 5a9a8fa031f6d..9e4f50e0e822d 100644 --- a/drivers/remoteproc/imx_dsp_rproc.c +++ b/drivers/remoteproc/imx_dsp_rproc.c @@ -1260,6 +1260,15 @@ static int imx_dsp_suspend(struct device *dev) if (rproc->state !=3D RPROC_RUNNING) goto out; =20 + /* + * No channel available for sending messages; + * indicates no mailboxes present, so trigger PM runtime suspend + */ + if (!priv->tx_ch) { + dev_dbg(dev, "No initialized mbox tx channel, suspend directly.\n"); + goto out; + } + reinit_completion(&priv->pm_comp); =20 /* Tell DSP that suspend is happening */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EDC503B3BF9; Sat, 28 Feb 2026 17:38:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300321; cv=none; b=HkrqEiua3My+wlSI2G1VT8L3qr7zENtDg2AD6NPCmnHxHYvbUnTCcGbiJkdTB9YJr4VlodSReb/lfQKX9etVhfTVWwGQgDo2p90X8jxrgJYAVrenHQYXvBFBRvjCbG+eVuKfd/SYO6ackEgxZ7lrC9Dl+HHI9ODpOuH8yXEfv+8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300321; c=relaxed/simple; bh=l7MNXpfxHs18FIzzszA7gfEIQrfQvlOn0TBRcP4V6i4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rl+QIslZiEFhzpVhds224rNkRVSGW9HRjDVDflh6+JFrBvGt9mA3wxFFe22LWANi9asDNVRQvIzbVB83otvPuIVoTvLTYP2ACEnNguGv0rgrPboFEGLig4NVIiCtNyVQqCe//8fSy6R2IR6nuxL90xq7vgmRLWCU/uvIsvIWUOY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U6vj0w/h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U6vj0w/h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32424C19424; Sat, 28 Feb 2026 17:38:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300320; bh=l7MNXpfxHs18FIzzszA7gfEIQrfQvlOn0TBRcP4V6i4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U6vj0w/hjvDvo8eu2a75uUiCbbE45d1dtjR1+j+p9VMva1rTXrAnCkYO+ABEIjHuw GBClhex4nZYAyolvuYmOkLnfcaQ92DAO7aFJ8MA68/+b1cLeqsUXm+rGhEwhWNt5M0 thwIW8YRl2t9gT3stVwc0il2J+YK0qcOtyydMjmEuZCcHrRbtHZlEdwLy0OscOBo/J Pzrg7RkNo9Ilk6mI5fDLSEsIbB54jeopjugYRkXW8sJ/FzGxwaRpzCZPHh/qp0qE86 nfs3eB8Jbaeiqm2OJOiLxSgeFMqHNVADrbzyg7hB6nVwbMID2xm6179zVdMx3ndR7j 14PN0JU3GpUzA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Valentina Fernandez , Conor Dooley , Jassi Brar , Sasha Levin Subject: [PATCH 6.19 352/844] mailbox: mchp-ipc-sbi: fix out-of-bounds access in mchp_ipc_get_cluster_aggr_irq() Date: Sat, 28 Feb 2026 12:24:25 -0500 Message-ID: <20260228173244.1509663-353-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Valentina Fernandez [ Upstream commit f7c330a8c83c9b0332fd524097eaf3e69148164d ] The cluster_cfg array is dynamically allocated to hold per-CPU configuration structures, with its size based on the number of online CPUs. Previously, this array was indexed using hartid, which may be non-contiguous or exceed the bounds of the array, leading to out-of-bounds access. Switch to using cpuid as the index, as it is guaranteed to be within the valid range provided by for_each_online_cpu(). Signed-off-by: Valentina Fernandez Reviewed-by: Conor Dooley Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mailbox/mailbox-mchp-ipc-sbi.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/mailbox/mailbox-mchp-ipc-sbi.c b/drivers/mailbox/mailb= ox-mchp-ipc-sbi.c index a6e52009a4245..d444491a584e8 100644 --- a/drivers/mailbox/mailbox-mchp-ipc-sbi.c +++ b/drivers/mailbox/mailbox-mchp-ipc-sbi.c @@ -180,20 +180,20 @@ static irqreturn_t mchp_ipc_cluster_aggr_isr(int irq,= void *data) /* Find out the hart that originated the irq */ for_each_online_cpu(i) { hartid =3D cpuid_to_hartid_map(i); - if (irq =3D=3D ipc->cluster_cfg[hartid].irq) + if (irq =3D=3D ipc->cluster_cfg[i].irq) break; } =20 status_msg.cluster =3D hartid; - memcpy(ipc->cluster_cfg[hartid].buf_base, &status_msg, sizeof(struct mchp= _ipc_status)); + memcpy(ipc->cluster_cfg[i].buf_base, &status_msg, sizeof(struct mchp_ipc_= status)); =20 - ret =3D mchp_ipc_sbi_send(SBI_EXT_IPC_STATUS, ipc->cluster_cfg[hartid].bu= f_base_addr); + ret =3D mchp_ipc_sbi_send(SBI_EXT_IPC_STATUS, ipc->cluster_cfg[i].buf_bas= e_addr); if (ret < 0) { dev_err_ratelimited(ipc->dev, "could not get IHC irq status ret=3D%d\n",= ret); return IRQ_HANDLED; } =20 - memcpy(&status_msg, ipc->cluster_cfg[hartid].buf_base, sizeof(struct mchp= _ipc_status)); + memcpy(&status_msg, ipc->cluster_cfg[i].buf_base, sizeof(struct mchp_ipc_= status)); =20 /* * Iterate over each bit set in the IHC interrupt status register (IRQ_ST= ATUS) to identify @@ -385,21 +385,21 @@ static int mchp_ipc_get_cluster_aggr_irq(struct mchp_= ipc_sbi_mbox *ipc) if (ret <=3D 0) continue; =20 - ipc->cluster_cfg[hartid].irq =3D ret; - ret =3D devm_request_irq(ipc->dev, ipc->cluster_cfg[hartid].irq, + ipc->cluster_cfg[cpuid].irq =3D ret; + ret =3D devm_request_irq(ipc->dev, ipc->cluster_cfg[cpuid].irq, mchp_ipc_cluster_aggr_isr, IRQF_SHARED, "miv-ihc-irq", ipc); if (ret) return ret; =20 - ipc->cluster_cfg[hartid].buf_base =3D devm_kmalloc(ipc->dev, - sizeof(struct mchp_ipc_status), - GFP_KERNEL); + ipc->cluster_cfg[cpuid].buf_base =3D devm_kmalloc(ipc->dev, + sizeof(struct mchp_ipc_status), + GFP_KERNEL); =20 - if (!ipc->cluster_cfg[hartid].buf_base) + if (!ipc->cluster_cfg[cpuid].buf_base) return -ENOMEM; =20 - ipc->cluster_cfg[hartid].buf_base_addr =3D __pa(ipc->cluster_cfg[hartid]= .buf_base); + ipc->cluster_cfg[cpuid].buf_base_addr =3D __pa(ipc->cluster_cfg[cpuid].b= uf_base); =20 irq_found =3D true; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0513B3B3C1A; Sat, 28 Feb 2026 17:38:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300322; cv=none; b=FKpJw5+vWgT1yBezoPg/8Ovpo67JLdSuPGqIjFzWOf0UhUJG1yTv5c5SzPkEZQcDOjqxHOeL2kel9/BTq9QxBE9pR/SwN6xQLaLOBvtfox9qxZdXdOXlxf+yDTsgEuGSGXuJdG+ptyjTF0iZtnAUCEgATITI9zlvPfWCqGyc10U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300322; c=relaxed/simple; bh=p0/zZUD++Cy59dQpIM9ZPgWXbqQmfQZVC5X+V6bLGmQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bohXIekAFaQIrXy0/fzKf0UopZFZz/Mq/qwv8gPLhLO9+aMMksKdN7FXxxFtgNnjVF0S1Qtv55OkU4kl4NKqdTElUwzfDR0NkXwPXdc06HhgwFFS01Oa2E66x+EDiiRzSkrguLunZXiB+0pNZ0jCq88XojC1CzJAGGexqQ54R1o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jT3i7IJ/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jT3i7IJ/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 225BDC19425; Sat, 28 Feb 2026 17:38:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300321; bh=p0/zZUD++Cy59dQpIM9ZPgWXbqQmfQZVC5X+V6bLGmQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jT3i7IJ/YIoi8O5EiOBGy2SEc80BclKYifqTea9qZburtMR3aoo98YPuRS5bP4Piw O8+pmW+mHt7+41o58XA7Nrop2USGT1m727gzZljAJoanwZfrIWluDBaoHIQIaiwFbS TzjlsYqPq3Zdp8XduF5vJfaSLOt+ICj5x6hST7qBMloQg8DpfvzkdmVghwEexDgNwK L56dpjcd7uk8ZW4nHAAQGDf1aVrycEjEQh5gMJtms3kgY0vg1jkUFLnlwiz/cA1cUD gOtdDzgbpDmf5ynebSfH+TYKcDUwXbDxVLHL8YBj6IaSf5YlOolqyPH007uqxMI3gE vFzKL+d3iARzg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mark Brown , Aishwarya TCV , Sudeep Holla , Jassi Brar , Sasha Levin Subject: [PATCH 6.19 353/844] mailbox: pcc: Remove spurious IRQF_ONESHOT usage Date: Sat, 28 Feb 2026 12:24:26 -0500 Message-ID: <20260228173244.1509663-354-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mark Brown [ Upstream commit 673327028cd61db68a1e0c708be2e302c082adf9 ] The PCC code currently specifies IRQF_ONESHOT if the interrupt could potentially be shared but doesn't actually use request_threaded_irq() and the interrupt handler does not use IRQ_WAKE_THREAD so IRQF_ONESHOT is never relevant. Since commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler") specifying it has resulted in a WARN_ON(), fix this by removing IRQF_ONESHOT. Reported-by: Aishwarya TCV Signed-off-by: Mark Brown Reviewed-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mailbox/pcc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c index 0e0a66359d4c3..713022aed2e2f 100644 --- a/drivers/mailbox/pcc.c +++ b/drivers/mailbox/pcc.c @@ -459,7 +459,7 @@ static int pcc_startup(struct mbox_chan *chan) =20 if (pchan->plat_irq > 0) { irqflags =3D pcc_chan_plat_irq_can_be_shared(pchan) ? - IRQF_SHARED | IRQF_ONESHOT : 0; + IRQF_SHARED : 0; rc =3D devm_request_irq(chan->mbox->dev, pchan->plat_irq, pcc_mbox_irq, irqflags, MBOX_IRQ_NAME, chan); if (unlikely(rc)) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB8063B446D; Sat, 28 Feb 2026 17:38:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300323; cv=none; b=ZkcR5HHBP6R6K8aWpMT8b75oTxQH/DiM6+6RUUSXNlQEzHJCm1BNbUnu9ynw/mguLbvmizcZSKZgn3JFJ1DnossJ/xrdqHW+5spgzIKwtcAt9ZqNl+tq1JfNb2W9+WGbyH7WHrEExK4ppQw++OavhQ94UPZ6DKjKDxg3+6DG9b8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300323; c=relaxed/simple; bh=zewmezckcapVIGLR/SEXo0DCkA/JWHsz4NUGR/Ja8jA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NjQbpLJ5114PaCPS2a2cqRkuVxNTd/UzFbPrPxyrqU9hGVr/cYO2iCXraxGssTOSqBWNj/zKkJdBzOUkHrTw+O/9LczmZVOkek3OgYTq4KY2tStJZ22Dh7i6ZxJ/cxqMXLB91cVNu3JLWPmtlgws4lRl/gPKlOxR63/unB8cNbo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ExDCBBPk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ExDCBBPk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C9B9C116D0; Sat, 28 Feb 2026 17:38:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300322; bh=zewmezckcapVIGLR/SEXo0DCkA/JWHsz4NUGR/Ja8jA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ExDCBBPk5VpTveT8Y6pqBlPviUCufbkZoTRHMsYXZrQ4nRP3J1SbEhzrY0JxrGlHb sImfazxeT8dI8yTK3hP3zGH8QbuLWJNgeSHni9IuVVnlguAZHY2wUc2sEpWuZ9ejkt WqZNyqet8Segc0ruX4QIOs1W3OpIl4riKeTehsurZGqV5bi08HtHvszgenN2O9M1sw PoC57gh5qLq+QM0MFKCJ3eXjts9P2do6/SyhYwHyjYRsGU8oP9UrL+6fj5f0g7boE/ d+4a2ufmQh+MHOj7NTAIt4Vise0eYwak9g2Jg1f/KXHPLMWSP4yNiIBCp4j0C5ewbD w5ehH0YXs8+Kg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jacky Bai , Peng Fan , Jassi Brar , Sasha Levin Subject: [PATCH 6.19 354/844] mailbox: imx: Skip the suspend flag for i.MX7ULP Date: Sat, 28 Feb 2026 12:24:27 -0500 Message-ID: <20260228173244.1509663-355-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jacky Bai [ Upstream commit 673b570825ace0dcb2ac0c676080559d505c6f40 ] In current imx-mailbox driver, the MU IRQ is configured with 'IRQF_NO_SUSPEND' flag set. So during linux suspend/resume flow, the MU IRQ is always enabled. With commit 892cb524ae8a ("mailbox: imx: fix wakeup failure from freeze mode"), if the MU IRQ is triggered after the priv->suspended flag has been set, the system suspend will be aborted. On i.MX7ULP platform, certain drivers that depend on rpmsg may need to send rpmsg request and receive an acknowledgment from the remote core during the late_suspend stage. Early suspend abort is not expected, and the i.MX7ULP already has additional hardware and software to make sure the system can be wakeup from freeze mode correctly when MU IRQ is trigger. Skip the 'suspend' flag handling logic on i.MX7ULP to avoid the early abort when doing suspend. Signed-off-by: Jacky Bai Reviewed-by: Peng Fan Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mailbox/imx-mailbox.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c index 6778afc64a048..003f9236c35e0 100644 --- a/drivers/mailbox/imx-mailbox.c +++ b/drivers/mailbox/imx-mailbox.c @@ -122,6 +122,7 @@ struct imx_mu_dcfg { u32 xRR; /* Receive Register0 */ u32 xSR[IMX_MU_xSR_MAX]; /* Status Registers */ u32 xCR[IMX_MU_xCR_MAX]; /* Control Registers */ + bool skip_suspend_flag; }; =20 #define IMX_MU_xSR_GIPn(type, x) (type & IMX_MU_V2 ? BIT(x) : BIT(28 + (3 = - (x)))) @@ -988,6 +989,7 @@ static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp =3D { .xRR =3D 0x40, .xSR =3D {0x60, 0x60, 0x60, 0x60}, .xCR =3D {0x64, 0x64, 0x64, 0x64, 0x64}, + .skip_suspend_flag =3D true, }; =20 static const struct imx_mu_dcfg imx_mu_cfg_imx8ulp =3D { @@ -1071,7 +1073,8 @@ static int __maybe_unused imx_mu_suspend_noirq(struct= device *dev) priv->xcr[i] =3D imx_mu_read(priv, priv->dcfg->xCR[i]); } =20 - priv->suspend =3D true; + if (!priv->dcfg->skip_suspend_flag) + priv->suspend =3D true; =20 return 0; } @@ -1094,7 +1097,8 @@ static int __maybe_unused imx_mu_resume_noirq(struct = device *dev) imx_mu_write(priv, priv->xcr[i], priv->dcfg->xCR[i]); } =20 - priv->suspend =3D false; + if (!priv->dcfg->skip_suspend_flag) + priv->suspend =3D false; =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF1BF3B4489; Sat, 28 Feb 2026 17:38:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300324; cv=none; b=MWgJn4cdh4xhb9znP7PfTAeIaGasXDt/iV5fcMkjJ8k+cDPNXpY2mS9LSDGywq4hJUWYFUizzYK+BArTMifjuWKdRLXS3wD6p8IWyjlpgOhU8Lq8MVHxINV2W55/QVtQ8WxYZlj1rurSrX982K2uYyMzdUbTW3yu1dKiHEjFgsg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300324; c=relaxed/simple; bh=aLpQTaDCsoaCt2G3eAu3tYCXL6/FwZb475hYCkU+bTk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eX01DqG2EH2lHLZTfGhERwqU4027+QH3uunkCyDrqoIGt0xrg1z9oWsavXRQSnZA+OR/KSVVcPyV3NMLw2F2mXxXK29+ITwkofTnw5wZvLkmLFSa5XfYuWbdT+mhcMIHx71O06iYYkcTOqrSbphEdEK7iejtSA/Vb9SJAXaI2A8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H4nu0aP8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H4nu0aP8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F85FC116D0; Sat, 28 Feb 2026 17:38:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300323; bh=aLpQTaDCsoaCt2G3eAu3tYCXL6/FwZb475hYCkU+bTk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H4nu0aP8aS83hPXFGD/b8DfFuEpPnjp8DV9BEnjYD4mcuLCS0lz98dniAQgrgWhFx 6QcK1Do1PtbRJf0QWH3/6Gvgr3Ro56SqE0CdPvruNIsFUKHk0IEVRG7bgBGIjXaN3a Tfoj3GSsqAaf+MtFnEj32U6QfiQKb3aitzPXSkirXGFIoEHRPRVih2Uup8eTVuMgVJ l/x6fp45qXP2Q+pUv+jwSvSfWmfgz3RcKXdoIUEi1pzJRb+NGOqp4jO3SxmFpn5V29 ipKPwnDRAUIrmXRXhXI1boArEI3YqV7ujvXcHWT5kLiNXAk6GWr/qcWCsSVD9zqcV2 aSkCpFZf+VRLw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Valentina Fernandez , kernel test robot , Dan Carpenter , Jassi Brar , Sasha Levin Subject: [PATCH 6.19 355/844] mailbox: mchp-ipc-sbi: fix uninitialized symbol and other smatch warnings Date: Sat, 28 Feb 2026 12:24:28 -0500 Message-ID: <20260228173244.1509663-356-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Valentina Fernandez [ Upstream commit bc4d17e495cd3b02bcb2e10f575763a5ff31f80b ] Fix uninitialized symbol 'hartid' warning in mchp_ipc_cluster_aggr_isr() by introducing a 'found' flag to track whether the IRQ matches any online hart. If no match is found, return IRQ_NONE. Also fix other smatch warnings by removing dead code in mchp_ipc_startup() and by returning -ENODEV in dev_err_probe() if the Microchip SBI extension is not found. Fixes below smatch warnings: drivers/mailbox/mailbox-mchp-ipc-sbi.c:187 mchp_ipc_cluster_aggr_isr() erro= r: uninitialized symbol 'hartid'. drivers/mailbox/mailbox-mchp-ipc-sbi.c:324 mchp_ipc_startup() warn: ignorin= g unreachable code. drivers/mailbox/mailbox-mchp-ipc-sbi.c:422 mchp_ipc_probe() warn: passing z= ero to 'dev_err_probe' Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202512171533.CDLdScMY-lkp@intel.com/ Signed-off-by: Valentina Fernandez Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mailbox/mailbox-mchp-ipc-sbi.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/drivers/mailbox/mailbox-mchp-ipc-sbi.c b/drivers/mailbox/mailb= ox-mchp-ipc-sbi.c index d444491a584e8..b87bf2fb4b9b9 100644 --- a/drivers/mailbox/mailbox-mchp-ipc-sbi.c +++ b/drivers/mailbox/mailbox-mchp-ipc-sbi.c @@ -174,17 +174,21 @@ static irqreturn_t mchp_ipc_cluster_aggr_isr(int irq,= void *data) struct mchp_ipc_msg ipc_msg; struct mchp_ipc_status status_msg; int ret; - unsigned long hartid; u32 i, chan_index, chan_id; + bool found =3D false; =20 /* Find out the hart that originated the irq */ for_each_online_cpu(i) { - hartid =3D cpuid_to_hartid_map(i); - if (irq =3D=3D ipc->cluster_cfg[i].irq) + if (irq =3D=3D ipc->cluster_cfg[i].irq) { + found =3D true; break; + } } =20 - status_msg.cluster =3D hartid; + if (unlikely(!found)) + return IRQ_NONE; + + status_msg.cluster =3D cpuid_to_hartid_map(i); memcpy(ipc->cluster_cfg[i].buf_base, &status_msg, sizeof(struct mchp_ipc_= status)); =20 ret =3D mchp_ipc_sbi_send(SBI_EXT_IPC_STATUS, ipc->cluster_cfg[i].buf_bas= e_addr); @@ -321,13 +325,6 @@ static int mchp_ipc_startup(struct mbox_chan *chan) goto fail_free_buf_msg_rx; } =20 - if (ret) { - dev_err(ipc->dev, "failed to register interrupt(s)\n"); - goto fail_free_buf_msg_rx; - } - - return ret; - fail_free_buf_msg_rx: kfree(chan_info->msg_buf_rx); fail_free_buf_msg_tx: @@ -419,7 +416,7 @@ static int mchp_ipc_probe(struct platform_device *pdev) =20 ret =3D sbi_probe_extension(SBI_EXT_MICROCHIP_TECHNOLOGY); if (ret <=3D 0) - return dev_err_probe(dev, ret, "Microchip SBI extension not detected\n"); + return dev_err_probe(dev, -ENODEV, "Microchip SBI extension not detected= \n"); =20 ipc =3D devm_kzalloc(dev, sizeof(*ipc), GFP_KERNEL); if (!ipc) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1567B480DE3; Sat, 28 Feb 2026 17:38:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300325; cv=none; b=q4a6C5ct2CyMTe/76F1gdx1q9Zj8Sz3j4A+bkHrQwRS096bkus46fAV43UlX+Co4GtliBs0HNzR2Hlhve+++1f5qgRPSO6Tq4d8tLmyn0xZ85GGSYiDzLdYcBylR7ZektV8q//u6rRA/biRd2YER6hNtHTDGmHDZ9K+7ECS6ads= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300325; c=relaxed/simple; bh=NwjbWlJVFuM2LLQdrqo6HtOXS/ngQ5Uh0I5P+jPDxCM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=X43vw2jVxxHavd38XvmzLeifF4ZEqcc2zNC1GDZswIDOq4dzQ9OnsGvpeRBnfUMAr4iwCJ+0UdoQAW2ijHQcOghcS8RX1SNtxsJJ3yjPqka+NwG4K2W5YH4Dn+z4rzb8ldCTgo3WW4DxsjXYUnfF9hocUw/6saDMqL6oj+v+p7M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=crXwxs4L; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="crXwxs4L" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 250E4C19423; Sat, 28 Feb 2026 17:38:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300324; bh=NwjbWlJVFuM2LLQdrqo6HtOXS/ngQ5Uh0I5P+jPDxCM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=crXwxs4Ly7S3oKZUXNrOwcICKXb6kKFE9qKATSFIPED5aoB+62ysk2ZviFzF3Edsm 7E1LARVVqEBOiSFvunWSREvcuc85tjZ4vVpyXhksibJ7iuBe90ChJp7oLZTZC+c0IV TQPfoUjdwccR4zqlfGrssD8q+5OXWdq5BSsuf2BMQpT1Zbk8M2SsEGY3WMKbEsdQYS lGaoA3n9ImMYNBcJ2j7RNmirmb5tkhcmTZbWkWZHUCQtRhz1H0XA035VE+I/zuGFr4 T4JlkI+RJYbapvWmlkEx/b6ncQh34C4zi02tM512A5S8KmNzHX//cz4fPkHkZ422be 8TT2tqZnLiRZw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Otto=20Pfl=C3=BCger?= , Jassi Brar , Sasha Levin Subject: [PATCH 6.19 356/844] mailbox: sprd: mask interrupts that are not handled Date: Sat, 28 Feb 2026 12:24:29 -0500 Message-ID: <20260228173244.1509663-357-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Otto Pfl=C3=BCger [ Upstream commit 75df94d05fc03fd9d861eaf79ce10fbb7a548bd8 ] To reduce the amount of spurious interrupts, disable the interrupts that are not handled in this driver. Signed-off-by: Otto Pfl=C3=BCger Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mailbox/sprd-mailbox.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/mailbox/sprd-mailbox.c b/drivers/mailbox/sprd-mailbox.c index ee8539dfcef54..c1a5fe6cc8771 100644 --- a/drivers/mailbox/sprd-mailbox.c +++ b/drivers/mailbox/sprd-mailbox.c @@ -243,21 +243,19 @@ static int sprd_mbox_startup(struct mbox_chan *chan) /* Select outbox FIFO mode and reset the outbox FIFO status */ writel(0x0, priv->outbox_base + SPRD_MBOX_FIFO_RST); =20 - /* Enable inbox FIFO overflow and delivery interrupt */ - val =3D readl(priv->inbox_base + SPRD_MBOX_IRQ_MSK); - val &=3D ~(SPRD_INBOX_FIFO_OVERFLOW_IRQ | SPRD_INBOX_FIFO_DELIVER_IRQ); + /* Enable inbox FIFO delivery interrupt */ + val =3D SPRD_INBOX_FIFO_IRQ_MASK; + val &=3D ~SPRD_INBOX_FIFO_DELIVER_IRQ; writel(val, priv->inbox_base + SPRD_MBOX_IRQ_MSK); =20 /* Enable outbox FIFO not empty interrupt */ - val =3D readl(priv->outbox_base + SPRD_MBOX_IRQ_MSK); + val =3D SPRD_OUTBOX_FIFO_IRQ_MASK; val &=3D ~SPRD_OUTBOX_FIFO_NOT_EMPTY_IRQ; writel(val, priv->outbox_base + SPRD_MBOX_IRQ_MSK); =20 /* Enable supplementary outbox as the fundamental one */ if (priv->supp_base) { writel(0x0, priv->supp_base + SPRD_MBOX_FIFO_RST); - val =3D readl(priv->supp_base + SPRD_MBOX_IRQ_MSK); - val &=3D ~SPRD_OUTBOX_FIFO_NOT_EMPTY_IRQ; writel(val, priv->supp_base + SPRD_MBOX_IRQ_MSK); } } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E64D73B4CED; Sat, 28 Feb 2026 17:38:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300326; cv=none; b=UTutuvb1IoUJazXqHqBReH3elDqh+E87F95xP9PYzJBz79KXxYiRGMSu+vIkfoWOqKOB3zc4UnWOMsho5RHkZzBS44reVSdf6rzwlHPiBZ5mB5kOphR4SKaZkStrFttBseM4KRDjYLWs/lyrH3HrsBuDYhLEJGmZOVquYJpqQpA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300326; c=relaxed/simple; bh=/xayTRITuOFmRiReUOG1S0Z7no1I7nxm+HbPt9IU6NM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AkXGTvRGy/Vgo/wEYRgPvN8pHNlY+548GYD2iDJlKWDKl9Wniz7aedZReqOZjyvDO/Xctv+U1VF0CrQ9EWPM8W4LDGpe9vyV4ABWV3p716PlUW38FQL+y9fbpYqPvMa/V604DK9qfmzMN97vTBoc1z6SOiA0atd2kzIoEevQCEQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YFJ7xapw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YFJ7xapw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF99AC19424; Sat, 28 Feb 2026 17:38:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300325; bh=/xayTRITuOFmRiReUOG1S0Z7no1I7nxm+HbPt9IU6NM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YFJ7xapw0Sd8NRcdsiA891uGwqvdpV4mwMCIlbYgufhQgV4Kgip2FcW16L+dZqj5a xR9jyeE0u8C0y7zKIhVADzr+yAqPKM9nuDETMQyqnDJd1ZnDjUMXnTOoCjpNBX14L7 k/nVVGNt7fuhxbuV7g7051B/upLCY7H+EEqrOH9VIO4xyiJY6wSi1peuEAB6bSFvAC 3eoXR7sZe0jdkrw+884WNUAwQtalTsI+7P6cOPwkiXRUZgz7+xcfL+tfRSPCY8hQBl HzRLzx4MZW7SSeIuEJQVpEH8DQugVfkxWBWAgj4jCvnvL3+QjxmI6j9A5DSIcpgqbD Nnvhttuuy5Mkg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tzung-Bi Shih , Chen-Yu Tsai , Mathieu Poirier , Sasha Levin Subject: [PATCH 6.19 357/844] remoteproc: mediatek: Break lock dependency to `prepare_lock` Date: Sat, 28 Feb 2026 12:24:30 -0500 Message-ID: <20260228173244.1509663-358-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tzung-Bi Shih [ Upstream commit d935187cfb27fc4168f78f3959aef4eafaae76bb ] A potential circular locking dependency (ABBA deadlock) exists between `ec_dev->lock` and the clock framework's `prepare_lock`. The first order (A -> B) occurs when scp_ipi_send() is called while `ec_dev->lock` is held (e.g., within cros_ec_cmd_xfer()): 1. cros_ec_cmd_xfer() acquires `ec_dev->lock` and calls scp_ipi_send(). 2. scp_ipi_send() calls clk_prepare_enable(), which acquires `prepare_lock`. See #0 in the following example calling trace. (Lock Order: `ec_dev->lock` -> `prepare_lock`) The reverse order (B -> A) is more complex and has been observed (learned) by lockdep. It involves the clock prepare operation triggering power domain changes, which then propagates through sysfs and power supply uevents, eventually calling back into the ChromeOS EC driver and attempting to acquire `ec_dev->lock`: 1. Something calls clk_prepare(), which acquires `prepare_lock`. It then triggers genpd operations like genpd_runtime_resume(), which takes `&genpd->mlock`. 2. Power domain changes can trigger regulator changes; regulator changes can then trigger device link changes; device link changes can then trigger sysfs changes. Eventually, power_supply_uevent() is called. 3. This leads to calls like cros_usbpd_charger_get_prop(), which calls cros_ec_cmd_xfer_status(), which then attempts to acquire `ec_dev->lock`. See #1 ~ #6 in the following example calling trace. (Lock Order: `prepare_lock` -> `&genpd->mlock` -> ... -> `&ec_dev->lock`) Move the clk_prepare()/clk_unprepare() operations for `scp->clk` to the remoteproc prepare()/unprepare() callbacks. This ensures `prepare_lock` is only acquired in prepare()/unprepare() callbacks. Since `ec_dev->lock` is not involved in the callbacks, the dependency loop is broken. This means the clock is always "prepared" when the SCP is running. The prolonged "prepared time" for the clock should be acceptable as SCP is designed to be a very power efficient processor. The power consumption impact can be negligible. A simplified calling trace reported by lockdep: > -> #6 (&ec_dev->lock) > cros_ec_cmd_xfer > cros_ec_cmd_xfer_status > cros_usbpd_charger_get_port_status > cros_usbpd_charger_get_prop > power_supply_get_property > power_supply_show_property > power_supply_uevent > dev_uevent > uevent_show > dev_attr_show > sysfs_kf_seq_show > kernfs_seq_show > -> #5 (kn->active#2) > kernfs_drain > __kernfs_remove > kernfs_remove_by_name_ns > sysfs_remove_file_ns > device_del > __device_link_del > device_links_driver_bound > -> #4 (device_links_lock) > device_link_remove > _regulator_put > regulator_put > -> #3 (regulator_list_mutex) > regulator_lock_dependent > regulator_disable > scpsys_power_off > _genpd_power_off > genpd_power_off > -> #2 (&genpd->mlock/1) > genpd_add_subdomain > pm_genpd_add_subdomain > scpsys_add_subdomain > scpsys_probe > -> #1 (&genpd->mlock) > genpd_runtime_resume > __rpm_callback > rpm_callback > rpm_resume > __pm_runtime_resume > clk_core_prepare > clk_prepare > -> #0 (prepare_lock) > clk_prepare > scp_ipi_send > scp_send_ipi > mtk_rpmsg_send > rpmsg_send > cros_ec_pkt_xfer_rpmsg Signed-off-by: Tzung-Bi Shih Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20260112110755.2435899-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/remoteproc/mtk_scp.c | 39 +++++++++++++++++++++++--------- drivers/remoteproc/mtk_scp_ipi.c | 4 ++-- 2 files changed, 30 insertions(+), 13 deletions(-) diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c index db8fd045468d9..98d00bd5200cc 100644 --- a/drivers/remoteproc/mtk_scp.c +++ b/drivers/remoteproc/mtk_scp.c @@ -283,7 +283,7 @@ static irqreturn_t scp_irq_handler(int irq, void *priv) struct mtk_scp *scp =3D priv; int ret; =20 - ret =3D clk_prepare_enable(scp->clk); + ret =3D clk_enable(scp->clk); if (ret) { dev_err(scp->dev, "failed to enable clocks\n"); return IRQ_NONE; @@ -291,7 +291,7 @@ static irqreturn_t scp_irq_handler(int irq, void *priv) =20 scp->data->scp_irq_handler(scp); =20 - clk_disable_unprepare(scp->clk); + clk_disable(scp->clk); =20 return IRQ_HANDLED; } @@ -665,7 +665,7 @@ static int scp_load(struct rproc *rproc, const struct f= irmware *fw) struct device *dev =3D scp->dev; int ret; =20 - ret =3D clk_prepare_enable(scp->clk); + ret =3D clk_enable(scp->clk); if (ret) { dev_err(dev, "failed to enable clocks\n"); return ret; @@ -680,7 +680,7 @@ static int scp_load(struct rproc *rproc, const struct f= irmware *fw) =20 ret =3D scp_elf_load_segments(rproc, fw); leave: - clk_disable_unprepare(scp->clk); + clk_disable(scp->clk); =20 return ret; } @@ -691,14 +691,14 @@ static int scp_parse_fw(struct rproc *rproc, const st= ruct firmware *fw) struct device *dev =3D scp->dev; int ret; =20 - ret =3D clk_prepare_enable(scp->clk); + ret =3D clk_enable(scp->clk); if (ret) { dev_err(dev, "failed to enable clocks\n"); return ret; } =20 ret =3D scp_ipi_init(scp, fw); - clk_disable_unprepare(scp->clk); + clk_disable(scp->clk); return ret; } =20 @@ -709,7 +709,7 @@ static int scp_start(struct rproc *rproc) struct scp_run *run =3D &scp->run; int ret; =20 - ret =3D clk_prepare_enable(scp->clk); + ret =3D clk_enable(scp->clk); if (ret) { dev_err(dev, "failed to enable clocks\n"); return ret; @@ -734,14 +734,14 @@ static int scp_start(struct rproc *rproc) goto stop; } =20 - clk_disable_unprepare(scp->clk); + clk_disable(scp->clk); dev_info(dev, "SCP is ready. FW version %s\n", run->fw_ver); =20 return 0; =20 stop: scp->data->scp_reset_assert(scp); - clk_disable_unprepare(scp->clk); + clk_disable(scp->clk); return ret; } =20 @@ -909,7 +909,7 @@ static int scp_stop(struct rproc *rproc) struct mtk_scp *scp =3D rproc->priv; int ret; =20 - ret =3D clk_prepare_enable(scp->clk); + ret =3D clk_enable(scp->clk); if (ret) { dev_err(scp->dev, "failed to enable clocks\n"); return ret; @@ -917,12 +917,29 @@ static int scp_stop(struct rproc *rproc) =20 scp->data->scp_reset_assert(scp); scp->data->scp_stop(scp); - clk_disable_unprepare(scp->clk); + clk_disable(scp->clk); =20 return 0; } =20 +static int scp_prepare(struct rproc *rproc) +{ + struct mtk_scp *scp =3D rproc->priv; + + return clk_prepare(scp->clk); +} + +static int scp_unprepare(struct rproc *rproc) +{ + struct mtk_scp *scp =3D rproc->priv; + + clk_unprepare(scp->clk); + return 0; +} + static const struct rproc_ops scp_ops =3D { + .prepare =3D scp_prepare, + .unprepare =3D scp_unprepare, .start =3D scp_start, .stop =3D scp_stop, .load =3D scp_load, diff --git a/drivers/remoteproc/mtk_scp_ipi.c b/drivers/remoteproc/mtk_scp_= ipi.c index c068227e251e7..7a37e273b3af8 100644 --- a/drivers/remoteproc/mtk_scp_ipi.c +++ b/drivers/remoteproc/mtk_scp_ipi.c @@ -171,7 +171,7 @@ int scp_ipi_send(struct mtk_scp *scp, u32 id, void *buf= , unsigned int len, WARN_ON(len > scp_sizes->ipi_share_buffer_size) || WARN_ON(!buf)) return -EINVAL; =20 - ret =3D clk_prepare_enable(scp->clk); + ret =3D clk_enable(scp->clk); if (ret) { dev_err(scp->dev, "failed to enable clock\n"); return ret; @@ -211,7 +211,7 @@ int scp_ipi_send(struct mtk_scp *scp, u32 id, void *buf= , unsigned int len, =20 unlock_mutex: mutex_unlock(&scp->send_lock); - clk_disable_unprepare(scp->clk); + clk_disable(scp->clk); =20 return ret; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98A483B4D06; Sat, 28 Feb 2026 17:38:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300326; cv=none; b=QgtF15CbnWwlLz8zEEvGiNQeGpY2WGoJMhr2TUosdgJlcqi2WlF+9xlVVj0me5+J370afPM63nWmDjJd7cuXBYGK8VoIjgcahnVrb+bKmYyBmI/XbtWXQ6hJascw0lxeCi5HGFkWuJUB8S1JFwyB71hkhzGORfQQwE0H5TDf8Uo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300326; c=relaxed/simple; bh=XEa/VH/PEJZzdsCFQkRXMz14ayIsfwmMUepq86+UQWc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OIErqMKazovt9IIHtSl0M0zcAfnJEOFI9AEcctAXKxDWz8HwE75xztSOwFZ0qbyzikFrOJcvAvraKDFEGG2B2ZXnO7kQWUjm43x8099Jnex1vBWisG0HRcghxnGLnfR7nv5+wdKhFRbB+jVu0MddpWtEopDWfsivEC3X7S2ZGhU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ns7TJavv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ns7TJavv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2CA7C19425; Sat, 28 Feb 2026 17:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300326; bh=XEa/VH/PEJZzdsCFQkRXMz14ayIsfwmMUepq86+UQWc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ns7TJavvSRfdAhclFXjM8KJ21i+BB2K4JLLlOlylp6JCfI6wtUJrhnx8NzQ1bL/EY FLDbeRK007apfyJqfuMJF+szVqmlIbrk5HiSRQvlDPUllxDEDHkFkEAsDHykpWEQ4M SZeXU8A+L/zVpeZ27t8zlgeZe4rWr3FenvjNJ6OmWrapTy8RxPCks+7AoXVDCQkACb Q+V28AiEARQjxjbiboXHh3OnmtKJcgnHBDMHWd+wEnjX09BiFWL7FR6crtagH9FDEh 21geNhl/xrEXR3JF2ql1R3GqtOIL+CRKfL0O3wPfCHXjZIgN2r0GY3VOqeUaSUag23 j/qJMSktQOgwg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Otto=20Pfl=C3=BCger?= , Jassi Brar , Sasha Levin Subject: [PATCH 6.19 358/844] mailbox: sprd: clear delivery flag before handling TX done Date: Sat, 28 Feb 2026 12:24:31 -0500 Message-ID: <20260228173244.1509663-359-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Otto Pfl=C3=BCger [ Upstream commit c77661d60d4223bf2ff10d409beb0c3b2021183b ] If there are any pending messages in the mailbox queue, they are sent as soon as a TX done event arrives from the driver. This may trigger a new delivery interrupt while the previous one is still being handled. If the delivery status is cleared after this, the interrupt is lost. To prevent this from happening, clear the delivery status immediately after checking it and before any new messages are sent. Signed-off-by: Otto Pfl=C3=BCger Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mailbox/sprd-mailbox.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/mailbox/sprd-mailbox.c b/drivers/mailbox/sprd-mailbox.c index c1a5fe6cc8771..46d0c34177ab9 100644 --- a/drivers/mailbox/sprd-mailbox.c +++ b/drivers/mailbox/sprd-mailbox.c @@ -166,6 +166,11 @@ static irqreturn_t sprd_mbox_inbox_isr(int irq, void *= data) return IRQ_NONE; } =20 + /* Clear FIFO delivery and overflow status first */ + writel(fifo_sts & + (SPRD_INBOX_FIFO_DELIVER_MASK | SPRD_INBOX_FIFO_OVERLOW_MASK), + priv->inbox_base + SPRD_MBOX_FIFO_RST); + while (send_sts) { id =3D __ffs(send_sts); send_sts &=3D (send_sts - 1); @@ -181,11 +186,6 @@ static irqreturn_t sprd_mbox_inbox_isr(int irq, void *= data) mbox_chan_txdone(chan, 0); } =20 - /* Clear FIFO delivery and overflow status */ - writel(fifo_sts & - (SPRD_INBOX_FIFO_DELIVER_MASK | SPRD_INBOX_FIFO_OVERLOW_MASK), - priv->inbox_base + SPRD_MBOX_FIFO_RST); - /* Clear irq status */ writel(SPRD_MBOX_IRQ_CLR, priv->inbox_base + SPRD_MBOX_IRQ_STS); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C244B3B4489; Sat, 28 Feb 2026 17:38:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300327; cv=none; b=tzh+yWhfm6rmTzi3yMzsR0tW7Loqmdo17bxSP9cc+7dI7WSsaHTaYyCosYqpyhkyRUSFks10AIuIe0pXb4RkErVjKxzdObJBVFwivMjQXgWLeRkWMogIvPBusnV9aFndwnEmsRnrMxcjJehvLrHr1FJIBzrPvJO8QH0OGILoUC0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300327; c=relaxed/simple; bh=/4RIoFWQvmnECXfpoZ2li00lAcsTSHybmqIwvfbhU54=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b/RrUch9MBDPEhEJ38dqWMKsuSB0R7ziS1SAAdoBFcViL860BgJSHjHskCY0Kzv6Ak8k5uykuGER+pHDHJdy3oo+BU7u+ohQ86yHhwXhYbV0xG0DL882LbftHMejNU6FE8Lsemr3woMq8STMUzV6O08YGEfEyUnONq2I7bsuM8w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dKEnZ6P5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dKEnZ6P5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF930C19424; Sat, 28 Feb 2026 17:38:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300327; bh=/4RIoFWQvmnECXfpoZ2li00lAcsTSHybmqIwvfbhU54=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dKEnZ6P56ixpUTKZp8RHbMlDATVbk7bU9r2DktZPwxpj1ClAdD/922X4wTqCnW0P0 1efKSP+5JcOvvraOxysHzndyasYyD9AjW4+S2M6FT+6mlz76dgfDHaC2QxqJaniiwL LFIGP4LodbT0+zjhBgw26iSoQSY/wIJVgsw9oHc8iyeyD2fUi8u9YRbVe22hIF+Xp2 FAHnhFw0huSngZeQJX8GL/AvBEF4KconquY+NWNSQF6gnxreJAHDngnD90TF0PSWIB nb2BaDJHn607SKipuehmyjmGNKGIgkIAPk/t6t18TNyGIP+VPJ7xAZQ+kpCE/evsbx etCDbQvRT1Z/w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chuan Liu , Jerome Brunet , Sasha Levin Subject: [PATCH 6.19 359/844] clk: amlogic: remove potentially unsafe flags from S4 video clocks Date: Sat, 28 Feb 2026 12:24:32 -0500 Message-ID: <20260228173244.1509663-360-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chuan Liu [ Upstream commit 4aca7e92023cac5018b4053bae324450f884c937 ] The video clocks enci, encp, vdac and hdmitx share the same clock source. Adding CLK_SET_RATE_PARENT to the mux may unintentionally change the shared parent clock, which could affect other video clocks. Signed-off-by: Chuan Liu Link: https://lore.kernel.org/r/20250919-add_video_clk-v6-3-fe223161fb3f@am= logic.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clk/meson/s4-peripherals.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/clk/meson/s4-peripherals.c b/drivers/clk/meson/s4-peri= pherals.c index 6d69b132d1e1f..bab4f5700de47 100644 --- a/drivers/clk/meson/s4-peripherals.c +++ b/drivers/clk/meson/s4-peripherals.c @@ -1106,7 +1106,6 @@ static struct clk_regmap s4_cts_enci_sel =3D { .ops =3D &clk_regmap_mux_ops, .parent_hws =3D s4_cts_parents, .num_parents =3D ARRAY_SIZE(s4_cts_parents), - .flags =3D CLK_SET_RATE_PARENT, }, }; =20 @@ -1122,7 +1121,6 @@ static struct clk_regmap s4_cts_encp_sel =3D { .ops =3D &clk_regmap_mux_ops, .parent_hws =3D s4_cts_parents, .num_parents =3D ARRAY_SIZE(s4_cts_parents), - .flags =3D CLK_SET_RATE_PARENT, }, }; =20 @@ -1138,7 +1136,6 @@ static struct clk_regmap s4_cts_vdac_sel =3D { .ops =3D &clk_regmap_mux_ops, .parent_hws =3D s4_cts_parents, .num_parents =3D ARRAY_SIZE(s4_cts_parents), - .flags =3D CLK_SET_RATE_PARENT, }, }; =20 @@ -1169,7 +1166,6 @@ static struct clk_regmap s4_hdmi_tx_sel =3D { .ops =3D &clk_regmap_mux_ops, .parent_hws =3D s4_hdmi_tx_parents, .num_parents =3D ARRAY_SIZE(s4_hdmi_tx_parents), - .flags =3D CLK_SET_RATE_PARENT, }, }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4AA513B5BEA; Sat, 28 Feb 2026 17:38:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300328; cv=none; b=EsvaJUBmP9GsCHp08cRTJmyegWWhvu2D3QVu/IyOKmwuWns7rp4gu5sjM40OiPNbKr5klF0XXqKZMCNwkSQ3qpqpBQqNvIoPz0jkg98Q+2c255J9YyjCIfg7tB35cF03en+Jcl0lUmsdO7pyzx3e8ONZt97l8ZhPqPGf/MxdRH0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300328; c=relaxed/simple; bh=VEKKTeVhlcWLRPYgdIU1LNz+iIYdHus7P0jtbj/SmGw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X1k15kcpXa4ByIVZbSWPJeArl9VTH7lOYFIDojxpwWEDrPMOOpOksGTUPqKt+9aongtI/5i9lkstP/SoXYWrqSP1Ms0C/WG/auONSHeKIQcad4KdIM4U1c2dQZ0r/A+rNmkAFOcDDdiD8pJ9/iIDt0gKN17xxHRM6eRLNRfLsj4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=su/3RFGh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="su/3RFGh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97862C19423; Sat, 28 Feb 2026 17:38:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300328; bh=VEKKTeVhlcWLRPYgdIU1LNz+iIYdHus7P0jtbj/SmGw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=su/3RFGh16VfYOxbgJ7C3IeTG1fYW8DrqQzcDthuTiGrXpcisVUaQyfVIAyjsUfIb xFrGnzlb1XbdV+sM7ZxN8dE+A4KeTzqN5MAz/g8QfDEWP8r0JuRS1Np1FrE9eBOcPf woAtce8j+t9M3LJkTrnMh2nanADd34BttOZVaviLv1ZbIagjOWklH+snRzX1lZum+O q/1Na5j0zYEuVJrdCQfXwZBCbunJqdxKz2Yx9y+wD2S776FcGhoThPwt5ERRQmCQ+V +p6KuMbMISt3fJfibUeuoUYLwHO72p/HDg5LGhMHTBQrikKH6JQ68F6DO53uIAinZU 2upNoqCAJKsnw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Biju Das , Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.19 360/844] clk: renesas: rzg2l: Deassert reset on assert timeout Date: Sat, 28 Feb 2026 12:24:33 -0500 Message-ID: <20260228173244.1509663-361-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Biju Das [ Upstream commit 0b0201f259e1158a875c5fd01adf318ae5d32352 ] If the assert() fails due to timeout error, set the reset register bit back to deasserted state. This change is needed especially for handling assert error in suspend() callback that expect the device to be in operational state in case of failure. Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260108123433.104464-2-biju.das.jz@bp.renes= as.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clk/renesas/rzg2l-cpg.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/clk/renesas/rzg2l-cpg.c b/drivers/clk/renesas/rzg2l-cp= g.c index 64d1ef6e4c943..c20ea1212b360 100644 --- a/drivers/clk/renesas/rzg2l-cpg.c +++ b/drivers/clk/renesas/rzg2l-cpg.c @@ -1647,6 +1647,7 @@ static int __rzg2l_cpg_assert(struct reset_controller= _dev *rcdev, u32 mask =3D BIT(info->resets[id].bit); s8 monbit =3D info->resets[id].monbit; u32 value =3D mask << 16; + u32 mon; int ret; =20 dev_dbg(rcdev->dev, "%s id:%ld offset:0x%x\n", @@ -1667,10 +1668,10 @@ static int __rzg2l_cpg_assert(struct reset_controll= er_dev *rcdev, return 0; } =20 - ret =3D readl_poll_timeout_atomic(priv->base + reg, value, - assert =3D=3D !!(value & mask), 10, 200); - if (ret && !assert) { - value =3D mask << 16; + ret =3D readl_poll_timeout_atomic(priv->base + reg, mon, + assert =3D=3D !!(mon & mask), 10, 200); + if (ret) { + value ^=3D mask; writel(value, priv->base + CLK_RST_R(info->resets[id].off)); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80AAB3B5C15; Sat, 28 Feb 2026 17:38:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300329; cv=none; b=Ah/uAYUPKWhBz7Au5lFO7iLN65qONsC7Valnw00uHpmXhK/CUBzd+X/DVqLR2W3j2OmOxiXx0JcPfXU3MbEgWdEB/dL8FAI0A/9edfbe7AoxTNpx4j22yrOer2dELV/BqDMKIEuHywckbxK5yyK42XGjqoBxem0oWJMtdFHYiqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300329; c=relaxed/simple; bh=XRTZj9O6e/ypbjfemxfPAAtPh7yD7YZZLwpmdZQF97s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q8SydJF1O2WmBNHEEtU9V/OitOb7zZ/0dq/n9oklO909AhJ7rvcyECba7Ndf639thRUpsg8L1mcBgO7ksBP320vhSEwutWE0Gym+yYk9akT5cR8RXtkwZB9xT8CyK6GkJUOxmc/VsaPfi0/yubTTZDGK21CVE+IUpTyySct2hjo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MJfXNcBB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MJfXNcBB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72543C19423; Sat, 28 Feb 2026 17:38:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300329; bh=XRTZj9O6e/ypbjfemxfPAAtPh7yD7YZZLwpmdZQF97s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MJfXNcBBJyovk+aHpX2Od2MCNMiBa2PaAIWHKZC1a/lscP7tBXsFqgtWursCndRQS mlZkC1o/aadXQyKuplJ4arobS2Mn5Zreh100F7DGBKgX/j6STHWqnbfUnpvw8TBMiD 4mEVeIbWdGuRUbg1CzkbRsXIxWWWA5eEBtA3BpzyBqMyLJhCGbn6ZQH87z6j6798Tl JvANADN0LW/LJ2hkbATna5qicMHphOv/ZU0iHEbT1k0K2huog2ZlaztYoLqqjsG67X 5DNObf9NhosoTM0TASAinmASykevB9/CCl9C8ftlZatWsOaJZrx229p5GrCXErgPiw Vvcb09vbyUwcQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Brian Masney , kernel test robot , Dan Carpenter , Claudiu Beznea , Sasha Levin Subject: [PATCH 6.19 361/844] clk: microchip: core: correct return value on *_get_parent() Date: Sat, 28 Feb 2026 12:24:34 -0500 Message-ID: <20260228173244.1509663-362-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Brian Masney [ Upstream commit 5df96d141cccb37f0c3112a22fc1112ea48e9246 ] roclk_get_parent() and sclk_get_parent() has the possibility of returning -EINVAL, however the framework expects this call to always succeed since the return value is unsigned. If there is no parent map defined, then the current value programmed in the hardware is used. Let's use that same value in the case where -EINVAL is currently returned. This index is only used by clk_core_get_parent_by_index(), and it validates that it doesn't overflow the number of available parents. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202512050233.R9hAWsJN-lkp@intel.com/ Signed-off-by: Brian Masney Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20251205-clk-microchip-fixes-v3-2-a02190705= e47@redhat.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clk/microchip/clk-core.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/clk/microchip/clk-core.c b/drivers/clk/microchip/clk-c= ore.c index a0163441dfe5c..82f62731fc0ed 100644 --- a/drivers/clk/microchip/clk-core.c +++ b/drivers/clk/microchip/clk-core.c @@ -283,14 +283,13 @@ static u8 roclk_get_parent(struct clk_hw *hw) =20 v =3D (readl(refo->ctrl_reg) >> REFO_SEL_SHIFT) & REFO_SEL_MASK; =20 - if (!refo->parent_map) - return v; - - for (i =3D 0; i < clk_hw_get_num_parents(hw); i++) - if (refo->parent_map[i] =3D=3D v) - return i; + if (refo->parent_map) { + for (i =3D 0; i < clk_hw_get_num_parents(hw); i++) + if (refo->parent_map[i] =3D=3D v) + return i; + } =20 - return -EINVAL; + return v; } =20 static unsigned long roclk_calc_rate(unsigned long parent_rate, @@ -817,13 +816,13 @@ static u8 sclk_get_parent(struct clk_hw *hw) =20 v =3D (readl(sclk->mux_reg) >> OSC_CUR_SHIFT) & OSC_CUR_MASK; =20 - if (!sclk->parent_map) - return v; + if (sclk->parent_map) { + for (i =3D 0; i < clk_hw_get_num_parents(hw); i++) + if (sclk->parent_map[i] =3D=3D v) + return i; + } =20 - for (i =3D 0; i < clk_hw_get_num_parents(hw); i++) - if (sclk->parent_map[i] =3D=3D v) - return i; - return -EINVAL; + return v; } =20 static int sclk_set_parent(struct clk_hw *hw, u8 index) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 533F13B63EC; Sat, 28 Feb 2026 17:38:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300330; cv=none; b=TcVcuypf9obFX/Ze3ZC1xBJqLuWjEmTGrHUrIQLz/KfeO3uFpMG7nj5phZNCdrUkZbjOwq+5rJXWNm/ye2nf9scS1eftaM5X0+kdG56pGkwZaPpTmJ495oCMYBO39wOkCY6CPnZYglqccH0oM25AL/J8n5rTi9nWKMZEw19ES0U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300330; c=relaxed/simple; bh=EBltPShLdHRg5MHLH88vzR0tSq7BbpzYUrYZ3TMQlZU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mAmWtmS5fAOdwk0h8ge97lbNNbOuvzMhdbmfua7FNYcqa6oedxmYow3bA7Vx7mtXzAx0jRpoCkzB91HtCmpkKcqOz71Iy2YYr1+tD4ifGJCd4wLAGkfa5eeGZVpAYhl9zV6yAvAPtgiwnPKFEx1dMJGzLK8rrSi9wjt8Z6l/BB0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gmhzBLt8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gmhzBLt8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76600C19424; Sat, 28 Feb 2026 17:38:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300330; bh=EBltPShLdHRg5MHLH88vzR0tSq7BbpzYUrYZ3TMQlZU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gmhzBLt8+thvvc7N9+Q5bDstNjFrKXQOEy/5CjP4iwM5qo2poDVbCim+QkGmqVvl9 Gu0gtQEY98+9zwolmGDd8agsQcGMIQfiRq+uVeSKZ7B+tLhdpm+N1D0I1h8tbLg0Mg PfYLMDQYymkMYGL9aFTKNiBFM1CUvnRpZuAwPmpZ9koHEWSgTLpa0RERlfVJ2nxsxt jjqZDiavKJaL/gjtvc7QlRxidOJPi3b0aE/CSl51MT9C70L8782XFmHelj//2ohSBL Jriodkt8ikqCKYBqDprpvARrbRxb4SiAXXLZAnd0wv9FwyQDu3BfBkdW4olRtXM63F /D7Tl+CtyMihQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Daniel Peng , Jiri Kosina , Douglas Anderson , Dmitry Torokhov , Sasha Levin Subject: [PATCH 6.19 362/844] HID: i2c-hid: Add FocalTech FT8112 Date: Sat, 28 Feb 2026 12:24:35 -0500 Message-ID: <20260228173244.1509663-363-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Daniel Peng [ Upstream commit 3d9586f1f90c9101b1abf5b0e9d70ca45f5f16db ] Information for touchscreen model HKO/RB116AS01-2 as below: - HID :FTSC1000 - slave address:0X38 - Interface:HID over I2C - Touch control lC:FT8112 - I2C ID: PNP0C50 Signed-off-by: Daniel Peng Acked-by: Jiri Kosina Reviewed-by: Douglas Anderson Link: https://patch.msgid.link/20251117094041.300083-2-Daniel_Peng@pegatron= .corp-partner.google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/i2c-hid/i2c-hid-of-elan.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/hid/i2c-hid/i2c-hid-of-elan.c b/drivers/hid/i2c-hid/i2= c-hid-of-elan.c index 0215f217f6d86..b81fcc6ff49ee 100644 --- a/drivers/hid/i2c-hid/i2c-hid-of-elan.c +++ b/drivers/hid/i2c-hid/i2c-hid-of-elan.c @@ -168,6 +168,13 @@ static const struct elan_i2c_hid_chip_data elan_ekth6a= 12nay_chip_data =3D { .power_after_backlight =3D true, }; =20 +static const struct elan_i2c_hid_chip_data focaltech_ft8112_chip_data =3D { + .post_power_delay_ms =3D 10, + .post_gpio_reset_on_delay_ms =3D 150, + .hid_descriptor_address =3D 0x0001, + .main_supply_name =3D "vcc33", +}; + static const struct elan_i2c_hid_chip_data ilitek_ili9882t_chip_data =3D { .post_power_delay_ms =3D 1, .post_gpio_reset_on_delay_ms =3D 200, @@ -191,6 +198,7 @@ static const struct elan_i2c_hid_chip_data ilitek_ili29= 01_chip_data =3D { static const struct of_device_id elan_i2c_hid_of_match[] =3D { { .compatible =3D "elan,ekth6915", .data =3D &elan_ekth6915_chip_data }, { .compatible =3D "elan,ekth6a12nay", .data =3D &elan_ekth6a12nay_chip_da= ta }, + { .compatible =3D "focaltech,ft8112", .data =3D &focaltech_ft8112_chip_da= ta }, { .compatible =3D "ilitek,ili9882t", .data =3D &ilitek_ili9882t_chip_data= }, { .compatible =3D "ilitek,ili2901", .data =3D &ilitek_ili2901_chip_data }, { } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 60E033B640A; Sat, 28 Feb 2026 17:38:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300331; cv=none; b=gGsvFz/8FXZo4p03zjoqm7M2mTBPoYfwJ4j2fCPNPM8w2QXMP+G2/+n6vbQ36Pr3M8JWPrhosnH1Q0J0xdHh3tBhkXNsEH476FUSbbMjWSnBMuPPPdyC2cGxS1VrvBc45HmvFRCcR7wt/dXcOvpaXszDKMZ+DZWb6cUvlOamEmw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300331; c=relaxed/simple; bh=ghFaaLmJj1iPLJhplCjQVJwlTyugZcyZZUzRtfbzkyk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DNYF9VyRFj9iEjx5OhJ00T+T84DH+gwRRupjoVa1hAWoAhYIiyCekC9NeZcTCoGHKJDU47TUOfYME0mBX3HbUnK8I0yqUvXY2dQTFqBVJMcViFOethVU5+z9Awlnc2fZIfj/xCi6fZWnp0LUftUupyYsfQLAVPI9ULqKKE6pxY0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eL8RNLzo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eL8RNLzo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7CFB6C19424; Sat, 28 Feb 2026 17:38:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300331; bh=ghFaaLmJj1iPLJhplCjQVJwlTyugZcyZZUzRtfbzkyk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eL8RNLzo5jcpaNmrGe+3E9NdCDw+ZAoHkqueHgsX0U9ukBZpOl+ffTGsVWwsfVlFA RHRL7uOZBJvBFOjnyuufzzYSFpxYldR8FEn2cNzld48Xu/KSwaDFj4TLE39ZhKDIAk klf1SKy/LnjTmJch2BYsDFsqlj7ZZIKdVIX8xrFH4DUwhDfVy0nDC12SYUQ+IcKUrn u0QHxDyrO64URhrxXpkCpy/l5kozb31kpQMEhsG/cDw3PI2yJCaJJYBq5dCrIWLAvx XWGzRP8YTKtDtM6G2ujWSoe7xtZ2ZsrQy9JVKBs1h8yID93RWN92edKN4SpxMkLArK aqKlX1pN+g4KA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Daniel Palmer , Greg Ungerer , Sasha Levin Subject: [PATCH 6.19 363/844] m68k: nommu: fix memmove() with differently aligned src and dest for 68000 Date: Sat, 28 Feb 2026 12:24:36 -0500 Message-ID: <20260228173244.1509663-364-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Daniel Palmer [ Upstream commit 590fe2f46c8698bb758f9002cb247ca10ce95569 ] 68000 has different alignment needs to 68020+. memcpy() checks if the destination is aligned and does a smaller copy to fix the alignment and then critically for 68000 it checks if the source is still unaligned and if it is reverts to smaller copies. memmove() does not currently do the second part and malfunctions if one of the pointers is aligned and the other isn't. This is apparently getting triggered by printk. If I put breakpoints into the new checks added by this commit the first hit looks like this: memmove (n=3D205, src=3D0x2f3971 , dest=3D0x2f3980= ) at arch/m68k/lib/memmove.c:82 Signed-off-by: Daniel Palmer Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/m68k/lib/memmove.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/arch/m68k/lib/memmove.c b/arch/m68k/lib/memmove.c index 6519f7f349f66..e33f00b02e4c0 100644 --- a/arch/m68k/lib/memmove.c +++ b/arch/m68k/lib/memmove.c @@ -24,6 +24,15 @@ void *memmove(void *dest, const void *src, size_t n) src =3D csrc; n--; } +#if defined(CONFIG_M68000) + if ((long)src & 1) { + char *cdest =3D dest; + const char *csrc =3D src; + for (; n; n--) + *cdest++ =3D *csrc++; + return xdest; + } +#endif if (n > 2 && (long)dest & 2) { short *sdest =3D dest; const short *ssrc =3D src; @@ -66,6 +75,15 @@ void *memmove(void *dest, const void *src, size_t n) src =3D csrc; n--; } +#if defined(CONFIG_M68000) + if ((long)src & 1) { + char *cdest =3D dest; + const char *csrc =3D src; + for (; n; n--) + *--cdest =3D *--csrc; + return xdest; + } +#endif if (n > 2 && (long)dest & 2) { short *sdest =3D dest; const short *ssrc =3D src; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C82B3B5C15; Sat, 28 Feb 2026 17:38:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300332; cv=none; b=SeGB9Fq1c3zfycXWtLUUPL9zDi23h+YXnSxE2FuKub5tutZZkoT8TCveqAKX7Ttw5BIY0NAQtA8m70tc/8ddYkgOdXavo/Bk7n4QBIpknE9DXsNNIT3/8icOJ16kneegIv0z3Js4EKy1mMhEq+LgK8UcRv6ALCRxPD3GAWvk3ms= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300332; c=relaxed/simple; bh=KKUiJY5BMU9CiNqmrwD1kfpk+y+W+aEkS7gg43iaqK8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=feM7HkY3ulwCmjEhzd+PTmruI2vWSvd33n85BlN7MJH18Xwk82BeA2RNHW8dX8YuQzBGy2N5Q74SNWjPvraWSIQVwgT4UEArvMRGekicnVdOekeB2oCXEJ/B7sYIyAL6roUF+jwKsDd3beIkd8R1oADUHa1hY0mB/C6TWRETDII= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LpsckwFU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LpsckwFU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5832DC19423; Sat, 28 Feb 2026 17:38:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300331; bh=KKUiJY5BMU9CiNqmrwD1kfpk+y+W+aEkS7gg43iaqK8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LpsckwFUErBuN7389uUiF3ozzLpO8RidF36/n9GdLd7C4xX7UrrXR0dhCyrnXwSmH ztb2ZtHhuPkcPeGRkRvoknAqxi+Ft8m+U+JpnNPgNZMyIhxk0n5q+Nr249OhaeHDki cTQxuklbwwGL8tNHVolYQG7G57CAA6SlBrFpQrPT+HCfTwNBVft5nVu8h3jnDgPSsZ NsudZaUCkwB6RjO5+UiOiEgY4QA3eCKTooNsmzvIsfDhgJM6whTiqZmqspcYhhTA4K umgtcqoWO/o2dhBWwOFPSnH6mWPqVgcVIHeSYsyEWKEovPPOGNdfkOwqLQjnTbIECD aojkXTXi5Rilg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Stefano Stabellini , Dominique Martinet , Sasha Levin Subject: [PATCH 6.19 364/844] 9p/xen: protect xen_9pfs_front_free against concurrent calls Date: Sat, 28 Feb 2026 12:24:37 -0500 Message-ID: <20260228173244.1509663-365-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Stefano Stabellini [ Upstream commit ce8ded2e61f47747e31eeefb44dc24a2160a7e32 ] The xenwatch thread can race with other back-end change notifications and call xen_9pfs_front_free() twice, hitting the observed general protection fault due to a double-free. Guard the teardown path so only one caller can release the front-end state at a time, preventing the crash. This is a fix for the following double-free: [ 27.052347] Oops: general protection fault, probably for non-canonical a= ddress 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-0208= 7-g51ab33fc0a8b-dirty #60 PREEMPT(none) [ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150 [ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 = 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48= > 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42 [ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246 [ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 00000000000= 00000 [ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 00000000000= 00000 [ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 00000000000= 00000 [ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e= 46b68 [ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a8= 87040 [ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:= 0000000000000000 [ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 00000000000= 50660 [ 27.052418] Call Trace: [ 27.052420] [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720 [ 27.052426] ? xenbus_otherend_changed+0x72/0x140 [ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10 [ 27.052434] xenwatch_thread+0x94/0x1c0 [ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10 [ 27.052442] kthread+0xf8/0x240 [ 27.052445] ? __pfx_kthread+0x10/0x10 [ 27.052449] ? __pfx_kthread+0x10/0x10 [ 27.052452] ret_from_fork+0x16b/0x1a0 [ 27.052456] ? __pfx_kthread+0x10/0x10 [ 27.052459] ret_from_fork_asm+0x1a/0x30 [ 27.052463] [ 27.052465] Modules linked in: [ 27.052471] ---[ end trace 0000000000000000 ]--- Signed-off-by: Stefano Stabellini Message-ID: <20260129230348.2390470-1-stefano.stabellini@amd.com> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/9p/trans_xen.c | 85 ++++++++++++++++++++++++---------------------- 1 file changed, 44 insertions(+), 41 deletions(-) diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c index 12f752a923324..9bbfc20744f69 100644 --- a/net/9p/trans_xen.c +++ b/net/9p/trans_xen.c @@ -277,45 +277,52 @@ static void xen_9pfs_front_free(struct xen_9pfs_front= _priv *priv) { int i, j; =20 - write_lock(&xen_9pfs_lock); - list_del(&priv->list); - write_unlock(&xen_9pfs_lock); - - for (i =3D 0; i < XEN_9PFS_NUM_RINGS; i++) { - struct xen_9pfs_dataring *ring =3D &priv->rings[i]; - - cancel_work_sync(&ring->work); - - if (!priv->rings[i].intf) - break; - if (priv->rings[i].irq > 0) - unbind_from_irqhandler(priv->rings[i].irq, ring); - if (priv->rings[i].data.in) { - for (j =3D 0; - j < (1 << priv->rings[i].intf->ring_order); - j++) { - grant_ref_t ref; - - ref =3D priv->rings[i].intf->ref[j]; - gnttab_end_foreign_access(ref, NULL); - } - free_pages_exact(priv->rings[i].data.in, + if (priv->rings) { + for (i =3D 0; i < XEN_9PFS_NUM_RINGS; i++) { + struct xen_9pfs_dataring *ring =3D &priv->rings[i]; + + cancel_work_sync(&ring->work); + + if (!priv->rings[i].intf) + break; + if (priv->rings[i].irq > 0) + unbind_from_irqhandler(priv->rings[i].irq, ring); + if (priv->rings[i].data.in) { + for (j =3D 0; + j < (1 << priv->rings[i].intf->ring_order); + j++) { + grant_ref_t ref; + + ref =3D priv->rings[i].intf->ref[j]; + gnttab_end_foreign_access(ref, NULL); + } + free_pages_exact(priv->rings[i].data.in, 1UL << (priv->rings[i].intf->ring_order + XEN_PAGE_SHIFT)); + } + gnttab_end_foreign_access(priv->rings[i].ref, NULL); + free_page((unsigned long)priv->rings[i].intf); } - gnttab_end_foreign_access(priv->rings[i].ref, NULL); - free_page((unsigned long)priv->rings[i].intf); + kfree(priv->rings); } - kfree(priv->rings); kfree(priv->tag); kfree(priv); } =20 static void xen_9pfs_front_remove(struct xenbus_device *dev) { - struct xen_9pfs_front_priv *priv =3D dev_get_drvdata(&dev->dev); + struct xen_9pfs_front_priv *priv; =20 + write_lock(&xen_9pfs_lock); + priv =3D dev_get_drvdata(&dev->dev); + if (priv =3D=3D NULL) { + write_unlock(&xen_9pfs_lock); + return; + } dev_set_drvdata(&dev->dev, NULL); + list_del(&priv->list); + write_unlock(&xen_9pfs_lock); + xen_9pfs_front_free(priv); } =20 @@ -382,7 +389,7 @@ static int xen_9pfs_front_init(struct xenbus_device *de= v) { int ret, i; struct xenbus_transaction xbt; - struct xen_9pfs_front_priv *priv =3D dev_get_drvdata(&dev->dev); + struct xen_9pfs_front_priv *priv; char *versions, *v; unsigned int max_rings, max_ring_order, len =3D 0; =20 @@ -410,6 +417,10 @@ static int xen_9pfs_front_init(struct xenbus_device *d= ev) if (p9_xen_trans.maxsize > XEN_FLEX_RING_SIZE(max_ring_order)) p9_xen_trans.maxsize =3D XEN_FLEX_RING_SIZE(max_ring_order) / 2; =20 + priv =3D kzalloc(sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + priv->dev =3D dev; priv->rings =3D kcalloc(XEN_9PFS_NUM_RINGS, sizeof(*priv->rings), GFP_KERNEL); if (!priv->rings) { @@ -468,6 +479,11 @@ static int xen_9pfs_front_init(struct xenbus_device *d= ev) goto error; } =20 + write_lock(&xen_9pfs_lock); + dev_set_drvdata(&dev->dev, priv); + list_add_tail(&priv->list, &xen_9pfs_devs); + write_unlock(&xen_9pfs_lock); + xenbus_switch_state(dev, XenbusStateInitialised); return 0; =20 @@ -482,19 +498,6 @@ static int xen_9pfs_front_init(struct xenbus_device *d= ev) static int xen_9pfs_front_probe(struct xenbus_device *dev, const struct xenbus_device_id *id) { - struct xen_9pfs_front_priv *priv =3D NULL; - - priv =3D kzalloc(sizeof(*priv), GFP_KERNEL); - if (!priv) - return -ENOMEM; - - priv->dev =3D dev; - dev_set_drvdata(&dev->dev, priv); - - write_lock(&xen_9pfs_lock); - list_add_tail(&priv->list, &xen_9pfs_devs); - write_unlock(&xen_9pfs_lock); - return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 365EC3B6CA0; Sat, 28 Feb 2026 17:38:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300333; cv=none; b=Mujs7U52z2C24oXg7lXzYULBladwcrmS2JDySbTRPOh4P5IERew7zVYvwiIL/WuZvWpgjuCkgS2nVdLBELcRx49anLFwYRjMIjs6ehbHU2BvBU94Wu5rmsQdc/rwrENCsYv8zeulTCqsUNT3QEsm4AgYp8gLy/B3waZXvRuwrRE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300333; c=relaxed/simple; bh=dUjo4k5J/KvXhmTqVg7UMWfUV5hSPL6zhpvc9ge/hx8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=o9ZfZ3n+AO5AMeax07DBJn6V7s0Fl2KYJsCyKvLI7Jl/w0JepZQtpAwmdWWJklUlMD/iM+Fc6Y4mqdJEjVMgkhc1fCo2PWpMs67VAuzswNRcmx1HiFlUYBn0e9Ai5154+EOz48tFtjGMHktxaN1zvXYESllR1wA1dnJVX5nM9SE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Cl8WVQsX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Cl8WVQsX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3137DC116D0; Sat, 28 Feb 2026 17:38:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300332; bh=dUjo4k5J/KvXhmTqVg7UMWfUV5hSPL6zhpvc9ge/hx8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Cl8WVQsXNdEEvR0wasKmmwKJVImFwKdANh6tvOGSiXaFwn5J+qklCyK2heOJ6+1cY phhZacxj2sf5CPX/mEMaY4r5a3pC6bCXfY4DaK88M1jgezhokbUm/gwYdP0z8By6VS S5rC7Lizo4l+ONi2sp+KUFGQH21JQSQnqRqvUVxE7zHGA7NjQ9XeRnhzDHVyc9fCDk VfORP6vZKLOUVycfLUH7XBIeZRnjRUERjHWogePROPajVbG95jArObMNWuaAcZAsSP yitqA+sAjBjHg4OL18gvvgAlg6TRM/vZ1L+r4c3hRTccuBInKVFzCJa/tlTkGKFGIc fQas/O/Dp6DDg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Amelie Delaunay , Eugen Hristev , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 365/844] dmaengine: stm32-dma3: use module_platform_driver Date: Sat, 28 Feb 2026 12:24:38 -0500 Message-ID: <20260228173244.1509663-366-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Amelie Delaunay [ Upstream commit 0d41ed4ea496fabbb4dc21171e32d9a924c2a661 ] Without module_platform_driver(), stm32-dma3 doesn't have a module_exit procedure. Once stm32-dma3 module is inserted, it can't be removed, marked busy. Use module_platform_driver() instead of subsys_initcall() to register (insmod) and unregister (rmmod) stm32-dma3 driver. Reviewed-by: Eugen Hristev Signed-off-by: Amelie Delaunay Link: https://patch.msgid.link/20251121-dma3_improv-v2-1-76a207b13ea6@foss.= st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/dma/stm32/stm32-dma3.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/dma/stm32/stm32-dma3.c b/drivers/dma/stm32/stm32-dma3.c index 50e7106c5cb73..9500164c8f688 100644 --- a/drivers/dma/stm32/stm32-dma3.c +++ b/drivers/dma/stm32/stm32-dma3.c @@ -1914,12 +1914,7 @@ static struct platform_driver stm32_dma3_driver =3D { }, }; =20 -static int __init stm32_dma3_init(void) -{ - return platform_driver_register(&stm32_dma3_driver); -} - -subsys_initcall(stm32_dma3_init); +module_platform_driver(stm32_dma3_driver); =20 MODULE_DESCRIPTION("STM32 DMA3 controller driver"); MODULE_AUTHOR("Amelie Delaunay "); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 058D93B6CBB; Sat, 28 Feb 2026 17:38:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300334; cv=none; b=Ue/FC5KtXfIFXT2Niozm8EykgmwaImVjDI9V+F1AEOEF6vEWw1Sl9qojTiJpMYC1ZrqlL02Z24yAniT0pR6wgXEw7K1TUJ4m2S1TCbDEjQ2ZilesJIBn2ilX/5orbl/8+TIxBTpDEgv8upnT1yKL5ajf40bGbGv5nnK/J1iNKMo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300334; c=relaxed/simple; bh=NTHk+Aj+yk0JQZSMKMquAes9wACrqJ8bnwzA5E35qOM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YhLjCKVZfeIaAvQDXdHIYZkaUiWwGmvbA/OSVmTiqb9e5riwjdb2PxVsGfJZ8gC+8UpAx32GqY9GS6GCF9q4YUNbJ4F0cRc5ohRiF7l/Co7TDDsTjqWn88F+QYGFsiw03UCvBvlhJBxqvVlB0GJvGHRv77BT6T+6MeWf/7HQH1o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gc102TDX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gc102TDX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2536EC19423; Sat, 28 Feb 2026 17:38:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300333; bh=NTHk+Aj+yk0JQZSMKMquAes9wACrqJ8bnwzA5E35qOM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gc102TDXTOaEs0hxXHlrZN6Ds7d/1EObQoqaZuKXxquLC67FsuKEj7ktgbywdbAsb nBMz6gYVeZjLvCvGfGd0E3cXhlxDK1FxeBm370Qzt+rlWfcdEaYYDmHOTiBvRkCvC2 QEJxBrBQLEkNKatu7H6QLAArxDW4GgX3rbdEb43Lsack9lQYmJ534/acg824kv8QsN AFIwBqsDpuoJQpsg0LMq+ol3RNznp4+QDzFfLxrPPbl6WRnZ1F5/Ft/iHLefRLinQ0 axZ43uGKSacwVh+SDt+JD+yT6YkpyNqWpscKEIHl+Vqqby5iDPZMe/haqq/nBYkSwn kEkEL408UxXpg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Ujfalusi , Kai Vehmanen , Bard Liao , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 366/844] soundwire: dmi-quirks: add mapping for Avell B.ON (OEM rebranded of NUC15) Date: Sat, 28 Feb 2026 12:24:39 -0500 Message-ID: <20260228173244.1509663-367-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Ujfalusi [ Upstream commit 59946373755d71dbd7614ba235e0093159f80b69 ] Avell B.ON is an OEM re-branded NUC15 'Bishop County' LAPBC510 and LAPBC710. Link: https://github.com/thesofproject/linux/issues/5529 Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Link: https://patch.msgid.link/20251215130947.31385-1-peter.ujfalusi@linux.= intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/soundwire/dmi-quirks.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/soundwire/dmi-quirks.c b/drivers/soundwire/dmi-quirks.c index 91ab97a456fa9..5854218e1a274 100644 --- a/drivers/soundwire/dmi-quirks.c +++ b/drivers/soundwire/dmi-quirks.c @@ -122,6 +122,17 @@ static const struct dmi_system_id adr_remap_quirk_tabl= e[] =3D { }, .driver_data =3D (void *)intel_tgl_bios, }, + { + /* + * quirk used for Avell B.ON (OEM rebrand of NUC15 'Bishop County' + * LAPBC510 and LAPBC710) + */ + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "Avell High Performance"), + DMI_MATCH(DMI_PRODUCT_NAME, "B.ON"), + }, + .driver_data =3D (void *)intel_tgl_bios, + }, { /* quirk used for NUC15 'Rooks County' LAPRC510 and LAPRC710 skews */ .matches =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 45FE73B775F; Sat, 28 Feb 2026 17:38:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300335; cv=none; b=PgZ7PdjpjDFHK3sgeus02ObqMZbxhSS6Kk+huC1lCzVmlOfgP989x24vjeFG2BHI2fUQkpklTP7KAzjEgULXyK6dAw2yGRkluxRnRvlyZ0G9pr7bXwmLniziAWwbrb0efH3vnqaVLWR+TdyguYkSYPsR/BIgF4U5Nu3yvQdeNEE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300335; c=relaxed/simple; bh=0KWI7mRy87m/nS0+mW6q0c2VaGXP+MWdnuyz1U6iQD8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qP6mW4kvH7xddJfhfVviievM3jHvpD95isFt3S8aEeUbWvq55aTTGtExRfpX9zXGkf3VFet2v8u+ukrT39z1n6BJLQf5QS99BSkqVoiWHEDWKXbz/4yCnYJP8iz3/HVSCc9rLwAkWOrRnzcsArMD8S3NpJt2SeGjAtZn5A2yycg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tcQEyMp3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tcQEyMp3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C202C116D0; Sat, 28 Feb 2026 17:38:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300334; bh=0KWI7mRy87m/nS0+mW6q0c2VaGXP+MWdnuyz1U6iQD8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tcQEyMp3cabSvRzkbNDE+PfarubyfSP1Ab+ijsX6cbYzbPVlsb2EMRyaLj7G7Zc4H Ag3yke/NkaX/0IY6MtiYcfvidpMvPbrmxpKm8IajJ3RY/PvOMK+rg2SfcwsnP36BI9 YAG8ak6U7jvgJsJFrubCCObbAEqlConn7v12sqcV6zk2Hac1cs5gErcBi7v7sqEHBu 9S/vMHkEQbzlO2313eIqieUFnbTBVJkPlxAI4WudMyIbTgZn2jKF9puGblg92xTnjy Dl4dWiwtiEzPkX1qipdK9ZEQwDTYOJGsuUV6BXXNtkur76+uLku9IuJXNuGfqyexk6 W1ZjUUew9SOXA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Maciej Strozek , Bard Liao , Charles Keepax , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 367/844] soundwire: intel_auxdevice: add cs42l45 codec to wake_capable_list Date: Sat, 28 Feb 2026 12:24:40 -0500 Message-ID: <20260228173244.1509663-368-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Strozek [ Upstream commit f87e5575a6bd1925cd55f500b61b661724372e5f ] Add cs42l45 to the wake_capable_list because it can generate jack events whilst the bus is stopped. Signed-off-by: Maciej Strozek Reviewed-by: Bard Liao Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20251215151729.3911077-1-ckeepax@opensource.= cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/soundwire/intel_auxdevice.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soundwire/intel_auxdevice.c b/drivers/soundwire/intel_= auxdevice.c index 6df2601fff909..8752b0e3ce74c 100644 --- a/drivers/soundwire/intel_auxdevice.c +++ b/drivers/soundwire/intel_auxdevice.c @@ -52,6 +52,7 @@ struct wake_capable_part { =20 static struct wake_capable_part wake_capable_list[] =3D { {0x01fa, 0x4243}, + {0x01fa, 0x4245}, {0x025d, 0x5682}, {0x025d, 0x700}, {0x025d, 0x711}, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EDF763B7778; Sat, 28 Feb 2026 17:38:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300336; cv=none; b=BTfoVn/5i5dIOZVuYzKh3sENBTr4TIbBxVTniB72WIR/BdsYg0xnHxSWypoQzV75lIR4R+bDJKyJeekilHZd2dKnZelG5Ug7Y75zhy0gXfu3x2abM5kEORj6tpX7cohnPwRsWaUgYySmy87TFXVbZd6PbnNleJt5mpAAFlRdIEo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300336; c=relaxed/simple; bh=DLs8O39Aquy21DE10NBbQgShhgreUQHnlNBuqWYnRLY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y1gqCbIRe8J21XbJTwE7XvBx/SWs263fAiHIAHA9IHoXlx421NCBEpByIthKQjM/S3WKzDDFTrK/gxzWcQ0+hlz0zHgUcgbio08HeusRR36LK6tOobMCJXaIREi6eYTztJ6tsKJKAMvgooZu1kUjG4kXOnPakSHW6cbb6Kziin0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rBKbDH3+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rBKbDH3+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33CDFC19423; Sat, 28 Feb 2026 17:38:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300335; bh=DLs8O39Aquy21DE10NBbQgShhgreUQHnlNBuqWYnRLY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rBKbDH3+K1fMN2jqauDYLuKo1OZTHsQvLfSgkD/dQJU9dHdKHSu/F1qNrneVFC8/o zNRKrwSNizaYdF7qF4Ra4oRhO8q6V6IiIh+sodFPLudqklDtHIMUkidpjRboioA0HS +K6xdo1Tdi58HWZrg1LqzhKi+8tsk4SsI73fR9dq1JBwWUsAH1N+hlK0Qv2GbokJUR Av96zAUT5XilyaXgH8+RoJ0KC4lm5JJf13ANKlJOHNbydlZXrRROySKE8KdcnrMmNJ OIZ77I9ekc4p55YzNxZkgGDLpiOga6af2EIJizGukrrnUWSS/Rmll/qJ6Vo/w/VkLY zM1mLq7Gcvrcg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Liang Jie , fanggeng , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 368/844] staging: rtl8723bs: fix missing status update on sdio_alloc_irq() failure Date: Sat, 28 Feb 2026 12:24:41 -0500 Message-ID: <20260228173244.1509663-369-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Liang Jie [ Upstream commit 618b4aec12faabc7579a6b0df046842d798a4c7c ] The return value of sdio_alloc_irq() was not stored in status. If sdio_alloc_irq() fails after rtw_drv_register_netdev() succeeds, status remains _SUCCESS and the error path skips resource cleanup, while rtw_drv_init() still returns success. Store the return value of sdio_alloc_irq() in status and reuse the existing error handling which relies on status. Reviewed-by: fanggeng Signed-off-by: Liang Jie Link: https://patch.msgid.link/20251208092730.262499-1-buaajxlj@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c b/drivers/staging= /rtl8723bs/os_dep/sdio_intf.c index 1d0239eef114b..dc787954126fd 100644 --- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c +++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c @@ -377,7 +377,8 @@ static int rtw_drv_init( if (status !=3D _SUCCESS) goto free_if1; =20 - if (sdio_alloc_irq(dvobj) !=3D _SUCCESS) + status =3D sdio_alloc_irq(dvobj); + if (status !=3D _SUCCESS) goto free_if1; =20 status =3D _SUCCESS; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5E2D3B7FA9; Sat, 28 Feb 2026 17:38:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300337; cv=none; b=H1o8Q0cVWmeKEW6iDn+MqWPgV6DHPak3WSLsZ/CYFe6VHb+pVuEA8S/m6SQcn2UFVPU1jA+yK2GZlOwlL3KPGaNZ+NA9HMxFGDPHpz51rYacSSCNOK1vImMkplREkkyAQwHyeYKq3SgIw7lxZycWqnkp85Z2ITL+/1tzDRFwo1s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300337; c=relaxed/simple; bh=yW97gJuKPxnqIsyq6Bu4iNRGSpevK2HY9UmX1o2LC+w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LCzhQppSpXyIDi6ppgU6t+JmlHsr8GQs0/Mo3h4PM/2SdJGWGRwuTaSaBe/tZMK2wfI6UD9qI7CPWJs7jTtKFxyGGkqoRDrgaPM2XOwTXr76SZi35aoGulbtZXEpIOur8MQyeFD/R/gy1NXaujf9mZlCnFchiLhfRLRcQyDnUhg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BWonVJbm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BWonVJbm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E584C116D0; Sat, 28 Feb 2026 17:38:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300336; bh=yW97gJuKPxnqIsyq6Bu4iNRGSpevK2HY9UmX1o2LC+w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BWonVJbmNhSTFGsQ+Wv0kkzY4VNchI4FExtyHPsxMVr1fRX6AKnU+4YiK83sl3HjB zNKDvvaUGvU8QqIX2gUDcqWwJo1f6T8ZPv13RqYPtb2cghZ3HXWShXMSfGVmnRPSoV 3y+Ur75QBClamx+tc7rqyutNHYMy4Gyt+phlsKo91CtTNwM1Ja8n55KxC9DJhZntPO ferfz2l7sAXzFYke3lCwTNEH0qChw0TFdmYQ0N4wdz9VzfEAsKAPjl52XB5UoQbFix sEJNmZUIjYE8Y8VHKpSwwm3YjMMJ01NF3sbjxhJ+4R7LeJLKn3qkcMZsRfVJ+fiU8z wMqgSnjqM0YgA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Artem Shimko , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 369/844] serial: 8250_dw: handle clock enable errors in runtime_resume Date: Sat, 28 Feb 2026 12:24:42 -0500 Message-ID: <20260228173244.1509663-370-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Artem Shimko [ Upstream commit d31228143a489ba6ba797896a07541ce06828c09 ] Add error checking for clk_prepare_enable() calls in dw8250_runtime_resume(). Currently if either clock fails to enable, the function returns success while leaving clocks in inconsistent state. This change implements comprehensive error handling by checking the return values of both clk_prepare_enable() calls. If the second clock enable operation fails after the first clock has already been successfully enabled, the code now properly cleans up by disabling and unpreparing the first clock before returning. The error code is then propagated to the caller, ensuring that clock enable failures are properly reported rather than being silently ignored. Signed-off-by: Artem Shimko Link: https://patch.msgid.link/20251104145433.2316165-2-a.shimko.dev@gmail.= com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/tty/serial/8250/8250_dw.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/82= 50_dw.c index 27af83f0ff463..0f8207652efe6 100644 --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -741,11 +741,18 @@ static int dw8250_runtime_suspend(struct device *dev) =20 static int dw8250_runtime_resume(struct device *dev) { + int ret; struct dw8250_data *data =3D dev_get_drvdata(dev); =20 - clk_prepare_enable(data->pclk); + ret =3D clk_prepare_enable(data->pclk); + if (ret) + return ret; =20 - clk_prepare_enable(data->clk); + ret =3D clk_prepare_enable(data->clk); + if (ret) { + clk_disable_unprepare(data->pclk); + return ret; + } =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BBD9E3B7FC3; Sat, 28 Feb 2026 17:38:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300337; cv=none; b=kxYE8ouO7IAu5/3C5kCxvMuxYZvWpd+MnzboVg51RePiHaxc3fGHBJhVesR8JlYKph++7XBz2VR/6XlJMnHNcY4dorisJayxfpOXqUhGADhdx2uXWBYT3pAHzE8B6lzvTO+6uJYna2v+wF4qzdmxoBfWOi3Lu9h2pm5Rmu07+MI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300337; c=relaxed/simple; bh=2P9R8lmUl+1m/5BkjvZoI2Z8hkc/ln2kqBMgtnzsO1I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PP8ir0Us3eVwPlvktNAegrE8f8NAjeHQ1F9gvcOvMiFeEelL47yn1v111VDvt8QORp9QYBhunx6wviqSHjNmuzxU9apQhGh58MJTXYx2LLJBc3viaE4VU5uqCnfDPDujCFAulBj1bVjexr+H4/rVxMBwNoTvSir1CevBY0WTtsE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CkFqVH88; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CkFqVH88" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA958C19423; Sat, 28 Feb 2026 17:38:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300337; bh=2P9R8lmUl+1m/5BkjvZoI2Z8hkc/ln2kqBMgtnzsO1I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CkFqVH88eoEFnyTMQHQ335YG2R2ZhErlDcY9H4XsCLqYLCsGqHanMxESiqCzvQ4fR Vk6lCmAW3/sbpilorxFJrdkNvKiwjqhRaXNe+Ixc13nH0+ut7zVq8q42kPAkxS+KFi 3Lb3VtoFknhKWgru2k9Ds0LROtg8/pk27LgGieCX1jC/iU1S+V7uUolO5Z7z8OKBBf AL0ymSJvC8c7xvIdRfVZ3NQpMMutAZpvwfS6bHV7lL7HMEVnJJ1/XHwJLO1zaERfeD AA4PHGl4367zITtrqWi+Ep25ezNEuhdRY4UZdpemYOVMWeo9IkUdWHMMlEtjqfw35u v919ths6yhAkw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benson Leung , Heikki Krogerus , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 370/844] usb: typec: ucsi: psy: Fix voltage and current max for non-Fixed PDOs Date: Sat, 28 Feb 2026 12:24:43 -0500 Message-ID: <20260228173244.1509663-371-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benson Leung [ Upstream commit 6811e0a08bdce6b2767414caf17fda24c2e4e032 ] ucsi_psy_get_voltage_max and ucsi_psy_get_current_max are calculated using whichever pdo is in the last position of the src_pdos array, presuming it to be a fixed pdo, so the pdo_fixed_voltage or pdo_max_current helpers are used on that last pdo. However, non-Fixed PDOs such as Battery PDOs, Augmented PDOs (used for AVS = and for PPS) may exist, and are always at the end of the array if they do. In the event one of these more advanced chargers are attached the helpers f= or fixed return mangled values. Here's an example case of a Google Pixel Flex Dual Port 67W USB-C Fast Char= ger with PPS support: POWER_SUPPLY_NAME=3Ducsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=3DUSB POWER_SUPPLY_CHARGE_TYPE=3DStandard POWER_SUPPLY_USB_TYPE=3DC [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=3D1 POWER_SUPPLY_VOLTAGE_MIN=3D5000000 POWER_SUPPLY_VOLTAGE_MAX=3D13400000 POWER_SUPPLY_VOLTAGE_NOW=3D20000000 POWER_SUPPLY_CURRENT_MAX=3D5790000 POWER_SUPPLY_CURRENT_NOW=3D3250000 Voltage Max is reading as 13.4V, but that's an incorrect decode of the PPS APDO in the last position. Same goes for CURRENT_MAX. 5.79A is incorrect. Instead, enumerate through the src_pdos and filter just for Fixed PDOs for now, and find the one with the highest voltage and current respectively. After, from the same charger: POWER_SUPPLY_NAME=3Ducsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=3DUSB POWER_SUPPLY_CHARGE_TYPE=3DStandard POWER_SUPPLY_USB_TYPE=3DC [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=3D1 POWER_SUPPLY_VOLTAGE_MIN=3D5000000 POWER_SUPPLY_VOLTAGE_MAX=3D20000000 POWER_SUPPLY_VOLTAGE_NOW=3D20000000 POWER_SUPPLY_CURRENT_MAX=3D4000000 POWER_SUPPLY_CURRENT_NOW=3D3250000 Signed-off-by: Benson Leung Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20251208174918.289394-3-bleung@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/usb/typec/ucsi/psy.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/drivers/usb/typec/ucsi/psy.c b/drivers/usb/typec/ucsi/psy.c index 3abe9370ffaaf..62160c4191718 100644 --- a/drivers/usb/typec/ucsi/psy.c +++ b/drivers/usb/typec/ucsi/psy.c @@ -112,15 +112,20 @@ static int ucsi_psy_get_voltage_max(struct ucsi_conne= ctor *con, union power_supply_propval *val) { u32 pdo; + int max_voltage =3D 0; =20 switch (UCSI_CONSTAT(con, PWR_OPMODE)) { case UCSI_CONSTAT_PWR_OPMODE_PD: - if (con->num_pdos > 0) { - pdo =3D con->src_pdos[con->num_pdos - 1]; - val->intval =3D pdo_fixed_voltage(pdo) * 1000; - } else { - val->intval =3D 0; + for (int i =3D 0; i < con->num_pdos; i++) { + int pdo_voltage =3D 0; + + pdo =3D con->src_pdos[i]; + if (pdo_type(pdo) =3D=3D PDO_TYPE_FIXED) + pdo_voltage =3D pdo_fixed_voltage(pdo) * 1000; + max_voltage =3D (pdo_voltage > max_voltage) ? pdo_voltage + : max_voltage; } + val->intval =3D max_voltage; break; case UCSI_CONSTAT_PWR_OPMODE_TYPEC3_0: case UCSI_CONSTAT_PWR_OPMODE_TYPEC1_5: @@ -168,6 +173,7 @@ static int ucsi_psy_get_current_max(struct ucsi_connect= or *con, union power_supply_propval *val) { u32 pdo; + int max_current =3D 0; =20 if (!UCSI_CONSTAT(con, CONNECTED)) { val->intval =3D 0; @@ -176,12 +182,16 @@ static int ucsi_psy_get_current_max(struct ucsi_conne= ctor *con, =20 switch (UCSI_CONSTAT(con, PWR_OPMODE)) { case UCSI_CONSTAT_PWR_OPMODE_PD: - if (con->num_pdos > 0) { - pdo =3D con->src_pdos[con->num_pdos - 1]; - val->intval =3D pdo_max_current(pdo) * 1000; - } else { - val->intval =3D 0; + for (int i =3D 0; i < con->num_pdos; i++) { + int pdo_current =3D 0; + + pdo =3D con->src_pdos[i]; + if (pdo_type(pdo) =3D=3D PDO_TYPE_FIXED) + pdo_current =3D pdo_max_current(pdo) * 1000; + max_current =3D (pdo_current > max_current) ? pdo_current + : max_current; } + val->intval =3D max_current; break; case UCSI_CONSTAT_PWR_OPMODE_TYPEC1_5: val->intval =3D UCSI_TYPEC_1_5_CURRENT * 1000; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAF853B775C; Sat, 28 Feb 2026 17:38:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300338; cv=none; b=E9Gdle7n1j+iuyuBseWD8XSW90vqp+3EBEMe5hsRqypitJm/7u53jioRIEWqfQ+BmX5CDNca0yRPJ4JUUyuofjH+SJptlP4BpM64Fz3N5+fx6aUL339ds/DzEyfAzU2mYLnnfRBIIBaJ8En6W3QUv9YW7k8s0o2rpLxWbfL7l60= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300338; c=relaxed/simple; bh=k6MRtvOHidhQD1Dwc8iePa7jUrChqt4sVoH4LSEX4nI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oMk9K7g54pFTrJgA4WikM3+RBGyb9/Oiv3pY1tD5sqDYLprlojB0gECW8aNbl3ktV7/Wqh+5aSx8mcVu7gJks8BCFLnxPVXvtyi7pB5FwDOFHD6R6j82AX1gVU6JToXaMn1eVK97Itmj88k+aznA4/Yo+gz4ijmc8OcLXFDngzQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NG8Ek/p1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NG8Ek/p1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB7EAC19424; Sat, 28 Feb 2026 17:38:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300338; bh=k6MRtvOHidhQD1Dwc8iePa7jUrChqt4sVoH4LSEX4nI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NG8Ek/p1tjaNKVvMY0L6r8SsA5FovYjQNwvQzvdAe/o3n3jT+VLOV0XLf24QtSS3e VoWf3TrZXjZ7jf1Uw2G57r8ELRZVBpeM2N2GCkEisA95iqYBTpPvXu/uNDkskB5TLt Tm30fB/Ng6XZny0DQQBMC6JSo02eceG8wEKxn+ja2RcUW7fjZ4Yj1EQZc6VmO+wxXs QGPz/ywku5Ehjg3fcyJ4ehkP3XAodbwYNv5Va6NrbgbZIwUkuzYAKFMNhTp4lIdlxI 9Z1+Vhjxhowxwvl+5ZtXeyPkgpGEGhB0SeFbWsDVmlw7okmVFHElpWubjiAontmw2L A3auCsGJdQX3A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nathan Chancellor , kernel test robot , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 371/844] tty: vt/keyboard: Split apart vt_do_diacrit() Date: Sat, 28 Feb 2026 12:24:44 -0500 Message-ID: <20260228173244.1509663-372-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nathan Chancellor [ Upstream commit 0a76a17238f805b231d97b118232a5185bbb7a18 ] After commit bfb24564b5fd ("tty: vt/keyboard: use __free()"), builds using asm goto for put_user() and get_user() with a version of clang older than 17 error with: drivers/tty/vt/keyboard.c:1709:7: error: cannot jump from this asm goto s= tatement to one of its possible targets if (put_user(asize, &a->kb_cnt)) ^ ... arch/arm64/include/asm/uaccess.h:298:2: note: expanded from macro '__put_= mem_asm' asm goto( \ ^ drivers/tty/vt/keyboard.c:1687:7: note: possible target of asm goto state= ment if (put_user(asize, &a->kb_cnt)) ^ ... arch/arm64/include/asm/uaccess.h:342:2: note: expanded from macro '__raw_= put_user' __rpu_failed: \ ^ drivers/tty/vt/keyboard.c:1697:23: note: jump exits scope of variable wit= h __attribute__((cleanup)) void __free(kfree) *buf =3D kmalloc_array(MAX_DIACR, size= of(struct kbdiacruc), ^ drivers/tty/vt/keyboard.c:1671:33: note: jump bypasses initialization of = variable with __attribute__((cleanup)) struct kbdiacr __free(kfree) *dia =3D kmalloc_array(MAX_D= IACR, sizeof(struct kbdiacr), ^ Prior to a fix to clang's scope checker in clang 17 [1], all labels in a function were validated as potential targets of all asm gotos in a function, regardless of whether they actually were a target of an asm goto call, resulting in false positive errors about skipping over variables marked with the cleanup attribute. To workaround this error, split up the bodies of the case statements in vt_do_diacrit() into their own functions so that the scope checker does not trip up on the multiple instances of __free(). Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202509091702.Oc7eCRDw-lkp@int= el.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202511241835.EA8lShgH-lkp@int= el.com/ Link: https://github.com/llvm/llvm-project/commit/f023f5cdb2e6c19026f04a15b= 5a935c041835d14 [1] Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20251125-tty-vt-keyboard-wa-clang-scope-chec= k-error-v1-1-f5a5ea55c578@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/tty/vt/keyboard.c | 221 ++++++++++++++++++++------------------ 1 file changed, 115 insertions(+), 106 deletions(-) diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c index d65fc60dd7bed..3538d54d6a6ac 100644 --- a/drivers/tty/vt/keyboard.c +++ b/drivers/tty/vt/keyboard.c @@ -1649,134 +1649,143 @@ int __init kbd_init(void) =20 /* Ioctl support code */ =20 -/** - * vt_do_diacrit - diacritical table updates - * @cmd: ioctl request - * @udp: pointer to user data for ioctl - * @perm: permissions check computed by caller - * - * Update the diacritical tables atomically and safely. Lock them - * against simultaneous keypresses - */ -int vt_do_diacrit(unsigned int cmd, void __user *udp, int perm) +static int vt_do_kdgkbdiacr(void __user *udp) { - int asize; - - switch (cmd) { - case KDGKBDIACR: - { - struct kbdiacrs __user *a =3D udp; - int i; + struct kbdiacrs __user *a =3D udp; + int i, asize; =20 - struct kbdiacr __free(kfree) *dia =3D kmalloc_array(MAX_DIACR, sizeof(st= ruct kbdiacr), - GFP_KERNEL); - if (!dia) - return -ENOMEM; + struct kbdiacr __free(kfree) *dia =3D kmalloc_array(MAX_DIACR, sizeof(str= uct kbdiacr), + GFP_KERNEL); + if (!dia) + return -ENOMEM; =20 - /* Lock the diacriticals table, make a copy and then - copy it after we unlock */ - scoped_guard(spinlock_irqsave, &kbd_event_lock) { - asize =3D accent_table_size; - for (i =3D 0; i < asize; i++) { - dia[i].diacr =3D conv_uni_to_8bit(accent_table[i].diacr); - dia[i].base =3D conv_uni_to_8bit(accent_table[i].base); - dia[i].result =3D conv_uni_to_8bit(accent_table[i].result); - } + /* Lock the diacriticals table, make a copy and then + copy it after we unlock */ + scoped_guard(spinlock_irqsave, &kbd_event_lock) { + asize =3D accent_table_size; + for (i =3D 0; i < asize; i++) { + dia[i].diacr =3D conv_uni_to_8bit(accent_table[i].diacr); + dia[i].base =3D conv_uni_to_8bit(accent_table[i].base); + dia[i].result =3D conv_uni_to_8bit(accent_table[i].result); } - - if (put_user(asize, &a->kb_cnt)) - return -EFAULT; - if (copy_to_user(a->kbdiacr, dia, asize * sizeof(struct kbdiacr))) - return -EFAULT; - return 0; } - case KDGKBDIACRUC: - { - struct kbdiacrsuc __user *a =3D udp; =20 - void __free(kfree) *buf =3D kmalloc_array(MAX_DIACR, sizeof(struct kbdia= cruc), - GFP_KERNEL); - if (buf =3D=3D NULL) - return -ENOMEM; + if (put_user(asize, &a->kb_cnt)) + return -EFAULT; + if (copy_to_user(a->kbdiacr, dia, asize * sizeof(struct kbdiacr))) + return -EFAULT; + return 0; +} =20 - /* Lock the diacriticals table, make a copy and then - copy it after we unlock */ - scoped_guard(spinlock_irqsave, &kbd_event_lock) { - asize =3D accent_table_size; - memcpy(buf, accent_table, asize * sizeof(struct kbdiacruc)); - } +static int vt_do_kdgkbdiacruc(void __user *udp) +{ + struct kbdiacrsuc __user *a =3D udp; + int asize; =20 - if (put_user(asize, &a->kb_cnt)) - return -EFAULT; - if (copy_to_user(a->kbdiacruc, buf, asize * sizeof(struct kbdiacruc))) - return -EFAULT; + void __free(kfree) *buf =3D kmalloc_array(MAX_DIACR, sizeof(struct kbdiac= ruc), + GFP_KERNEL); + if (buf =3D=3D NULL) + return -ENOMEM; =20 - return 0; + /* Lock the diacriticals table, make a copy and then + copy it after we unlock */ + scoped_guard(spinlock_irqsave, &kbd_event_lock) { + asize =3D accent_table_size; + memcpy(buf, accent_table, asize * sizeof(struct kbdiacruc)); } =20 - case KDSKBDIACR: - { - struct kbdiacrs __user *a =3D udp; - struct kbdiacr __free(kfree) *dia =3D NULL; - unsigned int ct; - int i; + if (put_user(asize, &a->kb_cnt)) + return -EFAULT; + if (copy_to_user(a->kbdiacruc, buf, asize * sizeof(struct kbdiacruc))) + return -EFAULT; =20 - if (!perm) - return -EPERM; - if (get_user(ct, &a->kb_cnt)) - return -EFAULT; - if (ct >=3D MAX_DIACR) - return -EINVAL; + return 0; +} =20 - if (ct) { - dia =3D memdup_array_user(a->kbdiacr, - ct, sizeof(struct kbdiacr)); - if (IS_ERR(dia)) - return PTR_ERR(dia); - } +static int vt_do_kdskbdiacr(void __user *udp, int perm) +{ + struct kbdiacrs __user *a =3D udp; + struct kbdiacr __free(kfree) *dia =3D NULL; + unsigned int ct; + int i; =20 - guard(spinlock_irqsave)(&kbd_event_lock); - accent_table_size =3D ct; - for (i =3D 0; i < ct; i++) { - accent_table[i].diacr =3D - conv_8bit_to_uni(dia[i].diacr); - accent_table[i].base =3D - conv_8bit_to_uni(dia[i].base); - accent_table[i].result =3D - conv_8bit_to_uni(dia[i].result); - } + if (!perm) + return -EPERM; + if (get_user(ct, &a->kb_cnt)) + return -EFAULT; + if (ct >=3D MAX_DIACR) + return -EINVAL; =20 - return 0; + if (ct) { + dia =3D memdup_array_user(a->kbdiacr, + ct, sizeof(struct kbdiacr)); + if (IS_ERR(dia)) + return PTR_ERR(dia); } =20 - case KDSKBDIACRUC: - { - struct kbdiacrsuc __user *a =3D udp; - unsigned int ct; - void __free(kfree) *buf =3D NULL; + guard(spinlock_irqsave)(&kbd_event_lock); + accent_table_size =3D ct; + for (i =3D 0; i < ct; i++) { + accent_table[i].diacr =3D + conv_8bit_to_uni(dia[i].diacr); + accent_table[i].base =3D + conv_8bit_to_uni(dia[i].base); + accent_table[i].result =3D + conv_8bit_to_uni(dia[i].result); + } =20 - if (!perm) - return -EPERM; + return 0; +} =20 - if (get_user(ct, &a->kb_cnt)) - return -EFAULT; +static int vt_do_kdskbdiacruc(void __user *udp, int perm) +{ + struct kbdiacrsuc __user *a =3D udp; + unsigned int ct; + void __free(kfree) *buf =3D NULL; =20 - if (ct >=3D MAX_DIACR) - return -EINVAL; + if (!perm) + return -EPERM; =20 - if (ct) { - buf =3D memdup_array_user(a->kbdiacruc, - ct, sizeof(struct kbdiacruc)); - if (IS_ERR(buf)) - return PTR_ERR(buf); - } - guard(spinlock_irqsave)(&kbd_event_lock); - if (ct) - memcpy(accent_table, buf, - ct * sizeof(struct kbdiacruc)); - accent_table_size =3D ct; - return 0; + if (get_user(ct, &a->kb_cnt)) + return -EFAULT; + + if (ct >=3D MAX_DIACR) + return -EINVAL; + + if (ct) { + buf =3D memdup_array_user(a->kbdiacruc, + ct, sizeof(struct kbdiacruc)); + if (IS_ERR(buf)) + return PTR_ERR(buf); } + guard(spinlock_irqsave)(&kbd_event_lock); + if (ct) + memcpy(accent_table, buf, + ct * sizeof(struct kbdiacruc)); + accent_table_size =3D ct; + return 0; +} + +/** + * vt_do_diacrit - diacritical table updates + * @cmd: ioctl request + * @udp: pointer to user data for ioctl + * @perm: permissions check computed by caller + * + * Update the diacritical tables atomically and safely. Lock them + * against simultaneous keypresses + */ +int vt_do_diacrit(unsigned int cmd, void __user *udp, int perm) +{ + switch (cmd) { + case KDGKBDIACR: + return vt_do_kdgkbdiacr(udp); + case KDGKBDIACRUC: + return vt_do_kdgkbdiacruc(udp); + case KDSKBDIACR: + return vt_do_kdskbdiacr(udp, perm); + case KDSKBDIACRUC: + return vt_do_kdskbdiacruc(udp, perm); } return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 917893B890D; Sat, 28 Feb 2026 17:38:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300339; cv=none; b=rrgtr3uBWnPNMBK7EjlYC57wktaMHGde6G7KmkkZyUB/j4LT0KqHfb50w3rsJC042sybhJXqMXqe5rEBfULh8x/iePD0J11p9+PW4tynwJHhdYUMxOC4Pp3qU+gk2nUGucpAPQGqYCFfdj73aNJnTl3C0ckB7/sf+mJpN1Rq3WY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300339; c=relaxed/simple; bh=BJiHfbMBDttSdwmqF2JckcA36kV56tfCTwb2LgXKDME=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ipts2mypbA7eVDsdM7jL570BouzNFc+x70B+7Kr1CC+KHsU12/+Vp0eI3dO++qYn3AWp1Efh3lohUqDDHuCpNdGrGL+opHS5z7yGm1SSfrNgD4iGErfc/Dd3A6CnqBzJ4HxkTUOHi7aJllrPx1c+R1fCf5Mye3AnGpEfq7x5Vvg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C4tTh/3H; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C4tTh/3H" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C98A4C19423; Sat, 28 Feb 2026 17:38:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300339; bh=BJiHfbMBDttSdwmqF2JckcA36kV56tfCTwb2LgXKDME=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C4tTh/3H8TbJvjaapcpOm0mvhPqGxW5a+fvfxUyn7lNvnOoPtdaN8zJ4YTJD3kiuS kqeIowm9W/ecpd4UFSYPkyodG9P92Wsj8diL9rI/bWl00ktJe1K77PTCRJMFqUs2+c XW9GyRk3+ePwi9MXlMifPAHrD0Sa2kZRlV1l9A6gejEPLR/IyMJZUh5WeZHUzXtn+W N13s6Ethe1kSM3RKqIicLH+ejZYHHtfsuH6UOtz51bJoMzxBb11HdrRwqw9dOiJ/ae zpSfWOaLfn9unwkthPPQ0ubFTPXiEZQukI5l7ctmmKNfYKUGP3jEvmIDqdg7s7JKRH e5ZXsNmhb7DGw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Biju Das , Lad Prabhakar , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 372/844] serial: rsci: Add set_rtrg() callback Date: Sat, 28 Feb 2026 12:24:45 -0500 Message-ID: <20260228173244.1509663-373-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Biju Das [ Upstream commit b346e5d7dbf6696176417923c49838a1beb1d785 ] The rtrg variable is populated in sci_init_single() for RZ/T2H. Add set_rtrg() callback for setting the rtrg value. Signed-off-by: Biju Das Tested-by: Lad Prabhakar Link: https://patch.msgid.link/20251129164325.209213-4-biju.das.jz@bp.renes= as.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/tty/serial/rsci.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/tty/serial/rsci.c b/drivers/tty/serial/rsci.c index b3c48dc1e07db..0533a4bb1d03c 100644 --- a/drivers/tty/serial/rsci.c +++ b/drivers/tty/serial/rsci.c @@ -151,6 +151,22 @@ static void rsci_start_rx(struct uart_port *port) rsci_serial_out(port, CCR0, ctrl); } =20 +static int rsci_scif_set_rtrg(struct uart_port *port, int rx_trig) +{ + u32 fcr =3D rsci_serial_in(port, FCR); + + if (rx_trig >=3D port->fifosize) + rx_trig =3D port->fifosize - 1; + else if (rx_trig < 1) + rx_trig =3D 0; + + fcr &=3D ~FCR_RTRG4_0; + fcr |=3D field_prep(FCR_RTRG4_0, rx_trig); + rsci_serial_out(port, FCR, fcr); + + return rx_trig; +} + static void rsci_set_termios(struct uart_port *port, struct ktermios *term= ios, const struct ktermios *old) { @@ -454,6 +470,7 @@ static const struct sci_port_ops rsci_port_ops =3D { .poll_put_char =3D rsci_poll_put_char, .prepare_console_write =3D rsci_prepare_console_write, .suspend_regs_size =3D rsci_suspend_regs_size, + .set_rtrg =3D rsci_scif_set_rtrg, .shutdown_complete =3D rsci_shutdown_complete, }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83C7B3B892B; Sat, 28 Feb 2026 17:39:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300340; cv=none; b=EzAtoWQKqoJWQ8pOlSfHQR+AndJ1hxstv/FybFgddwud4ujVjUlSOpalO1Cg4Owu6DrdUqSKPMATgO3+oW9fU+nlLd2aEPfxnLzeGrDAOZAF4tDL+94xZIY4yT0Ufs6XXanXqlW+5/IJYktTmFx3sgXeWiS2985QiabznV5vE8M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300340; c=relaxed/simple; bh=4B9zfesSIGCETB9yT7zZ8o1RykvPoYvqKhAu5noR5P0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rl3/b0omLlzy/HPrfqYpj5Z9B1QoUzhoigJEWDYcUsSA64RJ7rfBy26mU7Tw7kYB1gEnHdbbupBhQHB/HBQqKsSNgJupOSZxLBIoyZPtNHuIShZZgvQEjqFcOmnoEw8Z2kcofG17FeNaJiUMXSV6/wChOTySgGYLOjaGEWHuXTs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pH1CneM6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pH1CneM6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B79F5C2BC87; Sat, 28 Feb 2026 17:38:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300340; bh=4B9zfesSIGCETB9yT7zZ8o1RykvPoYvqKhAu5noR5P0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pH1CneM6NB0CYGHvwEo4Y5biUcELhwqzkJ7NBRvqDwonXA5Z3E11PggbBgpzaZD8h IBr5dHj6mjt1KYOkAA2J7wqDaZhqaT40n6dmaT1skdKRh4Zf+9C7+Q5UJOs7ohnwo+ 9f8giRK9hsMiqeSvqnEWSrkZeWxcncjLmjBk004OpM0mtMyFePqMt9B2YLa2QxRNYY LXDCnTVu4YElYcz6UE6L8VHXnOuZ4B1Uqjs+w2W82nPhJZpnCa4xrLwLLPPIDT3Opi 7imr4b5eGAdwHFCLlO4KfHbzPsBt0ig0EXPOxgUiEktBNSUSzWSwiMsvgnP1PDWgum QKPJ4As7nnOJQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Romain Gantois , Xu Yilun , Xu Yilun , Sasha Levin Subject: [PATCH 6.19 373/844] fpga: of-fpga-region: Fail if any bridge is missing Date: Sat, 28 Feb 2026 12:24:46 -0500 Message-ID: <20260228173244.1509663-374-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Romain Gantois [ Upstream commit c141c8221bc5089de915d9f26044df892c343c7e ] When parsing the region bridge list from the "fpga-bridges" device tree property, the of-fpga-region driver will silently ignore bridges which fail to be obtained, for example due to a missing bridge driver or invalid phandle. This can lead to hardware issues if a region bridge stays coupled when partial programming is performed. Fail if any of the bridges specified in "fpga-bridges" cannot be obtained. Signed-off-by: Romain Gantois Link: https://lore.kernel.org/r/20251127-of-fpga-region-fail-if-bridges-not= -found-v1-1-ca674f8d07eb@bootlin.com Reviewed-by: Xu Yilun Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/fpga/of-fpga-region.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c index 43db4bb77138a..caa091224dc54 100644 --- a/drivers/fpga/of-fpga-region.c +++ b/drivers/fpga/of-fpga-region.c @@ -83,7 +83,7 @@ static struct fpga_manager *of_fpga_region_get_mgr(struct= device_node *np) * done with the bridges. * * Return: 0 for success (even if there are no bridges specified) - * or -EBUSY if any of the bridges are in use. + * or an error code if any of the bridges are not available. */ static int of_fpga_region_get_bridges(struct fpga_region *region) { @@ -130,10 +130,10 @@ static int of_fpga_region_get_bridges(struct fpga_reg= ion *region) ®ion->bridge_list); of_node_put(br); =20 - /* If any of the bridges are in use, give up */ - if (ret =3D=3D -EBUSY) { + /* If any of the bridges are not available, give up */ + if (ret) { fpga_bridges_put(®ion->bridge_list); - return -EBUSY; + return ret; } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD7A93B8925; Sat, 28 Feb 2026 17:39:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300341; cv=none; b=Oy1ZG//jcF/cz1awE/jaJrbDVPDU1CGpJdBSOQQfQ9r+JOrGQIsKMZuSvrzYebeBEmoCfGniWFYTpZDJNbEkxXbZQZCS5xcjmz3n9eAI0tEtmwnYOWjFg4vEj1P5MVWpYJb24bZeH367MrZP04zKrkZInVIlZP0zont83nTjQ0k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300341; c=relaxed/simple; bh=QlgXHxLPUtH2sx/OHkgS6SP38Ze9WrPDAlWUKD10jUc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=k5E5sNJBWpSUrpT50faGBBlao6qu5e3OX58YAxS5j0qRowmUQBqJHjftODleiVtthUxKqRdJd4Kn1eM9pVwgVYkLSjdCvGSzcaEs3zN/V7KFxjcs/qGggOTyQQAbcBsoIwnqPn6Wvb8FSJ/XITmxLsirO08jme43/K5DmchZ0Vk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sNosKOzX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sNosKOzX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9AA6C116D0; Sat, 28 Feb 2026 17:39:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300341; bh=QlgXHxLPUtH2sx/OHkgS6SP38Ze9WrPDAlWUKD10jUc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sNosKOzXBgEjre7oc9ioOnDiL8TzThBdddSPGUV/ufkMqOFsOvuoGXBMUXSXXHkSB VNLoTfnZTPM1TTHv0qKCnm6Eg5l4DKmt8vQpRNG/iNC0g/oyyJgSOLPTAbIdnJUHaN m3+LIm9syJOUAzlJmX6KWkLH/OeeSPlGMaibYndyqc+ZjApl73W6qdW2s3D/8pxaHI xkdS91uBVYykm2Awawtkvakgi1qcQrVUIxWzHDzXSrB5rv1aBLsOh8trgPPmJFsM8c 4nF2h9NlJBeKzYz1U7y+ofQIz5i8jzVg6S1umEhGrLqQN0pxBx1l7LJOkAoZKMgT5n RKivWedo9bAFw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Navaneeth K , Abdun Nihaal , Dan Carpenter , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 374/844] most: core: fix resource leak in most_register_interface error paths Date: Sat, 28 Feb 2026 12:24:47 -0500 Message-ID: <20260228173244.1509663-375-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Navaneeth K [ Upstream commit 1f4c9d8a1021281750c6cda126d6f8a40cc24e71 ] The function most_register_interface() did not correctly release resources if it failed early (before registering the device). In these cases, it returned an error code immediately, leaking the memory allocated for the interface. Fix this by initializing the device early via device_initialize() and calling put_device() on all error paths. The most_register_interface() is expected to call put_device() on error which frees the resources allocated in the caller. The put_device() either calls release_mdev() or dim2_release(), depending on the caller. Switch to using device_add() instead of device_register() to handle the split initialization. Acked-by: Abdun Nihaal Signed-off-by: Navaneeth K Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20251127165337.19172-1-knavaneeth786@gmail.c= om Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/most/core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/most/core.c b/drivers/most/core.c index da319d108ea1d..6277e6702ca8c 100644 --- a/drivers/most/core.c +++ b/drivers/most/core.c @@ -1286,15 +1286,19 @@ int most_register_interface(struct most_interface *= iface) !iface->poison_channel || (iface->num_channels > MAX_CHANNELS)) return -EINVAL; =20 + device_initialize(iface->dev); + id =3D ida_alloc(&mdev_id, GFP_KERNEL); if (id < 0) { dev_err(iface->dev, "Failed to allocate device ID\n"); + put_device(iface->dev); return id; } =20 iface->p =3D kzalloc(sizeof(*iface->p), GFP_KERNEL); if (!iface->p) { ida_free(&mdev_id, id); + put_device(iface->dev); return -ENOMEM; } =20 @@ -1304,7 +1308,7 @@ int most_register_interface(struct most_interface *if= ace) iface->dev->bus =3D &mostbus; iface->dev->groups =3D interface_attr_groups; dev_set_drvdata(iface->dev, iface); - if (device_register(iface->dev)) { + if (device_add(iface->dev)) { dev_err(iface->dev, "Failed to register interface device\n"); kfree(iface->p); put_device(iface->dev); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB50A3BA240; Sat, 28 Feb 2026 17:39:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300342; cv=none; b=bLHqTqKBoYUfq0OsJ51jrGbeCz5MFbI8I/L/qrUuTdHKuYiTqmCqUwfQpX2lO3QZezwtC/1A8slsjblBRsfUXFo+F0q8kU9hm78C9Pp+KumMgjJ3TJitL969fYO80hSFiBKI86w6gZ7MFNVT7+xwRDQNHV2w43UFgtZuuFO1MHw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300342; c=relaxed/simple; bh=QT7k5Yx8S4mIz0mDONZEoZmlqOPLD2C4OTwYpUqprks=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H2baMUceHLovfTFtXm7RDZ/Sx5ab5UP7gjRJ30MY/aPHURR40EbW/s6VRkO1i6ysvui8b8cUFH7g/1R3drFkKR5y9a7wMq23jT8c9Slent0bdh/NOfjclXgT+PZt7oR1dUKZzK7EW4sb85ixVZ/w2UiOP6y39lpqg3r0u/HHFsc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Yth3WYRj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yth3WYRj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD72EC19423; Sat, 28 Feb 2026 17:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300342; bh=QT7k5Yx8S4mIz0mDONZEoZmlqOPLD2C4OTwYpUqprks=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Yth3WYRjn2HhhZle1s5gKydvOpQ4UXlKmfXfZUGoUbTFo/7jMsuRuzhXxjGooBaI8 /wGO7UHCKbvzrDC4PQbkIlBq/GuLFHt85EBipOP5cmuafaxybaQ6RBzgidfbaFEQ2l M15+kjG7KHQCLKDXFBvxmSmi2g0Gh7Ct58G88MzwCsb1oldnS0Ga9y3HqSZjN/Pdus gGkPPXLAGapC21Rkgn5Dhm1+f8INw7EcY3o83gxiXgkaF58v6l5zoAbRtbaccgmjRN vBVYz7bGPpLPM2zZi2Nxczfq6nfmWEyGi41qknEDN12QHsf4cTRAgiDi7Z8fonQ2Wp MSA/3+18WwuiQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chen-Yu Tsai , Jernej Skrabec , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 375/844] dmaengine: sun6i: Choose appropriate burst length under maxburst Date: Sat, 28 Feb 2026 12:24:48 -0500 Message-ID: <20260228173244.1509663-376-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chen-Yu Tsai [ Upstream commit 7178c3586ab42693b28bb81014320a7783e5c435 ] maxburst, as provided by the client, specifies the largest amount of data that is allowed to be transferred in one burst. This limit is normally provided to avoid a data burst overflowing the target FIFO. It does not mean that the DMA engine can only do bursts in that size. Let the driver pick the largest supported burst length within the given limit. This lets the driver work correctly with some clients that give a large maxburst value. In particular, the 8250_dw driver will give a quarter of the UART's FIFO size as maxburst. On some systems the FIFO size is 256 bytes, giving a maxburst of 64 bytes, while the hardware only supports bursts of up to 16 bytes. Signed-off-by: Chen-Yu Tsai Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20251221080450.1813479-1-wens@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/dma/sun6i-dma.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c index 2215ff877bf7d..f9d876deb1f05 100644 --- a/drivers/dma/sun6i-dma.c +++ b/drivers/dma/sun6i-dma.c @@ -583,6 +583,22 @@ static irqreturn_t sun6i_dma_interrupt(int irq, void *= dev_id) return ret; } =20 +static u32 find_burst_size(const u32 burst_lengths, u32 maxburst) +{ + if (!maxburst) + return 1; + + if (BIT(maxburst) & burst_lengths) + return maxburst; + + /* Hardware only does power-of-two bursts. */ + for (u32 burst =3D rounddown_pow_of_two(maxburst); burst > 0; burst /=3D = 2) + if (BIT(burst) & burst_lengths) + return burst; + + return 1; +} + static int set_config(struct sun6i_dma_dev *sdev, struct dma_slave_config *sconfig, enum dma_transfer_direction direction, @@ -616,15 +632,13 @@ static int set_config(struct sun6i_dma_dev *sdev, return -EINVAL; if (!(BIT(dst_addr_width) & sdev->slave.dst_addr_widths)) return -EINVAL; - if (!(BIT(src_maxburst) & sdev->cfg->src_burst_lengths)) - return -EINVAL; - if (!(BIT(dst_maxburst) & sdev->cfg->dst_burst_lengths)) - return -EINVAL; =20 src_width =3D convert_buswidth(src_addr_width); dst_width =3D convert_buswidth(dst_addr_width); - dst_burst =3D convert_burst(dst_maxburst); - src_burst =3D convert_burst(src_maxburst); + src_burst =3D find_burst_size(sdev->cfg->src_burst_lengths, src_maxburst); + dst_burst =3D find_burst_size(sdev->cfg->dst_burst_lengths, dst_maxburst); + dst_burst =3D convert_burst(dst_burst); + src_burst =3D convert_burst(src_burst); =20 *p_cfg =3D DMA_CHAN_CFG_SRC_WIDTH(src_width) | DMA_CHAN_CFG_DST_WIDTH(dst_width); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C808D3B8926; Sat, 28 Feb 2026 17:39:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300343; cv=none; b=jk+cpYKnIcjkbY/wgNgh4MEVtIP7q2cJrYQQtSbE+RxcR9qGMN/pxpNRV/n+xl8JF9bNrp4SwwHKA7IzKd3VsU4EU6z2ZqoDFPXnNi3i2cKcqEIRJgIqIjIdnpJq1Bj8fymNegApB77YVBrO0tkWLlBvifowzsUYEVXj/T1Fd2c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300343; c=relaxed/simple; bh=HdA84fezaPdN0UlF5lqo0bMf88YR7QriDE+7rE1Cuwc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=XYx4Pv3DLg+u7WpYeo3s5V6OWaBUPSM4BJ+c+VV/jzw1L+l7rSIZaZmT5L+nesFJSY5U348Tk8LePYY2koV+yQPOgk6U9nHGU8Fjwam+lXsxUXOcfHrzhk4nvOdNp+zq0Ca0GGt6yv7KJpc7LfaLos3nWx9rVz6w1xS/AqQo/C4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aQ3lACcK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aQ3lACcK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F45DC2BC87; Sat, 28 Feb 2026 17:39:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300343; bh=HdA84fezaPdN0UlF5lqo0bMf88YR7QriDE+7rE1Cuwc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aQ3lACcKjVeN319k4yhgR0ya9eNNdJH/uM4PWvBIGDL2F/eRYQ5/Zu/XLyUMoHRw+ 4ll9oTYe8f5H4WnWdy56z774BtCC9Y2Hzw7VH49oJZBVAeTbMZ4nrNLpiKR7KX991R g4g+Ps7bw45v2Mc+Vl5vrp0YSyqdfZ9IQvX9+wgDdMbyAJkzfnyJHqhpwCFIs/lZBU DMIL8B/tfvc16xdnQ3/DVWAMPCQDK6N/oOtZJBCkk86yErGnqJzJ3DeyB/QYG5lHQu EpSRdplCg7xAz6BUr2tPMvT1d2vr+jKwW96k3Wq2ESQlto9aPMiCUAc7lsI+jAI1V8 3bZjq1k/ovFlg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Cl=C3=A9ment=20Le=20Goffic?= , =?UTF-8?q?Cl=C3=A9ment=20Le=20Goffic?= , Amelie Delaunay , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 376/844] dmaengine: stm32-mdma: initialize m2m_hw_period and ccr to fix warnings Date: Sat, 28 Feb 2026 12:24:49 -0500 Message-ID: <20260228173244.1509663-377-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Cl=C3=A9ment Le Goffic [ Upstream commit aaf3bc0265744adbc2d364964ef409cf118d193d ] m2m_hw_period is initialized only when chan_config->m2m_hw is true. This triggers a warning: =E2=80=98m2m_hw_period=E2=80=99 may be used uninitialized [-Wmaybe-uninitia= lized] Although m2m_hw_period is only used when chan_config->m2m_hw is true and ignored otherwise, initialize it unconditionally to 0. ccr is initialized by stm32_mdma_set_xfer_param() when the sg list is not empty. This triggers a warning: =E2=80=98ccr=E2=80=99 may be used uninitialized [-Wmaybe-uninitialized] Indeed, it could be used uninitialized if the sg list is empty. Initialize it to 0. Signed-off-by: Cl=C3=A9ment Le Goffic Reviewed-by: Cl=C3=A9ment Le Goffic Signed-off-by: Amelie Delaunay Link: https://patch.msgid.link/20251217-mdma_warnings_fix-v2-1-340200e0bb55= @foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/dma/stm32/stm32-mdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/stm32/stm32-mdma.c b/drivers/dma/stm32/stm32-mdma.c index 080c1c725216c..b87d41b234df1 100644 --- a/drivers/dma/stm32/stm32-mdma.c +++ b/drivers/dma/stm32/stm32-mdma.c @@ -731,7 +731,7 @@ static int stm32_mdma_setup_xfer(struct stm32_mdma_chan= *chan, struct stm32_mdma_chan_config *chan_config =3D &chan->chan_config; struct scatterlist *sg; dma_addr_t src_addr, dst_addr; - u32 m2m_hw_period, ccr, ctcr, ctbr; + u32 m2m_hw_period =3D 0, ccr =3D 0, ctcr, ctbr; int i, ret =3D 0; =20 if (chan_config->m2m_hw) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFBE83BA8C2; Sat, 28 Feb 2026 17:39:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300345; cv=none; b=VL1VYrb+7+yG1sch1zUzTnFZiqOFV09lVLHx8jVq6a+OmEE3yvCSyiipaZkjyQl3LYmRUkdb/Fa8TcImPwhWClLXc21Hb1akttVx9QeGcqtG+tNM0vclfL0OvYxOwVoHaxBRv+0u3AUB/oUJjyeFPzCeTRqCuRSoe4L8skHXy34= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300345; c=relaxed/simple; bh=kk2/UZdY4A+i9yZHtFFnvjm4Eqf8Gk9+iUrxy+RCzw8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=M5PYH37xcnKU/WX2appsE+ESMg7t5m0vzGz7bBUvE4/bLovKEPXUSuYY0xYlsx6hULX6xZASSI/vp9D2blLYVFOzteC+BF3xG59VGGBP2qTP9DklJd4dXcvsYA3N6ddXJ73/QI4l3pp7mGGRZtiwkw4Uh+v2M1EFW6SiazQtuDE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U8vr3to9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U8vr3to9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4F0BC116D0; Sat, 28 Feb 2026 17:39:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300344; bh=kk2/UZdY4A+i9yZHtFFnvjm4Eqf8Gk9+iUrxy+RCzw8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U8vr3to925pE1BV3Mb/QN76jtlcxJobOZbJxKSeipBVoPQUttZY8chxg3AgrjoR+B tjjWk4LRQWgWKvFnnZTrHzR188c0v95ygXUa+FHHtf0tgim4C0H5sr8QS5rxgWMBOY lh4WacQBfOnSW1nAh2LvBmdkQ+GmCOCAVt5fF49Rl/owksqyqQMkkeJYGPLo9NN9+6 6+LAm+Jx4wvbJ9oh13oGZCoB4W0XMpGUQ7JKxMEUMrj5Pah7h0LIOf3iRsRu/0UGdl UCCDFfppIsKuReACjbb4jO8k9/Itxpm5tdhpbdo5m2e6YERKEvHMcJL3DvSssb4FnU QavVb6/aFM2WQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Thomas Richard (TI.com)" , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 377/844] phy: ti: phy-j721e-wiz: restore mux selection during resume Date: Sat, 28 Feb 2026 12:24:50 -0500 Message-ID: <20260228173244.1509663-378-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Thomas Richard (TI.com)" [ Upstream commit 53f6240e88c9e8715e09fc19942f13450db4cb33 ] While suspend and resume mux selection was getting lost. So save and restore these values in suspend and resume operations. Signed-off-by: Thomas Richard (TI.com) Link: https://patch.msgid.link/20251216-phy-ti-phy-j721e-wiz-resume-restore= -mux-sel-v1-1-771d564db966@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/phy/ti/phy-j721e-wiz.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c index a8b440c6c46bb..ba31b0a1f7f79 100644 --- a/drivers/phy/ti/phy-j721e-wiz.c +++ b/drivers/phy/ti/phy-j721e-wiz.c @@ -393,6 +393,7 @@ struct wiz { struct clk *output_clks[WIZ_MAX_OUTPUT_CLOCKS]; struct clk_onecell_data clk_data; const struct wiz_data *data; + int mux_sel_status[WIZ_MUX_NUM_CLOCKS]; }; =20 static int wiz_reset(struct wiz *wiz) @@ -1654,11 +1655,25 @@ static void wiz_remove(struct platform_device *pdev) pm_runtime_disable(dev); } =20 +static int wiz_suspend_noirq(struct device *dev) +{ + struct wiz *wiz =3D dev_get_drvdata(dev); + int i; + + for (i =3D 0; i < WIZ_MUX_NUM_CLOCKS; i++) + regmap_field_read(wiz->mux_sel_field[i], &wiz->mux_sel_status[i]); + + return 0; +} + static int wiz_resume_noirq(struct device *dev) { struct device_node *node =3D dev->of_node; struct wiz *wiz =3D dev_get_drvdata(dev); - int ret; + int ret, i; + + for (i =3D 0; i < WIZ_MUX_NUM_CLOCKS; i++) + regmap_field_write(wiz->mux_sel_field[i], wiz->mux_sel_status[i]); =20 /* Enable supplemental Control override if available */ if (wiz->sup_legacy_clk_override) @@ -1680,7 +1695,7 @@ static int wiz_resume_noirq(struct device *dev) return ret; } =20 -static DEFINE_NOIRQ_DEV_PM_OPS(wiz_pm_ops, NULL, wiz_resume_noirq); +static DEFINE_NOIRQ_DEV_PM_OPS(wiz_pm_ops, wiz_suspend_noirq, wiz_resume_n= oirq); =20 static struct platform_driver wiz_driver =3D { .probe =3D wiz_probe, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD7553BA8D3; Sat, 28 Feb 2026 17:39:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300345; cv=none; b=aBkLT4Dal0Ui5qh5nrHsox4qfMjbRDD61nEdBS54MTZdy0Oxhj/N11AjPr2mlu/5ZuQtgB10na1njor6WS6t0DI3d2Iwk2SQJ8t7Bc70kj24QdBhsopiaYq6lw4TFc3FVMto33bRo9LtTUPCZZYrmaf3dXXOdjbQ1Dfc6ub0UtU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300345; c=relaxed/simple; bh=QmJOBZaR5RMLhXGQoqBBPsyIqSkr6eHuIJHE0yzIkCk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p8KeVAf2FaM8MX0oB80JesQApQx1XHwwtN4jNU5WWLPCY+ixslSRauje9gt9jdnj2yqT7eor/q0kwJkIw1XnnnfyjwSJKppVGtTrggJCRXAcfm0SLtZyHr9IGEwPm9bD4HIzy4WsKvhpyZJ2HEYovqrp2P0bZtb+H0MGjYch3rA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Go2XSjQf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Go2XSjQf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80544C19424; Sat, 28 Feb 2026 17:39:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300345; bh=QmJOBZaR5RMLhXGQoqBBPsyIqSkr6eHuIJHE0yzIkCk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Go2XSjQfdsF8IZMTK70BnyRsQPm/OJEzBiELQqV/ygD28IlJjodgy+zoXj7AsLOy3 ZCTARIstp66CYZXT0+V4/VzWXVBJOWRjR2qKAudGZy9QKRX7zU1FGxdmgPJUAlVGuD N6Ug+3XspxPFbcda5fk7zyCT7tP1hXhH4II8DELhGAVdVmxVUkCFwUItCzR+QE9FIE APdrM0y6T/rAodnjEYMVBa8kaD7OZM60s4Mz11CEmtWkZmiTfP5Ot2hulRsQGQBr+m z/sr7C69rBlXEotau9kPApGNOxi0G7z9YJeUBf9WSIdnPaTU4k2TzUCzHpx7n0ISpF JjIv2KzeC8R8g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Thomas Richard (TI.com)" , Neil Armstrong , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 378/844] phy: cadence-torrent: restore parent clock for refclk during resume Date: Sat, 28 Feb 2026 12:24:51 -0500 Message-ID: <20260228173244.1509663-379-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Thomas Richard (TI.com)" [ Upstream commit 434e1a0ee145d0389b192252be4c993f86cf1134 ] While suspend and resume, parent clock config for refclk was getting lost. So save and restore it in suspend and resume operations. Reviewed-by: Neil Armstrong Signed-off-by: Thomas Richard (TI.com) Link: https://patch.msgid.link/20251216-phy-cadence-torrent-resume-restore-= refclk-parent-v3-1-8a7ed84b47e3@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/phy/cadence/phy-cadence-torrent.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drivers/phy/cadence/phy-cadence-torrent.c b/drivers/phy/cadenc= e/phy-cadence-torrent.c index 37fa4bad6bd72..877f22177c699 100644 --- a/drivers/phy/cadence/phy-cadence-torrent.c +++ b/drivers/phy/cadence/phy-cadence-torrent.c @@ -397,6 +397,7 @@ struct cdns_torrent_refclk_driver { struct clk_hw hw; struct regmap_field *cmn_fields[REFCLK_OUT_NUM_CMN_CONFIG]; struct clk_init_data clk_data; + u8 parent_index; }; =20 #define to_cdns_torrent_refclk_driver(_hw) \ @@ -3326,11 +3327,29 @@ static const struct cdns_torrent_vals sgmii_qsgmii_= xcvr_diag_ln_vals =3D { .num_regs =3D ARRAY_SIZE(sgmii_qsgmii_xcvr_diag_ln_regs), }; =20 +static void cdns_torrent_refclk_driver_suspend(struct cdns_torrent_phy *cd= ns_phy) +{ + struct clk_hw *hw =3D cdns_phy->clk_hw_data->hws[CDNS_TORRENT_REFCLK_DRIV= ER]; + struct cdns_torrent_refclk_driver *refclk_driver =3D to_cdns_torrent_refc= lk_driver(hw); + + refclk_driver->parent_index =3D cdns_torrent_refclk_driver_get_parent(hw); +} + +static int cdns_torrent_refclk_driver_resume(struct cdns_torrent_phy *cdns= _phy) +{ + struct clk_hw *hw =3D cdns_phy->clk_hw_data->hws[CDNS_TORRENT_REFCLK_DRIV= ER]; + struct cdns_torrent_refclk_driver *refclk_driver =3D to_cdns_torrent_refc= lk_driver(hw); + + return cdns_torrent_refclk_driver_set_parent(hw, refclk_driver->parent_in= dex); +} + static int cdns_torrent_phy_suspend_noirq(struct device *dev) { struct cdns_torrent_phy *cdns_phy =3D dev_get_drvdata(dev); int i; =20 + cdns_torrent_refclk_driver_suspend(cdns_phy); + reset_control_assert(cdns_phy->phy_rst); reset_control_assert(cdns_phy->apb_rst); for (i =3D 0; i < cdns_phy->nsubnodes; i++) @@ -3352,6 +3371,10 @@ static int cdns_torrent_phy_resume_noirq(struct devi= ce *dev) int node =3D cdns_phy->nsubnodes; int ret, i; =20 + ret =3D cdns_torrent_refclk_driver_resume(cdns_phy); + if (ret) + return ret; + ret =3D cdns_torrent_clk(cdns_phy); if (ret) return ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FA543BA8E4; Sat, 28 Feb 2026 17:39:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300346; cv=none; b=VEMX19lebWjJ1mIdlRGCadzHQev3F9MpaHR+ttAnxqB87FMzP0uQ3jKafaVB5xjAm79SXci2Qi/eiacegmnIRhvEAO7cD1Hp4qnk1LPGMAWhR84GsIR0Cmfd0desCniZESGFftstnfcJVOIJ13nPkJbqNfZLBK3ZCTHsvGS6wwg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300346; c=relaxed/simple; bh=wa9SgM5VuYcoV5xYsyuevJVQEAqVrSY4rN/akS6gnJI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VwGJVZOTB/tjMndxxn+scANEjMAQFT0OX1WFWNCf+nJKxebYeduzD4SKzI3xT0SEsGpZC+9ONsyl/Joc1A4INHxthUu8N+SlsD2jAb5mp1Vsvszo05lXsPg9uIzBrnYn13ctzhx+O3GGzSuBZMOckUoVVpHI37+rR6jSKbz7N3o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=thwszh8O; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="thwszh8O" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7267DC116D0; Sat, 28 Feb 2026 17:39:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300346; bh=wa9SgM5VuYcoV5xYsyuevJVQEAqVrSY4rN/akS6gnJI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=thwszh8Oaw1KEr3wjIhSBTBSqkPJyyQuB48kjqER4ElKamWwLqprYwa8pqKGyvrjo l0sbpoZwHrzf23+lxdVQyOT++JpeAqQXJxNuzNJh5pvX4duUWYRDnNXsWmgtrUbMtk Zn/raLYRr8rpio6P9oKmmegM0q/Q3Y5pKHMDTOo0q0UM8NfYGY1S9u18aPmAUd4kdt ZMgLuLmw+y5fs1+wmudXCJiFEyHBFGslJ9Ss5GDcGeyxlLlW4vZdDY7ESOyy9i2pWA sZ0qAIt2J12M9sxxGMbwD1bprETEz9MvPJLNOWRdLR6shs/gKqynx10L6abp+Nzjud Ql2gf1ljuOrKw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tuo Li , Scott Branden , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 379/844] misc: bcm_vk: Fix possible null-pointer dereferences in bcm_vk_read() Date: Sat, 28 Feb 2026 12:24:52 -0500 Message-ID: <20260228173244.1509663-380-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tuo Li [ Upstream commit ba75ecb97d3f4e95d59002c13afb6519205be6cb ] In the function bcm_vk_read(), the pointer entry is checked, indicating that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the following code may cause null-pointer dereferences: struct vk_msg_blk tmp_msg =3D entry->to_h_msg[0]; set_msg_id(&tmp_msg, entry->usr_msg_id); tmp_msg.size =3D entry->to_h_blks - 1; To prevent these possible null-pointer dereferences, copy to_h_msg, usr_msg_id, and to_h_blks from iter into temporary variables, and return these temporary variables to the application instead of accessing them through a potentially NULL entry. Signed-off-by: Tuo Li Reviewed-by: Scott Branden Link: https://patch.msgid.link/20251211063637.3987937-1-islituo@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/misc/bcm-vk/bcm_vk_msg.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/misc/bcm-vk/bcm_vk_msg.c b/drivers/misc/bcm-vk/bcm_vk_= msg.c index 1f42d1d5a630a..665a3888708ac 100644 --- a/drivers/misc/bcm-vk/bcm_vk_msg.c +++ b/drivers/misc/bcm-vk/bcm_vk_msg.c @@ -1010,6 +1010,9 @@ ssize_t bcm_vk_read(struct file *p_file, struct device *dev =3D &vk->pdev->dev; struct bcm_vk_msg_chan *chan =3D &vk->to_h_msg_chan; struct bcm_vk_wkent *entry =3D NULL, *iter; + struct vk_msg_blk tmp_msg; + u32 tmp_usr_msg_id; + u32 tmp_blks; u32 q_num; u32 rsp_length; =20 @@ -1034,6 +1037,9 @@ ssize_t bcm_vk_read(struct file *p_file, entry =3D iter; } else { /* buffer not big enough */ + tmp_msg =3D iter->to_h_msg[0]; + tmp_usr_msg_id =3D iter->usr_msg_id; + tmp_blks =3D iter->to_h_blks; rc =3D -EMSGSIZE; } goto read_loop_exit; @@ -1052,14 +1058,12 @@ ssize_t bcm_vk_read(struct file *p_file, =20 bcm_vk_free_wkent(dev, entry); } else if (rc =3D=3D -EMSGSIZE) { - struct vk_msg_blk tmp_msg =3D entry->to_h_msg[0]; - /* * in this case, return just the first block, so * that app knows what size it is looking for. */ - set_msg_id(&tmp_msg, entry->usr_msg_id); - tmp_msg.size =3D entry->to_h_blks - 1; + set_msg_id(&tmp_msg, tmp_usr_msg_id); + tmp_msg.size =3D tmp_blks - 1; if (copy_to_user(buf, &tmp_msg, VK_MSGQ_BLK_SIZE) !=3D 0) { dev_err(dev, "Error return 1st block in -EMSGSIZE\n"); rc =3D -EFAULT; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 947B833ADB2; Sat, 28 Feb 2026 17:39:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300347; cv=none; b=llW3b9rH3RWHXJKW3zIouAJQBtUlNB64Nt5PpOJ9hzD3Zc62M2ef3ZwkOzq+RWBc7+6yzAuK+YGJ2+PvdMqzreyOGmDFj6H69lUuC+iVE8UQUNw61Zid77GMkw4VkZ/YsZKGKQCbRcoRzHQYTyzpNsqGv4HtYorRZI9hTDVcfwc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300347; c=relaxed/simple; bh=eD98eyXOyek+cKc6dwkZtVgNb4YCbeFxdh7tKmVmhy4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eMCs7oJHvhyxYWQWHfYgpGAzo5kyan2iLu51oTRuTOEsZyTcCa+UznNDmqy65AmfnmU91YZgb6ntvxJt6u+zPSt5o4mL26IJIsz5SgfE8V7ehCvSBXkMQErkjWg60F6EQmxU8aNju8VmS0ezVjm1Ta3cSXVHPlGZetSBe4miXRw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iSTqe6Ro; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iSTqe6Ro" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 630CCC19425; Sat, 28 Feb 2026 17:39:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300347; bh=eD98eyXOyek+cKc6dwkZtVgNb4YCbeFxdh7tKmVmhy4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iSTqe6RoM4NQlLzkUete474UIQrHQrRI7BRZ3XS0Bb6FRunV411B/RBZcRYhQNO7p hnAwdwSKwjBsSESEUG/S1kfKlfLEer3hdzojLqeG2ICOfnzQgzWhLnWXQ1lEHtp7vq Uun6IATPXXUH13tsPqGToJKC/S5UdncqQupUBAmQ7hM/EluPTkfDyNO2bQjn3uEc24 TsOSC1uPdEPpUMo2Fm/zUsv/QhLhLp2pg5EHwNeeyziWFIX+aYkhevHxiS5LzVCIWA HT/guySpcmhtzlNAnkay9ds7hyPzBR/38ZJ3+UlfyIccDmoejdtWtwk+04wa62YUq/ Gq6VcnckiMMQA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Liang Jie , fanggeng , Linus Walleij , Sasha Levin Subject: [PATCH 6.19 380/844] pinctrl: mediatek: make devm allocations safer and clearer in mtk_eint_do_init() Date: Sat, 28 Feb 2026 12:24:53 -0500 Message-ID: <20260228173244.1509663-381-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Liang Jie [ Upstream commit 255b721c96046d4c57fa2268e4c72607868ce91f ] mtk_eint_do_init() allocates several pointer arrays which are then populated in a per-instance loop and freed on error. The arrays are currently allocated with devm_kmalloc(), so their entries are left uninitialised until the per-instance allocations succeed. On a failure in the middle of the loop, the error path iterates over the full nbase range and calls devm_kfree() on each element. For indices which were never initialised, the corresponding array entries contain stack garbage. If any of those happen to be non-zero, devm_kfree() will pass them to devres_destroy(), which will WARN because there is no matching devm_kmalloc() resource for such bogus pointers. Improve the robustness and readability by: - Using devm_kcalloc() for the pointer arrays so that all entries start as NULL, ensuring that only genuinely initialised elements may be freed and preventing spurious WARN_ON()s in the error path. - Switching the allocations to sizeof(*ptr) / sizeof(**ptr) forms, avoiding hard-coded element types and making the code more resilient to future type changes. - Dropping the redundant NULL checks before devm_kfree(), as devm_kfree() safely handles NULL pointers. The functional behaviour in the successful initialisation path remains unchanged, while the error handling becomes simpler and less error-prone. Reviewed-by: fanggeng Signed-off-by: Liang Jie Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pinctrl/mediatek/mtk-eint.c | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/drivers/pinctrl/mediatek/mtk-eint.c b/drivers/pinctrl/mediatek= /mtk-eint.c index c8c5097c11c4d..2a3c04eedc5f3 100644 --- a/drivers/pinctrl/mediatek/mtk-eint.c +++ b/drivers/pinctrl/mediatek/mtk-eint.c @@ -544,24 +544,32 @@ int mtk_eint_do_init(struct mtk_eint *eint, struct mt= k_eint_pin *eint_pin) } } =20 - eint->pin_list =3D devm_kmalloc(eint->dev, eint->nbase * sizeof(u16 *), G= FP_KERNEL); + eint->pin_list =3D devm_kcalloc(eint->dev, eint->nbase, + sizeof(*eint->pin_list), GFP_KERNEL); if (!eint->pin_list) goto err_pin_list; =20 - eint->wake_mask =3D devm_kmalloc(eint->dev, eint->nbase * sizeof(u32 *), = GFP_KERNEL); + eint->wake_mask =3D devm_kcalloc(eint->dev, eint->nbase, + sizeof(*eint->wake_mask), GFP_KERNEL); if (!eint->wake_mask) goto err_wake_mask; =20 - eint->cur_mask =3D devm_kmalloc(eint->dev, eint->nbase * sizeof(u32 *), G= FP_KERNEL); + eint->cur_mask =3D devm_kcalloc(eint->dev, eint->nbase, + sizeof(*eint->cur_mask), GFP_KERNEL); if (!eint->cur_mask) goto err_cur_mask; =20 for (i =3D 0; i < eint->nbase; i++) { - eint->pin_list[i] =3D devm_kzalloc(eint->dev, eint->base_pin_num[i] * si= zeof(u16), + eint->pin_list[i] =3D devm_kzalloc(eint->dev, + eint->base_pin_num[i] * sizeof(**eint->pin_list), GFP_KERNEL); port =3D DIV_ROUND_UP(eint->base_pin_num[i], 32); - eint->wake_mask[i] =3D devm_kzalloc(eint->dev, port * sizeof(u32), GFP_K= ERNEL); - eint->cur_mask[i] =3D devm_kzalloc(eint->dev, port * sizeof(u32), GFP_KE= RNEL); + eint->wake_mask[i] =3D devm_kzalloc(eint->dev, + port * sizeof(**eint->wake_mask), + GFP_KERNEL); + eint->cur_mask[i] =3D devm_kzalloc(eint->dev, + port * sizeof(**eint->cur_mask), + GFP_KERNEL); if (!eint->pin_list[i] || !eint->wake_mask[i] || !eint->cur_mask[i]) goto err_eint; } @@ -597,12 +605,9 @@ int mtk_eint_do_init(struct mtk_eint *eint, struct mtk= _eint_pin *eint_pin) =20 err_eint: for (i =3D 0; i < eint->nbase; i++) { - if (eint->cur_mask[i]) - devm_kfree(eint->dev, eint->cur_mask[i]); - if (eint->wake_mask[i]) - devm_kfree(eint->dev, eint->wake_mask[i]); - if (eint->pin_list[i]) - devm_kfree(eint->dev, eint->pin_list[i]); + devm_kfree(eint->dev, eint->cur_mask[i]); + devm_kfree(eint->dev, eint->wake_mask[i]); + devm_kfree(eint->dev, eint->pin_list[i]); } devm_kfree(eint->dev, eint->cur_mask); err_cur_mask: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12A173BA259; Sat, 28 Feb 2026 17:39:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300348; cv=none; b=o0evWMKicRhq/VDJMVEEHTWVQWuTDAoJGWybyPFUYBZzzwC7xdNedMaoQCo3n14JbzoBvuBIdHQJR8zqlTnDnBZYmB+NXiq9hK02KsgHITLliErQxRqPtNF4Uqr4/U7orEtsn4i9gIytmTWKDbyhMWs4JPBSFLD8Ee0Kx1nsHOs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300348; c=relaxed/simple; bh=m1ZSAN/ySeKCQCFbk2w7m2/15nYVBMXoKuwOBd1+OFU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iJd/HNiUJdIjFRKIEhGwor6AJ+hhSFv772MiFK6b/drYWyH717iC6cFsAhBG0n+MttjpWTirJfInf6M9WX3LCghvM9gdN3OhB1BtrwISptyuAP9vaGMnY3hYX8FSByRPSlZrsvmIf62nCZG4RAarkRofMU8pph9QSF9om3AonAQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cZ/nYlR2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cZ/nYlR2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5627CC2BC9E; Sat, 28 Feb 2026 17:39:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300347; bh=m1ZSAN/ySeKCQCFbk2w7m2/15nYVBMXoKuwOBd1+OFU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cZ/nYlR2scG41iDDbCPlptAtPET6GsiZ8xCxMp97AXzADX1KD5yBrnc5jKBpjtKfT i6/oGaIl++jo45flMQr8iZ4xw75fUaoUuR49sfD6iuvsFEeZwacIMfiQ6xRI/x0uO4 kTuU+z+ahYQ0RCDJniAHvEPmt5b7Y/6bW2Yjq9ySBaTj8RzvpFbq0IsphvUS52woxJ nZil/fNR6xGlqAgQ4gXszge/ruM4Bn5QXd2s/sy+31f+NbLhsGJajO7RPVA5uJ1M0Y mchSCUo2EjWtvmMWhD0h/FjazmYjcLGXkZuv1VW08sLkkv47kGIB0nKTgH60CTM2W9 on9ybHRw8oXfA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Markus Perkins , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 381/844] misc: eeprom: Fix EWEN/EWDS/ERAL commands for 93xx56 and 93xx66 Date: Sat, 28 Feb 2026 12:24:54 -0500 Message-ID: <20260228173244.1509663-382-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Markus Perkins [ Upstream commit b54c82d6cbfc76647ba558e8e3647eb2b0ba0e2b ] commit 14374fbb3f06 ("misc: eeprom_93xx46: Add new 93c56 and 93c66 compatible strings") added support for 93xx56 and 93xx66 eeproms, but didn't take into account that the write enable/disable + erase all commands are hardcoded for the 6-bit address of the 93xx46. This commit fixes the command word generation by increasing the number of shifts as the address field grows, keeping the command intact. Also, the check for 8-bit or 16-bit mode is no longer required as this is already taken into account in the edev->addrlen field. Signed-off-by: Markus Perkins Link: https://patch.msgid.link/20251202104823.429869-3-markus@notsyncing.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/misc/eeprom/eeprom_93xx46.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/misc/eeprom/eeprom_93xx46.c b/drivers/misc/eeprom/eepr= om_93xx46.c index 9cae6f530679b..5230e910a1d11 100644 --- a/drivers/misc/eeprom/eeprom_93xx46.c +++ b/drivers/misc/eeprom/eeprom_93xx46.c @@ -45,6 +45,7 @@ struct eeprom_93xx46_platform_data { #define OP_START 0x4 #define OP_WRITE (OP_START | 0x1) #define OP_READ (OP_START | 0x2) +/* The following addresses are offset for the 1K EEPROM variant in 16-bit = mode */ #define ADDR_EWDS 0x00 #define ADDR_ERAL 0x20 #define ADDR_EWEN 0x30 @@ -191,10 +192,7 @@ static int eeprom_93xx46_ew(struct eeprom_93xx46_dev *= edev, int is_on) bits =3D edev->addrlen + 3; =20 cmd_addr =3D OP_START << edev->addrlen; - if (edev->pdata->flags & EE_ADDR8) - cmd_addr |=3D (is_on ? ADDR_EWEN : ADDR_EWDS) << 1; - else - cmd_addr |=3D (is_on ? ADDR_EWEN : ADDR_EWDS); + cmd_addr |=3D (is_on ? ADDR_EWEN : ADDR_EWDS) << (edev->addrlen - 6); =20 if (has_quirk_instruction_length(edev)) { cmd_addr <<=3D 2; @@ -328,10 +326,7 @@ static int eeprom_93xx46_eral(struct eeprom_93xx46_dev= *edev) bits =3D edev->addrlen + 3; =20 cmd_addr =3D OP_START << edev->addrlen; - if (edev->pdata->flags & EE_ADDR8) - cmd_addr |=3D ADDR_ERAL << 1; - else - cmd_addr |=3D ADDR_ERAL; + cmd_addr |=3D ADDR_ERAL << (edev->addrlen - 6); =20 if (has_quirk_instruction_length(edev)) { cmd_addr <<=3D 2; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3212235D9A5; Sat, 28 Feb 2026 17:39:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300349; cv=none; b=pnOyamTSbensk+MWTycFCWHtq/qYU2g70+Vt3EdavQnpSyH+/r9iEP+VV++Ec7li+1xCGoef+PnOsp+1jk4B8M+uWuaJjp9c4ZZGwPkapmx32EzcCzYnqqA4Ae5EA9wB2H7qGlMWYNGtQmFgg/zzyQ8VLthxpG6nYs5ZSWv70jY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300349; c=relaxed/simple; bh=vDZ/7HLswCBu3RNHT/Isx3jQGWhJcnEeUc0aAdaKRdo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VWFsApas+D9hM5OvvVSAu4pPT/Qcv/7rRHUdWX38IPjqOz6cioZ9kkuKog53X5pDgctDhHHRnL6OGAxn2eT0bFajwVCgemi44VyJ8oI7A/xSexKhH446e/PUfRTFqKxKPOy6WwAiOZOyNe7O3S/95NZ9OygdqYvc9kWi6lqMajI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Hzq8OTtK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Hzq8OTtK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33F33C19424; Sat, 28 Feb 2026 17:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300348; bh=vDZ/7HLswCBu3RNHT/Isx3jQGWhJcnEeUc0aAdaKRdo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hzq8OTtKsWxY4fzxEWLWvRzJ0TJk8LjyuofPdX4T0CGZgRIc9kc2g3jiV1NSLKMLg 6+i1HUDJqgZRRdshj9jXhuhwtj1fgjcqKm62VtvOMA1Swwj5cdrKZFwZIHFyzryPmy csOYeuwJAWLJQ/PZ6Rgk2buY93oP3GSXTU0cuV2iO23L8Eo6splrEgbngsTMzwoS7S x8U83JqIwBfvmRO+EnczsoKPfwzta/CDxmA0gaYbTWmCrVhwhahupqlcQxmBXDnBgV eiRq6PtL7HSwK8qleCUii1+/PCTSwVeMDXojke06wmKvLVOMgWqi5haWxl32wJkH2T lNbzZSqnEuZ/Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Felix Gu , Romain Gantois , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 382/844] misc: ti_fpc202: fix a potential memory leak in probe function Date: Sat, 28 Feb 2026 12:24:55 -0500 Message-ID: <20260228173244.1509663-383-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Felix Gu [ Upstream commit dad9f13d967b4e53e8eaf5f9c690f8e778ad9802 ] Use for_each_child_of_node_scoped() to simplify the code and ensure the device node reference is automatically released when the loop scope ends. Signed-off-by: Felix Gu Reviewed-by: Romain Gantois Link: https://patch.msgid.link/tencent_FA1AC670F5CF49873F88A44424F866994A08= @qq.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/misc/ti_fpc202.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/misc/ti_fpc202.c b/drivers/misc/ti_fpc202.c index 7964e46c74482..8eb2b5ac98506 100644 --- a/drivers/misc/ti_fpc202.c +++ b/drivers/misc/ti_fpc202.c @@ -309,7 +309,6 @@ static void fpc202_remove_port(struct fpc202_priv *priv= , int port_id) static int fpc202_probe(struct i2c_client *client) { struct device *dev =3D &client->dev; - struct device_node *i2c_handle; struct fpc202_priv *priv; int ret, port_id; =20 @@ -357,7 +356,7 @@ static int fpc202_probe(struct i2c_client *client) =20 bitmap_zero(priv->probed_ports, FPC202_NUM_PORTS); =20 - for_each_child_of_node(dev->of_node, i2c_handle) { + for_each_child_of_node_scoped(dev->of_node, i2c_handle) { ret =3D of_property_read_u32(i2c_handle, "reg", &port_id); if (ret) { if (ret =3D=3D -EINVAL) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0F183BE2E0; Sat, 28 Feb 2026 17:39:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300349; cv=none; b=UNSUt5BV5DPzgbmjv7sz7jA5OSIH2EMztLKqQ03TlQJt3iQgLYahZ/5AIPnb25xKDJ6QfhMYauK+RnaIcZSJPdCVXDhdphQ9Pwn2gDhSr9ooVOu8rFmQ3JHtEusb9hCtQY0tTQmmEeZ8xIA23JsuOnvClqDx32NjmNI3f/0ph2A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300349; c=relaxed/simple; bh=FtLPtrI0n80xUd47vPTSe/TrOI8y2V9Hv0qj46pAWpQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RYW+atiYK9CGRfSWFhpHUX2PDG0e7lN5ZSU4ILgSIsfP1IKmpvMmAJueAD3Ku60Ef/HzNDo01FhWwW1vA4ut/odbaMuoGdyZ+VUwZl4Nv2ltplg/q3Vo0ghb6aFzJvbT/UM7TbaDILdWJ0uczjc3kLLTytov028ORD/GEtDoBUM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HzUXjEWP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HzUXjEWP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22DCAC116D0; Sat, 28 Feb 2026 17:39:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300349; bh=FtLPtrI0n80xUd47vPTSe/TrOI8y2V9Hv0qj46pAWpQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HzUXjEWPidg5Ms0u6plunCLC775KG+YurFXSa3oqiTiuZ7f13LeFRESHcUWSWnvzo jZmOwXI7OvLw8NkiLaUHmf3a5SO6RvF6yToEOfj02Dp6H/HHzTuR45PspX6QGjN0jG WGA3msTR2XxgVurBkGBsjltMwVHNRvePAfwjo2sQsVzbZmGDA9L2CcrvWCYWsSnOTL wafbACKQ0vtSftOVAeHJW0zG/0/CyiO3u2PA74rVelc97FQM8pLcfycDuNuT0Xp95+ q1Zd68y8baN6B15tZXuOUhB8WbPgcRtBYXuLEceRqgq6PkQ2rqBe0dghipNxKiI/hu l2+Lc6u92hmjA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Cosmin Tanislav , Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.19 383/844] pinctrl: renesas: rzt2h: Allow .get_direction() for IRQ function GPIOs Date: Sat, 28 Feb 2026 12:24:56 -0500 Message-ID: <20260228173244.1509663-384-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Cosmin Tanislav [ Upstream commit 49b039a61a314c18074c15a7047705399e1240e6 ] Setting up an IRQ would normally be done in the .activate() and .deactivate() ops of the IRQ domain, but for hierarchical IRQ domains the .activate() and .deactivate() ops are overridden in the gpiochip_hierarchy_setup_domain_ops() function. As such, activating and deactivating need to be done in the .translate() and .free() ops of the IRQ domain. For RZ/T2H and RZ/N2H, interrupts go through the pin controller, into the ICU, which level-translates them and forwards them to the GIC. To use a GPIO as an interrupt it needs to be put into peripheral function mode 0, which will connect it to the IRQ lines of the ICU. The IRQ chip .child_to_parent_hwirq() callback is called as part of the IRQ fwspec parsing logic (as part of irq_create_of_mapping()) which happens before the IRQ is requested (as part of gpiochip_lock_as_irq()). gpiochip_lock_as_irq() calls gpiod_get_direction() if the .get_direction() callback is provided to ensure that the GPIO line is set up as input. In our case, IRQ function is separate from GPIO, and both cannot be true at the same time. Return GPIO_LINE_DIRECTION_IN even if pin is in IRQ function to allow this setup to work. Hold the spinlock to ensure atomicity between reading the PMC register (which determines whether the pin is in GPIO mode or not) and reading the function of the pin when it is not in GPIO mode. Signed-off-by: Cosmin Tanislav Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251205150234.2958140-3-cosmin-gabriel.tani= slav.xa@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pinctrl/renesas/pinctrl-rzt2h.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/pinctrl/renesas/pinctrl-rzt2h.c b/drivers/pinctrl/rene= sas/pinctrl-rzt2h.c index 4826ff91cd906..40df706210119 100644 --- a/drivers/pinctrl/renesas/pinctrl-rzt2h.c +++ b/drivers/pinctrl/renesas/pinctrl-rzt2h.c @@ -51,6 +51,7 @@ =20 #define PFC_MASK GENMASK_ULL(5, 0) #define PFC_PIN_MASK(pin) (PFC_MASK << ((pin) * 8)) +#define PFC_FUNC_INTERRUPT 0 =20 /* * Use 16 lower bits [15:0] for pin identifier @@ -486,6 +487,7 @@ static int rzt2h_gpio_get_direction(struct gpio_chip *c= hip, unsigned int offset) struct rzt2h_pinctrl *pctrl =3D gpiochip_get_data(chip); u8 port =3D RZT2H_PIN_ID_TO_PORT(offset); u8 bit =3D RZT2H_PIN_ID_TO_PIN(offset); + u64 reg64; u16 reg; int ret; =20 @@ -493,8 +495,25 @@ static int rzt2h_gpio_get_direction(struct gpio_chip *= chip, unsigned int offset) if (ret) return ret; =20 - if (rzt2h_pinctrl_readb(pctrl, port, PMC(port)) & BIT(bit)) + guard(spinlock_irqsave)(&pctrl->lock); + + if (rzt2h_pinctrl_readb(pctrl, port, PMC(port)) & BIT(bit)) { + /* + * When a GPIO is being requested as an IRQ, the pinctrl + * framework expects to be able to read the GPIO's direction. + * IRQ function is separate from GPIO, and enabling it takes the + * pin out of GPIO mode. + * At this point, .child_to_parent_hwirq() has already been + * called to enable the IRQ function. + * Default to input direction for IRQ function. + */ + reg64 =3D rzt2h_pinctrl_readq(pctrl, port, PFC(port)); + reg64 =3D (reg64 >> (bit * 8)) & PFC_MASK; + if (reg64 =3D=3D PFC_FUNC_INTERRUPT) + return GPIO_LINE_DIRECTION_IN; + return -EINVAL; + } =20 reg =3D rzt2h_pinctrl_readw(pctrl, port, PM(port)); reg =3D (reg >> (bit * 2)) & PM_MASK; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB4023BE30C; Sat, 28 Feb 2026 17:39:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300350; cv=none; b=RG8WK6WjIk89G6uReBtyzx8uTMVv1zT7p/Ab6daBgbpKBkg7RlcbqdKlv9vHOilSkm1ZYs8/MZSNTUWCDM9kIMxB+WmdmwbYHqqoTN3DMvuy9ouYTRD39tYuSo5h0NY0R+kkJfLO6jJmdKYTuefZ5fL6xytyo5ZhBn/t06EHhCA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300350; c=relaxed/simple; bh=TZJLHA1ruZzfEsUVx0wbMMbI14TZoKcsi1pdmpeNt4A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=e9djr5YmMCU79rEaN/M2W5gqyRDMbyLRdFXKf06ezV8X54OJqwYq2qeRTms88b/d4KdPgZribtZ2eudZyal+NTSqd6jQEkV1YOdb9AQWI5Ge46kE1SfuLbJn+tzJd8AWZ5cLAfhI16YV0VoJ9myrFbJ0d9w/mutZBB4lF8mtoJo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aITxAjSr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aITxAjSr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2394C116D0; Sat, 28 Feb 2026 17:39:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300350; bh=TZJLHA1ruZzfEsUVx0wbMMbI14TZoKcsi1pdmpeNt4A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aITxAjSr8IgQ9MbwGrUf24ScxIoQEIrnNyk2Qp8BV6odMZa7sIZ3JFqpeaSxXVVzM k5niqIMArSV87Hk+vhHdKphEO8f84LII9eplxP+FdvJZ3M1KZqEgFih2wsERCCPHj/ VXobQDZJZZYXrtOVip4iuV+l0QqoAMyH+vcga5UCAuchyx+JuWyKWuYC09887t6bDa EjvqgAVYHOfcCVXUbTfWVXdKBf5ulX6Dqn/4fQ8AV+84pvZq7srdaejIMlLRLGsKlG eVTIQ5FNdzXe1SQpAGT8mBYFsucyhxww8+Hd7pnLttrZjgIfaX6Xep4YFWGxvIZCIt hXO/PGTlqb/0Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Derek J. Clark" , Andy Shevchenko , Jonathan Cameron , Sasha Levin Subject: [PATCH 6.19 384/844] iio: bmi270_i2c: Add MODULE_DEVICE_TABLE for BMI260/270 Date: Sat, 28 Feb 2026 12:24:57 -0500 Message-ID: <20260228173244.1509663-385-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Derek J. Clark" [ Upstream commit f69b5ac682dbc61e6aca806c22ce2ae74d598e45 ] Currently BMI260 & BMI270 devices do not automatically load this driver. To fix this, add missing MODULE_DEVICE_TABLE for the i2c, acpi, and of device tables so the driver will load when the hardware is detected. Tested on my OneXPlayer F1 Pro. Signed-off-by: Derek J. Clark Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iio/imu/bmi270/bmi270_i2c.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/imu/bmi270/bmi270_i2c.c b/drivers/iio/imu/bmi270/b= mi270_i2c.c index b909a421ad017..b92da4e0776fa 100644 --- a/drivers/iio/imu/bmi270/bmi270_i2c.c +++ b/drivers/iio/imu/bmi270/bmi270_i2c.c @@ -37,6 +37,7 @@ static const struct i2c_device_id bmi270_i2c_id[] =3D { { "bmi270", (kernel_ulong_t)&bmi270_chip_info }, { } }; +MODULE_DEVICE_TABLE(i2c, bmi270_i2c_id); =20 static const struct acpi_device_id bmi270_acpi_match[] =3D { /* GPD Win Mini, Aya Neo AIR Pro, OXP Mini Pro, etc. */ @@ -45,12 +46,14 @@ static const struct acpi_device_id bmi270_acpi_match[] = =3D { { "BMI0260", (kernel_ulong_t)&bmi260_chip_info }, { } }; +MODULE_DEVICE_TABLE(acpi, bmi270_acpi_match); =20 static const struct of_device_id bmi270_of_match[] =3D { { .compatible =3D "bosch,bmi260", .data =3D &bmi260_chip_info }, { .compatible =3D "bosch,bmi270", .data =3D &bmi270_chip_info }, { } }; +MODULE_DEVICE_TABLE(of, bmi270_of_match); =20 static struct i2c_driver bmi270_i2c_driver =3D { .driver =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DDFF53BED06; Sat, 28 Feb 2026 17:39:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300351; cv=none; b=RzTxsp00R7gXDpyVp4bMwDofku1eQEDa8c/EruaUXMOgaNCqSQkjRfl/9yBpY+EvdmXMwu6ke2bP1UM0ifuhR5DzSQlaKkZmU68tTYc7oUDUYqu/x1nOyknjFLmwpa5a3UGD9Dlj8SgF+MhPpzrBTKQyjvuooM/TP3UpHo7BYtY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300351; c=relaxed/simple; bh=TCTzgd/ixZeKmx5B74oVFbclG3zNxk6BZ936t2NpB1w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eZdid4SDyTufRk2arN7tFNyntX9NPxHCeUpR28WGHfTqmvocb6KcTtZHd9lGe2/u6oMi+PlRRZnnTUISd07hDQ5L4pswXfqpynjaPjBa5fD8PX8O/lNTCVPcJF1b2pd7gDJDG6sXB+IuAkh/dwrJDAXC042eZdnQHTS83wBQmdA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D7xR3V3Z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="D7xR3V3Z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1ED8C19425; Sat, 28 Feb 2026 17:39:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300351; bh=TCTzgd/ixZeKmx5B74oVFbclG3zNxk6BZ936t2NpB1w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D7xR3V3Z1NrhLD+1pN+pyEi7r1tS0nrmFnk2X9cZvZ/yZ8JKQvc+6kUlO7T4FTl8g RtmiM/5VorMUbcgh33CakP+d+tC795QcLTG02kc8eHoO/juV+AWoDbUKj68bVKxYbD TwodyxjL2ognjWFfJt8j3JB9TwFzfpF72mJjAfwobuHbwnc2PyfVcuASmNjTt4r3yQ D0aJXhtdYqIN+rsN+lv5z3s5UGv/ScNFky1lUS5W7wLI5Jzhum2YwwMS6jaS9hwncZ LJ8sGWwsEqKtuerrTvXCY/sQTBnKD50p4r2fFSxpjMdjZLj1j2LFvQ6f85QK1SEu0P V2Cp9rANjX3Tw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sam Day , David Heidelberg , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 385/844] usb: gadget: f_fs: fix DMA-BUF OUT queues Date: Sat, 28 Feb 2026 12:24:58 -0500 Message-ID: <20260228173244.1509663-386-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sam Day [ Upstream commit 0145e7acd29855dfba4a2f387d455b5d9a520f0e ] Currently, DMA_FROM_DEVICE is used when attaching DMABUFs to IN endpoints and DMA_TO_DEVICE for OUT endpoints. This is inverted from how it should be. The result is IOMMU read-only mappings placed on OUT queues, triggering arm-smmu write faults. Put differently, OUT endpoints flow data from host -> gadget, meaning the UDC peripheral needs to have write access to the buffer to fill it with the incoming data. This commit flips the directions and updates the implicit-sync helpers so IN endpoints act as readers and OUT endpoints as writers. Signed-off-by: Sam Day Tested-by: David Heidelberg # OnePlus 6T on sdm845-next-20= 251119 Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-2-e51633891= a81@samcday.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/usb/gadget/function/f_fs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/functi= on/f_fs.c index fa467a40949d2..928f51fddc64e 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -1509,7 +1509,7 @@ static int ffs_dmabuf_attach(struct file *file, int f= d) goto err_dmabuf_detach; } =20 - dir =3D epfile->in ? DMA_FROM_DEVICE : DMA_TO_DEVICE; + dir =3D epfile->in ? DMA_TO_DEVICE : DMA_FROM_DEVICE; =20 err =3D ffs_dma_resv_lock(dmabuf, nonblock); if (err) @@ -1639,7 +1639,7 @@ static int ffs_dmabuf_transfer(struct file *file, /* Make sure we don't have writers */ timeout =3D nonblock ? 0 : msecs_to_jiffies(DMABUF_ENQUEUE_TIMEOUT_MS); retl =3D dma_resv_wait_timeout(dmabuf->resv, - dma_resv_usage_rw(epfile->in), + dma_resv_usage_rw(!epfile->in), true, timeout); if (retl =3D=3D 0) retl =3D -EBUSY; @@ -1684,7 +1684,7 @@ static int ffs_dmabuf_transfer(struct file *file, dma_fence_init(&fence->base, &ffs_dmabuf_fence_ops, &priv->lock, priv->context, seqno); =20 - resv_dir =3D epfile->in ? DMA_RESV_USAGE_WRITE : DMA_RESV_USAGE_READ; + resv_dir =3D epfile->in ? DMA_RESV_USAGE_READ : DMA_RESV_USAGE_WRITE; =20 dma_resv_add_fence(dmabuf->resv, &fence->base, resv_dir); dma_resv_unlock(dmabuf->resv); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 864BA3BED1C; Sat, 28 Feb 2026 17:39:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300352; cv=none; b=MI3y5zXTFBsNDUPzoUI9OwNmumsLGfD36rxnA5C9F1TRkM+V6JSjc90ujjK2nwtgzPaYlb6l2f5LSf0D8BUaFALuRf3opJM1QIs/PGGxnffHN1BfIHf6U7BgQN6NiA8Dii1Xey1qv5SUs0Ck3PXskUwiB2B2ou/sFH2xfZ+AjY8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300352; c=relaxed/simple; bh=dB6FPpCoDZ1xiwuejfr7S5mzPXo8oS/VjLqIRF8hHqg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W/sDAr2oajDaMuAfOsVkQpPS0k5T8kbCf4ITahtDzAzw91cYQo8SqqxQr1ztrXIKWeM11nhbIcaaKpAUkGqMbLMFFAK8RDqh2dDhG1dE6L+DknWspC3r5bET9qokVHy/D3O+ocoSuJnVOp6hZKX29y6kn4k0GLBCceNPRgfwKO8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s1IDYMUY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s1IDYMUY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D21CDC116D0; Sat, 28 Feb 2026 17:39:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300352; bh=dB6FPpCoDZ1xiwuejfr7S5mzPXo8oS/VjLqIRF8hHqg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s1IDYMUYnUsIRPtUqceY9m6cN5zPmxaAxVtG44SdC9Ix6egeLabM/rSQauPEIl1Ub hrlR5MXYWx5/LDkYYSP01K0Ms1HRo3BI4FoeKnInJVxsF0ePxS7kU5Gru803qHkfQ1 yzIeoPKUdH+C0JoE34oUGQZBZvAGpiz31Bu2c3nKQJzA2vRGcWVK/HW3ay4hxFOyDu 39DcGV6DHfPRg9iayFby5LoolwufsewOn3KhMJyCWjV80oFkzOh4DtHFATwoinQKyi AzEpE5a+PiI8dLLwIX+LldDz5Hgj8O0wcMIZYDgOByR8DvGQFRjaDZsY2H3s2Kr6m4 LAHRfLx0YZ9tA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sam Day , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 386/844] usb: gadget: f_fs: Fix ioctl error handling Date: Sat, 28 Feb 2026 12:24:59 -0500 Message-ID: <20260228173244.1509663-387-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sam Day [ Upstream commit 8e4c1d06183c25022f6b0002a5cab84979ca6337 ] When ffs_epfile_ioctl handles FUNCTIONFS_DMABUF_* ioctls, it's currently falling through when copy_from_user fails. However, this fallthrough isn't being checked properly, so the handler continues executing further than it should. It then tries the secondary dispatch where it ultimately gives up and returns -ENOTTY. The end result is invalid ioctl invocations will yield a -ENOTTY rather than an -EFAULT. It's a common pattern elsewhere in the kernel code to directly return -EFAULT when copy_from_user fails. So we update ffs_epfile_ioctl to do the same and fix this issue. Signed-off-by: Sam Day Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-1-e51633891= a81@samcday.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/usb/gadget/function/f_fs.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/functi= on/f_fs.c index 928f51fddc64e..e75d5d8b5ac91 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -1744,10 +1744,8 @@ static long ffs_epfile_ioctl(struct file *file, unsi= gned code, { int fd; =20 - if (copy_from_user(&fd, (void __user *)value, sizeof(fd))) { - ret =3D -EFAULT; - break; - } + if (copy_from_user(&fd, (void __user *)value, sizeof(fd))) + return -EFAULT; =20 return ffs_dmabuf_attach(file, fd); } @@ -1755,10 +1753,8 @@ static long ffs_epfile_ioctl(struct file *file, unsi= gned code, { int fd; =20 - if (copy_from_user(&fd, (void __user *)value, sizeof(fd))) { - ret =3D -EFAULT; - break; - } + if (copy_from_user(&fd, (void __user *)value, sizeof(fd))) + return -EFAULT; =20 return ffs_dmabuf_detach(file, fd); } @@ -1766,10 +1762,8 @@ static long ffs_epfile_ioctl(struct file *file, unsi= gned code, { struct usb_ffs_dmabuf_transfer_req req; =20 - if (copy_from_user(&req, (void __user *)value, sizeof(req))) { - ret =3D -EFAULT; - break; - } + if (copy_from_user(&req, (void __user *)value, sizeof(req))) + return -EFAULT; =20 return ffs_dmabuf_transfer(file, &req); } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BAEBA3BE2E0; Sat, 28 Feb 2026 17:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300353; cv=none; b=F99WRpIntTRZjTparsknEpGgNoy65vTzBFhJW3ApxZktGP6RsxWXnIFws6y4dOoEdeSaWN88CV0ifk/sIDO1zRV1fwdJdHD8t/sU4vlVjhlSv/Q/sB1J6XGXJX0wLNBvq1EjZKbaCX+co0iOn9QEG1aCyc7uYp01BsquEv0efXs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300353; c=relaxed/simple; bh=uB02P82FG2llshEYJ+80qIcj8UQiobQ13+TnUgGKNNE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KYwPp9F/pEN2Kg64//j+VIsWuZ9x+0kizfMDzOX4uiSBnMSUSgeLR8vN5y50kibcnlYO1K6lOYOW6D0d6CxGdoMo//mYDMsg4UF9Sl3Qgm+Tx0vUJ4pvlGNefgyhLA6MgZBFYyEEprboxUE7UEngSpqCoNPXs3z4Ksrq/u37Uss= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oPjJfcjv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oPjJfcjv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABB12C19423; Sat, 28 Feb 2026 17:39:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300353; bh=uB02P82FG2llshEYJ+80qIcj8UQiobQ13+TnUgGKNNE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oPjJfcjvmCfRWS8MPuZOdnJ3hjjf2clFJ4Yjd2GOqXf71B2WwXoOg2KRYsZiTtjy8 NEXJSMX7YUMIo7Tm2QreG9WmWJ5GI7/a71YZck+UC0MMGIA6Fpm6N/qH8lESgFyxNS cyg1Qn8nWt5hfr85PbN3oNaIW+946Jw0bjtdk64LOjJMXX7QoyBKHpFMmmybp//AYv qvUowy9g3Ryuow6LbySxNnoEIivuL5+X4tJyHxU1CLGf5zwCRTtoiKx9zvI03rMI64 IkYSXkJ3jOIRCIxhh/87AzwGQfujtDcYnxLAYdcvTWQS1X1LMpKdEgrrF7j6VpRsN0 lSP1hhOoVzieQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mario Peter , Xu Yang , Peter Chen , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 387/844] usb: chipidea: udc: fix DMA and SG cleanup in _ep_nuke() Date: Sat, 28 Feb 2026 12:25:00 -0500 Message-ID: <20260228173244.1509663-388-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mario Peter [ Upstream commit cea2a1257a3b5ea3e769a445b34af13e6aa5a123 ] The ChipIdea UDC driver can encounter "not page aligned sg buffer" errors when a USB device is reconnected after being disconnected during an active transfer. This occurs because _ep_nuke() returns requests to the gadget layer without properly unmapping DMA buffers or cleaning up scatter-gather bounce buffers. Root cause: When a disconnect happens during a multi-segment DMA transfer, the request's num_mapped_sgs field and sgt.sgl pointer remain set with stale values. The request is returned to the gadget driver with status -ESHUTDOWN but still has active DMA state. If the gadget driver reuses this request on reconnect without reinitializing it, the stale DMA state causes _hardware_enqueue() to skip DMA mapping (seeing non-zero num_mapped_sgs) and attempt to use freed/invalid DMA addresses, leading to alignment errors and potential memory corruption. The normal completion path via _hardware_dequeue() properly calls usb_gadget_unmap_request_by_dev() and sglist_do_debounce() before returning the request. The _ep_nuke() path must do the same cleanup to ensure requests are returned in a clean, reusable state. Fix: Add DMA unmapping and bounce buffer cleanup to _ep_nuke() to mirror the cleanup sequence in _hardware_dequeue(): - Call usb_gadget_unmap_request_by_dev() if num_mapped_sgs is set - Call sglist_do_debounce() with copy=3Dfalse if bounce buffer exists This ensures that when requests are returned due to endpoint shutdown, they don't retain stale DMA mappings. The 'false' parameter to sglist_do_debounce() prevents copying data back (appropriate for shutdown path where transfer was aborted). Signed-off-by: Mario Peter Reviewed-by: Xu Yang Acked-by: Peter Chen Link: https://patch.msgid.link/20260108165902.795354-1-mario.peter@leica-ge= osystems.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/usb/chipidea/udc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 64a421ae0f05b..c8d931d9d4330 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -931,6 +931,13 @@ __acquires(hwep->lock) list_del_init(&hwreq->queue); hwreq->req.status =3D -ESHUTDOWN; =20 + /* Unmap DMA and clean up bounce buffers before giving back */ + usb_gadget_unmap_request_by_dev(hwep->ci->dev->parent, + &hwreq->req, hwep->dir); + + if (hwreq->sgt.sgl) + sglist_do_debounce(hwreq, false); + if (hwreq->req.complete !=3D NULL) { spin_unlock(hwep->lock); usb_gadget_giveback_request(&hwep->ep, &hwreq->req); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B9753BF4D1; Sat, 28 Feb 2026 17:39:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300354; cv=none; b=uVlzhzGxSoYzuX4hHF54EcEaZumntb71URk1ZiLmh7UrBs/yQqcAZc/wQyTqdoQ11tk1gIrOGe1W7PTaZ4/+xDrePEYjcNTKEloQxAjXkWVWdJedU1GADq734PVwd3XHmFL2dlYW/FpQAm67ehP4nLeEoqf6/md07L7QjHhMJyY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300354; c=relaxed/simple; bh=8LXErPPlZk5EBBHZQDaSNda4uB89A0brGA4+ZkFQRVg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DEMapXxTyvMeXrXsemssEsggoTqgvcVsmZ9VCIrwpwyS1TacpY3OEF0bM/B3fxUjNDHhonSsoFWqYT6NBVr5sNMR4eIw4BVwibreH8/jDUXeIiTAK11u8wG94VyStq+X+LyQQWg8x1r1lbtZKXmpVbnff+SIFMqvmm4tyOiJtx4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mMXMp3b8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mMXMp3b8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF3BCC19424; Sat, 28 Feb 2026 17:39:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300354; bh=8LXErPPlZk5EBBHZQDaSNda4uB89A0brGA4+ZkFQRVg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mMXMp3b8N0YSHaFzRHX3YYPk+JM/YLHYB3gNtEMQTCH8f0QwWDLKJR+6zN+ix9L0I /DiJl1r+rGev6lAZXi7lMDYhxtjeN/p+Nagisqm76sfGKM9KHQLEfpj1LXF4ihgpMv rQ6cBvCbZNZmfWmo70j0u76g7SMmxIVtOgRL3GoyKrmpcvSNMLj9d/PMX5yJDm6r+g UVSArZI2y9bhfCpgGusrGX7ZQ6SU75MGqHwrZgSaW3gFh5NECGb8M6jynnbTl0/yYc YJmKEveP8qlzHksSrE12jeUfVcyovpHupchooRcQURiGBkZN4IjQzuebE73i2E281Q 8mO1hIOjCK5RA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Diksha Kumari , Mukesh Kumar Chaurasiya , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 388/844] staging: rtl8723bs: fix memory leak on failure path Date: Sat, 28 Feb 2026 12:25:01 -0500 Message-ID: <20260228173244.1509663-389-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Diksha Kumari [ Upstream commit abe850d82c8cb72d28700673678724e779b1826e ] cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths. Signed-off-by: Diksha Kumari Reviewed-by: Mukesh Kumar Chaurasiya Link: https://patch.msgid.link/20260113091712.7071-1-dikshakdevgan@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/st= aging/rtl8723bs/os_dep/ioctl_cfg80211.c index 60edeae1cffe7..476ab055e53e5 100644 --- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c @@ -315,9 +315,10 @@ struct cfg80211_bss *rtw_cfg80211_inform_bss(struct ad= apter *padapter, struct wl len, notify_signal, GFP_ATOMIC); =20 if (unlikely(!bss)) - goto exit; + goto free_buf; =20 cfg80211_put_bss(wiphy, bss); +free_buf: kfree(buf); =20 exit: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C95F3BF4EA; Sat, 28 Feb 2026 17:39:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300355; cv=none; b=KjrTnNIZHY3cGdYmyZL/1PXn3Y/yO8dLYXCA914oK9AK5+W0hNXbTeBnydVI2m4sjV7a2E2bdXHXHbeyfuubsRcJOsixLXJGGFqQK8akee1novJeA3gyA2h0cCiz+Ozfty2jkEXa2jb2Z7f+/lp//PUE39QphpZ4NnQ0MXsFV3M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300355; c=relaxed/simple; bh=i8/3pj5C23rWp+g8HgYnKimhcpObrbmR5Xq/logB+3o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=j8CRRkF3wNr79+TrvMw8IxuauAAhBwVUs6O3qBW6+WMxIM7IEv/3fDTRikaS52qhRFwb8eH2dVuk7onSMuAn58w07U63rawI/ycvOZwoNlqaDuD6GW592GzFRKlp5SrQv29HFAUQ/scQkaDz7tGKrYUipGsj4LyH6goCug5nbBQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hOas6iMT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hOas6iMT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2F67C116D0; Sat, 28 Feb 2026 17:39:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300355; bh=i8/3pj5C23rWp+g8HgYnKimhcpObrbmR5Xq/logB+3o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hOas6iMTZCSDZfvtFJ0Fj7OOoV8GS5MVQUSFLOXZzBDHa4XDH1njKFGDF8g/o5tMG cd7o4gPlbg/tdKPs4+zMzw+ufxLao8WZjR+OOe6qUnscZ9Vcjep4loJKwdvq63XKJH yFOxkMKrO1htIkrG1/cLTrtHhWk7xqBUr+s3bNkMaAlgRnMKJeOk6UEOAhzZnT6Sgu usYYOC0wWWLuYbQHxFkbt9Ltiv06/qbRoyynZKnpLz21k+cm3ovnExSJb0puW9NivC EoH5Ppx105fr4aEDZwAPa7GpSpdlZZUiGIDcSMVV2r1bdKC/aSw9VpOLz27NWOS0DL C0oMipT61ecRQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Moteen Shah , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 389/844] serial: 8250: 8250_omap.c: Add support for handling UART error conditions Date: Sat, 28 Feb 2026 12:25:02 -0500 Message-ID: <20260228173244.1509663-390-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Moteen Shah [ Upstream commit 623b07b370e9963122d167e04fdc1dc713ebfbaf ] The DMA IRQ handler does not accounts for the overrun(OE) or any other errors being reported by the IP before triggering a DMA transaction which leads to the interrupts not being handled resulting into an IRQ storm. The way to handle OE is to: 1. Reset the RX FIFO. 2. Read the UART_RESUME register, which clears the internal flag Earlier, the driver issued DMA transations even in case of OE which shouldn= 't be done according to the OE handling mechanism mentioned above, as we are resetting the FIFO's, refer section: "12.1.6.4.8.1.3.6 Overrun During Receive" [0]. [0] https://www.ti.com/lit/pdf/spruiu1 Signed-off-by: Moteen Shah Link: https://patch.msgid.link/20260112081829.63049-2-m-shah@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/tty/serial/8250/8250_omap.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/= 8250_omap.c index 9e49ef48b851b..e26bae0a6488f 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -100,6 +100,9 @@ #define OMAP_UART_REV_52 0x0502 #define OMAP_UART_REV_63 0x0603 =20 +/* Resume register */ +#define UART_OMAP_RESUME 0x0B + /* Interrupt Enable Register 2 */ #define UART_OMAP_IER2 0x1B #define UART_OMAP_IER2_RHR_IT_DIS BIT(2) @@ -119,7 +122,6 @@ /* Timeout low and High */ #define UART_OMAP_TO_L 0x26 #define UART_OMAP_TO_H 0x27 - struct omap8250_priv { void __iomem *membase; int line; @@ -1256,6 +1258,20 @@ static u16 omap_8250_handle_rx_dma(struct uart_8250_= port *up, u8 iir, u16 status return status; } =20 +static void am654_8250_handle_uart_errors(struct uart_8250_port *up, u8 ii= r, u16 status) +{ + if (status & UART_LSR_OE) { + serial8250_clear_and_reinit_fifos(up); + serial_in(up, UART_LSR); + serial_in(up, UART_OMAP_RESUME); + } else { + if (status & (UART_LSR_FE | UART_LSR_PE | UART_LSR_BI)) + serial_in(up, UART_RX); + if (iir & UART_IIR_XOFF) + serial_in(up, UART_IIR); + } +} + static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir, u16 status) { @@ -1266,7 +1282,8 @@ static void am654_8250_handle_rx_dma(struct uart_8250= _port *up, u8 iir, * Queue a new transfer if FIFO has data. */ if ((status & (UART_LSR_DR | UART_LSR_BI)) && - (up->ier & UART_IER_RDI)) { + (up->ier & UART_IER_RDI) && !(status & UART_LSR_OE)) { + am654_8250_handle_uart_errors(up, iir, status); omap_8250_rx_dma(up); serial_out(up, UART_OMAP_EFR2, UART_OMAP_EFR2_TIMEOUT_BEHAVE); } else if ((iir & 0x3f) =3D=3D UART_IIR_RX_TIMEOUT) { @@ -1282,6 +1299,8 @@ static void am654_8250_handle_rx_dma(struct uart_8250= _port *up, u8 iir, serial_out(up, UART_OMAP_EFR2, 0x0); up->ier |=3D UART_IER_RLSI | UART_IER_RDI; serial_out(up, UART_IER, up->ier); + } else { + am654_8250_handle_uart_errors(up, iir, status); } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3975B3BED2A; Sat, 28 Feb 2026 17:39:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300356; cv=none; b=i/wNPFIw4/gk4ePfixeQ6Z3GuNke44ON5XDU/XSFb94IDYMbykuwxzltrlvpjRMcJyE0xt3aStmanNBrEahxANP8p2oDVSyx4tpHgIq/tzyCKzd3llySMz5LYEQJr2UxuYqKjjjV1Y12OZsk1Sg8+l4ZbPPTDPkHlIBttOAR1nE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300356; c=relaxed/simple; bh=cMDqkK33dyeBBPrf5Ta6K24p+p4t+4mm1cDDdK4KIqc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rsSR3jFCaLQrxitpKKuuDX39abW48vrKw6dp+JKveTu5sUyqBLzF6uUz3hYz+k6GKaVwEYj4+eNeKiZgsEtgG0VLeJSmqKq8EuKA9Je0LA8vsS78CWNcr8MYoiMMuIE3husLmLxPNMYO5F9FANq4xGgPkDltERlqRjSxDtB4H7A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HHQdV5mE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HHQdV5mE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8056BC19424; Sat, 28 Feb 2026 17:39:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300356; bh=cMDqkK33dyeBBPrf5Ta6K24p+p4t+4mm1cDDdK4KIqc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HHQdV5mEzf2jYKzD2lnV0cGhB5YVc64ApO3DLMKN0Ej1BjAjpb8pRJl+HLkihiCdS tInKi972pdpGRmhvG32UW+tXxxv9cvtSVFL12UDe68uTpjwucAlccQ15ina9dCoQ1j XW8+B3ltj3ZFgnaH58BpOmrG71hwPH5yFruNA7C/l0g1puafcoCZPSu/wT1SFkMf+L V/j/T5e6232zAwHdaszHjK1P+5HsUmVpFJJsnmXUpk0MtgAfMsPz+1yGTjOAkTTy/Q 3EaExUysZQpEYlFTzOD4idlULmXtonXfEeQ6kQgQ6upXhsefFOyJVfhBq4s9XQ3/HI 3XFPq81lOodTw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Moteen Shah , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 390/844] serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done Date: Sat, 28 Feb 2026 12:25:03 -0500 Message-ID: <20260228173244.1509663-391-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Moteen Shah [ Upstream commit a5fd8945a478ff9be14812693891d7c9b4185a50 ] Clear rx_running flag only after DMA teardown polling completes. In the previous implementation the flag was being cleared while hardware teardown was still in progress, creating a mismatch between software state (flag =3D 0, "ready") and hardware state (still terminating). Signed-off-by: Moteen Shah Link: https://patch.msgid.link/20260112081829.63049-3-m-shah@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/tty/serial/8250/8250_omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/= 8250_omap.c index e26bae0a6488f..272bc07c9a6b5 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -931,7 +931,6 @@ static void __dma_rx_do_complete(struct uart_8250_port = *p) goto out; =20 cookie =3D dma->rx_cookie; - dma->rx_running =3D 0; =20 /* Re-enable RX FIFO interrupt now that transfer is complete */ if (priv->habit & UART_HAS_RHR_IT_DIS) { @@ -965,6 +964,7 @@ static void __dma_rx_do_complete(struct uart_8250_port = *p) goto out; ret =3D tty_insert_flip_string(tty_port, dma->rx_buf, count); =20 + dma->rx_running =3D 0; p->port.icount.rx +=3D ret; p->port.icount.buf_overrun +=3D count - ret; out: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 272953BFD96; Sat, 28 Feb 2026 17:39:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300357; cv=none; b=FgHHaKnhpxUoeRZtYejE8u19Xu/vQ5gZMR5QmYiYycICTvgyHTfMMQTzNoosBpVl9IhA/0Ay9zdl8r0VGncnym7kaMn+IswFvHCZ3r3FPRR+qnOmQu10cHMc9cQvkNz3kdm+0jrSqBozGtXSQp2wIEnDqgwk0NxzeP5jTGpUQMs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300357; c=relaxed/simple; bh=VVnje+7+SfWBlrdLKBwQdRyCvKyAE8CdhiGHg4l/OXY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KHKgTh8qzIA7FmtAinikmwUeXcKbdU0QxzU4S9wSCLSgtIGpHJ9ryFhFkJTZEqIyltVvrKFpvr028sc3SyvGn0F7B2DrpJ9p/4A7pNhGHGn9F5LszLadeuv1jtSEHSHeYqNZO1f+dxG+YjUNVkPeKjncSm+p8XlRiSaAPgKLQn4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=io5+URdy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="io5+URdy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F0DCC116D0; Sat, 28 Feb 2026 17:39:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300357; bh=VVnje+7+SfWBlrdLKBwQdRyCvKyAE8CdhiGHg4l/OXY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=io5+URdyfmLVOXqIL8VcWX5gPPBQh3u6YDc3vGCwYytXUM4Jyew+yqJEY8EDOn7AX hK3De0h8pyIEzqz9wWPyd9pt98aJ/1SVb4TT5HdU2+Nlf4VoxzCzb6QRXNGUsJSWKX PjvG1abwNq0gz5t52kSDpLw9NRrAFME1jo1NYYYAs7z8COBCsdViGoz7FSahUdr4KA 9fpOEI2kMhkl4AsV/6PioEfBB2VxCSCBQzJxjQU2kni1QAL/YXSqTvSXJK/uqIMXVw wgiTn755xrcLGc04yIpvZQB+UevZ3CJ248Nks4vqwHdobvyR6pUQYImGD+A/MdWPuK WXekBqUBP0l2Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ren=C3=A9=20Rebe?= , Guenter Roeck , Wim Van Sebroeck , Sasha Levin Subject: [PATCH 6.19 391/844] fix it87_wdt early reboot by reporting running timer Date: Sat, 28 Feb 2026 12:25:04 -0500 Message-ID: <20260228173244.1509663-392-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ren=C3=A9 Rebe [ Upstream commit 88b2ab346436f799b99894a3e9518a3ffa344524 ] Some products, such as the Ugreen DXP4800 Plus NAS, ship with the it87 wdt enabled by the firmware and a broken BIOS option that does not allow to change the time or turn it off. As this makes installing Linux rather difficult, change the it87_wdt to report it running to the watchdog core. Signed-off-by: Ren=C3=A9 Rebe Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/watchdog/it87_wdt.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c index 3b8488c86a2f3..1d9f8591f38d8 100644 --- a/drivers/watchdog/it87_wdt.c +++ b/drivers/watchdog/it87_wdt.c @@ -188,6 +188,12 @@ static void _wdt_update_timeout(unsigned int t) superio_outb(t >> 8, WDTVALMSB); } =20 +/* Internal function, should be called after superio_select(GPIO) */ +static bool _wdt_running(void) +{ + return superio_inb(WDTVALLSB) || (max_units > 255 && superio_inb(WDTVALMS= B)); +} + static int wdt_update_timeout(unsigned int t) { int ret; @@ -374,6 +380,12 @@ static int __init it87_wdt_init(void) } } =20 + /* wdt already left running by firmware? */ + if (_wdt_running()) { + pr_info("Left running by firmware.\n"); + set_bit(WDOG_HW_RUNNING, &wdt_dev.status); + } + superio_exit(); =20 if (timeout < 1 || timeout > max_units * 60) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E2BC3BFDBB; Sat, 28 Feb 2026 17:39:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300358; cv=none; b=Zte4MO5AvFurFw05Vc7lF6d2ujXFF9qhnw+XaEZ5jrjbk9mcfMQO/WV/ervBo1MlZFS2MuI6wZNNpO3vpYX9kbeEiV31/TMckca07vW7pczVjw6X5Y04Y6uGe7sVVvf3ViogFcgB/Xml96B/m8vCAaecwu5Mz8q9G9xWkx44peI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300358; c=relaxed/simple; bh=yBO+1gdi5CQ4aTFRj9PBxz+kigfQ1PcO4Qqr4ognvF8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fwHFbD9kEnNXM31sm401+kywY79bRAFXQ3NxKtwUZQJ7YLir0WKQZWZ5lS1PoIdXqhcBfKlPWvfWrUaPjH4lIMRmaE3oXP/aARmWs98OAxjTGG0JWA4VKLmlPAu36CGE4cTA3rZzYFyrx68BK+TmBocd/EiUUdxoWCNgdjpOQjY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SPellaVt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SPellaVt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DED1C19424; Sat, 28 Feb 2026 17:39:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300358; bh=yBO+1gdi5CQ4aTFRj9PBxz+kigfQ1PcO4Qqr4ognvF8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SPellaVtipo35qUywzs0Ejci7dFJlgih0nvkih/aj6HIqUuysJ+bNhf+kQ5k+eomR kNx8Vpg6rya6McK0TKuJYycRjY/rDNinbXpbseBGoegkZMXecOnZpGJsdgZyJmIMnl ZNL6GLteUKH1QFzcX48kaW4s+Eu2OKdw17SmjH3J8mhJqAPeuUYnYq754qd9EsOsOT z080utaUN8+tMRkHjrtHIEGqddgfbm03ijdY7XmfeCECLR2UpTtBwrF02Ysjbcivpz b2Zg5zDvgLVASN8H2dTSgZGixNRy4P9vrxJXQOj9AbjOHaJYHJ7a2oWorZJChst7Nr puTZ5kFHEiiTw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , Carlos Llamas , Alice Ryhl , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 392/844] binder: don't use %pK through printk Date: Sat, 28 Feb 2026 12:25:05 -0500 Message-ID: <20260228173244.1509663-393-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Thomas Wei=C3=9Fschuh [ Upstream commit 56d21267663bad91e8b10121224ec46366a7937e ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Wei=C3=9Fschuh Acked-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260107-restricted-pointers-binder-v1-1-181= 018bf3812@linutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/android/binder.c | 2 +- drivers/android/binder_alloc.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index b356c9b882544..33e4dad0915bb 100644 --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -4523,7 +4523,7 @@ static int binder_thread_write(struct binder_proc *pr= oc, } } binder_debug(BINDER_DEBUG_DEAD_BINDER, - "%d:%d BC_DEAD_BINDER_DONE %016llx found %pK\n", + "%d:%d BC_DEAD_BINDER_DONE %016llx found %p\n", proc->pid, thread->pid, (u64)cookie, death); if (death =3D=3D NULL) { diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c index 979c96b74cad3..d5ed64543bbf4 100644 --- a/drivers/android/binder_alloc.c +++ b/drivers/android/binder_alloc.c @@ -81,7 +81,7 @@ static void binder_insert_free_buffer(struct binder_alloc= *alloc, new_buffer_size =3D binder_alloc_buffer_size(alloc, new_buffer); =20 binder_alloc_debug(BINDER_DEBUG_BUFFER_ALLOC, - "%d: add free buffer, size %zd, at %pK\n", + "%d: add free buffer, size %zd, at %p\n", alloc->pid, new_buffer_size, new_buffer); =20 while (*p) { @@ -572,7 +572,7 @@ static struct binder_buffer *binder_alloc_new_buf_locke= d( } =20 binder_alloc_debug(BINDER_DEBUG_BUFFER_ALLOC, - "%d: binder_alloc_buf size %zd got buffer %pK size %zd\n", + "%d: binder_alloc_buf size %zd got buffer %p size %zd\n", alloc->pid, size, buffer, buffer_size); =20 /* @@ -748,7 +748,7 @@ static void binder_free_buf_locked(struct binder_alloc = *alloc, ALIGN(buffer->extra_buffers_size, sizeof(void *)); =20 binder_alloc_debug(BINDER_DEBUG_BUFFER_ALLOC, - "%d: binder_free_buf %pK size %zd buffer_size %zd\n", + "%d: binder_free_buf %p size %zd buffer_size %zd\n", alloc->pid, buffer, size, buffer_size); =20 BUG_ON(buffer->free); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B7743C0BE9; Sat, 28 Feb 2026 17:39:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300359; cv=none; b=X49nlmruhClDR0A3oIOW75raYqLB6IEk5yeNSH57Mq4kIGZ25XA8+YO0M3rQtBYZD2g6SFrd4sW8uM9rSBFi1vuTrXbxBSJsfOtI79p2AyeT50lM4hKgC+XQzgdxwJ4IT3Lx3jTJabP3nDo4JiO7y4cvi7Sz8ZdGyYREFU/3c6I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300359; c=relaxed/simple; bh=neWF+2LZdaQ2MOhn1PQjNr004MV0PkZmv2RD8jGWMRM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sWHnmT8CcEr/zGyhZADoi/RaBA/KUKnbiaACoZPFF6008/6BUm6k/UOgCHFnei4KVBsLFeqfx6/4BaDqsrJ8Ck4UFMWLRlO8M/qWDdvJULaj0r3tEtngWYkZtACJYnEPW49qV+Lq8W2sBRTb1o2XOIIEeExIL9ewcnThhB2wt2Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E/tmur1h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E/tmur1h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53FD3C116D0; Sat, 28 Feb 2026 17:39:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300359; bh=neWF+2LZdaQ2MOhn1PQjNr004MV0PkZmv2RD8jGWMRM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E/tmur1hx6t4as5zsgOxUCKsihY2rQoo7uq8kYjA96hseB5+8gqSh8lrdfkW/cxHF eq6X5x74AL7xaGjSYOlWXcf0vKKxZXpu4KaMRTJS/cBejrLHEfRJg3j5e6SJDcaV2e fZHFNUKSlIttsfHZsUKqoAA3eFdX/0M+/gl/W0QgC9sSX/BGX/nzKawRtkPlIISMlI 8oHVIBcH92Ze8Sy6aQZje3KzrZOKrqfjiUYkW4arLKIeOT0r8xs6r8IGoLO8Lcofwi Cs6SKpyDYhKXwTQv5AHksxXnZYv0jbMkOiyIzYbBhJp64OSEPQTFJ1+4RIw8ioo0il miNs4WhFcURTA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Oleksandr Suvorov , Guenter Roeck , Frank Li , Wim Van Sebroeck , Sasha Levin Subject: [PATCH 6.19 393/844] watchdog: imx7ulp_wdt: handle the nowayout option Date: Sat, 28 Feb 2026 12:25:06 -0500 Message-ID: <20260228173244.1509663-394-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Oleksandr Suvorov [ Upstream commit d303d37ef5cf86c8c3b2daefd2a7d7fd8ca1ec14 ] The module parameter `nowayout` indicates whether the watchdog should ever be allowed to stop, but the driver currently ignores this option. Pass the `nowayout` parameter to the watchdog core by setting the WDOG_NO_WAY_OUT flag accordingly. Signed-off-by: Oleksandr Suvorov Reviewed-by: Guenter Roeck Reviewed-by: Frank Li Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/watchdog/imx7ulp_wdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/imx7ulp_wdt.c b/drivers/watchdog/imx7ulp_wdt.c index 0f13a30533574..03479110453ce 100644 --- a/drivers/watchdog/imx7ulp_wdt.c +++ b/drivers/watchdog/imx7ulp_wdt.c @@ -346,6 +346,7 @@ static int imx7ulp_wdt_probe(struct platform_device *pd= ev) watchdog_stop_on_reboot(wdog); watchdog_stop_on_unregister(wdog); watchdog_set_drvdata(wdog, imx7ulp_wdt); + watchdog_set_nowayout(wdog, nowayout); =20 imx7ulp_wdt->hw =3D of_device_get_match_data(dev); ret =3D imx7ulp_wdt_init(imx7ulp_wdt, wdog->timeout * imx7ulp_wdt->hw->wd= og_clock_rate); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 286AC3C0BFF; Sat, 28 Feb 2026 17:39:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300360; cv=none; b=L0Q3Z2urENMoJRPnCVJOlBKTsm1JGgWDZ+pciQHoTE/at17+p1DbomZ3pifZ4hCa37hESMToCBN8+wweYqURkHIZGjfarEnMdEFMIKeiq9DwBX36nrGU2pZIv8hJQOyBAgJlvfhtANzdaWi38VIxR+uimi8nIk0aCt26z8YvOsk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300360; c=relaxed/simple; bh=FTwb94O2+0BWU/8PxjRoKtacny9TIv5c8a1PPMB4qto=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K32CX5q3yEOgqJONElNSGX5wyELjqomN7wiyR6pUJoX2c2JxnkW/ZWok/QAa6Slh9+KeHrTyhCjFpP4Kk/U/VWsLRewPmTM2Z1bOAWQxnrXlttZV2QXVc8XwnnlZ+9CiEqAHh//ceFXomrIaychdosS8O9A3KIrXzipgyryZlUI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N1vNGUpc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N1vNGUpc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F066C19424; Sat, 28 Feb 2026 17:39:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300360; bh=FTwb94O2+0BWU/8PxjRoKtacny9TIv5c8a1PPMB4qto=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N1vNGUpcSJW6+xh/3R/bPE9wer+EqlmykeiUy1dgk4yJvMlhDUOgIyqa0s2xLKyC3 BR3w0N7s61OF0dUSeoq+Ly0BgIg5sbigcVCRFO5sc6PjjFrX+nw09N5V34Gr6ejH68 5BqAGy/OyY5bzaaqMIIP+y3ypF2KJWpVccRlZ+P4vASAw4DE9h3gynV1vXCCgCQua1 QA9NpP27ygyIGpExKD+jwZVgSbJS8DfKnEbO3pAY30GCdYFkF5HCLr9Qkzo+kVAnMC uJHNxAlfgnOL0xM3FBWbRyB+LyyUARk5otIo60G9a/jvAGN2Jdj6xXwX8VBROVGPjb qa1tf/AI6HPSw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Rafael J. Wysocki" , Guenter Roeck , Wim Van Sebroeck , Sasha Levin Subject: [PATCH 6.19 394/844] watchdog: rzv2h_wdt: Discard pm_runtime_put() return value Date: Sat, 28 Feb 2026 12:25:07 -0500 Message-ID: <20260228173244.1509663-395-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Rafael J. Wysocki" [ Upstream commit 2dea984a74265a67e3210f818416a83b87f70200 ] Failing device probe due to pm_runtime_put() returning an error is not particularly useful. Returning an error code from pm_runtime_put() merely means that it has not queued up a work item to check whether or not the device can be suspended and there are many perfectly valid situations in which that can happen, like after writing "on" to the devices' runtime PM "control" attribute in sysfs for one example. It also happens when the kernel is configured with CONFIG_PM unset. Accordingly, update rzt2h_wdt_wdtdcr_init() to simply discard the return value of pm_runtime_put() and return success to the caller after invoking that function. This will facilitate a planned change of the pm_runtime_put() return type to void in the future. Signed-off-by: Rafael J. Wysocki Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/watchdog/rzv2h_wdt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/watchdog/rzv2h_wdt.c b/drivers/watchdog/rzv2h_wdt.c index a694786837e11..f9bb4ef3d327b 100644 --- a/drivers/watchdog/rzv2h_wdt.c +++ b/drivers/watchdog/rzv2h_wdt.c @@ -270,9 +270,7 @@ static int rzt2h_wdt_wdtdcr_init(struct platform_device= *pdev, =20 rzt2h_wdt_wdtdcr_count_stop(priv); =20 - ret =3D pm_runtime_put(&pdev->dev); - if (ret < 0) - return ret; + pm_runtime_put(&pdev->dev); =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07D273C0C1A; Sat, 28 Feb 2026 17:39:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300361; cv=none; b=EeY5/n7W1BuPc2PiMmzerx12jJeiTF8pkvwTYFSAGFM+iQOb6TFv31/yur4zx7jyiGAGMUEU/GLam2+hZafhw/oSF5rc19tLttPrQg63sM76rg5cq/TJ+dUbfeQvK8V7BJcA2THhziglgVji5xZqOLifwn+x5xyxqqmZ1rq+WrY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300361; c=relaxed/simple; bh=gruoONGr1LBGtKcr1XKUcE1mXzaxkW8h7qwHuPBVHY4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DQgosii8Cp95Mo7ENf2PvbjQ1xk1eMPFe0pndJxc5z0RK0AZQHO6+4XmnXLodGdeB7TpUdngxUwke9/nGmCDOzcqQ4BrO3+FKtPojiQGEfULJ3OCqT2BT2wgLv8e+CS/1Qd6+jgZQ9gWqhFol8Fc3aVhYUKdobm8W38yu4h6YIA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gugd4w2O; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gugd4w2O" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FF3CC19424; Sat, 28 Feb 2026 17:39:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300360; bh=gruoONGr1LBGtKcr1XKUcE1mXzaxkW8h7qwHuPBVHY4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gugd4w2OwT+c4NMZDLD9/vnvH1Wai/jyVYEDO6HOzRVbSYg0ritXVCu1biUWtkpkE kpkwEJU5uUEQGHgV3BY058xnDLCCft9iGV9DcCUoAUPxn8SXSIXm79Ql8FLMNj5WIX t+CO0UVNJggxNx15WKSlomfdDgEuc9XVcnmlkapnAJBf0bfMqvJ1UYgV3W6WhwLywJ w1j9+LNzYwmhbHSOquBO9way5sO0icflrXcQjZA3cUuxZuYOwnvy1Z8dsrDJ3C39wB eU8gxf+4Cb+gmNdg66iHhoIITHf9B8KODv72/D/FMrY1HTVKjsVYKAIXxDEeSWnuFd uw4F2PFDdVxqQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Aleksandar Gerasimovski , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 395/844] phy: mvebu-cp110-utmi: fix dr_mode property read from dts Date: Sat, 28 Feb 2026 12:25:08 -0500 Message-ID: <20260228173244.1509663-396-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Aleksandar Gerasimovski [ Upstream commit e2ce913452ab56b3330539cc443b97b7ea8c3a1a ] The problem with the current implementation is that it does not consider that the USB controller can have multiple PHY handles with different arguments count, as for example we have in our cn9131 based platform: "phys =3D <&cp0_comphy1 0>, <&cp0_utmi0>;". In such case calling "of_usb_get_dr_mode_by_phy" with -1 (no phy-cells) leads to not proper phy detection, taking the "marvell,cp110-utmi-phy" dts definition we can call the "of_usb_get_dr_mode_by_phy" with 0 (#phy-cells =3D <0>) and safely look for that phy. Signed-off-by: Aleksandar Gerasimovski Link: https://patch.msgid.link/20260106150643.922110-1-aleksandar.gerasimov= ski@belden.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/phy/marvell/phy-mvebu-cp110-utmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/marvell/phy-mvebu-cp110-utmi.c b/drivers/phy/marve= ll/phy-mvebu-cp110-utmi.c index 59903f86b13f5..dd3e515a8e865 100644 --- a/drivers/phy/marvell/phy-mvebu-cp110-utmi.c +++ b/drivers/phy/marvell/phy-mvebu-cp110-utmi.c @@ -338,7 +338,7 @@ static int mvebu_cp110_utmi_phy_probe(struct platform_d= evice *pdev) return -ENOMEM; } =20 - port->dr_mode =3D of_usb_get_dr_mode_by_phy(child, -1); + port->dr_mode =3D of_usb_get_dr_mode_by_phy(child, 0); if ((port->dr_mode !=3D USB_DR_MODE_HOST) && (port->dr_mode !=3D USB_DR_MODE_PERIPHERAL)) { dev_err(&pdev->dev, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EAE523C152C; Sat, 28 Feb 2026 17:39:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300362; cv=none; b=u/VVV8ZnYx01kFwG6GPpi+AbpZVymt6UGnY1Fr2I2EKiCBbc2xCfqwmLu+vloU0YGzVRTLerZ5Fjtqwv/kK91MQhCKvppLt7p3IifIbHuSpsrEfk8MVhjl0vubQmBeo26uFJ+z8lu6hK7cCZl6UURYIguvSyKpH16e56g7MAcE8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300362; c=relaxed/simple; bh=2HlZxEimLJFMScH+05ZMokGzWzkMwOJYBPTUJDQQWwA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EffWWE6XL92m6whZT/fQ2k+jVsHb2Nr8XHn9doTEC8qoNYRRLEm42GIYHp44taDx6CQDLMl6h3sbMq63jZazTdyjBbpMQRhl/YJID8CwL3Vof2HQ2efLKsoeyLWFk5dtRRVveYNc+AuvbD3sKCbZB6d149Wr8HTdwjExSDrKDRA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U/CJO61a; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U/CJO61a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C5A0C19425; Sat, 28 Feb 2026 17:39:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300361; bh=2HlZxEimLJFMScH+05ZMokGzWzkMwOJYBPTUJDQQWwA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U/CJO61anMXotQ9DlMrEl/0BDlhJsQ+YgGz8nEzsbyasgigpIHc9HquepQ/8Ldtzb WbNk4zk9iyL12yBIv7aI60dSJExN1CdOScKZBxJvzx0kzP6+F//f/W4tIyaySrsWj/ 7Gw1iMRNp2m7TPRc5RZvz77DDN+lyOv6RDSB/1VLVzGWgzFe2u49NJ08R+BFNOCgtD OKrM7ysPmFc9Sk6Ty8jVBIRfP/7fN/vf7Ergw9PKOq/7EGMxpCjwEcUfXiPpH+b6q/ sjMdkLmBGxfCACPGVbQ7yllumaBkvV9BwFbv3nsp9II9DlYxlb3ik8qP0QMIYiU7bf 4Mah+Do0cBzQQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xu Yang , Frank Li , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 396/844] phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature Date: Sat, 28 Feb 2026 12:25:09 -0500 Message-ID: <20260228173244.1509663-397-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xu Yang [ Upstream commit 27ee0869d77b2cb404770ac49bdceae3aedf658b ] Disabling PHYs in runtime usually causes the client with external abort exception or similar issue due to lack of API to notify clients about PHY removal. This patch removes the possibility to unbind i.MX PHY drivers in runtime. Signed-off-by: Xu Yang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260120111712.3159782-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/frees= cale/phy-fsl-imx8mq-usb.c index 91b3e62743d3a..b30d01f345d20 100644 --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c @@ -730,6 +730,7 @@ static struct platform_driver imx8mq_usb_phy_driver =3D= { .driver =3D { .name =3D "imx8mq-usb-phy", .of_match_table =3D imx8mq_usb_phy_of_match, + .suppress_bind_attrs =3D true, } }; module_platform_driver(imx8mq_usb_phy_driver); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2349D3C1525; Sat, 28 Feb 2026 17:39:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300363; cv=none; b=ky+3v4CEBH285zbnwE83I/586LGvKlw77WRrMCqV8aiKgPa8mftBbzroFNRAnKKYjSAZRV+XkGxU8uhWESowamYL5DQr/GmTy4lrh+zLl3W2hgk8Z/fuif+LKKWydjyws3qQPs0+ImHb9FQNKPVIjU335pj/qTJSYgJMv51hoaw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300363; c=relaxed/simple; bh=Z/bdLUj1wqj9sxsuaIVpV0P7vtGpNZAyjM/rPm9AFew=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mVXrnGJ9hk6W0/oR+GTos28LR6IDXWZh20I07KTo9kwkPw1ugvkqfDnfutkwBxGkiCgtP4lNJEAGQaPDWDeucQjqJ17AtaUC9QDzPHdxpqlm4A8VTq8FZZBd5iMigVYYkhvM7VyexusMNwAMH47CWObEqSH54O6zhnC8BQgIiek= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S/qomozQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S/qomozQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C32AC19423; Sat, 28 Feb 2026 17:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300362; bh=Z/bdLUj1wqj9sxsuaIVpV0P7vtGpNZAyjM/rPm9AFew=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S/qomozQxob5xbkQeTDbpko8npmVMNrh6g3MXPS7EhbeJvDzZa+6CWCiYKD1JhPFS snu7jtpJcyvUhlSEUepl5aDnBX0aDH2wKlUaCUW1odIxH38nnUM3iPI8ab/2CnjXzT BHDtKyibIsoPaKK/WDZdT1dNGXwI8JD4Ltdapf1yxZXG/KtSOAOzgU2zBWTxXlEXu7 3t+wO2ltLdN2QOZc+ngi1DzWe+2BEdLp095yLRONUPFXDAACL/F3WNS4X/ZX50FSDl I+POmL3hngrVh1x6f79qS8f0oFPR8N8W50w1dPsgMrxGtIJ1huB4hxbZADI67cp3S2 BDKecY4E6U/mQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Marcus Folkesson , Lee Jones , Sasha Levin Subject: [PATCH 6.19 397/844] Revert "mfd: da9052-spi: Change read-mask to write-mask" Date: Sat, 28 Feb 2026 12:25:10 -0500 Message-ID: <20260228173244.1509663-398-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marcus Folkesson [ Upstream commit 12daa9c1954542bf98bb942fb2dadf19de79a44b ] This reverts commit 2e3378f6c79a1b3f7855ded1ef306ea4406352ed. Almost every register in this chip can be customized via OTP memory. Somehow the value for R19, which decide if the flag is set on read or write operation, seems to have been overwritten for the chip the original patch were written for. Revert the change to follow the default behavior. Signed-off-by: Marcus Folkesson Link: https://patch.msgid.link/20251124-da9052-revert-v1-1-fbeb2c894002@gma= il.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mfd/da9052-spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/da9052-spi.c b/drivers/mfd/da9052-spi.c index 80fc5c0cac2fb..be5f2b34e18ae 100644 --- a/drivers/mfd/da9052-spi.c +++ b/drivers/mfd/da9052-spi.c @@ -37,7 +37,7 @@ static int da9052_spi_probe(struct spi_device *spi) spi_set_drvdata(spi, da9052); =20 config =3D da9052_regmap_config; - config.write_flag_mask =3D 1; + config.read_flag_mask =3D 1; config.reg_bits =3D 7; config.pad_bits =3D 1; config.val_bits =3D 8; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E3F023C0BFF; Sat, 28 Feb 2026 17:39:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300364; cv=none; b=EZflwc5XnxII4PBd/hK82rbsp2/6i/uF0IRZwAJkdOC5be+m1DWBMLklie/kAS1AJeh/PJmhjZ7glvXO7dXlUfG19tIE0gtPktMP7IMVjKJ2DE+1iR8NPbUcOQn563doqWzz93G4Rp19GKvWyVv/i9HEWYNssjlHj/kSwhyt52g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300364; c=relaxed/simple; bh=0UMkOyGjMxIoCr9XoxNfWkc7FQFB4U5HlxQCUve25mU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IsTpY/YN2UzNvQEAQthx0cyXqt54gGS1kSL7X0wymQu8GBOWExhJ3aDSyIEK7pxGLYY1rCpWhgsyX6GjoRDSzBdkxJgTN69mhNqIgFEeI4it3slqYYE861hwn4Tj9Hjc/WsxSeKmqS5essQH7g664u1ZY2wJnoYW0H8oXwFWr7w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qa11s6dt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qa11s6dt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC756C19424; Sat, 28 Feb 2026 17:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300363; bh=0UMkOyGjMxIoCr9XoxNfWkc7FQFB4U5HlxQCUve25mU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qa11s6dtvGNCmaBPmuMNbv76UngHPTvHbhb1kGe77lks81ro/7CjZIR/qMSR+MSLu tSo49fbISz7nVzl/FUyLpePObowUxQrJir+T98wNt6cVsuPolpVlx5xsAQb5zOjp5E J5NeRyV6UP07WaumlqJN8McruvAdxCWZ/LIKxgVXi17WjArtQePxn+8aK4SYnr+5je qbupNMCm+J+4kShunOhNdfg3fTtC9wUHIAj5/YyX4VmALOKCqI+fpB2Q0G+ed/qDLG cBXeqn526JoZFyWH8ai5GxwaHlIR3lGEUi7GMZzzlvpzcKLiyFELZx5USqtQ414f88 Oi8TpPyX9e1UA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Andy Shevchenko , Lee Jones , Sasha Levin Subject: [PATCH 6.19 398/844] mfd: intel-lpss: Add Intel Nova Lake-S PCI IDs Date: Sat, 28 Feb 2026 12:25:11 -0500 Message-ID: <20260228173244.1509663-399-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ilpo J=C3=A4rvinen [ Upstream commit cefd793fa17de708d043adab50e7f96f414b0f1d ] Add Intel Nova Lake-S LPSS PCI IDs. Signed-off-by: Ilpo J=C3=A4rvinen Acked-by: Andy Shevchenko Link: https://patch.msgid.link/20260113172151.48062-1-ilpo.jarvinen@linux.i= ntel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mfd/intel-lpss-pci.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c index 8d92c895d3aef..713a5bfb1a3c2 100644 --- a/drivers/mfd/intel-lpss-pci.c +++ b/drivers/mfd/intel-lpss-pci.c @@ -437,6 +437,19 @@ static const struct pci_device_id intel_lpss_pci_ids[]= =3D { { PCI_VDEVICE(INTEL, 0x5ac4), (kernel_ulong_t)&bxt_spi_info }, { PCI_VDEVICE(INTEL, 0x5ac6), (kernel_ulong_t)&bxt_spi_info }, { PCI_VDEVICE(INTEL, 0x5aee), (kernel_ulong_t)&bxt_uart_info }, + /* NVL-S */ + { PCI_VDEVICE(INTEL, 0x6e28), (kernel_ulong_t)&bxt_uart_info }, + { PCI_VDEVICE(INTEL, 0x6e29), (kernel_ulong_t)&bxt_uart_info }, + { PCI_VDEVICE(INTEL, 0x6e2a), (kernel_ulong_t)&tgl_spi_info }, + { PCI_VDEVICE(INTEL, 0x6e2b), (kernel_ulong_t)&tgl_spi_info }, + { PCI_VDEVICE(INTEL, 0x6e4c), (kernel_ulong_t)&ehl_i2c_info }, + { PCI_VDEVICE(INTEL, 0x6e4d), (kernel_ulong_t)&ehl_i2c_info }, + { PCI_VDEVICE(INTEL, 0x6e4e), (kernel_ulong_t)&ehl_i2c_info }, + { PCI_VDEVICE(INTEL, 0x6e4f), (kernel_ulong_t)&ehl_i2c_info }, + { PCI_VDEVICE(INTEL, 0x6e5c), (kernel_ulong_t)&bxt_uart_info }, + { PCI_VDEVICE(INTEL, 0x6e5e), (kernel_ulong_t)&tgl_spi_info }, + { PCI_VDEVICE(INTEL, 0x6e7a), (kernel_ulong_t)&ehl_i2c_info }, + { PCI_VDEVICE(INTEL, 0x6e7b), (kernel_ulong_t)&ehl_i2c_info }, /* ARL-H */ { PCI_VDEVICE(INTEL, 0x7725), (kernel_ulong_t)&bxt_uart_info }, { PCI_VDEVICE(INTEL, 0x7726), (kernel_ulong_t)&bxt_uart_info }, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABC143C4C2F; Sat, 28 Feb 2026 17:39:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300364; cv=none; b=LKlbzNfsw6ZA7vjlmIS7HuYbB3OEm+kVy3BKWvZFn7pBp4yqEPUdpter4xHERH4WtoJA9NQy6r8GrGtGfR3iZOzN4MF6rQXDV0fbvLATF30q9zqfVOICStaUnHs33J5O4jx4aVnxPsO7ZpNm8SP7QuYaGunVdDSrTax2EyRb/Ng= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300364; c=relaxed/simple; bh=f1c3761UCRyf4cWsV3oJHwqJWcKxzIdOUIZpC3Sf0GI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aHq0qQvTXN46Cn/THKAr8m1+8Qhf4QPiPHAIkexk4VDpvyhNKCpgJcEnCwPpVb20jW6xRquj8vogYiFuG0AMZfi86nC8rSLmwcANs2PpDnxBCRG4dJAcJFE9M+UmOOON46D8+it7MdsVX84DBK0GzeNBzCdfyqErWx26sBxQAaw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wz49rJpY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Wz49rJpY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0CE3C19425; Sat, 28 Feb 2026 17:39:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300364; bh=f1c3761UCRyf4cWsV3oJHwqJWcKxzIdOUIZpC3Sf0GI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Wz49rJpYgJMWxeoR7ZIRnFLfkYBBzAvj7WUWQwbj2B0x1YJ27urqDwUw/eQkl9fHJ b3oFUFVf8RqmpwV61U+QPmmyGCUBpIJLojwug82VJgCZVrlgwbNtKKMboGfF9MpwDD EbIiL+IqkhWu0ABJq16y3I8K8S1FT5juh/qK7LKu3dByRSN0BVZtdpMNEf1YM8wxVk IXgmYHYa/5xLASW4bfPsqFfZWGit0hyz+pQjFWBszA3FEWoiP0QvVZPQSScYbWgC2X mKoHqp/AxnpddAJ5YF2vBByHZjl3Ui/kXkPArn+UDf0WHk/P4TlQquzrcjC9RAVYc7 5Imw7q2D02qyg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sebastian Andrzej Siewior , Andy Shevchenko , Jonathan Cameron , Sasha Levin Subject: [PATCH 6.19 399/844] iio: Use IRQF_NO_THREAD Date: Sat, 28 Feb 2026 12:25:12 -0500 Message-ID: <20260228173244.1509663-400-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sebastian Andrzej Siewior [ Upstream commit 04d390af97f2c28166f7ddfe1a6bda622e3a4766 ] The interrupt handler iio_trigger_generic_data_rdy_poll() will invoke other interrupt handler and this supposed to happen from within the hardirq. Use IRQF_NO_THREAD to forbid forced-threading. Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iio/accel/bma180.c | 5 +++-- drivers/iio/adc/ad7766.c | 2 +- drivers/iio/gyro/itg3200_buffer.c | 8 +++----- drivers/iio/light/si1145.c | 2 +- 4 files changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c index 8925f5279e627..7bc6761f51354 100644 --- a/drivers/iio/accel/bma180.c +++ b/drivers/iio/accel/bma180.c @@ -986,8 +986,9 @@ static int bma180_probe(struct i2c_client *client) } =20 ret =3D devm_request_irq(dev, client->irq, - iio_trigger_generic_data_rdy_poll, IRQF_TRIGGER_RISING, - "bma180_event", data->trig); + iio_trigger_generic_data_rdy_poll, + IRQF_TRIGGER_RISING | IRQF_NO_THREAD, + "bma180_event", data->trig); if (ret) { dev_err(dev, "unable to request IRQ\n"); goto err_trigger_free; diff --git a/drivers/iio/adc/ad7766.c b/drivers/iio/adc/ad7766.c index 4d570383ef025..1e6bfe8765ab3 100644 --- a/drivers/iio/adc/ad7766.c +++ b/drivers/iio/adc/ad7766.c @@ -261,7 +261,7 @@ static int ad7766_probe(struct spi_device *spi) * don't enable the interrupt to avoid extra load on the system */ ret =3D devm_request_irq(&spi->dev, spi->irq, ad7766_irq, - IRQF_TRIGGER_FALLING | IRQF_NO_AUTOEN, + IRQF_TRIGGER_FALLING | IRQF_NO_AUTOEN | IRQF_NO_THREAD, dev_name(&spi->dev), ad7766->trig); if (ret < 0) diff --git a/drivers/iio/gyro/itg3200_buffer.c b/drivers/iio/gyro/itg3200_b= uffer.c index a624400a239cb..cf97adfa97274 100644 --- a/drivers/iio/gyro/itg3200_buffer.c +++ b/drivers/iio/gyro/itg3200_buffer.c @@ -118,11 +118,9 @@ int itg3200_probe_trigger(struct iio_dev *indio_dev) if (!st->trig) return -ENOMEM; =20 - ret =3D request_irq(st->i2c->irq, - &iio_trigger_generic_data_rdy_poll, - IRQF_TRIGGER_RISING, - "itg3200_data_rdy", - st->trig); + ret =3D request_irq(st->i2c->irq, &iio_trigger_generic_data_rdy_poll, + IRQF_TRIGGER_RISING | IRQF_NO_THREAD, + "itg3200_data_rdy", st->trig); if (ret) goto error_free_trig; =20 diff --git a/drivers/iio/light/si1145.c b/drivers/iio/light/si1145.c index f8eb251eca8dc..ef0abc4499b74 100644 --- a/drivers/iio/light/si1145.c +++ b/drivers/iio/light/si1145.c @@ -1248,7 +1248,7 @@ static int si1145_probe_trigger(struct iio_dev *indio= _dev) =20 ret =3D devm_request_irq(&client->dev, client->irq, iio_trigger_generic_data_rdy_poll, - IRQF_TRIGGER_FALLING, + IRQF_TRIGGER_FALLING | IRQF_NO_THREAD, "si1145_irq", trig); if (ret < 0) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8FBB3C4C52; Sat, 28 Feb 2026 17:39:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300365; cv=none; b=tStrP09c7MQLZXVbwpzL4LUvIT5NqUTzOI4kJB/an+qjhNfNxERP1fXyK0MuMFPl/fVj+hliPHGYW0mai1Jv21XaKQbUIESmme4SPoS6F5tvxEz2QcEgSmFCy96JZ1EstjUrREqbIYrwi/h+sRE1OOrWcBtBZfopySm2B8vFsog= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300365; c=relaxed/simple; bh=xTcTq8oodcuv1Ba4/+yqPFIurfKOhpE/WebVsNgyVC0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=V4jztyfw5VfC3+MtiEh0RSHY7lBcmXCMU7qdaLF7MG0zX0fDS45Zyw+xbE05+K8oAdsMvlRnOE6CKf3ZuYdLe1dsFgRvlUOVbyEchTBiMeOOpZABIS6qCaiUD4/Qvj8AXw1VL1eSdNUtg7iEEfGWpfyT8p8jCDZdUXTMHT/IZpI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RhawvEi1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RhawvEi1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5A36C116D0; Sat, 28 Feb 2026 17:39:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300365; bh=xTcTq8oodcuv1Ba4/+yqPFIurfKOhpE/WebVsNgyVC0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RhawvEi17zezplLH5gR4JhHATVMoSmRKgA2hTJkNPWjqJgcCB8TssxBZFjsPKHlLv UxkdUpm/ElxNcZ0fu92ergRtVfhEhQz5oWxN3ed64v9fQBq1SRsmP0ZYCvaygfPeAo jLK6z9ZnoXFBrgHXALYX9bpz5N4viWlgBmXwoxdOg6WxLdgJ3szq01YVcOT0YBObWP 8hJ2GWe58kqYlePEeyjYbqRTtLeNrIq/55V4kFM5+0GPb0GxQD7LGFfy2Hy9EIPvpB y4Y6vtKCRrDf7r1/4P0ETD/Av1KwL9utRqpM/gTxT3DdSgYotmJVdFN32TLSx9TdzC xs2RC0Q8O75Vg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sebastian Andrzej Siewior , Geert Uytterhoeven , Andy Shevchenko , =?UTF-8?q?Nuno=20S=C3=A1?= , Jonathan Cameron , Sasha Levin Subject: [PATCH 6.19 400/844] iio: magnetometer: Remove IRQF_ONESHOT Date: Sat, 28 Feb 2026 12:25:13 -0500 Message-ID: <20260228173244.1509663-401-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Sebastian Andrzej Siewior [ Upstream commit a54e9440925e6617c98669066b4753c4cdcea8a0 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also disallows force-threading of the primary handler and the irq-core will warn about this. The force-threading functionality is required on PREEMPT_RT because the handler is using locks with can sleep on PREEMPT_RT. Remove IRQF_ONESHOT from irqflags. Tested-by: Geert Uytterhoeven Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Andy Shevchenko Reviewed-by: Nuno S=C3=A1 Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iio/magnetometer/ak8975.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/a= k8975.c index 3fd0171e5d69b..d30315ad85ded 100644 --- a/drivers/iio/magnetometer/ak8975.c +++ b/drivers/iio/magnetometer/ak8975.c @@ -581,7 +581,7 @@ static int ak8975_setup_irq(struct ak8975_data *data) irq =3D gpiod_to_irq(data->eoc_gpiod); =20 rc =3D devm_request_irq(&client->dev, irq, ak8975_irq_handler, - IRQF_TRIGGER_RISING | IRQF_ONESHOT, + IRQF_TRIGGER_RISING, dev_name(&client->dev), data); if (rc < 0) { dev_err(&client->dev, "irq %d request failed: %d\n", irq, rc); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCEDD3C4C41; Sat, 28 Feb 2026 17:39:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300366; cv=none; b=Y1+p3SPLwHm/02bbBabSf5A1fdMFzOMqelEOt7hai+/hP35Wwe88O8HiAIkC1+DUFGa/T8rPZmBCp82jP81U1o7sVVt41/QmSlEIFBAjHbO85B9lTfZOineT+gc+fJuIULbQaGwIbCTx0wTBdTeEmqD1+zf1krTDvntZIODc4NY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300366; c=relaxed/simple; bh=rVn4T+1vnnJGADQEtIx/kYDPe7oJdBkEqyDhGHEpXTQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sIC1dnihWI8P3eYBmw3+3nl7m+l+r+jv+RmUso0hpbH4yBZw7zVd8lwCCEWtU2MKze5BbUTg2p/obyFHxDk5BCsOW9UQfqduQhDwkkhxNiehq+bE0+fa4dl8/iRDEofm5KBeZa0pw2t3Pl22GfAwM143MArM+Ass1dvmzmuuq2E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mUmQN5gq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mUmQN5gq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF729C19423; Sat, 28 Feb 2026 17:39:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300366; bh=rVn4T+1vnnJGADQEtIx/kYDPe7oJdBkEqyDhGHEpXTQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mUmQN5gqGhtOZ+LvTCAl8liZzG06ZRWTUtaWbKBmL1Z6CQDfiqhGJitCyGx8law/G 20wS8bz0YVRSazuBXJeixbMmMEsX6nbi8yVR0O8uCo68pYXUcDRqDrg8AYHzDv7ylR Sw74DANhX2P54ZRL0T2b1IjFHwxckL82mMxg4JKsVFC/YvWPmVFma52/vZo6tqwfVy v9xAoYkr4iFRf7AVL4w6qTjynYfH92FVHHmzn4kR0HiFdZ3I7Riq/Qd0ZLQWjeY2W0 h6FXQfq6RwB9+eiP4htXGN84MgtWZtR5dg4qPiGy/8Z55FhWZm+3DHQa+cSwtfq524 dmLlGPy+j3t/Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Garry , Huacai Chen , Thomas Bogendoerfer , Sasha Levin Subject: [PATCH 6.19 401/844] MIPS: Loongson: Make cpumask_of_node() robust against NUMA_NO_NODE Date: Sat, 28 Feb 2026 12:25:14 -0500 Message-ID: <20260228173244.1509663-402-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Garry [ Upstream commit d55d3fe2d1470ac5b6e93efe7998b728013c9fc8 ] The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this. Signed-off-by: John Garry Reviewed-by: Huacai Chen Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/mips/include/asm/mach-loongson64/topology.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/include/asm/mach-loongson64/topology.h b/arch/mips/i= nclude/asm/mach-loongson64/topology.h index 3414a1fd17835..89bb4deab98a6 100644 --- a/arch/mips/include/asm/mach-loongson64/topology.h +++ b/arch/mips/include/asm/mach-loongson64/topology.h @@ -7,7 +7,7 @@ #define cpu_to_node(cpu) (cpu_logical_map(cpu) >> 2) =20 extern cpumask_t __node_cpumask[]; -#define cpumask_of_node(node) (&__node_cpumask[node]) +#define cpumask_of_node(node) ((node) =3D=3D NUMA_NO_NODE ? cpu_all_mask= : &__node_cpumask[node]) =20 struct pci_bus; extern int pcibus_to_node(struct pci_bus *); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B561D3C549B; Sat, 28 Feb 2026 17:39:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300367; cv=none; b=IlUbQGxclWKY1A90MwF9n1AEfUBwgt8xpK4pQmNv/seFNFvBaHFmTzusluthg3QUC69Wtn6x2mBUVgx5oG+BuH6oQAI86YtkM6RagmweHVU5DDzhGN4KgKtugeuPxFAOU/QbomnHC4/YtJbI3LZWI/Z2N38/8lO2wwsvYa5t6bc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300367; c=relaxed/simple; bh=OIBxYoi4uypns6AwCV0b1xVjceQlkEIKTS9RSHW11rY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VihOiYe0ZidkmvG6jcqO5d3xYsupGgGFiCz68ROas2+XCrCmrT3x32cljC05rYWK/JjV5KerOcOLbh7aB3MvjY9eq0EptnXaun88TbVrPb+3YXLB8QmzwZFsQR4NRjvoyYVtMKnFT1O3Y+Wv4cHyjEyHQReBtXmfxxT70YQjfCM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ByvovmCm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ByvovmCm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1B55C116D0; Sat, 28 Feb 2026 17:39:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300367; bh=OIBxYoi4uypns6AwCV0b1xVjceQlkEIKTS9RSHW11rY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ByvovmCmVpASp4QKhoMppCvInPpoJ+zB1rycLnrXXX+uC74/JRC2qrGOIs+uOhhyB 6XBloSuylRgbOgCqTyhp8xwVKAg4BcrZIFXn9Sb2ResfmyOMibqGqQVVFIMcBqnULE WVHCiuxkK7kBW0w4pFK41ulGOnMfuKIhy49AB8lVi6Q3tIHqoxieUyovLhI6Erj59n HX9Sw7/UityFPcKX1j5WUrQfi39RBf9FxqbF69J5yjtgDkW2+c28mFfeZ6roVJOou5 AUgV3+OePOOutkjrt5hVs9EbDLoH117INrQXWU9SGmu11drGU27EpuOZMEnumT+28W UfqR/oXh43U2A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chaitanya Kulkarni , Christoph Hellwig , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 402/844] block: fix partial IOVA mapping cleanup in blk_rq_dma_map_iova Date: Sat, 28 Feb 2026 12:25:15 -0500 Message-ID: <20260228173244.1509663-403-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chaitanya Kulkarni [ Upstream commit 81e7223b1a2d63b655ee72577c8579f968d037e3 ] When dma_iova_link() fails partway through mapping a request's bvec list, the function breaks out of the loop without cleaning up already mapped segments. Similarly, if dma_iova_sync() fails after linking all segments, no cleanup is performed. This leaves partial IOVA mappings in place. The completion path attempts to unmap the full expected size via dma_iova_destroy() or nvme_unmap_data(), but only a partial size was actually mapped, leading to incorrect unmap operations. Add an out_unlink error path that calls dma_iova_destroy() to clean up partial mappings before returning failure. The dma_iova_destroy() function handles both partial unlink and IOVA space freeing. It correctly handles the mapped_len =3D=3D 0 case (first dma_iova_link() failure) by only freeing the IOVA allocation without attempting to unmap. Signed-off-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- block/blk-mq-dma.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c index fb018fffffdcc..feead1934301a 100644 --- a/block/blk-mq-dma.c +++ b/block/blk-mq-dma.c @@ -126,17 +126,20 @@ static bool blk_rq_dma_map_iova(struct request *req, = struct device *dma_dev, error =3D dma_iova_link(dma_dev, state, vec->paddr, mapped, vec->len, dir, attrs); if (error) - break; + goto out_unlink; mapped +=3D vec->len; } while (blk_map_iter_next(req, &iter->iter, vec)); =20 error =3D dma_iova_sync(dma_dev, state, 0, mapped); - if (error) { - iter->status =3D errno_to_blk_status(error); - return false; - } + if (error) + goto out_unlink; =20 return true; + +out_unlink: + dma_iova_destroy(dma_dev, state, mapped, dir, attrs); + iter->status =3D errno_to_blk_status(error); + return false; } =20 static inline void blk_rq_map_iter_init(struct request *rq, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B91003C54B9; Sat, 28 Feb 2026 17:39:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300368; cv=none; b=OP6NCDfZ82d68gwRHmUgjXmxF/K+S158A1kh7yguWL7O33iTI8MwWgKMucv+5H9kHmhQUX2rAFaNPfgoDHkhpI2AJbfiJXrOBgX2SzwiiW68s4Py2FEHisD8GWfy/YwdGWPDvYE7kjVBwzKL8COGE8/md4qwjVFR4xlKRl9ShhU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300368; c=relaxed/simple; bh=8QqsC/w7loO7pIvqjHyjqBcYWmo3bQPoDN2bYXPQljY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=taLK90de3na6/GJdC8WngJ/azVWW0JWM2kCWs8x1znFJeNyeLyRaj1tL0WsupCLxsD+0bUX/l2SW5wzUet7r5FRMkujF2fF04PStifT/PcufPdbs+aOrYlv4ZTqhCklVupNulcd1OfZjZA9qpHuu6LS7lF0RzSAHmkop1vyRf/4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=P8W8bjBc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="P8W8bjBc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6973C116D0; Sat, 28 Feb 2026 17:39:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300368; bh=8QqsC/w7loO7pIvqjHyjqBcYWmo3bQPoDN2bYXPQljY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P8W8bjBcXM6TY9zBqyQ+92/sAVqjQgrODorVjusZRL5TM5ttdNsy34fIPrCpuhyhQ sG9PkpvboSZaMKkB0rRR9VCLaviXueFtMAiRjs7Qaln4hbdC6ghTwCvMK+ZBEH3Q8a IpvneJW6YZn0fLX5Carg+qkn7XOt/1uuKswHYQ2+W7vkY4m/0loBqVroA82nQDYCk0 MkgeLUoDtA007HLQ0oduHO3mDnX0qDyh1eRvhVns9+s2iu62CksxywgJ7N5PKAad/z Eoouug8oQdcinLTY26oWEnV0sQ6+/Q+y27HSkLfC7586fPoNs0EYPNQzVU0UjWuRXH QfsAY4Nt0PRKA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jaehun Gou , Seunghun Han , Jihoon Kwon , Konstantin Komarov , Sasha Levin Subject: [PATCH 6.19 403/844] fs: ntfs3: check return value of indx_find to avoid infinite loop Date: Sat, 28 Feb 2026 12:25:16 -0500 Message-ID: <20260228173244.1509663-404-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jaehun Gou [ Upstream commit 1732053c8a6b360e2d5afb1b34fe9779398b072c ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds t= he size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ntfs3/index.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/ntfs3/index.c b/fs/ntfs3/index.c index 7157cfd70fdcb..75b94beac1613 100644 --- a/fs/ntfs3/index.c +++ b/fs/ntfs3/index.c @@ -1190,7 +1190,12 @@ int indx_find(struct ntfs_index *indx, struct ntfs_i= node *ni, return -EINVAL; } =20 - fnd_push(fnd, node, e); + err =3D fnd_push(fnd, node, e); + + if (err) { + put_indx_node(node); + return err; + } } =20 *entry =3D e; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EFDC63C5C92; Sat, 28 Feb 2026 17:39:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300370; cv=none; b=UtPaOfCBWh7+ltWMyYXZsUJ1PYUl1z82axDnTUZU4cixcVouEqhpAnFeg4dc5t6+Y+3TMo57GCJ0FYYnDf9IrRposRQyGsCL2IVdcXt1r987YPewg6iOGT2hZ41oQyfzRf0hkIbrij99lsl7UeR2KsYU2jva5d59YjGHMuvh/y4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300370; c=relaxed/simple; bh=eJufBIgFYLmO1ZT837sOCaDD3kXiBVg1PvAFNT10wXQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B9GkjQFnWAWbfOjoZlld3GzIgwPvm5VKA4EEkccofDurvhOeoOTRSHqnDLH2ffd9Q2zSDhqU1SKvnFRLdqRgpbtTrIMGOoPZFlPhM4jDBHulIBpSwSlEEcUzZRq+WLyV0iBwEk2ZYocEzlK5xl9lecHBhCLrHfbSCpOMEaLWNFY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rSPH+mO1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rSPH+mO1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0084C116D0; Sat, 28 Feb 2026 17:39:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300369; bh=eJufBIgFYLmO1ZT837sOCaDD3kXiBVg1PvAFNT10wXQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rSPH+mO1b3Ed3iW1zYjTNJzHi49RbMMyegYRsEdmtbmekLrT8Bofn3VZNlE7fxmVV VI9PdstPb95lcI5Yecf3P8vjqYQ4FFCLWNAGV5LqF0ptlBzJivxwIAseWIW8qh1VPM wVxGn3a8iCTLRa+73dwO5S2KrBeXBoUkDw6oWSAVjkwlM6KbF9qye3pmDK9ZyT/hNH xv2RzN05+QESJDR3hbP2eTyMfAZ8tpePxYhTZSv+02AmeYtS4JT5mZO5+e87V+vKes MvESw3J9ArD6SbMTIse/7eSxKoSFG79MFbgvyxTAQ3ZTU84JvWudbg4pZz0ZTKR0Hq JOaVSTIzWO9xQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jaehun Gou , Seunghun Han , Jihoon Kwon , Konstantin Komarov , Sasha Levin Subject: [PATCH 6.19 404/844] fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata Date: Sat, 28 Feb 2026 12:25:17 -0500 Message-ID: <20260228173244.1509663-405-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jaehun Gou [ Upstream commit 4b90f16e4bb5607fb35e7802eb67874038da4640 ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=3D-1 with svcn=3D0 is a valid= way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=3D-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn +=3D 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ntfs3/attrib.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/fs/ntfs3/attrib.c b/fs/ntfs3/attrib.c index 980ae9157248d..c45880ab23912 100644 --- a/fs/ntfs3/attrib.c +++ b/fs/ntfs3/attrib.c @@ -1354,19 +1354,28 @@ int attr_load_runs_range(struct ntfs_inode *ni, enu= m ATTR_TYPE type, CLST vcn; CLST vcn_last =3D (to - 1) >> cluster_bits; CLST lcn, clen; - int err; + int err =3D 0; + int retry =3D 0; =20 for (vcn =3D from >> cluster_bits; vcn <=3D vcn_last; vcn +=3D clen) { if (!run_lookup_entry(run, vcn, &lcn, &clen, NULL)) { + if (retry !=3D 0) { /* Next run_lookup_entry(vcn) also failed. */ + err =3D -EINVAL; + break; + } err =3D attr_load_runs_vcn(ni, type, name, name_len, run, vcn); if (err) - return err; + break; + clen =3D 0; /* Next run_lookup_entry(vcn) must be success. */ + retry++; } + else + retry =3D 0; } =20 - return 0; + return err; } =20 #ifdef CONFIG_NTFS3_LZX_XPRESS --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C27BC3C5CA8; Sat, 28 Feb 2026 17:39:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300370; cv=none; b=WWx3LMzAkMh3kE/aK7HYBntmSx98K+QZRWPXw8/f4q3ikWRO/bELws2vO1IIdlW4oEa9hQRKo92H113MKGvyjxebqO9ZutGMqMVjI6bQRVDP4gbNY3UfUqgYe09Jg2WlCY2v90BOEKmc1NAkz1GoNn2MPL3p8HbQx7Ob6JG7o5s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300370; c=relaxed/simple; bh=nEBHn/E2vI88MIJ7nIqaANfuIDHotYdC5cPu7qAjxCc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WrAeiO7zVGRnNdUrtCz/NBVb3q6ywvfjFqggR49uyWZGDcqtogv45hMC35+TMGMiL0YyQ5qRMtp004iUvLY80LfzVQnegvnCMaD8+3GzsWD7OrtswscOqlEfY8q5fLPsLlBOZ2M79AxwGCSgIbaoBuTBgVwdrpEW1tteg2RyLHI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EHRPO12i; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EHRPO12i" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2498C19424; Sat, 28 Feb 2026 17:39:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300370; bh=nEBHn/E2vI88MIJ7nIqaANfuIDHotYdC5cPu7qAjxCc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EHRPO12iWyoWyl1zrKtNPCz1q6cmy2niMI9/KlNDXObQJ314NH/UXt86AMW1qNOwf S85Yw1dfuazbmzxCsQFMDMdkLmIAWIK8509L/ubX6iytOHgGl+f+tv3v8a5oZPspFA 8CZ82CHKedzRerrdKdlr6vGPukvpf7nz9FnZaaHtf5IFxIXTDKVoHzKyjaD19RJ3Vw 9m/s+TpPvGYdvryIZEceDz1lum7pfIC1+QowaXb3v0kMHEG502cNjg/zB5+j3csA7g bxW66G0Lqy8U+Yk9tklCtvURvgDzngXEfUKIcnSikTayFVGEnl65HYu9PVCVcJc/sZ iLhAxG7trS2cg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jaehun Gou , Seunghun Han , Jihoon Kwon , Konstantin Komarov , Sasha Levin Subject: [PATCH 6.19 405/844] fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST Date: Sat, 28 Feb 2026 12:25:18 -0500 Message-ID: <20260228173244.1509663-406-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jaehun Gou [ Upstream commit 06909b2549d631a47fcda249d34be26f7ca1711d ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribu= te indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribu= te list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel threa= d. This patch adds validation to ensure that data_size is non-zero before memo= ry allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ntfs3/attrlist.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/fs/ntfs3/attrlist.c b/fs/ntfs3/attrlist.c index a4d74bed74fab..098bd7e8c3d64 100644 --- a/fs/ntfs3/attrlist.c +++ b/fs/ntfs3/attrlist.c @@ -52,6 +52,11 @@ int ntfs_load_attr_list(struct ntfs_inode *ni, struct AT= TRIB *attr) =20 if (!attr->non_res) { lsize =3D le32_to_cpu(attr->res.data_size); + if (!lsize) { + err =3D -EINVAL; + goto out; + } + /* attr is resident: lsize < record_size (1K or 4K) */ le =3D kvmalloc(al_aligned(lsize), GFP_KERNEL); if (!le) { @@ -66,6 +71,10 @@ int ntfs_load_attr_list(struct ntfs_inode *ni, struct AT= TRIB *attr) u16 run_off =3D le16_to_cpu(attr->nres.run_off); =20 lsize =3D le64_to_cpu(attr->nres.data_size); + if (!lsize) { + err =3D -EINVAL; + goto out; + } =20 run_init(&ni->attr_list.run); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 85D063C5CBE; Sat, 28 Feb 2026 17:39:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300371; cv=none; b=SORTvzgAdGSytH03ldCyGJh+CapCmIOyJW7TszL2sJvwbj8tn4Gy4uoI9eMUBqFxJFQADgVyv1oNYDzD1EwuKZE+6dBG/sM43xNbWYi1uOcE9gua35E96Nna8gtUQQtj5GKansFj53hHhbn/Gmg8q5gUJ59j5Owr+xsUt5dy1g0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300371; c=relaxed/simple; bh=HEIzHM/hG9YWHaa0ZiDSP3b5QM4WNh/Zah3RMKXgBwY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IYKfgRzbybJMZRglpJ0wjLa9jfxikwq0sDWVEpQjzzsiqx8DRtCWJvCjB5V7UFtiOPrr5tFZLyaXn0k3YZkaU4l8dwK1MPNUKVuy+DE70QscvdPuI8sGAAP/dN3s9nNty42/0+Hb0H7pBVVdYWmk911CjL/69Vlyomq8cA2IrJE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=u1wFAJ+v; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="u1wFAJ+v" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9697C19423; Sat, 28 Feb 2026 17:39:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300371; bh=HEIzHM/hG9YWHaa0ZiDSP3b5QM4WNh/Zah3RMKXgBwY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=u1wFAJ+vnV9XyceYdAK15AjUB3bE0bd3azfaoHMc/cRRU7QGd4htr/uwMRIWxl027 T75eUYKUnD+mACm00qajrFVU3vQSDB2ivyB1rw8YlLAUWoo4vu5HR8a95wxubq6fmH 7slJvBH99JtKNxCaAxBa7WU6aKqlSmpTHgTiOD3DLkdkZ/xwgdeP2I/yyptb6AAkgN PFmfSebF+TSyev3bFeUzrQ7AWdi0iWkG7XK/KiTw/oEHdtBDalzoXbOUSvOE2TVO3U QnR22kiAJ7L8wqnkb2xjGONDheoF95P9QTxEYVZSrcGr8GD4WuxtQm3S6ulzcEyj7v nYpT+QFPnpRmg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konstantin Komarov , Sasha Levin Subject: [PATCH 6.19 406/844] fs/ntfs3: handle attr_set_size() errors when truncating files Date: Sat, 28 Feb 2026 12:25:19 -0500 Message-ID: <20260228173244.1509663-407-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konstantin Komarov [ Upstream commit 576248a34b927e93b2fd3fff7df735ba73ad7d01 ] If attr_set_size() fails while truncating down, the error is silently ignored and the inode may be left in an inconsistent state. Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ntfs3/file.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/fs/ntfs3/file.c b/fs/ntfs3/file.c index 5120bd7851694..13d014b878f6c 100644 --- a/fs/ntfs3/file.c +++ b/fs/ntfs3/file.c @@ -505,8 +505,8 @@ static int ntfs_truncate(struct inode *inode, loff_t ne= w_size) { struct super_block *sb =3D inode->i_sb; struct ntfs_inode *ni =3D ntfs_i(inode); - int err, dirty =3D 0; u64 new_valid; + int err; =20 if (!S_ISREG(inode->i_mode)) return 0; @@ -522,7 +522,6 @@ static int ntfs_truncate(struct inode *inode, loff_t ne= w_size) } =20 new_valid =3D ntfs_up_block(sb, min_t(u64, ni->i_valid, new_size)); - truncate_setsize(inode, new_size); =20 ni_lock(ni); @@ -536,20 +535,19 @@ static int ntfs_truncate(struct inode *inode, loff_t = new_size) ni->i_valid =3D new_valid; =20 ni_unlock(ni); + if (unlikely(err)) + return err; =20 ni->std_fa |=3D FILE_ATTRIBUTE_ARCHIVE; inode_set_mtime_to_ts(inode, inode_set_ctime_current(inode)); if (!IS_DIRSYNC(inode)) { - dirty =3D 1; + mark_inode_dirty(inode); } else { err =3D ntfs_sync_inode(inode); if (err) return err; } =20 - if (dirty) - mark_inode_dirty(inode); - return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 949CE35DA50; Sat, 28 Feb 2026 17:39:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300372; cv=none; b=Z4SopTOl6hmUwpyIJYkVGMG9+UD9wP3NVjk+SGIP4Lae/bscX01tjKEwX/CoTHsQ+oAMlEVhZFD1iysLVIm2gcLZ2Umqaa22DnIC+36t7LBK52OMJ/ug1OFUPvc0Du4E9cwrtjNulOBxFGsBr7p4m4u86bUHEhZ8O8fkphnhXHU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300372; c=relaxed/simple; bh=z69yTu7YGTdTn6w8tiKYhaaMN4El/O20bnCQeaVdANU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HDLlss21nzcMccf5gpiGET0bG10terAwkVnTYaqKMTOzFNR65lgfI8rHy2pIrrPXTB9Num6nKvKIZaE2zY5G9MvJ5GWlxlxfojoFKYlBYslm/VzXmpfIX10wz0Zuz5dwd5CpPfvFHVV2m4wy8L+yn5ZmdJ0lB9AjenGfgysfPc8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EQNtNJ/v; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EQNtNJ/v" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB655C19425; Sat, 28 Feb 2026 17:39:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300372; bh=z69yTu7YGTdTn6w8tiKYhaaMN4El/O20bnCQeaVdANU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EQNtNJ/vntFGHO7/ZoyiqZrBo60sVz13+OUbg1t89qbjz8vt7doNG9EHnH7Sga3Hn 1KCej+onQNJ5RuPD4Kq3f+hgZyVhGaR8+hMEbfOFy/UDZBIlG34JBx3AlJ4EI8cIQs WuIr+tH5ytdkmvjiq89e6SdgrsUi6AvnSC7wNOY9bwBpxbCoLmX2t/DGbFpmHe9VW9 jgYZy5QlVUTu0OvrihhQx8Ufw49ZYav4brxgXm/PN6PDgT66TB9M8W+BvNadnwlTx1 CkBxqZIVWb55tflgKD3Fajena0gKFLXTcqUsTiRIzNto7Y5UArUkfhoVUZ9avVCu71 3M6DBDO6IAg0w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konstantin Komarov , Sasha Levin Subject: [PATCH 6.19 407/844] fs/ntfs3: drop preallocated clusters for sparse and compressed files Date: Sat, 28 Feb 2026 12:25:20 -0500 Message-ID: <20260228173244.1509663-408-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konstantin Komarov [ Upstream commit 3a6aba7f3cf2b46816e08548c254d98de9c74eba ] Do not keep preallocated clusters for sparsed and compressed files. Preserving preallocation in these cases causes fsx failures when running with sparse files and preallocation enabled. Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ntfs3/attrib.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/ntfs3/attrib.c b/fs/ntfs3/attrib.c index c45880ab23912..0cd15a0983fee 100644 --- a/fs/ntfs3/attrib.c +++ b/fs/ntfs3/attrib.c @@ -448,8 +448,10 @@ int attr_set_size(struct ntfs_inode *ni, enum ATTR_TYP= E type, =20 is_ext =3D is_attr_ext(attr_b); align =3D sbi->cluster_size; - if (is_ext) + if (is_ext) { align <<=3D attr_b->nres.c_unit; + keep_prealloc =3D false; + } =20 old_valid =3D le64_to_cpu(attr_b->nres.valid_size); old_size =3D le64_to_cpu(attr_b->nres.data_size); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5973835DA6A; Sat, 28 Feb 2026 17:39:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300373; cv=none; b=mapInrJlxtH+Fxw/I8uJ2awt0C9ASTlbsFpUu5P0TNE3f7rT5VaEIU26/1Ej37XLhyP1k4ANPzxX40MGFG7VHfl0VbaeW9eqMF0aL89m33X/NKOf7ZabHtscOmW1B19G9Z1itShaMJQgd4sF95oGBi0AcL4VieOjyLHCtG8qjK8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300373; c=relaxed/simple; bh=lvdZkfkW74kRgGoxKJBGpZCeXsBUgyeAH0BQerntK04=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rgykEsYn93Zhg47uXmCHqJ9w9js0wSmTN6Al++8rqsDVRgmZAsRxBF6bm4vV24YLf+Tm8n9MXugVU/huG9EvT9ETbmLDG9AU44wMO04O3wF6UM3S3aePIi8bNK8E+0qu0IOg7UR/ljdUri0m8NoRNtpp73ACu3zDbuxqHpPJVYs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V61Rnmda; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V61Rnmda" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7360CC19424; Sat, 28 Feb 2026 17:39:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300373; bh=lvdZkfkW74kRgGoxKJBGpZCeXsBUgyeAH0BQerntK04=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V61RnmdazZD4rEk7ILE1u+3cPa+4HOAGgSRKV3INOUlmBUrTeMSlQLowSdpMyC8Y8 gh3FvrBpdXx9qE9ksfYQmZaianQhqdvifuhGbn1FdujCpjVY5l0/jlZFGJyeo8cufs Iym45me2QEfoqTOkEbTkAtMtOignw+MBPTYDqbrfumMcDaT1gR4FyWEZOR0KZuWJdg 1RcKgS9SSvR8VkWzPl+B5rfrdVzVYmQKbgEEs+M8HX44DexoNU1l6HX+P7QpOtJsa6 +6lCuL/FdNN2XWb6RWbePULJhhLdb2mGMbJgYWQ/bNPXUQm6nZRcSUmvvAIYitrovN U1Zxk8TlVCmzg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Szymon Wilczek , syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com, Konstantin Komarov , Sasha Levin Subject: [PATCH 6.19 408/844] ntfs3: fix circular locking dependency in run_unpack_ex Date: Sat, 28 Feb 2026 12:25:21 -0500 Message-ID: <20260228173244.1509663-409-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Szymon Wilczek [ Upstream commit 08ce2fee1b869ecbfbd94e0eb2630e52203a2e03 ] Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock. The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone(). This creates an AB-BA deadlock. Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock. Reported-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com Tested-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Dd27edf9f96ae85939222 Signed-off-by: Szymon Wilczek Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ntfs3/run.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/ntfs3/run.c b/fs/ntfs3/run.c index 395b204925258..dc59cad4fa376 100644 --- a/fs/ntfs3/run.c +++ b/fs/ntfs3/run.c @@ -1131,11 +1131,14 @@ int run_unpack_ex(struct runs_tree *run, struct ntf= s_sb_info *sbi, CLST ino, struct rw_semaphore *lock =3D is_mounted(sbi) ? &sbi->mft.ni->file.run_lock : NULL; - if (lock) - down_read(lock); - ntfs_refresh_zone(sbi); - if (lock) - up_read(lock); + if (lock) { + if (down_read_trylock(lock)) { + ntfs_refresh_zone(sbi); + up_read(lock); + } + } else { + ntfs_refresh_zone(sbi); + } } up_write(&wnd->rw_lock); if (err) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29DF63C5CA5; Sat, 28 Feb 2026 17:39:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300374; cv=none; b=tpucmjN3MNPsildPu7mRNZLTGjneZd020B6ZkDxsIIrMsa2Kgp4BVKXlHWd6mHZ1BTn2shCTOKa9pVAwnxWy2vjh/nJWlByf5O+f3vCDCgrQwmaMCJYoqAwG//oz5DKcMZ0INlt6rs/8ZJUq56AaGFs1ubYVPCYAWOtXmF7xGk0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300374; c=relaxed/simple; bh=p8922vCtxBCG5X3sTHGfzms+45v893kkBlH0TnDgQZs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hgvEQOAlHka6gYMCF4bRh5c/KK/RL0Cvjm6K7wESY0cEh7J7HZE5GZnVz2t4vexo5K5yPi3d00RQ3jN5yIWLakwZa359TEoTqb87W9UJEJvhIHdLWeDB3tTdeMkyak4wf6S/KXH5AZOiPaIqEKPF0EqfaV+wGl7lRFb4MDI38Z8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fU6zCZWn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fU6zCZWn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 608C9C116D0; Sat, 28 Feb 2026 17:39:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300374; bh=p8922vCtxBCG5X3sTHGfzms+45v893kkBlH0TnDgQZs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fU6zCZWnt08WFbwYF0kAyyc+joSwgnhlxv2x980kB7VNCUoH3NoVwJvtcJDsqZP8J hq1aokkYhI+g0w50Vdi0NWS6aLIYIuqEPETXtvlRimJ0k5jvVV3PgtsbO3c76Py0xD m89IqWcAcX8Ke+Y0Keh6aZFx2b7Tn7xKQOL0zdD5KbQlqXIlmqfGLquVP9nbicB/ku Wcv3ZDfc8qw8gTiiAJ4iY5uSiNFIk934I2IGVs1ZLGX3yn0qMGm43tLG3YVI4lLwHx +yuiwy90b0Y+J7SRj0yA9gzOMLACWFAuwX6KB2puwQ4ns0xZAMCThFsAfAIHxGS6CX USQu2gmin2GRQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konstantin Komarov , kernel test robot , Dan Carpenter , Sasha Levin Subject: [PATCH 6.19 409/844] fs/ntfs3: avoid calling run_get_entry() when run == NULL in ntfs_read_run_nb_ra() Date: Sat, 28 Feb 2026 12:25:22 -0500 Message-ID: <20260228173244.1509663-410-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konstantin Komarov [ Upstream commit c5226b96c08a010ebef5fdf4c90572bcd89e4299 ] When ntfs_read_run_nb_ra() is invoked with run =3D=3D NULL the code later assumes run is valid and may call run_get_entry(NULL, ...), and also uses clen/idx without initializing them. Smatch reported uninitialized variable warnings and this can lead to undefined behaviour. This patch fixes it. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202512230646.v5hrYXL0-lkp@intel.com/ Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ntfs3/fsntfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/ntfs3/fsntfs.c b/fs/ntfs3/fsntfs.c index bd67ba7b50153..ea5b673462c35 100644 --- a/fs/ntfs3/fsntfs.c +++ b/fs/ntfs3/fsntfs.c @@ -1252,6 +1252,12 @@ int ntfs_read_run_nb(struct ntfs_sb_info *sbi, const= struct runs_tree *run, =20 } while (len32); =20 + if (!run) { + err =3D -EINVAL; + goto out; + } + + /* Get next fragment to read. */ vcn_next =3D vcn + clen; if (!run_get_entry(run, ++idx, &vcn, &lcn, &clen) || vcn !=3D vcn_next) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53FF83C6C7E; Sat, 28 Feb 2026 17:39:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300375; cv=none; b=PnTZ0Lcsubgp+fBioTjrEWE8Io70OjJl1IMdxve6TeD7nOld2cZBumoyzitXXBa1o+JilXvbZTL9dpn1ul5hmRe+223k0ZhpiDzWddLhg2oiOJb49hiNpt+7glK0tfmvHZC21ScrFuq+vRNcrT/n0jDQrTkPgmKqnvUiey2st8s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300375; c=relaxed/simple; bh=+LFFS+stI+uOU1fATjaA1Y4zF0vcSj1p8FCwZJMkMoI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FjT8fvIxWmAnGnFyjmJMoeLyjVQMyOcamRUNi1g9VmfehSJKMGxVLVIdISqpwP1v+JJnmk42EfEwYw2CTi5+hzLuOnFUF3PThBQYZ88JxNMexQ98iecNNFYEIHbyiMNz6M/S05dYGNRgEvJ3zAPIXUf3odv7i+tp6+N8Md6I5WY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mG+toGzk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mG+toGzk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CC77C116D0; Sat, 28 Feb 2026 17:39:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300375; bh=+LFFS+stI+uOU1fATjaA1Y4zF0vcSj1p8FCwZJMkMoI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mG+toGzkYE2YW3/EKOVcabil79ZRL8/46incGPlzIEiWTz8YpzIw9bV50XDPabK6w RVBhCzZ8Lk3bvO8/nXWK43IJeWhRHcpBC92GMMWybQVKug+60aJbZfy9cIY4+TVSRh egpvWx8cJ6/sIMvt8sXT9fYurOzNRdHstYr902whcfuH8CQAEVY3wTzxs+tJShBnsF lGB0C+d5H+j9so3IbJGueOjtFg9s+7p/1SSF9ufORQEfbFCd+iiprO6JaIIOQyepvR IKt4WzAiK/ZZGNRYXK1eR4pFefZV8Qv/MSxgltoK2pXicnfeEssWvAzohTMI+MKRCD PMcRTCSUvFRTQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: ethanwu , Viacheslav Dubeyko , Ilya Dryomov , Sasha Levin Subject: [PATCH 6.19 410/844] ceph: supply snapshot context in ceph_uninline_data() Date: Sat, 28 Feb 2026 12:25:23 -0500 Message-ID: <20260228173244.1509663-411-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: ethanwu [ Upstream commit 305ff6b3a03c230d3c07b61457e961406d979693 ] The ceph_uninline_data function was missing proper snapshot context handling for its OSD write operations. Both CEPH_OSD_OP_CREATE and CEPH_OSD_OP_WRITE requests were passing NULL instead of the appropriate snapshot context, which could lead to unnecessary object clone. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore // turn on cephfs inline data ./bin/ceph fs set a inline_data true --yes-i-really-really-mean-it // allow fs_a client to take snapshot ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=3Da' mon 'allow r f= sname=3Da' osd 'allow rw tag cephfs data=3Da' // mount cephfs with fuse, since kernel cephfs doesn't support inline write ceph-fuse --id fs_a -m 127.0.0.1:40318 --conf ceph.conf -d /mnt/mycephfs/ // bump snapshot seq mkdir /mnt/mycephfs/.snap/snap1 echo "foo" > /mnt/mycephfs/test // umount and mount it again using kernel cephfs client umount /mnt/mycephfs mount -t ceph fs_a@.a=3D/ /mnt/mycephfs/ -o conf=3D./ceph.conf echo "bar" >> /mnt/mycephfs/test ./bin/rados listsnaps -p cephfs.a.data $(printf "%x\n" $(stat -c %i /mnt/my= cephfs/test)).00000000 will see this object does unnecessary clone 1000000000a.00000000 (seq:2): cloneid snaps size overlap 2 2 4 [] head - 8 but it's expected to see 10000000000.00000000 (seq:2): cloneid snaps size overlap head - 8 since there's no snapshot between these 2 writes clone happened because the first osd request CEPH_OSD_OP_CREATE doesn't pass snap context so object is created with snap seq 0, but later data writeback is equipped with snapshot context. snap.seq(1) > object snap seq(0), so osd does object clone. This fix properly acquiring the snapshot context before performing write operations. Signed-off-by: ethanwu Reviewed-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ceph/addr.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index 63b75d2142102..faecd9025ee9c 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -2199,6 +2199,7 @@ int ceph_uninline_data(struct file *file) struct ceph_osd_request *req =3D NULL; struct ceph_cap_flush *prealloc_cf =3D NULL; struct folio *folio =3D NULL; + struct ceph_snap_context *snapc =3D NULL; u64 inline_version =3D CEPH_INLINE_NONE; struct page *pages[1]; int err =3D 0; @@ -2226,6 +2227,24 @@ int ceph_uninline_data(struct file *file) if (inline_version =3D=3D 1) /* initial version, no data */ goto out_uninline; =20 + down_read(&fsc->mdsc->snap_rwsem); + spin_lock(&ci->i_ceph_lock); + if (__ceph_have_pending_cap_snap(ci)) { + struct ceph_cap_snap *capsnap =3D + list_last_entry(&ci->i_cap_snaps, + struct ceph_cap_snap, + ci_item); + snapc =3D ceph_get_snap_context(capsnap->context); + } else { + if (!ci->i_head_snapc) { + ci->i_head_snapc =3D ceph_get_snap_context( + ci->i_snap_realm->cached_context); + } + snapc =3D ceph_get_snap_context(ci->i_head_snapc); + } + spin_unlock(&ci->i_ceph_lock); + up_read(&fsc->mdsc->snap_rwsem); + folio =3D read_mapping_folio(inode->i_mapping, 0, file); if (IS_ERR(folio)) { err =3D PTR_ERR(folio); @@ -2241,7 +2260,7 @@ int ceph_uninline_data(struct file *file) req =3D ceph_osdc_new_request(&fsc->client->osdc, &ci->i_layout, ceph_vino(inode), 0, &len, 0, 1, CEPH_OSD_OP_CREATE, CEPH_OSD_FLAG_WRITE, - NULL, 0, 0, false); + snapc, 0, 0, false); if (IS_ERR(req)) { err =3D PTR_ERR(req); goto out_unlock; @@ -2257,7 +2276,7 @@ int ceph_uninline_data(struct file *file) req =3D ceph_osdc_new_request(&fsc->client->osdc, &ci->i_layout, ceph_vino(inode), 0, &len, 1, 3, CEPH_OSD_OP_WRITE, CEPH_OSD_FLAG_WRITE, - NULL, ci->i_truncate_seq, + snapc, ci->i_truncate_seq, ci->i_truncate_size, false); if (IS_ERR(req)) { err =3D PTR_ERR(req); @@ -2320,6 +2339,7 @@ int ceph_uninline_data(struct file *file) folio_put(folio); } out: + ceph_put_snap_context(snapc); ceph_free_cap_flush(prealloc_cf); doutc(cl, "%llx.%llx inline_version %llu =3D %d\n", ceph_vinop(inode), inline_version, err); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB5713C6C8E; Sat, 28 Feb 2026 17:39:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300375; cv=none; b=qZgUWD7tdap6vjYCIoU2JpbiG1WZXvM7cX6qu/jijWjGiONJBMvad0BakmvkHYKIIiCpIZRGq+ZY7jiGOG1eU+fv4HKz3uXDLcbUy1E9dRYhxDBTTSCLyy8jl3h5bvyHnH1kRiddeU7nfo9mcDytR3svgo/9MRwM/XQZ3I2LW1E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300375; c=relaxed/simple; bh=bxOlb7S2gEiTiRn/OHO4IMGNPo+NERVhy1Idt0tE1Zw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GBjHqD4rU/Fx7xBV2KpTVlE31v/lDdzKS769PZMu1OW6TRbGJC9yUMpM3AjjD8h0bjjVTeJylFJT4A0/3evRZJkHOKiQozd47yLUGfyHERsDCi0WrUdGTErBukGmE7zcGqujepTABahqIWP71vU+g3ok5/DCZRoAZbBmmLyJArI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O3Vg6lnl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O3Vg6lnl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A7B4C19423; Sat, 28 Feb 2026 17:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300375; bh=bxOlb7S2gEiTiRn/OHO4IMGNPo+NERVhy1Idt0tE1Zw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O3Vg6lnliLo9MViDfZTfCvWXhrbuVao6f7hzp9aWLveFeVwjSqDwBal95igMV0Y5P tqSI+k69pFoH8/YUaBzJ3xXAQAQlTCr2lx5lPV+uAQA/KzyzheLg01OadhSnBZ4JPj TcD0s7fcR+c26qheYOWNIJAojFXV9TFxfcaf1RUFUXQJlywp/cuje1KwCVSAw+XW/e J6Ndr3PB6wy9wUi/rdV5H6ACN9hf8+E1FtkgYxjRagGw33P9asLuu26WAhjZqRXjjy co/b7/AFkg0BQjKAhCzEvapgMBsgAiRav3MUatn707jeKaZm10QFR2yA5dCgRmthnP e/mf6XgQH+0hQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ilya Dryomov , Sasha Levin Subject: [PATCH 6.19 411/844] libceph: define and enforce CEPH_MAX_KEY_LEN Date: Sat, 28 Feb 2026 12:25:24 -0500 Message-ID: <20260228173244.1509663-412-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ilya Dryomov [ Upstream commit ac431d597a9bdfc2ba6b314813f29a6ef2b4a3bf ] When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway. Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/ceph/crypto.c | 8 +++++--- net/ceph/crypto.h | 2 +- net/ceph/messenger_v2.c | 2 +- 3 files changed, 7 insertions(+), 5 deletions(-) diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c index 01b2ce1e8fc06..5601732cf4faa 100644 --- a/net/ceph/crypto.c +++ b/net/ceph/crypto.c @@ -37,9 +37,6 @@ static int set_secret(struct ceph_crypto_key *key, void *= buf) return -ENOTSUPP; } =20 - if (!key->len) - return -EINVAL; - key->key =3D kmemdup(buf, key->len, GFP_NOIO); if (!key->key) { ret =3D -ENOMEM; @@ -83,6 +80,11 @@ int ceph_crypto_key_decode(struct ceph_crypto_key *key, = void **p, void *end) ceph_decode_copy(p, &key->created, sizeof(key->created)); key->len =3D ceph_decode_16(p); ceph_decode_need(p, end, key->len, bad); + if (key->len > CEPH_MAX_KEY_LEN) { + pr_err("secret too big %d\n", key->len); + return -EINVAL; + } + ret =3D set_secret(key, *p); memzero_explicit(*p, key->len); *p +=3D key->len; diff --git a/net/ceph/crypto.h b/net/ceph/crypto.h index 23de29fc613cf..a20bad6d1e964 100644 --- a/net/ceph/crypto.h +++ b/net/ceph/crypto.h @@ -5,7 +5,7 @@ #include #include =20 -#define CEPH_KEY_LEN 16 +#define CEPH_MAX_KEY_LEN 16 #define CEPH_MAX_CON_SECRET_LEN 64 =20 /* diff --git a/net/ceph/messenger_v2.c b/net/ceph/messenger_v2.c index c9d50c0dcd33a..31e042dc1b3f2 100644 --- a/net/ceph/messenger_v2.c +++ b/net/ceph/messenger_v2.c @@ -2360,7 +2360,7 @@ static int process_auth_reply_more(struct ceph_connec= tion *con, */ static int process_auth_done(struct ceph_connection *con, void *p, void *e= nd) { - u8 session_key_buf[CEPH_KEY_LEN + 16]; + u8 session_key_buf[CEPH_MAX_KEY_LEN + 16]; u8 con_secret_buf[CEPH_MAX_CON_SECRET_LEN + 16]; u8 *session_key =3D PTR_ALIGN(&session_key_buf[0], 16); u8 *con_secret =3D PTR_ALIGN(&con_secret_buf[0], 16); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA58F3C7540; Sat, 28 Feb 2026 17:39:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300376; cv=none; b=YxYEtsis6k5jXB/C/19VPTRIYMLxsb/nCEJG2V+MeP4/nQvyC6+u7zNjt/IGhb6QUp8kpJDBDyVpyL3hkcBpr0w9GND0VwIe3f/gr0U+9yyPiSHZExRlak7KgrKHulomQnyz4ou32KreXHBb4e74c+a3DYEvxIs7/R8xuKJhJ7k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300376; c=relaxed/simple; bh=I+WvSmise0Jx+vGOsNKnKisnbDDF5sjkEkUosGkspek=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sCMutkNPMpJhgR1bWjEj/CSl1RVC/eabUVbpPaJju66Nm4OgDZhHNmWUF0YAgi05USPFinKJxnL072fA6qR6/bZsSDIqX4QFHQJbS0q2N7iHkQI22LNxzqMqH1XU+Of2x/O80BK3W3ZUX+Qa6MhKBqPiZYsahnc9ECqgxOM+1ZY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=suNbqh0C; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="suNbqh0C" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F0F0EC19423; Sat, 28 Feb 2026 17:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300376; bh=I+WvSmise0Jx+vGOsNKnKisnbDDF5sjkEkUosGkspek=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=suNbqh0CDJYBXnnsCyDQTiuQPjqt1Fv6SeGiNork1UtFNRIFhn0cDsKAxhjz/IISx q7+qARlvPoLYlO1UPOWmLz8b2UjU7EJ9B8AZj4cdOC+7L6BveOuuPL34ZUVOVse/b1 KXcnvxhcmKQj+FUt7rq35CaoeWjqaOc7qhp+athPA9ePpz34MJw+KSoG29EqviFaMu xBzL1cxF2eJdeNa82ENW/X4COgkqXB0SstZNKYgwHzAexFc6TTwNrdTEJeM+1Wh0wE Iod4gcEk0v9DpzjSOTloIgOwTV4fxdvUvKu7gxfUxkK15glnv8BHf5Nc1ogkKhU03Q E26j1skfyD33Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kaushlendra Kumar , Srinivas Pandruvada , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 412/844] thermal: int340x: Fix sysfs group leak on DLVR registration failure Date: Sat, 28 Feb 2026 12:25:25 -0500 Message-ID: <20260228173244.1509663-413-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kaushlendra Kumar [ Upstream commit 15176b818e048ccf6ef4b96db34eda7b7e98938a ] When DLVR sysfs group creation fails in proc_thermal_rfim_add(), the function returns immediately without cleaning up the FIVR group that may have been created earlier. Add proper error unwinding to remove the FIVR group before returning failure. Signed-off-by: Kaushlendra Kumar Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/LV3PR11MB876881B77D32A2854AD2908EF563A@LV3PR= 11MB8768.namprd11.prod.outlook.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../thermal/intel/int340x_thermal/processor_thermal_rfim.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c= b/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c index 589a3a71f0c4c..ba88d878c998d 100644 --- a/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c +++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c @@ -466,8 +466,11 @@ int proc_thermal_rfim_add(struct pci_dev *pdev, struct= proc_thermal_device *proc break; } ret =3D sysfs_create_group(&pdev->dev.kobj, &dlvr_attribute_group); - if (ret) + if (ret) { + if (proc_priv->mmio_feature_mask & PROC_THERMAL_FEATURE_FIVR) + sysfs_remove_group(&pdev->dev.kobj, &fivr_attribute_group); return ret; + } } =20 if (proc_priv->mmio_feature_mask & PROC_THERMAL_FEATURE_DVFS) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A94153C7559; Sat, 28 Feb 2026 17:39:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300377; cv=none; b=dLTZ18r9COC8bSRu4Q7ydi4z3JoWXiyi+ZSSyFDYE4WgEGZi7JSAlQ0+oV4sDTuU5R0tVFLgw2CTDslV8QI8YMcUFoLTTbWDF2nICU0D6Mub2JYT4DgbjJhO+Kf7bb5dknTOUJ/8/immWyUwN6xKRvqthScV2UxL+k5F+V3usWc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300377; c=relaxed/simple; bh=LRvyp1T7495ebwokwEb5xk3tnpAB4BOXNi8MmubQZjQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LloOGc0IM32wS4xkhPG8rjOefKQICYDooXCmgbAAvVUwlDfyIMy/lgQn05X4BdbSHOPbIOAJ1Lm3ZEDxuc5xo6+kmBrR9ZJvMwWGmd4A4Blrju9RJPwhH7glx/PDF9YCv0jRz5wD5zex6ozhFGxCVPwQyy7YMZcUKz3aakpHpU4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I9PAN+dn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I9PAN+dn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3307C116D0; Sat, 28 Feb 2026 17:39:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300377; bh=LRvyp1T7495ebwokwEb5xk3tnpAB4BOXNi8MmubQZjQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I9PAN+dnhNDBuHO9gcln1jTPn3RqLBg8oYdJg2Va5l1Mn7OVabpqy7E7it02iqA92 kNszaOodf+3gtaZeaKOhFXng1XZI9x/h1+3ARwEC+iAb1DhINeIWjXrviJxvT0YRGh qC1r3VGRCH+gNdMmUDrBTt00CfG8kci9ImNyPowwz2f+4Fk296tnBTnDM6fjqLlMLC WpGlDT6NKWHcw6uB7CNlUY9XtKpPVr5oiwCLJTTPj4NT/2nus/bcb/5asQFBbjPPtC OswjE2gdz2i6+3fhmD6UFOmZBGXDQQIrztw0ZwpOuMfSiyXk64nNeEgyfWXcbc7JjM 2vWIYOp3qb2HQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yauhen Kharuzhy , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 413/844] ACPI: x86: Force enabling of PWM2 on the Yogabook YB1-X90 Date: Sat, 28 Feb 2026 12:25:26 -0500 Message-ID: <20260228173244.1509663-414-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yauhen Kharuzhy [ Upstream commit a8c975302868c716afef0f50467bebbd069a35b8 ] The PWM2 on YB1-X90 tablets is used for keyboard backlight control but it is disabled in the ACPI DSDT table. Add it to the override_status_ids list to allow keyboard function control driver (drivers/platform/x86/lenovo/yogabook.c) to use it. Signed-off-by: Yauhen Kharuzhy Link: https://patch.msgid.link/20260211222242.4101162-1-jekhor@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/x86/utils.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c index 4ee30c2897a2b..418951639f511 100644 --- a/drivers/acpi/x86/utils.c +++ b/drivers/acpi/x86/utils.c @@ -81,6 +81,18 @@ static const struct override_status_id override_status_i= ds[] =3D { DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"), }), =20 + /* + * Lenovo Yoga Book uses PWM2 for touch keyboard backlight control. + * It needs to be enabled only for the Android device version (YB1-X90* + * aka YETI-11); the Windows version (YB1-X91*) uses ACPI control + * methods. + */ + PRESENT_ENTRY_HID("80862289", "2", INTEL_ATOM_AIRMONT, { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"), + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"), + }), + /* * The INT0002 device is necessary to clear wakeup interrupt sources * on Cherry Trail devices, without it we get nobody cared IRQ msgs. --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 895DB3C7579; Sat, 28 Feb 2026 17:39:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300378; cv=none; b=iF0cBu0/A5TUyH63fuYmTM+mbu0FDj6cUIf5qadZrMkQPn8erbzCetM4KSkh05o6MepFaWpeUwCJg2LZx8mEvImdT8FDxTvJxjmkviNwaCeerWdBlEwDzygQTdxek8brPZgogdaKYit4FeqwOo29r3XrmYqUsNwRcIQ+/kOOUWw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300378; c=relaxed/simple; bh=SmIZ7eLhuIMXWv0+9VOXp6q9bv9TM4DpcEnGvHeowfc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=S91rzEQsIZkD+TyWtPkmrzx7XcRKimNQvGSQqq5sI+tVrkTAc2hADdU2L8MROM0YsNpJjPhwrJSqA5Wb5biAF2vThYwQYqHukSfoetOWha5Gy/PigErLsEsuK4taypuJkyjKvI+Z8EnKk8smYu60DBRMP0BUmocgdtEG7Uuv8fE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p3UQYNoD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p3UQYNoD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD4A7C19423; Sat, 28 Feb 2026 17:39:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300378; bh=SmIZ7eLhuIMXWv0+9VOXp6q9bv9TM4DpcEnGvHeowfc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p3UQYNoDTtPjHQxgVc92AVBKk2IjoEVp+XQBLkVhYNaTXKaySjEYihqoAl7U5emLP q/mItUgNU60XegredbhoLszFSlEYAOLOaTKfcpp09alJDm3LK7DC/2r6VO0eeXwzlm GyaUj+MFRGyoupAOzEDcFDmUctIPBp8YtwZ3J/W90FZkqaK9Ih1glw7RBXSAybSs42 F1qoRHrzuQ5AG1O8lmLDBEn2oKJDEwt0pZZ150GoIxIo3T4YD91OiisGjKPARX7cn0 toMY57uODU3/eJT16//HaQMS3vG4j/MAd/ywNqoAOHSfeBmt9NBMl2WORttuXk4GST WHq3ZQcpRoN3A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Phil Sutter , Alyssa Ross , Florian Westphal , Sasha Levin Subject: [PATCH 6.19 414/844] include: uapi: netfilter_bridge.h: Cover for musl libc Date: Sat, 28 Feb 2026 12:25:27 -0500 Message-ID: <20260228173244.1509663-415-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Phil Sutter [ Upstream commit 4edd4ba71ce0df015303dba75ea9d20d1a217546 ] Musl defines its own struct ethhdr and thus defines __UAPI_DEF_ETHHDR to zero. To avoid struct redefinition errors, user space is therefore supposed to include netinet/if_ether.h before (or instead of) linux/if_ether.h. To relieve them from this burden, include the libc header here if not building for kernel space. Reported-by: Alyssa Ross Suggested-by: Florian Westphal Signed-off-by: Phil Sutter Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/uapi/linux/netfilter_bridge.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/uapi/linux/netfilter_bridge.h b/include/uapi/linux/net= filter_bridge.h index 1610fdbab98df..ad520d3e9df8f 100644 --- a/include/uapi/linux/netfilter_bridge.h +++ b/include/uapi/linux/netfilter_bridge.h @@ -5,6 +5,10 @@ /* bridge-specific defines for netfilter.=20 */ =20 +#ifndef __KERNEL__ +#include /* for __UAPI_DEF_ETHHDR if defined */ +#endif + #include #include #include --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 62EA33C7D8C; Sat, 28 Feb 2026 17:39:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300379; cv=none; b=Npg1NANOUOBRHUf4rGthI2eZcRO3mPuCg30rpGwm8xTrbeQ71pzeAs+MJhSEphro4b6JwPqjvqmH7cdaLVMQco93vBu1EdRmMDRXMxxInRLKa3fFlzmOoHzHJGR1olCGZUrNWy6FGfPd7niThV6D1MH13VGUOMz8m42kiCRUDXc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300379; c=relaxed/simple; bh=dn1iFD73VMHB/YqmWH1neyVbOGQ8Ue4J3Ro2YMlNY1o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WACfRwfsVPtzMCRD3aD/69r/jhZaE72vDXIzMRpJNK0PbpiTeLOdcy2EnNOgS59ztS4KQ8Dg9hsjlT/4cEku+NI2n5F7bjmif71SHCPVx+F4UgRxly0g68W/AW+5SqBts7hX6JDS0PtaCnTk4ay0SWdnN+NIlDgpca5+6LfPwCA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j1gRhOlJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j1gRhOlJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE51AC19424; Sat, 28 Feb 2026 17:39:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300379; bh=dn1iFD73VMHB/YqmWH1neyVbOGQ8Ue4J3Ro2YMlNY1o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j1gRhOlJQbQ16BTwwCGnO0Rsl/qTu0b6NaVLgNMut0YKbszvxcPo1fTZu4C7the0n PCyMQIJLFFrflGcj8IbxMZ0oU9Av3gXgqvSyAgNpJfpOYzolE6w+BeiRBhbezyap4g ORsFSK+90uuwIq3GPKuh7rYaYCWmYI5F9CtgkuUmuYFjsK2f7rYCHvyWTpf+oKfpKW B4a5poArAXFykFLuVZUMfwtCOQmH/WLZ9JsMUOlyVHthsyXDITT/kAqnY5ua6lL8as rI6DWaI07RMzKXjBWmRxvzXc9KFOASq0pu8op0DzYNYepNsCowVjjO61ouf5GeTpk0 rEjxFmnd6LnMw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Weissschuh , "Russell King (Oracle)" , Sasha Levin Subject: [PATCH 6.19 415/844] ARM: 9467/1: mm: Don't use %pK through printk Date: Sat, 28 Feb 2026 12:25:28 -0500 Message-ID: <20260228173244.1509663-416-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Thomas Weissschuh [ Upstream commit 012ea376a5948b025f260aa45d2a6ec5d96674ea ] Restricted pointers ("%pK") were never meant to be used through printk(). They can acquire sleeping locks in atomic contexts. Switch to %px over the more secure %p as this usage is a debugging aid, gated behind CONFIG_DEBUG_VIRTUAL and used by WARN(). Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7= c7070468023@linutronix.de/ Signed-off-by: Thomas Wei=C3=9Fschuh Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm/mm/physaddr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mm/physaddr.c b/arch/arm/mm/physaddr.c index 3f263c840ebc4..1a37ebfacbba9 100644 --- a/arch/arm/mm/physaddr.c +++ b/arch/arm/mm/physaddr.c @@ -38,7 +38,7 @@ static inline bool __virt_addr_valid(unsigned long x) phys_addr_t __virt_to_phys(unsigned long x) { WARN(!__virt_addr_valid(x), - "virt_to_phys used for non-linear address: %pK (%pS)\n", + "virt_to_phys used for non-linear address: %px (%pS)\n", (void *)x, (void *)x); =20 return __virt_to_phys_nodebug(x); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7CDC73C7DAE; Sat, 28 Feb 2026 17:39:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300380; cv=none; b=YQhdOMoU3RexMltAmt0fujzqgoyBMSt3dj8NKajpeM/smgNqP/pIImm3DPk5/Lsx+jLN6t4Wu7NDiPJK1tupNRu9FaQCszsFFa9b1EC+Vr+FZaOPsHI9eSIYUnjlxm5QEHC0V7Q8CS1CfsBu4/UlG/Cch6HDN2YPPU35xkpMt7c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300380; c=relaxed/simple; bh=m89m20wiqH7mnSq3LhErip9IslFvY+E+ehGPSQd9HaM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eyJ37pORMitEGHiHUocPRC9NcDFVxE7kOw5zyJmuBuxcJqzSkti7+lBzDiVUqexz0op9TinIfRfYAj9GpZBm76Bwe0ZDDBX4gbj+7xIg1lqPAHJikvhkNU7fwjIsGDyxgZQQEBPqNE2QGiCwu6hjJ7m/92DCcBpBfvR6BBOYiac= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pnuA2Nr/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pnuA2Nr/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89CC6C2BC87; Sat, 28 Feb 2026 17:39:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300380; bh=m89m20wiqH7mnSq3LhErip9IslFvY+E+ehGPSQd9HaM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pnuA2Nr/cb+U9gVnxh+s3wfM6E+H1CMwMQjT9+t/0OPSz2RuYaUe5+GIX46SPg5np HMAodA/gUvnW58HHqLv++JqsXPPFq5OZNZXyzscCfqeI/EgZalY4bn6xDAMxajguWa qFcvbk77nT9kOsLADEl51oFeS2DhEs28WlcoiK4v/KuPCLFUN5cah9QQIyNsg8sIeF u+gmtbpb2ZdqA9jw7vDfU2uGw53rc7HZvDe5xWH+bCstmgVAkGxy3N3D7eH84KiB4W JO08K3hvsQLLY9kHx0DoD3s9wsRkQA70cHINt1QbipNaz6MBKjjDfXiVULDLsRYDm+ VI3nNVc6mOYTg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alex Hung , Harry Wentland , Wayne Lin , Dan Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 416/844] drm/amd/display: Fix writeback on DCN 3.2+ Date: Sat, 28 Feb 2026 12:25:29 -0500 Message-ID: <20260228173244.1509663-417-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alex Hung [ Upstream commit 9ef84a307582a92ef055ef0bd3db10fd8ac75960 ] [WHAT] 1. Set no scaling for writeback as they are hardcoded in DCN3.2+. 2. Set no fast plane update for writeback commits. Reviewed-by: Harry Wentland Signed-off-by: Alex Hung Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gp= u/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 209a6e5c713ca..150cc3fc7b2a9 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -10648,10 +10648,10 @@ static void dm_set_writeback(struct amdgpu_displa= y_manager *dm, =20 wb_info->dwb_params.capture_rate =3D dwb_capture_rate_0; =20 - wb_info->dwb_params.scaler_taps.h_taps =3D 4; - wb_info->dwb_params.scaler_taps.v_taps =3D 4; - wb_info->dwb_params.scaler_taps.h_taps_c =3D 2; - wb_info->dwb_params.scaler_taps.v_taps_c =3D 2; + wb_info->dwb_params.scaler_taps.h_taps =3D 1; + wb_info->dwb_params.scaler_taps.v_taps =3D 1; + wb_info->dwb_params.scaler_taps.h_taps_c =3D 1; + wb_info->dwb_params.scaler_taps.v_taps_c =3D 1; wb_info->dwb_params.subsample_position =3D DWB_INTERSTITIAL_SUBSAMPLING; =20 wb_info->mcif_buf_params.luma_pitch =3D afb->base.pitches[0]; @@ -11667,6 +11667,8 @@ static bool should_reset_plane(struct drm_atomic_st= ate *state, struct drm_crtc_state *old_crtc_state, *new_crtc_state; struct dm_crtc_state *old_dm_crtc_state, *new_dm_crtc_state; struct amdgpu_device *adev =3D drm_to_adev(plane->dev); + struct drm_connector_state *new_con_state; + struct drm_connector *connector; int i; =20 /* @@ -11677,6 +11679,15 @@ static bool should_reset_plane(struct drm_atomic_s= tate *state, state->allow_modeset) return true; =20 + /* Check for writeback commit */ + for_each_new_connector_in_state(state, connector, new_con_state, i) { + if (connector->connector_type !=3D DRM_MODE_CONNECTOR_WRITEBACK) + continue; + + if (new_con_state->writeback_job) + return true; + } + if (amdgpu_in_reset(adev) && state->allow_modeset) return true; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 696EF481642; Sat, 28 Feb 2026 17:39:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300381; cv=none; b=dAUh4S6ZlX5rtEsh6mypr8wv4d/qOr2i9Qt6FcmBR/Hxv/Jo3f5hejJ4VGa01erFjrWHM8Ox2n9YgOlVuBAdXqvEw4S0SiRP76/zGegi8Jx5fF77+tT0D4lgzEq/mIVSdz21lAqr1E/VhaD/AqVmZ6kTzu6XNF09mazcEP+BF0o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300381; c=relaxed/simple; bh=jlnQChbr8HUhHwG/JR8f/1rKBO3Lt3uODy66onsJy7M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TxUXwNeimmhn5HFQLg7/HvfPh3WdPDzRoLYmjKbM5xcSbk7skjO9IEbhGFnyrT957rcQ50ssQO4tdJw2YVA55wrGkPMnsCsl4KjUV5KKkFGpU4H05K6GCXFN5AnUhxRvCGU7tDHwMFNuqLM+8l6LKpLT2Rq+NX86xzWrLzb2/90= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hV4UJ8i3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hV4UJ8i3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A26C5C19423; Sat, 28 Feb 2026 17:39:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300381; bh=jlnQChbr8HUhHwG/JR8f/1rKBO3Lt3uODy66onsJy7M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hV4UJ8i3EB7d/x51xtNK8cDDfaSBiBBR+nlUDW4L2Cjcv/ZQmvUYsfuy365HLFnQ3 uHjBye0dc25KmMbjIsDFj16DVasWbKEAjfidA8jN6yW/NwLZDg7DA62LYywPjttIkN /nG1rqRPcVPsQmQEjL5OoH88KLh8gybHbP8ksVt35Uuv4luNzfRzLFugbLhv0wKU0W mGOjZ2bz+iVrSVinNdQFbqqAf1pJoG46fNp+nDbQERAiyPtjYfsk9ynb7teBlJQAsh 6U73kU3WWbwAr4nbfC9RAxFCv5S+TkHvQ2RtXHZQpWYHsHVR0LElI1Q0AOhDDzLa4g 9TWHkDVDbyWUQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lijo Lazar , Mangesh Gadre , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 417/844] drm/amdgpu: Skip vcn poison irq release on VF Date: Sat, 28 Feb 2026 12:25:30 -0500 Message-ID: <20260228173244.1509663-418-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lijo Lazar [ Upstream commit 8980be03b3f9a4b58197ef95d3b37efa41a25331 ] VF doesn't enable VCN poison irq in VCNv2.5. Skip releasing it and avoid call trace during deinitialization. [ 71.913601] [drm] clean up the vf2pf work item [ 71.915088] ------------[ cut here ]------------ [ 71.915092] WARNING: CPU: 3 PID: 1079 at /tmp/amd.aFkFvSQl/amd/amdgpu/am= dgpu_irq.c:641 amdgpu_irq_put+0xc6/0xe0 [amdgpu] [ 71.915355] Modules linked in: amdgpu(OE-) amddrm_ttm_helper(OE) amdttm(= OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) dr= m_suballoc_helper drm_display_helper cec rc_core i2c_algo_bit video wmi bin= fmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common input_leds joydev s= erio_raw mac_hid qemu_fw_cfg sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh= _emc scsi_dh_alua efi_pstore ip_tables x_tables autofs4 btrfs blake2b_gener= ic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_t= x xor raid6_pq libcrc32c raid1 raid0 hid_generic crct10dif_pclmul crc32_pcl= mul polyval_clmulni polyval_generic ghash_clmulni_intel usbhid 8139too sha2= 56_ssse3 sha1_ssse3 hid psmouse bochs i2c_i801 ahci drm_vram_helper libahci= i2c_smbus lpc_ich drm_ttm_helper 8139cp mii ttm aesni_intel crypto_simd cr= yptd [ 71.915484] CPU: 3 PID: 1079 Comm: rmmod Tainted: G OE 6.= 8.0-87-generic #88~22.04.1-Ubuntu [ 71.915489] Hardware name: Red Hat KVM/RHEL, BIOS 1.16.3-2.el9_5.1 04/01= /2014 [ 71.915492] RIP: 0010:amdgpu_irq_put+0xc6/0xe0 [amdgpu] [ 71.915768] Code: 75 84 b8 ea ff ff ff eb d4 44 89 ea 48 89 de 4c 89 e7 = e8 fd fc ff ff 5b 41 5c 41 5d 41 5e 5d 31 d2 31 f6 31 ff e9 55 30 3b c7 <0f= > 0b eb d4 b8 fe ff ff ff eb a8 e9 b7 3b 8a 00 66 2e 0f 1f 84 00 [ 71.915771] RSP: 0018:ffffcf0800eafa30 EFLAGS: 00010246 [ 71.915775] RAX: 0000000000000000 RBX: ffff891bda4b0668 RCX: 00000000000= 00000 [ 71.915777] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000= 00000 [ 71.915779] RBP: ffffcf0800eafa50 R08: 0000000000000000 R09: 00000000000= 00000 [ 71.915781] R10: 0000000000000000 R11: 0000000000000000 R12: ffff891bda4= 80000 [ 71.915782] R13: 0000000000000000 R14: 0000000000000001 R15: 00000000000= 00000 [ 71.915792] FS: 000070cff87c4c40(0000) GS:ffff893abfb80000(0000) knlGS:= 0000000000000000 [ 71.915795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 71.915797] CR2: 00005fa13073e478 CR3: 000000010d634006 CR4: 00000000007= 70ef0 [ 71.915800] PKRU: 55555554 [ 71.915802] Call Trace: [ 71.915805] [ 71.915809] vcn_v2_5_hw_fini+0x19e/0x1e0 [amdgpu] Signed-off-by: Lijo Lazar Reviewed-by: Mangesh Gadre Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c b/drivers/gpu/drm/amd/am= dgpu/vcn_v2_5.c index cebee453871c1..006a154511971 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c @@ -521,7 +521,9 @@ static int vcn_v2_5_hw_fini(struct amdgpu_ip_block *ip_= block) RREG32_SOC15(VCN, i, mmUVD_STATUS))) vinst->set_pg_state(vinst, AMD_PG_STATE_GATE); =20 - if (amdgpu_ras_is_supported(adev, AMDGPU_RAS_BLOCK__VCN)) + /* VF doesn't enable interrupt operations for RAS */ + if (!amdgpu_sriov_vf(adev) && + amdgpu_ras_is_supported(adev, AMDGPU_RAS_BLOCK__VCN)) amdgpu_irq_put(adev, &vinst->ras_poison_irq, 0); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84E1E3C85FC; Sat, 28 Feb 2026 17:39:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300382; cv=none; b=p2+VNtfGkBvQz/UMdXrM80dz3xCFx2ORt3aBpJODafu+iAQVwI+3zJY+TdELZ262uD9gdTd1NstNHIOiOfsWBCXkgs34egeR4uspnbvp45s6R6OaDHHUDGtGjPA/GeTw5PuyBKNFEaOCTIUvVYLs0v1vxsnT1VAbVG5CqNgR94A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300382; c=relaxed/simple; bh=l9iocyxtMSRJtf9FMoPMF9SpeSmJIAfbepK3rtVppNU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dptaWZ1vhWhl1gNyEPEaj74e+L7nDshrIulQxZ82enbEbmeFRjpQSy6rty2PJ+DicrEThXIKYtcvJrS+ZRuLYAcqAn+Xg0hR9EWUmf7fM3Zfy20pHkVtV85mTc0BN92o0tE87ob5CsqB3Ro53CkX5WVc9K3LwNBu9a4BNGrqdHQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UHrMx3+m; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UHrMx3+m" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9119BC19423; Sat, 28 Feb 2026 17:39:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300382; bh=l9iocyxtMSRJtf9FMoPMF9SpeSmJIAfbepK3rtVppNU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UHrMx3+mUzmaAy+T9fEvO4u6arHq2/4oV+DW7oO+kyLykRHQEIKxXRY3aC1Yczpx7 bHQs4Df5+6sVHA2YdNa0TVOo+nmvpjzavXVAEuaGNHVsf+21FPno8oQpEHANP4mAsh /FZvR2lkazDN8geB1Mna2CVVngM1J3gGrPO/LWi3J29x1WqFIo9lyf1hWAJK+0kJdq klnY8YCvAK7pT9nlSZF8D6KaPuak9ccKEBzzjGrQMkomv5k2NrnBoHKrH4r+Em0RDY 3DccAHcJhEI0U8IROEWgWomV8KMryv2iqLgrRajPznYEsLfLRfEftGoc10ir7V+/d8 PT7ScsEeF3kwQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Purna Pavan Chandra Aekkaladevi , Nuno Das Neves , Stanislav Kinsburskii , Michael Kelley , Wei Liu , Sasha Levin Subject: [PATCH 6.19 418/844] mshv: Ignore second stats page map result failure Date: Sat, 28 Feb 2026 12:25:31 -0500 Message-ID: <20260228173244.1509663-419-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Purna Pavan Chandra Aekkaladevi [ Upstream commit 7538b80e5a4b473b73428d13b3a47ceaad9a8a7c ] Older versions of the hypervisor do not have a concept of separate SELF and PARENT stats areas. In this case, mapping the HV_STATS_AREA_SELF page is sufficient - it's the only page and it contains all available stats. Mapping HV_STATS_AREA_PARENT returns HV_STATUS_INVALID_PARAMETER which currently causes module init to fail on older hypevisor versions. Detect this case and gracefully fall back to populating stats_pages[HV_STATS_AREA_PARENT] with the already-mapped SELF page. Add comments to clarify the behavior, including a clarification of why this isn't needed for hv_call_map_stats_page2() which always supports PARENT and SELF areas. Signed-off-by: Purna Pavan Chandra Aekkaladevi Signed-off-by: Nuno Das Neves Reviewed-by: Stanislav Kinsburskii Acked-by: Stanislav Kinsburskii Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hv/mshv_root_hv_call.c | 52 +++++++++++++++++++++++++++++++--- drivers/hv/mshv_root_main.c | 3 ++ 2 files changed, 51 insertions(+), 4 deletions(-) diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c index 598eaff4ff299..1f93b94d7580c 100644 --- a/drivers/hv/mshv_root_hv_call.c +++ b/drivers/hv/mshv_root_hv_call.c @@ -813,6 +813,13 @@ hv_call_notify_port_ring_empty(u32 sint_index) return hv_result_to_errno(status); } =20 +/* + * Equivalent of hv_call_map_stats_page() for cases when the caller provid= es + * the map location. + * + * NOTE: This is a newer hypercall that always supports SELF and PARENT st= ats + * areas, unlike hv_call_map_stats_page(). + */ static int hv_call_map_stats_page2(enum hv_stats_object_type type, const union hv_stats_object_identity *identity, u64 map_location) @@ -855,6 +862,34 @@ static int hv_call_map_stats_page2(enum hv_stats_objec= t_type type, return ret; } =20 +static int +hv_stats_get_area_type(enum hv_stats_object_type type, + const union hv_stats_object_identity *identity) +{ + switch (type) { + case HV_STATS_OBJECT_HYPERVISOR: + return identity->hv.stats_area_type; + case HV_STATS_OBJECT_LOGICAL_PROCESSOR: + return identity->lp.stats_area_type; + case HV_STATS_OBJECT_PARTITION: + return identity->partition.stats_area_type; + case HV_STATS_OBJECT_VP: + return identity->vp.stats_area_type; + } + + return -EINVAL; +} + +/* + * Map a stats page, where the page location is provided by the hypervisor. + * + * NOTE: The concept of separate SELF and PARENT stats areas does not exis= t on + * older hypervisor versions. All the available stats information can be f= ound + * on the SELF page. When attempting to map the PARENT area on a hypervisor + * that doesn't support it, return "success" but with a NULL address. The + * caller should check for this case and instead fallback to the SELF area + * alone. + */ static int hv_call_map_stats_page(enum hv_stats_object_type type, const union hv_stats_object_identity *identity, void **addr) @@ -863,7 +898,7 @@ static int hv_call_map_stats_page(enum hv_stats_object_= type type, struct hv_input_map_stats_page *input; struct hv_output_map_stats_page *output; u64 status, pfn; - int ret =3D 0; + int hv_status, ret =3D 0; =20 do { local_irq_save(flags); @@ -878,11 +913,20 @@ static int hv_call_map_stats_page(enum hv_stats_objec= t_type type, pfn =3D output->map_location; =20 local_irq_restore(flags); - if (hv_result(status) !=3D HV_STATUS_INSUFFICIENT_MEMORY) { - ret =3D hv_result_to_errno(status); + + hv_status =3D hv_result(status); + if (hv_status !=3D HV_STATUS_INSUFFICIENT_MEMORY) { if (hv_result_success(status)) break; - return ret; + + if (hv_stats_get_area_type(type, identity) =3D=3D HV_STATS_AREA_PARENT = && + hv_status =3D=3D HV_STATUS_INVALID_PARAMETER) { + *addr =3D NULL; + return 0; + } + + hv_status_debug(status, "\n"); + return hv_result_to_errno(status); } =20 ret =3D hv_call_deposit_pages(NUMA_NO_NODE, diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c index 681b58154d5ea..d3e8a66443ad6 100644 --- a/drivers/hv/mshv_root_main.c +++ b/drivers/hv/mshv_root_main.c @@ -993,6 +993,9 @@ static int mshv_vp_stats_map(u64 partition_id, u32 vp_i= ndex, if (err) goto unmap_self; =20 + if (!stats_pages[HV_STATS_AREA_PARENT]) + stats_pages[HV_STATS_AREA_PARENT] =3D stats_pages[HV_STATS_AREA_SELF]; + return 0; =20 unmap_self: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F64E3C8612; Sat, 28 Feb 2026 17:39:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300383; cv=none; b=BoJYRLLgP8H4nswi6tzGfV/gVFh9KWp246bmo7zfzz8G4gThS8oz1u3yacnfQKAr4D3PIbgYtksPp6cLMZk9o/HMpKxEBrpsj9ftY3kGMf6IxiBW0aqkm9ciwXrNXBIZcEwhkenm+hZmxCvbWm3o3iNaQ0xO1TkacNZTnYzvQ/4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300383; c=relaxed/simple; bh=FESLrKIy69xsfGW/tTxfnfUnMZGuw9zNEDOrNDVSBQ8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WlmlQVkaaN8xp9Q1cM3drKVhkLM42DW7TH0tTCNLJD5Eq1QYARZmX2qFvgv8DOD8nusab/DOOMrY8t7PFhJjEmDD8Fb36kAk30WfFFq1JlPCtIQ3pSwDEwb5ujW1JocgMm7G49KDLebLaMDtFtWaLk6sLS6X8tS4krsHAQJIzkw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TE2PGgmc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TE2PGgmc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD112C116D0; Sat, 28 Feb 2026 17:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300383; bh=FESLrKIy69xsfGW/tTxfnfUnMZGuw9zNEDOrNDVSBQ8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TE2PGgmc/6og8rA0vC5XKRvs1OOesnvyz4DKzgbjLIxoGwkun2ONEF+YM6LfOpgMd +Dk0tcWn4iaM/B6+EQi0vaXuuZGytSD1TPLZGzT9WYqu0KDI252JaJjXV7KfoLLIFy 2TYzKMzVu84YKk9hGUQvkj8AbJlXxcBDu3+SAybDh4RhefJOIgGt5XDZ9fCagfG7Ts OjmkLwOAmjOA+HsFjJ34PVS3gzT/2u6vs7iw86alhYyDBNnodKckrhyZ7onXk0XGNt /Ok8uGkLDALG25vZIdQHvXO0tXLo8g87IcyzaduLanYkIanLESlnM1MflEIDkt367v tOcnSHM5VqPlA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mukesh R , Wei Liu , Sasha Levin Subject: [PATCH 6.19 419/844] x86/hyperv: Move hv crash init after hypercall pg setup Date: Sat, 28 Feb 2026 12:25:32 -0500 Message-ID: <20260228173244.1509663-420-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mukesh R [ Upstream commit c3a6ae7ea2d3f507cbddb5818ccc65b9d84d6dc7 ] hv_root_crash_init() is not setting up the hypervisor crash collection for baremetal cases because when it's called, hypervisor page is not setup. Fix is simple, just move the crash init call after the hypercall page setup. Signed-off-by: Mukesh Rathor Signed-off-by: Wei Liu Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/hyperv/hv_init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index 14de43f4bc6c1..7f3301bd081ec 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -558,7 +558,6 @@ void __init hyperv_init(void) memunmap(src); =20 hv_remap_tsc_clocksource(); - hv_root_crash_init(); hv_sleep_notifiers_register(); } else { hypercall_msr.guest_physical_address =3D vmalloc_to_pfn(hv_hypercall_pg); @@ -567,6 +566,9 @@ void __init hyperv_init(void) =20 hv_set_hypercall_pg(hv_hypercall_pg); =20 + if (hv_root_partition()) /* after set hypercall pg */ + hv_root_crash_init(); + skip_hypercall_pg_init: /* * hyperv_init() is called before LAPIC is initialized: see --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B7EC481A81; Sat, 28 Feb 2026 17:39:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300384; cv=none; b=VOHIOgoDn6AINVRucoTyx77nFLHqXeRilWOylJhhKIsrFnm3QbvtQOsPzjARIJH7uobgK9JhPMuXHNzNwzg3WR2ER4upk8acDD9s5bHz+UH1aDDpx4ItjI1h/4G7GhdXEJs5b252EqgUgKHnqJKR1bmmqm5CFSy7GOQ7hSqbZz8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300384; c=relaxed/simple; bh=DnlNZrpKdXMCrmj9gg1iXz58tbdOuYJMJUcu+H4F/CU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MSqa2e7d06P5kaw1BdclGIRxN3UsXi7ybCv62TjSpfyX8S2mnBEf1+1OU9pFzTb5bbhQJVchPba+ziMJnAcqdoZluBfrEIqSQ61Ahrbjnc5bZbtTMrjkMWD+8PeQeHz0/bd7EMw83pf1L4mjGmbfp/Uo4BDCtP4C8Sv3uW8K3Fw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MirafwV2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MirafwV2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86786C19425; Sat, 28 Feb 2026 17:39:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300384; bh=DnlNZrpKdXMCrmj9gg1iXz58tbdOuYJMJUcu+H4F/CU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MirafwV2ESGkYmlFSTm7x9O1POtz1J2kEaGy/kL/DRWXm2tIKo8dGGEFC61PL/s8J KoW5XLBSAqLrUkLrrNiwmbBcMZddajgFrSJfzZQabzH8Vg8o+w951wXBZ+QZ7C9NJb 3se/MPNOLY8mXQV+gFeymeGzMb+RxNkwlvywT8YSVLG0yFRosLIXjA3yVyB65ZVoAc Bg/kglwg6qirlOiOsGPZ/1LjP/Wzb/DHX1tsVv+b1KOfkeIDQqyZo8uggQl987qXbR RNDM8dUxiG7Zif+FIp/yNoSZdxR2ADkgF8tUzHTd0TxvoCICY3OM69MDWiCAD+qMLh H8KT43PbdrITw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Carlos=20L=C3=B3pez?= , Wei Liu , Sasha Levin Subject: [PATCH 6.19 420/844] mshv: clear eventfd counter on irqfd shutdown Date: Sat, 28 Feb 2026 12:25:33 -0500 Message-ID: <20260228173244.1509663-421-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Carlos L=C3=B3pez [ Upstream commit 2b4246153e2184e3a3b4edc8cc35337d7a2455a6 ] While unhooking from the irqfd waitqueue, clear the internal eventfd counter by using eventfd_ctx_remove_wait_queue() instead of remove_wait_queue(), preventing potential spurious interrupts. This removes the need to store a pointer into the workqueue, as the eventfd already keeps track of it. This mimicks what other similar subsystems do on their equivalent paths with their irqfds (KVM, Xen, ACRN support, etc). Signed-off-by: Carlos L=C3=B3pez Signed-off-by: Wei Liu Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hv/mshv_eventfd.c | 5 ++--- drivers/hv/mshv_eventfd.h | 1 - 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/hv/mshv_eventfd.c b/drivers/hv/mshv_eventfd.c index 6d176ed8ae516..188923fce40b4 100644 --- a/drivers/hv/mshv_eventfd.c +++ b/drivers/hv/mshv_eventfd.c @@ -248,12 +248,13 @@ static void mshv_irqfd_shutdown(struct work_struct *w= ork) { struct mshv_irqfd *irqfd =3D container_of(work, struct mshv_irqfd, irqfd_shutdown); + u64 cnt; =20 /* * Synchronize with the wait-queue and unhook ourselves to prevent * further events. */ - remove_wait_queue(irqfd->irqfd_wqh, &irqfd->irqfd_wait); + eventfd_ctx_remove_wait_queue(irqfd->irqfd_eventfd_ctx, &irqfd->irqfd_wai= t, &cnt); =20 if (irqfd->irqfd_resampler) { mshv_irqfd_resampler_shutdown(irqfd); @@ -372,8 +373,6 @@ static void mshv_irqfd_queue_proc(struct file *file, wa= it_queue_head_t *wqh, struct mshv_irqfd *irqfd =3D container_of(polltbl, struct mshv_irqfd, irqfd_polltbl); =20 - irqfd->irqfd_wqh =3D wqh; - /* * TODO: Ensure there isn't already an exclusive, priority waiter, e.g. * that the irqfd isn't already bound to another partition. Only the diff --git a/drivers/hv/mshv_eventfd.h b/drivers/hv/mshv_eventfd.h index 332e7670a3442..464c6b81ab336 100644 --- a/drivers/hv/mshv_eventfd.h +++ b/drivers/hv/mshv_eventfd.h @@ -32,7 +32,6 @@ struct mshv_irqfd { struct mshv_lapic_irq irqfd_lapic_irq; struct hlist_node irqfd_hnode; poll_table irqfd_polltbl; - wait_queue_head_t *irqfd_wqh; wait_queue_entry_t irqfd_wait; struct work_struct irqfd_shutdown; struct mshv_irqfd_resampler *irqfd_resampler; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1900F3C8F59; Sat, 28 Feb 2026 17:39:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300385; cv=none; b=HkKqfCzZAaQAgdW92YEUXcWXx5c7VgkZATgAdn9go8tS9z/yp5A6fH8BA2cvEWqvZcKZCp3g5JStOvKXnuzzgo6x/cVT6tijb+PxWEeKt4DJv9hAkzDjJej/GsTUtZ6esVNSVn7d++3egUe9I9plEN+3lPitCSStl2MyxyNkqBU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300385; c=relaxed/simple; bh=XZc44cBv0slfjRfWU5Sg3CT6rJjxxRymbEQGtCUh0eQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TedA9yEkxASx+vgWLqZSCInGYaQtBnty3vLZx1TUK5fd4BJV1WKWv/+XDZbimfN302L42Akel+8DbOkK3tKhQnWplaI5EkzpxonLtlwdE/8Txcx7WKEJA/8hAgCEQOkhKcihRqdgOGrH2r8vdWqyUtJnjqhiz7KkUdwq00gKngY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZfWBLxB3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZfWBLxB3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63EA4C19423; Sat, 28 Feb 2026 17:39:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300385; bh=XZc44cBv0slfjRfWU5Sg3CT6rJjxxRymbEQGtCUh0eQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZfWBLxB3MzqculhVQ7gVAT3iMD0Bf+ewxlCc0Rhkt656UvjpPVTqgm4OtpXoaQBJU l8LKFz8xiAwcekjCMYWNjTe51VR70n6uH7nsuGfGbDf8RukK600eOCfYjOreKozGFn 36LmGQ+EBm7ioiD54F3vU8A/poJlRCaxbWkBwUI9sBJWaklG6dvUpZebtK/BzdInP5 uZFbTG+IZa+MpLHCCiPmpEml0fxjpQxkCP8q1HnCORM5+YDEOttroD7jXbMPShBUTX +QC1gQ4z5lkZCDLIZXWqfFmEzpXI36OwmjseoDRPF1BZ0tKwULWRnhL9ZkdVC44JCy Q3t7lZh97PSOw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jack Yu , Mark Brown , Sasha Levin Subject: [PATCH 6.19 421/844] ASoC: rt721-sdca: Fix issue of fail to detect OMTP jack type Date: Sat, 28 Feb 2026 12:25:34 -0500 Message-ID: <20260228173244.1509663-422-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jack Yu [ Upstream commit 5578da7d957fbaf91f6c39ba2363c2d2e4273183 ] Add related HP-JD settings to fix issue of fail to detect OMTP jack type. Signed-off-by: Jack Yu Link: https://patch.msgid.link/20260210074335.2337830-1-jack.yu@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/codecs/rt721-sdca.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/rt721-sdca.c b/sound/soc/codecs/rt721-sdca.c index 8233532a1752a..35960c2252249 100644 --- a/sound/soc/codecs/rt721-sdca.c +++ b/sound/soc/codecs/rt721-sdca.c @@ -245,12 +245,12 @@ static void rt721_sdca_jack_preset(struct rt721_sdca_= priv *rt721) regmap_write(rt721->mbq_regmap, 0x5b10007, 0x2000); regmap_write(rt721->mbq_regmap, 0x5B10017, 0x1b0f); rt_sdca_index_write(rt721->mbq_regmap, RT721_CBJ_CTRL, - RT721_CBJ_A0_GAT_CTRL1, 0x2a02); + RT721_CBJ_A0_GAT_CTRL1, 0x2205); rt_sdca_index_write(rt721->mbq_regmap, RT721_CAP_PORT_CTRL, RT721_HP_AMP_2CH_CAL4, 0xa105); rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL, RT721_UAJ_TOP_TCON14, 0x3b33); - regmap_write(rt721->mbq_regmap, 0x310400, 0x3023); + regmap_write(rt721->mbq_regmap, 0x310400, 0x3043); rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL, RT721_UAJ_TOP_TCON14, 0x3f33); rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EAB633C8F78; Sat, 28 Feb 2026 17:39:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300386; cv=none; b=duQqglijOLzhOcUfgSGiL/wQK/ECnXk+w6PvTyM3/sjBZIUybiUXbI2f0M9GHnAJ68g0g/hTSRTRx0RES2yuwYoZgciM/U86OOaCUgVpiLeveb5DxB22Pqw7YDSjFxi5ZsDTT68rudxrs1eqryBZXO9fE17ewbNeEVe1JivEHAA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300386; c=relaxed/simple; bh=rdw9fSOL60NnHL7PQnfza4CqIrfGPbXzoQmTbqEaQ/4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VRJ3P18zjB3OZ+2U7XBtBCWq/pH4uLmUUZLKci3msHqNbfHWCvA06j6GMCKR7mI/2TKUqSqv7QSkj/MMriJ8u2Pjws6Mpk6KSNOENSsELo/UVY38Ds875Il1EUlSlmmRZFfYALTwM0fwqUeUQAHo8YO4KRDHWY49bSvWKbK9OBo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MTcTCP54; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MTcTCP54" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EAE4C116D0; Sat, 28 Feb 2026 17:39:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300385; bh=rdw9fSOL60NnHL7PQnfza4CqIrfGPbXzoQmTbqEaQ/4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MTcTCP547oOfm5JnLBtygwdbi+pJVAOe2I6Grwjzud20HcRAbzXBIrBKrlEPnS1I1 UUF9YSheSalTIVnnuPX53GuzDY4bLovvfuHwwL+eTWcZLV8HHBssCkvSz0Y8CBFmBa CfY6N1aw9X0hW6Yygtr1vplxUr+hjOlfFJdGlfBuq+IkHuFzrG2I1TMXuoMwLqjwth zepQGYo8bnRrfFWPkl4GVGV9U9oHsf4Mi8EbzYX7QT+rRlLdH8NPj4qEGzlRZOFUP9 he2axz96J5PZCUmqhLboSzMmrFI+IWhJbQoyiaN7R007waWW/3iXL0cnjkIg/IjGQp eRm5s7Dl/mLoQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bjorn Andersson , Mark Brown , Sasha Levin Subject: [PATCH 6.19 422/844] regulator: core: Remove regulator supply_name length limit Date: Sat, 28 Feb 2026 12:25:35 -0500 Message-ID: <20260228173244.1509663-423-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bjorn Andersson [ Upstream commit e243cdd87b911ce9968b62e4ab2b680dfadc4341 ] When creating the regulator object, associated with a consumer device, the supply_name is string formatted into a statically sized buffer on the stack, then strdup()'ed onto the heap. Not only is the dance on the stack unnecessary, but when the device's name is long we might not fit the constructed supply_name in the fixed 64 byte buffer on the stack. One such case can be seen on the Qualcomm Rb3Gen2 board, where we find a PCIe controller, with a PCIe switch, with a USB controller, with a USB hub, consuming a regulator. In this example the dev->kobj.name itself is 62 characters long. Drop the temporary buffer on the stack and kasprintf() the string directly on the heap, both to simplify the code, and to remove the length limitation. Signed-off-by: Bjorn Andersson Link: https://patch.msgid.link/20260211-regulator-supply-name-length-v1-1-3= 875541c1576@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/regulator/core.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 8ee33b777f6ce..838bbdcdede9a 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1949,8 +1949,6 @@ static const struct file_operations constraint_flags_= fops =3D { #endif }; =20 -#define REG_STR_SIZE 64 - static void link_and_create_debugfs(struct regulator *regulator, struct re= gulator_dev *rdev, struct device *dev) { @@ -1998,15 +1996,7 @@ static struct regulator *create_regulator(struct reg= ulator_dev *rdev, lockdep_assert_held_once(&rdev->mutex.base); =20 if (dev) { - char buf[REG_STR_SIZE]; - int size; - - size =3D snprintf(buf, REG_STR_SIZE, "%s-%s", - dev->kobj.name, supply_name); - if (size >=3D REG_STR_SIZE) - return NULL; - - supply_name =3D kstrdup(buf, GFP_KERNEL); + supply_name =3D kasprintf(GFP_KERNEL, "%s-%s", dev->kobj.name, supply_na= me); if (supply_name =3D=3D NULL) return NULL; } else { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5AB63C97AA; Sat, 28 Feb 2026 17:39:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300386; cv=none; b=RNUpqOVhJuovjAML/+RCdtKhZVHmmoY81QbHJJKOSh8pKl4inZwaFnVdnw5lKZwz20in1iCnHQgGSODMTJKUYaUFMcqQRNKEapzPFImAiv45zZD02ZZBpnTBu+UjlLXPzn8EcjMakOs4PT9X1ZBPLhtILoyx5CyE6wDWzk/JIKw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300386; c=relaxed/simple; bh=6Qso9r6u69JTBCvIc5ianu2/g1XD02SfiWBTrKGkfMM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Wc5sBfSsxovb+g/gQa1GAt4in7uDK+Df0f9PWL5gU/TYVM6qjMrvdcjHQTOUwm5oBut7i3oQAGBVSo6DuxqaPN85G3GdkLVoTdCvXcdQTdO8vi5EjNfeLsSQoFmcKwL4K3cK+5Y//n8uoU/5E/aY8gd6RKg0/VfzkIOAR/d+zGU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Q5ambMn7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Q5ambMn7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AEABC116D0; Sat, 28 Feb 2026 17:39:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300386; bh=6Qso9r6u69JTBCvIc5ianu2/g1XD02SfiWBTrKGkfMM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q5ambMn7lLMBbTWEBNazXGfaLngcQnnxKrZ15KN4ZQyHqKGqyVCPsy6rgt968N8zM gkK/VXNdE1ctzxW7CVzxL6IaQXI0E+eO1auuQcJN37WfBv834aP/uOiRm51519tIPl uej8Elgnr7yrTBmdC6mFyAYPkx6biC8Y/DJJxDC1fRAnHaANI9/dXcki5MVbrW2szW cZrnLHoAMQ24IZ3ItxDxpQV5qT7JzS8ixf8XokgfDkVXwdHpfaCGzv313LFyRhPc/q GjAGQZyNeB09mZyTNIeKe99g7HdlVBD9ldohZhvr9IvBynmeOYEl/DHmPOZFe75hc2 KLc+rAP6blq4g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Baojun Xu , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 423/844] ALSA: hda/tas2781: Ignore reset check for SPI device Date: Sat, 28 Feb 2026 12:25:36 -0500 Message-ID: <20260228173244.1509663-424-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Baojun Xu [ Upstream commit 908ef80e31e4d3bd953a0088fe57640cd9ae7b3e ] In the SPI driver probe, the device should be in the default state, so the device status check is not necessary. It should be forced to do the firmware download as I2C device. Signed-off-by: Baojun Xu Link: https://patch.msgid.link/20260211030946.2330-1-baojun.xu@ti.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../hda/codecs/side-codecs/tas2781_hda_spi.c | 20 +++++++------------ 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_spi.c b/sound/hda/cod= ecs/side-codecs/tas2781_hda_spi.c index b9a55672bf15d..488e35dac9524 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_spi.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_spi.c @@ -634,7 +634,7 @@ static void tasdev_fw_ready(const struct firmware *fmw,= void *context) struct tasdevice_priv *tas_priv =3D context; struct tas2781_hda *tas_hda =3D dev_get_drvdata(tas_priv->dev); struct hda_codec *codec =3D tas_priv->codec; - int ret, val; + int ret; =20 pm_runtime_get_sync(tas_priv->dev); guard(mutex)(&tas_priv->codec_lock); @@ -673,20 +673,14 @@ static void tasdev_fw_ready(const struct firmware *fm= w, void *context) tas_priv->rcabin.profile_cfg_id =3D 0; =20 tas_priv->fw_state =3D TASDEVICE_DSP_FW_ALL_OK; - ret =3D tasdevice_spi_dev_read(tas_priv, tas_priv->index, - TAS2781_REG_CLK_CONFIG, &val); - if (ret < 0) - goto out; =20 - if (val =3D=3D TAS2781_REG_CLK_CONFIG_RESET) { - ret =3D tasdevice_prmg_load(tas_priv, 0); - if (ret < 0) { - dev_err(tas_priv->dev, "FW download failed =3D %d\n", - ret); - goto out; - } - tas_priv->fw_state =3D TASDEVICE_DSP_FW_ALL_OK; + ret =3D tasdevice_prmg_load(tas_priv, 0); + if (ret < 0) { + dev_err(tas_priv->dev, "FW download failed =3D %d\n", ret); + goto out; } + tas_priv->fw_state =3D TASDEVICE_DSP_FW_ALL_OK; + if (tas_priv->fmw->nr_programs > 0) tas_priv->tasdevice[tas_priv->index].cur_prog =3D 0; if (tas_priv->fmw->nr_configurations > 0) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFAD73C97CC; Sat, 28 Feb 2026 17:39:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300387; cv=none; b=BBSuJoC/AUZqfBNoGxyZTDTxvxhIC3HCofPuSmt7akwZ/uW6WgFrEhW4JnDN08j9SwRcdeZWtKZS/NODL6x46UYBittb8jQZgYAg2Y4umgLsqmtzKsHZIf1ovwbLji/0hW3CTcC4B/HLIBDL1DNFfQR6TkePzWkhJBf3YWc0WM4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300387; c=relaxed/simple; bh=BTDRynjVjWjEDGWUKmJuV6dDV3tt2Q+2Vr7hjJwaa1o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MCtGQq7Yr0t6kMuxDbzlnAUX28u3WfE2MdbyYLtOUawM1Swg2fKHPg6VcWa72mUFj0m5GHLO9aeFVWndRVaqYCOJSSpB+dxuemmwk2jmVos1YvuguFKdXUio3SbAo7ab4XChP946dvOy+s33WjILtoamRzSwJ1nqjFLGycdT03I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O9q99RXb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O9q99RXb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC98DC2BCB0; Sat, 28 Feb 2026 17:39:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300387; bh=BTDRynjVjWjEDGWUKmJuV6dDV3tt2Q+2Vr7hjJwaa1o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O9q99RXbYmEumK6CQfapBxsWsR9cl3NsPrh3rNV6MZTIe/aTWKOfOjgmRedTtd/cf RKTYTKvjdcvWBWTqD0gsha3TXorhtVGj64spMqLdkt8tcy9plU82WJkgeBfarTiUTJ N88SkR3WQacvOkPPUPmh/Cx7nq727zHgdz9g0zgEqfO5x4AixON0814mrctNLeXv95 wMw4nt2g546mmgrtjjJxH2xhM+GKfg4+n7H/w70wUC0uXjIc1/ejV/tX5xmy3uXwvb UCsE5sBVJ9+5EdzbLwn80+6U5KpBo7OqJn4Z3HtWkh1JLcOugakGIFMZRR3fkqu8Df YATwhoUOQSo4Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tom Chung , Nicholas Kazlauskas , Wayne Lin , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 424/844] drm/amd/display: Fix system resume lag issue Date: Sat, 28 Feb 2026 12:25:37 -0500 Message-ID: <20260228173244.1509663-425-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tom Chung [ Upstream commit 64c94cd9be2e188ed07efeafa6a109bce638c967 ] [Why] System will try to apply idle power optimizations setting during system resume. But system power state is still in D3 state, and it will cause the idle power optimizations command not actually to be sent to DMUB and cause some platforms to go into IPS. [How] Set power state to D0 first before calling the dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false) Reviewed-by: Nicholas Kazlauskas Signed-off-by: Tom Chung Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gp= u/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 150cc3fc7b2a9..b6eee94861477 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3468,7 +3468,17 @@ static int dm_resume(struct amdgpu_ip_block *ip_bloc= k) struct dc_commit_streams_params commit_params =3D {}; =20 if (dm->dc->caps.ips_support) { + if (!amdgpu_in_reset(adev)) + mutex_lock(&dm->dc_lock); + + /* Need to set POWER_STATE_D0 first or it will not execute + * idle_power_optimizations command to DMUB. + */ + dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, DC_ACPI_CM_POWER_STAT= E_D0); dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false); + + if (!amdgpu_in_reset(adev)) + mutex_unlock(&dm->dc_lock); } =20 if (amdgpu_in_reset(adev)) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 067883C9FA2; Sat, 28 Feb 2026 17:39:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300389; cv=none; b=vDeefqqvQCQVeFqAsaTuJNX7FOi8vHTMa8mvoevpuyxLS7rPQnBeMca6KW77YxbdyJYv7yjuRoh2QWaXWVbNfim6l5zuvLyEsO/l7DoMmgDGhdBf/D4pkEuZNCCFJBCUY7aH4+IjrNb7Ri8/dur0KjpyIzYs6G+H8LeYOa+Enpw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300389; c=relaxed/simple; bh=ywHQZgXUE2dXca+/1j2x1D1sumAvGLhLXQ8vjh723WM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SUI2wZt4bdEvOeV/QxckKF60TFJYkeWmNbUSpPzmXlr41t8xqwdGCmPTjiAH/8e4jn6Too38hbMd423nYt56K6FflmjUACM485GDcPq5hsyeWxgSMcp4b+7WOLS1Cgrpwj3h12qBPet2cl7CGSIA8au15Acv4cGayrAG+CLETug= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M5m8R+WN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M5m8R+WN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12AB0C19423; Sat, 28 Feb 2026 17:39:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300388; bh=ywHQZgXUE2dXca+/1j2x1D1sumAvGLhLXQ8vjh723WM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M5m8R+WNYjg+aucrhvYBRcEqe11X8Zke9Qz4c9QcVg734z2icfsaUVpucyEhxAxAT c5Z1g+9N4BCTCG4J1iCc94IRy3kwSCu8AnQDii+DOvDfbFMu/1c0zyBczrMyHn49Vy fUhglpTFixGTDKIBCi2DswmkO5IrInWZBUKF+XHDBSkd8ETTzbnZeTw0EUzWiH+mTb Rx9e1n8rhjv6y5yJ1Z7LC/akwJU0zwJtmHwy0akPC5Vpm4k8tPp7/sAUImPwREMRm8 RqbqpVVe0ZLWaFagQK6rCDEaKHVQs3m4nWfd/7KlhhZJ+c/h3Cs0THIwIHneU/ciCV 99sHil4YuXcRg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Wayne Lin , Harry Wentland , Tom Chung , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 425/844] drm/amd/display: Avoid updating surface with the same surface under MPO Date: Sat, 28 Feb 2026 12:25:38 -0500 Message-ID: <20260228173244.1509663-426-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wayne Lin [ Upstream commit 1a38ded4bc8ac09fd029ec656b1e2c98cc0d238c ] [Why & How] Although it's dummy updates of surface update for committing stream updates, we should not have dummy_updates[j].surface all indicating to the same surface under multiple surfaces case. Otherwise, copy_surface_update_to_plane() in update_planes_and_stream_state() will update to the same surface only. Reviewed-by: Harry Wentland Signed-off-by: Wayne Lin Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gp= u/drm/amd/display/amdgpu_dm/amdgpu_dm.c index b6eee94861477..e84ec4365ca6b 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -10961,7 +10961,7 @@ static void amdgpu_dm_atomic_commit_tail(struct drm= _atomic_state *state) continue; } for (j =3D 0; j < status->plane_count; j++) - dummy_updates[j].surface =3D status->plane_states[0]; + dummy_updates[j].surface =3D status->plane_states[j]; =20 sort(dummy_updates, status->plane_count, sizeof(*dummy_updates), dm_plane_layer_index_cmp, NULL); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 123F73C9FBD; Sat, 28 Feb 2026 17:39:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300390; cv=none; b=rObg2zKoYQZyLL9K+ZlxKpaqC33SM3S7tUXJd2TIIhg6Qw08Ha9m9Hy5PRawA+n+swgvyw6IHnJ7I/PVqb9lk/VSddSGARiNft0hN/Sqry0C/NwtrR5nAVstBpK7WK7GMj8UQGcoVV1XxR2PamIL+Ya7ldS0bi4wGhkY9eq2kbI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300390; c=relaxed/simple; bh=4GxOB6SFmcshO8Wpj87J+ttVhAfcdXsZRNkgMnA72JA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FpBgTkPc0lgikJ9gyfWtYlg7CbC9PqxhzhaT2lqpgpgmE7GuRqZq47x24qjwSUy9K7umZRDnHOoCqC+c+UP/iyM1nLjX3AI6Ydf2lCrk/ZB7TE6T8b0Yl1PWN3D7JnKJ99W6XxJm9/csRqJfx1sCkBB8J09dyHsWK9ajaHJeaTQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pY6fRwDe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pY6fRwDe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D32EC19423; Sat, 28 Feb 2026 17:39:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300390; bh=4GxOB6SFmcshO8Wpj87J+ttVhAfcdXsZRNkgMnA72JA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pY6fRwDerxCpkgE8Fh9oNQCbvZbo5kijxAvN4nCYa629/JtYgGs0Zw+HVX12lkYZ1 SCb6g9YXLDFkAPNKxDPGQWyV/M3uxtRFayn75op8TMqmbd+ZhOwpiBDQeTz2iL90iB Mglb0JuEU714Zpa/yHroh4GD9mObxvLFPmhEy9a0xtdP1ZLhKyFU3RGMxFEbEsS6nd zmXNclPQbaNYXCEL7175KiMIK63cLZMxWlx2+lSHWBoOOZbnjmbR/HZ74ndMT7FPzs 9rz8EaHuXmbRvFBHV0D4/A3AarDqRwXKDvyCh4tUMHaswC6bHrZ2AW+tQm7gwKPU8g mHCDCNTlb6beQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gangliang Xie , Tao Zhou , Kent Russell , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 426/844] drm/amdgpu: return when ras table checksum is error Date: Sat, 28 Feb 2026 12:25:39 -0500 Message-ID: <20260228173244.1509663-427-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gangliang Xie [ Upstream commit 044f8d3b1fac6ac89c560f61415000e6bdab3a03 ] end the function flow when ras table checksum is error Signed-off-by: Gangliang Xie Reviewed-by: Tao Zhou Reviewed-by: Kent Russell Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c b/drivers/gpu/d= rm/amd/amdgpu/amdgpu_ras_eeprom.c index 64dd7a81bff5f..710a8fe79fccd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c @@ -1701,10 +1701,12 @@ int amdgpu_ras_eeprom_check(struct amdgpu_ras_eepro= m_control *control) } =20 res =3D __verify_ras_table_checksum(control); - if (res) + if (res) { dev_err(adev->dev, "RAS table incorrect checksum or error:%d\n", res); + return -EINVAL; + } =20 /* Warn if we are at 90% of the threshold or above */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 02FB23C9FD9; Sat, 28 Feb 2026 17:39:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300391; cv=none; b=LjV5Dwt7xE42U600ncdPZ3yYRBRMc5akRXMPT8Sxkrjq2dG4IsR6cLCyhOrDCgH6UXrMRvYovL446Qi2KTaC0suDTdUHfZfviD5rFhzdC8VxbjGfZ5GX4yVawniLBe75FUet1MXDjY15gZA4wx60oM3DEarDCOMK6rKulmavcso= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300391; c=relaxed/simple; bh=amOzwzQjItQiIy9ZvowQ6ojMd3CQtr0MIAbVNTIUAj4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qtlhquNQPIhJ4vxEG3S7QzLXc7F6Z/cH8vPKiqt6QmWe+4NK24+IxW6UTMRrypiaDORkKm1kP5zDr0LbokMY/83MLm8J9gIbby9MppFvl42Iy+u+YXZk/Xlq6PBPLfhF+zdI3peQvB6da3ItCENfCzsHzSOEj9U7K532RytsYEI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cSDg/mF4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cSDg/mF4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 387FAC19424; Sat, 28 Feb 2026 17:39:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300390; bh=amOzwzQjItQiIy9ZvowQ6ojMd3CQtr0MIAbVNTIUAj4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cSDg/mF4ldvhuWSMMocETZtymmtswGZ32SLCogg4NTC7Sp/5wCIpKFCf3m0mEM6z5 nC1ClTBJJtrRGcXA2rxk0WiPYM57ngVs+A28WGo8JEqkkr7mXc5Gf7FmwxmThSt/o3 DQq8eDvlKRUEBM5Y8ttlHUSas1vvVNDBcJaD/HGY1+C8YeFTzklBOH1t0Ko/1oBk69 q0xcihhi0ViyHTsSlkz9+XvJFGBkgZClVbrSNX4mzIE1l7zdARm9VIzFK6yRpjHSHt Zz/4jjMfN+6UH7M/o+miEe/CZgXZ3E6Qaud4NR0CeeOGdIYtWSW1bkPnR+OyWWsW1f dHUUs3qu4wCQQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ce Sun , Lijo Lazar , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 427/844] drm/amdgpu: Adjust usleep_range in fence wait Date: Sat, 28 Feb 2026 12:25:40 -0500 Message-ID: <20260228173244.1509663-428-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ce Sun [ Upstream commit 3ee1c72606bd2842f0f377fd4b118362af0323ae ] Tune the sleep interval in the PSP fence wait loop from 10-100us to 60-100us.This adjustment results in an overall wait window of 1.2s (60us * 20000 iterations) to 2 seconds (100us * 20000 iterations), which guarantees that we can retrieve the correct fence value Signed-off-by: Ce Sun Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/= amdgpu/amdgpu_psp.c index 0b10497d487c3..81bdd6aaad2a1 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c @@ -726,7 +726,7 @@ psp_cmd_submit_buf(struct psp_context *psp, ras_intr =3D amdgpu_ras_intr_triggered(); if (ras_intr) break; - usleep_range(10, 100); + usleep_range(60, 100); amdgpu_device_invalidate_hdp(psp->adev, NULL); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DACAC3CA763; Sat, 28 Feb 2026 17:39:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300391; cv=none; b=iIZXVYaWhIs7+debpk+PVJUkYIx+95IJn2acr7REtJma8JpTBXbqlbrlEO6B+ByzP5Zql/2/S9DCXJ7nMRZK0FNvGJ28/baXZEAVogSYCl9/NNfcEM+MkXiS4j5W9cFK12QFpyKMpiYy+Vy9HbtjXrMonqO8HspwM/ErZHIn8E8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300391; c=relaxed/simple; bh=A0DZ+VURr0w625Y0aRbinDsfvZTdhyTk4iXPX+wyYu8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EKt0bYOTQf7mM8mfmfZZUZHmSmhKkb1oMW+F1Xqr+fLoQBGshqmEFP6KAzlNUy7LGd3QB2xX0qShXOxNEjmAEMXGHN9b+7Nrt7zTAEfQ0Bg7nXmjCVigS9BUfpsa5gHHcaZYyMiIwGBr7LOQIUm49bIiemV104+Low9cPzo50Nw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sjKEaMkm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sjKEaMkm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28E41C116D0; Sat, 28 Feb 2026 17:39:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300391; bh=A0DZ+VURr0w625Y0aRbinDsfvZTdhyTk4iXPX+wyYu8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sjKEaMkmrMdPe1VWrWgf9KDZBCKm47rmI3vIG3e6DufrGrOHFxjOsUh3FdLAMhAJE bnuW3fCGz0rQ3zOm3Nr/vfnHMqcI7g5TefGgabBc/m3+pQZuVoe7Re+3ycikyLWadG XjElkNfN5MDC2a7waz5a4FAd0EVTFNh0bb/r5A4bZD0OgoJiZc39vUZIsz4FQu8NnJ 7TxMoTm2q8aBvrOJa5xA8xC7bfR1QY6S/nV6mbEhqf1/XQIldfsTSo+QinttbDQwSz 5sRfEFrEYpVWOLUO5VJnigfRcR+kdqwoaOwLNJ/EnYD6gA1vdTZOVDpPCOf0UZxIa3 ymEZavTuiOUlQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Erik Sanjaya , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 428/844] ALSA: hda/realtek: Fix headset mic on ASUS Zenbook 14 UX3405MA Date: Sat, 28 Feb 2026 12:25:41 -0500 Message-ID: <20260228173244.1509663-429-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Erik Sanjaya [ Upstream commit 91062e119b4eafde553c894ca072cd615a6dae2e ] The ASUS Zenbook 14 UX3405MA uses an ALC294 codec with CS35L41 amplifiers over SPI. The existing quirk for this model only configured the amplifiers, leaving the headset microphone on the combo jack non-functional. Introduce a new fixup that configures pin 0x19 as headset mic input and chains to ALC245_FIXUP_CS35L41_SPI_2 to preserve speaker functionality. Similar to the fix done for the UM3406HA in commit 018f659753fd ("ALSA: hda/realtek: Fix headset mic on ASUS Zenbook 14"). Signed-off-by: Erik Sanjaya Link: https://patch.msgid.link/20260217102112.20651-1-sirreidlos@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/hda/codecs/realtek/alc269.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/a= lc269.c index c11312aa5ca76..36053042ca772 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -3886,6 +3886,7 @@ enum { ALC294_FIXUP_ASUS_MIC, ALC294_FIXUP_ASUS_HEADSET_MIC, ALC294_FIXUP_ASUS_I2C_HEADSET_MIC, + ALC294_FIXUP_ASUS_SPI_HEADSET_MIC, ALC294_FIXUP_ASUS_SPK, ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE, ALC285_FIXUP_LENOVO_PC_BEEP_IN_NOISE, @@ -5236,6 +5237,15 @@ static const struct hda_fixup alc269_fixups[] =3D { .chained =3D true, .chain_id =3D ALC287_FIXUP_CS35L41_I2C_2 }, + [ALC294_FIXUP_ASUS_SPI_HEADSET_MIC] =3D { + .type =3D HDA_FIXUP_PINS, + .v.pins =3D (const struct hda_pintbl[]) { + { 0x19, 0x04a11020 }, /* use as headset mic */ + { } + }, + .chained =3D true, + .chain_id =3D ALC245_FIXUP_CS35L41_SPI_2 + }, [ALC294_FIXUP_ASUS_SPK] =3D { .type =3D HDA_FIXUP_VERBS, .v.verbs =3D (const struct hda_verb[]) { @@ -7189,7 +7199,7 @@ static const struct hda_quirk alc269_fixup_tbl[] =3D { SND_PCI_QUIRK(0x1043, 0x19ce, "ASUS B9450FA", ALC294_FIXUP_ASUS_HPE), SND_PCI_QUIRK(0x1043, 0x19e1, "ASUS UX581LV", ALC295_FIXUP_ASUS_MIC_NO_PR= ESENCE), SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW), - SND_PCI_QUIRK(0x1043, 0x1a63, "ASUS UX3405MA", ALC245_FIXUP_CS35L41_SPI_2= ), + SND_PCI_QUIRK(0x1043, 0x1a63, "ASUS UX3405MA", ALC294_FIXUP_ASUS_SPI_HEAD= SET_MIC), SND_PCI_QUIRK(0x1043, 0x1a83, "ASUS UM5302LA", ALC294_FIXUP_CS35L41_I2C_2= ), SND_PCI_QUIRK(0x1043, 0x1a8e, "ASUS G712LWS", ALC294_FIXUP_LENOVO_MIC_LOC= ATION), SND_PCI_QUIRK(0x1043, 0x1a8f, "ASUS UX582ZS", ALC245_FIXUP_CS35L41_SPI_2), --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 96AC63CA77A; Sat, 28 Feb 2026 17:39:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300392; cv=none; b=IQEim4zs+7IfVRSNMuqvPlvMq66qXxYU9T+Si7sBubPJ8rOuXf8OxIioRc3R/Su3U2+j+K1byRqTw7JAFF4sfGGXmHUoOkICeus4A9kJLev45u4ISSZrwzmHRV/Q4YF/m9ioi+21ArTagTMCSKvPHKNbglMoDrmCC0COMYyNCIA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300392; c=relaxed/simple; bh=jGjwEs4qfs/Cs+UbuhuSh0oAOAqxAXQEo1nK2ljfwqk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NKey6zbZse9TwIsbcXki9zJvMTnBejhqwrBZ2x9EV+m//78wd4Oc1xvRGeKp1uXm5k5O1ikXpTA74HBNjtge8V1+Ye0n6m8IzBjTORs71XlN6t8oG3U0bcEJaW5v6UbGSTJCeiGFr/Uv54q9QFXhhTjr9ZF5N/5PjNz6j8AMCIk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fE90BElc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fE90BElc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01D6FC19424; Sat, 28 Feb 2026 17:39:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300392; bh=jGjwEs4qfs/Cs+UbuhuSh0oAOAqxAXQEo1nK2ljfwqk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fE90BElcAfb4gQFBobEV+N8sJjudJ91gAi8dDIKZMp53rQurjde4SBtFubiMusqdG zLuEpvE48NOKsJrcPCCNJSBzZAVwwQZJMV+PBfclbwagWNMJB+bkL5WDsE5ZeZkHls Cbqcq9uLHItoFr5jiR+lqpsdaEtkaGaUUFgIDVBgFCNDFoNGaR3+rkOk+ZC/3JQE1K LzQlnmrUsLj+oa0c5XgdGII5OGOCXc7e5raTta3fICi+hndCSfTkdVpaUjUCdTkX+8 TmKPBKJntJ55gL2+QZeuQYoazoSx5esqbXfi7c/xtky/MVGJs4+BK4njSWZeZYCXKg romrPIvDzhf0Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 429/844] ALSA: usb-audio: Update the number of packets properly at receiving Date: Sat, 28 Feb 2026 12:25:42 -0500 Message-ID: <20260228173244.1509663-430-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Takashi Iwai [ Upstream commit cf044e44190234a41a788de1cdbb6c21f4a52e1e ] At receiving the packets from the implicit feedback source, we didn't update ctx->packets field but only the ctx->packet_size[] data. In exceptional cases, this might lead to unexpectedly superfluous data transfer (although this won't happen usually due to the nature of USB isochronous transfer). Fix it to update the field properly. Link: https://patch.msgid.link/20260216141209.1849200-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/usb/endpoint.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c index 8f9313857ee9d..27ade2aa16f5a 100644 --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -481,6 +481,7 @@ int snd_usb_queue_pending_output_urbs(struct snd_usb_en= dpoint *ep, =20 /* copy over the length information */ if (implicit_fb) { + ctx->packets =3D packet->packets; for (i =3D 0; i < packet->packets; i++) ctx->packet_size[i] =3D packet->packet_size[i]; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B12F93CA79F; Sat, 28 Feb 2026 17:39:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300393; cv=none; b=mjdMDZmANoP6YcSaaVYvmqglUbqssd6unTbrgox3PmLz299Vtj4aIjwHFcXZIcVglFx8FTxxQxr2UQ3GXhbjf6JjUQ177frJeiQsKeUqVfHRpDsJld0eHElDLariDx7f373wI3/nI+UnwMGc9bJn2+jhFxIoS9PDxRIpb38wArA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300393; c=relaxed/simple; bh=8TGf0VU6GfG5Mi/G35xP1i+Vl1YCC2XhmyQds21Bc0g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PyHcv/o/qE5nfiGRL/AFpk8K9NxkP7cFXVDVQF1+uH7kK7QNxaR9clWHHSH2WwtfQgD8e4VkqOWmyAKbsYWlUi31RbOs+8Y6GSQgx3FmxJex2f/3TItanbuTpOeAHjqzhAR//Jir+uB3iSPb9DNOwUE2jL2ZtBC3wfHp7UxGDB8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SztrSJAA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SztrSJAA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBEB0C19425; Sat, 28 Feb 2026 17:39:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300393; bh=8TGf0VU6GfG5Mi/G35xP1i+Vl1YCC2XhmyQds21Bc0g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SztrSJAA80ikq4QvDUS5tvIhnIrwUjq0RIqWkkcAQuD69VY7TFvc+hlXJXX+VgPOv JyR54nW1TqlWlvgItfjTVP5I1qMOtDb0mVIJlnUd9pnIDj3k9A6PP2A0C/9Ko2vGnH 3bA1ShfTpo9N5VlrKTRovUO4c/D5+nvDwJpKwC3bcJl/MlsYcJBueQfNifkDPCzq7+ Rg5VWXlR0Gr0yC8qW0Yt9Y9vcdHe/aO1waKwTlYhriIRKFWceEnmM4xd5+oBaM0zkm 5FIc/Qi4HWe79G7UKgWrZluLX/ZbApOUYXzaIlCNSuc+l1Br26LRkQ60WXAGXCQ+/G 9ua///FQ6a+fw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: YiLing Chen , Nicholas Kazlauskas , Tom Chung , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 430/844] drm/amd/display: set enable_legacy_fast_update to false for DCN36 Date: Sat, 28 Feb 2026 12:25:43 -0500 Message-ID: <20260228173244.1509663-431-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: YiLing Chen [ Upstream commit d0728aee5090853d0b9982757f5fb1b13e2e2b27 ] [Why/How] Align the default value of the flag with DCN35/351. Reviewed-by: Nicholas Kazlauskas Signed-off-by: YiLing Chen Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/resource/dcn36/dcn36_resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn36/dcn36_resource.c= b/drivers/gpu/drm/amd/display/dc/resource/dcn36/dcn36_resource.c index 6469d5fe2e6d4..a1132102afde4 100644 --- a/drivers/gpu/drm/amd/display/dc/resource/dcn36/dcn36_resource.c +++ b/drivers/gpu/drm/amd/display/dc/resource/dcn36/dcn36_resource.c @@ -769,7 +769,7 @@ static const struct dc_debug_options debug_defaults_drv= =3D { }; =20 static const struct dc_check_config config_defaults =3D { - .enable_legacy_fast_update =3D true, + .enable_legacy_fast_update =3D false, }; =20 static const struct dc_panel_config panel_config_defaults =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 900613CAF6D; Sat, 28 Feb 2026 17:39:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300394; cv=none; b=iPJUnR2WuTbJXyGOiz9RMSog9xjYQRuP3IrSpmQtL1BJIKcnA9dcIdfykIT15Uz2j9nQwm54uymcKqKsA+JYwIhtQH4ckRm2jLOWb+ReejXrxSFmtumjMuD/ZWLasXiEopLMyQiMUs/GIrlCYXFON+QiZlJxtMGbQvtDqQf+OWc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300394; c=relaxed/simple; bh=Z0zHhq6U1lG+GvEXgpJNjSHVhFdAXGkDjCx+HiB5Zhw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mkzlE9fXUYJVTykAjSn4cejSuk4ZzN103BQ7e0oGDebe9zgom/htO5vAcQVYt+8HCfiTObR5dI+/13s6wJv7hNk66+DuiA+Y/kS70uSY1Ej96CrZEgJJT2QDvhEINE4bOqIm3ypN6uPVSI6ecgrpSJWOoW4kP64uB6E14E5zeXM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SL0NYL4O; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SL0NYL4O" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D439FC116D0; Sat, 28 Feb 2026 17:39:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300394; bh=Z0zHhq6U1lG+GvEXgpJNjSHVhFdAXGkDjCx+HiB5Zhw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SL0NYL4Ou4PkS9p87WUycS5+BfI1Ix3n1Zl7M+XmVsfKZ7P+XzIioH/c7jam/RT1E 64XTOdvAyAInjCF+u8HX5dKDdUBrGNuKYuU+y3KZbZ4ELf5e+FMPvZj7eepO7kjZtN 6f0z3oz/XrZXLDEWGLzCRE7VDiGEUVtbVczqIpzhajfK7LwOhc5w07BXrnMVlCov+O olzl5FFZisQicUNsG4LcsAKAoH5cUa0uJPiO5BxdZJMwWzemsO3T6faxt+DaqF1NoL XtbLf6O3JTLQ5WykCvt9HeAak73JSZtZHW5vSgfqEzpi6ExvPGUF1DluHDJkouz3Uo Z6BrDB6uzgDWA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: decce6 , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 431/844] drm/amdgpu: Add HAINAN clock adjustment Date: Sat, 28 Feb 2026 12:25:44 -0500 Message-ID: <20260228173244.1509663-432-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: decce6 [ Upstream commit 49fe2c57bdc0acff9d2551ae337270b6fd8119d9 ] This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from 850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This patch is for amdgpu. Signed-off-by: decce6 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c b/drivers/gpu/drm/a= md/pm/legacy-dpm/si_dpm.c index 695432d3045ff..2d8d86efe2e73 100644 --- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c +++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c @@ -3464,6 +3464,11 @@ static void si_apply_state_adjust_rules(struct amdgp= u_device *adev, max_sclk =3D 60000; max_mclk =3D 80000; } + if ((adev->pdev->device =3D=3D 0x666f) && + (adev->pdev->revision =3D=3D 0x00)) { + max_sclk =3D 80000; + max_mclk =3D 95000; + } } else if (adev->asic_type =3D=3D CHIP_OLAND) { if ((adev->pdev->revision =3D=3D 0xC7) || (adev->pdev->revision =3D=3D 0x80) || --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAAB13CAF90; Sat, 28 Feb 2026 17:39:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300395; cv=none; b=M5hP6LxYmqEKDA2KuXWtiR79WJbi+Dt27K/hZH7zh/0ArAeWkQ7UidcKspPHx/YrZTnProUJilGolmfNPaZTZcQyhIuNkDaYP7yhWoLIkSpiFtnoFHX/6axURP4HJGl3QjyNJ63T236oSQza+LKCajKC1dqUWmAda3G0ruKg4aA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300395; c=relaxed/simple; bh=tdLRcPDYUfZm78vFyiDv0xPCoGYLygU2PRZY3oEzq2Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U2sPdSh9F8ukkZHG9Yww8QQICplenvNqPg1CFJ2eIdmkPIFebH8Jsa6NM3KxPuoq5oNGPrRQw+EAOq+xFRrS5UWoIKPuwtIeKvCnq+1apjbQ4FrGjIdIxi4+LhDURJysioh23A61IqadVLJBl5DTty6VRociKHGoIh8WkUAzB0Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ETgk1PxZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ETgk1PxZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B54B2C116D0; Sat, 28 Feb 2026 17:39:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300395; bh=tdLRcPDYUfZm78vFyiDv0xPCoGYLygU2PRZY3oEzq2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ETgk1PxZPbX4ztyxDSm1j/gCSVubOvIZmaBen2YyS+kD38mDXYgKskq2UvTfX3LSh vVcgoXUnTKNDMgA2ug5zyBEe4w7PB2doT/qpvlWKFTwM7Ihi8wsigCtxh8Cacqb4Rh fGrzIdxx7i5p5ivvxAX7QA4NrFHIr62PwuJAVyYtP8gsOU1bgX8xK7WehP81HY4gyE 1fqGH5wIsrSzUDxi1ZA82mplwb+uPUv1YAtSppv0Qc8c6/MdlDB3jHdj3tvP33mYzV 1sMn1Pe2y7zqMJdsgoNHvFf240bAjuswchYSg3oVUWgonQB9Vxjooxv44gt5+xY6Nr 4dOi+tGRxAx2Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Clay King , Aric Cyr , Tom Chung , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 432/844] drm/amd/display: bypass post csc for additional color spaces in dal Date: Sat, 28 Feb 2026 12:25:45 -0500 Message-ID: <20260228173244.1509663-433-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Clay King [ Upstream commit 7d9ec9dc20ecdb1661f4538cd9112cd3d6a5f15a ] [Why] For RGB BT2020 full and limited color spaces, overlay adjustments were applied twice (once by MM and once by DAL). This results in incorrect colours and a noticeable difference between mpo and non-mpo cases. [How] Add RGB BT2020 full and limited color spaces to list that bypasses post csc adjustment. Reviewed-by: Aric Cyr Signed-off-by: Clay King Signed-off-by: Tom Chung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c | 21 ++++++++++++++++--- .../drm/amd/display/dc/dpp/dcn30/dcn30_dpp.h | 4 ++++ .../amd/display/dc/dpp/dcn401/dcn401_dpp.c | 6 +++--- 3 files changed, 25 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c b/drivers= /gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c index ef4a161171814..c7923531da83d 100644 --- a/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c +++ b/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c @@ -376,10 +376,10 @@ void dpp3_cnv_setup ( =20 tbl_entry.color_space =3D input_color_space; =20 - if (color_space >=3D COLOR_SPACE_YCBCR601) - select =3D INPUT_CSC_SELECT_ICSC; - else + if (dpp3_should_bypass_post_csc_for_colorspace(color_space)) select =3D INPUT_CSC_SELECT_BYPASS; + else + select =3D INPUT_CSC_SELECT_ICSC; =20 dpp3_program_post_csc(dpp_base, color_space, select, &tbl_entry); @@ -1541,3 +1541,18 @@ bool dpp3_construct( return true; } =20 +bool dpp3_should_bypass_post_csc_for_colorspace(enum dc_color_space dc_col= or_space) +{ + switch (dc_color_space) { + case COLOR_SPACE_UNKNOWN: + case COLOR_SPACE_SRGB: + case COLOR_SPACE_XR_RGB: + case COLOR_SPACE_SRGB_LIMITED: + case COLOR_SPACE_MSREF_SCRGB: + case COLOR_SPACE_2020_RGB_FULLRANGE: + case COLOR_SPACE_2020_RGB_LIMITEDRANGE: + return true; + default: + return false; + } +} diff --git a/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.h b/drivers= /gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.h index d4a70b4379eaf..6a61b99d6a798 100644 --- a/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.h +++ b/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.h @@ -644,4 +644,8 @@ void dpp3_program_cm_dealpha( =20 void dpp3_cm_get_gamut_remap(struct dpp *dpp_base, struct dpp_grph_csc_adjustment *adjust); + +bool dpp3_should_bypass_post_csc_for_colorspace( + enum dc_color_space dc_color_space); + #endif /* __DC_HWSS_DCN30_H__ */ diff --git a/drivers/gpu/drm/amd/display/dc/dpp/dcn401/dcn401_dpp.c b/drive= rs/gpu/drm/amd/display/dc/dpp/dcn401/dcn401_dpp.c index 96c2c853de42c..2d6a646462e21 100644 --- a/drivers/gpu/drm/amd/display/dc/dpp/dcn401/dcn401_dpp.c +++ b/drivers/gpu/drm/amd/display/dc/dpp/dcn401/dcn401_dpp.c @@ -206,10 +206,10 @@ void dpp401_dpp_setup( =20 tbl_entry.color_space =3D input_color_space; =20 - if (color_space >=3D COLOR_SPACE_YCBCR601) - select =3D INPUT_CSC_SELECT_ICSC; - else + if (dpp3_should_bypass_post_csc_for_colorspace(color_space)) select =3D INPUT_CSC_SELECT_BYPASS; + else + select =3D INPUT_CSC_SELECT_ICSC; =20 dpp3_program_post_csc(dpp_base, color_space, select, &tbl_entry); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BEED3CA79B; Sat, 28 Feb 2026 17:39:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300396; cv=none; b=FnWEoEQU2OXVNYW3GddgnWzuzGmw1dOMGdSRKLp7aDVrPMhBROX4KQ2cohUSEpSnPD6fGfeEjxGTQE+Ho5uk3/rWqtTyvHPE6lauMlj+7uBO+p9G1OT94dTVpZYTHRbsFlUsU3LCfAmL52eAuR8XGK3MzX4v8eM4yqKMS6I0xh4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300396; c=relaxed/simple; bh=M2hlIiwEZWSkqOgs9cGI/Zl461ZEg2wPTS4lRx17/Ko=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=faBqJAPxlWx/DXIY3Zg9E6CoHyPVmAcIr3VceYphg/VILtYgCOuOcQa2kTh6AHYpIP/90yeMwRp7fJmjdcF9cxp/zIe72wzlzBgvU4KcfLMW33z0yDd8zGVZzyyJTG9WyUGY+nsnDTmqaxbT/66+QpbcPzpzwZBYiNsCj1Nrwo8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oQm+Zbwa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oQm+Zbwa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD304C19425; Sat, 28 Feb 2026 17:39:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300396; bh=M2hlIiwEZWSkqOgs9cGI/Zl461ZEg2wPTS4lRx17/Ko=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oQm+ZbwaNjrcJhCLaguoxRVFVM0dRLFDfE42Ihc33SUw89Bx/6pb5K6nt942bPkTX miR9Sy154/dQBpE2NoLMncnEnIyBLNuJ7XDsISrFqzYxv2HpBhy7FICTgzUdw0NYp/ QWHTtxrDEMSZjJULxDpEprLqLi1Piv+VZWwPBxlmZ3/vUE0GVgG+Gfx8kYA5+59cTf OvzHKu5ygE80BRlmFOEgY2wN77hs+l5FSP0khHNEewfRoiRx4cz1F7LzVmzmIk2gN0 SdBB+QWvhjc2dS3JZwliMgv5rMrsby8f+1rt66W+Aiwd6GvDmy6kDcre/HtdOaOgzb ZGk5Sd5LObMMQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Fabian Godehardt , Mark Brown , Sasha Levin Subject: [PATCH 6.19 433/844] spi: spidev: fix lock inversion between spi_lock and buf_lock Date: Sat, 28 Feb 2026 12:25:46 -0500 Message-ID: <20260228173244.1509663-434-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Fabian Godehardt [ Upstream commit 40534d19ed2afb880ecf202dab26a8e7a5808d16 ] The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path: write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks: WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK *** The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor. Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock. buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues. This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour. Signed-off-by: Fabian Godehardt Link: https://patch.msgid.link/20260211072616.489522-1-fg@emlix.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spi/spidev.c | 63 ++++++++++++++++---------------------------- 1 file changed, 22 insertions(+), 41 deletions(-) diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c index 9a0160f6dc3dc..f28528ed1c24e 100644 --- a/drivers/spi/spidev.c +++ b/drivers/spi/spidev.c @@ -74,7 +74,6 @@ struct spidev_data { struct list_head device_entry; =20 /* TX/RX buffers are NULL unless this device is open (users > 0) */ - struct mutex buf_lock; unsigned users; u8 *tx_buffer; u8 *rx_buffer; @@ -102,24 +101,6 @@ spidev_sync_unlocked(struct spi_device *spi, struct sp= i_message *message) return status; } =20 -static ssize_t -spidev_sync(struct spidev_data *spidev, struct spi_message *message) -{ - ssize_t status; - struct spi_device *spi; - - mutex_lock(&spidev->spi_lock); - spi =3D spidev->spi; - - if (spi =3D=3D NULL) - status =3D -ESHUTDOWN; - else - status =3D spidev_sync_unlocked(spi, message); - - mutex_unlock(&spidev->spi_lock); - return status; -} - static inline ssize_t spidev_sync_write(struct spidev_data *spidev, size_t len) { @@ -132,7 +113,8 @@ spidev_sync_write(struct spidev_data *spidev, size_t le= n) =20 spi_message_init(&m); spi_message_add_tail(&t, &m); - return spidev_sync(spidev, &m); + + return spidev_sync_unlocked(spidev->spi, &m); } =20 static inline ssize_t @@ -147,7 +129,8 @@ spidev_sync_read(struct spidev_data *spidev, size_t len) =20 spi_message_init(&m); spi_message_add_tail(&t, &m); - return spidev_sync(spidev, &m); + + return spidev_sync_unlocked(spidev->spi, &m); } =20 /*------------------------------------------------------------------------= -*/ @@ -157,7 +140,7 @@ static ssize_t spidev_read(struct file *filp, char __user *buf, size_t count, loff_t *f_p= os) { struct spidev_data *spidev; - ssize_t status; + ssize_t status =3D -ESHUTDOWN; =20 /* chipselect only toggles at start or end of operation */ if (count > bufsiz) @@ -165,7 +148,11 @@ spidev_read(struct file *filp, char __user *buf, size_= t count, loff_t *f_pos) =20 spidev =3D filp->private_data; =20 - mutex_lock(&spidev->buf_lock); + mutex_lock(&spidev->spi_lock); + + if (spidev->spi =3D=3D NULL) + goto err_spi_removed; + status =3D spidev_sync_read(spidev, count); if (status > 0) { unsigned long missing; @@ -176,7 +163,9 @@ spidev_read(struct file *filp, char __user *buf, size_t= count, loff_t *f_pos) else status =3D status - missing; } - mutex_unlock(&spidev->buf_lock); + +err_spi_removed: + mutex_unlock(&spidev->spi_lock); =20 return status; } @@ -187,7 +176,7 @@ spidev_write(struct file *filp, const char __user *buf, size_t count, loff_t *f_pos) { struct spidev_data *spidev; - ssize_t status; + ssize_t status =3D -ESHUTDOWN; unsigned long missing; =20 /* chipselect only toggles at start or end of operation */ @@ -196,13 +185,19 @@ spidev_write(struct file *filp, const char __user *bu= f, =20 spidev =3D filp->private_data; =20 - mutex_lock(&spidev->buf_lock); + mutex_lock(&spidev->spi_lock); + + if (spidev->spi =3D=3D NULL) + goto err_spi_removed; + missing =3D copy_from_user(spidev->tx_buffer, buf, count); if (missing =3D=3D 0) status =3D spidev_sync_write(spidev, count); else status =3D -EFAULT; - mutex_unlock(&spidev->buf_lock); + +err_spi_removed: + mutex_unlock(&spidev->spi_lock); =20 return status; } @@ -379,14 +374,6 @@ spidev_ioctl(struct file *filp, unsigned int cmd, unsi= gned long arg) =20 ctlr =3D spi->controller; =20 - /* use the buffer lock here for triple duty: - * - prevent I/O (from us) so calling spi_setup() is safe; - * - prevent concurrent SPI_IOC_WR_* from morphing - * data fields while SPI_IOC_RD_* reads them; - * - SPI_IOC_MESSAGE needs the buffer locked "normally". - */ - mutex_lock(&spidev->buf_lock); - switch (cmd) { /* read requests */ case SPI_IOC_RD_MODE: @@ -510,7 +497,6 @@ spidev_ioctl(struct file *filp, unsigned int cmd, unsig= ned long arg) break; } =20 - mutex_unlock(&spidev->buf_lock); spi_dev_put(spi); mutex_unlock(&spidev->spi_lock); return retval; @@ -541,9 +527,6 @@ spidev_compat_ioc_message(struct file *filp, unsigned i= nt cmd, return -ESHUTDOWN; } =20 - /* SPI_IOC_MESSAGE needs the buffer locked "normally" */ - mutex_lock(&spidev->buf_lock); - /* Check message and copy into scratch area */ ioc =3D spidev_get_ioc_message(cmd, u_ioc, &n_ioc); if (IS_ERR(ioc)) { @@ -564,7 +547,6 @@ spidev_compat_ioc_message(struct file *filp, unsigned i= nt cmd, kfree(ioc); =20 done: - mutex_unlock(&spidev->buf_lock); spi_dev_put(spi); mutex_unlock(&spidev->spi_lock); return retval; @@ -802,7 +784,6 @@ static int spidev_probe(struct spi_device *spi) /* Initialize the driver data */ spidev->spi =3D spi; mutex_init(&spidev->spi_lock); - mutex_init(&spidev->buf_lock); =20 INIT_LIST_HEAD(&spidev->device_entry); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C4A73CB80B; Sat, 28 Feb 2026 17:39:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300397; cv=none; b=LUdIKRWbj2W1kntdoldOPymmPsdbTjTKRj0wIwcbKpnvGW/0L9djlTwrn3GQEPrkYKFng11HTfSVLpe9lu72SqhBXYZNspynd4b8Cc2TZCJlRoIDjJQchxsK+DQLszPGxI/oM8BznvioTBZAiZT+cQahd9SBlyMGW/kFJ5yuR0U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300397; c=relaxed/simple; bh=10LD9H4CBUJb42a3buQSMpkNQAa4if+Msqqc8c9f7nM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sHp8wWj5m9fWJGqHAWKRCTAln+a8XfSr5x3U+HcoAHhsqvZCNoYnjy4532nggrM2Idd1ZmTtz630pIEtwciGB7ZtW87SxDjqpIPBCic8RJ9zkLQjZmXdR1viqELxZMMnPm4qOFSFx05FkXGSGInjPTvJgpawt6lWdIskj+DAaCI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dB4SYnls; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dB4SYnls" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97AC1C19423; Sat, 28 Feb 2026 17:39:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300397; bh=10LD9H4CBUJb42a3buQSMpkNQAa4if+Msqqc8c9f7nM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dB4SYnlsbD5qMCVJNfpxyr4qKCNv81XdIurWM4vxf3GtVpenMZuDJdR9V6wWn9EWH SNkkV71Fe+J7GH36p82bB+FQKfLjaauLD/HTTopmkLziRKrrDpo/aSSnqLWWaBSqjm wHa9DbSWvomAT6wW6BHA4K79AfvZ7GsbBmPR3vTDFfDaXMTMU2QEMNhP0fwsY6WJb4 UIJPZ/z9dMw/O+tSN4c0ppZ0y4FHNVCqUewOhj2BOTdMyuR3WcqC5bWaetp5b4rXag 5fxmzSTU5Nujwhvrmm1flV+Si8rD7z7VTIId2fQyTur3HhOx/WKrwjCOnZswAOdKpD 4RoKQjmhNA0uA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: decce6 , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 434/844] drm/radeon: Add HAINAN clock adjustment Date: Sat, 28 Feb 2026 12:25:47 -0500 Message-ID: <20260228173244.1509663-435-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: decce6 [ Upstream commit 908d318f23d6b5d625bea093c5fc056238cdb7ff ] This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from 850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This patch is for radeon. Signed-off-by: decce6 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/radeon/si_dpm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dp= m.c index 9deb91970d4df..f12227145ef08 100644 --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -2925,6 +2925,11 @@ static void si_apply_state_adjust_rules(struct radeo= n_device *rdev, max_sclk =3D 60000; max_mclk =3D 80000; } + if ((rdev->pdev->device =3D=3D 0x666f) && + (rdev->pdev->revision =3D=3D 0x00)) { + max_sclk =3D 80000; + max_mclk =3D 95000; + } } else if (rdev->family =3D=3D CHIP_OLAND) { if ((rdev->pdev->revision =3D=3D 0xC7) || (rdev->pdev->revision =3D=3D 0x80) || --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 140CA3CB81A; Sat, 28 Feb 2026 17:39:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300398; cv=none; b=Uc/WaXHgW1SgSnLQ5JD7j5jJ6gy57Rf914aPZrC9zpR7boKAevwV+edZG0c5qSADxHxcaAh4ezMGyE3EsexmuoYqFg5IkwUMzUOswTy0li/V8pCMvN1IyR5A3yYko7Mlcr1rJdcF4K8DaUBlLjq/zaLZ4qMP4MZV2yFOzpb0Fg4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300398; c=relaxed/simple; bh=z4ONJflA2gCPaXMC/sKG6Z8ES0UuOJ9WngsB/kBloT8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p1iHGVQmU2oXWaVgS/LcWfDAtvoJIGZq0lhWo2s8yEkPBN2LS5qaWLEMqmEc8QHvfD0qH0tRx07VlS45rgi+S8G5nw3SymOdKnTVLd45od0ZW15EGnsIbwwX8CpZSeac0TX+Qc3mv86P8aB7xnpO4HFWWildu8slv9nNIcSjqFM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FMEpFz39; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FMEpFz39" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73562C2BC87; Sat, 28 Feb 2026 17:39:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300398; bh=z4ONJflA2gCPaXMC/sKG6Z8ES0UuOJ9WngsB/kBloT8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FMEpFz397jfDrn2iYsfvJgWRzRXG+syAXZtdCoHuKPlDK3qEf6VtXQEOnlX0be17f /X2MvBNlgPSk1ILpET5rBOu1EGkOIbyLwK5Ehn9cDzR8bJzNEfpTFmQafdZgth3aEM 3Mfha/BoVJm8hWYJslhREGRD0eQ8d81hrrKnSLfYoC8DLXZqXcW2psR6IeZyvSnnkt XAKad1xwewZt9cDC+xb8iyXgPu04KEb7Nb2sXRU0YgYmLoj+aovxx3e5gVSiMXWRJf 6I2bjtbRys6Ym/5bBt8y207HoTW1ZeHPKCkPf/p6/ya3sxKx8la4bohV4la7S0cRN0 M+H6oj4FxGD4A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 435/844] ALSA: usb-audio: Add sanity check for OOB writes at silencing Date: Sat, 28 Feb 2026 12:25:48 -0500 Message-ID: <20260228173244.1509663-436-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Takashi Iwai [ Upstream commit fba2105a157fffcf19825e4eea498346738c9948 ] At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D221076 Link: https://patch.msgid.link/20260216141209.1849200-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/usb/endpoint.c | 39 ++++++++++++++++++++++----------------- 1 file changed, 22 insertions(+), 17 deletions(-) diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c index 27ade2aa16f5a..1eaf52d1ae9c7 100644 --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -275,8 +275,8 @@ static inline bool has_tx_length_quirk(struct snd_usb_a= udio *chip) return chip->quirk_flags & QUIRK_FLAG_TX_LENGTH; } =20 -static void prepare_silent_urb(struct snd_usb_endpoint *ep, - struct snd_urb_ctx *ctx) +static int prepare_silent_urb(struct snd_usb_endpoint *ep, + struct snd_urb_ctx *ctx) { struct urb *urb =3D ctx->urb; unsigned int offs =3D 0; @@ -289,28 +289,34 @@ static void prepare_silent_urb(struct snd_usb_endpoin= t *ep, extra =3D sizeof(packet_length); =20 for (i =3D 0; i < ctx->packets; ++i) { - unsigned int offset; - unsigned int length; - int counts; - - counts =3D snd_usb_endpoint_next_packet_size(ep, ctx, i, 0); - length =3D counts * ep->stride; /* number of silent bytes */ - offset =3D offs * ep->stride + extra * i; - urb->iso_frame_desc[i].offset =3D offset; + int length; + + length =3D snd_usb_endpoint_next_packet_size(ep, ctx, i, 0); + if (length < 0) + return length; + length *=3D ep->stride; /* number of silent bytes */ + if (offs + length + extra > ctx->buffer_size) + break; + urb->iso_frame_desc[i].offset =3D offs; urb->iso_frame_desc[i].length =3D length + extra; if (extra) { packet_length =3D cpu_to_le32(length); - memcpy(urb->transfer_buffer + offset, + memcpy(urb->transfer_buffer + offs, &packet_length, sizeof(packet_length)); + offs +=3D extra; } - memset(urb->transfer_buffer + offset + extra, + memset(urb->transfer_buffer + offs, ep->silence_value, length); - offs +=3D counts; + offs +=3D length; } =20 - urb->number_of_packets =3D ctx->packets; - urb->transfer_buffer_length =3D offs * ep->stride + ctx->packets * extra; + if (!offs) + return -EPIPE; + + urb->number_of_packets =3D i; + urb->transfer_buffer_length =3D offs; ctx->queued =3D 0; + return 0; } =20 /* @@ -332,8 +338,7 @@ static int prepare_outbound_urb(struct snd_usb_endpoint= *ep, if (data_subs && ep->prepare_data_urb) return ep->prepare_data_urb(data_subs, urb, in_stream_lock); /* no data provider, so send silence */ - prepare_silent_urb(ep, ctx); - break; + return prepare_silent_urb(ep, ctx); =20 case SND_USB_ENDPOINT_TYPE_SYNC: if (snd_usb_get_speed(ep->chip->dev) >=3D USB_SPEED_HIGH) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CD8A481A9B; Sat, 28 Feb 2026 17:39:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300399; cv=none; b=NPKh+rM4+Sep5p2+ROAc5kAEC5mRwk9r9pk3DGjXQAUtSL546BBnh6QZHeOhahlsSZTzoQvt4Bu0vhnJlHePSq/V7xynLZWWuOEnQZ6YC2S3LvXgs2w3OXg267Xi+mRiIzX8rbbYiiVZdb4MZLtXUY5DS01JE5Dl4pStVIgpAtI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300399; c=relaxed/simple; bh=wBsxPKeSjbR8ckgdKfACUaRlX2AI0xFolBu/BvXXt5A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WzvxjxypB1JOyeDSeSHDcKTswUjRENGhF85tYI245A3lw3qsLVpHcbnCwRPIGPIHsvYSC5Qf7ysg0SapD96uqS36A+dimtVMEqpnGAKUJcjVtFBzu5ZUao4VjDDdQfOXzgBoaIUXtKnUpWWhyjngtqM0p4Cvxia9i5ZvPz97iks= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FbzQT4Ji; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FbzQT4Ji" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D542C19423; Sat, 28 Feb 2026 17:39:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300398; bh=wBsxPKeSjbR8ckgdKfACUaRlX2AI0xFolBu/BvXXt5A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FbzQT4JiFSCKGUZW0YsdHAJYKz3HD0agIYc0VBkCrYrx2+peVnwA6KEyealEXu6Ra hcNsUh7HG4DK/kyKH0I/Mb3P+74Ys7+kZl4XhqHW4Ranyxag+mK99CcUqQXUW1bWgt BJH49mHILIGhZYWMS3dI/AZ3ymxAKilGuNid6X5hDzlU55/mbOD83rIHEU0xtag/a4 ZIOmszdZKCK01e5k96Bio0XJ3MXKwckePdDPY8h8oQepIRF2fCJn8P8v7uSNhflhQW cSFqqZHD85vnIAQ0Y+KpEyjSwKf2S2nvKvJ5bzyabkekrie3FYH488WXcSk+YAGCdf LeJn5cngExH1w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Adarsh Das , Qu Wenruo , David Sterba , Sasha Levin Subject: [PATCH 6.19 436/844] btrfs: replace BUG() with error handling in __btrfs_balance() Date: Sat, 28 Feb 2026 12:25:49 -0500 Message-ID: <20260228173244.1509663-437-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Adarsh Das [ Upstream commit be6324a809dbda76d5fdb23720ad9b20e5c1905c ] We search with offset (u64)-1 which should never match exactly. Previously this was handled with BUG(). Now logs an error and return -EUCLEAN. Reviewed-by: Qu Wenruo Signed-off-by: Adarsh Das Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/volumes.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 99e167a697ba8..1cbe7c6a2889c 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4234,8 +4234,14 @@ static int __btrfs_balance(struct btrfs_fs_info *fs_= info) * this shouldn't happen, it means the last relocate * failed */ - if (ret =3D=3D 0) - BUG(); /* FIXME break ? */ + if (unlikely(ret =3D=3D 0)) { + btrfs_err(fs_info, + "unexpected exact match of CHUNK_ITEM in chunk tree, offset 0x%llx", + key.offset); + mutex_unlock(&fs_info->reclaim_bgs_lock); + ret =3D -EUCLEAN; + goto error; + } =20 ret =3D btrfs_previous_item(chunk_root, path, 0, BTRFS_CHUNK_ITEM_KEY); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF9EE3CC1B8; Sat, 28 Feb 2026 17:39:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300400; cv=none; b=lmE1di2ove7wnvDx/QCqYgMt7Bj6AlAXQkY6qCV5tY3gtdoZYPcWSGRIxaXjZVPCG/Q1pBM0o0B1//Qr3/4R3C49J5qKMn6RA0JEQJ8qhVhQgY9dNQsOP56RvDFctNbrW5/nrMe6sSTFdttsCEwtzyrwCGT30/L1/qKkXACcmow= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300400; c=relaxed/simple; bh=CAIGXWOCpq5JZbzY6B5ypnvatHjxM4ndTCrYQmeRl4s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VOgamChd+sR2h2KoFIoy57gKL5pAovneoE0FjNMZI97y5bFCXeqlnCyJ4RFA7fG+8glQEdpLmQvxPcY4z7x3SqOvm7PsiD+pNuDHsKWK2Gov+sFDMBpcgQyjP5gQ5d5jxq+4yC5mgwEKzIAzlg03ZBO2Nzq8AlGS2Ij/DHGJNTE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PYVlv6mg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PYVlv6mg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2DDB2C19425; Sat, 28 Feb 2026 17:39:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300399; bh=CAIGXWOCpq5JZbzY6B5ypnvatHjxM4ndTCrYQmeRl4s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PYVlv6mgQgQzmQIMpxpyy5R2+CnDMACA7TXK/quVhCN5fddxn2w1v5KCuy3i4jMSy yJlZp6gicVumFtoD0ccYSdtKcHd62FhrD5yA9nVbllzC98P/LaFPhG1eoRAxYsCU7C 9zVUFv03qie8ilpSy1kDeXB2DDh+/1ZjnNocXrWlnDRwn9rnk/rdbaTDmCt4/sDD/M WUTxFevVlDfPyPVHPM9I9O/fJcnvCapdQ/yNv9orj/X0kXmJqSuJRcRKIOI0SgVTjA 0JFMgf+AS5iRsdR20C4QuKiy1/h4bg3mxtOfXvCKzEbzZXty7Si9Om3+WzABBPFaAr nwnXt9uZk4YxQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Qu Wenruo , Christoph Hellwig , David Sterba , Sasha Levin Subject: [PATCH 6.19 437/844] btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure() Date: Sat, 28 Feb 2026 12:25:50 -0500 Message-ID: <20260228173244.1509663-438-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Qu Wenruo [ Upstream commit 8ceaad6cd6e7fa5f73b0b2796a2e85d75d37e9f3 ] [BUG] There is a bug report that when btrfs hits ENOSPC error in a critical path, btrfs flips RO (this part is expected, although the ENOSPC bug still needs to be addressed). The problem is after the RO flip, if there is a read repair pending, we can hit the ASSERT() inside btrfs_repair_io_failure() like the following: BTRFS info (device vdc): relocating block group 30408704 flags metadata|r= aid1 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -28) WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/= 0xfd0, CPU#1: btrfs/383844 Modules linked in: kvm_intel kvm irqbypass [...] ---[ end trace 0000000000000000 ]--- BTRFS info (device vdc state EA): 2 enospc errors during balance BTRFS info (device vdc state EA): balance: ended with status: -30 BTRFS error (device vdc state EA): parent transid verify failed on logica= l 30556160 mirror 2 wanted 8 found 6 BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, fl= ush 0, corrupt 10, gen 0 [...] assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/b= io.c:938 ------------[ cut here ]------------ assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/b= io.c:938 kernel BUG at fs/btrfs/bio.c:938! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N = 6.19.0-rc6+ #4788 PREEMPT(full) Tainted: [W]=3DWARN, [N]=3DTEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb5= 2ca86e094d-prebuilt.qemu.org 04/01/2014 Workqueue: btrfs-endio simple_end_io_work RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120 RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246 RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988 R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310 R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000 FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000= 000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ------------[ cut here ]------------ [CAUSE] The cause of -ENOSPC error during the test case btrfs/124 is still unknown, although it's known that we still have cases where metadata can be over-committed but can not be fulfilled correctly, thus if we hit such ENOSPC error inside a critical path, we have no choice but abort the current transaction. This will mark the fs read-only. The problem is inside the btrfs_repair_io_failure() path that we require the fs not to be mount read-only. This is normally fine, but if we are doing a read-repair meanwhile the fs flips RO due to a critical error, we can enter btrfs_repair_io_failure() with super block set to read-only, thus triggering the above crash. [FIX] Just replace the ASSERT() with a proper return if the fs is already read-only. Reported-by: Christoph Hellwig Link: https://lore.kernel.org/linux-btrfs/20260126045555.GB31641@lst.de/ Tested-by: Christoph Hellwig Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/bio.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/bio.c b/fs/btrfs/bio.c index e4d382d3a7aea..1de1b408c6a6d 100644 --- a/fs/btrfs/bio.c +++ b/fs/btrfs/bio.c @@ -934,7 +934,6 @@ int btrfs_repair_io_failure(struct btrfs_fs_info *fs_in= fo, u64 ino, u64 fileoff, struct bio *bio =3D NULL; int ret =3D 0; =20 - ASSERT(!(fs_info->sb->s_flags & SB_RDONLY)); BUG_ON(!mirror_num); =20 /* Basic alignment checks. */ @@ -946,6 +945,13 @@ int btrfs_repair_io_failure(struct btrfs_fs_info *fs_i= nfo, u64 ino, u64 fileoff, ASSERT(step <=3D length); ASSERT(is_power_of_2(step)); =20 + /* + * The fs either mounted RO or hit critical errors, no need + * to continue repairing. + */ + if (unlikely(sb_rdonly(fs_info->sb))) + return 0; + if (btrfs_repair_one_zone(fs_info, logical)) return 0; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED1443CC1D7; Sat, 28 Feb 2026 17:40:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300401; cv=none; b=DRoQS83rkSktDp+4VYx55k8TqOQIfpzvtN0Q+ONlKZKXBcJP+cjz5NQ8em0MvwP/dqpx8I7xhhzdUqf2xv1Hf5mYeKTOnUp+r+ob6P/S9k55GDrTqZaBkhMCXx7H51tibTFNOc9y3Vu7zA84vq8hKTEjAuN02pg4u134OcKA2MU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300401; c=relaxed/simple; bh=C7Bf/4SETKQRpPhhtzMAKhHgf2oEI1fWMYv2QqDhegk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=M2scCRdnRsCnmeQJPDDFBi4l1FdD/AeLZAw5pNxDAu/BQy46y52CqQdgeg7ByQ1vuB8QaPdCmTUOWE/vEBwXbXFGCk4CKeKgnxuYcX9v3oMeXGFwNaBw4vOJFUk5Amla6AAVGaMqCq+uj3MY4j0f2tkHWIpq7ELoSzt9uJTqaNA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GgisCwzc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GgisCwzc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D947C19423; Sat, 28 Feb 2026 17:40:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300400; bh=C7Bf/4SETKQRpPhhtzMAKhHgf2oEI1fWMYv2QqDhegk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GgisCwzcMkONW7ttGsVx5qjhcte/q8Q5Vc7tI1TYrLGUMgWBPxvZgazdBYyFiGKPN C6wekJzgfgRj0j4f5G9QDJ1t7Nl7USrM2Iba7/g8xnoSMt/DJVm8+NqHOUTCKUCEWc E/PA7vJxps0Jmqh73r3x/MZ97Ig0zDiMvRkuthP/Z14GUfz11Fw3WSrGgTxBMS6xI6 x2pvcQI69Xg3HnieckWeWZU5o2JNjoVqVamcI96KAVVIV1dwfZAuQcU+GQ4dwdiEeJ KS8YBVN1DxeAQsiOnLR7U/p5goATmYc8jaNweC9KMVodIKa5Eyh8we5IgOhxtPOknd yhmzHZgq8NYsA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vijendar Mukunda , "Mario Limonciello (AMD)" , Mark Brown , Sasha Levin Subject: [PATCH 6.19 438/844] ASoC: amd: amd_sdw: add machine driver quirk for Lenovo models Date: Sat, 28 Feb 2026 12:25:51 -0500 Message-ID: <20260228173244.1509663-439-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vijendar Mukunda [ Upstream commit 3acf517e1ae05ef66561b7a2782690387ce46e21 ] This patch adds a quirk to include the codec amplifier function for Lenovo models listed in the quirk table. Note: In these models, the RT722 codec amplifier is excluded, and an external amplifier is used instead. Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20260218104734.3641481-3-Vijendar.Mukunda@am= d.com Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/amd/acp/acp-sdw-legacy-mach.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/sound/soc/amd/acp/acp-sdw-legacy-mach.c b/sound/soc/amd/acp/ac= p-sdw-legacy-mach.c index fae94b9edd5a3..4f92de33a71a0 100644 --- a/sound/soc/amd/acp/acp-sdw-legacy-mach.c +++ b/sound/soc/amd/acp/acp-sdw-legacy-mach.c @@ -95,6 +95,22 @@ static const struct dmi_system_id soc_sdw_quirk_table[] = =3D { }, .driver_data =3D (void *)(ASOC_SDW_CODEC_SPKR), }, + { + .callback =3D soc_sdw_quirk_cb, + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "21YW"), + }, + .driver_data =3D (void *)(ASOC_SDW_CODEC_SPKR), + }, + { + .callback =3D soc_sdw_quirk_cb, + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "21YX"), + }, + .driver_data =3D (void *)(ASOC_SDW_CODEC_SPKR), + }, {} }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D04BB3CC9E6; Sat, 28 Feb 2026 17:40:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300401; cv=none; b=hHnW9EIHsoUQ6QPQFONL49fCg6oH7rycO4zO9tLd+uonrfYF5qqfclRW3YVa1bG45AE/pKTXqIn5iJfGGhJqaF02HhXjbNHM7NOHKaWtZ8Mzkv8a2BqiGugv+EMwFVFA2VrWOr06cO7N67/j9xgdHScW9R9aiDrXmt12rTh7r70= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300401; c=relaxed/simple; bh=FmRr01DdfDLLOruObW/tsEkSx9zOqwHGqIC11f0aC08=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SllG/tHRVN3owo8kirYPq9Bc2k+tuPjW607senmmZSWaMoDJNwElg4UQCsN0ZA0R4TUPGaMCIETz+G0a7ag0UEDRz2TOy2TDtOtkl1hd/DLev+5JwTbcqj4Byg1hkj9scCxErMwovQfZSWRuooDaVURqQhet1SONzGIsUyYiP9Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dAc0/8u+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dAc0/8u+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F0A5C2BC87; Sat, 28 Feb 2026 17:40:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300401; bh=FmRr01DdfDLLOruObW/tsEkSx9zOqwHGqIC11f0aC08=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dAc0/8u+nWgqAxCZgFhmefYpXaUDMKNASow7+AMki5N7PWemmcvWmx4Uv2u9kxpyU 2BqhRT1iJ/Ju6dDik3EVgOkCqJuSE5gnmA5GDnzmGsOhIn7XL0E2N/+fcX8sjZX7S2 uPVQyQ3soYOwVjv64CRXN77607NfLg+/Ixfrm0GebigIB9YPfPmvYU2K39wRSQ8pkz tEckAszNDNKsJcWEBqY/xvg6WzurrX3CqPJ/yozg+sAiLf+ZP7zjdqG/kED8NlY3CI kYSM4OcIOBrd2z3T4RxMPcxoxiBBoakEDsMW3tIJNRjQeMvbo4Ztp6khL+k4cA0ZvX IHKIYzqedsZ7A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Aaron Erhardt , Werner Sembach , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 439/844] ALSA: hda/hdmi: Add quirk for TUXEDO IBS14G6 Date: Sat, 28 Feb 2026 12:25:52 -0500 Message-ID: <20260228173244.1509663-440-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Aaron Erhardt [ Upstream commit d649c58bcad8fb9b749e3837136a201632fa109d ] Depending on the timing during boot, the BIOS might report wrong pin capabilities, which can lead to HDMI audio being disabled. Therefore, force HDMI audio connection on TUXEDO InfinityBook S 14 Gen6. Signed-off-by: Aaron Erhardt Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260218213234.429686-1-wse@tuxedocomputers.= com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/hda/codecs/hdmi/hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/hda/codecs/hdmi/hdmi.c b/sound/hda/codecs/hdmi/hdmi.c index 111c9b5335afc..c2e3adc7b3c00 100644 --- a/sound/hda/codecs/hdmi/hdmi.c +++ b/sound/hda/codecs/hdmi/hdmi.c @@ -1557,6 +1557,7 @@ static const struct snd_pci_quirk force_connect_list[= ] =3D { SND_PCI_QUIRK(0x1043, 0x86ae, "ASUS", 1), /* Z170 PRO */ SND_PCI_QUIRK(0x1043, 0x86c7, "ASUS", 1), /* Z170M PLUS */ SND_PCI_QUIRK(0x1462, 0xec94, "MS-7C94", 1), + SND_PCI_QUIRK(0x1558, 0x14a1, "TUXEDO InfinityBook S 14 Gen6", 1), SND_PCI_QUIRK(0x8086, 0x2060, "Intel NUC5CPYB", 1), SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", 1), {} --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 290993CCA1C; Sat, 28 Feb 2026 17:40:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300403; cv=none; b=LYUIXhq4/PdyFWl3c6i4NB371eV8dbzy7eFB+abiWdzJeIFZGaQwGj63W0iP25KJX+D1PZXDvifrQ01+audf6oqp6oEc6Je664JDZyfB+X27OdEolK3+0nmUKRoNfNTjpi7oRpQLwO0FW54wdZ+GnC8Tgt3+ALGIrdWzIUAZedI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300403; c=relaxed/simple; bh=XiDpqIsE+Q9+ban9oyun+ipydHoaR3GRXevI8VVtrhs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VD5wBXqzrt86h4cK1xcTt7jLOLqaf8QpzKUgSbIv0Vfs6SGJGXD8zG6O2Wq+skBDQeWNwinri8+g8j9LcnagvOX8UzNR02SKKMe+XQNmCTjvBQbvQlqVA38bPkNF7pjd61vpinzzpgmvtXBYCQxaC0GQTlKRkwmW+IoB5U0V3IU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vLcUp3uA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vLcUp3uA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02BC0C116D0; Sat, 28 Feb 2026 17:40:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300402; bh=XiDpqIsE+Q9+ban9oyun+ipydHoaR3GRXevI8VVtrhs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vLcUp3uAYY9Qr7DsNFKahKTKU/bR4D73HPn2nDLjunHEn0FdYCERnA3b4U6Lclx4e iT6hbNdRu0+iyq7aYqRYn8oEyzoLFPEJP50SS7e5iXuoSACQNw0C0ZnHwkZbHTzpgd GrsKmDYsYeGYrLnEvQE1gywc8VTfqQgUJowM9eSR6ptUuG3CAjPCgx5Uj+G6G8zJ0N TNfYEoHui6ClnwfymyDiB96nC3beqkSB10e3kAECsnXCkko5dsvroAdXjK74BalUiK I4PqzljK9cuIBtS137rWGNzxXRldpS08Z1Y40JLqofWHIqlZDG03nzVVjok53aswdJ yueP94m2LDXZA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnd Bergmann , Catalin Marinas , Dev Jain , Will Deacon , Sasha Levin Subject: [PATCH 6.19 440/844] arm64: hugetlbpage: avoid unused-but-set-parameter warning (gcc-16) Date: Sat, 28 Feb 2026 12:25:53 -0500 Message-ID: <20260228173244.1509663-441-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann [ Upstream commit 729a2e8e9ac47099a967567389cc9d73ef4194ca ] 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 use= d [-Werror=3Dunused-but-set-parameter=3D] 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 Signed-off-by: Arnd Bergmann Reviewed-by: Dev Jain Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/include/asm/pgtable.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgta= ble.h index 64d5f1d9cce96..5ab5fe3bef25e 100644 --- a/arch/arm64/include/asm/pgtable.h +++ b/arch/arm64/include/asm/pgtable.h @@ -179,8 +179,6 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t ph= ys) __pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(pr= ot)) =20 #define pte_none(pte) (!pte_val(pte)) -#define __pte_clear(mm, addr, ptep) \ - __set_pte(ptep, __pte(0)) #define pte_page(pte) (pfn_to_page(pte_pfn(pte))) =20 /* @@ -1320,6 +1318,13 @@ static inline bool pud_user_accessible_page(pud_t pu= d) /* * Atomic pte/pmd modifications. */ + +static inline void __pte_clear(struct mm_struct *mm, + unsigned long addr, pte_t *ptep) +{ + __set_pte(ptep, __pte(0)); +} + static inline int __ptep_test_and_clear_young(struct vm_area_struct *vma, unsigned long address, pte_t *ptep) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F144F3CD198; Sat, 28 Feb 2026 17:40:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300404; cv=none; b=Xd8Ceur94MpEfaustC7zZ2hEfxaOjNzf7AlRc0pfA/JrsV8dWkJK1clrz756gUV1e50/quJ3DUKAfErt/i1W4ZS4cXt4nQ5MF8D4ldmkq+n/jMX0LXnftU9RoNsZnBwJfIL7n3wparACiQL8xO35F2XGu2qnWqYR4FFThzJC4EY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300404; c=relaxed/simple; bh=JhcK1gvo4yTmYegjrZ9t6Zk3+B0vjGYbIhz1HG6nqHU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=u6ZVBvV1EzFzdNK/LgyDR8YyFX+QUHWQe29t/Qx2iIf9QqrkIL7C/21pkjnQbF0mLonMk5jF6sEZralBb9tfjlJXOcK+hlU8om/5LnHSzKzcJTkDYphakRxTIyz5rRNVNJ9m47g3RbLU90WoRxGgQ2zCXje9v8wK2/J9vA3dyog= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D0cQjw+M; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="D0cQjw+M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A790C2BC9E; Sat, 28 Feb 2026 17:40:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300403; bh=JhcK1gvo4yTmYegjrZ9t6Zk3+B0vjGYbIhz1HG6nqHU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D0cQjw+M4SGS2M23tZBwIT0EXBVL81jl8q6+FhJrbMjY5wKibDBlAe5oetVc/1DwN Tige9pIaGuAQJ8AeNBN6x9eOzvhY5b+prhGCGa5Yzl6bY8QBnr+I5dt/zu/BSOimrY U++8UsBnSwR7VFkXYvTnVL0fRUUGRGc31BRXwV4k9DC2wJTrCiObGatdA4R1/gCQpQ K2QgBqBvT+4vxgcq3dJMX521aGGnG7TtyctdunGzWK+nanRSfm/vIDCpsuOZOagSNz wxgCrFTS6SqfcK3XK2OQ+yaQLsRbv+XD5clO4Rot7gxZS4q/6m/2Q+6unkVYt+rsez AEpm8Re2DcBCA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alex Hung , Aurabindo Pillai , Ray Wu , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 441/844] drm/amd/display: Remove conditional for shaper 3DLUT power-on Date: Sat, 28 Feb 2026 12:25:54 -0500 Message-ID: <20260228173244.1509663-442-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alex Hung [ Upstream commit 1b38a87b8f8020e8ef4563e7752a64182b5a39b9 ] [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 Signed-off-by: Alex Hung Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/mpc/dcn32/dcn32_mpc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/mpc/dcn32/dcn32_mpc.c b/drivers= /gpu/drm/amd/display/dc/mpc/dcn32/dcn32_mpc.c index 83bbbf34bcac7..badcef027b846 100644 --- a/drivers/gpu/drm/amd/display/dc/mpc/dcn32/dcn32_mpc.c +++ b/drivers/gpu/drm/amd/display/dc/mpc/dcn32/dcn32_mpc.c @@ -724,8 +724,7 @@ bool mpc32_program_shaper( return false; } =20 - if (mpc->ctx->dc->debug.enable_mem_low_power.bits.mpc) - mpc32_power_on_shaper_3dlut(mpc, mpcc_id, true); + mpc32_power_on_shaper_3dlut(mpc, mpcc_id, true); =20 current_mode =3D mpc32_get_shaper_current(mpc, mpcc_id); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F20D3CD1BE; Sat, 28 Feb 2026 17:40:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300405; cv=none; b=R91ZXz87Jmq2/OhDnwZd1KuUc6xeUB3jcsnHbAZg3zyAlljqz6/wjeqIiQfHSH54vQEyNDCImG+IHoKcgo1tqkvUMakuJOirv/iGOFOKGHH2cmvStHw/oRBi3VPyf5RDfW0L7uMIf7fXvdwt8AzrjSBKDif2ATwgfQUUiTx+LyU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300405; c=relaxed/simple; bh=nGfWN/RyvxmqAuCr2FHXkxLg68q650iTb5z6WbxzE9w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GGLrmilgM9tPpCVh9yAF3Cpo1m+minkfSyEKjo8zASVjRcSFloc/BYW8RWC63NNF80x22Ur1skic1RX6GRA63Y4jRwOyPJoCzHHYPvFhrwrPLAOibwB3wOy7AqxL8OxAIApQFq55ybPAC4nxry+Y21uF+zMe07D++Z0nduN3Wio= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O53EaLrz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O53EaLrz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22F96C116D0; Sat, 28 Feb 2026 17:40:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300404; bh=nGfWN/RyvxmqAuCr2FHXkxLg68q650iTb5z6WbxzE9w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O53EaLrzlMs0u83WZlP8Rj6sAYU/7w6Cmyv41czsa+sGUAPpzWCLfR43wfFfPtdLO oB3Qzgf66ysr3qIkdpBGF5No4wlVUNaoyCfpiOmySnNYffyKZGGbIFPnx606uDAhqd 9t61nRqmekGeDZXtSHZ3HCPKUXOqqTzerBMqB2KsFB8e5FTUl7Yy/JMnHMdw31n9mo 1kW47DzCWQ4JGO6yckc0Z8zJnyYSRIcb5NOnvwHuMtf8K/XRYvwO4qJdmnT+RYeX8E 7H62nWUs+iDSXcyoBV6FX9ZJba+hC1Fn9ZXO2jeiZLy7fkpbmYpGJ4GE4VQbBPJdw+ 2uJRpPu8Q+w4A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Victor Zhao , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 442/844] drm/amdgpu: avoid sdma ring reset in sriov Date: Sat, 28 Feb 2026 12:25:55 -0500 Message-ID: <20260228173244.1509663-443-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Victor Zhao [ Upstream commit 5cc7bbd9f1b74d9fe2f7ac08d6ba0477e8d2d65f ] sdma ring reset is not supported in SRIOV. kfd driver does not check reset mask, and could queue sdma ring reset during unmap_queues_cpsch. Avoid the ring reset for sriov. Signed-off-by: Victor Zhao Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c b/drivers/gpu/drm/amd= /amdgpu/amdgpu_sdma.c index 8b8a04138711c..321310ba2c08e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c @@ -558,6 +558,9 @@ int amdgpu_sdma_reset_engine(struct amdgpu_device *adev= , uint32_t instance_id, struct amdgpu_ring *gfx_ring =3D &sdma_instance->ring; struct amdgpu_ring *page_ring =3D &sdma_instance->page; =20 + if (amdgpu_sriov_vf(adev)) + return -EOPNOTSUPP; + mutex_lock(&sdma_instance->engine_reset_mutex); =20 if (!caller_handles_kernel_queues) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D2FC73CD9EB; Sat, 28 Feb 2026 17:40:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300405; cv=none; b=dJDDuZvzTAR/HKz1qhZaibvjdFHotXDNv6eP4bo7mw/AOjtAkRhWNa/ZStPD1b2SBmT6tKTFu42ev/msLwmOn9hd6glmAJw/HVyzF9/U+1fkiltykxZdZxTlUzyokSzWv2Pq2Jgs/LHXUwGbQNd1HP6DnhkMrYbsl7G8kPHfhvY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300405; c=relaxed/simple; bh=9JOA6572BYDqfDjY//bb7H4d1r4XQRYQMbcpDHSnCOU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SpSb9jNbh5wb3R9BShlCxAbBbxrqBuXWGPlSZ2qJfGuaa063pJYH3kaMDhhwcesA+DxlvvtsiCt2KoVWJvexVy9ARwRuwNb0sc5ACgdZJYpV1MSVhmnFW3/eJD7iIqhJoGwtDsE2wB1At4NW79mevO4vH7rSu9O/UGFgYXMxJDo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EyilbVrN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EyilbVrN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00502C19425; Sat, 28 Feb 2026 17:40:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300405; bh=9JOA6572BYDqfDjY//bb7H4d1r4XQRYQMbcpDHSnCOU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EyilbVrNglLOg+OWxGZ0fECbxxFVKuBzL32kIXKAvp4PShzozdvym3fvebw65LSEk w+wkNDdBylY1LTqHMhaqIShLcd24Vfl9lO8ASWmbpzF/fLBQ5Z6/fJSthk3LPTt6mv o30kUIuYAHO/MNOPoP0y2I5r7kEez1oENE1enNjg9pP/FGVEAkpTue+2xQzncP4Fa7 /E4iDQZJyPRpAkntH4on1mOrwqWnipAbY/wMeQyh6Y9jioNfqk0AZI/6MwbU0iNaVX YxleJxnUXHW4fB6dqOrzIPzEoopTzF/EOwEqK6WC8LW+Soecqa7ZTcDEBTvaxyGoTH Od2nl/7RyCeyQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tomas Melin , Harini T , Michal Simek , Alexandre Belloni , Sasha Levin Subject: [PATCH 6.19 443/844] rtc: zynqmp: correct frequency value Date: Sat, 28 Feb 2026 12:25:56 -0500 Message-ID: <20260228173244.1509663-444-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tomas Melin [ Upstream commit 2724fb4d429cbb724dcb6fa17953040918ebe3a2 ] Fix calibration value in case a clock reference is provided. The actual calibration value written into register is frequency - 1. Reviewed-by: Harini T Tested-by: Harini T Signed-off-by: Tomas Melin Acked-by: Michal Simek Link: https://patch.msgid.link/20260122-zynqmp-rtc-updates-v4-1-d4edb966b49= 9@vaisala.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/rtc/rtc-zynqmp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index 3baa2b481d9f2..856bc1678e7d3 100644 --- a/drivers/rtc/rtc-zynqmp.c +++ b/drivers/rtc/rtc-zynqmp.c @@ -345,7 +345,10 @@ static int xlnx_rtc_probe(struct platform_device *pdev) &xrtcdev->freq); if (ret) xrtcdev->freq =3D RTC_CALIB_DEF; + } else { + xrtcdev->freq--; } + ret =3D readl(xrtcdev->reg_base + RTC_CALIB_RD); if (!ret) writel(xrtcdev->freq, (xrtcdev->reg_base + RTC_CALIB_WR)); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AEB6C3CD9FC; Sat, 28 Feb 2026 17:40:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300406; cv=none; b=uFjhlxg0x8cb7plDKsLqVBCl2pL28OGOLEezf7HbQSryX7aEF9XdFYSsS0ejeAU6hEa4ghNrCbRrvhWUHLCnTVw7N9a0kY10hba2jYKRze605a1sXigF5ubKKWcpQ4jzr5sDFbg21doZvaT/PLQ4jFHJgDHrcVY5fijlHga7rWY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300406; c=relaxed/simple; bh=stzw8+O1qLWHpiBs5B6E30/TaFmQDt6Mst2++3fJidA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lbAdyhXAkR695SsCtuGKbCV9zKSVayXmtjYQ0Lkc7FdWdalgQMKsP6TZCZUmy9C6TZnx5Kk6ctlLYwS7fJ8GBXdO2y/hIgU4fpZ+vI1gycjqC4XzRqrG7yVd/xGccice/dWXzYvXIQx0dQs91jUD8MABJW/w29IxmWQYVGwvjw8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IK2OiP3P; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IK2OiP3P" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02D4CC19423; Sat, 28 Feb 2026 17:40:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300406; bh=stzw8+O1qLWHpiBs5B6E30/TaFmQDt6Mst2++3fJidA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IK2OiP3PXrB5feiVfQCIpQF90/SbZkEl7gDXaeXFH3NQmnyu6MlNBwPF9Z3epuE4G qH0hplPEbBoZRUH0gAbzPiFBQua2i0nKHeFGsNhiX7oI9BsaHDCtztizWRHpSz8aXw obS1/5BGFAZLa+vs5rs2mctnwBV//fqh4dYi+0AJBxIAVjlIItjsPtqyDOjNKnC2r5 zJXsJ7Xv/dGxt6sCSo5aFsNCSGM/ucQUZ2j4D1LIyqx+rDVd9jXcE1AY2ExcjrsCPG o8rnYDFatl8SDnQpTIPjGBLwanxrZ2I3gNFTcwWAle4mOIMPoiZoj0FY4Z4pndflXK uWHHfJt/t+6Hg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Maciej Grochowski , Jon Mason , Sasha Levin Subject: [PATCH 6.19 444/844] ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access Date: Sat, 28 Feb 2026 12:25:57 -0500 Message-ID: <20260228173244.1509663-445-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Grochowski [ Upstream commit c8ba7ad2cc1c7b90570aa347b8ebbe279f1eface ] Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid. Signed-off-by: Maciej Grochowski Signed-off-by: Jon Mason Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c b/drivers/ntb/hw/mscc/n= tb_hw_switchtec.c index f851397b65d6e..f15ebab138144 100644 --- a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c +++ b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c @@ -1314,6 +1314,12 @@ static void switchtec_ntb_init_shared(struct switcht= ec_ntb *sndev) for (i =3D 0; i < sndev->nr_lut_mw; i++) { int idx =3D sndev->nr_direct_mw + i; =20 + if (idx >=3D MAX_MWS) { + dev_err(&sndev->stdev->dev, + "Total number of MW cannot be bigger than %d", MAX_MWS); + break; + } + sndev->self_shared->mw_sizes[idx] =3D LUT_SIZE; } } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8738E3CCA1C; Sat, 28 Feb 2026 17:40:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300407; cv=none; b=tODYUT1XgBE1mreFUnShJj55p4LidHn5Lc2EXqRUTzqx4QagWJvbDdoNq8o38XZQrAaylaWL6ZjWJMh8BAQWGiJ/aba8maezIdw4cWwm93dt5c51gCjd0Z2wFi2Te0PScBWZD7XsNFeeGuUH3jTeCYcbb9hJRjykvdla9JyWhkU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300407; c=relaxed/simple; bh=Bd41o2rswMZE6Q+rHhQPOTZy5oI39Vt0D1sCOpwwBwQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qUIns29tFiQAGYPousu/UT7PKh4Fzw5gGcqLP8lKysNoT1AhkqJKZ4fzPl65Ca1ZtjduyAy+vF7eTJ8pYHWEfgQOs+sDKMMNkdnteHghxKoLbxc5QDLXxEL+4fVUnc+aeUCyVQ3dUVPqqSS13BhjF7cBQodT2USdHfzYWuAbUwk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Bvj2UH7O; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Bvj2UH7O" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D486DC116D0; Sat, 28 Feb 2026 17:40:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300407; bh=Bd41o2rswMZE6Q+rHhQPOTZy5oI39Vt0D1sCOpwwBwQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Bvj2UH7OrIoDjYQoKd4ydUAF7kflg/RU7G8gSA3fCZ4XBI62jsuh2Xaepd7KfJwJX KRFs0yXb3j5m0Lr1kqxSxff/NaNybPvMgpEM1RvXYiOKy6AQEyQCJSM3arxS7bTNfw 4hO4HParqNi7KU1AD8q8gF+tFlyGkM7M4zrV0KiaQmAMi/K3GBNAwVyGM647ijmyVx I8dO6rZ855O9HNZjSwQmz46wSjPJ/lqZEsWsuSWh/JP2ZFUfKpRZNhC05Z8E8mFJRr FP1Alj/NANWPT6oJxbeSynxo81sJ5f3X2CSXgrNteiwxbhoUU554Rrud/BalhxkhTv WS/Tzo9T5i7jQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Maciej Grochowski , Jon Mason , Sasha Levin Subject: [PATCH 6.19 445/844] ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut Date: Sat, 28 Feb 2026 12:25:58 -0500 Message-ID: <20260228173244.1509663-446-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Grochowski [ Upstream commit 186615f8855a0be4ee7d3fcd09a8ecc10e783b08 ] Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value. Signed-off-by: Maciej Grochowski Signed-off-by: Jon Mason Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c b/drivers/ntb/hw/mscc/n= tb_hw_switchtec.c index f15ebab138144..0536521fa6ccc 100644 --- a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c +++ b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c @@ -1202,7 +1202,8 @@ static void switchtec_ntb_init_mw(struct switchtec_nt= b *sndev) sndev->mmio_self_ctrl); =20 sndev->nr_lut_mw =3D ioread16(&sndev->mmio_self_ctrl->lut_table_entries); - sndev->nr_lut_mw =3D rounddown_pow_of_two(sndev->nr_lut_mw); + if (sndev->nr_lut_mw) + sndev->nr_lut_mw =3D rounddown_pow_of_two(sndev->nr_lut_mw); =20 dev_dbg(&sndev->stdev->dev, "MWs: %d direct, %d lut\n", sndev->nr_direct_mw, sndev->nr_lut_mw); @@ -1212,7 +1213,8 @@ static void switchtec_ntb_init_mw(struct switchtec_nt= b *sndev) =20 sndev->peer_nr_lut_mw =3D ioread16(&sndev->mmio_peer_ctrl->lut_table_entries); - sndev->peer_nr_lut_mw =3D rounddown_pow_of_two(sndev->peer_nr_lut_mw); + if (sndev->peer_nr_lut_mw) + sndev->peer_nr_lut_mw =3D rounddown_pow_of_two(sndev->peer_nr_lut_mw); =20 dev_dbg(&sndev->stdev->dev, "Peer MWs: %d direct, %d lut\n", sndev->peer_nr_direct_mw, sndev->peer_nr_lut_mw); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 912323CE1F7; Sat, 28 Feb 2026 17:40:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300408; cv=none; b=WN9fOwl1nZXlAljRyAjOlAF/Jr2wLoFFJrZB+3bCwTDbtl9XlA/zMCtpaFRGfc+2Pcf1drM6LuiM92lIBf8azekuUVaE264SIjyg4LM3yVZ4v9QurYEPeaRGTd0Qr+aW9wSOq/dGb25NbHDXlBaAsLhzZnp3H0l16DFeUOHLjrc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300408; c=relaxed/simple; bh=foTziOL5uMZZVG7EYhfaZnbTwa5BlJ3I3QTgsbVTeUw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UteMM+FdGP4zPWix/JO53bxcgsk2gcGj0AQTQZUNq7G68M4EAX8BR06tQET9qVdvcqYh/ZtZCvkWMh40AVpo7Zb3T8/Dx2gxDcncTpzZp0Uoxh3Sp61wzuiN9gF+lq6GOu4X0/GWLzqryOs5jW0I3XBD1xDPaL1VE8DVpeEfD+A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RiOcZRES; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RiOcZRES" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFC00C19424; Sat, 28 Feb 2026 17:40:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300408; bh=foTziOL5uMZZVG7EYhfaZnbTwa5BlJ3I3QTgsbVTeUw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RiOcZREStqDCeCBhKynyYncTfHZWBh5xiTPY82RcuiYC9GcvDOF9J6hw3giMgsEfj Z3OI36x5E90r7eAy9Yyh8I7uSN9iHsRAtS4/mxBGii6Qj51OMK7xtlfTuAF3zAMr0h r9F/XWhJQgZWuxWhVPdgYXblIcmJYhl3i++Ek+yMMihkAOyiY1UyyW6C6mytku6ZOt zU+f4Md0CNAw70jJyNUmCSyHNA4jEiGkgL6cR1K32R4N6PBuQfkStQK4F+RSEC6lQJ WAAnA86hdF+GdFoo7d4Tw5y6gfJeLgdi2fND9OqmRbeK+waXIdsATN6cAbreBrIPMp us2/L1vsDgWnA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ankit Soni , Srikanth Aithal , Vasant Hegde , Joerg Roedel , Sasha Levin Subject: [PATCH 6.19 446/844] iommu/amd: serialize sequence allocation under concurrent TLB invalidations Date: Sat, 28 Feb 2026 12:25:59 -0500 Message-ID: <20260228173244.1509663-447-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ankit Soni [ Upstream commit 9e249c48412828e807afddc21527eb734dc9bd3d ] With concurrent TLB invalidations, completion wait randomly gets timed out because cmd_sem_val was incremented outside the IOMMU spinlock, allowing CMD_COMPL_WAIT commands to be queued out of sequence and breaking the ordering assumption in wait_on_sem(). Move the cmd_sem_val increment under iommu->lock so completion sequence allocation is serialized with command queuing. And remove the unnecessary return. Fixes: d2a0cac10597 ("iommu/amd: move wait_on_sem() out of spinlock") Tested-by: Srikanth Aithal Reported-by: Srikanth Aithal Signed-off-by: Ankit Soni Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iommu/amd/amd_iommu_types.h | 2 +- drivers/iommu/amd/init.c | 2 +- drivers/iommu/amd/iommu.c | 18 ++++++++++++------ 3 files changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_io= mmu_types.h index 320733e7d8b42..3b09da3ffb74f 100644 --- a/drivers/iommu/amd/amd_iommu_types.h +++ b/drivers/iommu/amd/amd_iommu_types.h @@ -706,7 +706,7 @@ struct amd_iommu { =20 u32 flags; volatile u64 *cmd_sem; - atomic64_t cmd_sem_val; + u64 cmd_sem_val; /* * Track physical address to directly use it in build_completion_wait() * and avoid adding any special checks and handling for kdump. diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index 62a7a718acf8f..58d6f5ae155f2 100644 --- a/drivers/iommu/amd/init.c +++ b/drivers/iommu/amd/init.c @@ -1877,7 +1877,7 @@ static int __init init_iommu_one(struct amd_iommu *io= mmu, struct ivhd_header *h, iommu->pci_seg =3D pci_seg; =20 raw_spin_lock_init(&iommu->lock); - atomic64_set(&iommu->cmd_sem_val, 0); + iommu->cmd_sem_val =3D 0; =20 /* Add IOMMU to internal data structures */ list_add_tail(&iommu->list, &amd_iommu_list); diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index c5f7e003d01c9..e216b5a13d49d 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -1417,6 +1417,12 @@ static int iommu_queue_command(struct amd_iommu *iom= mu, struct iommu_cmd *cmd) return iommu_queue_command_sync(iommu, cmd, true); } =20 +static u64 get_cmdsem_val(struct amd_iommu *iommu) +{ + lockdep_assert_held(&iommu->lock); + return ++iommu->cmd_sem_val; +} + /* * This function queues a completion wait command into the command * buffer of an IOMMU @@ -1431,11 +1437,11 @@ static int iommu_completion_wait(struct amd_iommu *= iommu) if (!iommu->need_sync) return 0; =20 - data =3D atomic64_inc_return(&iommu->cmd_sem_val); - build_completion_wait(&cmd, iommu, data); - raw_spin_lock_irqsave(&iommu->lock, flags); =20 + data =3D get_cmdsem_val(iommu); + build_completion_wait(&cmd, iommu, data); + ret =3D __iommu_queue_command_sync(iommu, &cmd, false); raw_spin_unlock_irqrestore(&iommu->lock, flags); =20 @@ -3113,10 +3119,11 @@ static void iommu_flush_irt_and_complete(struct amd= _iommu *iommu, u16 devid) return; =20 build_inv_irt(&cmd, devid); - data =3D atomic64_inc_return(&iommu->cmd_sem_val); - build_completion_wait(&cmd2, iommu, data); =20 raw_spin_lock_irqsave(&iommu->lock, flags); + data =3D get_cmdsem_val(iommu); + build_completion_wait(&cmd2, iommu, data); + ret =3D __iommu_queue_command_sync(iommu, &cmd, true); if (ret) goto out_err; @@ -3130,7 +3137,6 @@ static void iommu_flush_irt_and_complete(struct amd_i= ommu *iommu, u16 devid) =20 out_err: raw_spin_unlock_irqrestore(&iommu->lock, flags); - return; } =20 static inline u8 iommu_get_int_tablen(struct iommu_dev_data *dev_data) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B301F3CE215; Sat, 28 Feb 2026 17:40:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300409; cv=none; b=jQfE2gVy1r0Hwwf+YeBLV2sEJpmIzIFBFfc5R/O2v+R05yTcv6LxaM2+wcsryHF8Ay/BYqxepeEpS7dYNHcr5ENGt5RURlmZNyzs0PMrykYJENoRLHxSblw/UlJ7EJY8ppCpbOeCpbIF9JAf4nOJJ26ZsF7iT2U8OmylHhjnEII= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300409; c=relaxed/simple; bh=nq9qkBe4okAHoTat6O8vzfoeylYqMxsyWvi3bxn5F+M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=it+H8RZWXMzuBhi8r7Dn52ODlEwJDwAc2nDFWGpQbMVF8M0Klgh35zFjUuWMkBLBbdBsqC7ZFmqiT00yzrDw6qAzBZt8VryYZ3lOt11hBknzJkP7cWydIcsbc48iQm/TNfF+sRGNMUq8xzyz3nQnADy+uSD1yzKNePLejNDA5LU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VyJR7ZVt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VyJR7ZVt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8D0EC19423; Sat, 28 Feb 2026 17:40:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300409; bh=nq9qkBe4okAHoTat6O8vzfoeylYqMxsyWvi3bxn5F+M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VyJR7ZVtKWmAvQ1nCGMKrY2M49uHJ3a4za/bz2ctZ4KMf3bmfh1EfQjNShMoqK71A hYjKfLr7N2zGgvl9Fj2+ggYpgTvrcxzNHriuWDs/hBiUhLJhmvclxXLtPkupDDGRVc DsBgSHKTtzlvYGyW8riKZfDSDQRGxLV7LaeBs0Zer54AlSxninx172BCVkXf5dbCa8 N4qctfcYvUIMvXfpoSCboTqUTxnWiHJhQVPa53VZkPqVLczQb+AugcEOE6oMMVw8hV /PFltgl0AKxKiTzIoa4xPNw1B7afyJpylMKiwwrL2XDH8qtKk8fpYvHTOQ5Ar4ncV7 skNloilRIYqZA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiayuan Chen , syzbot+e136d86d34b42399a8b1@syzkaller.appspotmail.com, Jiayuan Chen , Simon Horman , Steffen Klassert , Sasha Levin Subject: [PATCH 6.19 447/844] xfrm6: fix uninitialized saddr in xfrm6_get_saddr() Date: Sat, 28 Feb 2026 12:26:00 -0500 Message-ID: <20260228173244.1509663-448-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiayuan Chen [ Upstream commit 1799d8abeabc68ec05679292aaf6cba93b343c05 ] xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error. Fixes: a1e59abf8249 ("[XFRM]: Fix wildcard as tunnel source") Reported-by: syzbot+e136d86d34b42399a8b1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68bf1024.a70a0220.7a912.02c2.GAE@google= .com/T/ Signed-off-by: Jiayuan Chen Signed-off-by: Jiayuan Chen Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/ipv6/xfrm6_policy.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c index 1f19b6f14484c..125ea9a5b8a08 100644 --- a/net/ipv6/xfrm6_policy.c +++ b/net/ipv6/xfrm6_policy.c @@ -57,6 +57,7 @@ static int xfrm6_get_saddr(xfrm_address_t *saddr, struct dst_entry *dst; struct net_device *dev; struct inet6_dev *idev; + int err; =20 dst =3D xfrm6_dst_lookup(params); if (IS_ERR(dst)) @@ -68,9 +69,11 @@ static int xfrm6_get_saddr(xfrm_address_t *saddr, return -EHOSTUNREACH; } dev =3D idev->dev; - ipv6_dev_get_saddr(dev_net(dev), dev, ¶ms->daddr->in6, 0, - &saddr->in6); + err =3D ipv6_dev_get_saddr(dev_net(dev), dev, ¶ms->daddr->in6, 0, + &saddr->in6); dst_release(dst); + if (err) + return -EHOSTUNREACH; return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7AFA3CEAE5; Sat, 28 Feb 2026 17:40:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300411; cv=none; b=rKGL0lcgaNsP4VSNo8oomba78/6oalQeqjJ/OfRDygkY0tsiQe4tOP2M1WCgDA+J2i/HTybW90IV6DNJS7nmv+hO90K8UZwWpDvpyLbLMdvx6ZQ4fCNhx92cGt6aeRyrmbxCI6Esq8ePE5uf5hDCg30ZIemfMwfyQC6/J1U1zI0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300411; c=relaxed/simple; bh=fQBx7ID8R19kwDXm1s3pbxKnmBmO0qJDPrYFYhjrKog=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GknIFesxDQn2rKWKS3j8rYaAlyT9jKcHsQyGTkcbHx4a9wRS18EHj9/dSCQd9JrvRMVJBVQjXjQqhZfFcF7J6fTjL9rj6wXiDmFRiB/VkitVMQOZylcSA3dG6y/FVl/S1DFXzhSdoCzRFQv5kWKX++Sc9r7q79OiLB/faXsQkOw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZctO02JV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZctO02JV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D96FCC116D0; Sat, 28 Feb 2026 17:40:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300410; bh=fQBx7ID8R19kwDXm1s3pbxKnmBmO0qJDPrYFYhjrKog=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZctO02JVnkpfHA+ZKzJI1+QWKpcAdm9progQ5iz6WbhKJMmwFHhb7F1NeL1KqQeod wsfviIcasfVkMbl9liBo4oe+xncuxgA1hif2QLronTme3Rq6TFgL/MAY/ymleb4sB2 KxUNdFHu9F2xJ3NJ5i5wcMFlbZbx/bIVakhjwiNjq7F15mYw06XKKDVmO2gIjg0G3d 78zQy+TuCwvr8Kcpz5a9i5/sg2lIqehvvmoSrlyCECgfPp6FthAcaNarKJG8566dco +scrKndzpT+IzuUCnplc+PQx/P19tVQDCTCKZhSeMcrLhrNBFJaqjLHo1gtnC29kMB Yec2nMdd98rdw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Leon Romanovsky , Jianbo Liu , Cosmin Ratiu , Tariq Toukan , Simon Horman , Steffen Klassert , Sasha Levin Subject: [PATCH 6.19 448/844] xfrm: skip templates check for packet offload tunnel mode Date: Sat, 28 Feb 2026 12:26:01 -0500 Message-ID: <20260228173244.1509663-449-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Leon Romanovsky [ Upstream commit 0a4524bc69882a4ddb235bb6b279597721bda197 ] In packet offload, hardware is responsible to check templates. The result of its operation is forwarded through secpath by relevant drivers. That secpath is actually removed in __xfrm_policy_check2(). In case packet is forwarded, this secpath is reset in RX, but pushed again to TX where policy is rechecked again against dummy secpath in xfrm_policy_ok(). Such situation causes to unexpected XfrmInTmplMismatch increase. As a solution, simply skip template mismatch check. Fixes: 600258d555f0 ("xfrm: delete intermediate secpath entry in packet off= load mode") Signed-off-by: Leon Romanovsky Reviewed-by: Jianbo Liu Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/xfrm/xfrm_policy.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c index 62486f8669752..5428185196a1f 100644 --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -3801,8 +3801,8 @@ int __xfrm_policy_check(struct sock *sk, int dir, str= uct sk_buff *skb, struct xfrm_tmpl *tp[XFRM_MAX_DEPTH]; struct xfrm_tmpl *stp[XFRM_MAX_DEPTH]; struct xfrm_tmpl **tpp =3D tp; + int i, k =3D 0; int ti =3D 0; - int i, k; =20 sp =3D skb_sec_path(skb); if (!sp) @@ -3828,6 +3828,12 @@ int __xfrm_policy_check(struct sock *sk, int dir, st= ruct sk_buff *skb, tpp =3D stp; } =20 + if (pol->xdo.type =3D=3D XFRM_DEV_OFFLOAD_PACKET && sp =3D=3D &dummy) + /* This policy template was already checked by HW + * and secpath was removed in __xfrm_policy_check2. + */ + goto out; + /* For each tunnel xfrm, find the first matching tmpl. * For each tmpl before that, find corresponding xfrm. * Order is _important_. Later we will implement @@ -3837,7 +3843,7 @@ int __xfrm_policy_check(struct sock *sk, int dir, str= uct sk_buff *skb, * verified to allow them to be skipped in future policy * checks (e.g. nested tunnels). */ - for (i =3D xfrm_nr-1, k =3D 0; i >=3D 0; i--) { + for (i =3D xfrm_nr - 1; i >=3D 0; i--) { k =3D xfrm_policy_ok(tpp[i], sp, k, family, if_id); if (k < 0) { if (k < -1) @@ -3853,6 +3859,7 @@ int __xfrm_policy_check(struct sock *sk, int dir, str= uct sk_buff *skb, goto reject; } =20 +out: xfrm_pols_put(pols, npols); sp->verified_cnt =3D k; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C34D23CEAFC; Sat, 28 Feb 2026 17:40:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300411; cv=none; b=Okogn+HynCrnpx5jKBxyzLZAX85HWqH5mqQ67h9gffQIaj2h3PGTQ7lrgwNyyvHtOgoHlhYuSrja9j2AJxQEYWj7Y4koixzycDjAMtbykvUSSk23UL2yt+9NYeX3ghpd4qhnfHrUR3AbbrO+cbkUfgX5a7X0xpT/3w6uiMQQLhc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300411; c=relaxed/simple; bh=f+9w+xIfsNKQxYYkTRobj6+SBwpLWJTstDUHok5rPqQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JpbhCpZdXWOLLKcD2NUyNDTa4GIc1AHLos6QZwXWmS/1HmTy6g5wwylcfcSWvs7EH3AiHLG4kMamcr8Gp2OHgxx07jWek7zFqvFDRPO18jxwB/NR7CZT7MHxS2YIkishD2JLb5TccCDb/gYltn3Es24DbXj+BMYyISFjQGFcufk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GM/tx2LT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GM/tx2LT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B5E7C19423; Sat, 28 Feb 2026 17:40:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300411; bh=f+9w+xIfsNKQxYYkTRobj6+SBwpLWJTstDUHok5rPqQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GM/tx2LT9fgAV2sudR7/Vze15lqiJK/qgRpzHA0k8RPCvCLEKaAq8ytMs5UNDBvTm c5+feLtVZ+vNL1KWJ37x4hdbLFolOrwLAk144G4OOIs7OuCb2/QrpwkziDTVNMDNGL MNCKCHT6j0D2m10Q3cX3Vnh2xr0tySZm4za+6B6oGc5PlIGBs3jxAO1a92xWGgz5Eu OozckL7GYM1oEukJjkT0hat8fJCEs5xYXy9Z5CYD2ehFFC9Eh2Kej56z/kKR+nrCE8 PK31YutYbaFM3q11OutsIN+2LEvlwrnbT+8xwyXK8FlK8ly4CD3WNJT4MQxS0fETrP laTQFsVxAehbg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Matt Johnston , Corey Minyard , Sasha Levin Subject: [PATCH 6.19 449/844] ipmi: ipmb: initialise event handler read bytes Date: Sat, 28 Feb 2026 12:26:02 -0500 Message-ID: <20260228173244.1509663-450-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Matt Johnston [ Upstream commit 9f235ccecd03c436cb1683eac16b12f119e54aa9 ] IPMB doesn't use i2c reads, but the handler needs to set a value. Otherwise an i2c read will return an uninitialised value from the bus driver. Fixes: 63c4eb347164 ("ipmi:ipmb: Add initial support for IPMI over IPMB") Signed-off-by: Matt Johnston Message-ID: <20260113-ipmb-read-init-v1-1-a9cbce7b94e3@codeconstruct.com.au> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/char/ipmi/ipmi_ipmb.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/char/ipmi/ipmi_ipmb.c b/drivers/char/ipmi/ipmi_ipmb.c index 3a51e58b24875..28818952a7a4b 100644 --- a/drivers/char/ipmi/ipmi_ipmb.c +++ b/drivers/char/ipmi/ipmi_ipmb.c @@ -202,11 +202,16 @@ static int ipmi_ipmb_slave_cb(struct i2c_client *clie= nt, break; =20 case I2C_SLAVE_READ_REQUESTED: + *val =3D 0xff; + ipmi_ipmb_check_msg_done(iidev); + break; + case I2C_SLAVE_STOP: ipmi_ipmb_check_msg_done(iidev); break; =20 case I2C_SLAVE_READ_PROCESSED: + *val =3D 0xff; break; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C3A203CEB14; Sat, 28 Feb 2026 17:40:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300412; cv=none; b=X1cxV+foDwJAoiAiKOiVOSPJiNNqOf1QYHAD5eeTgCmEpsIssxje9uZ8pxNp1Tndx6cRukGXgcfUkumK9tnNT8/dWpDGX7lvzWH6ZwgoFbtzUcg0n+NSSsPB71G1eIPdVZ86lL16gZxX74MgUO1yEvGuCF0ZZIPdQsJbTj0J0cE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300412; c=relaxed/simple; bh=SrC1HFLWc/goT+GjWOISSRyEcH/2eDN1Im7wikqoMHo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=O2FJ5s2OVlrvxYJR1yubJkMswk4zDJ39VWjUlpt45xKHJrZopbn8cV+fokGm4UfXh1w1vHb7eixAr7v3zaU+O89GhRveHrAd5JJKgFCajSrySuetC53VURQzS7MHWuB86x67NX6QWA7jePm9EFT+MZOFIRo8M55Cx7+Asw/SpnU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j8xjT1xd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j8xjT1xd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E80C1C116D0; Sat, 28 Feb 2026 17:40:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300412; bh=SrC1HFLWc/goT+GjWOISSRyEcH/2eDN1Im7wikqoMHo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j8xjT1xdkoF+R02YuJD1nOPrCVjeGxlvWcGBiiwuwR0SAh3dWXjdd2P7nOTA0uSKO aTu3lfGognugZqWEE/bU85WowR7KhJp2jrQfx3H9rYEszDXo+0foRQX4SQwn58eBHE Y2iUwQr5EahU9fSnk9aLqm6DLsCR8mrX4s0g4Aczt51oV/FzE69N7yqRbVUnSnyIGE Hrb6Xig83Dyk/xmakFHbXAYS19Xq36crhZ+B15ZpiIIeyR9y1kPl6nmTx2OsoIWElH rkDxi2TzR0KIagb+pg+1RRSbl3MI90jSHNAsu9S/6JTcLLt6CkmhlVsPmGw3yeZc+v deNfMzVBnu4Hg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tetsuo Handa , syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com, Sabrina Dubroca , Steffen Klassert , Sasha Levin Subject: [PATCH 6.19 450/844] xfrm: always flush state and policy upon NETDEV_UNREGISTER event Date: Sat, 28 Feb 2026 12:26:03 -0500 Message-ID: <20260228173244.1509663-451-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tetsuo Handa [ Upstream commit 4efa91a28576054aae0e6dad9cba8fed8293aef8 ] syzbot is reporting that "struct xfrm_state" refcount is leaking. unregister_netdevice: waiting for netdevsim0 to become free. Usage count = =3D 2 ref_tracker: netdev@ffff888052f24618 has 1/1 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_tracker_alloc include/linux/netdevice.h:4412 [inline] xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316 xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline] xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022 xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550 xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646 __sys_sendmsg+0x16d/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f This is because commit d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") implemented xfrm_dev_unregister() as no-op despite xfrm_dev_state_add() from xfrm_state_construct() acquires a reference to "struct net_device". I guess that that commit expected that NETDEV_DOWN event is fired before NETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add() is called only if (dev->features & NETIF_F_HW_ESP) !=3D 0. Sabrina Dubroca identified steps to reproduce the same symptoms as below. echo 0 > /sys/bus/netdevsim/new_device dev=3D$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/) ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \ spi 0x1000 mode tunnel aead 'rfc4106(gcm(aes))' $key 128 \ offload crypto dev $dev dir out ethtool -K $dev esp-hw-offload off echo 0 > /sys/bus/netdevsim/del_device Like these steps indicate, the NETIF_F_HW_ESP bit can be cleared after xfrm_dev_state_add() acquired a reference to "struct net_device". Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bit when acquiring a reference to "struct net_device". Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device") re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but that commit for unknown reason chose to share xfrm_dev_down() between the NETDEV_DOWN event and the NETDEV_UNREGISTER event. I guess that that commit missed the behavior in the previous paragraph. Therefore, we need to re-introduce xfrm_dev_unregister() in order to release the reference to "struct net_device" by unconditionally flushing state and policy. Reported-by: syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D881d65229ca4f9ae8c84 Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") Cc: Sabrina Dubroca Signed-off-by: Tetsuo Handa Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/xfrm/xfrm_device.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c index 52ae0e034d29e..550457e4c4f01 100644 --- a/net/xfrm/xfrm_device.c +++ b/net/xfrm/xfrm_device.c @@ -544,6 +544,14 @@ static int xfrm_dev_down(struct net_device *dev) return NOTIFY_DONE; } =20 +static int xfrm_dev_unregister(struct net_device *dev) +{ + xfrm_dev_state_flush(dev_net(dev), dev, true); + xfrm_dev_policy_flush(dev_net(dev), dev, true); + + return NOTIFY_DONE; +} + static int xfrm_dev_event(struct notifier_block *this, unsigned long event= , void *ptr) { struct net_device *dev =3D netdev_notifier_info_to_dev(ptr); @@ -556,8 +564,10 @@ static int xfrm_dev_event(struct notifier_block *this,= unsigned long event, void return xfrm_api_check(dev); =20 case NETDEV_DOWN: - case NETDEV_UNREGISTER: return xfrm_dev_down(dev); + + case NETDEV_UNREGISTER: + return xfrm_dev_unregister(dev); } return NOTIFY_DONE; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3E053CF365; Sat, 28 Feb 2026 17:40:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300413; cv=none; b=TPsPAswounpnyyT46wim6N8t5tt5s9mOPPLkOnIwTnErboU3dewbDFjFBafA15DVe6m4QrtQ16D6GMwe2oZPcMv1KoNzTnaoqab4yT8qtwAAQMlglrHOvju3jyZLQnabR1So9OiPCgAjPSki+aWb8AAqLyAx4z0iiyFlHIBgSwE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300413; c=relaxed/simple; bh=CHIQ8RFlYm6XssHKC0qEZNneuTPqhYyW6GTW/jhvNzA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XvG0Rcge6vsZQGm+nHmuHwNiZRkw04Eq4ccl96azMzBNfwmmfMfFAn0XmGvFhYRGkLUUgIdzgKhgHOXeyhcmlRm12XUUGUduzG1MFYBBWGpwc0PECshluior+K+QP5P3+yOAsYXdYJwsK7qJnG0ErN810AmcNJ5aphh9YQD+4Go= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tcfVUVws; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tcfVUVws" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAB35C116D0; Sat, 28 Feb 2026 17:40:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300413; bh=CHIQ8RFlYm6XssHKC0qEZNneuTPqhYyW6GTW/jhvNzA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tcfVUVwsKhsMksy0DGoRl+BccbjaLRkRCy/Y7EcZMlNJpBYqCznBv9SVsOcK2wdPk AV+7+VPj0cr/9VWivfTmWUcbuCV5XiPa9xv+65ODKjNltz6ZpDhsPHHk8/qnhjDxxe 8pzMSa8PtUBDS9ZCDPVPsJ5pUKLHT/ESfjsDGjlgU/Ec/RNXyNaeadQpnnEdK5yINZ fa9sWYoJFxZRtztvJReZoiVy+OL4KDwwy2Dq2NryUUPQju30wLEilxNgxhEthqlIt7 7wJ5W5xVQsCHUaDdpNM+TnCdOkS2E8zXKeBdxBOKIE3MFkV93Z8pfahlfrauWNlj/Q CfJ3N0R4EAbjw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Huacai Chen , Jan Kara , Christian Brauner , Sasha Levin Subject: [PATCH 6.19 451/844] writeback: Fix wakeup and logging timeouts for !DETECT_HUNG_TASK Date: Sat, 28 Feb 2026 12:26:04 -0500 Message-ID: <20260228173244.1509663-452-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Huacai Chen [ Upstream commit 9eed043d10f17301c1b5141e16bb98a85a8fd07e ] Recent changes of fs-writeback cause such warnings if DETECT_HUNG_TASK is not enabled: INFO: The task sync:1342 has been waiting for writeback completion for more= than 1 seconds. The reason is sysctl_hung_task_timeout_secs is 0 when DETECT_HUNG_TASK is not enabled, then it causes the warning message even if the writeback lasts for only one second. Guard the wakeup and logging with "#ifdef CONFIG_DETECT_HUNG_TASK" can eliminate the warning messages. But on the other hand, it is possible that sysctl_hung_task_timeout_secs be also 0 when DETECT_HUNG_TASK is enabled. So let's just check the value of sysctl_hung_task_timeout_secs to decide whether do wakeup and logging. Fixes: 1888635532fb ("writeback: Wake up waiting tasks when finishing the w= riteback of a chunk.") Fixes: d6e621590764 ("writeback: Add logging for slow writeback (exceeds sy= sctl_hung_task_timeout_secs)") Signed-off-by: Huacai Chen Link: https://patch.msgid.link/20260203094014.2273240-1-chenhuacai@loongson= .cn Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/fs-writeback.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 5444fc706ac7d..79b02ac66ac6d 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -198,10 +198,11 @@ static void wb_queue_work(struct bdi_writeback *wb, =20 static bool wb_wait_for_completion_cb(struct wb_completion *done) { + unsigned long timeout =3D sysctl_hung_task_timeout_secs; unsigned long waited_secs =3D (jiffies - done->wait_start) / HZ; =20 done->progress_stamp =3D jiffies; - if (waited_secs > sysctl_hung_task_timeout_secs) + if (timeout && (waited_secs > timeout)) pr_info("INFO: The task %s:%d has been waiting for writeback " "completion for more than %lu seconds.", current->comm, current->pid, waited_secs); @@ -1944,6 +1945,7 @@ static long writeback_sb_inodes(struct super_block *s= b, .range_end =3D LLONG_MAX, }; unsigned long start_time =3D jiffies; + unsigned long timeout =3D sysctl_hung_task_timeout_secs; long write_chunk; long total_wrote =3D 0; /* count both pages and inodes */ unsigned long dirtied_before =3D jiffies; @@ -2030,9 +2032,8 @@ static long writeback_sb_inodes(struct super_block *s= b, __writeback_single_inode(inode, &wbc); =20 /* Report progress to inform the hung task detector of the progress. */ - if (work->done && work->done->progress_stamp && - (jiffies - work->done->progress_stamp) > HZ * - sysctl_hung_task_timeout_secs / 2) + if (work->done && work->done->progress_stamp && timeout && + (jiffies - work->done->progress_stamp) > HZ * timeout / 2) wake_up_all(work->done->waitq); =20 wbc_detach_inode(&wbc); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B861E3CF381; Sat, 28 Feb 2026 17:40:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300414; cv=none; b=IfGHSTq6mcY30vEe0AJ0WUSW1/NYP5PozWvvVNjd2fOr4RSISpwpqSD7020wA/qN3yeRHvgmcG8zFFVTO8KqUI3wuKyCpJkp0RT5HjBPjaHhs5ip/rv2rox7chlOODaQtnOpO2E/jAabIX68uBI1nfrUtcyoTLkK/k8iMp0cTZY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300414; c=relaxed/simple; bh=Mkr7txylNClnI/ikhiqTFcjnIOLJ2QwjG46nz1JZw7E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ufNtVDmFKAw9ZjA90sxTyQNl6zvfQsibI/yBJ5kzjap8jg6CPlXH2D5IszIex26Dqd4fLoUi3DV37d0XCwCnlg5azWgr0Yb5kq6MkK73qve3mZXpWNBzuVwr1c4j7Q2uIsCZbB94rzxEIuKNnVaA8QoiOwu6F3rSGIhdLVzPnww= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G8Y+gnt8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="G8Y+gnt8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD05FC19425; Sat, 28 Feb 2026 17:40:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300414; bh=Mkr7txylNClnI/ikhiqTFcjnIOLJ2QwjG46nz1JZw7E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G8Y+gnt8R4UGrKpaVgpZrVhI/pNAg8SRkbfAcFIURWoaiybpX5iBUbnyWczxcz8AG BV8cR/3ziHrYiVToyxvFVqCutQEbMbf+63ziRkIMfu+6NfQTjQ7mcqSh7mA7QgUXz3 s1O46c9i7K6IRJsB/Ek6InYvKYuqb/yr3Jv/26ZbBeTanIcXfebPV3tgBNoWeW6z9y u4BFrbmL3nPeZn5W2dTWBguBH0eCmF9aqlUHhUROFAQE/k8WwhJQlkidvE/If0Zvg0 saQVRcI+iq/pYiwxSSDaNYbqAUIE/3FLksgL5ADw0o9qWZQT5LLYIM0l3Tvx1mIhS2 hS6Xjm3t1gN+g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , syzbot+937b5bbb6a815b3e5d0b@syzkaller.appspotmail.com, Kuniyuki Iwashima , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 452/844] tcp: fix potential race in tcp_v6_syn_recv_sock() Date: Sat, 28 Feb 2026 12:26:05 -0500 Message-ID: <20260228173244.1509663-453-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit 858d2a4f67ff69e645a43487ef7ea7f28f06deae ] Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+937b5bbb6a815b3e5d0b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69949275.050a0220.2eeac1.0145.GAE@go= ogle.com/ Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260217161205.2079883-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/net/inet_connection_sock.h | 4 +- include/net/tcp.h | 4 +- net/ipv4/syncookies.c | 2 +- net/ipv4/tcp_fastopen.c | 2 +- net/ipv4/tcp_ipv4.c | 8 ++- net/ipv4/tcp_minisocks.c | 2 +- net/ipv6/tcp_ipv6.c | 98 +++++++++++++----------------- net/mptcp/subflow.c | 6 +- net/smc/af_smc.c | 6 +- 9 files changed, 66 insertions(+), 66 deletions(-) diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connecti= on_sock.h index ecb362025c4e5..5cb3056d6ddc7 100644 --- a/include/net/inet_connection_sock.h +++ b/include/net/inet_connection_sock.h @@ -42,7 +42,9 @@ struct inet_connection_sock_af_ops { struct request_sock *req, struct dst_entry *dst, struct request_sock *req_unhash, - bool *own_req); + bool *own_req, + void (*opt_child_init)(struct sock *newsk, + const struct sock *sk)); u16 net_header_len; int (*setsockopt)(struct sock *sk, int level, int optname, sockptr_t optval, unsigned int optlen); diff --git a/include/net/tcp.h b/include/net/tcp.h index e0a5cf2f78181..279ddb923e656 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -533,7 +533,9 @@ struct sock *tcp_v4_syn_recv_sock(const struct sock *sk= , struct sk_buff *skb, struct request_sock *req, struct dst_entry *dst, struct request_sock *req_unhash, - bool *own_req); + bool *own_req, + void (*opt_child_init)(struct sock *newsk, + const struct sock *sk)); int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb); int tcp_v4_connect(struct sock *sk, struct sockaddr_unsized *uaddr, int ad= dr_len); int tcp_connect(struct sock *sk); diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c index 569befcf021ba..061751aabc8e1 100644 --- a/net/ipv4/syncookies.c +++ b/net/ipv4/syncookies.c @@ -203,7 +203,7 @@ struct sock *tcp_get_cookie_sock(struct sock *sk, struc= t sk_buff *skb, bool own_req; =20 child =3D icsk->icsk_af_ops->syn_recv_sock(sk, skb, req, dst, - NULL, &own_req); + NULL, &own_req, NULL); if (child) { refcount_set(&req->rsk_refcnt, 1); sock_rps_save_rxhash(child, skb); diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c index 7d945a527daf0..444306af444ae 100644 --- a/net/ipv4/tcp_fastopen.c +++ b/net/ipv4/tcp_fastopen.c @@ -247,7 +247,7 @@ static struct sock *tcp_fastopen_create_child(struct so= ck *sk, bool own_req; =20 child =3D inet_csk(sk)->icsk_af_ops->syn_recv_sock(sk, skb, req, NULL, - NULL, &own_req); + NULL, &own_req, NULL); if (!child) return NULL; =20 diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c index f8a9596e8f4d4..e4e7bc8782ab6 100644 --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -1706,7 +1706,9 @@ struct sock *tcp_v4_syn_recv_sock(const struct sock *= sk, struct sk_buff *skb, struct request_sock *req, struct dst_entry *dst, struct request_sock *req_unhash, - bool *own_req) + bool *own_req, + void (*opt_child_init)(struct sock *newsk, + const struct sock *sk)) { struct inet_request_sock *ireq; bool found_dup_sk =3D false; @@ -1758,6 +1760,10 @@ struct sock *tcp_v4_syn_recv_sock(const struct sock = *sk, struct sk_buff *skb, } sk_setup_caps(newsk, dst); =20 +#if IS_ENABLED(CONFIG_IPV6) + if (opt_child_init) + opt_child_init(newsk, sk); +#endif tcp_ca_openreq_child(newsk, dst); =20 tcp_sync_mss(newsk, dst_mtu(dst)); diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c index 9776c921d1bb4..0742a41687ffc 100644 --- a/net/ipv4/tcp_minisocks.c +++ b/net/ipv4/tcp_minisocks.c @@ -909,7 +909,7 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_b= uff *skb, * socket is created, wait for troubles. */ child =3D inet_csk(sk)->icsk_af_ops->syn_recv_sock(sk, skb, req, NULL, - req, &own_req); + req, &own_req, NULL); if (!child) goto listen_overflow; =20 diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c index 4ae664b05fa91..9df81f85ec982 100644 --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -1310,11 +1310,48 @@ static void tcp_v6_restore_cb(struct sk_buff *skb) sizeof(struct inet6_skb_parm)); } =20 +/* Called from tcp_v4_syn_recv_sock() for v6_mapped children. */ +static void tcp_v6_mapped_child_init(struct sock *newsk, const struct sock= *sk) +{ + struct inet_sock *newinet =3D inet_sk(newsk); + struct ipv6_pinfo *newnp; + + newinet->pinet6 =3D newnp =3D tcp_inet6_sk(newsk); + newinet->ipv6_fl_list =3D NULL; + + memcpy(newnp, tcp_inet6_sk(sk), sizeof(struct ipv6_pinfo)); + + newnp->saddr =3D newsk->sk_v6_rcv_saddr; + + inet_csk(newsk)->icsk_af_ops =3D &ipv6_mapped; + if (sk_is_mptcp(newsk)) + mptcpv6_handle_mapped(newsk, true); + newsk->sk_backlog_rcv =3D tcp_v4_do_rcv; +#if defined(CONFIG_TCP_MD5SIG) || defined(CONFIG_TCP_AO) + tcp_sk(newsk)->af_specific =3D &tcp_sock_ipv6_mapped_specific; +#endif + + newnp->ipv6_mc_list =3D NULL; + newnp->ipv6_ac_list =3D NULL; + newnp->pktoptions =3D NULL; + newnp->opt =3D NULL; + + /* tcp_v4_syn_recv_sock() has initialized newinet->mc_{index,ttl} */ + newnp->mcast_oif =3D newinet->mc_index; + newnp->mcast_hops =3D newinet->mc_ttl; + + newnp->rcv_flowinfo =3D 0; + if (inet6_test_bit(REPFLOW, sk)) + newnp->flow_label =3D 0; +} + static struct sock *tcp_v6_syn_recv_sock(const struct sock *sk, struct sk_= buff *skb, struct request_sock *req, struct dst_entry *dst, struct request_sock *req_unhash, - bool *own_req) + bool *own_req, + void (*opt_child_init)(struct sock *newsk, + const struct sock *sk)) { struct inet_request_sock *ireq; struct ipv6_pinfo *newnp; @@ -1330,61 +1367,10 @@ static struct sock *tcp_v6_syn_recv_sock(const stru= ct sock *sk, struct sk_buff * #endif struct flowi6 fl6; =20 - if (skb->protocol =3D=3D htons(ETH_P_IP)) { - /* - * v6 mapped - */ - - newsk =3D tcp_v4_syn_recv_sock(sk, skb, req, dst, - req_unhash, own_req); - - if (!newsk) - return NULL; - - newinet =3D inet_sk(newsk); - newinet->pinet6 =3D tcp_inet6_sk(newsk); - newinet->ipv6_fl_list =3D NULL; - - newnp =3D tcp_inet6_sk(newsk); - newtp =3D tcp_sk(newsk); - - memcpy(newnp, np, sizeof(struct ipv6_pinfo)); - - newnp->saddr =3D newsk->sk_v6_rcv_saddr; - - inet_csk(newsk)->icsk_af_ops =3D &ipv6_mapped; - if (sk_is_mptcp(newsk)) - mptcpv6_handle_mapped(newsk, true); - newsk->sk_backlog_rcv =3D tcp_v4_do_rcv; -#if defined(CONFIG_TCP_MD5SIG) || defined(CONFIG_TCP_AO) - newtp->af_specific =3D &tcp_sock_ipv6_mapped_specific; -#endif - - newnp->ipv6_mc_list =3D NULL; - newnp->ipv6_ac_list =3D NULL; - newnp->pktoptions =3D NULL; - newnp->opt =3D NULL; - newnp->mcast_oif =3D inet_iif(skb); - newnp->mcast_hops =3D ip_hdr(skb)->ttl; - newnp->rcv_flowinfo =3D 0; - if (inet6_test_bit(REPFLOW, sk)) - newnp->flow_label =3D 0; - - /* - * No need to charge this sock to the relevant IPv6 refcnt debug socks c= ount - * here, tcp_create_openreq_child now does this for us, see the comment = in - * that function for the gory details. -acme - */ - - /* It is tricky place. Until this moment IPv4 tcp - worked with IPv6 icsk.icsk_af_ops. - Sync it now. - */ - tcp_sync_mss(newsk, inet_csk(newsk)->icsk_pmtu_cookie); - - return newsk; - } - + if (skb->protocol =3D=3D htons(ETH_P_IP)) + return tcp_v4_syn_recv_sock(sk, skb, req, dst, + req_unhash, own_req, + tcp_v6_mapped_child_init); ireq =3D inet_rsk(req); =20 if (sk_acceptq_is_full(sk)) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 96d54cb2cd93f..b11d0bf006c19 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -810,7 +810,9 @@ static struct sock *subflow_syn_recv_sock(const struct = sock *sk, struct request_sock *req, struct dst_entry *dst, struct request_sock *req_unhash, - bool *own_req) + bool *own_req, + void (*opt_child_init)(struct sock *newsk, + const struct sock *sk)) { struct mptcp_subflow_context *listener =3D mptcp_subflow_ctx(sk); struct mptcp_subflow_request_sock *subflow_req; @@ -857,7 +859,7 @@ static struct sock *subflow_syn_recv_sock(const struct = sock *sk, =20 create_child: child =3D listener->icsk_af_ops->syn_recv_sock(sk, skb, req, dst, - req_unhash, own_req); + req_unhash, own_req, opt_child_init); =20 if (child && *own_req) { struct mptcp_subflow_context *ctx =3D mptcp_subflow_ctx(child); diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c index d8201eb3ac5f3..18c56b0d7ad53 100644 --- a/net/smc/af_smc.c +++ b/net/smc/af_smc.c @@ -124,7 +124,9 @@ static struct sock *smc_tcp_syn_recv_sock(const struct = sock *sk, struct request_sock *req, struct dst_entry *dst, struct request_sock *req_unhash, - bool *own_req) + bool *own_req, + void (*opt_child_init)(struct sock *newsk, + const struct sock *sk)) { struct smc_sock *smc; struct sock *child; @@ -142,7 +144,7 @@ static struct sock *smc_tcp_syn_recv_sock(const struct = sock *sk, =20 /* passthrough to original syn recv sock fct */ child =3D smc->ori_af_ops->syn_recv_sock(sk, skb, req, dst, req_unhash, - own_req); + own_req, opt_child_init); /* child must not inherit smc or its ops */ if (child) { rcu_assign_sk_user_data(child, NULL); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC2C23CF399; Sat, 28 Feb 2026 17:40:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300415; cv=none; b=CddZrBmK6tXiTihe5vAtrjmqthMLf9q1IHvbjiDoOfHk+9G/hd1UWiL+Wor8VzYZ72ID83CEHEPJ+0ijN7lZqlVHCjXceb1INUUaTVDRz+B3YqJdcQQdshxNC//DTu42BPTkeG54wi++tEgdONHVY0T0unVajNGHpWCjHufbSMQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300415; c=relaxed/simple; bh=eS5QHnOZ1NOzGEt+7Pljd+wWiRN60mY52EW9hpayvyk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=C5nGw3AqkKvHgW8qHECJJa+RwgBi2/8Fel5JclugdGdzC0B17tbXsl97gTAATvBmjZl4Ya1y3/0eq3NOsGuXvv0RiXtRJy+55v6D3zMnQK4lV915hAU92gC/Mbc/iq2QUvvflYjuSzYIzeNnWQ5bp7ava5TP2t10HuhznikgFn0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NIW0VMyI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NIW0VMyI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0348C116D0; Sat, 28 Feb 2026 17:40:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300415; bh=eS5QHnOZ1NOzGEt+7Pljd+wWiRN60mY52EW9hpayvyk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NIW0VMyIi84A4w6/tQ6U41EvhBvrxT4uo824jhPxoFkDqUrKvto3pWm/5bdBBWVI3 aRy3IpKARE/vUuyDE585Ys7CmelAqAt+WbCyrDtKqtJOoUx08dKnntuJ+aX6vwRd38 InN7Y/w0nV3KxjPgg1iX+lE9Sf/9CiBWWJ6FNMYUpJ0C0zjy+bVpc5z402H+CJgwe8 R+d5JM4iupOePGqO/MCUNSBh/LVGuD8LTNNDukNgvxpc6p9UHQ9/wD76swbWo+QpLe eCZcvHztAuT1t8Vjnuau+SYtnhcGh1KYjgVWQbKsRpbCxNniiZC+/q6l7Tqe4GlXYu Pv/fO87fiFqPg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Daniel Zahka , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 453/844] psp: use sk->sk_hash in psp_write_headers() Date: Sat, 28 Feb 2026 12:26:06 -0500 Message-ID: <20260228173244.1509663-454-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit f891007ab1c77436950d10e09eae54507f1865ff ] udp_flow_src_port() is indirectly using sk->sk_txhash as a base, because __tcp_transmit_skb() uses skb_set_hash_from_sk(). This is problematic because this field can change over the lifetime of a TCP flow, thanks to calls to sk_rethink_txhash(). Problem is that some NIC might (ab)use the PSP UDP source port in their RSS computation, and PSP packets for a given flow could jump from one queue to another. In order to avoid surprises, it is safer to let Protective Load Balancing (PLB) get its entropy from the IPv6 flowlabel, and change psp_write_headers() to use sk->sk_hash which does not change for the duration of the flow. We might add a sysctl to select the behavior, if there is a need for it. Fixes: fc724515741a ("psp: provide encapsulation helper for drivers") Signed-off-by: Eric Dumazet Reviewed-By: Daniel Zahka Link: https://patch.msgid.link/20260218141337.999945-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/psp/psp_main.c | 39 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/net/psp/psp_main.c b/net/psp/psp_main.c index a8534124f6266..066222eb56c4a 100644 --- a/net/psp/psp_main.c +++ b/net/psp/psp_main.c @@ -166,9 +166,46 @@ static void psp_write_headers(struct net *net, struct = sk_buff *skb, __be32 spi, { struct udphdr *uh =3D udp_hdr(skb); struct psphdr *psph =3D (struct psphdr *)(uh + 1); + const struct sock *sk =3D skb->sk; =20 uh->dest =3D htons(PSP_DEFAULT_UDP_PORT); - uh->source =3D udp_flow_src_port(net, skb, 0, 0, false); + + /* A bit of theory: Selection of the source port. + * + * We need some entropy, so that multiple flows use different + * source ports for better RSS spreading at the receiver. + * + * We also need that all packets belonging to one TCP flow + * use the same source port through their duration, + * so that all these packets land in the same receive queue. + * + * udp_flow_src_port() is using sk_txhash, inherited from + * skb_set_hash_from_sk() call in __tcp_transmit_skb(). + * This field is subject to reshuffling, thanks to + * sk_rethink_txhash() calls in various TCP functions. + * + * Instead, use sk->sk_hash which is constant through + * the whole flow duration. + */ + if (likely(sk)) { + u32 hash =3D sk->sk_hash; + int min, max; + + /* These operations are cheap, no need to cache the result + * in another socket field. + */ + inet_get_local_port_range(net, &min, &max); + /* Since this is being sent on the wire obfuscate hash a bit + * to minimize possibility that any useful information to an + * attacker is leaked. Only upper 16 bits are relevant in the + * computation for 16 bit port value because we use a + * reciprocal divide. + */ + hash ^=3D hash << 16; + uh->source =3D htons((((u64)hash * (max - min)) >> 32) + min); + } else { + uh->source =3D udp_flow_src_port(net, skb, 0, 0, false); + } uh->check =3D 0; uh->len =3D htons(udp_len); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F0153CFCEB; Sat, 28 Feb 2026 17:40:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300416; cv=none; b=YdDU/E3CNi/qp5tB7Q12c28JmD4E7fS0z9V6GeleBrnFeeWNi+6YN6L1E7ImFFeH/Y5XTQ6coZlHAc3FnEmKar7fkYRI0FWGuMQgJVBkwJ2OAjurvUU2+gtDk5O5yrfK/+GcUafz6Q8l21r4mDBvsYcCrE29Q0sZclitNeXkdxU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300416; c=relaxed/simple; bh=dH/i1FBsguOEmUILzyVjTdcuHv2E7eXf4aeX/spdWmg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=m57M92kHJPWk5H0GeafvyIr8Lojr0kz+gwOGRkWB9subFx+BtHSL2B3TpNqntLDXs9mqb3No6zYyGpGKqk8kOcj3gB/XTUB6pztbYvjbMepS7PPcwil6gX+6Ypp6Popkf3QQ4XzS6M27BZS5CHEmAp0CMPz+L9tGXkL5IkZfQNQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T6j1we1l; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T6j1we1l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D45DDC116D0; Sat, 28 Feb 2026 17:40:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300416; bh=dH/i1FBsguOEmUILzyVjTdcuHv2E7eXf4aeX/spdWmg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T6j1we1l3Yhp/wKBsoYQjfTTHs06Q+FILcL0Tb/X2nsAs9iWFZ7WAvDUaMJ3Pso5j PWibYPGCCKZ9FiHqq8kbDSFliLK1rXnCxzsZFY5b2Q+ko3YgEUE89gN2xs0mcbWsjT U7Q09Ugf3GqmRgQk56+eBekvMdPTkgMvmtdSSTUKgPqP/Q8HKhflVUgxMGGv63FCx6 glEFMtutZMAd9jkfdYJkGKlwv7SVer/vKrQecDwKrgbZFOUhtsdrtG1c4QYGmQ4Elm uCzuRvJVQfpsFIxclP/jUGEL4WABvId4wu1vYRQjHKJGE0Sx3FgYwqSvc+BuK5OQ4k pdjFfBk9XhgPg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hyunwoo Kim , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 454/844] espintcp: Fix race condition in espintcp_close() Date: Sat, 28 Feb 2026 12:26:07 -0500 Message-ID: <20260228173244.1509663-455-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hyunwoo Kim [ Upstream commit e1512c1db9e8794d8d130addd2615ec27231d994 ] This issue was discovered during a code audit. After cancel_work_sync() is called from espintcp_close(), espintcp_tx_work() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the espintcp_tx_work() worker may dereference a freed espintcp ctx or sk. The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work); To prevent this race condition, cancel_work_sync() is replaced with disable_work_sync(). Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Hyunwoo Kim Reviewed-by: Simon Horman Link: https://patch.msgid.link/aZSie7rEdh9Nu0eM@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/xfrm/espintcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/xfrm/espintcp.c b/net/xfrm/espintcp.c index bf744ac9d5a73..8709df716e98e 100644 --- a/net/xfrm/espintcp.c +++ b/net/xfrm/espintcp.c @@ -536,7 +536,7 @@ static void espintcp_close(struct sock *sk, long timeou= t) sk->sk_prot =3D &tcp_prot; barrier(); =20 - cancel_work_sync(&ctx->work); + disable_work_sync(&ctx->work); strp_done(&ctx->strp); =20 skb_queue_purge(&ctx->out_queue); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92A703CFD07; Sat, 28 Feb 2026 17:40:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300417; cv=none; b=CewGd7jJL6z3w0bQHpT0gxT3/EMj7lRw+lFZo6WnSa6iVJ4K+6vQTMwIe4cCZND+Wi7ZhMece9fOjEM5FsxgO4kBtic2ekPa56McWZocx9M4IhReKDXNRENI25mdupolVAGdz4vdgTrkiyqYg4GHDfDsCwuiLXHt9gaTq4uTF5s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300417; c=relaxed/simple; bh=sUGRmpIzP6VTIdZXiy1GrpAXt4jwWFVe8WWblpyBuAs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uzAr4hbipXglxQX8QJBoPHS+rButy6BWIBbhv3UaijcUMmBdmdkEu3YNdaAd2jh2UD62mbuAH5n7fDsGQmZm6zVIa2UQdU6WMn65H+aXtwZTTXN0EyntzG/ivAu2JRGTsDQqdR/J/p1TchYWX/pr3yHzHAYZdQzFwgak5aDNvEA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SPN6Yw8V; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SPN6Yw8V" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C639AC116D0; Sat, 28 Feb 2026 17:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300417; bh=sUGRmpIzP6VTIdZXiy1GrpAXt4jwWFVe8WWblpyBuAs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SPN6Yw8V5dYYUaFu0/6CTcjIA737CjFIpkaApwqe6dS0HvSblX0tCMGoun+Py6uYg 56lFEhx6puRGrdNhTfjA9u4c+3sgPTeWRTjZ+lvV1rhV3ovxCVB4mSlNuBWmAnYh/z dmF9BzvSdvTczJMsHP99HxeT2SpJwAY/ndC9nS0zyMwpffIfglUoYGYGR37lgf7rl/ PEXduxZNo0PL0TGZ220txWhYe3VmDKS+jluxpHxtuMFAnRRFvnhrYKr952mBwQr6v9 3gx3ETLfnivUW9j0qz8/PyfaTRJlbnDphgksf/kvPA6btZEvgcYBDQ5NsINnmMSAvV PGqs83s9n+50w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ziyi Guo , Paolo Abeni , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 455/844] net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode Date: Sat, 28 Feb 2026 12:26:08 -0500 Message-ID: <20260228173244.1509663-456-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ziyi Guo [ Upstream commit 64868f5ecadeb359a49bc4485bfa7c497047f13a ] kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): "URB submitted while active" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl= 8150_set_multicast"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time. Suggested-by: Paolo Abeni Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260217175012.1234494-1-n7l8m4@u.northweste= rn.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/usb/kaweth.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c index c9efb7df892ec..e01d14f6c3667 100644 --- a/drivers/net/usb/kaweth.c +++ b/drivers/net/usb/kaweth.c @@ -765,7 +765,6 @@ static void kaweth_set_rx_mode(struct net_device *net) =20 netdev_dbg(net, "Setting Rx mode to %d\n", packet_filter_bitmap); =20 - netif_stop_queue(net); =20 if (net->flags & IFF_PROMISC) { packet_filter_bitmap |=3D KAWETH_PACKET_FILTER_PROMISCUOUS; @@ -775,7 +774,6 @@ static void kaweth_set_rx_mode(struct net_device *net) } =20 kaweth->packet_filter_bitmap =3D packet_filter_bitmap; - netif_wake_queue(net); } =20 /**************************************************************** --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FEA83CF365; Sat, 28 Feb 2026 17:40:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300418; cv=none; b=Ez0blI+IIMAX2FalRQgbVMNHAH4RUx8vSZCzXbKlj8z7wvaypFq8q8J6VJT4CPJVJaINOsMLDTUxCFo006Y+AtgV4XTyQCtw+jzg4OpvwjL8j4oL4eRmo7vOtx3BEYeC2ri2lnkpHaJEU7DLLMX2rPFVqw+wjTf48EkXeR8K1aY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300418; c=relaxed/simple; bh=zaLi0pMp0bWbvEXHJsbhu3SFVHOuKzj/+3rDcft9+5I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uYgK3hfX+bSg52KBxmaO2uAm793xLd3RPFXs2rBdNJS7ZYSlF7RNdefeusl/I76VOdef32C7gbNdSgR/NsSZq6vmje0ZSNn2qogbMpK16fA6qYpqylFk/oRuxx9Dh68IZsI/pb0ipgHUL4bamuVwk26ZTn3KHjmyUhHkdfRzYsU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mfxjbzNQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mfxjbzNQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B779CC116D0; Sat, 28 Feb 2026 17:40:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300418; bh=zaLi0pMp0bWbvEXHJsbhu3SFVHOuKzj/+3rDcft9+5I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mfxjbzNQsMErFZ4wFVW7OAwGjjqa6gx0Yhw+rU6VHZ3OwsiR4aGSDQtOkn9aoS8HE 8ttYIaxDCSP4IUBJfiY+PuiDxY1Wjm3oO9PdSj5hhWVNu/kfZUCP8jrBffZB1kj/e1 uE2N1Zg2waeBsLM/eVd3cBiEpnHm1WyaORR2Mfpo7YkBwxgYxizLq9VVgFQ6dSOO8F d4SE+Tj73y9QG9i43qAuJqEh4WzVfvTlpyJigj3naDyvVzXqUfKFbnoxhMOoG/KH/L wT4c+aTBhd7jp6a5LGo+QoKXhdXPR/2L4Sb8uktuE3IcAdBctEvfjrB+0CLBvtutJ0 +Dwdd1igYg1Ew== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Martin=20P=C3=A5lsson?= , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 456/844] net: usb: lan78xx: scan all MDIO addresses on LAN7801 Date: Sat, 28 Feb 2026 12:26:09 -0500 Message-ID: <20260228173244.1509663-457-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Martin P=C3=A5lsson [ Upstream commit f1e2f0ce704e4a14e3f367d3b97d3dd2d8e183b7 ] The LAN7801 is designed exclusively for external PHYs (unlike the LAN7800/LAN7850 which have internal PHYs), but lan78xx_mdio_init() restricts PHY scanning to MDIO addresses 0-7 by setting phy_mask to ~(0xFF). This prevents discovery of external PHYs wired to addresses outside that range. One such case is the DP83TC814 100BASE-T1 PHY, which is typically configured at MDIO address 10 via PHYAD bootstrap pins and goes undetected with the current mask. Remove the restrictive phy_mask assignment for the LAN7801 so that the default mask of 0 applies, allowing all 32 MDIO addresses to be scanned during bus registration. Fixes: 02dc1f3d613d ("lan78xx: add LAN7801 MAC only support") Signed-off-by: Martin P=C3=A5lsson Link: https://patch.msgid.link/0110019c6f388aff-98d99cf0-4425-4fff-b16b-dea= 5ad8fafe0-000000@eu-north-1.amazonses.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/usb/lan78xx.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c index 00397a8073934..065588c9cfa65 100644 --- a/drivers/net/usb/lan78xx.c +++ b/drivers/net/usb/lan78xx.c @@ -2094,8 +2094,6 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev) dev->mdiobus->phy_mask =3D ~(1 << 1); break; case ID_REV_CHIP_ID_7801_: - /* scan thru PHYAD[2..0] */ - dev->mdiobus->phy_mask =3D ~(0xFF); break; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 47CDA3D05F5; Sat, 28 Feb 2026 17:40:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300419; cv=none; b=H4p8ZtJX9YrpOri6wPycxiXa00EOSASU2HdDtbaz1yuee5MYnPy8P10BmvB56QXWcDy9ES2QwccBQkVtJxnpANX663fk/UsstIGO3btFOiLEIpfl+VnABtVsovBtQR7I9qbAvbTaqjJklGr6flaoP5+YyBRsRM/YynVG5VvOkh8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300419; c=relaxed/simple; bh=Q8SaXWL93odJG0thtYeuDo3S//j8M8ja3rclt+aW2gE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Swu1DiLp+TPeV3pEhHZ/PF7LV/1r6oi9XkYrWRWn4jQMTjugzYQ6TAXWVIvfoaVnkyD1HrU2XbBI088hvpkPK2nPDyXsLsRkM+cOhylY6grEJNNSfXbSOztaETjJNxZWqv/4Ht7NfO+3pu75/TR88ZY6gF6brGEDX80DJJUXt8c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KgILu77i; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KgILu77i" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 941FCC19425; Sat, 28 Feb 2026 17:40:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300419; bh=Q8SaXWL93odJG0thtYeuDo3S//j8M8ja3rclt+aW2gE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KgILu77iEPCruMcv2g/txsGihyz6qbXM2c/VCLLgFYJGacq8V3tT3VSI1YGNdCaHy 9yV7fBROcadhkC5mMzJgYd6fMq8wMbookQVhDY4Iu9b5bz5ens3x/AIZVRH39ylVDv 8m1jHzixt3x8iq7YdRBpKg55SS2HF70w/cBdOqwjVeLXsy85Jyye9cqYi9IyysvwS5 fJbarVLKiRXo+rxjYt1ks//Te3SbQRnq0J0h4BUuFKqM24zd2Ln1BoNzMfY85CuVEk doKhn1EqxXUQfD2wuyKiPU+2IqiIiabiKUQRmsJA3OhfPnIwWWCg4vzwraGZv2qzNI dXce6AL3nJM7A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Tidmore , Christian Brauner , Sasha Levin Subject: [PATCH 6.19 457/844] proc: Fix pointer error dereference Date: Sat, 28 Feb 2026 12:26:10 -0500 Message-ID: <20260228173244.1509663-458-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Tidmore [ Upstream commit f6a495484a27150fb85f943e1a7464da88c2a797 ] The function try_lookup_noperm() can return an error pointer. Add check for error pointer. Detected by Smatch: fs/proc/base.c:2148 proc_fill_cache() error: 'child' dereferencing possible ERR_PTR() Fixes: 1df98b8bbcca ("proc_fill_cache(): clean up, get rid of pointless fin= d_inode_number() use") Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260219221001.1117135-1-ethantidmore06@gmai= l.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/proc/base.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/proc/base.c b/fs/proc/base.c index 4eec684baca9f..4c863d17dfb4c 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -2128,6 +2128,9 @@ bool proc_fill_cache(struct file *file, struct dir_co= ntext *ctx, ino_t ino =3D 1; =20 child =3D try_lookup_noperm(&qname, dir); + if (IS_ERR(child)) + goto end_instantiate; + if (!child) { DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); child =3D d_alloc_parallel(dir, &qname, &wq); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9112E3D061B; Sat, 28 Feb 2026 17:40:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300420; cv=none; b=PRaNvJKq6usEyxxR4k6E+G3oi3H+0oD4+c3c8oycWSpfQ1yhDA5bOG8zKGXfNoZmdDIj3Z5ZhvfUUkEL/UOGYqCCWF9VNIMcObbZcNf9hUnW+UJxIJB+CzEx+3KMV3SunTG6+8Z2cviRXa7A+aBY705yDrUBSP5nXSvLachoCTg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300420; c=relaxed/simple; bh=weKkzB8KZ5DLReewVFSur3h8mJwcAvL7MIgP5XVfu5k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aQhi7LUrig3ZvHaLu1hHZK7R17JOgYeCW33OntBEaUhJ97CPGCMwmpSXS5tiwOAULAIT2unEH69JuCm/i9RObw7MNcqysoQEEg2xyumHg0PMOE2LDCicXtQo0W2PjcRUdWAFGjbagb+1Fmykm63hqprZBsIeofxhhkZ3BaxtYBk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T34sPbUb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T34sPbUb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E90CC19425; Sat, 28 Feb 2026 17:40:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300420; bh=weKkzB8KZ5DLReewVFSur3h8mJwcAvL7MIgP5XVfu5k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T34sPbUbuCvjhVa/1boB4tQMx1D0WIoXAsRglkyXfMv4iy9r9zJAkLZlE5eK+pKu2 qs6KAhkUemumL8ipCpAQewhnkppse1akfdg7FgO7gfpV0cPhxkzhpYTv9Z+kU8c6sI PM548MIat9/Erm17cRF2SugbkUjBMCOgHpXoA6R4E3K4zrHeubt5rFzu3FIl7yqqNU NWDxNb2oSO+hfiYgqFWBjlj11HBHHSOtE8SC/bKL6moxe1qIT9XX1xa1OynN9jPH2n lkzOULBqZoI+hGG+8wWz4xrHXKCsDYaZCcjbrRvHjGZlD2Ja/I4VaWSzhTe0N3LwWa 1LJy3J1WeZm/A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dmitry Torokhov , Bartosz Golaszewski , Linus Walleij , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 458/844] net: phy: qcom: qca807x: normalize return value of gpio_get Date: Sat, 28 Feb 2026 12:26:11 -0500 Message-ID: <20260228173244.1509663-459-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dmitry Torokhov [ Upstream commit 2bb995e6155cb4f254574598cbd6fe1dcc99766a ] The GPIO get callback is expected to return 0 or 1 (or a negative error code). Ensure that the value returned by qca807x_gpio_get() is normalized to the [0, 1] range. Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get(= )") Signed-off-by: Dmitry Torokhov Reviewed-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Link: https://patch.msgid.link/aZZeyr2ysqqk2GqA@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/phy/qcom/qca807x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/qcom/qca807x.c b/drivers/net/phy/qcom/qca807x.c index 1be8295a95cb5..511cde345e089 100644 --- a/drivers/net/phy/qcom/qca807x.c +++ b/drivers/net/phy/qcom/qca807x.c @@ -375,7 +375,7 @@ static int qca807x_gpio_get(struct gpio_chip *gc, unsig= ned int offset) reg =3D QCA807X_MMD7_LED_FORCE_CTRL(offset); val =3D phy_read_mmd(priv->phy, MDIO_MMD_AN, reg); =20 - return FIELD_GET(QCA807X_GPIO_FORCE_MODE_MASK, val); + return !!FIELD_GET(QCA807X_GPIO_FORCE_MODE_MASK, val); } =20 static int qca807x_gpio_set(struct gpio_chip *gc, unsigned int offset, int= value) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B2603D0E62; Sat, 28 Feb 2026 17:40:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300421; cv=none; b=TBEMBvnlkXk+BJ3DVChziTraPjXk2/qTKnfYuub6r1zfQOtgSciimQoaGMFXMAAacUOai4Px2MvczQ8K40OL22awRi1izG7c/Z3hhM1JnZvRy3PX59gyiasBpW75ottSN34VPCills6ADkTxEANuBieSvrAD64KpkslbX7La+WQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300421; c=relaxed/simple; bh=pUCiQnWyxC0p8wloLakDOX3hNyutKCYZb/R46N5Q2zc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ok08tJhVFqV3T/kl/1we5NJOBnEbGVNuvRDvjZBc00VRq9zjfIETpW2ZqkqUedgNdlm2JoNyNngDoOQT30ok8lbQYB00ZWZNrRObizIbT7l1dak2hhfdIJu6yPrGKjnXprXynRFXYdy5ObdXCR++P5BU4sLiwZ4kjDcUX9jgKG8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SkbZadYo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SkbZadYo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74DB2C19424; Sat, 28 Feb 2026 17:40:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300421; bh=pUCiQnWyxC0p8wloLakDOX3hNyutKCYZb/R46N5Q2zc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SkbZadYoLx8GqFKaVmefhtgXeb1NP4roJw0WF1kz92XCm5b5Go3WblALsXkqTtqyg 3rxJduYmy6OvoNWwIl/EVqM6Ybp9ONglspr6ja01xhwBDcPsYPhpF3pNzp8EdIw9vO fitUS+HY2kXjsP6EHXSFCYJiwTzQkJr5lbADattVIRDmMWU8oqMTt1f8gMclXneLQd bFBzqey1GuAm9f2fz7r+nqBp/zRezOTfTK8mboL2jKbuUe8MabWzLqiIvCw4d01F7B mbIVwe+hkMjsePNWhP8FuO/nXRD95m0MCyXHgxp1K4LX3VTtfLeGJPlUHqhx86DQjS wrHD3bKqZgb9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Linus Walleij , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 459/844] net: ethernet: xscale: Check for PTP support properly Date: Sat, 28 Feb 2026 12:26:12 -0500 Message-ID: <20260228173244.1509663-460-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Linus Walleij [ Upstream commit 594163ea88a03bdb412063af50fc7177ef3cbeae ] In ixp4xx_get_ts_info() ixp46x_ptp_find() is called unconditionally despite this feature only existing on ixp46x, leading to the following splat from tcpdump: root@OpenWrt:~# tcpdump -vv -X -i eth0 (...) Unable to handle kernel NULL pointer dereference at virtual address 00000238 when read (...) Call trace: ptp_clock_index from ixp46x_ptp_find+0x1c/0x38 ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64 ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108 __ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648 __dev_ethtool from dev_ethtool+0x160/0x234 dev_ethtool from dev_ioctl+0x2cc/0x460 dev_ioctl from sock_ioctl+0x1ec/0x524 sock_ioctl from sys_ioctl+0x51c/0xa94 sys_ioctl from ret_fast_syscall+0x0/0x44 (...) Segmentation fault Check for ixp46x in ixp46x_ptp_find() before trying to set up PTP to avoid this. To avoid altering the returned error code from ixp4xx_hwtstamp_set() which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP from ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matter the error code. The helper function ixp46x_ptp_find() helper returns -ENODEV. Fixes: 9055a2f59162 ("ixp4xx_eth: make ptp support a platform driver") Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260219-ixp4xx-fix-ethernet-v3-1-f235ccc3cd= 46@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/xscale/ixp4xx_eth.c | 5 +---- drivers/net/ethernet/xscale/ptp_ixp46x.c | 3 +++ 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c b/drivers/net/etherne= t/xscale/ixp4xx_eth.c index e1e7f65553e76..b0faa0f1780d0 100644 --- a/drivers/net/ethernet/xscale/ixp4xx_eth.c +++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c @@ -403,15 +403,12 @@ static int ixp4xx_hwtstamp_set(struct net_device *net= dev, int ret; int ch; =20 - if (!cpu_is_ixp46x()) - return -EOPNOTSUPP; - if (!netif_running(netdev)) return -EINVAL; =20 ret =3D ixp46x_ptp_find(&port->timesync_regs, &port->phc_index); if (ret) - return ret; + return -EOPNOTSUPP; =20 ch =3D PORT2CHANNEL(port); regs =3D port->timesync_regs; diff --git a/drivers/net/ethernet/xscale/ptp_ixp46x.c b/drivers/net/etherne= t/xscale/ptp_ixp46x.c index 94203eb46e6b0..93c64db22a696 100644 --- a/drivers/net/ethernet/xscale/ptp_ixp46x.c +++ b/drivers/net/ethernet/xscale/ptp_ixp46x.c @@ -232,6 +232,9 @@ static struct ixp_clock ixp_clock; =20 int ixp46x_ptp_find(struct ixp46x_ts_regs *__iomem *regs, int *phc_index) { + if (!cpu_is_ixp46x()) + return -ENODEV; + *regs =3D ixp_clock.regs; *phc_index =3D ptp_clock_index(ixp_clock.ptp_clock); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 588053D0E84; Sat, 28 Feb 2026 17:40:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300422; cv=none; b=nfNpBPkdbAMIEoZrPGFaeYIPXSVq7d60y5IuOPGW7RRvogmY/Nnhnf8fqswv+WOcdhu/JiNvWYmPIn43mSqN1tF9FgYlvJ4s6R5FYHrVZOian7BiJmErkc2QyyIUfGqlpFllqEudZTxHOKhx4rwXn6vcRcJs8ewqDZHUD+zcrNA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300422; c=relaxed/simple; bh=K+vWixumeWL2fRMPBy/mNqW6qNoi92HvkM4bZ8OqI4w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LUST2S/cW9LnGayzWSoBWqyIHDoILZ+GRSXgTH7Kq42UnAYP+ZWWwg4NyBhionESeppW9iifhG4J8YBcuf8BP5CohlOZU/RSye2mimdQU7dZi9NIEPapcTENa/VargwjRR/d7JE/jfg2J6qVvdA0cOOtbVqbVMxo7kMPSZthcac= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Pla6L91G; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Pla6L91G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59D98C116D0; Sat, 28 Feb 2026 17:40:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300422; bh=K+vWixumeWL2fRMPBy/mNqW6qNoi92HvkM4bZ8OqI4w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Pla6L91GaFffA92lJd+HkREUrCuZV1FSsCSTR0NDuElr6Gbz4auodxcugLkuWvNyp EEqK9HFBBAJy8F5nc4glNtPHLFNZM08qQjqXpWEX8KjOU7hVN28mNaoSgb1ER0JvOw vbV8lSEj3E1fW1fxH9xZdJafbyyAHpGPIRTSh2X+5erEQiCfF7ep0tcq5+ZkYwUc8f Cagz9PujMzJ3AE0USqseyLn+znrXBBDo3Zk+Vo6vRtro5cO2qZzCGxbyMVgjR6ITjH 56sPN0aUIOcP6znlRJe0fAjbX+T9oZrsMLgyg28jtcnkqZmNaTS2BQjw2LLAUn7TPP 49QnfwB0IAQiw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kuniyuki Iwashima , syzbot , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 460/844] udplite: Fix null-ptr-deref in __udp_enqueue_schedule_skb(). Date: Sat, 28 Feb 2026 12:26:13 -0500 Message-ID: <20260228173244.1509663-461-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit 470c7ca2b4c3e3a51feeb952b7f97a775b5c49cd ] syzbot reported null-ptr-deref of udp_sk(sk)->udp_prod_queue. [0] Since the cited commit, udp_lib_init_sock() can fail, as can udp_init_sock() and udpv6_init_sock(). Let's handle the error in udplite_sk_init() and udplitev6_sk_init(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrume= nted.h:82 [inline] BUG: KASAN: null-ptr-deref in atomic_read include/linux/atomic/atomic-instr= umented.h:32 [inline] BUG: KASAN: null-ptr-deref in __udp_enqueue_schedule_skb+0x151/0x1480 net/i= pv4/udp.c:1719 Read of size 4 at addr 0000000000000008 by task syz.2.18/2944 CPU: 1 UID: 0 PID: 2944 Comm: syz.2.18 Not tainted syzkaller #0 PREEMPTLAZY Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 kasan_report+0xa2/0xe0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200 instrument_atomic_read include/linux/instrumented.h:82 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719 __udpv6_queue_rcv_skb net/ipv6/udp.c:795 [inline] udpv6_queue_rcv_one_skb+0xa2e/0x1ad0 net/ipv6/udp.c:906 udp6_unicast_rcv_skb+0x227/0x380 net/ipv6/udp.c:1064 ip6_protocol_deliver_rcu+0xe17/0x1540 net/ipv6/ip6_input.c:438 ip6_input_finish+0x191/0x350 net/ipv6/ip6_input.c:489 NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318 ip6_input+0x16c/0x2b0 net/ipv6/ip6_input.c:500 NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6149 [inline] __netif_receive_skb+0xd3/0x370 net/core/dev.c:6262 process_backlog+0x4d6/0x1160 net/core/dev.c:6614 __napi_poll+0xae/0x320 net/core/dev.c:7678 napi_poll net/core/dev.c:7741 [inline] net_rx_action+0x60d/0xdc0 net/core/dev.c:7893 handle_softirqs+0x209/0x8d0 kernel/softirq.c:622 do_softirq+0x52/0x90 kernel/softirq.c:523 __local_bh_enable_ip+0xe7/0x120 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x109c/0x2dc0 net/core/dev.c:4856 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x158/0x4e0 net/ipv6/ip6_output.c:219 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x342/0x580 net/ipv6/ip6_output.c:246 ip6_send_skb+0x1d7/0x3c0 net/ipv6/ip6_output.c:1984 udp_v6_send_skb+0x9a5/0x1770 net/ipv6/udp.c:1442 udp_v6_push_pending_frames+0xa2/0x140 net/ipv6/udp.c:1469 udpv6_sendmsg+0xfe0/0x2830 net/ipv6/udp.c:1759 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3eb/0x580 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd2/0xf20 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f67b4d9c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 = 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff f= f 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f67b5c98028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f67b5015fa0 RCX: 00007f67b4d9c629 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f67b4e32b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000040000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f67b5016038 R14: 00007f67b5015fa0 R15: 00007ffe3cb66dd8 Fixes: b650bf0977d3 ("udp: remove busylock and add per NUMA queues") Reported-by: syzbot Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260219173142.310741-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/ipv4/udplite.c | 3 +-- net/ipv6/udplite.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/net/ipv4/udplite.c b/net/ipv4/udplite.c index d3e621a11a1aa..826e9e79eb19c 100644 --- a/net/ipv4/udplite.c +++ b/net/ipv4/udplite.c @@ -20,10 +20,9 @@ EXPORT_SYMBOL(udplite_table); /* Designate sk as UDP-Lite socket */ static int udplite_sk_init(struct sock *sk) { - udp_init_sock(sk); pr_warn_once("UDP-Lite is deprecated and scheduled to be removed in 2025,= " "please contact the netdev mailing list\n"); - return 0; + return udp_init_sock(sk); } =20 static int udplite_rcv(struct sk_buff *skb) diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c index 2cec542437f74..e867721cda4d3 100644 --- a/net/ipv6/udplite.c +++ b/net/ipv6/udplite.c @@ -16,10 +16,9 @@ =20 static int udplitev6_sk_init(struct sock *sk) { - udpv6_init_sock(sk); pr_warn_once("UDP-Lite is deprecated and scheduled to be removed in 2025,= " "please contact the netdev mailing list\n"); - return 0; + return udpv6_init_sock(sk); } =20 static int udplitev6_rcv(struct sk_buff *skb) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C2773D0E9F; Sat, 28 Feb 2026 17:40:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300423; cv=none; b=HfhLFhhi6JL+vkwpuX4ZWTsNoGdwfahiq8DUXLWyva5hc14eU8Q6kymeLzK1T1yvNMuMWyRjjZf235BApxryxXYliLe3dsXXr2IMdaTcCsk5Zdw61gj4RMhDWb27GWnxEiGmBJ+Mr1R/GbPgCt04qn4lXhy4LVDstMcs2KIVv8A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300423; c=relaxed/simple; bh=GKG4WXJ0g5xS0f6lnaAyKIggdj/G7+BuJYBs6t6nw3A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=D0ESmRtu5dwpbBahex0jdKeqarjHLPs8UjuRngUnkVEyuFr5vtp9PA48MPDq3jIaQrrrhtU6j1GkZjiFoti7z/IXW0Pl/Snu136b208GN1hp6g5Q9HB3uGqk6L353ZdAF1KkThhIgwEaFyjcD8Vz8JJJEhUBoekloFqBhBZk2rQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=msqdqyL3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="msqdqyL3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4982CC19425; Sat, 28 Feb 2026 17:40:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300423; bh=GKG4WXJ0g5xS0f6lnaAyKIggdj/G7+BuJYBs6t6nw3A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=msqdqyL3hdphKnv5RM4ehse4A+KlFgPku775Gor4Z2U2f2BBkwfbQGuuOiGQHUpbJ CwwKeo/0gDqOMFr5U4xuYBX5KNGCpqPHEfzNRLQGHRf2lipTqdJZMu8z35oIiVeCkA RWs/eo1VKEF4T1lbk2pr+b1ZPmplwK7JVouGaJu3NTzhNm7mL/PFHDBCsR4eGaNfoP fChk+AJBzxdYTJiXK84hEdAnnFF9q2RnoqtLVyxsti903Yp/kZXUB9yTCXzl6N9b6H U0y47ckeSJxvzPtimV01l1+AEMcgTtkz45RXxqX5Md1qknZJJ4ZmAAh9lRNuVLH5xR HQh9nNRSFXnDQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Pavan Chebbi , Jakub Kicinski , Andy Gospodarek , Michael Chan , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 461/844] bnxt_en: Fix RSS context delete logic Date: Sat, 28 Feb 2026 12:26:14 -0500 Message-ID: <20260228173244.1509663-462-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pavan Chebbi [ Upstream commit e123d9302d223767bd910bfbcfe607bae909f8ac ] We need to free the corresponding RSS context VNIC in FW everytime an RSS context is deleted in driver. Commit 667ac333dbb7 added a check to delete the VNIC in FW only when netif_running() is true to help delete RSS contexts with interface down. Having that condition will make the driver leak VNICs in FW whenever close() happens with active RSS contexts. On the subsequent open(), as part of RSS context restoration, we will end up trying to create extra VNICs for which we did not make any reservation. FW can fail this request, thereby making us lose active RSS contexts. Suppose an RSS context is deleted already and we try to process a delete request again, then the HWRM functions will check for validity of the request and they simply return if the resource is already freed. So, even for delete-when-down cases, netif_running() check is not necessary. Remove the netif_running() condition check when deleting an RSS context. Reported-by: Jakub Kicinski Fixes: 667ac333dbb7 ("eth: bnxt: allow deleting RSS contexts when the devic= e is down") Reviewed-by: Andy Gospodarek Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260219185313.2682148-2-michael.chan@broadc= om.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethern= et/broadcom/bnxt/bnxt.c index 8419d1eb4035d..64832289e18d0 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -10827,12 +10827,10 @@ void bnxt_del_one_rss_ctx(struct bnxt *bp, struct= bnxt_rss_ctx *rss_ctx, struct bnxt_ntuple_filter *ntp_fltr; int i; =20 - if (netif_running(bp->dev)) { - bnxt_hwrm_vnic_free_one(bp, &rss_ctx->vnic); - for (i =3D 0; i < BNXT_MAX_CTX_PER_VNIC; i++) { - if (vnic->fw_rss_cos_lb_ctx[i] !=3D INVALID_HW_RING_ID) - bnxt_hwrm_vnic_ctx_free_one(bp, vnic, i); - } + bnxt_hwrm_vnic_free_one(bp, &rss_ctx->vnic); + for (i =3D 0; i < BNXT_MAX_CTX_PER_VNIC; i++) { + if (vnic->fw_rss_cos_lb_ctx[i] !=3D INVALID_HW_RING_ID) + bnxt_hwrm_vnic_ctx_free_one(bp, vnic, i); } if (!all) return; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F3BE3D16CC; Sat, 28 Feb 2026 17:40:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300424; cv=none; b=Dg0DkkAINfAkbk5MpWG7U3QLwZ5DixtYiV+XNHSfEreJ1VrDvxFdnJoEzsIgbGhcosQ47PEDJ1swJ2J51l9u3SD3POZj0n1RVpMqkW2wFnTi0Dtnfw8dFGO/4ksQ0yJv2uqdMp09OSzCHmIiKUhtrzaNdTYDhWGZ//nlytBV1rY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300424; c=relaxed/simple; bh=YsgnVC5mvlJ8X8mgQnsL8yzWbVEER0wnQ52gvS/bdnk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iloUZFWMvZZgbHVrsxlaEARaAG5KnKHDLG5cq1b0ngXg9JP3+r9792HJPOhU4C4niTsia7/du48vYaKiFvdegMZJON0iYoFhsau/r/bmQZTeAD+6fgkRIOdHwPI/LUZbbZlNhYC+J2eOWMWWP0IloOC7X/wCaFeHPVpjxggPIJo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c+K4mwOf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c+K4mwOf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6506CC19423; Sat, 28 Feb 2026 17:40:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300424; bh=YsgnVC5mvlJ8X8mgQnsL8yzWbVEER0wnQ52gvS/bdnk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c+K4mwOfhbxIbDZPpIeGfcBsO5LmoOK1VnZ3A3ragumRvAMZiq8yJGam0IgueAD+X csvfmudBB7cBK6XoXYo9WCN7BjBOoSPDXyFcWRQCSgkZeMegcD/IJpyY98rgp7EFHe DlMh3aNMUhe/Xt9l7Iu0T+AjXrP99dfSSi9gsrNKFMtoxkNXyhTPgNvftOUuaWP6+Z biFLvBv7n1C/qnapypxu0e2diRd+2uEHTETGuQLaEkqU6+F2S7AXmXDztRWfEGL/Ha DGGH5xDgxOY4dEQNVn3dPTsynX2Qd/kvCLgSotN72HfNQ4qJs7MTG2k6Fg5gPciAI7 dRJbq6p8D0IcA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Pavan Chebbi , Michael Chan , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 462/844] bnxt_en: Fix deleting of Ntuple filters Date: Sat, 28 Feb 2026 12:26:15 -0500 Message-ID: <20260228173244.1509663-463-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pavan Chebbi [ Upstream commit c1bbd9900d65ac65b9fce9f129e3369a04871570 ] Ntuple filters can be deleted when the interface is down. The current code blindly sends the filter delete command to FW. When the interface is down, all the VNICs are deleted in the FW. When the VNIC is freed in the FW, all the associated filters are also freed. We need not send the free command explicitly. Sending such command will generate FW error in the dmesg. In order to fix this, we can safely return from bnxt_hwrm_cfa_ntuple_filter_free() when BNXT_STATE_OPEN is not true which confirms the VNICs have been deleted. Fixes: 8336a974f37d ("bnxt_en: Save user configured filters in a lookup lis= t") Suggested-by: Michael Chan Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260219185313.2682148-3-michael.chan@broadc= om.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethern= et/broadcom/bnxt/bnxt.c index 64832289e18d0..c4657bb3acc18 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -6212,6 +6212,9 @@ int bnxt_hwrm_cfa_ntuple_filter_free(struct bnxt *bp, int rc; =20 set_bit(BNXT_FLTR_FW_DELETED, &fltr->base.state); + if (!test_bit(BNXT_STATE_OPEN, &bp->state)) + return 0; + rc =3D hwrm_req_init(bp, req, HWRM_CFA_NTUPLE_FILTER_FREE); if (rc) return rc; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 396B33D16ED; Sat, 28 Feb 2026 17:40:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300425; cv=none; b=IbwWeuA3/UjVP/jjyC/0WmL6Zx/2SfdKDNKFM2gTkBiLTcEgXZWrVS+hv2EPDkCFnkeKI3EtWbRtIWKF1GTqqPeAtyrdj2oRdWWEblCM/eAEDgqh43SuWEU+/o2PlXK29LLrtgh94XX+3ma+QLS+5cYRJsxbIhA+NiaP6RRoAJ0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300425; c=relaxed/simple; bh=Jb5ywi24OQ8pNIhxv/M9crNwVllSRmKpFUIzwjBM088=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pGgvuYpDWh3FhFZzhoBgtHM31lvEWrqmyFaGGOYTM3tVLgBnRQDw4XOUXcuogaT+q72exHjIyxqpwxf+vCV5FTnnv+dgHcHHeFTkRK3RvKLbjfaESDtRbP0qtjiYiUX5J3HLlTxVOhg34EO9XCGeU/CNdpcWO9sQInvPR7ovau0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qbpte7vi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qbpte7vi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 553D6C116D0; Sat, 28 Feb 2026 17:40:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300425; bh=Jb5ywi24OQ8pNIhxv/M9crNwVllSRmKpFUIzwjBM088=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qbpte7vid3xXwl2a8MkI7dIMHniVlAm2wJ/w9a2FiMBUJQAqpOAjLO9KnQXx0mnl3 f/6Z/FWwjAipp12BCQp+iD60rb+u7SmexP8d4K7TUAd7X0O9U0zQZaWUjDtY8hK+d0 mCJ2TLBql3G39wE6Qy7ZomCcrWMHkJOGw5seoYhnjFevgd3p8RHZ5zbg9KMXOFHfWi Ig1gT5dZ+RqRwRTGDNh5IxLlabNmka8q7Ned7HgBOg5odpsGzTr8yzL+huitMFs0js DnYJGjPndsi8XD6XD2QR29ONWGesLcjAwzuPavtyGlUyRVCo6W6OaXfAknx4Alx9LH KjwpjeOHwr+7Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ralf Lici , Antonio Quartulli , Sabrina Dubroca , "David S. Miller" , Sasha Levin Subject: [PATCH 6.19 463/844] ovpn: tcp - fix packet extraction from stream Date: Sat, 28 Feb 2026 12:26:16 -0500 Message-ID: <20260228173244.1509663-464-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ralf Lici [ Upstream commit d4f687fbbce45b5e88438e89b5e26c0c15847992 ] When processing TCP stream data in ovpn_tcp_recv, we receive large cloned skbs from __strp_rcv that may contain multiple coalesced packets. The current implementation has two bugs: 1. Header offset overflow: Using pskb_pull with large offsets on coalesced skbs causes skb->data - skb->head to exceed the u16 storage of skb->network_header. This causes skb_reset_network_header to fail on the inner decapsulated packet, resulting in packet drops. 2. Unaligned protocol headers: Extracting packets from arbitrary positions within the coalesced TCP stream provides no alignment guarantees for the packet data causing performance penalties on architectures without efficient unaligned access. Additionally, openvpn's 2-byte length prefix on TCP packets causes the subsequent 4-byte opcode and packet ID fields to be inherently misaligned. Fix both issues by allocating a new skb for each openvpn packet and using skb_copy_bits to extract only the packet content into the new buffer, skipping the 2-byte length prefix. Also, check the length before invoking the function that performs the allocation to avoid creating an invalid skb. If the packet has to be forwarded to userspace the 2-byte prefix can be pushed to the head safely, without misalignment. As a side effect, this approach also avoids the expensive linearization that pskb_pull triggers on cloned skbs with page fragments. In testing, this resulted in TCP throughput improvements of up to 74%. Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli Reviewed-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ovpn/tcp.c | 53 ++++++++++++++++++++++++++++-------------- 1 file changed, 36 insertions(+), 17 deletions(-) diff --git a/drivers/net/ovpn/tcp.c b/drivers/net/ovpn/tcp.c index ec2bbc28c1966..5499c1572f3e2 100644 --- a/drivers/net/ovpn/tcp.c +++ b/drivers/net/ovpn/tcp.c @@ -70,37 +70,56 @@ static void ovpn_tcp_to_userspace(struct ovpn_peer *pee= r, struct sock *sk, peer->tcp.sk_cb.sk_data_ready(sk); } =20 -static void ovpn_tcp_rcv(struct strparser *strp, struct sk_buff *skb) +static struct sk_buff *ovpn_tcp_skb_packet(const struct ovpn_peer *peer, + struct sk_buff *orig_skb, + const int pkt_len, const int pkt_off) { - struct ovpn_peer *peer =3D container_of(strp, struct ovpn_peer, tcp.strp); - struct strp_msg *msg =3D strp_msg(skb); - size_t pkt_len =3D msg->full_len - 2; - size_t off =3D msg->offset + 2; - u8 opcode; + struct sk_buff *ovpn_skb; + int err; =20 - /* ensure skb->data points to the beginning of the openvpn packet */ - if (!pskb_pull(skb, off)) { - net_warn_ratelimited("%s: packet too small for peer %u\n", - netdev_name(peer->ovpn->dev), peer->id); + /* create a new skb with only the content of the current packet */ + ovpn_skb =3D netdev_alloc_skb(peer->ovpn->dev, pkt_len); + if (unlikely(!ovpn_skb)) goto err; - } =20 - /* strparser does not trim the skb for us, therefore we do it now */ - if (pskb_trim(skb, pkt_len) !=3D 0) { - net_warn_ratelimited("%s: trimming skb failed for peer %u\n", + skb_copy_header(ovpn_skb, orig_skb); + err =3D skb_copy_bits(orig_skb, pkt_off, skb_put(ovpn_skb, pkt_len), + pkt_len); + if (unlikely(err)) { + net_warn_ratelimited("%s: skb_copy_bits failed for peer %u\n", netdev_name(peer->ovpn->dev), peer->id); + kfree_skb(ovpn_skb); goto err; } =20 - /* we need the first 4 bytes of data to be accessible + consume_skb(orig_skb); + return ovpn_skb; +err: + kfree_skb(orig_skb); + return NULL; +} + +static void ovpn_tcp_rcv(struct strparser *strp, struct sk_buff *skb) +{ + struct ovpn_peer *peer =3D container_of(strp, struct ovpn_peer, tcp.strp); + struct strp_msg *msg =3D strp_msg(skb); + int pkt_len =3D msg->full_len - 2; + u8 opcode; + + /* we need at least 4 bytes of data in the packet * to extract the opcode and the key ID later on */ - if (!pskb_may_pull(skb, OVPN_OPCODE_SIZE)) { + if (unlikely(pkt_len < OVPN_OPCODE_SIZE)) { net_warn_ratelimited("%s: packet too small to fetch opcode for peer %u\n= ", netdev_name(peer->ovpn->dev), peer->id); goto err; } =20 + /* extract the packet into a new skb */ + skb =3D ovpn_tcp_skb_packet(peer, skb, pkt_len, msg->offset + 2); + if (unlikely(!skb)) + goto err; + /* DATA_V2 packets are handled in kernel, the rest goes to user space */ opcode =3D ovpn_opcode_from_skb(skb, 0); if (unlikely(opcode !=3D OVPN_DATA_V2)) { @@ -113,7 +132,7 @@ static void ovpn_tcp_rcv(struct strparser *strp, struct= sk_buff *skb) /* The packet size header must be there when sending the packet * to userspace, therefore we put it back */ - skb_push(skb, 2); + *(__be16 *)__skb_push(skb, sizeof(u16)) =3D htons(pkt_len); ovpn_tcp_to_userspace(peer, strp->sk, skb); return; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 402313D16D2; Sat, 28 Feb 2026 17:40:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300426; cv=none; b=sqwMA5x8wBrM9ZBez8lZCmWoNAnODNnRt7l90FRzZpvexFwG+P2HUGRQS/LlE/i5O6K956iT8x/0n60beFS9GGbp63RXJZxRdd3Pn6mtjoNc0fH/U3nQ9LLZ7EU3qQt8GXjP9cOjs78bgYjhsBfA9eP19SbbF8rxKOQAiVIkO7I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300426; c=relaxed/simple; bh=YRK9ONJlnM2sOe/cu5jE1EbEEdK76nUezm1zHZimbN0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P3x6lF6Ofn7LJr/knk701Cd6nQpmLQD4AnPGp6Z1LQxUXTu2d612z5gNWSMLO+fWwDRVBvEvQHGLqwct/QegEj6md0VBsV9mg4SBDuGRKQMNArPS6NPUkRjF6Fpn/acz55YRNv3jKrXnqyu7PyQilgXIJ7uHzQP4U01AOAVryI4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Q/8lLlLY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Q/8lLlLY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F665C19423; Sat, 28 Feb 2026 17:40:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300426; bh=YRK9ONJlnM2sOe/cu5jE1EbEEdK76nUezm1zHZimbN0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q/8lLlLY4ioxQ9SNLEIJrJDdHoub6bdfJX0Q55nFWNAT/AqdEzYdxRKNhF8vlrXQu wr3QSldv6XonA54+5H+3VdSZQRdUMMjO6yZ4h10VR48sXpwQJxAqloeleQgVL4DNry cEltmxKxIpZ6+ht7WfqX1rNJrCz2pF0/hOny9oWZh4WZKjF7PT9JBqmJe9KJmr5nLy 1PfL0HANXflhgzSqnRFoJCjkHOR/Y2RyK0GE6KQGNZn2vTbT1FIL7P6580pjxmRh/s tqtQbYK8SL+aDhbIvAMyglBrftFdTWeaUxPcimy+mawI6LVqi8itnwKL7+egBoV+eH YHQQp2yylJmuQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nicholas Carlini , Stefan Metzmacher , Namjae Jeon , Steve French , Sasha Levin Subject: [PATCH 6.19 464/844] ksmbd: fix signededness bug in smb_direct_prepare_negotiation() Date: Sat, 28 Feb 2026 12:26:17 -0500 Message-ID: <20260228173244.1509663-465-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicholas Carlini [ Upstream commit 6b4f875aac344cdd52a1f34cc70ed2f874a65757 ] smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32) Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and = tranport layers") Signed-off-by: Nicholas Carlini Reviewed-by: Stefan Metzmacher Acked-by: Stefan Metzmacher Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/smb/server/transport_rdma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/smb/server/transport_rdma.c b/fs/smb/server/transport_rdma.c index c94068b78a1d2..dcc7a6c20d6f8 100644 --- a/fs/smb/server/transport_rdma.c +++ b/fs/smb/server/transport_rdma.c @@ -2527,9 +2527,9 @@ static int smb_direct_prepare(struct ksmbd_transport = *t) goto put; =20 req =3D (struct smbdirect_negotiate_req *)recvmsg->packet; - sp->max_recv_size =3D min_t(int, sp->max_recv_size, + sp->max_recv_size =3D min_t(u32, sp->max_recv_size, le32_to_cpu(req->preferred_send_size)); - sp->max_send_size =3D min_t(int, sp->max_send_size, + sp->max_send_size =3D min_t(u32, sp->max_send_size, le32_to_cpu(req->max_receive_size)); sp->max_fragmented_send_size =3D le32_to_cpu(req->max_fragmented_size); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 18B1B3D2452; Sat, 28 Feb 2026 17:40:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300427; cv=none; b=SIXah/L+4WzsCPN61+hXgXwnfvRXdR2l+indB+c1v/zDJZ4EZflohsRZauju/7l92k1IX7dQ2G1ZKY5qLBJnSWu+q39UQm6r+VCeBop6d08DhY0mb2chDOjp04NxmByAFNqOyShJ0LLGs8VKBXhSJgvAdEm7xhd72yIgPkMDI2k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300427; c=relaxed/simple; bh=dLPGJNofiRNB53LoWfuvKRZy9fh8nZFlbeV2LQiNivc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p1oQbHN9x9X/wKbPoBYZpgBaPqBjEzxS+vZDlHD9PRXb8YE5nTzqqkVqR/tJXi1tRq2Hb5ZZwHRq6scS5HpNROU2z3QrnQ4KK4dlNyKQ2eKnI2HspmaL7HvF9mtsT89tr1UHder/9LI7bi8kFzNVceaCKH7RPZT4ozHYt8vwylA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XPZPSa+h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XPZPSa+h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64C5BC116D0; Sat, 28 Feb 2026 17:40:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300427; bh=dLPGJNofiRNB53LoWfuvKRZy9fh8nZFlbeV2LQiNivc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XPZPSa+hPDPro9iRvtV+yl2Mxx8Ir0G30tVjNlSge69z1An9pIUZYQGO0148H3azO 9Vqk3Y2mLhLL7Eskrp2bDYIOzm6z8c4m6Qbnho2tThgmJegZP3Vpw+0GSzSyabp0kH pohbsmMJQ6XDk6DGul3XQeLbjV7PHcRDQEYpaspRAgACgnMz+2FUyKD9dm0NK93X5C 2tcxzrNZcRbYf8MVCKByblMCm0g4HfJaikEWQZ/xKIf2BCtw7HDyr4L2wM179m0XI1 /XEY1RAeKvf3dDTul6tL0XUmVCXFyV6D0CFGtzlFMS7bUvpKSA2aiD0/bzoRTx3ZoH qnfEJ8sQucwQA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiri Pirko , Marek Szyprowski , Sasha Levin Subject: [PATCH 6.19 465/844] dma-mapping: avoid random addr value print out on error path Date: Sat, 28 Feb 2026 12:26:18 -0500 Message-ID: <20260228173244.1509663-466-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiri Pirko [ Upstream commit 47322c469d4a63ac45b705ca83680671ff71c975 ] dma_addr is unitialized in dma_direct_map_phys() when swiotlb is forced and DMA_ATTR_MMIO is set which leads to random value print out in warning. Fix that by just returning DMA_MAPPING_ERROR. Fixes: e53d29f957b3 ("dma-mapping: convert dma_direct_*map_page to be phys_= addr_t based") Signed-off-by: Jiri Pirko Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260209153809.250835-2-jiri@resnulli.us Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/dma/direct.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h index da2fadf45bcd6..62f0d9d0ba02e 100644 --- a/kernel/dma/direct.h +++ b/kernel/dma/direct.h @@ -88,7 +88,7 @@ static inline dma_addr_t dma_direct_map_phys(struct devic= e *dev, =20 if (is_swiotlb_force_bounce(dev)) { if (attrs & DMA_ATTR_MMIO) - goto err_overflow; + return DMA_MAPPING_ERROR; =20 return swiotlb_map(dev, phys, size, dir, attrs); } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C8B13D2468; Sat, 28 Feb 2026 17:40:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300428; cv=none; b=s3QdmucI3zHq70NDbuNKEQCm7r4eEfCWq7nrSqescxi/uOEvgqlIqvVTA5zzOJhcX0CXhDJovhmvaRkVjDoqU4wYAqfZECwPwmA7ks+Jpv+g3Z5B6k4iDItJSjUkjXkDJqI5dvYdakRqECVJlSpbRueiN5jX0ChQNgA9yqKmpXc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300428; c=relaxed/simple; bh=Uir/nTXAjJY5kvnSsz0oWmIUwVbzB1gRI+aYvUOgwgs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IdIkCtHEkW7R9J7nOJ4/09bI+BMMFrFFcn0wCtnPIP3bzTAB/fLH8HiljoOeP3qdhWd6bhewItEZiCS+Jsq8/WP0Y2ISC71z9JB29SzKqeXNO06CxEjTRQj8yMDPqZO74xVtPUoA5LLJ6M6z4y9radj8K4te4j0hIoBqTRlT13k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gEZrIwLM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gEZrIwLM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F311C116D0; Sat, 28 Feb 2026 17:40:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300428; bh=Uir/nTXAjJY5kvnSsz0oWmIUwVbzB1gRI+aYvUOgwgs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gEZrIwLMV5zRfSiHxFJARNE2FRf3Iux8ViarxlEBPFMIXZjOj01H72oIUNXnoYyGr WFHpinq341fpYNohzV9OQMDVJ5fIvGXb/KVM/R1fr29fBRXnXpCzyOYoTRVL6kACNw C0tTey+/CU0mikgj4Wk1FS2x99xtNSmfEuNB3mVPj967Ke0Hu+98bHsIPdVPpS9xUT XoBJHp/QFMCDQSXXldD6TGkzX5O9efF3Bm6pqFbDuNV5P2a1gt4pe+D7y5LGIWjfMU 3r4MOiql6hL+ibzA60iy44oCRbgkMkj+iqzIldnfSKoraTEeC1BhG7swak+9i4tDlp KhyW6F/xmlqhQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Stian Halseth , Marek Szyprowski , Nathaniel Roach , Han Gao , Sasha Levin Subject: [PATCH 6.19 466/844] sparc: Fix page alignment in dma mapping Date: Sat, 28 Feb 2026 12:26:19 -0500 Message-ID: <20260228173244.1509663-467-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Stian Halseth [ Upstream commit d5b5e8149af0f5efed58653cbebf1cb3258ce49a ] 'phys' may include an offset within the page, while previously used 'base_paddr' was already page-aligned. This caused incorrect DMA mapping in dma_4u_map_phys and dma_4v_map_phys. Fix both functions by masking 'phys' with IO_PAGE_MASK, covering both generic SPARC code and sun4v. Fixes: 38c0d0ebf520 ("sparc: Use physical address DMA mapping") Reported-by: Stian Halseth Closes: https://github.com/sparclinux/issues/issues/75 Suggested-by: Marek Szyprowski Signed-off-by: Stian Halseth Tested-by: Nathaniel Roach Tested-by: Han Gao # on SPARC Enterprise T5220 [mszyprow: adjusted commit description a bit] Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260218120056.3366-2-stian@itx.no Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/sparc/kernel/iommu.c | 2 ++ arch/sparc/kernel/pci_sun4v.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c index 46ef88bc9c26e..7613ab0ffb89d 100644 --- a/arch/sparc/kernel/iommu.c +++ b/arch/sparc/kernel/iommu.c @@ -312,6 +312,8 @@ static dma_addr_t dma_4u_map_phys(struct device *dev, p= hys_addr_t phys, if (direction !=3D DMA_TO_DEVICE) iopte_protection |=3D IOPTE_WRITE; =20 + phys &=3D IO_PAGE_MASK; + for (i =3D 0; i < npages; i++, base++, phys +=3D IO_PAGE_SIZE) iopte_val(*base) =3D iopte_protection | phys; =20 diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c index 791f0a76665f6..58ca4148f86be 100644 --- a/arch/sparc/kernel/pci_sun4v.c +++ b/arch/sparc/kernel/pci_sun4v.c @@ -410,6 +410,8 @@ static dma_addr_t dma_4v_map_phys(struct device *dev, p= hys_addr_t phys, =20 iommu_batch_start(dev, prot, entry); =20 + phys &=3D IO_PAGE_MASK; + for (i =3D 0; i < npages; i++, phys +=3D IO_PAGE_SIZE) { long err =3D iommu_batch_add(phys, mask); if (unlikely(err < 0L)) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF2243D47C2; Sat, 28 Feb 2026 17:40:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300429; cv=none; b=KeML/XgymD32Q0vPKxmJ4j4mt2jS4te5t6Us4en2gmvLB92DIUmOYn6Nv0UFwC6Xt4wzcRZvaoPrsd14USRuPydsPfWGu3lhHbA9yIBO2gsAlHAZXd5+BIr//HBQia2uR10Zf7wEhYB7yoFNKQOJAxkSO1oTEhIc09DFut6bgAk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300429; c=relaxed/simple; bh=Z3JggKkIQWZ7ZM1BGBwbAxjDIQXOhJSkTCR4Gf/52sM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G9Fr21+PHDDt+W2Lmt11tA0WO6QAHlh6FK4lajK+DGQOb7oLRkfaNvTrBdAaZN7OLSSrljOQHfwsbfBqM3TyLT6cbVS6KPYhsdkZTEoeshnRNiGfWGkNKTusVxM+ACjiR3BfCH3BMCgQpfyvEDhbWBpmq6MhpQcaQEz22kD2zVc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RxXOKymA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RxXOKymA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4616BC19424; Sat, 28 Feb 2026 17:40:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300428; bh=Z3JggKkIQWZ7ZM1BGBwbAxjDIQXOhJSkTCR4Gf/52sM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RxXOKymA7+/KR8QYSsn0r09zgv8J83MwFktxEE73f2LSZED5tPD/7uuJjTNZ0HB8f dGbRd3vFnGjN2Hlkw/13e4A58aoJzzPVqvY5CdnKEZp47Ic56xTY3JK/W+vORm1ZgZ SXky4RJ+F3dWr2LBA5gTItyXv9HdrhV01eHPfOlJbw/U52QEcZlW85Oi4GKkkz0V4A eVvgSPsKEkEPmXPChoQjEVks9upF3sal6rzLFAm0jk7JMnyaViflBTACq0fS0FFRz0 diAdatYunIvPahea/E3DVm0/C7QWjwlEEBQtpVFZV7hvsOIw9gAWeD2gWbpfgcieor F2PFrM5vyIvAw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Jouni Malinen , Sasha Levin Subject: [PATCH 6.19 467/844] wifi: cfg80211: wext: fix IGTK key ID off-by-one Date: Sat, 28 Feb 2026 12:26:20 -0500 Message-ID: <20260228173244.1509663-468-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit c8d7f21ead727485ebf965e2b4d42d4a4f0840f6 ] The IGTK key ID must be 4 or 5, but the code checks against key ID + 1, so must check against 5/6 rather than 4/5. Fix that. Reported-by: Jouni Malinen Fixes: 08645126dd24 ("cfg80211: implement wext key handling") Link: https://patch.msgid.link/20260209181220.362205-2-johannes@sipsolution= s.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/wireless/wext-compat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c index 1241fda78a68c..680500fa57cfd 100644 --- a/net/wireless/wext-compat.c +++ b/net/wireless/wext-compat.c @@ -684,7 +684,7 @@ static int cfg80211_wext_siwencodeext(struct net_device= *dev, =20 idx =3D erq->flags & IW_ENCODE_INDEX; if (cipher =3D=3D WLAN_CIPHER_SUITE_AES_CMAC) { - if (idx < 4 || idx > 5) { + if (idx < 5 || idx > 6) { idx =3D wdev->wext.default_mgmt_key; if (idx < 0) return -EINVAL; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE9323D47E0; Sat, 28 Feb 2026 17:40:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300429; cv=none; b=SDng1VgSSmFAUYtpG4Dc+tFSjGN9qC1WOYcvFROojC2bHS6XwgZKKC454h9b/xCwIn3Oev35trDlh2m7DDbn0VrM4ADSW4t7v9TcSJ25V2VgzUKdKbfpxURntOIwdxpWjxUN2sDldxteyiDXlGQLwmxLSuCYtfAKwHdJiEAHow4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300429; c=relaxed/simple; bh=V5zwxPQQmhoylxmdGBbyD7S0kz+77ermZOUg3JESav4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=i6g28zUls4C1dWMiqGU5AD/MeQwAHsW6w2IYD03NqyHTmgwXGZGrdVjwKHEAUAlyAqq33XhorGHMqz1AgnAlTQgdfQGh8cFtHPqSDWNOfDztoTbhsHRtCc2+F1Gm3Ya5RVX2105wcE0snHHXXBpUAUIWXbeJA3VXLXquoFRGRzI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I3YoKf0+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I3YoKf0+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1FDCAC116D0; Sat, 28 Feb 2026 17:40:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300429; bh=V5zwxPQQmhoylxmdGBbyD7S0kz+77ermZOUg3JESav4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I3YoKf0+2DCR3MO3dRUiGvBM9aldd2rBFYH6WPIJxzQgEaJeZnQ2AMWbHhd55YOwi IsuT4Vg3NLrrtnzPCRVJzQK4SPXCTtOdxYplwALU9WPN+2WOlLjpcoWC/gSm0XhIix sGM1GUgc5HkRGT9l47wbJIIdh3FaWk1UyyatNAhS2yl6qTK7j3/cm4Iwvfhi7qwLNA EQMYoO31HMstouJAbaOQ7c/6lkLLC4lyp6Ct5GiGE6vgbs1UzHjuOzynZdZVkiBhV6 tEj7beZo0MrK4vm1fdocBFa63EHHR73odnYafNG9aju3aZGNsY2gLLeY+jpqAWNutn 3TX53MZBnRDtA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Marek Szyprowski , Arend van Spriel , Johannes Berg , Sasha Levin Subject: [PATCH 6.19 468/844] wifi: brcmfmac: Fix potential kernel oops when probe fails Date: Sat, 28 Feb 2026 12:26:21 -0500 Message-ID: <20260228173244.1509663-469-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marek Szyprowski [ Upstream commit 243307a0d1b0d01538e202c00454c28b21d4432e ] When probe of the sdio brcmfmac device fails for some reasons (i.e. missing firmware), the sdiodev->bus is set to error instead of NULL, thus the cleanup later in brcmf_sdio_remove() tries to free resources via invalid bus pointer. This happens because sdiodev->bus is set 2 times: first in brcmf_sdio_probe() and second time in brcmf_sdiod_probe(). Fix this by chaning the brcmf_sdio_probe() function to return the error code and set sdio->bus only there. Fixes: 0ff0843310b7 ("wifi: brcmfmac: Add optional lpo clock enable support= ") Signed-off-by: Marek Szyprowski Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260203102133.1478331-1-m.szyprowski@samsun= g.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 7 +++---- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 ++++--- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/dr= ivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index 6a3f187320fc4..13952dfeb3e30 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c @@ -951,11 +951,10 @@ int brcmf_sdiod_probe(struct brcmf_sdio_dev *sdiodev) goto out; =20 /* try to attach to the target device */ - sdiodev->bus =3D brcmf_sdio_probe(sdiodev); - if (IS_ERR(sdiodev->bus)) { - ret =3D PTR_ERR(sdiodev->bus); + ret =3D brcmf_sdio_probe(sdiodev); + if (ret) goto out; - } + brcmf_sdiod_host_fixup(sdiodev->func2->card->host); out: if (ret) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/driv= ers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c index 8cf9d7e7c3f70..4e6ed02c15913 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -4445,7 +4445,7 @@ brcmf_sdio_prepare_fw_request(struct brcmf_sdio *bus) return fwreq; } =20 -struct brcmf_sdio *brcmf_sdio_probe(struct brcmf_sdio_dev *sdiodev) +int brcmf_sdio_probe(struct brcmf_sdio_dev *sdiodev) { int ret; struct brcmf_sdio *bus; @@ -4551,11 +4551,12 @@ struct brcmf_sdio *brcmf_sdio_probe(struct brcmf_sd= io_dev *sdiodev) goto fail; } =20 - return bus; + return 0; =20 fail: brcmf_sdio_remove(bus); - return ERR_PTR(ret); + sdiodev->bus =3D NULL; + return ret; } =20 /* Detach and free everything */ diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h b/driv= ers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h index 0d18ed15b4032..80180d5c6c879 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h @@ -358,7 +358,7 @@ void brcmf_sdiod_freezer_uncount(struct brcmf_sdio_dev = *sdiodev); int brcmf_sdiod_probe(struct brcmf_sdio_dev *sdiodev); int brcmf_sdiod_remove(struct brcmf_sdio_dev *sdiodev); =20 -struct brcmf_sdio *brcmf_sdio_probe(struct brcmf_sdio_dev *sdiodev); +int brcmf_sdio_probe(struct brcmf_sdio_dev *sdiodev); void brcmf_sdio_remove(struct brcmf_sdio *bus); void brcmf_sdio_isr(struct brcmf_sdio *bus, bool in_isr); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB2053D47FB; Sat, 28 Feb 2026 17:40:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300430; cv=none; b=CRpGfwZ8OHXyJ1Dg1EGS43i77vgMMLa8FZ2boZwXAfaBE+tjwBUuaZFIDZ2zO5gjiKEeLvusExrXCDrR5W8jo+w9Dpm2oVDWLXMGmZsdOt9BwzkIOPwU9DQvCzOQKQSMyGQ95fU/qQRtyuBy8mzqduJdkylTaKUJzNGd4DNABVo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300430; c=relaxed/simple; bh=baLELUhdSxS/P2kMWgbDYgUhWZDPxAux4hCEsjWRBz0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cF+tW/sBpnoJwF9NpfkEilA2JmPVjUMBGHNvAL9QUNRBx3Q+5pQ3oMJT6YA0CRhfrDwAW0K7bEChbk0l1jFmEWjdt0U7FuYvFkcM3ZVNJzcZWPQzdri0YfjK+9/j/dEjXY5PulrcOsGVgyrwgU+Z/VpBd6hE4YjGmLOCr9kP4rk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i/VKSl4l; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="i/VKSl4l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11B16C19423; Sat, 28 Feb 2026 17:40:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300430; bh=baLELUhdSxS/P2kMWgbDYgUhWZDPxAux4hCEsjWRBz0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i/VKSl4lCD2bTFH0S/IHP4sTvqPSOXVRNBBfSUyBnCCsqA98lYgWWAkzZMKLGMvFZ PNKO+3D2+KSoG9+rKsh6858f2wOIQCecbV7Of8aPsQMKHExSJNNNeMjIhD2vGe+nkh V6eLXqyswxh3XArYx10M/H1oJkHr3eG/Igo4ssGLC55RcuzGcgPQDlMUNqUOlKthUo 8/KEk6QNpVQaPreN+R/4fdpiY8CqPO68L/JQuIONohSXJ+/NP3H+Aq/Vb54UvAtF1r 7wB5awQgVXx/rwf5+pMZPzQTqtxQDX2/xLVh00JBGJHoAcVnWwBpTZm/F5LsaEy+ft XrSyvlxb+Rr/A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Linus Torvalds , Jason Donenfeld , Sasha Levin Subject: [PATCH 6.19 469/844] Remove WARN_ALL_UNSEEDED_RANDOM kernel config option Date: Sat, 28 Feb 2026 12:26:22 -0500 Message-ID: <20260228173244.1509663-470-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Linus Torvalds [ Upstream commit 7dff99b354601dd01829e1511711846e04340a69 ] This config option goes way back - it used to be an internal debug option to random.c (at that point called DEBUG_RANDOM_BOOT), then was renamed and exposed as a config option as CONFIG_WARN_UNSEEDED_RANDOM, and then further renamed to the current CONFIG_WARN_ALL_UNSEEDED_RANDOM. It was all done with the best of intentions: the more limited rate-limited reports were reporting some cases, but if you wanted to see all the gory details, you'd enable this "ALL" option. However, it turns out - perhaps not surprisingly - that when people don't care about and fix the first rate-limited cases, they most certainly don't care about any others either, and so warning about all of them isn't actually helping anything. And the non-ratelimited reporting causes problems, where well-meaning people enable debug options, but the excessive flood of messages that nobody cares about will hide actual real information when things go wrong. I just got a kernel bug report (which had nothing to do with randomness) where two thirds of the the truncated dmesg was just variations of random: get_random_u32 called from __get_random_u32_below+0x10/0x70 with= crng_init=3D0 and in the process early boot messages had been lost (in addition to making the messages that _hadn't_ been lost harder to read). The proper way to find these things for the hypothetical developer that cares - if such a person exists - is almost certainly with boot time tracing. That gives you the option to get call graphs etc too, which is likely a requirement for fixing any problems anyway. See Documentation/trace/boottime-trace.rst for that option. And if we for some reason do want to re-introduce actual printing of these things, it will need to have some uniqueness filtering rather than this "just print it all" model. Fixes: cc1e127bfa95 ("random: remove ratelimiting for in-kernel unseeded ra= ndomness") Acked-by: Jason Donenfeld Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/char/random.c | 12 +----------- kernel/configs/debug.config | 1 - lib/Kconfig.debug | 27 --------------------------- 3 files changed, 1 insertion(+), 39 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index bab03c7c4194a..c36c76c2e88e0 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -96,8 +96,7 @@ static ATOMIC_NOTIFIER_HEAD(random_ready_notifier); /* Control how we warn userspace. */ static struct ratelimit_state urandom_warning =3D RATELIMIT_STATE_INIT_FLAGS("urandom_warning", HZ, 3, RATELIMIT_MSG_ON_REL= EASE); -static int ratelimit_disable __read_mostly =3D - IS_ENABLED(CONFIG_WARN_ALL_UNSEEDED_RANDOM); +static int ratelimit_disable __read_mostly =3D 0; module_param_named(ratelimit_disable, ratelimit_disable, int, 0644); MODULE_PARM_DESC(ratelimit_disable, "Disable random ratelimit suppression"= ); =20 @@ -168,12 +167,6 @@ int __cold execute_with_initialized_rng(struct notifie= r_block *nb) return ret; } =20 -#define warn_unseeded_randomness() \ - if (IS_ENABLED(CONFIG_WARN_ALL_UNSEEDED_RANDOM) && !crng_ready()) \ - printk_deferred(KERN_NOTICE "random: %s called from %pS with crng_init= =3D%d\n", \ - __func__, (void *)_RET_IP_, crng_init) - - /********************************************************************* * * Fast key erasure RNG, the "crng". @@ -434,7 +427,6 @@ static void _get_random_bytes(void *buf, size_t len) */ void get_random_bytes(void *buf, size_t len) { - warn_unseeded_randomness(); _get_random_bytes(buf, len); } EXPORT_SYMBOL(get_random_bytes); @@ -523,8 +515,6 @@ type get_random_ ##type(void) \ struct batch_ ##type *batch; \ unsigned long next_gen; \ \ - warn_unseeded_randomness(); \ - \ if (!crng_ready()) { \ _get_random_bytes(&ret, sizeof(ret)); \ return ret; \ diff --git a/kernel/configs/debug.config b/kernel/configs/debug.config index 9f6ab7dabf672..0a6c1763d976e 100644 --- a/kernel/configs/debug.config +++ b/kernel/configs/debug.config @@ -29,7 +29,6 @@ CONFIG_SECTION_MISMATCH_WARN_ONLY=3Dy # CONFIG_UBSAN_ALIGNMENT is not set # CONFIG_UBSAN_DIV_ZERO is not set # CONFIG_UBSAN_TRAP is not set -# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set CONFIG_DEBUG_FS=3Dy CONFIG_DEBUG_FS_ALLOW_ALL=3Dy CONFIG_DEBUG_IRQFLAGS=3Dy diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index cda3cf1fa302c..4bae3b389a9c5 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1687,33 +1687,6 @@ config STACKTRACE It is also used by various kernel debugging features that require stack trace generation. =20 -config WARN_ALL_UNSEEDED_RANDOM - bool "Warn for all uses of unseeded randomness" - default n - help - Some parts of the kernel contain bugs relating to their use of - cryptographically secure random numbers before it's actually possible - to generate those numbers securely. This setting ensures that these - flaws don't go unnoticed, by enabling a message, should this ever - occur. This will allow people with obscure setups to know when things - are going wrong, so that they might contact developers about fixing - it. - - Unfortunately, on some models of some architectures getting - a fully seeded CRNG is extremely difficult, and so this can - result in dmesg getting spammed for a surprisingly long - time. This is really bad from a security perspective, and - so architecture maintainers really need to do what they can - to get the CRNG seeded sooner after the system is booted. - However, since users cannot do anything actionable to - address this, by default this option is disabled. - - Say Y here if you want to receive warnings for all uses of - unseeded randomness. This will be of use primarily for - those developers interested in improving the security of - Linux kernels running on their architecture (or - subarchitecture). - config DEBUG_KOBJECT bool "kobject debugging" depends on DEBUG_KERNEL --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B2E553D5646; Sat, 28 Feb 2026 17:40:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300431; cv=none; b=Qeo7r1XzPCw2e4il8zlzg0H5NkdjP/uBPAgwZT/fRXdtPABvIYDveltY+PysROM5I4BPjKb3HZKqHa7c5GMUalYdinpC4RQSqVXDWewlp46knCoFBUm9M+XIKHaSCJzHbkn+ACEIGgGBRG9g6xFe2gpGmeIlIlomFFuLxqtwkHA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300431; c=relaxed/simple; bh=ocHrck2TQZJancoEowj8OAOvZJd3MHztoq2hv2rFfTM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FxHejTTBOKkVKU0Y7p8GrGQz7UyGiOx9dSy6EZoaVSbTCJNIM+1QD+ozN/lIBwKrAgruaa6nTlv+2fzeVy9IprMEzsml35sd4HfF5rHZMauFxQxLWHYcU5M7ZkRaxtzR/EURlE9QVtRyJuGSNHFKgWqA9Lz3ZAVk4JIDIDlrQj8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Qwts9uwf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Qwts9uwf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2447C116D0; Sat, 28 Feb 2026 17:40:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300431; bh=ocHrck2TQZJancoEowj8OAOvZJd3MHztoq2hv2rFfTM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Qwts9uwfgtUGtOI1mjNLBRqlVkcIYQDyJjWp71apbu0Sg7bjBmQ66NWdg9pKND0ZD go5ivAqXaGvH/Ha/a4m68meDkRywF99Ykq5Im6Grsf3413ZfA1Tb9EYpNEXuqLOT+Z f7UVtI4ney8QWXja63O4CVQT/8eAzEtdTb9ZgOL6eAZ6VlgOxMZ8lPaW/nRxRWuzlK a+ThwvT0fh0CaEkTos5dUhnwWALKzODBN7nFrTPjjJujZHRBytLS1K5LPV1fB8tj1c Tlq3pQc0tSFLriZKvd8kqGGCO80SCmWwcR1SoKzEqcAiyPFZIyEciAjiSs7i+Yin1N w2BFtOXHecxLA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 470/844] Bluetooth: L2CAP: Fix invalid response to L2CAP_ECRED_RECONF_REQ Date: Sat, 28 Feb 2026 12:26:23 -0500 Message-ID: <20260228173244.1509663-471-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit 7accb1c4321acb617faf934af59d928b0b047e2b ] This fixes responding with an invalid result caused by checking the wrong size of CID which should have been (cmd_len - sizeof(*req)) and on top of it the wrong result was use L2CAP_CR_LE_INVALID_PARAMS which is invalid/reserved for reconf when running test like L2CAP/ECFC/BI-03-C: > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 64 MPS: 64 Source CID: 64 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reserved (0x000c) Result: Reconfiguration failed - one or more Destination CIDs inva= lid (0x0003) Fiix L2CAP/ECFC/BI-04-C which expects L2CAP_RECONF_INVALID_MPS (0x0002) when more than one channel gets its MPS reduced: > ACL Data RX: Handle 64 flags 0x02 dlen 16 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 8 MTU: 264 MPS: 99 Source CID: 64 ! Source CID: 65 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - reduction in size of MPS not allo= wed for more than one channel at a time (0x0002) Fix L2CAP/ECFC/BI-05-C when SCID is invalid (85 unconnected): > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 65 MPS: 64 ! Source CID: 85 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - one or more Destination CIDs inva= lid (0x0003) Fix L2CAP/ECFC/BI-06-C when MPS < L2CAP_ECRED_MIN_MPS (64): > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 672 ! MPS: 63 Source CID: 64 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration failed - reduction in size of MPS not allow= ed for more than one channel at a time (0x0002) Result: Reconfiguration failed - other unacceptable parameters (0x0= 004) Fix L2CAP/ECFC/BI-07-C when MPS reduced for more than one channel: > ACL Data RX: Handle 64 flags 0x02 dlen 16 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 3 len 8 MTU: 84 ! MPS: 71 Source CID: 64 ! Source CID: 65 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - reduction in size of MPS not allow= ed for more than one channel at a time (0x0002) Link: https://github.com/bluez/bluez/issues/1865 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credi= t Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/net/bluetooth/l2cap.h | 2 ++ net/bluetooth/l2cap_core.c | 63 +++++++++++++++++++++++++---------- 2 files changed, 47 insertions(+), 18 deletions(-) diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h index 00e182a22720a..9820ccc379f1c 100644 --- a/include/net/bluetooth/l2cap.h +++ b/include/net/bluetooth/l2cap.h @@ -493,6 +493,8 @@ struct l2cap_ecred_reconf_req { #define L2CAP_RECONF_SUCCESS 0x0000 #define L2CAP_RECONF_INVALID_MTU 0x0001 #define L2CAP_RECONF_INVALID_MPS 0x0002 +#define L2CAP_RECONF_INVALID_CID 0x0003 +#define L2CAP_RECONF_INVALID_PARAMS 0x0004 =20 struct l2cap_ecred_reconf_rsp { __le16 result; diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 07b493331fd78..e705b4a171dec 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -5294,14 +5294,14 @@ static inline int l2cap_ecred_reconf_req(struct l2c= ap_conn *conn, struct l2cap_ecred_reconf_req *req =3D (void *) data; struct l2cap_ecred_reconf_rsp rsp; u16 mtu, mps, result; - struct l2cap_chan *chan; + struct l2cap_chan *chan[L2CAP_ECRED_MAX_CID] =3D {}; int i, num_scid; =20 if (!enable_ecred) return -EINVAL; =20 - if (cmd_len < sizeof(*req) || cmd_len - sizeof(*req) % sizeof(u16)) { - result =3D L2CAP_CR_LE_INVALID_PARAMS; + if (cmd_len < sizeof(*req) || (cmd_len - sizeof(*req)) % sizeof(u16)) { + result =3D L2CAP_RECONF_INVALID_CID; goto respond; } =20 @@ -5311,42 +5311,69 @@ static inline int l2cap_ecred_reconf_req(struct l2c= ap_conn *conn, BT_DBG("mtu %u mps %u", mtu, mps); =20 if (mtu < L2CAP_ECRED_MIN_MTU) { - result =3D L2CAP_RECONF_INVALID_MTU; + result =3D L2CAP_RECONF_INVALID_PARAMS; goto respond; } =20 if (mps < L2CAP_ECRED_MIN_MPS) { - result =3D L2CAP_RECONF_INVALID_MPS; + result =3D L2CAP_RECONF_INVALID_PARAMS; goto respond; } =20 cmd_len -=3D sizeof(*req); num_scid =3D cmd_len / sizeof(u16); + + if (num_scid > L2CAP_ECRED_MAX_CID) { + result =3D L2CAP_RECONF_INVALID_PARAMS; + goto respond; + } + result =3D L2CAP_RECONF_SUCCESS; =20 + /* Check if each SCID, MTU and MPS are valid */ for (i =3D 0; i < num_scid; i++) { u16 scid; =20 scid =3D __le16_to_cpu(req->scid[i]); - if (!scid) - return -EPROTO; + if (!scid) { + result =3D L2CAP_RECONF_INVALID_CID; + goto respond; + } =20 - chan =3D __l2cap_get_chan_by_dcid(conn, scid); - if (!chan) - continue; + chan[i] =3D __l2cap_get_chan_by_dcid(conn, scid); + if (!chan[i]) { + result =3D L2CAP_RECONF_INVALID_CID; + goto respond; + } =20 - /* If the MTU value is decreased for any of the included - * channels, then the receiver shall disconnect all - * included channels. + /* The MTU field shall be greater than or equal to the greatest + * current MTU size of these channels. */ - if (chan->omtu > mtu) { - BT_ERR("chan %p decreased MTU %u -> %u", chan, - chan->omtu, mtu); + if (chan[i]->omtu > mtu) { + BT_ERR("chan %p decreased MTU %u -> %u", chan[i], + chan[i]->omtu, mtu); result =3D L2CAP_RECONF_INVALID_MTU; + goto respond; } =20 - chan->omtu =3D mtu; - chan->remote_mps =3D mps; + /* If more than one channel is being configured, the MPS field + * shall be greater than or equal to the current MPS size of + * each of these channels. If only one channel is being + * configured, the MPS field may be less than the current MPS + * of that channel. + */ + if (chan[i]->remote_mps >=3D mps && i) { + BT_ERR("chan %p decreased MPS %u -> %u", chan[i], + chan[i]->remote_mps, mps); + result =3D L2CAP_RECONF_INVALID_MPS; + goto respond; + } + } + + /* Commit the new MTU and MPS values after checking they are valid */ + for (i =3D 0; i < num_scid; i++) { + chan[i]->omtu =3D mtu; + chan[i]->remote_mps =3D mps; } =20 respond: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 430063D5657; Sat, 28 Feb 2026 17:40:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300432; cv=none; b=CKO2Y+0JGQzdZ7i35cYG/sB5FTkP4KzwDGSA12g5+UjcGY4nZzrEK9teBv6VkpWxqSbdSmuAwbqEb0HFz8lEX+h8xKPFbM/VdzQejW4fgGh/qLy1bmZZkw7MtAF6E/s8uNJ+IdJcfPsG0Ztat33W2yxWnQqy00F/mEq8FYt6BJI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300432; c=relaxed/simple; bh=lEa1RlafBsckoZh6eMRjQETxXFx6+7H+LvTwJMaPMvU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cX/MmhXZwsW8TfZe5YeQ3LL8gxilsSOZPU3tnpP1GYBr/DH02hj4ESCTcljG8v8bvJ27MDIgkvrMQDV/QFjzlatCg88BI0sV/RzDxxmIdH9Ggxva2PFylA/bb4dmBwxKJKHotOG2JIUvc8NzSHib6eT97m3zVSBxkfF02aOB2CA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uGcXcQ1R; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uGcXcQ1R" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A365FC19424; Sat, 28 Feb 2026 17:40:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300432; bh=lEa1RlafBsckoZh6eMRjQETxXFx6+7H+LvTwJMaPMvU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uGcXcQ1Rg5v0SYzEKN95uPnPvyiWQQJHb1mjIPY8M0m36YKXQkfGeUsiU8E6dGkD9 kY2eWE5FUPu4K61ploPpG/XScLPurJUWuEx76Ci7Pc6Rg+8hB2XhI7otyng3Yv2hPO KQidGTENiG/fJPEhqUIfqKj/09Ve48nwiVBn5BKdbj6VVZs6mR8uGO67j2oSuriIOf 1QbVusk5AA8yebNtT130Rjmknd7XrpuWwP/e6MPsFHLoDui1NQHNJyYHCvGyZbnkOq 1JTZnOdQo6ywMiIVyNIgXxdspA4jXWOT3iGKRzN69WLubJ3tkwRRrAnU/g7QTr+oaj vcz1ypwDmg85A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 471/844] Bluetooth: L2CAP: Fix result of L2CAP_ECRED_CONN_RSP when MTU is too short Date: Sat, 28 Feb 2026 12:26:24 -0500 Message-ID: <20260228173244.1509663-472-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit c28d2bff70444a85b3b86aaf241ece9408c7858c ] Test L2CAP/ECFC/BV-26-C expect the response to L2CAP_ECRED_CONN_REQ with and MTU value < L2CAP_ECRED_MIN_MTU (64) to be L2CAP_CR_LE_INVALID_PARAMS rather than L2CAP_CR_LE_UNACCEPT_PARAMS. Also fix not including the correct number of CIDs in the response since the spec requires all CIDs being rejected to be included in the response. Link: https://github.com/bluez/bluez/issues/1868 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credi= t Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/net/bluetooth/l2cap.h | 6 +++--- net/bluetooth/l2cap_core.c | 14 ++++++++------ 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h index 9820ccc379f1c..f08ed93bb6fa3 100644 --- a/include/net/bluetooth/l2cap.h +++ b/include/net/bluetooth/l2cap.h @@ -284,9 +284,9 @@ struct l2cap_conn_rsp { #define L2CAP_CR_LE_BAD_KEY_SIZE 0x0007 #define L2CAP_CR_LE_ENCRYPTION 0x0008 #define L2CAP_CR_LE_INVALID_SCID 0x0009 -#define L2CAP_CR_LE_SCID_IN_USE 0X000A -#define L2CAP_CR_LE_UNACCEPT_PARAMS 0X000B -#define L2CAP_CR_LE_INVALID_PARAMS 0X000C +#define L2CAP_CR_LE_SCID_IN_USE 0x000A +#define L2CAP_CR_LE_UNACCEPT_PARAMS 0x000B +#define L2CAP_CR_LE_INVALID_PARAMS 0x000C =20 /* connect/create channel status */ #define L2CAP_CS_NO_INFO 0x0000 diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index e705b4a171dec..0b236e977d70e 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -5035,13 +5035,15 @@ static inline int l2cap_ecred_conn_req(struct l2cap= _conn *conn, struct l2cap_chan *chan, *pchan; u16 mtu, mps; __le16 psm; - u8 result, len =3D 0; + u8 result, rsp_len =3D 0; int i, num_scid; bool defer =3D false; =20 if (!enable_ecred) return -EINVAL; =20 + memset(pdu, 0, sizeof(*pdu)); + if (cmd_len < sizeof(*req) || (cmd_len - sizeof(*req)) % sizeof(u16)) { result =3D L2CAP_CR_LE_INVALID_PARAMS; goto response; @@ -5050,6 +5052,9 @@ static inline int l2cap_ecred_conn_req(struct l2cap_c= onn *conn, cmd_len -=3D sizeof(*req); num_scid =3D cmd_len / sizeof(u16); =20 + /* Always respond with the same number of scids as in the request */ + rsp_len =3D cmd_len; + if (num_scid > L2CAP_ECRED_MAX_CID) { result =3D L2CAP_CR_LE_INVALID_PARAMS; goto response; @@ -5059,7 +5064,7 @@ static inline int l2cap_ecred_conn_req(struct l2cap_c= onn *conn, mps =3D __le16_to_cpu(req->mps); =20 if (mtu < L2CAP_ECRED_MIN_MTU || mps < L2CAP_ECRED_MIN_MPS) { - result =3D L2CAP_CR_LE_UNACCEPT_PARAMS; + result =3D L2CAP_CR_LE_INVALID_PARAMS; goto response; } =20 @@ -5079,8 +5084,6 @@ static inline int l2cap_ecred_conn_req(struct l2cap_c= onn *conn, =20 BT_DBG("psm 0x%2.2x mtu %u mps %u", __le16_to_cpu(psm), mtu, mps); =20 - memset(pdu, 0, sizeof(*pdu)); - /* Check if we have socket listening on psm */ pchan =3D l2cap_global_chan_by_psm(BT_LISTEN, psm, &conn->hcon->src, &conn->hcon->dst, LE_LINK); @@ -5105,7 +5108,6 @@ static inline int l2cap_ecred_conn_req(struct l2cap_c= onn *conn, BT_DBG("scid[%d] 0x%4.4x", i, scid); =20 pdu->dcid[i] =3D 0x0000; - len +=3D sizeof(*pdu->dcid); =20 /* Check for valid dynamic CID range */ if (scid < L2CAP_CID_DYN_START || scid > L2CAP_CID_LE_DYN_END) { @@ -5172,7 +5174,7 @@ static inline int l2cap_ecred_conn_req(struct l2cap_c= onn *conn, return 0; =20 l2cap_send_cmd(conn, cmd->ident, L2CAP_ECRED_CONN_RSP, - sizeof(*pdu) + len, pdu); + sizeof(*pdu) + rsp_len, pdu); =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 375753D5674; Sat, 28 Feb 2026 17:40:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300433; cv=none; b=d4BElg65mF2oNaVEAaqGnM3LxXQ1DF7OxozlFDhHXtG0PLVj4ouTF8bf3Xep8/FHF1nWcls/Kj5MvGK9/YFDu0YPHi5xG6tgjw7i0Nwj8uSIAZ5h324DQXmFGVOYOdhnDRcimj0o9mIEDjTy9WTfVcl0VxMQ5sRDuIQOylyCzVk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300433; c=relaxed/simple; bh=vFJOB/tj3DORoPczvwwyK/P3t1OiK9PdPbshDbq73c8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HRLAC7gC2VU9zNrAmn09UbjWWH9hs2PGqDUwr4/O/q3KtUDfDj2Gq7DTzSVMpvT1Ai+QFc5fA5LDPsYWajKZazF21KcWSq6+S5qwTaU3zQbeCRrA2pyYrwe2uKKlUJ2SFnGU/2ItCj8MiFjJ3L6GR0DuPgNfwRlfqA1IkEfS5IA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XbBXauBz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XbBXauBz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C49FC116D0; Sat, 28 Feb 2026 17:40:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300433; bh=vFJOB/tj3DORoPczvwwyK/P3t1OiK9PdPbshDbq73c8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XbBXauBzbcBWQoFGwyvhEoJXeRYytMjhj7yXnLx3kBYmNtYNwKyB9GLRTuG7nXwdz 0tokNr8sch7kdWPYnmLG9JDBEpvf5rzJMj3u0OuiTK4yVWJTzEIhU1h+1Uut1OwtYs bMgcwlyhyiqurKxA/8DjTC7AbqNNU/SgiDfNuNQgWZe2ZhhuvJNoyyVV+QLQXBVoSL yupJiESYsUbcIbkCUaozcG7k8UJrW4/4yiSd5+G0mHXvLgWCfDcK0hK2PxoVzcVKX/ heHOkhZhwmvl02jPLAW/8UMp1wzJyZsEeX1iiXgnA3UVdrqymuuHtp7ZOfNf/zwl2B 3tBr06DI2OrhA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jinwang Li , Bartosz Golaszewski , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 472/844] Bluetooth: hci_qca: Cleanup on all setup failures Date: Sat, 28 Feb 2026 12:26:25 -0500 Message-ID: <20260228173244.1509663-473-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jinwang Li [ Upstream commit 5c4e9a8b18457ad28b57069ef0f14661e3192b2e ] The setup process previously combined error handling and retry gating under one condition. As a result, the final failed attempt exited without performing cleanup. Update the failure path to always perform power and port cleanup on setup failure, and reopen the port only when retrying. Fixes: 9e80587aba4c ("Bluetooth: hci_qca: Enhance retry logic in qca_setup") Signed-off-by: Jinwang Li Reviewed-by: Bartosz Golaszewski Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/bluetooth/hci_qca.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index a3c217571c3c4..c0cc04995fc2f 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2045,19 +2045,23 @@ static int qca_setup(struct hci_uart *hu) } =20 out: - if (ret && retries < MAX_INIT_RETRIES) { - bt_dev_warn(hdev, "Retry BT power ON:%d", retries); + if (ret) { qca_power_shutdown(hu); - if (hu->serdev) { - serdev_device_close(hu->serdev); - ret =3D serdev_device_open(hu->serdev); - if (ret) { - bt_dev_err(hdev, "failed to open port"); - return ret; + + if (retries < MAX_INIT_RETRIES) { + bt_dev_warn(hdev, "Retry BT power ON:%d", retries); + if (hu->serdev) { + serdev_device_close(hu->serdev); + ret =3D serdev_device_open(hu->serdev); + if (ret) { + bt_dev_err(hdev, "failed to open port"); + return ret; + } } + retries++; + goto retry; } - retries++; - goto retry; + return ret; } =20 /* Setup bdaddr */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF8853D6CA1; Sat, 28 Feb 2026 17:40:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300434; cv=none; b=cwVyFJBNZ+HG5ZwJBRaecS2kRXlftSzotYZMEIHD0eAsRwqyaU/Xa55tE0h/TGyVZcxgSWdVJs8/XX3jKIGAwp92MK46gjZsXUSdcLovpWYh6zhtEfQZKwbfZ0yq+8kFPJtXzwG35OYuS0C3tQoXWN8j/D3i8N/J8yl0zl7qL6k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300434; c=relaxed/simple; bh=bAekLvKe5cXYjCit2m3nXXMiwpO0zC6TC3rs3T5uT+Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kU16+uqv/EzDYCUiN1d2/OCYyYCZ6IJCAy37GIyl2fHhHXoqeafj/8Gg+rA+udWjyltJ9w8hOwjB/N9fCJoC0yI7M0SHLuEdGcmPv48XNu+ZIudmz4TtsFRM0fRDtauqllSssSLruH3wOE2YQYHJgu7wUw7WGDYHgU2FFIA2k9U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BGQtqvl+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BGQtqvl+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C4EAC2BC87; Sat, 28 Feb 2026 17:40:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300433; bh=bAekLvKe5cXYjCit2m3nXXMiwpO0zC6TC3rs3T5uT+Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BGQtqvl+8X7SF22gnHYtagtq2cD9kO5CLLqFPSnimszG9xe5Bq2vkx3zZyzuhS7Gu TSZrJ++LId+BBSiJf7gNwFyZ+gC42CzBk93J+LypmPJ9AYe6UbwNQVmc6slmwINNqo AInayieQ/mYBoSYd45GNpTAr7tgGRNiELvRSswvCPeH8U9bn0CxqlA+IdHVy0Rl9/T qssA4lxBSQ1PQ1HHpGw5oGnZPaVGBIoto0rkYNUofE/Cffm+2ay4DW8w/k72zOYJ6g Z348ZHVEegKhr/DGy0BiO13pCPG/+gjSmvBpmQMq3aCYqxKUtKK8/KVNpjeOWzu+c1 GJ7knjyEF4ldA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 473/844] Bluetooth: L2CAP: Fix response to L2CAP_ECRED_CONN_REQ Date: Sat, 28 Feb 2026 12:26:26 -0500 Message-ID: <20260228173244.1509663-474-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit 05761c2c2b5bfec85c47f60c903c461e9b56cf87 ] Similar to 03dba9cea72f ("Bluetooth: L2CAP: Fix not responding with L2CAP_CR_LE_ENCRYPTION") the result code L2CAP_CR_LE_ENCRYPTION shall be used when BT_SECURITY_MEDIUM is set since that means security mode 2 which mean it doesn't require authentication which results in qualification test L2CAP/ECFC/BV-32-C failing. Link: https://github.com/bluez/bluez/issues/1871 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credi= t Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/bluetooth/l2cap_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 0b236e977d70e..a5038160675ea 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -5096,7 +5096,8 @@ static inline int l2cap_ecred_conn_req(struct l2cap_c= onn *conn, =20 if (!smp_sufficient_security(conn->hcon, pchan->sec_level, SMP_ALLOW_STK)) { - result =3D L2CAP_CR_LE_AUTHENTICATION; + result =3D pchan->sec_level =3D=3D BT_SECURITY_MEDIUM ? + L2CAP_CR_LE_ENCRYPTION : L2CAP_CR_LE_AUTHENTICATION; goto unlock; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B38333D6CC5; Sat, 28 Feb 2026 17:40:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300434; cv=none; b=LeEa4OpWAW9N5Ty1uyu/5b5j0ebImVg/hi2L8Ou2DYNd+ZkW683rwibtrXKY9RM9ywieKaRbb+gSVWA0xAo1Lva9xHdYk2wjtQ8ozzc6RPpJPrG4uK+Ecn/af6rEPVxMfoZ9Rp9Ezg4oLW+uGYCMDt1P0VNoazjPvDffQpZG/hc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300434; c=relaxed/simple; bh=HdpIbdqWlygfBKQsCat8ydjJKTUIpd8b2jpC7u8VgAA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fu6ILiCvp+waHgMIDUdrdd41Pb+e30zSxOQbtVoZ11X4N8M9BNv01QuBb/l76NKKL+T9REg4Aj/VJYynVnlQs/gjTRI8iY30mVqOieT6mNDcxwBisBItlWRemz0g+vmAh2p33UBSo5JJslnJTmSCAPwTID31ey/7LM3M4xvGjsI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HaWXWqnf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HaWXWqnf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20632C2BC9E; Sat, 28 Feb 2026 17:40:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300434; bh=HdpIbdqWlygfBKQsCat8ydjJKTUIpd8b2jpC7u8VgAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HaWXWqnf8TPQUyHiEtncegslpItFHZ3gcly0Gj/lKHHT+9IuE6PwJwO+Twob+T/vx tMQFz0ht5ukl4dW7zw31wa9qR69LduTEu6e7MCAEgQ9/sHwNxG1tzK3rJmjrilyqjB S0c6XDexvdb/WmP4Vm/XsQbK6e1HgCM8+6Ifc5bzz+Yey6coS2LgQoPrjOWwCW4bYl mmDlsXYhIa3uhJvtloIREpCVNrxs5GJJSF8xop1LN5sIzQUJrzIThUpY/G3WM3BMch xXFnsZ3Yuww5GmNvCwS+75hDjQsZQqVgkQfmiobea735l3wIpxhx2CjLkGPj/lhneI mLk+TfikpdYew== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.19 474/844] Bluetooth: L2CAP: Fix not checking output MTU is acceptable on L2CAP_ECRED_CONN_REQ Date: Sat, 28 Feb 2026 12:26:27 -0500 Message-ID: <20260228173244.1509663-475-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit a8d1d73c81d1e70d2aa49fdaf59d933bb783ffe5 ] Upon receiving L2CAP_ECRED_CONN_REQ the given MTU shall be checked against the suggested MTU of the listening socket as that is required by the likes of PTS L2CAP/ECFC/BV-27-C test which expects L2CAP_CR_LE_UNACCEPT_PARAMS if the MTU is lowers than socket omtu. In order to be able to set chan->omtu the code now allows setting setsockopt(BT_SNDMTU), but it is only allowed when connection has not been stablished since there is no procedure to reconfigure the output MTU. Link: https://github.com/bluez/bluez/issues/1895 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credi= t Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/bluetooth/l2cap_core.c | 8 ++++++++ net/bluetooth/l2cap_sock.c | 15 +++++++++++---- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index a5038160675ea..29af3f63e89ce 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -5101,6 +5101,14 @@ static inline int l2cap_ecred_conn_req(struct l2cap_= conn *conn, goto unlock; } =20 + /* Check if the listening channel has set an output MTU then the + * requested MTU shall be less than or equal to that value. + */ + if (pchan->omtu && mtu < pchan->omtu) { + result =3D L2CAP_CR_LE_UNACCEPT_PARAMS; + goto unlock; + } + result =3D L2CAP_CR_LE_SUCCESS; =20 for (i =3D 0; i < num_scid; i++) { diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c index 9ee189c815d49..66ab2754594d6 100644 --- a/net/bluetooth/l2cap_sock.c +++ b/net/bluetooth/l2cap_sock.c @@ -1029,10 +1029,17 @@ static int l2cap_sock_setsockopt(struct socket *soc= k, int level, int optname, break; } =20 - /* Setting is not supported as it's the remote side that - * decides this. - */ - err =3D -EPERM; + /* Only allow setting output MTU when not connected */ + if (sk->sk_state =3D=3D BT_CONNECTED) { + err =3D -EISCONN; + break; + } + + err =3D copy_safe_from_sockptr(&mtu, sizeof(mtu), optval, optlen); + if (err) + break; + + chan->omtu =3D mtu; break; =20 case BT_RCVMTU: --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90A0A3D5677; Sat, 28 Feb 2026 17:40:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300435; cv=none; b=GAquBvjXKcJCxUg6bk42AeQk3/cHL4sUFshNShcTFlSaABgp7k5kji5BAZSZLZmfPt2cknbTfn1PRjIZoQbX4xkcxq+faBxoJdBfSjuYk5lrF74gzdS3EwtuchkUqFh6hKwisqjP3E4KiYGOhaIjK+bnUt/eM8g0xStkYv7NjJE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300435; c=relaxed/simple; bh=dJMssyz69qshYFj1P0Z+P9H6EwkDVsF3N1ezNEZ4jGY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=can86C15LzUH2oEZWNqezU5C5eO5TLAE0rpX4hyg31lDA2Gm+ayaVstm/IzqulLfOvjBMXjIVQOJfe4GGZA9eNvpnSo2YmEEivuy3xUkJGn2cdnRCwsVdgDN90thTbJ/tG3feUKurb4RM8Qg+WXvDdPgeSjGdpVbibQI8zr6umo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bV/kM9Pt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bV/kM9Pt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9133C19425; Sat, 28 Feb 2026 17:40:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300435; bh=dJMssyz69qshYFj1P0Z+P9H6EwkDVsF3N1ezNEZ4jGY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bV/kM9PtVTa42jNcYGlZA84iAkSnnqiQqdgUYEkAy+4EvexUczTz5xzgYgmKFlccW b8mSgzbZXU7gAv1BCnTKe6Dpoc3skgYF8scUR/iDrSzOQPK54lYRqbfu6+XCMvnQG/ 0erXhwBSr1x0FMiXDjeyH6uYpMvw1qrId+zvQm/WyG+kVVoe07LxY8L6q/YdxXoE3R x6fmpHAVMjAmPx6VVX9H1YTKtfSVD4Tl4L+5X3Y1ygcW1Zd4AbJrtu9hLC0D1ESNgr QpAKDn+CmRQ8lqB6gAOi8U0MgRLaCj4xPrFaxkQqsS/COlCXegfL7b1cuNyTx4OhX4 pbNN8SRvVkyJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Christian Eggers , Sasha Levin Subject: [PATCH 6.19 475/844] Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ Date: Sat, 28 Feb 2026 12:26:28 -0500 Message-ID: <20260228173244.1509663-476-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit 138d7eca445ef37a0333425d269ee59900ca1104 ] This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE. Link: https://lore.kernel.org/linux-bluetooth/5782243.rdbgypaU67@n9w6sw14/ Fixes: 27e2d4c8d28b ("Bluetooth: Add basic LE L2CAP connect request receivi= ng support") Signed-off-by: Luiz Augusto von Dentz Tested-by: Christian Eggers Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/bluetooth/l2cap_core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 29af3f63e89ce..72a4bb1fee46a 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -4900,6 +4900,13 @@ static int l2cap_le_connect_req(struct l2cap_conn *c= onn, goto response_unlock; } =20 + /* Check if Key Size is sufficient for the security level */ + if (!l2cap_check_enc_key_size(conn->hcon, pchan)) { + result =3D L2CAP_CR_LE_BAD_KEY_SIZE; + chan =3D NULL; + goto response_unlock; + } + /* Check for valid dynamic CID range */ if (scid < L2CAP_CID_DYN_START || scid > L2CAP_CID_LE_DYN_END) { result =3D L2CAP_CR_LE_INVALID_SCID; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9ACCE3D74F5; Sat, 28 Feb 2026 17:40:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300436; cv=none; b=oBI7cPJRWFeAqE7sddT1R1SDcjmQAlX+fht5IiQ0v/ppZOQa/CVvqVOrHYCvHju3gml6empDwe147TyZB3+Od81AOaNOz7otAx4ZYkJ48wktlY+MW03gSHRzeM/SEM2kOd+1hIz/L1iLS1NaBVwQCbtD2FyDfcRyajsXjRBU+eI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300436; c=relaxed/simple; bh=48EgMikTl/bu9W9zNPAxWtRIaL/Orh+GgvS+Au/IDV0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jnQL0npnezSQ7J4qzbryxQ1xtQoXfJ/8b9UpYtmPtaBMb5OZm1FR1EhYB3HzPK93XN3kyR6jmqXqnX6R83P0nvFNkiwCSJBURlW769optLbz/N66WfvHju0l9+2B9viw0tP2Gr71Da5mzM9ta3G75CvqahcS7ebm+GRGdkg5zjs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JwtuMui4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JwtuMui4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9164C19425; Sat, 28 Feb 2026 17:40:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300436; bh=48EgMikTl/bu9W9zNPAxWtRIaL/Orh+GgvS+Au/IDV0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JwtuMui4JT3JkeZ8r3tjxwldKAvIV3HqoYPOIaDcMjn7NMGFOhSnXwt8UGwxT63ln 9CKhlwtHQ9Co++O0+/Q2o0Q7pZAI0xGz7FNuZaJSi3cuTDf7Gi4sdJPD522WtLD5c4 SMoJzQmkEA4h3xBf3+Q1mi3tzHj7GH4ytTh1LtVXlaAlUli4UbMZKGiiiDAkW0boCG BJmfL9A70C4oULy7gpO0n8zUgWmzvIImdgDEySrDbqfpyGXE8l9eXklDkvPYaWg77f 5ftYmk6MsiiLZblXd4OxFxw54+dZcDve6a68LDLpSxfVjDZZJLPwDbqGQO9XRc6QId vw9nMxqiQBnnQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Krishna Kumar , Kuniyuki Iwashima , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 476/844] net: do not pass flow_id to set_rps_cpu() Date: Sat, 28 Feb 2026 12:26:29 -0500 Message-ID: <20260228173244.1509663-477-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit 8a8a9fac9efa6423fd74938b940cb7d731780718 ] Blamed commit made the assumption that the RPS table for each receive queue would have the same size, and that it would not change. Compute flow_id in set_rps_cpu(), do not assume we can use the value computed by get_rps_cpu(). Otherwise we risk out-of-bound access and/or crashes. Fixes: 48aa30443e52 ("net: Cache hash and flow_id to avoid recalculation") Signed-off-by: Eric Dumazet Cc: Krishna Kumar Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260220222605.3468081-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/core/dev.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index f5e4040e08399..60a26208cbd87 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4988,8 +4988,7 @@ static bool rps_flow_is_active(struct rps_dev_flow *r= flow, =20 static struct rps_dev_flow * set_rps_cpu(struct net_device *dev, struct sk_buff *skb, - struct rps_dev_flow *rflow, u16 next_cpu, u32 hash, - u32 flow_id) + struct rps_dev_flow *rflow, u16 next_cpu, u32 hash) { if (next_cpu < nr_cpu_ids) { u32 head; @@ -5000,6 +4999,7 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *s= kb, struct rps_dev_flow *tmp_rflow; unsigned int tmp_cpu; u16 rxq_index; + u32 flow_id; int rc; =20 /* Should we steer this flow to a different hardware queue? */ @@ -5015,6 +5015,7 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *s= kb, if (!flow_table) goto out; =20 + flow_id =3D rfs_slot(hash, flow_table); tmp_rflow =3D &flow_table->flows[flow_id]; tmp_cpu =3D READ_ONCE(tmp_rflow->cpu); =20 @@ -5062,7 +5063,6 @@ static int get_rps_cpu(struct net_device *dev, struct= sk_buff *skb, struct rps_dev_flow_table *flow_table; struct rps_map *map; int cpu =3D -1; - u32 flow_id; u32 tcpu; u32 hash; =20 @@ -5109,8 +5109,7 @@ static int get_rps_cpu(struct net_device *dev, struct= sk_buff *skb, /* OK, now we know there is a match, * we can look at the local (per receive queue) flow table */ - flow_id =3D rfs_slot(hash, flow_table); - rflow =3D &flow_table->flows[flow_id]; + rflow =3D &flow_table->flows[rfs_slot(hash, flow_table)]; tcpu =3D rflow->cpu; =20 /* @@ -5129,8 +5128,7 @@ static int get_rps_cpu(struct net_device *dev, struct= sk_buff *skb, ((int)(READ_ONCE(per_cpu(softnet_data, tcpu).input_queue_head) - rflow->last_qtail)) >=3D 0)) { tcpu =3D next_cpu; - rflow =3D set_rps_cpu(dev, skb, rflow, next_cpu, hash, - flow_id); + rflow =3D set_rps_cpu(dev, skb, rflow, next_cpu, hash); } =20 if (tcpu < nr_cpu_ids && cpu_online(tcpu)) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F1673D751D; Sat, 28 Feb 2026 17:40:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300437; cv=none; b=YYKcrrWDUfn8Gyolr1hmyjyq5s2hoY5F0KoX3V0Zab4YQjzZr45w0w2WjAj6tAFohe8cdbSEbGLygYEHqoiumOmBUhE10JutX+BmXbn6T+5TMFFws5JfkRuXTfq0fyvba3SArLPWsG3tHvZIwLr2pOd649Valx7urMZHXKOBFMU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300437; c=relaxed/simple; bh=9Blwvyplt0VKUoH7HlX+1l3YnzTFHwZ8qOvdIEe2KfY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hSbyYyjS3Qd9g4hbMdA9sDCuYtVKcwaXpsZakoUMdo+ClaIZDA8Of55B4H1yWW9PKN4KZY1jK+8rAN2Vd1XIKr51gdwUZwMFGYM/nnWsLgNm60iQRLT6ae3b9hRG+J1Rt6WihdJBFtPKawvOjDBdFRemeiBceAwkuco8MT9XMCI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ENj86LYz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ENj86LYz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0D82C116D0; Sat, 28 Feb 2026 17:40:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300437; bh=9Blwvyplt0VKUoH7HlX+1l3YnzTFHwZ8qOvdIEe2KfY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ENj86LYzy2URA2Te6SFkV+R+NW9AFRM64vSGJbKubeNLKpOGv+Ve3pY2DqqQpS8s9 QPTFTkNj5a8TBXR/+s+JzHXABPqSRCswtsr80+3d1PQWobGXVvy/e63a4e22PG9/r2 GXK1SE+IppOH6SdTcAP2blLy8P4msrptlnrxrGo7EcUmIrGy41tXHSQzbGi0RZmEx6 DdxsB4Wm8usUIXgJcv0vrP61uDEu35T4h2w7uob5h8x9ujrNX0HK/e54eebbRQ7cu+ mxJ88E7SWnyurD5iwUqolj6h8IroUXoKF02H+VDd2fRnJ+w2a3GnXYdguko0u8Yzco FKPxUSkrmSXJQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hyunwoo Kim , Simon Horman , Sabrina Dubroca , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 477/844] tls: Fix race condition in tls_sw_cancel_work_tx() Date: Sat, 28 Feb 2026 12:26:30 -0500 Message-ID: <20260228173244.1509663-478-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hyunwoo Kim [ Upstream commit 7bb09315f93dce6acc54bf59e5a95ba7365c2be4 ] This issue was discovered during a code audit. After cancel_delayed_work_sync() is called from tls_sk_proto_close(), tx_work_handler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the tx_work_handler() worker may dereference a freed TLS object. The following is a simple race scenario: cpu0 cpu1 tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED= , &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work= .work, 0); To prevent this race condition, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync(). Fixes: f87e62d45e51 ("net/tls: remove close callback sock unlock/lock aroun= d TX work flush") Signed-off-by: Hyunwoo Kim Reviewed-by: Simon Horman Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/aZgsFO6nfylfvLE7@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/tls/tls_sw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 9937d4c810f2b..b1fa62de9dab5 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -2533,7 +2533,7 @@ void tls_sw_cancel_work_tx(struct tls_context *tls_ct= x) =20 set_bit(BIT_TX_CLOSING, &ctx->tx_bitmask); set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); - cancel_delayed_work_sync(&ctx->tx_work.work); + disable_delayed_work_sync(&ctx->tx_work.work); } =20 void tls_sw_release_resources_tx(struct sock *sk) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93A4F3D834B; Sat, 28 Feb 2026 17:40:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300438; cv=none; b=V/aLY0290bRXCE1YYjL0U7FLGcz4pK1ydZroI2464lU6+e2z7jp5Ju9InDPTd7UckbzOTa+jqvZbvSmfG8YN/7wWVH22v5l0x9RRZr452Wo2dKJWo+9OHcJNc34OOIXtkpLavCnHarVQnK9WR5RUHdWO9gjq5ozGupVU+6hoyFE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300438; c=relaxed/simple; bh=0TTJkMOME3sDF9qX8M3Nezn4qaRZBmS/veqUDaC1Glw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lrJoAAS4C27SRgj74EPlw4Hl3Ypbj24JsDVcCaVQMrCfpaTzOw8huA7WJt0EU5bqKDD7jWRzQO90OtsjQuz9dhmD1Zj8KuWH9ZwDyBmog08zq2lRXmvPiFwME3x2rO8xh8h8+6taL3o2Y/3SoLKddxvY5tR4SRKAsoy/r8moMf0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V5ISElVL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V5ISElVL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8063C19424; Sat, 28 Feb 2026 17:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300438; bh=0TTJkMOME3sDF9qX8M3Nezn4qaRZBmS/veqUDaC1Glw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V5ISElVLdv6aiUSoOv8Pg6MuF0z8o/nhO8aYkcj6beVC06wYgCyd8W1NFDIS0awoi E4qYX0q5bbcxQUGDTb0IbqBx5EEo5RnGBMZKBX22xkD7i8B3jAFqWfN7mc/IU4UKX6 VT8jCu+aE8bq6rbh3l/3TkXjd9KXcI58s1sp24/Bt0upGX33KOi9i51esTGnbmxxFA 3nnDM+gUsJ8yA4FfWDjCYSPyjLd6DprlH/cryJfOkp5jfLvRm3iMflH7Phkir+Y1un gSL2y/oF09ljep0Q+dVj74Gz7Nn9yYjjQVHzFHC/KS3PMxHxkgCkERYyUf7KtRY4SC r+bxnPh6lP9QQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiayuan Chen , syzbot+52624bdfbf2746d37d70@syzkaller.appspotmail.com, Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 478/844] kcm: fix zero-frag skb in frag_list on partial sendmsg error Date: Sat, 28 Feb 2026 12:26:31 -0500 Message-ID: <20260228173244.1509663-479-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiayuan Chen [ Upstream commit ca220141fa8ebae09765a242076b2b77338106b0 ] Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list. When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb, it allocates a new skb (tskb) and links it into the frag_list before copying data. If the copy subsequently fails (e.g. -EFAULT from user memory), tskb remains in the frag_list with zero fragments: head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+ For SOCK_SEQPACKET with partial data already copied, the error path saves this message via partial_message for later completion. For SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a subsequent zero-length write(fd, NULL, 0) completes the message and queues it to sk_write_queue. kcm_write_msgs() then walks the frag_list and hits: WARN_ON(!skb_shinfo(skb)->nr_frags) TCP has a similar pattern where skbs are enqueued before data copy and cleaned up on failure via tcp_remove_empty_skb(). KCM was missing the equivalent cleanup. Fix this by tracking the predecessor skb (frag_prev) when allocating a new frag_list entry. On error, if the tail skb has zero frags, use frag_prev to unlink and free it in O(1) without walking the singly-linked frag_list. frag_prev is safe to dereference because the entire message chain is only held locally (or in kcm->seq_skb) and is not added to sk_write_queue until MSG_EOR, so the send path cannot free it underneath us. Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log if the condition is somehow hit repeatedly. There are currently no KCM selftests in the kernel tree; a simple reproducer is available at [1]. [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa Reported-by: syzbot+52624bdfbf2746d37d70@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000269a1405a12fdc77@google.com= /T/ Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260219014256.370092-1-jiayuan.chen@linux.d= ev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/kcm/kcmsock.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c index 5dd7e0509a48f..3912e75079f5e 100644 --- a/net/kcm/kcmsock.c +++ b/net/kcm/kcmsock.c @@ -628,7 +628,7 @@ static int kcm_write_msgs(struct kcm_sock *kcm) skb =3D txm->frag_skb; } =20 - if (WARN_ON(!skb_shinfo(skb)->nr_frags) || + if (WARN_ON_ONCE(!skb_shinfo(skb)->nr_frags) || WARN_ON_ONCE(!skb_frag_page(&skb_shinfo(skb)->frags[0]))) { ret =3D -EINVAL; goto out; @@ -749,7 +749,7 @@ static int kcm_sendmsg(struct socket *sock, struct msgh= dr *msg, size_t len) { struct sock *sk =3D sock->sk; struct kcm_sock *kcm =3D kcm_sk(sk); - struct sk_buff *skb =3D NULL, *head =3D NULL; + struct sk_buff *skb =3D NULL, *head =3D NULL, *frag_prev =3D NULL; size_t copy, copied =3D 0; long timeo =3D sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT); int eor =3D (sock->type =3D=3D SOCK_DGRAM) ? @@ -824,6 +824,7 @@ static int kcm_sendmsg(struct socket *sock, struct msgh= dr *msg, size_t len) else skb->next =3D tskb; =20 + frag_prev =3D skb; skb =3D tskb; skb->ip_summed =3D CHECKSUM_UNNECESSARY; continue; @@ -933,6 +934,22 @@ static int kcm_sendmsg(struct socket *sock, struct msg= hdr *msg, size_t len) out_error: kcm_push(kcm); =20 + /* When MAX_SKB_FRAGS was reached, a new skb was allocated and + * linked into the frag_list before data copy. If the copy + * subsequently failed, this skb has zero frags. Remove it from + * the frag_list to prevent kcm_write_msgs from later hitting + * WARN_ON(!skb_shinfo(skb)->nr_frags). + */ + if (frag_prev && !skb_shinfo(skb)->nr_frags) { + if (head =3D=3D frag_prev) + skb_shinfo(head)->frag_list =3D NULL; + else + frag_prev->next =3D NULL; + kfree_skb(skb); + /* Update skb as it may be saved in partial_message via goto */ + skb =3D frag_prev; + } + if (sock->type =3D=3D SOCK_SEQPACKET) { /* Wrote some bytes before encountering an * error, return partial success. --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86BEC3D8366; Sat, 28 Feb 2026 17:40:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300439; cv=none; b=D2nnBjWbU8L1qHeXD8TI+dAoX5JBz6XqUxii8NPVHrE5GdvUrpqE+OZax1sdK8OJsfrfQGwaOhJBnBfYxYp0I4eFU1XPPVDOuWwDqqt0TZh2UksLLf1ZOoZntDdoR82D0fB6TzQa3sOW6V/3i9vDWgNaVuqi5dgjyRjf4F3vXJs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300439; c=relaxed/simple; bh=uOU7PEpDm7z0hH/MQwjULsqqsKpWCC8N/AVwo0iYu4c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NZis32+0whALtuElQxn8WBy+FIeFFCuScIsq0hAwi6Dqnv/n8nsSiLjyoLRIUJV0SzDTckJvRHQcGLy9XU2y0vNr7C8NrQJUdNBbGKCK1wvUfJ2MdqKoyJqTGkYQf1TxkmXn2TswRAQe/rqD0e5hOTb8IglXp8R/5pblLPsz+ho= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FgFMTK0N; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FgFMTK0N" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC4CCC2BC87; Sat, 28 Feb 2026 17:40:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300439; bh=uOU7PEpDm7z0hH/MQwjULsqqsKpWCC8N/AVwo0iYu4c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FgFMTK0NUfypXVWU/6LHU9+IsDtUJx4MMzCLwANAmRhH48+E6Z7Vo/Q0nOHq5Ol+1 gG1Q+0A25dySavd+l1jjYXT9UMCWhUiD+KziP7dsB81xJgTqezf6SIrywBgaFKBAiz Ls8ObNvKHWZ/DTqOCIRwPGAT1/jO1kN0fmbKE+MvgQVd02kvTzxPaIziXPFybKV/EQ 6HamNuta4vuK5itOGXgU8IMGySV/IM2cyBWQ+cdT6jh9ib9LS/tuFnFesWEhVYpE/J BV+5db2Qt4OKcQ27w0dUKbHxeeccyoNf53YKstz0r+Ti3hk2/Qf4iEplyfD46C010n lKkZfSvViPY7g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ivan Vecera , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 479/844] dpll: zl3073x: fix REF_PHASE_OFFSET_COMP register width for some chip IDs Date: Sat, 28 Feb 2026 12:26:32 -0500 Message-ID: <20260228173244.1509663-480-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ivan Vecera [ Upstream commit 4cfe066a82cdf9e83e48b16000f55280efc98325 ] The REF_PHASE_OFFSET_COMP register is 48-bit wide on most zl3073x chip variants, but only 32-bit wide on chip IDs 0x0E30, 0x0E93..0x0E97 and 0x1F60. The driver unconditionally uses 48-bit read/write operations, which on 32-bit variants causes reading 2 bytes past the register boundary (corrupting the value) and writing 2 bytes into the adjacent register. Fix this by storing the chip ID in the device structure during probe and adding a helper to detect the affected variants. Use the correct register width for read/write operations and the matching sign extension bit (31 vs 47) when interpreting the phase compensation value. Fixes: 6287262f761e ("dpll: zl3073x: Add support to adjust phase") Signed-off-by: Ivan Vecera Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260220155755.448185-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/dpll/zl3073x/core.c | 1 + drivers/dpll/zl3073x/core.h | 28 ++++++++++++++++++++++++++++ drivers/dpll/zl3073x/dpll.c | 7 +++++-- drivers/dpll/zl3073x/ref.c | 25 ++++++++++++++++++++----- drivers/dpll/zl3073x/regs.h | 1 + 5 files changed, 55 insertions(+), 7 deletions(-) diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c index 383e2397dd033..b20d4f24c0e94 100644 --- a/drivers/dpll/zl3073x/core.c +++ b/drivers/dpll/zl3073x/core.c @@ -1023,6 +1023,7 @@ int zl3073x_dev_probe(struct zl3073x_dev *zldev, "Unknown or non-match chip ID: 0x%0x\n", id); } + zldev->chip_id =3D id; =20 /* Read revision, firmware version and custom config version */ rc =3D zl3073x_read_u16(zldev, ZL_REG_REVISION, &revision); diff --git a/drivers/dpll/zl3073x/core.h b/drivers/dpll/zl3073x/core.h index 09bca2d0926d5..f6a792557ccd6 100644 --- a/drivers/dpll/zl3073x/core.h +++ b/drivers/dpll/zl3073x/core.h @@ -35,6 +35,7 @@ struct zl3073x_dpll; * @dev: pointer to device * @regmap: regmap to access device registers * @multiop_lock: to serialize multiple register operations + * @chip_id: chip ID read from hardware * @ref: array of input references' invariants * @out: array of outs' invariants * @synth: array of synths' invariants @@ -48,6 +49,7 @@ struct zl3073x_dev { struct device *dev; struct regmap *regmap; struct mutex multiop_lock; + u16 chip_id; =20 /* Invariants */ struct zl3073x_ref ref[ZL3073X_NUM_REFS]; @@ -144,6 +146,32 @@ int zl3073x_write_hwreg_seq(struct zl3073x_dev *zldev, =20 int zl3073x_ref_phase_offsets_update(struct zl3073x_dev *zldev, int channe= l); =20 +/** + * zl3073x_dev_is_ref_phase_comp_32bit - check ref phase comp register size + * @zldev: pointer to zl3073x device + * + * Some chip IDs have a 32-bit wide ref_phase_offset_comp register instead + * of the default 48-bit. + * + * Return: true if the register is 32-bit, false if 48-bit + */ +static inline bool +zl3073x_dev_is_ref_phase_comp_32bit(struct zl3073x_dev *zldev) +{ + switch (zldev->chip_id) { + case 0x0E30: + case 0x0E93: + case 0x0E94: + case 0x0E95: + case 0x0E96: + case 0x0E97: + case 0x1F60: + return true; + default: + return false; + } +} + static inline bool zl3073x_is_n_pin(u8 id) { diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c index a8001c9760382..d7194418d1568 100644 --- a/drivers/dpll/zl3073x/dpll.c +++ b/drivers/dpll/zl3073x/dpll.c @@ -459,8 +459,11 @@ zl3073x_dpll_input_pin_phase_adjust_get(const struct d= pll_pin *dpll_pin, ref_id =3D zl3073x_input_pin_ref_get(pin->id); ref =3D zl3073x_ref_state_get(zldev, ref_id); =20 - /* Perform sign extension for 48bit signed value */ - phase_comp =3D sign_extend64(ref->phase_comp, 47); + /* Perform sign extension based on register width */ + if (zl3073x_dev_is_ref_phase_comp_32bit(zldev)) + phase_comp =3D sign_extend64(ref->phase_comp, 31); + else + phase_comp =3D sign_extend64(ref->phase_comp, 47); =20 /* Reverse two's complement negation applied during set and convert * to 32bit signed int diff --git a/drivers/dpll/zl3073x/ref.c b/drivers/dpll/zl3073x/ref.c index aa2de13effa87..6b65e61039999 100644 --- a/drivers/dpll/zl3073x/ref.c +++ b/drivers/dpll/zl3073x/ref.c @@ -121,8 +121,16 @@ int zl3073x_ref_state_fetch(struct zl3073x_dev *zldev,= u8 index) return rc; =20 /* Read phase compensation register */ - rc =3D zl3073x_read_u48(zldev, ZL_REG_REF_PHASE_OFFSET_COMP, - &ref->phase_comp); + if (zl3073x_dev_is_ref_phase_comp_32bit(zldev)) { + u32 val; + + rc =3D zl3073x_read_u32(zldev, ZL_REG_REF_PHASE_OFFSET_COMP_32, + &val); + ref->phase_comp =3D val; + } else { + rc =3D zl3073x_read_u48(zldev, ZL_REG_REF_PHASE_OFFSET_COMP, + &ref->phase_comp); + } if (rc) return rc; =20 @@ -179,9 +187,16 @@ int zl3073x_ref_state_set(struct zl3073x_dev *zldev, u= 8 index, if (!rc && dref->sync_ctrl !=3D ref->sync_ctrl) rc =3D zl3073x_write_u8(zldev, ZL_REG_REF_SYNC_CTRL, ref->sync_ctrl); - if (!rc && dref->phase_comp !=3D ref->phase_comp) - rc =3D zl3073x_write_u48(zldev, ZL_REG_REF_PHASE_OFFSET_COMP, - ref->phase_comp); + if (!rc && dref->phase_comp !=3D ref->phase_comp) { + if (zl3073x_dev_is_ref_phase_comp_32bit(zldev)) + rc =3D zl3073x_write_u32(zldev, + ZL_REG_REF_PHASE_OFFSET_COMP_32, + ref->phase_comp); + else + rc =3D zl3073x_write_u48(zldev, + ZL_REG_REF_PHASE_OFFSET_COMP, + ref->phase_comp); + } if (rc) return rc; =20 diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h index d837bee72b178..5573d7188406b 100644 --- a/drivers/dpll/zl3073x/regs.h +++ b/drivers/dpll/zl3073x/regs.h @@ -194,6 +194,7 @@ #define ZL_REF_CONFIG_DIFF_EN BIT(2) =20 #define ZL_REG_REF_PHASE_OFFSET_COMP ZL_REG(10, 0x28, 6) +#define ZL_REG_REF_PHASE_OFFSET_COMP_32 ZL_REG(10, 0x28, 4) =20 #define ZL_REG_REF_SYNC_CTRL ZL_REG(10, 0x2e, 1) #define ZL_REF_SYNC_CTRL_MODE GENMASK(2, 0) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78F143D8358; Sat, 28 Feb 2026 17:40:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300440; cv=none; b=juTXX/qWerGqyPKBj+YVqwAVrWQ7Bo1z1aVkgoVc8JHX9u5NhQUaanT080Wh6V86yiMNaIONsZalnHtFRlVeC125srq1IgeFw3BFCvzH6Q/wlxb2gg1Lp+9AMh2MQhyJPbP0EXL+01mjU60BfKCreEoUrkn/erszSxppHbTjg4M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300440; c=relaxed/simple; bh=KC4k2oJe8InnAy4iSiJf0CgxbA7L6xle0i7Jgq9Ivr4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iQvIEkpeO7mne1yzogQxrLTHe/14v8f0jkBeMTO9V7Au1GXXZxthDUVhICu4/2Gl0fa0bu6VAxBTqOvlcT2GzK97449pEcM7AKb0CUyH8iFBEBgGu1pvfRaz4HbqTcTS8iA+5vSpCStnjR48bSzdV+Sv4fFM+UM2r4sVDlESDFI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G/WjtO0O; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="G/WjtO0O" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD111C19423; Sat, 28 Feb 2026 17:40:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300440; bh=KC4k2oJe8InnAy4iSiJf0CgxbA7L6xle0i7Jgq9Ivr4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G/WjtO0OKq7etolDBucE75ghglawTgd7uxM9/7y71a9UCcFnyxBfbiaaXY6kqg8v5 juDwVofrfFR+1IxeXEsWd8nsT1ogVzoImhZizybThNskc+8Iw3uMa5AYwM4C/s+y2c ywByWkGvcOYNLanlX3Z45vr+yN5DgafF0tkZFvQGLSGXovYYPOaMwEcs/kWhG3+eYi eIR0dcNUXA/phnYkM6I1E4rPGgF38ehPxfobAABQXyqBvwUCjHLO4lx9uPSWJrCESU blXxFminlWKIy40IEYyyobinGJ4hhVYlRuq7D6PHxFZ5O+bkZejJK/o/gHOedSgRgx JCKWWrH4H9XQw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tung Nguyen , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 480/844] tipc: fix duplicate publication key in tipc_service_insert_publ() Date: Sat, 28 Feb 2026 12:26:33 -0500 Message-ID: <20260228173244.1509663-481-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tung Nguyen [ Upstream commit 3aa677625c8fad39989496c51bcff3872c1f16f1 ] TIPC uses named table to store TIPC services represented by type and instance. Each time an application calls TIPC API bind() to bind a type/instance to a socket, an entry is created and inserted into the named table. It looks like this: named table: key1, entry1 (type, instance ...) key2, entry2 (type, instance ...) In the above table, each entry represents a route for sending data from one socket to the other. For all publications originated from the same node, the key is UNIQUE to identify each entry. It is calculated by this formula: key =3D socket portid + number of bindings + 1 (1) where: - socket portid: unique and calculated by using linux kernel function get_random_u32_below(). So, the value is randomized. - number of bindings: the number of times a type/instance pair is bound to a socket. This number is linearly increased, starting from 0. While the socket portid is unique and randomized by linux kernel, the linear increment of "number of bindings" in formula (1) makes "key" not unique anymore. For example: - Socket 1 is created with its associated port number 20062001. Type 1000, instance 1 is bound to socket 1: key1: 20062001 + 0 + 1 =3D 20062002 Then, bind() is called a second time on Socket 1 to by the same type 1000, instance 1: key2: 20062001 + 1 + 1 =3D 20062003 Named table: key1 (20062002), entry1 (1000, 1 ...) key2 (20062003), entry2 (1000, 1 ...) - Socket 2 is created with its associated port number 20062002. Type 1000, instance 1 is bound to socket 2: key3: 20062002 + 0 + 1 =3D 20062003 TIPC looks up the named table and finds out that key2 with the same value already exists and rejects the insertion into the named table. This leads to failure of bind() call from application on Socket 2 with error message EINVAL "Invalid argument". This commit fixes this issue by adding more port id checking to make sure that the key is unique to publications originated from the same port id and node. Fixes: 218527fe27ad ("tipc: replace name table service range array with rb = tree") Signed-off-by: Tung Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260220050541.237962-1-tung.quang.nguyen@es= t.tech Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/tipc/name_table.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c index e74940eab3a47..7f42fb6a8481f 100644 --- a/net/tipc/name_table.c +++ b/net/tipc/name_table.c @@ -348,7 +348,8 @@ static bool tipc_service_insert_publ(struct net *net, =20 /* Return if the publication already exists */ list_for_each_entry(_p, &sr->all_publ, all_publ) { - if (_p->key =3D=3D key && (!_p->sk.node || _p->sk.node =3D=3D node)) { + if (_p->key =3D=3D key && _p->sk.ref =3D=3D p->sk.ref && + (!_p->sk.node || _p->sk.node =3D=3D node)) { pr_debug("Failed to bind duplicate %u,%u,%u/%u:%u/%u\n", p->sr.type, p->sr.lower, p->sr.upper, node, p->sk.ref, key); @@ -388,7 +389,8 @@ static struct publication *tipc_service_remove_publ(str= uct service_range *r, u32 node =3D sk->node; =20 list_for_each_entry(p, &r->all_publ, all_publ) { - if (p->key !=3D key || (node && node !=3D p->sk.node)) + if (p->key !=3D key || p->sk.ref !=3D sk->ref || + (node && node !=3D p->sk.node)) continue; list_del(&p->all_publ); list_del(&p->local_publ); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6740E3D930F; Sat, 28 Feb 2026 17:40:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300441; cv=none; b=Ex1yYQZZ5o6Cf5lhmSuoO6nr9heJHQcf+kk8dtCQGL/9jvzS9HXXDZ08NEkX2Y7JfxBMdowalWbWidVm79YDae+JxKbzFwYr0S+fq8JMJ3mjzYKvyuTZUkyuGJLYdv5DW6UXVQrwg4bgpRIEdrF5XJTpUM6xJ/MJO7F5DHSBbZY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300441; c=relaxed/simple; bh=WFkc/BLEq/oAc3zdv4OmyDaimeBgO5B1197yn9rFeYw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NXaKs50Ea6Ehl/9s2M4cehS+Wlf62y1hxQXKCNSkori03kwjnq0mkV/4gaYqCEV2cFUewzcDOrxBFjVymH+jRN7+yY8HN/A7hd3GC6mbsbeD9w3rnNmO62nuHflGAhZnj6ZZA+LfDPRw1osBqynm2pLJXuLTgWvRDJc0iUAsEf4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CZ/vE0MX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CZ/vE0MX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D856C116D0; Sat, 28 Feb 2026 17:40:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300441; bh=WFkc/BLEq/oAc3zdv4OmyDaimeBgO5B1197yn9rFeYw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CZ/vE0MXe1jXaghqyayjqRX1+kyxrsYRRvXTVaHZsCCX6fiMX8xvh1QS5+3QQGATm zttN/Vcbryxc+a5V+jtz8BxIRqCTboXAzGfksllc2+CTwKIBUIQITOmZ5ksZyu7UvW HQFGdBZHU3TotMKgSyzl5SRFtUWu5J2/U46vuhpZg59oC6+CkSzvkk2c8tX3V0TFCT 4tyPMppd8QrYiF30esHl6HSlEeDKa4Q2/OkWe12lJdFs74jmX06KdovU4Xn4SlWyio 4MCKDPT0qgjQCqaOvW4tekYH6yTKdYIufVusEKnVVCbX5jPzwRKIRAmnB2vJqpCbhj 7yskXP45OQBqQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiri Pirko , syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com, Leon Romanovsky , Sasha Levin Subject: [PATCH 6.19 481/844] RDMA/core: Fix stale RoCE GIDs during netdev events at registration Date: Sat, 28 Feb 2026 12:26:34 -0500 Message-ID: <20260228173244.1509663-482-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Jiri Pirko [ Upstream commit 9af0feae8016ba58ad7ff784a903404986b395b1 ] RoCE GID entries become stale when netdev properties change during the IB device registration window. This is reproducible with a udev rule that sets a MAC address when a VF netdev appears: ACTION=3D=3D"add", SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"eth4", \ RUN+=3D"/sbin/ip link set eth4 address 88:22:33:44:55:66" After VF creation, show_gids displays GIDs derived from the original random MAC rather than the configured one. The root cause is a race between netdev event processing and device registration: CPU 0 (driver) CPU 1 (udev/workqueue) =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 = =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 ib_register_device() ib_cache_setup_one() gid_table_setup_one() _gid_table_setup_one() =E2=86=90 GID table allocated rdma_roce_rescan_device() =E2=86=90 GIDs populated with OLD MAC ip link set eth4 addr NEW_MAC NETDEV_CHANGEADDR queued netdevice_event_work_handler() ib_enum_all_roce_netdevs() =E2=86=90 Iterates DEVICE_REGISTERED =E2=86=90 Device NOT marked yet, SK= IP! enable_device_and_get() xa_set_mark(DEVICE_REGISTERED) =E2=86=90 Too late, event was lost The netdev event handler uses ib_enum_all_roce_netdevs() which only iterates devices marked DEVICE_REGISTERED. However, this mark is set late in the registration process, after the GID cache is already populated. Events arriving in this window are silently dropped. Fix this by introducing a new xarray mark DEVICE_GID_UPDATES that is set immediately after the GID table is allocated and initialized. Use the new mark in ib_enum_all_roce_netdevs() function to iterate devices instead of DEVICE_REGISTERED. This is safe because: - After _gid_table_setup_one(), all required structures exist (port_data, immutable, cache.gid) - The GID table mutex serializes concurrent access between the initial rescan and event handlers - Event handlers correctly update stale GIDs even when racing with rescan - The mark is cleared in ib_cache_cleanup_one() before teardown This also fixes similar races for IP address events (inetaddr_event, inet6addr_event) which use the same enumeration path. Fixes: 0df91bb67334 ("RDMA/devices: Use xarray to store the client_data") Signed-off-by: Jiri Pirko Link: https://patch.msgid.link/20260127093839.126291-1-jiri@resnulli.us Reported-by: syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D881d65229ca4f9ae8c84 Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/infiniband/core/cache.c | 13 +++++++++++ drivers/infiniband/core/core_priv.h | 3 +++ drivers/infiniband/core/device.c | 34 ++++++++++++++++++++++++++++- 3 files changed, 49 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/core/cache.c b/drivers/infiniband/core/cach= e.c index 0fc1c5bce2f0d..78bc7d83edc65 100644 --- a/drivers/infiniband/core/cache.c +++ b/drivers/infiniband/core/cache.c @@ -927,6 +927,13 @@ static int gid_table_setup_one(struct ib_device *ib_de= v) if (err) return err; =20 + /* + * Mark the device as ready for GID cache updates. This allows netdev + * event handlers to update the GID cache even before the device is + * fully registered. + */ + ib_device_enable_gid_updates(ib_dev); + rdma_roce_rescan_device(ib_dev); =20 return err; @@ -1639,6 +1646,12 @@ void ib_cache_release_one(struct ib_device *device) =20 void ib_cache_cleanup_one(struct ib_device *device) { + /* + * Clear the GID updates mark first to prevent event handlers from + * accessing the device while it's being torn down. + */ + ib_device_disable_gid_updates(device); + /* The cleanup function waits for all in-progress workqueue * elements and cleans up the GID cache. This function should be * called after the device was removed from the devices list and diff --git a/drivers/infiniband/core/core_priv.h b/drivers/infiniband/core/= core_priv.h index 05102769a918a..a2c36666e6fcb 100644 --- a/drivers/infiniband/core/core_priv.h +++ b/drivers/infiniband/core/core_priv.h @@ -100,6 +100,9 @@ void ib_enum_all_roce_netdevs(roce_netdev_filter filter, roce_netdev_callback cb, void *cookie); =20 +void ib_device_enable_gid_updates(struct ib_device *device); +void ib_device_disable_gid_updates(struct ib_device *device); + typedef int (*nldev_callback)(struct ib_device *device, struct sk_buff *skb, struct netlink_callback *cb, diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/dev= ice.c index 1174ab7da6295..87eaefd3794bb 100644 --- a/drivers/infiniband/core/device.c +++ b/drivers/infiniband/core/device.c @@ -93,6 +93,7 @@ static struct workqueue_struct *ib_unreg_wq; static DEFINE_XARRAY_FLAGS(devices, XA_FLAGS_ALLOC); static DECLARE_RWSEM(devices_rwsem); #define DEVICE_REGISTERED XA_MARK_1 +#define DEVICE_GID_UPDATES XA_MARK_2 =20 static u32 highest_client_id; #define CLIENT_REGISTERED XA_MARK_1 @@ -2441,11 +2442,42 @@ void ib_enum_all_roce_netdevs(roce_netdev_filter fi= lter, unsigned long index; =20 down_read(&devices_rwsem); - xa_for_each_marked (&devices, index, dev, DEVICE_REGISTERED) + xa_for_each_marked(&devices, index, dev, DEVICE_GID_UPDATES) ib_enum_roce_netdev(dev, filter, filter_cookie, cb, cookie); up_read(&devices_rwsem); } =20 +/** + * ib_device_enable_gid_updates - Mark device as ready for GID cache updat= es + * @device: Device to mark + * + * Called after GID table is allocated and initialized. After this mark is= set, + * netdevice event handlers can update the device's GID cache. This allows + * events that arrive during device registration to be processed, avoiding + * stale GID entries when netdev properties change during the device + * registration process. + */ +void ib_device_enable_gid_updates(struct ib_device *device) +{ + down_write(&devices_rwsem); + xa_set_mark(&devices, device->index, DEVICE_GID_UPDATES); + up_write(&devices_rwsem); +} + +/** + * ib_device_disable_gid_updates - Clear the GID updates mark + * @device: Device to unmark + * + * Called before GID table cleanup to prevent event handlers from accessing + * the device while it's being torn down. + */ +void ib_device_disable_gid_updates(struct ib_device *device) +{ + down_write(&devices_rwsem); + xa_clear_mark(&devices, device->index, DEVICE_GID_UPDATES); + up_write(&devices_rwsem); +} + /* * ib_enum_all_devs - enumerate all ib_devices * @cb: Callback to call for each found ib_device --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B886F3D9333; Sat, 28 Feb 2026 17:40:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300442; cv=none; b=nWxzLx4Xy9/RpXdnPisaOl7zcNEaOF4x/NRVeBAOaTbeRHLDIglR1VEEmm5HqnE5ua6hJlMnfarx5tz6+KoqSshyXo4qOPAv11Y8dZwph2kjPftgFl302Zchq/+2fmQ9UhddB9VtdFBnr1NfqzF4xdgSyHdrTCptZZgxq2GhMnU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300442; c=relaxed/simple; bh=bsvXoGUNCJ3MfDXSFJNmUx/E3P2uYm7IiUQTKcKUV2M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YBFNOetDEaC2adIiXjIPbLWysKbkDoQ9We1npDeJtz9a6yx2llI6HPGB1GtIucQXGemkG5wg1cJVTulJ2liNpTc+4v/4zqOQ+4iRR7trhNPZ5usY+df9kg6+xAhZxk9KtS0ezJkVF2cPCn/gsTqIHhVGSTg0bpz83XUQM0MGzMI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=diJBqdm6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="diJBqdm6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92B46C19425; Sat, 28 Feb 2026 17:40:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300442; bh=bsvXoGUNCJ3MfDXSFJNmUx/E3P2uYm7IiUQTKcKUV2M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=diJBqdm6u1Fl3jR8zyV8xS9G+kqBSCxIh5DlpC9mYYj3DyJw/Y4Bs/E48L8B3uLgh pl9nYeBgl7rEEXMjkf/YjZRXWE0uY8+ji3d9vKpF+zIkgw7vukEzqJMVYs+S9HM4Ox /QjzX4nxqgKeGxwGLHfqsQWSi/hGtWlXk2rjSqtWbYU4OOyWdHHFkTkNw/CpBuzSI7 8Aj0cZFDxESrVD7bJ54uOdlPKjrQjqUP6ciIA82nKIFBIXtlMFS3cFB0gh18t/ba90 OrYutnIyDardIfQMy7AgKBvJ5/E0BVR75SEWHeXuPQED7Lbe3RihMBKHjmjOPBV/gu 2VbpZSIoYxwdA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Siva Reddy Kallam , Simon Horman , kernel test robot , Dan Carpenter , Leon Romanovsky , Sasha Levin Subject: [PATCH 6.19 482/844] RDMA/bng_re: Remove unnessary validity checks Date: Sat, 28 Feb 2026 12:26:35 -0500 Message-ID: <20260228173244.1509663-483-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Siva Reddy Kallam [ Upstream commit 7a23af417d9dd57b4382356b2e7442e5d2bf5bea ] Fix below smatch warning: drivers/infiniband/hw/bng_re/bng_dev.c:113 bng_re_net_ring_free() warn: variable dereferenced before check 'rdev' (see line 107) current driver has unnessary validity checks. So, removing these unnessary validity checks. Fixes: 4f830cd8d7fe ("RDMA/bng_re: Add infrastructure for enabling Firmware= channel") Fixes: 745065770c2d ("RDMA/bng_re: Register and get the resources from bnge= driver") Fixes: 04e031ff6e60 ("RDMA/bng_re: Initialize the Firmware and Hardware") Fixes: d0da769c19d0 ("RDMA/bng_re: Add Auxiliary interface") Reported-by: Simon Horman Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202601010413.sWadrQel-lkp@intel.com/ Signed-off-by: Siva Reddy Kallam Link: https://patch.msgid.link/20260218091246.1764808-2-siva.kallam@broadco= m.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/infiniband/hw/bng_re/bng_dev.c | 27 ++++---------------------- 1 file changed, 4 insertions(+), 23 deletions(-) diff --git a/drivers/infiniband/hw/bng_re/bng_dev.c b/drivers/infiniband/hw= /bng_re/bng_dev.c index d8f8d7f7075f0..0678aaecb3b5a 100644 --- a/drivers/infiniband/hw/bng_re/bng_dev.c +++ b/drivers/infiniband/hw/bng_re/bng_dev.c @@ -54,9 +54,6 @@ static void bng_re_destroy_chip_ctx(struct bng_re_dev *rd= ev) { struct bng_re_chip_ctx *chip_ctx; =20 - if (!rdev->chip_ctx) - return; - kfree(rdev->dev_attr); rdev->dev_attr =3D NULL; =20 @@ -124,12 +121,6 @@ static int bng_re_net_ring_free(struct bng_re_dev *rde= v, struct bnge_fw_msg fw_msg =3D {}; int rc =3D -EINVAL; =20 - if (!rdev) - return rc; - - if (!aux_dev) - return rc; - bng_re_init_hwrm_hdr((void *)&req, HWRM_RING_FREE); req.ring_type =3D type; req.ring_id =3D cpu_to_le16(fw_ring_id); @@ -150,10 +141,7 @@ static int bng_re_net_ring_alloc(struct bng_re_dev *rd= ev, struct hwrm_ring_alloc_input req =3D {}; struct hwrm_ring_alloc_output resp; struct bnge_fw_msg fw_msg =3D {}; - int rc =3D -EINVAL; - - if (!aux_dev) - return rc; + int rc; =20 bng_re_init_hwrm_hdr((void *)&req, HWRM_RING_ALLOC); req.enables =3D 0; @@ -184,10 +172,7 @@ static int bng_re_stats_ctx_free(struct bng_re_dev *rd= ev) struct hwrm_stat_ctx_free_input req =3D {}; struct hwrm_stat_ctx_free_output resp =3D {}; struct bnge_fw_msg fw_msg =3D {}; - int rc =3D -EINVAL; - - if (!aux_dev) - return rc; + int rc; =20 bng_re_init_hwrm_hdr((void *)&req, HWRM_STAT_CTX_FREE); req.stat_ctx_id =3D cpu_to_le32(rdev->stats_ctx.fw_id); @@ -208,13 +193,10 @@ static int bng_re_stats_ctx_alloc(struct bng_re_dev *= rdev) struct hwrm_stat_ctx_alloc_output resp =3D {}; struct hwrm_stat_ctx_alloc_input req =3D {}; struct bnge_fw_msg fw_msg =3D {}; - int rc =3D -EINVAL; + int rc; =20 stats->fw_id =3D BNGE_INVALID_STATS_CTX_ID; =20 - if (!aux_dev) - return rc; - bng_re_init_hwrm_hdr((void *)&req, HWRM_STAT_CTX_ALLOC); req.update_period_ms =3D cpu_to_le32(1000); req.stats_dma_addr =3D cpu_to_le64(stats->dma_map); @@ -486,8 +468,7 @@ static void bng_re_remove(struct auxiliary_device *adev) =20 rdev =3D dev_info->rdev; =20 - if (rdev) - bng_re_remove_device(rdev, adev); + bng_re_remove_device(rdev, adev); kfree(dev_info); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B251F481FDF; Sat, 28 Feb 2026 17:40:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300443; cv=none; b=fJGfRI4AHGo+ycA4qGAp/NU/vSU/tqOa5aJCoz9UoOkiSdaribIDJc3jmCZWzWH+Lp4Ak8sQFaMHcJ2o22qC6VY7zrfKHzj1CVwQ5ACm1MNi5U/DDgcqT0fgXDvTDTWDInLW88JOrS13QfsEPh9BoFJ3cxF7doJ5rfOQtXtVg4k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300443; c=relaxed/simple; bh=ZKLOfgt7DuMD+hChXCv/rI0XkF20k9wMc4tB1RBafQc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P1utqBmLYFWb1TmygltlXOLNkVLjlhz7HM5y7N0y9RqTarCSVLRIvSVvqlYjdrf6wxSBj5PP1sd19EkpYx7RNzzCqUwVsrxwpyE5M8CmZeFDU3Jy5kr+/kY+2s5uoIdgqbeM9nKZQq2tHaagUiuIwNGjpd8U55LX8AnRGhljD+8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a+u3HTyi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a+u3HTyi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6BB6C116D0; Sat, 28 Feb 2026 17:40:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300443; bh=ZKLOfgt7DuMD+hChXCv/rI0XkF20k9wMc4tB1RBafQc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a+u3HTyi+OVgaWcipVOxOXsyWSINnRpRf5mBfsJkVgeyEQPJA8AW0DGiGUma0Xusk Rhu+Omm7b4Ebwii+QWe2TF+5aXxJw52ODTdV76tnhFrIMMZLKNzYMcJK8V6U+7plnH PizewESNE/2VZZQAcbDNJ0s9KVv89wYZjJBq23I9d+pCDv5vjYi2r5RfAM5JoWwQiS 9YBg7Ve3tfs2lcoggq46SAGb4cJp/z868EabyjsdO5T71x+8JzKRP27/qwMCKKKWzn CwiE+NBATsftvUmPBJeBjZkUagzM2MIf+neEJzLJcqmjlHbleyMDuahnMaoUfaU1kO LESH1j829X4Mw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Siva Reddy Kallam , Simon Horman , kernel test robot , Dan Carpenter , Leon Romanovsky , Sasha Levin Subject: [PATCH 6.19 483/844] RDMA/bng_re: Unwind bng_re_dev_init properly Date: Sat, 28 Feb 2026 12:26:36 -0500 Message-ID: <20260228173244.1509663-484-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Siva Reddy Kallam [ Upstream commit 3d2e5d12a2eef0ca8a629a422aa593673235c77c ] Fix below smatch warning: drivers/infiniband/hw/bng_re/bng_dev.c:270 bng_re_dev_init() warn: missing unwind goto? Current bng_re_dev_init function is not having clear unwinding code. So, added proper unwinding with ladder. Fixes: 4f830cd8d7fe ("RDMA/bng_re: Add infrastructure for enabling Firmware= channel") Reported-by: Simon Horman Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202601010413.sWadrQel-lkp@intel.com/ Signed-off-by: Siva Reddy Kallam Link: https://patch.msgid.link/20260218091246.1764808-3-siva.kallam@broadco= m.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/infiniband/hw/bng_re/bng_dev.c | 29 +++++++++++++------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/drivers/infiniband/hw/bng_re/bng_dev.c b/drivers/infiniband/hw= /bng_re/bng_dev.c index 0678aaecb3b5a..fd0a4fe274ca6 100644 --- a/drivers/infiniband/hw/bng_re/bng_dev.c +++ b/drivers/infiniband/hw/bng_re/bng_dev.c @@ -285,7 +285,7 @@ static int bng_re_dev_init(struct bng_re_dev *rdev) if (rc) { ibdev_err(&rdev->ibdev, "Failed to register with netedev: %#x\n", rc); - return -EINVAL; + goto reg_netdev_fail; } =20 set_bit(BNG_RE_FLAG_NETDEV_REGISTERED, &rdev->flags); @@ -294,19 +294,16 @@ static int bng_re_dev_init(struct bng_re_dev *rdev) ibdev_err(&rdev->ibdev, "RoCE requires minimum 2 MSI-X vectors, but only %d reserved\n", rdev->aux_dev->auxr_info->msix_requested); - bnge_unregister_dev(rdev->aux_dev); - clear_bit(BNG_RE_FLAG_NETDEV_REGISTERED, &rdev->flags); - return -EINVAL; + rc =3D -EINVAL; + goto msix_ctx_fail; } ibdev_dbg(&rdev->ibdev, "Got %d MSI-X vectors\n", rdev->aux_dev->auxr_info->msix_requested); =20 rc =3D bng_re_setup_chip_ctx(rdev); if (rc) { - bnge_unregister_dev(rdev->aux_dev); - clear_bit(BNG_RE_FLAG_NETDEV_REGISTERED, &rdev->flags); ibdev_err(&rdev->ibdev, "Failed to get chip context\n"); - return -EINVAL; + goto msix_ctx_fail; } =20 bng_re_query_hwrm_version(rdev); @@ -315,16 +312,14 @@ static int bng_re_dev_init(struct bng_re_dev *rdev) if (rc) { ibdev_err(&rdev->ibdev, "Failed to allocate RCFW Channel: %#x\n", rc); - goto fail; + goto alloc_fw_chl_fail; } =20 /* Allocate nq record memory */ rdev->nqr =3D kzalloc(sizeof(*rdev->nqr), GFP_KERNEL); if (!rdev->nqr) { - bng_re_destroy_chip_ctx(rdev); - bnge_unregister_dev(rdev->aux_dev); - clear_bit(BNG_RE_FLAG_NETDEV_REGISTERED, &rdev->flags); - return -ENOMEM; + rc =3D -ENOMEM; + goto nq_alloc_fail; } =20 rdev->nqr->num_msix =3D rdev->aux_dev->auxr_info->msix_requested; @@ -393,9 +388,15 @@ static int bng_re_dev_init(struct bng_re_dev *rdev) free_ring: bng_re_net_ring_free(rdev, rdev->rcfw.creq.ring_id, type); free_rcfw: + kfree(rdev->nqr); +nq_alloc_fail: bng_re_free_rcfw_channel(&rdev->rcfw); -fail: - bng_re_dev_uninit(rdev); +alloc_fw_chl_fail: + bng_re_destroy_chip_ctx(rdev); +msix_ctx_fail: + bnge_unregister_dev(rdev->aux_dev); + clear_bit(BNG_RE_FLAG_NETDEV_REGISTERED, &rdev->flags); +reg_netdev_fail: return rc; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CB973D9DB7; Sat, 28 Feb 2026 17:40:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300444; cv=none; b=PtOcN84OhimS65GxC5CHIQmjn37ZWDNme2n3ih4OobZA+kOUrHdgRTfvJW5DYtQJ5XvNym4LfM9aYtJcAHfSs5KcgT8SkrBMJWyRWAvsypm3WgtXO0J41PtL5hDTt1wutE7mgXhTxL11FtzOqW6dKe2jAPMThov23tAWLOKExCI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300444; c=relaxed/simple; bh=mz6fbB2yOkrwl6+aHsnGN2dqGszwg07acNOLfQMNirs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GYEoSRP/o5olVEzo8eFQlyucu1lDlKX5VLlOabkSxGWdE+shmwN3VKZPCN9eKcmqHUGItYL6SGRiY39/3KCVYIpOU3rj8kbPx8/FCRRH+mfos33F+BH+kckxjxqlUmCYSjYFig0TmQjfPrs5NCBeyMnfS2YVgF+V5w3i3JNcGZQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C+7CwWcD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C+7CwWcD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D24D4C116D0; Sat, 28 Feb 2026 17:40:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300444; bh=mz6fbB2yOkrwl6+aHsnGN2dqGszwg07acNOLfQMNirs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C+7CwWcDAb7hc+Jsrnrm99NQvgs1UG3Wucd/Fc+J6av58KHo/mJTCmQu3Yp6zdU8t iSzTrDVD8kScvNyFfklmTHQHnodJW2MMvF9JK8E88KDv5BPL6U8G7ynuhKu57TBUP9 WmBBUIj4Xi+2mNG8v0+MWzESbbTPVmEnlyMkb9LglESdrYTthYFozHmYN9OS9cAU0F IctnJeQADS9ule3DpX3hM1hIEJrSsR4B/8FdRiDM7CABEMzGKjkSRynMhPejYllIZH kNMhv6kowGqudC1BL7fOGYf89Ru8EcXACUMI2MofHg6PRLTrl1JTEZ0sH5mshZr97C h6ywE0xxWyXUA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Duoming Zhou , Jijie Shao , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 484/844] net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets Date: Sat, 28 Feb 2026 12:26:37 -0500 Message-ID: <20260228173244.1509663-485-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Duoming Zhou [ Upstream commit bae8a5d2e759da2e0cba33ab2080deee96a09373 ] When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=3D0|zone=3D1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88800aad1080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800aad1100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fix this by ensuring that both fst_tx_task and fst_int_task are properly canceled before the fst_card_info is released. Add tasklet_kill() in fst_remove_one() to synchronize with any pending or running tasklets. Since unregister_hdlc_device() stops data transmission and reception, and fst_disable_intr() prevents further interrupts, it is appropriate to place tasklet_kill() after these calls. The bugs were identified through static analysis. To reproduce the issue and validate the fix, a FarSync T-series card was simulated in QEMU and delays(e.g., mdelay()) were introduced within the tasklet handler to increase the likelihood of triggering the race condition. Fixes: 2f623aaf9f31 ("net: farsync: Fix kmemleak when rmmods farsync") Signed-off-by: Duoming Zhou Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20260219124637.72578-1-duoming@zju.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wan/farsync.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c index 5b01642ca44e0..6b2d1e63855e8 100644 --- a/drivers/net/wan/farsync.c +++ b/drivers/net/wan/farsync.c @@ -2550,6 +2550,8 @@ fst_remove_one(struct pci_dev *pdev) =20 fst_disable_intr(card); free_irq(card->irq, card); + tasklet_kill(&fst_tx_task); + tasklet_kill(&fst_int_task); =20 iounmap(card->ctlmem); iounmap(card->mem); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FE6B3D9DD3; Sat, 28 Feb 2026 17:40:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300445; cv=none; b=pL0/shjve4RbnSHZ7xDJ+GKHY4+/9aOJINsqJPQoDkhuY9HlFfZzTP7VVMbc9V1pz2E9Wj3MVKCiJ0XDQuKSPXK7xjQfkE9E/ckb/kdwfG2WLOJKt2iYIOGu9uk/LBAM4ycmz8pNnt7eVgroTz42mCHt5Csm/aw3O7AjRA90a1M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300445; c=relaxed/simple; bh=2jMmiVVMdvqj27SNqhkV2zWGqwRFbajKz7cQ3iAA9q4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F5Eq6Q9XtLMVdGyVJci+UjAmUxkZ6YY5OzuNh1Nq6UOh9hPCo1CGC/GfVDE0j+zMO2whV2GVRsUVqO/yqMGYCKoEPZU9N9hVn35omxLJAth2/RYYvWkDwohNe8V1gIIpJGwUD1esFAAER4uWgYVwzv1AF/8nPZ2ariDg7qZoJys= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Zqh8Vh4K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Zqh8Vh4K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C32DAC19424; Sat, 28 Feb 2026 17:40:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300445; bh=2jMmiVVMdvqj27SNqhkV2zWGqwRFbajKz7cQ3iAA9q4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Zqh8Vh4K5s9wP8S/Qhdsn8fA1/hTAdIcWg8qOse5ZCoUYnV9k2m4hv2opFdaSvoyd oy6ovxiX0T3gyW0ThOosg/1RYJMHCBJ0xBmMj1gjLB0ttTfTYm569i+5y4EsJOeb1b qtZpweR4MbEPw9Xgo0PNh5qiUnWiBik9GRZKQQCGqi7W/CwohhPjmGgXVqPvKy5qHx BC4taGmsJiTjg0wOyQuGCyJGJYNLwcyfznHkGIOmWrrMCVvZUTGQvObSALDbopjNQ2 qGAzj10ZA7HCZG+A6sDlqLL0O+Buu7JPWnTf9ChfN6aXp42aWpPE1jNkSz4A+r6EWj T+PMG2rTWQBJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jakub Kicinski , Simon Horman , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 485/844] netconsole: avoid OOB reads, msg is not nul-terminated Date: Sat, 28 Feb 2026 12:26:38 -0500 Message-ID: <20260228173244.1509663-486-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jakub Kicinski [ Upstream commit 82aec772fca2223bc5774bd9af486fd95766e578 ] msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g= 4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4= c00) Fixes: c62c0a17f9b7 ("netconsole: Append kernel version to message") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260219195021.2099699-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/netconsole.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c index 9cb4dfc242f5f..f418efb38508c 100644 --- a/drivers/net/netconsole.c +++ b/drivers/net/netconsole.c @@ -1524,7 +1524,8 @@ static void send_msg_no_fragmentation(struct netconso= le_target *nt, if (release_len) { release =3D init_utsname()->release; =20 - scnprintf(nt->buf, MAX_PRINT_CHUNK, "%s,%s", release, msg); + scnprintf(nt->buf, MAX_PRINT_CHUNK, "%s,%.*s", release, + msg_len, msg); msg_len +=3D release_len; } else { memcpy(nt->buf, msg, msg_len); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 68B2248A2A8; Sat, 28 Feb 2026 17:40:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300446; cv=none; b=qSdmSsBEsRI2eFwN0O4pydKgfV6nvtUMg4OlkjH1vtipFNvWL1exwDZTqGPaP4cSgZAxPLyIeGh8Ik7/VTD9InNr8RFonWT/TApiBqGBW7GoarSlF0b17FAfSB0IwfwuLorcM7h6NlisPgzEhycfxz8JVJIGhjqQe5DRn4ECPv8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300446; c=relaxed/simple; bh=yH2Z9AcWUq5d8W1YQjCN4M2P2vtr+m3C/YvoCnfwbgA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LyZqSKxJycJyRn2Tp+ovDruqz0JY3azi36/C+dJbp13bdd7Xosppuk+tQcL8rrnWHdf/X6ZN2mJatAwWdY/L+DEF9fQnDItDJd9fSrPIrY+q/LSfBe0pxqyrt7p6we1yYCl5I6Q2slFL1u97UPKVc7fTbB1w4hGANy/L0Rfaw10= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fvC2q0o5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fvC2q0o5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4FDAC19425; Sat, 28 Feb 2026 17:40:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300446; bh=yH2Z9AcWUq5d8W1YQjCN4M2P2vtr+m3C/YvoCnfwbgA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fvC2q0o5Yet7GDChn8tVvCMOwQZ628MdD2ATCdZoUesjDY9b6exUjBURBA4BBdeDW fG6Aye0hifINY+YY4Su7JOgT0j6gwm/HvsJUxxyBuIMaq/J5mrGlmKNlnyLMNNibyX 3qYz8VAthkA/xPi+fNgd3G5rukx+/kt6r6tAMKzcu1vUhTwW2FNM1EuKjiShl6XbxR 7HBxo5+sjQ4OBBJ0qvge2iXlgZgqnbpdTAiaUysw4qTBW59+0ogVK+y7+J/2oE4zwT MIeSzSj8pIfS4JjhNg0z8AIwcTpzyOUuDQHcp8/z6tDNMf1TA+Xa8quFLpz5BTDxA6 TcchNOxXnN5ig== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kamal Heib , Leon Romanovsky , Sasha Levin Subject: [PATCH 6.19 486/844] RDMA/ionic: Fix potential NULL pointer dereference in ionic_query_port Date: Sat, 28 Feb 2026 12:26:39 -0500 Message-ID: <20260228173244.1509663-487-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kamal Heib [ Upstream commit fd80bd7105f88189f47d465ca8cb7d115570de30 ] The function ionic_query_port() calls ib_device_get_netdev() without checking the return value which could lead to NULL pointer dereference, Fix it by checking the return value and return -ENODEV if the 'ndev' is NULL. Fixes: 2075bbe8ef03 ("RDMA/ionic: Register device ops for miscellaneous fun= ctionality") Signed-off-by: Kamal Heib Link: https://patch.msgid.link/20260220222125.16973-2-kheib@redhat.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/infiniband/hw/ionic/ionic_ibdev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/infiniband/hw/ionic/ionic_ibdev.c b/drivers/infiniband= /hw/ionic/ionic_ibdev.c index 164046d00e5d4..bd4c73e530d08 100644 --- a/drivers/infiniband/hw/ionic/ionic_ibdev.c +++ b/drivers/infiniband/hw/ionic/ionic_ibdev.c @@ -81,6 +81,8 @@ static int ionic_query_port(struct ib_device *ibdev, u32 = port, return -EINVAL; =20 ndev =3D ib_device_get_netdev(ibdev, port); + if (!ndev) + return -ENODEV; =20 if (netif_running(ndev) && netif_carrier_ok(ndev)) { attr->state =3D IB_PORT_ACTIVE; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABAC03DB4E7; Sat, 28 Feb 2026 17:40:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300447; cv=none; b=by60bGtnL305BL+8MaUDZ7MLbLlmcKidP9mmbEIZftAxKRkR6/ZHe+758NGE+S7aGKMSSq9gUmddfhD4G+4wXIF9h1JWEBDVUQ89olP00Da5XXxzJJu1rLgpUrjj9GCIYFs1xINGQP1DFRJLLgREuK1ash188Wn3sM0FT4V2AeY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300447; c=relaxed/simple; bh=RZJViCNLIiBqodozrBC42YiKsU8srBesroCSyoWxziI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=S4H/wEDfKXW9Yn688z45+6DjFVGZZ3lgg6shUkfJKm2bQab7FLq8Tjcg3n5qxS+JnRNScmfM144h9wyOfE98yHaDtQVL0DZE5epDBztT43UxIbCDt+WXW4ZnfMu54nqF5qLt9wmBaWOvJklq79Ox0E2+rZeq1RmssDDvGpeWH1g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qN2YjBXk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qN2YjBXk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90A4EC19424; Sat, 28 Feb 2026 17:40:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300447; bh=RZJViCNLIiBqodozrBC42YiKsU8srBesroCSyoWxziI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qN2YjBXkFbdrRtTkGuM3eP6XoAAj5hY1pG1y30dK2xy8w7wrTI2O24U1Iy82FuRk2 /ybYm0zOjKbYYzVhJXSczxYdexxBELaDoy1XuhMa2ytRr1IYr9MEPWWp4XsXfFEM+W hT4ENydy+BhBzfJUE80r6Mjk1Om5mN0hhIbDpj012/7AxoBxqlL2AXa9zFsWaLm7cN eeDlRY6W2+uJgyQbuvx+FSkGSS8ulhIFy8dIAXeSqs0VG7gm+7fuKElbKMBEIgsC62 ybRxgCBMw0Rbsklbt2tNF1FvWb/wqyo21G953W8hACSlfFmVVWgdxYT7EHci7PM31p khukPLxTPGsXg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jason Gunthorpe , Michael Margolin , Leon Romanovsky , Sasha Levin Subject: [PATCH 6.19 487/844] RDMA/efa: Fix typo in efa_alloc_mr() Date: Sat, 28 Feb 2026 12:26:40 -0500 Message-ID: <20260228173244.1509663-488-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jason Gunthorpe [ Upstream commit f22c77ce49db0589103d96487dca56f5b2136362 ] The pattern is to check the entire driver request space, not just sizeof something unrelated. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Signed-off-by: Jason Gunthorpe Link: https://patch.msgid.link/1-v1-83e918d69e73+a9-rdma_udata_rc_jgg@nvidi= a.com Acked-by: Michael Margolin Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/infiniband/hw/efa/efa_verbs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/efa/efa_verbs.c b/drivers/infiniband/hw/= efa/efa_verbs.c index 755bba8d58bbc..5cab7dd70aebf 100644 --- a/drivers/infiniband/hw/efa/efa_verbs.c +++ b/drivers/infiniband/hw/efa/efa_verbs.c @@ -1663,7 +1663,7 @@ static struct efa_mr *efa_alloc_mr(struct ib_pd *ibpd= , int access_flags, struct efa_mr *mr; =20 if (udata && udata->inlen && - !ib_is_udata_cleared(udata, 0, sizeof(udata->inlen))) { + !ib_is_udata_cleared(udata, 0, udata->inlen)) { ibdev_dbg(&dev->ibdev, "Incompatible ABI params, udata not cleared\n"); return ERR_PTR(-EINVAL); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C702D481FDF; Sat, 28 Feb 2026 17:40:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300448; cv=none; b=NOZlPL5c2GbhwpWr3j4KqG+iOlvwuBCLDMleOJSkcc3XbT8MTdMO/ZQdHs8Bwhomc59kaoHGvuHp+6esffqJVKzeynXJjeGydGbTvi9KLJsdumIdDC+AKKZb5T/YdL0pDPAOJMkkfq79h5JxWvyx+ZN77orebdkYNc5reyl3vk8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300448; c=relaxed/simple; bh=WOkoccIId5DHJYPfVCdMPRT4pu4rdCeXh9/NXk9vzHI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eS7HTK3dnvAUIFUvXluJzj0/XDS8c7kcmwwZG58YP+GRNoU3DCR2bluZtaEe+HfS6LbCpmXhV2BeddOZlA/h4Wi76kcMW/FG7nTu7fux/y3SgskWu4/GLpQthYDoK85Mc+yuB5SEy505hC2ojw93EE6Qi6+ueCG7OnMLrMEPbe8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tULBAGzt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tULBAGzt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9724CC19423; Sat, 28 Feb 2026 17:40:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300448; bh=WOkoccIId5DHJYPfVCdMPRT4pu4rdCeXh9/NXk9vzHI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tULBAGztr4Df3fRxinhCgylnYVdGc2/kj/kAMrw77GsKPtIA7Z8KhpRDQ2WeOHGC4 gTFL1tfimJND04ChbYxdOFJSy2p1KII+H1BDKO/R7ld/Sic5sgiF8UYiS7CFQ4j3U5 Zy9n8yJehAzcKV0JCiuHdfIMtIhQjqdaBFXOql903tYxpl6J2bxiBspJC/sv4ezVBM KaS876BoMSPKU/wHq8nSfxlwDpD2M2u5e1/0bshi16y4bGljq33nYrkxf5FAS1KEQV RzCHNpcv7Fkv8F1bYldaBlKZ1nkwaHfgTo7KlG6zTnK76+K5Bqrcr+USJ/Hw034Rzd Tb706/NKXO/PA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sebastian Andrzej Siewior , Willem de Bruijn , Jason Xing , Eric Dumazet , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 488/844] net: Drop the lock in skb_may_tx_timestamp() Date: Sat, 28 Feb 2026 12:26:41 -0500 Message-ID: <20260228173244.1509663-489-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sebastian Andrzej Siewior [ Upstream commit 983512f3a87fd8dc4c94dfa6b596b6e57df5aad7 ] skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared. Link: https://lore.kernel.org/all/20260205145104.iWinkXHv@linutronix.de Fixes: b245be1f4db1a ("net-timestamp: no-payload only sysctl") Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Willem de Bruijn Reviewed-by: Jason Xing Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260220183858.N4ERjFW6@linutronix.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/net/sock.h | 2 +- net/core/skbuff.c | 23 ++++++++++++++++++----- net/socket.c | 2 +- 3 files changed, 20 insertions(+), 7 deletions(-) diff --git a/include/net/sock.h b/include/net/sock.h index aafe8bdb2c0f9..ff65c3a67efa2 100644 --- a/include/net/sock.h +++ b/include/net/sock.h @@ -2089,7 +2089,7 @@ static inline int sk_rx_queue_get(const struct sock *= sk) =20 static inline void sk_set_socket(struct sock *sk, struct socket *sock) { - sk->sk_socket =3D sock; + WRITE_ONCE(sk->sk_socket, sock); if (sock) { WRITE_ONCE(sk->sk_uid, SOCK_INODE(sock)->i_uid); WRITE_ONCE(sk->sk_ino, SOCK_INODE(sock)->i_ino); diff --git a/net/core/skbuff.c b/net/core/skbuff.c index fa6209f45de9c..79dc6d6900cd3 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -5555,15 +5555,28 @@ static void __skb_complete_tx_timestamp(struct sk_b= uff *skb, =20 static bool skb_may_tx_timestamp(struct sock *sk, bool tsonly) { - bool ret; + struct socket *sock; + struct file *file; + bool ret =3D false; =20 if (likely(tsonly || READ_ONCE(sock_net(sk)->core.sysctl_tstamp_allow_dat= a))) return true; =20 - read_lock_bh(&sk->sk_callback_lock); - ret =3D sk->sk_socket && sk->sk_socket->file && - file_ns_capable(sk->sk_socket->file, &init_user_ns, CAP_NET_RAW); - read_unlock_bh(&sk->sk_callback_lock); + /* The sk pointer remains valid as long as the skb is. The sk_socket and + * file pointer may become NULL if the socket is closed. Both structures + * (including file->cred) are RCU freed which means they can be accessed + * within a RCU read section. + */ + rcu_read_lock(); + sock =3D READ_ONCE(sk->sk_socket); + if (!sock) + goto out; + file =3D READ_ONCE(sock->file); + if (!file) + goto out; + ret =3D file_ns_capable(file, &init_user_ns, CAP_NET_RAW); +out: + rcu_read_unlock(); return ret; } =20 diff --git a/net/socket.c b/net/socket.c index 136b98c54fb37..05952188127f5 100644 --- a/net/socket.c +++ b/net/socket.c @@ -674,7 +674,7 @@ static void __sock_release(struct socket *sock, struct = inode *inode) iput(SOCK_INODE(sock)); return; } - sock->file =3D NULL; + WRITE_ONCE(sock->file, NULL); } =20 /** --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEDC13DBD20; Sat, 28 Feb 2026 17:40:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300450; cv=none; b=PK0hqu5xvNWHO3dTn+qMDWI41v6G3wrz2ii1bBFb3FAl/KdnIPzFzBbIlyWK0nG/Nbq2bKQps5391lqBfRoy39mpIFE8zw5iyBTAB76KakbqPX4IBRHxWsI8VX/ocgf/vtkuB8eg4sIOChkK7nNe3elKsgAt1Apm3tWuQXme3Fg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300450; c=relaxed/simple; bh=4VyEYONTL+TgY1a7SDXvB0Bl/lU4+G5iJWVq4kmxXU4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Uum6VgTdex2paMvuKGcj89ic2BI5lk1vb+CMZ0txHP+/ek+og450+4/CStcyBQQsYryoLcxz8DxT8bQEyD97y80yMnp3Qu3IOLqGFVcv80+4qgNg+8lC8wyqcBsP8nqssROvifM4f5NSSWWaRzN2ftZGlM2fjCLHNoKchGLv51k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cb0hqDEY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cb0hqDEY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D63B8C19424; Sat, 28 Feb 2026 17:40:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300449; bh=4VyEYONTL+TgY1a7SDXvB0Bl/lU4+G5iJWVq4kmxXU4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cb0hqDEYS/XvtShnmBkudVBEmVR1w5dRHBOBT+yeVUmkbTYejgqJ5X0YP0WG2i2MM /JvDYXIkGoaZqFFKBY4rnayIfUtBsuXJrfadKwqerYPZXK6i7tbnjtGOkz6hFZW3tw ULkTGaxnJh36WA/KfAzmaufRROhmKaptVrrLcgTn9/BpCA3s1fB4GFLIpsv1H85oaB XvgN4fnYini2a5CbMNNi0rrmEMKaRuwwFZMwlMGDmjMMOUlIXH2HuXYVcTweot+LsQ HNiFNbQtu+C9Gjw/UlUJwLnkrdZcJiI8+XOGYz0tQAmAVAAm1FSiOTRwPy9VoHoF2y RsyXEiegEJtBQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ziyi Guo , Simon Horman , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 489/844] net: usb: pegasus: enable basic endpoint checking Date: Sat, 28 Feb 2026 12:26:42 -0500 Message-ID: <20260228173244.1509663-490-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ziyi Guo [ Upstream commit 3d7e6ce34f4fcc7083510c28b17a7c36462a25d4 ] pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ziyi Guo Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260222050633.410165-1-n7l8m4@u.northwester= n.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/usb/pegasus.c | 35 ++++++++++++++++++++++++++++++----- 1 file changed, 30 insertions(+), 5 deletions(-) diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c index c514483134f05..0f16a133c75d1 100644 --- a/drivers/net/usb/pegasus.c +++ b/drivers/net/usb/pegasus.c @@ -31,6 +31,17 @@ static const char driver_name[] =3D "pegasus"; BMSR_100FULL | BMSR_ANEGCAPABLE) #define CARRIER_CHECK_DELAY (2 * HZ) =20 +/* + * USB endpoints. + */ + +enum pegasus_usb_ep { + PEGASUS_USB_EP_CONTROL =3D 0, + PEGASUS_USB_EP_BULK_IN =3D 1, + PEGASUS_USB_EP_BULK_OUT =3D 2, + PEGASUS_USB_EP_INT_IN =3D 3, +}; + static bool loopback; static bool mii_mode; static char *devid; @@ -545,7 +556,7 @@ static void read_bulk_callback(struct urb *urb) goto tl_sched; goon: usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb, - usb_rcvbulkpipe(pegasus->usb, 1), + usb_rcvbulkpipe(pegasus->usb, PEGASUS_USB_EP_BULK_IN), pegasus->rx_skb->data, PEGASUS_MTU, read_bulk_callback, pegasus); rx_status =3D usb_submit_urb(pegasus->rx_urb, GFP_ATOMIC); @@ -585,7 +596,7 @@ static void rx_fixup(struct tasklet_struct *t) return; } usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb, - usb_rcvbulkpipe(pegasus->usb, 1), + usb_rcvbulkpipe(pegasus->usb, PEGASUS_USB_EP_BULK_IN), pegasus->rx_skb->data, PEGASUS_MTU, read_bulk_callback, pegasus); try_again: @@ -713,7 +724,7 @@ static netdev_tx_t pegasus_start_xmit(struct sk_buff *s= kb, ((__le16 *) pegasus->tx_buff)[0] =3D cpu_to_le16(l16); skb_copy_from_linear_data(skb, pegasus->tx_buff + 2, skb->len); usb_fill_bulk_urb(pegasus->tx_urb, pegasus->usb, - usb_sndbulkpipe(pegasus->usb, 2), + usb_sndbulkpipe(pegasus->usb, PEGASUS_USB_EP_BULK_OUT), pegasus->tx_buff, count, write_bulk_callback, pegasus); if ((res =3D usb_submit_urb(pegasus->tx_urb, GFP_ATOMIC))) { @@ -840,7 +851,7 @@ static int pegasus_open(struct net_device *net) set_registers(pegasus, EthID, 6, net->dev_addr); =20 usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb, - usb_rcvbulkpipe(pegasus->usb, 1), + usb_rcvbulkpipe(pegasus->usb, PEGASUS_USB_EP_BULK_IN), pegasus->rx_skb->data, PEGASUS_MTU, read_bulk_callback, pegasus); if ((res =3D usb_submit_urb(pegasus->rx_urb, GFP_KERNEL))) { @@ -851,7 +862,7 @@ static int pegasus_open(struct net_device *net) } =20 usb_fill_int_urb(pegasus->intr_urb, pegasus->usb, - usb_rcvintpipe(pegasus->usb, 3), + usb_rcvintpipe(pegasus->usb, PEGASUS_USB_EP_INT_IN), pegasus->intr_buff, sizeof(pegasus->intr_buff), intr_callback, pegasus, pegasus->intr_interval); if ((res =3D usb_submit_urb(pegasus->intr_urb, GFP_KERNEL))) { @@ -1136,10 +1147,24 @@ static int pegasus_probe(struct usb_interface *intf, pegasus_t *pegasus; int dev_index =3D id - pegasus_ids; int res =3D -ENOMEM; + static const u8 bulk_ep_addr[] =3D { + PEGASUS_USB_EP_BULK_IN | USB_DIR_IN, + PEGASUS_USB_EP_BULK_OUT | USB_DIR_OUT, + 0}; + static const u8 int_ep_addr[] =3D { + PEGASUS_USB_EP_INT_IN | USB_DIR_IN, + 0}; =20 if (pegasus_blacklisted(dev)) return -ENODEV; =20 + /* Verify that all required endpoints are present */ + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) { + dev_err(&intf->dev, "Missing or invalid endpoints\n"); + return -ENODEV; + } + net =3D alloc_etherdev(sizeof(struct pegasus)); if (!net) goto out; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84D003DBD31; Sat, 28 Feb 2026 17:40:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300450; cv=none; b=gfYNaGGVewQUPbNhblH4IYk2Sl2C65ylhovfcNTHvddyJvXVyjKp9mJ0LcxsfH4K2KDlo3nJ8zReAxav1aoZLr6qx74+sDsk34k6vsMb7uzvaznKSMrvHtIAqC7NPWqC+7xLsoMNCaoXvj2SXvSrLxaqdseOspeAxiC23bXNRSg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300450; c=relaxed/simple; bh=H4+M4frMpuu9VZziEWFTpF/5sUXIheXRCgWyulN+qZc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GHOyFzbdgd1/Bj+6jLpdKNe/AIXW5rAv949Ok5DqrnZusvHNqXBW6f7SDcVOxkUa9qtC7eACN+kbtalUFlNwMtSV7ll8Zegk7FPKmfQl7qJCnyDPyJUGjNoSScwGJei6+16m5tsthdW1Op6BWaFWeokmY2mkmEFzftGbtKPZ0g0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F1yBVa/I; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F1yBVa/I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0B68C19423; Sat, 28 Feb 2026 17:40:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300450; bh=H4+M4frMpuu9VZziEWFTpF/5sUXIheXRCgWyulN+qZc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F1yBVa/IiPlA1IMMXVSlB+LzF83M1ni8ip8r4O0iSr3EjUrIfKeKGyCe09hjhFGHS l3TqRqlrT2OvljuV5WDQoCy3Bf9sI6gWY4wcmzghAnZveERpH77Azhg2L1LJTu1AAy PblIkjChcg9Y89hV9kXnVrAYtvIXleMOSVfE+szU7WkwtDsRa97NdXq51ftwPMQQqO Gn/utEaSRIHHKGkJhhxUu43wTjwxoixvMGbRY6wZ34mGN5OF35a7/lqs/YdHqrv+OG SstkWjsT+1AWCLS2bMQJN+ByYiExucirvaQaFFqpAXHrLpsXEntj4Xv3lYvurHx0VC n6Zm8QzRIvL7w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gao Xiang , syzbot+d988dc155e740d76a331@syzkaller.appspotmail.com, Sasha Levin Subject: [PATCH 6.19 490/844] erofs: fix interlaced plain identification for encoded extents Date: Sat, 28 Feb 2026 12:26:43 -0500 Message-ID: <20260228173244.1509663-491-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gao Xiang [ Upstream commit 4a2d046e4b13202a6301a993961f5b30ae4d7119 ] Only plain data whose start position and on-disk physical length are both aligned to the block size should be classified as interlaced plain extents. Otherwise, it must be treated as shifted plain extents. This issue was found by syzbot using a crafted compressed image containing plain extents with unaligned physical lengths, which can cause OOB read in z_erofs_transform_plain(). Reported-and-tested-by: syzbot+d988dc155e740d76a331@syzkaller.appspotmail.c= om Closes: https://lore.kernel.org/r/699d5714.050a0220.cdd3c.03e7.GAE@google.c= om Fixes: 1d191b4ca51d ("erofs: implement encoded extent metadata") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/erofs/zmap.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/erofs/zmap.c b/fs/erofs/zmap.c index c8d8e129eb4ba..30775502b56da 100644 --- a/fs/erofs/zmap.c +++ b/fs/erofs/zmap.c @@ -513,6 +513,7 @@ static int z_erofs_map_blocks_ext(struct inode *inode, unsigned int recsz =3D z_erofs_extent_recsize(vi->z_advise); erofs_off_t pos =3D round_up(Z_EROFS_MAP_HEADER_END(erofs_iloc(inode) + vi->inode_isize + vi->xattr_isize), recsz); + unsigned int bmask =3D sb->s_blocksize - 1; bool in_mbox =3D erofs_inode_in_metabox(inode); erofs_off_t lend =3D inode->i_size; erofs_off_t l, r, mid, pa, la, lstart; @@ -596,17 +597,17 @@ static int z_erofs_map_blocks_ext(struct inode *inode, map->m_flags |=3D EROFS_MAP_MAPPED | EROFS_MAP_FULL_MAPPED | EROFS_MAP_ENCODED; fmt =3D map->m_plen >> Z_EROFS_EXTENT_PLEN_FMT_BIT; + if (map->m_plen & Z_EROFS_EXTENT_PLEN_PARTIAL) + map->m_flags |=3D EROFS_MAP_PARTIAL_REF; + map->m_plen &=3D Z_EROFS_EXTENT_PLEN_MASK; if (fmt) map->m_algorithmformat =3D fmt - 1; - else if (interlaced && !erofs_blkoff(sb, map->m_pa)) + else if (interlaced && !((map->m_pa | map->m_plen) & bmask)) map->m_algorithmformat =3D Z_EROFS_COMPRESSION_INTERLACED; else map->m_algorithmformat =3D Z_EROFS_COMPRESSION_SHIFTED; - if (map->m_plen & Z_EROFS_EXTENT_PLEN_PARTIAL) - map->m_flags |=3D EROFS_MAP_PARTIAL_REF; - map->m_plen &=3D Z_EROFS_EXTENT_PLEN_MASK; } } map->m_llen =3D lend - map->m_la; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C72D23DC665; Sat, 28 Feb 2026 17:40:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300451; cv=none; b=EdOgbE8bj5BewFI7attPcoa7jZLSewaUq8uJMRKdzGzED3M8RD6dDDtp8dwn2XCnMUagXwPU1OgPF2L/PQkVcyCKG/EKheQ5bdNkJ+0QzDwYzlSQaP/Ci9VZZO2GgyCOt2kWZtzT4RU9YM5vgMAEclVPGFE+5BLCD8IdFDORuW0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300451; c=relaxed/simple; bh=cA0iyVRujC2xfGltGqfFBfS7ZxxYDuTQ0L0yzi6eVWs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TCVV2rv7nw0Gcz5nslOmMnIl62g1GWBHyKvBYeZyxOOv0/mR1MrKsox0ctpfLWifvcGckz0koMrbXgpGMt0IRwYuz/LLa/okn/HpAtpj5R1XsEbmuxC/aIl5F9GC3uUcmy+TqfKvv+4rGk6fXOPtc1e3f0yWutOYsuOxpImPLkg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SWfspa2E; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SWfspa2E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0608C116D0; Sat, 28 Feb 2026 17:40:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300451; bh=cA0iyVRujC2xfGltGqfFBfS7ZxxYDuTQ0L0yzi6eVWs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SWfspa2EhiYJuNoBWw+ZANwbtlD/wTlA3KkyF0TMBxuz117nk8ZdI8FcknRryWifS aBksxWrvfq/mGv8m9rBbFNAsFFDW+MV5tLNboGgZjfZlSjQoJyDrf8aIux37KYAFyT sTj7cC8RR5mg/7WBTbNAVjT6AcQtsVTGgJmXuh89Lv6wVRjOyZtnFqKA0e1JKMaL/2 LnXJJVSnXcRCxtp/bFP8HpbVeM/V6SupP83MVukrfdUSsHLMDyxDgI6WSGSvr5WK0O SZTH1bhg+O5VAXPFfCQnrfkvLZGhpmzM3p34Cv8sL7RVMlK5oOFiWeA5N+Iy/RIpAu J+7Dpi+GG0seg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jacob Moroni , Leon Romanovsky , Sasha Levin Subject: [PATCH 6.19 491/844] RDMA/umem: Fix double dma_buf_unpin in failure path Date: Sat, 28 Feb 2026 12:26:44 -0500 Message-ID: <20260228173244.1509663-492-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jacob Moroni [ Upstream commit 104016eb671e19709721c1b0048dd912dc2e96be ] In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf is immediately unpinned but the umem_dmabuf->pinned flag is still set. Then, when ib_umem_release() is called, it calls ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again. Fix this by removing the immediate unpin upon failure and just let the ib_umem_release/revoke path handle it. This also ensures the proper unmap-unpin unwind ordering if the dmabuf_map_pages call happened to fail due to dma_resv_wait_timeout (and therefore has a non-NULL umem_dmabuf->sgt). Fixes: 1e4df4a21c5a ("RDMA/umem: Allow pinned dmabuf umem usage") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260224234153.1207849-1-jmoroni@google.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/infiniband/core/umem_dmabuf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/cor= e/umem_dmabuf.c index 0ec2e4120cc94..17b16fe0e49d9 100644 --- a/drivers/infiniband/core/umem_dmabuf.c +++ b/drivers/infiniband/core/umem_dmabuf.c @@ -221,13 +221,11 @@ ib_umem_dmabuf_get_pinned_with_dma_device(struct ib_d= evice *device, =20 err =3D ib_umem_dmabuf_map_pages(umem_dmabuf); if (err) - goto err_unpin; + goto err_release; dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv); =20 return umem_dmabuf; =20 -err_unpin: - dma_buf_unpin(umem_dmabuf->attach); err_release: dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv); ib_umem_release(&umem_dmabuf->umem); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9F333DC687; Sat, 28 Feb 2026 17:40:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300452; cv=none; b=H3NGstQCwwMREaq+x0iTXc/+B0RMJP0kazmUKnHsXM2x+XddwNHTsRvstGSJfvEoYkwMQ+JHRbP/LsHXoVbSB2jFP1nNfucs00EsXGyVmu3/OqP6A7dyDWvRt9HhpyE3reWEFmPewvj7BCFPE/78eVuCqhYEqR34uwMcTyS80ys= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300452; c=relaxed/simple; bh=xctf/FX59r6/hlv+aEw3/WUbikDEiYAqTmsBHZN29J8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FTy69nazgs0IoyD+Ozt3rOTS3XRRmalhN+Mj/wyBC1bYMNyQstEilQ4Kxyy8E0bJXYnWoNw39ZA4KIpB4UJg5of0ArmZHmaxmx4Gp29EyRGPQqdnkXJ0kZuJ6joEkv5mho4Bga43Qb2RvC0ln4s8s8+cxqPBuPnfm1QqeMQzlvY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZREm1Jhr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZREm1Jhr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3AC7C19424; Sat, 28 Feb 2026 17:40:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300452; bh=xctf/FX59r6/hlv+aEw3/WUbikDEiYAqTmsBHZN29J8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZREm1Jhrdc6CGojS7X2/PvXVU+dsl3OFKYDsaQaMLCCsNqaAlhxUUPGHqze4WCvc6 C5z6q82jxed2mNWBeXZi8bGU7o0qfM1/DrXhk7vWqnb2YoPkzgV/t2fJh1vtU0KV8Z t8Kz5YLwh8HZL5aWsVXLXWRHNgYj1qsYNpWd2pdJtZ21F5kWwDnKlzvLWuFUzVd38D u26kPoBtpKfT2Stp8b4BN5TwmNBTMzT4HEQVcCu3FGe6XVEZMWFZPTghpRV28C8IcP E3R2qQjZwnRxoiiOpaF6S2zR7h0l//PqxFWia65C5x6lIWgWy5AAcjQOqS/gH/h32H XklSq0D9czZCw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Simon Baatz , Eric Dumazet , Kuniyuki Iwashima , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 492/844] tcp: re-enable acceptance of FIN packets when RWIN is 0 Date: Sat, 28 Feb 2026 12:26:45 -0500 Message-ID: <20260228173244.1509663-493-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Simon Baatz [ Upstream commit 1e3bb184e94125bae7c1703472109a646d0f79d9 ] Commit 2bd99aef1b19 ("tcp: accept bare FIN packets under memory pressure") allowed accepting FIN packets in tcp_data_queue() even when the receive window was closed, to prevent ACK/FIN loops with broken clients. Such a FIN packet is in sequence, but because the FIN consumes a sequence number, it extends beyond the window. Before commit 9ca48d616ed7 ("tcp: do not accept packets beyond window"), tcp_sequence() only required the seq to be within the window. After that change, the entire packet (including the FIN) must fit within the window. As a result, such FIN packets are now dropped and the handling path is no longer reached. Be more lenient by not counting the sequence number consumed by the FIN when calling tcp_sequence(), restoring the previous behavior for cases where only the FIN extends beyond the window. Fixes: 9ca48d616ed7 ("tcp: do not accept packets beyond window") Signed-off-by: Simon Baatz Reviewed-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260224-fix_zero_wnd_fin-v2-1-a16677ea7cea@= gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/ipv4/tcp_input.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 0d080a3e27d6f..aa4f5bf765596 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4611,15 +4611,24 @@ static enum skb_drop_reason tcp_disordered_ack_chec= k(const struct sock *sk, */ =20 static enum skb_drop_reason tcp_sequence(const struct sock *sk, - u32 seq, u32 end_seq) + u32 seq, u32 end_seq, + const struct tcphdr *th) { const struct tcp_sock *tp =3D tcp_sk(sk); + u32 seq_limit; =20 if (before(end_seq, tp->rcv_wup)) return SKB_DROP_REASON_TCP_OLD_SEQUENCE; =20 - if (after(end_seq, tp->rcv_nxt + tcp_receive_window(tp))) { - if (after(seq, tp->rcv_nxt + tcp_receive_window(tp))) + seq_limit =3D tp->rcv_nxt + tcp_receive_window(tp); + if (unlikely(after(end_seq, seq_limit))) { + /* Some stacks are known to handle FIN incorrectly; allow the + * FIN to extend beyond the window and check it in detail later. + */ + if (!after(end_seq - th->fin, seq_limit)) + return SKB_NOT_DROPPED_YET; + + if (after(seq, seq_limit)) return SKB_DROP_REASON_TCP_INVALID_SEQUENCE; =20 /* Only accept this packet if receive queue is empty. */ @@ -6145,7 +6154,8 @@ static bool tcp_validate_incoming(struct sock *sk, st= ruct sk_buff *skb, =20 step1: /* Step 1: check sequence number */ - reason =3D tcp_sequence(sk, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_se= q); + reason =3D tcp_sequence(sk, TCP_SKB_CB(skb)->seq, + TCP_SKB_CB(skb)->end_seq, th); if (reason) { /* RFC793, page 37: "In all states except SYN-SENT, all reset * (RST) segments are validated by checking their SEQ-fields." --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AD7A3DC69E; Sat, 28 Feb 2026 17:40:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300453; cv=none; b=mfJ/RecXRr4AAP7+UE6MfC4s8AmYaZ49MUwak8AONGSUkKYtJHid2/T80bW7fctLbOOI3MpzPf2JjzlX8kyw26ONhUw0NBNqWXIsyiyCBPbrVBOY6z9oJ7m3GcPWiWiPV18sL33fF8HRSQG2AwjfTICQA4OrNrmsi0sVZXdnxL8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300453; c=relaxed/simple; bh=+M3Ojoc64XvgPwIK89boFs6nFnX5f6iJJtVGh9XQs3Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eoT8Mab0yHpSgUy8K8rlhDkFEKOoMm2f2I+8cEo0wEX852hSECfQXTTEMO0XQrcg/4p3Z/90lEhOKY5pyVc8PCnJUgeZoal8wkVB51DIJuo0+PPOuoTGr7iVs60LjuRnwVnf+oYxGVJV6TMU5J4FlJWsK6Slu00okIw1Yuinh+4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GYk/rh4h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GYk/rh4h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B839BC19425; Sat, 28 Feb 2026 17:40:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300453; bh=+M3Ojoc64XvgPwIK89boFs6nFnX5f6iJJtVGh9XQs3Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GYk/rh4hn7tItJ17gvh4O3Rml2I9Hr7A2RhQiUFwlFPa90EHSx7cS/3adNynI4ZoY jwnsb547tu0PezLO0UPnn6DlBe4qgKd+I5Us28tZ23m6h9lvwh67J7/BDwQOFAdYfG AY70UJA3LPeFzc1+WgvL6q6ZEi4OlS3Fp9Zb6e4uAncU7TOthFAwUaiC42K0HLuTxu G4zRkbL8s89zQ3T9gzdqXi+ap0/1ScX2pKNStBKOq4mlPPSah59Ubcd+uzglhrmdSA cNza/n3vJnjXyzvlMDwENEK8Os50mguSpYN3+ahCPvsGZDKW4BJ3re5gWk6ipb88eI RXMLKmLuMQ+1A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Felix Gu , Ivan Vecera , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 493/844] dpll: zl3073x: Remove redundant cleanup in devm_dpll_init() Date: Sat, 28 Feb 2026 12:26:46 -0500 Message-ID: <20260228173244.1509663-494-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Felix Gu [ Upstream commit 676c7af91fcd740d34e7cb788cbc58e3bcafde39 ] The devm_add_action_or_reset() function already executes the cleanup action on failure before returning an error, so the explicit goto error and subsequent zl3073x_dev_dpll_fini() call causes double cleanup. Fixes: ebb1031c5137 ("dpll: zl3073x: Refactor DPLL initialization") Reviewed-by: Ivan Vecera Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260224-dpll-v2-1-d7786414a830@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/dpll/zl3073x/core.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c index b20d4f24c0e94..b9b7c751b7602 100644 --- a/drivers/dpll/zl3073x/core.c +++ b/drivers/dpll/zl3073x/core.c @@ -978,11 +978,7 @@ zl3073x_devm_dpll_init(struct zl3073x_dev *zldev, u8 n= um_dplls) } =20 /* Add devres action to release DPLL related resources */ - rc =3D devm_add_action_or_reset(zldev->dev, zl3073x_dev_dpll_fini, zldev); - if (rc) - goto error; - - return 0; + return devm_add_action_or_reset(zldev->dev, zl3073x_dev_dpll_fini, zldev); =20 error: zl3073x_dev_dpll_fini(zldev); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9314D3DCEAE; Sat, 28 Feb 2026 17:40:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300454; cv=none; b=Hu/rxCCTKEH6p6NCO5GAOxz1mr12gH2wTNNgKkwjS4nbzdaaep27CKTb6DUhagnV0CmjzSfCH6NoQ+KarK87yKYjpxoWT5LK/aglr89c2SejlTCoWqIi4Sj0Fg/3Fb7qizGSI/HpB+KundiUs7OotaxD87H90bLPXMn5jUwIzgk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300454; c=relaxed/simple; bh=xpotWUrM6lst7zkgzpHCfRXXRWuN+DrVm/m7yWLh7xE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lql6Bc+SOryStUslI3UbbNePgBAYfPoCr8hRLIgI56PdNHXoMpw9At4j1opyw3Wwm2t9WqvOjO8MLa332tWmM0X+qZPOrI6jpU5kwwU6xUyoB6iQtIq1LhGP6Uu5PUpO9uOdZdIyBNMV0htn8+Nv9wzv7yupytklbjzTq6s8sb0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B7x57UD5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="B7x57UD5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE9ACC19424; Sat, 28 Feb 2026 17:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300454; bh=xpotWUrM6lst7zkgzpHCfRXXRWuN+DrVm/m7yWLh7xE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B7x57UD5/pbHJxcKVucvNm2EaQjdnY568C6sYfJzFEBVrxC3FQsWjFE4EaC8DXXaq oyHCDMHlKTo6EhZHbkXVSEVDkj1tdiBqoVwgFh4XfcisZaEeYcaf/Hc+QDGmiQECkc jdaP6BR5903WzotxF3IpKnUP173oQ25o/XJuey4TV8xNisziLpcQAtaXf+OWMx5Yty x3NDeZ4pWQ8BIbZUH5jAnhOP4SqDT3KAQDA/y0utIsEeDHLbhBD+hv+VZW2iJ0DaJ4 h7xsPoZpuoCCIb70e/IPETvfDCI1WgY+BTM6/517tXukRpaN6iuOPdn6jFsGSL8cCX d9j0zPTFkEeyg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dipayaan Roy , Haiyang Zhang , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 494/844] net: mana: Fix double destroy_workqueue on service rescan PCI path Date: Sat, 28 Feb 2026 12:26:47 -0500 Message-ID: <20260228173244.1509663-495-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dipayaan Roy [ Upstream commit f975a0955276579e2176a134366ed586071c7c6a ] While testing corner cases in the driver, a use-after-free crash was found on the service rescan PCI path. When mana_serv_reset() calls mana_gd_suspend(), mana_gd_cleanup() destroys gc->service_wq. If the subsequent mana_gd_resume() fails with -ETIMEDOUT or -EPROTO, the code falls through to mana_serv_rescan() which triggers pci_stop_and_remove_bus_device(). This invokes the PCI .remove callback (mana_gd_remove), which calls mana_gd_cleanup() a second time, attempting to destroy the already- freed workqueue. Fix this by NULL-checking gc->service_wq in mana_gd_cleanup() and setting it to NULL after destruction. Call stack of issue for reference: [Sat Feb 21 18:53:48 2026] Call Trace: [Sat Feb 21 18:53:48 2026] [Sat Feb 21 18:53:48 2026] mana_gd_cleanup+0x33/0x70 [mana] [Sat Feb 21 18:53:48 2026] mana_gd_remove+0x3a/0xc0 [mana] [Sat Feb 21 18:53:48 2026] pci_device_remove+0x41/0xb0 [Sat Feb 21 18:53:48 2026] device_remove+0x46/0x70 [Sat Feb 21 18:53:48 2026] device_release_driver_internal+0x1e3/0x250 [Sat Feb 21 18:53:48 2026] device_release_driver+0x12/0x20 [Sat Feb 21 18:53:48 2026] pci_stop_bus_device+0x6a/0x90 [Sat Feb 21 18:53:48 2026] pci_stop_and_remove_bus_device+0x13/0x30 [Sat Feb 21 18:53:48 2026] mana_do_service+0x180/0x290 [mana] [Sat Feb 21 18:53:48 2026] mana_serv_func+0x24/0x50 [mana] [Sat Feb 21 18:53:48 2026] process_one_work+0x190/0x3d0 [Sat Feb 21 18:53:48 2026] worker_thread+0x16e/0x2e0 [Sat Feb 21 18:53:48 2026] kthread+0xf7/0x130 [Sat Feb 21 18:53:48 2026] ? __pfx_worker_thread+0x10/0x10 [Sat Feb 21 18:53:48 2026] ? __pfx_kthread+0x10/0x10 [Sat Feb 21 18:53:48 2026] ret_from_fork+0x269/0x350 [Sat Feb 21 18:53:48 2026] ? __pfx_kthread+0x10/0x10 [Sat Feb 21 18:53:48 2026] ret_from_fork_asm+0x1a/0x30 [Sat Feb 21 18:53:48 2026] Fixes: 505cc26bcae0 ("net: mana: Add support for auxiliary device servicing= events") Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Reviewed-by: Simon Horman Link: https://patch.msgid.link/aZ2bzL64NagfyHpg@linuxonhyperv3.guj3yctzbm1e= tfxqx2vob5hsef.xx.internal.cloudapp.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/microsoft/mana/gdma_main.c | 5 ++++- drivers/net/ethernet/microsoft/mana/mana_en.c | 4 +++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/= ethernet/microsoft/mana/gdma_main.c index 0055c231acf6d..3926d18f1840b 100644 --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c @@ -1946,7 +1946,10 @@ static void mana_gd_cleanup(struct pci_dev *pdev) =20 mana_gd_remove_irqs(pdev); =20 - destroy_workqueue(gc->service_wq); + if (gc->service_wq) { + destroy_workqueue(gc->service_wq); + gc->service_wq =3D NULL; + } dev_dbg(&pdev->dev, "mana gdma cleanup successful\n"); } =20 diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/et= hernet/microsoft/mana/mana_en.c index 1ad154f9db1ad..d487bf2f1cf1f 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -3690,7 +3690,9 @@ void mana_rdma_remove(struct gdma_dev *gd) } =20 WRITE_ONCE(gd->rdma_teardown, true); - flush_workqueue(gc->service_wq); + + if (gc->service_wq) + flush_workqueue(gc->service_wq); =20 if (gd->adev) remove_adev(gd); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D7293DCEDB; Sat, 28 Feb 2026 17:40:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300456; cv=none; b=OTQnD7j+INR1CMtZ21bn/wTFtQ/Kq3Y6380SeWJvNwjdZD887R0Ol3ncjIVWXnB5XQZrfXIgh9ecF6I92kkJjjtfrrae7jSX3Twf6eqo3HE49pzdtbhPL0mas4++uzYIoMwMeLVMkQq2xk/ivSlxiEe+37TUpHlDhnBBdslGspM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300456; c=relaxed/simple; bh=/X2qo0fxVpWKGEpHPfNQHbX/j4hmYZWEuxoIb69Wglk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p3/5+JrY3dQYAG2Z6z6HZXQWRrM/pQGNOh3MWZOV14Jaadk1nHBLHtrB51xjASwINAnQI/KeSV/DkoyLy+ZdEaV26MMGjW3hI31LNZyfVlmZDmn99n11N2SSXlMxR7kg0H+cTAte0Kl9SiBDtDOGAFsA6PbkP9sSrVfWxpuFajM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=imgnZFXz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="imgnZFXz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7277C116D0; Sat, 28 Feb 2026 17:40:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300455; bh=/X2qo0fxVpWKGEpHPfNQHbX/j4hmYZWEuxoIb69Wglk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=imgnZFXz4w9TJhhUIi6qDtvGKfsbUiWejbZIdu42JSxifFZVjcPRdpNxxkOUT8JPp TfoDlzcrWt5UJEDiO+P1qGuJc0eM/IFGbBIo7H1vfF8bvzwOrbm6QUk6jVkdGoQZyN ZBAo+fehqZw10hQSFtHpEgkAFS4fhIa6V8ZwwXq5iMHBCAw3lCWLWrd8ww4iY1f4zj le9yMvSskHwxaai+nzeRKbanzBHScXYe+ysf5NiNqu1pt9YQoEyAd3evDwX5+wqWLc gVShJc5e2sB05k5e6tp96a4UB3EoXeNb+NMyAhoLZ4OHwLxr0UslX11FFHg56HG3D+ EOBmDE1o1HeHg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tetsuo Handa , syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com, Ido Schimmel , Jiri Pirko , Stanislav Fomichev , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 495/844] team: avoid NETDEV_CHANGEMTU event when unregistering slave Date: Sat, 28 Feb 2026 12:26:48 -0500 Message-ID: <20260228173244.1509663-496-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tetsuo Handa [ Upstream commit bb4c698633c0e19717586a6524a33196cff01a32 ] syzbot is reporting unregister_netdevice: waiting for netdevsim0 to become free. Usage count = =3D 3 ref_tracker: netdev@ffff88807dcf8618 has 1/2 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_hold include/linux/netdevice.h:4429 [inline] inetdev_init+0x201/0x4e0 net/ipv4/devinet.c:286 inetdev_event+0x251/0x1610 net/ipv4/devinet.c:1600 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_mtu net/core/dev.c:2318 [inline] netif_set_mtu_ext+0x5aa/0x800 net/core/dev.c:9886 netif_set_mtu+0xd7/0x1b0 net/core/dev.c:9907 dev_set_mtu+0x126/0x260 net/core/dev_api.c:248 team_port_del+0xb07/0xcb0 drivers/net/team/team_core.c:1333 team_del_slave drivers/net/team/team_core.c:1936 [inline] team_device_event+0x207/0x5b0 drivers/net/team/team_core.c:2929 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2281 [inline] call_netdevice_notifiers net/core/dev.c:2295 [inline] __dev_change_net_namespace+0xcb7/0x2050 net/core/dev.c:12592 do_setlink+0x2ce/0x4590 net/core/rtnetlink.c:3060 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x15a9/0x1be0 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 problem. Ido Schimmel found steps to reproduce ip link add name team1 type team ip link add name dummy1 mtu 1499 master team1 type dummy ip netns add ns1 ip link set dev dummy1 netns ns1 ip -n ns1 link del dev dummy1 and also found that the same issue was fixed in the bond driver in commit f51048c3e07b ("bonding: avoid NETDEV_CHANGEMTU event when unregistering slave"). Let's do similar thing for the team driver, with commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations") and commit 303a8487a657 ("net: s/__dev_set_mtu/__netif_set_mtu/") also applied. Reported-by: syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D881d65229ca4f9ae8c84 Suggested-by: Ido Schimmel Reviewed-by: Jiri Pirko Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Signed-off-by: Tetsuo Handa Signed-off-by: Ido Schimmel Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260224125709.317574-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/team/team_core.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c index c08a5c1bd6e4d..a0fe998cc055d 100644 --- a/drivers/net/team/team_core.c +++ b/drivers/net/team/team_core.c @@ -1292,7 +1292,7 @@ static int team_port_add(struct team *team, struct ne= t_device *port_dev, =20 static void __team_port_change_port_removed(struct team_port *port); =20 -static int team_port_del(struct team *team, struct net_device *port_dev) +static int team_port_del(struct team *team, struct net_device *port_dev, b= ool unregister) { struct net_device *dev =3D team->dev; struct team_port *port; @@ -1330,7 +1330,13 @@ static int team_port_del(struct team *team, struct n= et_device *port_dev) __team_port_change_port_removed(port); =20 team_port_set_orig_dev_addr(port); - dev_set_mtu(port_dev, port->orig.mtu); + if (unregister) { + netdev_lock_ops(port_dev); + __netif_set_mtu(port_dev, port->orig.mtu); + netdev_unlock_ops(port_dev); + } else { + dev_set_mtu(port_dev, port->orig.mtu); + } kfree_rcu(port, rcu); netdev_info(dev, "Port device %s removed\n", portname); netdev_compute_master_upper_features(team->dev, true); @@ -1634,7 +1640,7 @@ static void team_uninit(struct net_device *dev) ASSERT_RTNL(); =20 list_for_each_entry_safe(port, tmp, &team->port_list, list) - team_port_del(team, port->dev); + team_port_del(team, port->dev, false); =20 __team_change_mode(team, NULL); /* cleanup */ __team_options_unregister(team, team_options, ARRAY_SIZE(team_options)); @@ -1933,7 +1939,16 @@ static int team_del_slave(struct net_device *dev, st= ruct net_device *port_dev) =20 ASSERT_RTNL(); =20 - return team_port_del(team, port_dev); + return team_port_del(team, port_dev, false); +} + +static int team_del_slave_on_unregister(struct net_device *dev, struct net= _device *port_dev) +{ + struct team *team =3D netdev_priv(dev); + + ASSERT_RTNL(); + + return team_port_del(team, port_dev, true); } =20 static netdev_features_t team_fix_features(struct net_device *dev, @@ -2926,7 +2941,7 @@ static int team_device_event(struct notifier_block *u= nused, !!netif_oper_up(port->dev)); break; case NETDEV_UNREGISTER: - team_del_slave(port->team->dev, dev); + team_del_slave_on_unregister(port->team->dev, dev); break; case NETDEV_FEAT_CHANGE: if (!port->team->notifier_ctx) { @@ -2999,3 +3014,4 @@ MODULE_LICENSE("GPL v2"); MODULE_AUTHOR("Jiri Pirko "); MODULE_DESCRIPTION("Ethernet team device driver"); MODULE_ALIAS_RTNL_LINK(DRV_NAME); +MODULE_IMPORT_NS("NETDEV_INTERNAL"); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F0CD3DD743; Sat, 28 Feb 2026 17:40:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300457; cv=none; b=Q/FwJ4yTy5fjtCaBSTcIoppoytPacOwohAFjnmIE20S+66dzoYOgGynf/h0plR/78BjVxGwc3GyEfkvNPEIvwQ5UKchx6aq/t8ik3rD9hEKDkiMI98R9zDk54xC2gYbtkPveu1LoM7fdh232IJlCSIs/JT6Gk+aNG46+GaYpXLM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300457; c=relaxed/simple; bh=RdkuAf7scFKBUlHx22gyfCGgrI6nOkT0Ss8a3+t2sEM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=anfwNNqM8/GLDmNRU8bV708AHBc40XX6Lpadg1L01XjUFSx3X3TSOFB9eVtxZ09AvDZHizfkl++zRzuSQVk7C/UzjN+gxpdOmBhKadfofnEnFMfi4d/n9IJb8t6royoaQY0+vZVk6iOPS0az59EEvvMie7ccquMQefp/O+RO9d8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ll7h0DNE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ll7h0DNE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11BB5C2BC87; Sat, 28 Feb 2026 17:40:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300457; bh=RdkuAf7scFKBUlHx22gyfCGgrI6nOkT0Ss8a3+t2sEM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ll7h0DNEAl5dWMlfp0FqPLRjNIU84hpfTOARXgUVbiB/uC5ubc3/5XbI5tVCmy0Q1 xbcOpgUIMsoo9xzr+NLneXZGYbhXqK9H/VQ+EtncG0oXmIFqayIp4jUZt0d4zAklve k4UnT0TfwhGXL3enMtHGR8FjVIEOZMhMzZz9dTlpBVwX/pWDg7uet33Cv7E1RMNcmW WFOlvdhIPV/qWig6BmDzYqgaN0JXdv2O+VB+Lg7lCU3HaMk4aE9g2TFagjupMtP6bN ZklkCWLzdU5I+AMels8O0sX/+2wT6ImVZNCV1NqRLc0C66mXRtjCp9y2wvXR+OYlzO riOCz64xZQqcQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shay Drory , Yevgeny Kliteynik , Alex Vesker , Tariq Toukan , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 496/844] net/mlx5: DR, Fix circular locking dependency in dump Date: Sat, 28 Feb 2026 12:26:49 -0500 Message-ID: <20260228173244.1509663-497-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shay Drory [ Upstream commit 2700b7e603af39ca55fe9fc876ca123efd44680f ] Fix a circular locking dependency between dbg_mutex and the domain rx/tx mutexes that could lead to a deadlock. The dump path in dr_dump_domain_all() was acquiring locks in the order: dbg_mutex -> rx.mutex -> tx.mutex While the table/matcher creation paths acquire locks in the order: rx.mutex -> tx.mutex -> dbg_mutex This inverted lock ordering creates a circular dependency. Fix this by changing dr_dump_domain_all() to acquire the domain lock before dbg_mutex, matching the order used in mlx5dr_table_create() and mlx5dr_matcher_create(). Lockdep splat: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D WARNING: possible circular locking dependency detected 6.19.0-rc6net_next_e817c4e #1 Not tainted ------------------------------------------------------ sos/30721 is trying to acquire lock: ffff888102df5900 (&dmn->info.rx.mutex){+.+.}-{4:4}, at: dr_dump_start+0x131/0x450 [mlx5_core] but task is already holding lock: ffff888102df5bc0 (&dmn->dump_info.dbg_mutex){+.+.}-{4:4}, at: dr_dump_start+0x10b/0x450 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dmn->dump_info.dbg_mutex){+.+.}-{4:4}: __mutex_lock+0x91/0x1060 mlx5dr_matcher_create+0x377/0x5e0 [mlx5_core] mlx5_cmd_dr_create_flow_group+0x62/0xd0 [mlx5_core] mlx5_create_flow_group+0x113/0x1c0 [mlx5_core] mlx5_chains_create_prio+0x453/0x2290 [mlx5_core] mlx5_chains_get_table+0x2e2/0x980 [mlx5_core] esw_chains_create+0x1e6/0x3b0 [mlx5_core] esw_create_offloads_fdb_tables.cold+0x62/0x63f [mlx5_core] esw_offloads_enable+0x76f/0xd20 [mlx5_core] mlx5_eswitch_enable_locked+0x35a/0x500 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x561/0x950 [mlx5_core] devlink_nl_eswitch_set_doit+0x67/0xe0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x188/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x1ed/0x2c0 netlink_sendmsg+0x210/0x450 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dmn->info.tx.mutex){+.+.}-{4:4}: __mutex_lock+0x91/0x1060 mlx5dr_table_create+0x11d/0x530 [mlx5_core] mlx5_cmd_dr_create_flow_table+0x62/0x140 [mlx5_core] __mlx5_create_flow_table+0x46f/0x960 [mlx5_core] mlx5_create_flow_table+0x16/0x20 [mlx5_core] esw_create_offloads_fdb_tables+0x136/0x240 [mlx5_core] esw_offloads_enable+0x76f/0xd20 [mlx5_core] mlx5_eswitch_enable_locked+0x35a/0x500 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x561/0x950 [mlx5_core] devlink_nl_eswitch_set_doit+0x67/0xe0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x188/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x1ed/0x2c0 netlink_sendmsg+0x210/0x450 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #0 (&dmn->info.rx.mutex){+.+.}-{4:4}: __lock_acquire+0x18b6/0x2eb0 lock_acquire+0xd3/0x2c0 __mutex_lock+0x91/0x1060 dr_dump_start+0x131/0x450 [mlx5_core] seq_read_iter+0xe3/0x410 seq_read+0xfb/0x130 full_proxy_read+0x53/0x80 vfs_read+0xba/0x330 ksys_read+0x65/0xe0 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dmn->dump_info.dbg_mutex); lock(&dmn->info.tx.mutex); lock(&dmn->dump_info.dbg_mutex); lock(&dmn->info.rx.mutex); *** DEADLOCK *** Fixes: 9222f0b27da2 ("net/mlx5: DR, Add support for dumping steering info") Signed-off-by: Shay Drory Reviewed-by: Yevgeny Kliteynik Reviewed-by: Alex Vesker Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_dbg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_dbg.c = b/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_dbg.c index 030a5776c9374..a4c19af1775f1 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_dbg.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_dbg.c @@ -1050,8 +1050,8 @@ static int dr_dump_domain_all(struct seq_file *file, = struct mlx5dr_domain *dmn) struct mlx5dr_table *tbl; int ret; =20 - mutex_lock(&dmn->dump_info.dbg_mutex); mlx5dr_domain_lock(dmn); + mutex_lock(&dmn->dump_info.dbg_mutex); =20 ret =3D dr_dump_domain(file, dmn); if (ret < 0) @@ -1064,8 +1064,8 @@ static int dr_dump_domain_all(struct seq_file *file, = struct mlx5dr_domain *dmn) } =20 unlock_mutex: - mlx5dr_domain_unlock(dmn); mutex_unlock(&dmn->dump_info.dbg_mutex); + mlx5dr_domain_unlock(dmn); return ret; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 650563DD75C; Sat, 28 Feb 2026 17:40:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300458; cv=none; b=o/917+qm3fe2esmHcEiBifueGEwfbe/MsP24ykP1JdoTzrR+T2KroXib66mWBRl21xsVexIX1HTLeaC6sANCFgzKR9stowMdfVtrO/tOHZfzeSXipgcN6nX9AEpJzjrnWE2PVAeXGjyuC1r2yOfD52XwjgHIpQFM4wHBJck9zP8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300458; c=relaxed/simple; bh=DmIdHrVOEh5pIXvp5DpPCo+ufBXsdDTMsz2cQjswpq4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pMwmbvyGohxtRxb5mrVcLDLtVCkEFIJKUKD8zccOt36rHQVejRYoOUtOL9bI/O51f8UYmiL6QN+O+LahmInztaRnLS30nqFC3xoQTnAVbLmdeqptXXnZhvMTiygucmEIVqwParitt4JlyRos0wEQLUdyzFE0OGKTCAseXkujO84= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R95a87qM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R95a87qM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EEDBC19425; Sat, 28 Feb 2026 17:40:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300458; bh=DmIdHrVOEh5pIXvp5DpPCo+ufBXsdDTMsz2cQjswpq4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R95a87qMAqSkofjirmunTAo++Vhi8Q4aQmmGVOOsjnffCZltInhQ8IG/rQXgPzAt3 ucJcbqryivjMJO+Qi9u+toSklxjuUemooJkWwdsF1HMjJm6fZMnTWrGaiqMFW+URbL hz6n01lvRa7jtDmSTNYHyBTtFN4AaA1gRbGJxmhiz4ucYaiEzh20sGpUEZH0xENpvM ng0l4tIyzwwUdeq7pN3TM3vScbx1Pm9eB+DoPJGE3WwNPCsd3UzopphNADWC2+8tiF La8sazZpCiSi56928p5kIOyfHMfrrjNA7vpiM4zhSyjQfSFff8K8QbGrC7KPq0X21B I4XuCmb7fmRsA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shay Drory , Mark Bloch , Tariq Toukan , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 497/844] net/mlx5: LAG, disable MPESW in lag_disable_change() Date: Sat, 28 Feb 2026 12:26:50 -0500 Message-ID: <20260228173244.1509663-498-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shay Drory [ Upstream commit bd7b9f83fb9f85228c3ac9748d9cba9fab7fb5a2 ] mlx5_lag_disable_change() unconditionally called mlx5_disable_lag() when LAG was active, which is incorrect for MLX5_LAG_MODE_MPESW. Hnece, call mlx5_disable_mpesw() when running in MPESW mode. Fixes: a32327a3a02c ("net/mlx5: Lag, Control MultiPort E-Switch single FDB = mode") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c | 8 ++++++-- drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.c | 8 ++++---- drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.h | 5 +++++ 3 files changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c b/drivers/ne= t/ethernet/mellanox/mlx5/core/lag/lag.c index a459a30f36cae..73659a0463cde 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c @@ -1654,8 +1654,12 @@ void mlx5_lag_disable_change(struct mlx5_core_dev *d= ev) mutex_lock(&ldev->lock); =20 ldev->mode_changes_in_progress++; - if (__mlx5_lag_is_active(ldev)) - mlx5_disable_lag(ldev); + if (__mlx5_lag_is_active(ldev)) { + if (ldev->mode =3D=3D MLX5_LAG_MODE_MPESW) + mlx5_lag_disable_mpesw(ldev); + else + mlx5_disable_lag(ldev); + } =20 mutex_unlock(&ldev->lock); mlx5_devcom_comp_unlock(dev->priv.hca_devcom_comp); diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.c b/drivers/= net/ethernet/mellanox/mlx5/core/lag/mpesw.c index 2d86af8f0d9b8..c217998604fdb 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.c @@ -65,7 +65,7 @@ static int mlx5_mpesw_metadata_set(struct mlx5_lag *ldev) return err; } =20 -static int enable_mpesw(struct mlx5_lag *ldev) +static int mlx5_lag_enable_mpesw(struct mlx5_lag *ldev) { struct mlx5_core_dev *dev0; int err; @@ -124,7 +124,7 @@ static int enable_mpesw(struct mlx5_lag *ldev) return err; } =20 -static void disable_mpesw(struct mlx5_lag *ldev) +void mlx5_lag_disable_mpesw(struct mlx5_lag *ldev) { if (ldev->mode =3D=3D MLX5_LAG_MODE_MPESW) { mlx5_mpesw_metadata_cleanup(ldev); @@ -150,9 +150,9 @@ static void mlx5_mpesw_work(struct work_struct *work) } =20 if (mpesww->op =3D=3D MLX5_MPESW_OP_ENABLE) - mpesww->result =3D enable_mpesw(ldev); + mpesww->result =3D mlx5_lag_enable_mpesw(ldev); else if (mpesww->op =3D=3D MLX5_MPESW_OP_DISABLE) - disable_mpesw(ldev); + mlx5_lag_disable_mpesw(ldev); unlock: mutex_unlock(&ldev->lock); mlx5_devcom_comp_unlock(devcom); diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.h b/drivers/= net/ethernet/mellanox/mlx5/core/lag/mpesw.h index 02520f27a033c..46de93ed790de 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.h +++ b/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.h @@ -31,5 +31,10 @@ int mlx5_lag_mpesw_do_mirred(struct mlx5_core_dev *mdev, bool mlx5_lag_is_mpesw(struct mlx5_core_dev *dev); void mlx5_lag_mpesw_disable(struct mlx5_core_dev *dev); int mlx5_lag_mpesw_enable(struct mlx5_core_dev *dev); +#ifdef CONFIG_MLX5_ESWITCH +void mlx5_lag_disable_mpesw(struct mlx5_lag *ldev); +#else +static inline void mlx5_lag_disable_mpesw(struct mlx5_lag *ldev) {} +#endif /* CONFIG_MLX5_ESWITCH */ =20 #endif /* __MLX5_LAG_MPESW_H__ */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FB2E3DD779; Sat, 28 Feb 2026 17:40:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300459; cv=none; b=caH4GGVo5zZYx/Z7EzoXOFSHJ2+sfapUyyDTYLX6Tg7n/UrEXg/sD/DMShFS5n7YZWsH0G+bAn+Qnarum9YTDXsDUHqqyP6rE/3zbFsoC0yzpCkHnWtyUdk+myF1SxV1R+XVOiaCoC6qWOhcyrQNYbLxjUBIS3UELV3e3t1LCg0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300459; c=relaxed/simple; bh=jDigmOKKuMiPcALnNm2j92QIQ0o6oguQ3QtcDjX4KAg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pTW4CAwuZV8twZNIdV7IYx9Q4LBBJIsfLC+ZXCE52d/iC3KYqRNxhqjY+KTKU7tXwU4hYZ5Z2tyhEEVvTsgUeapKzddOdhJDzWawu29r1N4xVSMLsYvY3sBCUaw+6g8/RVJ08X5hsHx8oAKDtTmx2xBQN0n72/ld+PGKJqhPmKY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TrBFsggY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TrBFsggY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 590E2C19423; Sat, 28 Feb 2026 17:40:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300459; bh=jDigmOKKuMiPcALnNm2j92QIQ0o6oguQ3QtcDjX4KAg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TrBFsggY8Cj1CXfhbfFQdRurUpcygAXgurcMbzfv8x+dmfnbuMf8J4Vpv/wFG9p0E TE9lwmVNccXks9CRLshF59f48YQENLdB24s/1edC86Ri+KKszAl5uPB/DsdcWFeqYY N2oqsmjO9q5zirGuKPGPbag0RmUcE3fLUbOJLeO1dip7sxcX7yDwR0seBz5nmhfX8c x7IaKaF9PnW1TAbVlIrRhChYO7LO1GXQKb1Kjk3d+FuroPzAUhTdUcN8c+nJu+0xpq W1v4yqtBafNjctrufiNnzDhDCXaNmBd+ewZa9Jc6xpmcZJWJNdoIiKH30Amx8oRAjw 1+OGzzY3EpziQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shay Drory , Mark Bloch , Tariq Toukan , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 498/844] net/mlx5: E-switch, Clear legacy flag when moving to switchdev Date: Sat, 28 Feb 2026 12:26:51 -0500 Message-ID: <20260228173244.1509663-499-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shay Drory [ Upstream commit d7073e8b978ae925f1f0f08754f33f84d8547ea7 ] The cited commit introduced MLX5_PRIV_FLAGS_SWITCH_LEGACY to identify when a transition to legacy mode is requested via devlink. However, the logic failed to clear this flag if the mode was subsequently changed back to MLX5_ESWITCH_OFFLOADS (switchdev). Consequently, if a user toggled from legacy to switchdev, the flag remained set, leaving the driver with wrong state indicating Fix this by explicitly clearing the MLX5_PRIV_FLAGS_SWITCH_LEGACY bit when the requested mode is MLX5_ESWITCH_OFFLOADS. Fixes: 2a4f56fbcc47 ("net/mlx5e: Keep netdev when leave switchdev for devli= nk set legacy only") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/d= rivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c index 02b7e474586d9..ccf53d4783628 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c @@ -4068,6 +4068,8 @@ int mlx5_devlink_eswitch_mode_set(struct devlink *dev= link, u16 mode, =20 if (mlx5_mode =3D=3D MLX5_ESWITCH_LEGACY) esw->dev->priv.flags |=3D MLX5_PRIV_FLAGS_SWITCH_LEGACY; + if (mlx5_mode =3D=3D MLX5_ESWITCH_OFFLOADS) + esw->dev->priv.flags &=3D ~MLX5_PRIV_FLAGS_SWITCH_LEGACY; mlx5_eswitch_disable_locked(esw); if (mlx5_mode =3D=3D MLX5_ESWITCH_OFFLOADS) { if (mlx5_devlink_trap_get_num_active(esw->dev)) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AB3423DE14A; Sat, 28 Feb 2026 17:41:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300460; cv=none; b=ASIxOtbE4qw2TwZNI8GVv2joeb2iJ9Z8MtB/ltiiwoagMawoU/NcPo8Rrd8mpsd+90gxAQkh3tYS3TmXainzLvGpuDmjuZsdZKX9Bc+Iq1dGSU3h9ejEPjIb2MuUzP/p6CX3SpZUD91tu+yK7pAPB4J1iXFd9/RLomZ4Xwp6hmw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300460; c=relaxed/simple; bh=dgFpN3XHNCBHH2zfZ7BwvQ0zx2JH/3/1eleSXZHaDG8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IJcOrp439JXfuNHPUIqi+vz08hPBwLrsfLMaKQcYiNggryWyVd/y6oSDA9n3vguMzQYYW4JCENkiz+6/T3VKt2F07hSIBOPEpc2IGIWrDK2tI1qIxvQvqyRHOOEqKmIKpJyASQViURluJUc0kYWcAy0gMTahlp/Vs6DmTwfbo8E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IHJyX7NT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IHJyX7NT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7870EC19423; Sat, 28 Feb 2026 17:40:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300460; bh=dgFpN3XHNCBHH2zfZ7BwvQ0zx2JH/3/1eleSXZHaDG8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IHJyX7NT10sgMwUnA1ATZJNxx2SOyvMxCTK+85eb5VQJoTe4fgWNgyPLR7P4QMg2c TvgHouxi0moDbThYnfAHtXo9Ytq42CTWRrEdyX1AfO5U2i18D4Cue9oeC/kbrjt8Hk 7kAqjlcAycP200xoYL4G+2np6uEyPWys4Gu4mTI0GwKAsde4nrVQVLl7ann3CvH/Hb vv43kwgCmOY/7D9cDQrEjQwqeT60f+7XubgtG1R51x3cpRVmBIRV06/BfwkFP2om5Y gL6SiqwCAcS4KOZ7K6tQjfnYDcWj+g6r/92AV2VE3NfeAtjW+gND//6Ov00Ermq7rI NE5/ME5+Z7yHg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shay Drory , Mark Bloch , Tariq Toukan , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 499/844] net/mlx5: Fix missing devlink lock in SRIOV enable error path Date: Sat, 28 Feb 2026 12:26:52 -0500 Message-ID: <20260228173244.1509663-500-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shay Drory [ Upstream commit 60253042c0b87b61596368489c44d12ba720d11c ] The cited commit miss to add locking in the error path of mlx5_sriov_enable(). When pci_enable_sriov() fails, mlx5_device_disable_sriov() is called to clean up. This cleanup function now expects to be called with the devlink instance lock held. Add the missing devl_lock(devlink) and devl_unlock(devlink) Fixes: 84a433a40d0e ("net/mlx5: Lock mlx5 devlink reload callbacks") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/mellanox/mlx5/core/sriov.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sriov.c b/drivers/net/= ethernet/mellanox/mlx5/core/sriov.c index a2fc937d54617..172862a70c70d 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/sriov.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/sriov.c @@ -193,7 +193,9 @@ static int mlx5_sriov_enable(struct pci_dev *pdev, int = num_vfs) err =3D pci_enable_sriov(pdev, num_vfs); if (err) { mlx5_core_warn(dev, "pci_enable_sriov failed : %d\n", err); + devl_lock(devlink); mlx5_device_disable_sriov(dev, num_vfs, true, true); + devl_unlock(devlink); } return err; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C7A6F3DE166; Sat, 28 Feb 2026 17:41:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300461; cv=none; b=K1dgZXWBqlHfAO/WpwquRldURY/ItZJgwYv1KbmAkLRuESLckiMGzgji19V2J1JXMU9Qx3LVqv0OnGJKki9fNzzZfhSbgIAI/NmeuurnnUlmFQ95M3GEQEh+GP9cOXcrOv9sj9StYYI8mHlyi/Kak1K9X9+Mv7QRvYx0QybKDIY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300461; c=relaxed/simple; bh=m8rcSrTq8JiI7juCypbu6cgYnNFLbEXxQCOdNeq9dtY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oGReH5b8e7+XsVT1SiojUAnQ6xN/gNX27Zo4DPay1EX81itEM0hnIJvmny3dPtJPEz3/MbdafOCaalgorStDFtoeMQ5G/iMVL3SPeWtT7DGBweo97M9hhKfkY9UYb8o7pBDDJ01BN3OPJxXCOX1387ldjFpmaI5E8JeiA0XVgfo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CkIgc0Cb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CkIgc0Cb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF4D4C19423; Sat, 28 Feb 2026 17:41:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300461; bh=m8rcSrTq8JiI7juCypbu6cgYnNFLbEXxQCOdNeq9dtY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CkIgc0Cb+WNJNHVLPH3KZNMUfQf1BRkQrbvYmSpfNBEW4E38WfTCNkxc+crFCwRyH Knbzdbd+npd7Z99rH2lE1ia9BmdM2r+oXk7LNx5jviLsbPuidz4Sy8CzeaLizklhjQ kPHy9/3v438IyuaV877ru77CosjzKoR2QrcN4mbGlTiFDFcHCp07g3uDt8WILy2xyb yEI+v/J0Zf+uMNhpLz2AwnZk1r9MFNxXW4fmhZBgTovyrY80Mv9sUb8w2cYWyvnNeI Z0z48Bw9M5PbKQc4z7t8hyDRoG2YWKodsvkiBjgHEdbifvjjpngC3TkX/PvM2iGI5L FYlJ0rYvPOLZA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jianbo Liu , Leon Romanovsky , Tariq Toukan , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 500/844] net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query Date: Sat, 28 Feb 2026 12:26:53 -0500 Message-ID: <20260228173244.1509663-501-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jianbo Liu [ Upstream commit 859380694f434597407632c29f30fdb5e763e6cc ] Fix a "scheduling while atomic" bug in mlx5e_ipsec_init_macs() by replacing mlx5_query_mac_address() with ether_addr_copy() to get the local MAC address directly from netdev->dev_addr. The issue occurs because mlx5_query_mac_address() queries the hardware which involves mlx5_cmd_exec() that can sleep, but it is called from the mlx5e_ipsec_handle_event workqueue which runs in atomic context. The MAC address is already available in netdev->dev_addr, so no need to query hardware. This avoids the sleeping call and resolves the bug. Call trace: BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200 __schedule+0x7ab/0xa20 schedule+0x1c/0xb0 schedule_timeout+0x6e/0xf0 __wait_for_common+0x91/0x1b0 cmd_exec+0xa85/0xff0 [mlx5_core] mlx5_cmd_exec+0x1f/0x50 [mlx5_core] mlx5_query_nic_vport_mac_address+0x7b/0xd0 [mlx5_core] mlx5_query_mac_address+0x19/0x30 [mlx5_core] mlx5e_ipsec_init_macs+0xc1/0x720 [mlx5_core] mlx5e_ipsec_build_accel_xfrm_attrs+0x422/0x670 [mlx5_core] mlx5e_ipsec_handle_event+0x2b9/0x460 [mlx5_core] process_one_work+0x178/0x2e0 worker_thread+0x2ea/0x430 Fixes: cee137a63431 ("net/mlx5e: Handle ESN update events") Signed-off-by: Jianbo Liu Reviewed-by: Leon Romanovsky Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/dri= vers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c index 9c7064187ed0f..f03507a522b4f 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c @@ -259,7 +259,6 @@ static void mlx5e_ipsec_init_limits(struct mlx5e_ipsec_= sa_entry *sa_entry, static void mlx5e_ipsec_init_macs(struct mlx5e_ipsec_sa_entry *sa_entry, struct mlx5_accel_esp_xfrm_attrs *attrs) { - struct mlx5_core_dev *mdev =3D mlx5e_ipsec_sa2dev(sa_entry); struct mlx5e_ipsec_addr *addrs =3D &attrs->addrs; struct net_device *netdev =3D sa_entry->dev; struct xfrm_state *x =3D sa_entry->x; @@ -276,7 +275,7 @@ static void mlx5e_ipsec_init_macs(struct mlx5e_ipsec_sa= _entry *sa_entry, attrs->type !=3D XFRM_DEV_OFFLOAD_PACKET) return; =20 - mlx5_query_mac_address(mdev, addr); + ether_addr_copy(addr, netdev->dev_addr); switch (attrs->dir) { case XFRM_DEV_OFFLOAD_IN: src =3D attrs->dmac; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08B733DD743; Sat, 28 Feb 2026 17:41:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300463; cv=none; b=hHuWLsBrys9CboFmvEx6N77PbnXNLLcWQ5LLMlytA9M9DgjasZjwqBfCJEP9tfHZORrARIABjq8fvjtCecDVMCk6DichysYO1+mcojck++Q6HQ4JT96qlXH37UExq95EE9P3o2s5/afnXwmE0klzLRDhmegIr8S3HzMaOuL+kP8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300463; c=relaxed/simple; bh=J78dsazIkoKl/QHeY1XsBXrk/kkW+ncj5rTqse0vuoc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b+AOUw5yMz7pkAKqEL4UBv2/rn/UcEv+JvdBXLHPuBQMvGlNA3jxvtbQok0S78m3V6AP/GlSUoZFixHRU5jxTKOmqHLLRLtRnysM7RHTCSIYlDdP15Q3VWX0lnh28GUC+qprfEoo2pNSexgTeeFE/D+yQpOMKlk5Uuh6rkollaI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ROAUf7jV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ROAUf7jV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04425C19425; Sat, 28 Feb 2026 17:41:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300462; bh=J78dsazIkoKl/QHeY1XsBXrk/kkW+ncj5rTqse0vuoc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ROAUf7jVdZ+6xtY88a6QnfH4phHkUAa2KG6mN/tUU9pWtRwH4bi0fyXAG4JzGWg2u 1qWP7+evl2/YS/4VP3Aul9kCEz/rticXrVX2h21zHreqTHw17ESvCa2VXkP7ZVFjJa VRKpcvahp6pcgAdvpotqTUkusNLLUci97Gm8iYn7vYDpz3iJB+UgnLYwz3MsxhFJGl T/LzoaUyVP/l9NF+KvXRkxc0XIl/rg0zfy+L5Zj09yCKu8DAosp2KgKdU02XR2/yWl tiQkf0ZGj5k8Qtceq0qOljStxJv26Kq2tNXRz52s+ZSeApDDCJVznDecIwp1lx+Xux TX+kZfUIMSIFQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jakub Kicinski , Eric Dumazet , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 501/844] net: consume xmit errors of GSO frames Date: Sat, 28 Feb 2026 12:26:54 -0500 Message-ID: <20260228173244.1509663-502-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jakub Kicinski [ Upstream commit 7aa767d0d3d04e50ae94e770db7db8197f666970 ] udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\ snd_nxt "x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link). Link: https://lore.kernel.org/CANn89iJcLepEin7EtBETrZ36bjoD9LrR=3Dk4cfwWh04= 6GB+4f9A@mail.gmail.com Fixes: 1f59533f9ca5 ("qdisc: validate frames going through the direct_xmit = path") Signed-off-by: Jakub Kicinski Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260223235100.108939-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/core/dev.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 60a26208cbd87..062415cc3e5a4 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4818,6 +4818,8 @@ int __dev_queue_xmit(struct sk_buff *skb, struct net_= device *sb_dev) * to -1 or to their cpu id, but not to our id. */ if (READ_ONCE(txq->xmit_lock_owner) !=3D cpu) { + bool is_list =3D false; + if (dev_xmit_recursion()) goto recursion_alert; =20 @@ -4828,17 +4830,28 @@ int __dev_queue_xmit(struct sk_buff *skb, struct ne= t_device *sb_dev) HARD_TX_LOCK(dev, txq, cpu); =20 if (!netif_xmit_stopped(txq)) { + is_list =3D !!skb->next; + dev_xmit_recursion_inc(); skb =3D dev_hard_start_xmit(skb, dev, txq, &rc); dev_xmit_recursion_dec(); - if (dev_xmit_complete(rc)) { - HARD_TX_UNLOCK(dev, txq); - goto out; - } + + /* GSO segments a single SKB into + * a list of frames. TCP expects error + * to mean none of the data was sent. + */ + if (is_list) + rc =3D NETDEV_TX_OK; } HARD_TX_UNLOCK(dev, txq); + if (!skb) /* xmit completed */ + goto out; + net_crit_ratelimited("Virtual device %s asks to queue packet!\n", dev->name); + /* NETDEV_TX_BUSY or queue was stopped */ + if (!is_list) + rc =3D -ENETDOWN; } else { /* Recursion is detected! It is possible, * unfortunately @@ -4846,10 +4859,10 @@ int __dev_queue_xmit(struct sk_buff *skb, struct ne= t_device *sb_dev) recursion_alert: net_crit_ratelimited("Dead loop on virtual device %s, fix it urgently!\= n", dev->name); + rc =3D -ENETDOWN; } } =20 - rc =3D -ENETDOWN; rcu_read_unlock_bh(); =20 dev_core_stats_tx_dropped_inc(dev); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C29073DEA82; Sat, 28 Feb 2026 17:41:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300463; cv=none; b=QMZHojdvOnk8hW3RvGcBIUkn03JvonONpS63nsMD9LDXCAGpdryJEsF49PgnxoG+6o5du0ZiGV4XEvC8o2Hpayg95DMp1JU7CK0g6FmP+4fj0lJlnPCPVGEhrMIlJWs0JTxmiobm30xFXO/hWCL0qf+b4qIvfjhjE13OhlTumZ0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300463; c=relaxed/simple; bh=NRKqTnUJObOPjyQErjImIDJZ46r1K3jPKEhgdD/B0tc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ThE1gAKkXpkXmDUgyRU0fi/gL0DwZ4PgkUOhs5qs/Bev2IscUeUut3+j3QmgbznisA8Q9L94PBz2aiyi6Up6LDo94C1l8v/J5Up4z0FLkhAzsU5SVMHME8Hundnp/MdHBSXk5ayhynmmVxbvV6ifO6s4fTgs5gxC89zt7bW3C20= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sa7WPEdk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sa7WPEdk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED124C19424; Sat, 28 Feb 2026 17:41:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300463; bh=NRKqTnUJObOPjyQErjImIDJZ46r1K3jPKEhgdD/B0tc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sa7WPEdkHOe4P6Cd2PBHDbgQllrW4gruCAHwOex29dsya79vtJmd/4NLcuAZErG2E 8jffLrPc73A1m1jBWqLIvxV3wbivg2u6Igd2ejy5cbEOdhk4KpykYjkVrhK92tNEny hvu0zQJvpiCM81FrrXZfsy0uoCWcNWHKk8oZxHHdCRhBumAsKs/MxdO+exXIZC4IIj WssW+5sf5pwAyPcW5feKZCVTuCxNkQtIREpxulh3N/h3otol3hNmTQSWAwP4c4zFDL UUtC8KJJuOFsrZh7Mrw28pKibJE9SQGbUgH++3f5Tyz7qtHYxk5DbUWK4P3+2N6w/0 C+46EJPMDyXVQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Junrui Luo , Ioana Ciornei , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 502/844] dpaa2-switch: validate num_ifs to prevent out-of-bounds write Date: Sat, 28 Feb 2026 12:26:55 -0500 Message-ID: <20260228173244.1509663-503-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Junrui Luo [ Upstream commit 8a5752c6dcc085a3bfc78589925182e4e98468c5 ] The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >=3D 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs =3D=3D DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >=3D because num_ifs =3D=3D DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >=3D 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |=3D ... Fixes: 539dda3c5d19 ("staging: dpaa2-switch: properly setup switching domai= ns") Signed-off-by: Junrui Luo Reviewed-by: Ioana Ciornei Link: https://patch.msgid.link/SYBPR01MB78812B47B7F0470B617C408AAF74A@SYBPR= 01MB7881.ausprd01.prod.outlook.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c b/drivers/= net/ethernet/freescale/dpaa2/dpaa2-switch.c index 66240c340492c..78e21b46a5ba8 100644 --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c @@ -3034,6 +3034,13 @@ static int dpaa2_switch_init(struct fsl_mc_device *s= w_dev) goto err_close; } =20 + if (ethsw->sw_attr.num_ifs >=3D DPSW_MAX_IF) { + dev_err(dev, "DPSW num_ifs %u exceeds max %u\n", + ethsw->sw_attr.num_ifs, DPSW_MAX_IF); + err =3D -EINVAL; + goto err_close; + } + err =3D dpsw_get_api_version(ethsw->mc_io, 0, ðsw->major, ðsw->minor); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB25C3DEA9D; Sat, 28 Feb 2026 17:41:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300464; cv=none; b=IrfDkn7XFUPGV25oogvpzpz16aZIlxFepXDEz9Jw6dUcmr2+4DYWpiSOdWyzUCvJ/sonNXYRkx7PSBpAV+jmVSVOyyQBc8Bg2FcN8Rsf1QLx+FQrosv90kBHdmkTbyMx5dNS8ZIAQQ5W/uYXnGXuHpI0KjUAlbpcnamFoz+NWFE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300464; c=relaxed/simple; bh=NjVMZIFF01Ct9/8k1rhQgQ8mLN3iYbuKfSR59VHi294=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=le3AbO57d4mZaC0sOCTY5mh2I5qn7DTYHvyyYvdzX3OB3cnGpeekbTr4V/aJ9hbVs1vYELvn81M/t8l8c58MPmZErACtQYdJOToHVGFxIVzVj9McwZKo+KgarM8q2TsJWxpu3pJ0sTuVSQkrIWutOGh20/HW0dvjGeWApgEH65Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hKj+f8Rm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hKj+f8Rm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF7D7C116D0; Sat, 28 Feb 2026 17:41:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300464; bh=NjVMZIFF01Ct9/8k1rhQgQ8mLN3iYbuKfSR59VHi294=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hKj+f8RmN8TwedLYoZ8XorqkdCxWJg0hUaO381KfV9DoYkK17zfk0oAEdAzSfwvDv w27cUEGQDWqyJVisK6i8BYZc7KxVpJxHYK5RdqaxTlsizmefKFDIgRYomC5KGw7qgW chtEvW6sV+pzg0cDAfTMn+CApcM75qXiMOIi0AsgWdjuOg0yXlG+GkFKQa1ShTqUAN Q+NMCME89oY/FZw7a33i/Wlus2g0hegkFk3mAKY/EHfSGIjbSsR2X1kTqtIvM0FJjw VbmMrPKZuAsyQYXxQoh5qUF9kfKBlm2TR5j1UVamXHPOfeVe+g0LI14ebl/q/8ZkC2 OtChCADGIpCQg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vahagn Vardanian , Florian Westphal , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 503/844] netfilter: nf_conntrack_h323: fix OOB read in decode_choice() Date: Sat, 28 Feb 2026 12:26:56 -0500 Message-ID: <20260228173244.1509663-504-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vahagn Vardanian [ Upstream commit baed0d9ba91d4f390da12d5039128ee897253d60 ] In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len =3D 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len =3D get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur =3D=3D bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len(). Fixes: ec8a8f3c31dd ("netfilter: nf_ct_h323: Extend nf_h323_error_boundary = to work on bits as well") Signed-off-by: Vahagn Vardanian Signed-off-by: Florian Westphal Link: https://patch.msgid.link/20260225130619.1248-2-fw@strlen.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/netfilter/nf_conntrack_h323_asn1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/netfilter/nf_conntrack_h323_asn1.c b/net/netfilter/nf_conn= track_h323_asn1.c index 540d97715bd23..62aa22a078769 100644 --- a/net/netfilter/nf_conntrack_h323_asn1.c +++ b/net/netfilter/nf_conntrack_h323_asn1.c @@ -796,7 +796,7 @@ static int decode_choice(struct bitstr *bs, const struc= t field_t *f, =20 if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); - if (nf_h323_error_boundary(bs, len, 0)) + if (nf_h323_error_boundary(bs, 2, 0)) return H323_ERROR_BOUND; len =3D get_len(bs); if (nf_h323_error_boundary(bs, len, 0)) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFC6D3DE166; Sat, 28 Feb 2026 17:41:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300465; cv=none; b=MkJILXwzapw9U171zxbC9h24NqmJfjhUhmi0/pPep0kMhuj4oH61niF0vJYg4owDt6x/NUC7MXiVncJY0IjW9izuipyf68i0ON8ohn6v6Fj6/izPmlqbpyQhbDA7YusJK3lJC+GT2nhcUWVelpxafb7zemGJ9qzhhcTPjR+KVgA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300465; c=relaxed/simple; bh=VszvAGQGexyAPXulfykvBTiopVRWbgzyGHF2T03Iu68=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=svYjhNtrBdmgpjWy4t3EExwNsQn4Oyt74IlrqVBKJmBtEG9IpyRc51daztbawXOuJXXUvQkhGe/C2vMrdEeIsRadRg7cmbT9OotqwoZy1F6sBK2Adf8bbGiRdt+ANpMvHECJEkKNTgcHr/EDFTDLc7DZWD2IffWyzbpS+AJf7Ss= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gxT1YWKP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gxT1YWKP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8295C19425; Sat, 28 Feb 2026 17:41:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300465; bh=VszvAGQGexyAPXulfykvBTiopVRWbgzyGHF2T03Iu68=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gxT1YWKPxatP8aT+MXaHrJc8XL8Rno9q6GcVZ90mkZ5wOkeCTwlvo9faVkgEgubhA M5DwBSuPV94TAi1kMOkfZATum9rqaD8IgLQeugR4aes7DDll184HAigJ7PIRkR+3Vq 6DYYhGuqgl3vSUtLZvanD3f9voaaZWJSaVb6f9hJ43fBB9Z9eIdgD9sGFJiSzZ1yBf tSGdslOuuRsuQoIggBccAfdRfJlyqKJLVSj2Hy7G7gGvcIc8HolmXAzpnNXJdgIZ+A BoGAl+B7BvoHyzuf0G5PA/Z0g8vyZpk1op4c/XAB5DobLTXltAceWGhLj4B/2C9t/n OWkwcFLYEg2rw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yazen Ghannam , Michal Pecio , "Borislav Petkov (AMD)" , Ingo Molnar , Ricardo Neri , Sasha Levin Subject: [PATCH 6.19 504/844] x86/acpi/boot: Correct acpi_is_processor_usable() check again Date: Sat, 28 Feb 2026 12:26:57 -0500 Message-ID: <20260228173244.1509663-505-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yazen Ghannam [ Upstream commit adbf61cc47cb72b102682e690ad323e1eda652c2 ] ACPI v6.3 defined a new "Online Capable" MADT LAPIC flag. This bit is used in conjunction with the "Enabled" MADT LAPIC flag to determine if a CPU can be enabled/hotplugged by the OS after boot. Before the new bit was defined, the "Enabled" bit was explicitly described like this (ACPI v6.0 wording provided): "If zero, this processor is unusable, and the operating system support will not attempt to use it" This means that CPU hotplug (based on MADT) is not possible. Many BIOS implementations follow this guidance. They may include LAPIC entries in MADT for unavailable CPUs, but since these entries are marked with "Enabled=3D0" it is expected that the OS will completely ignore these entries. However, QEMU will do the same (include entries with "Enabled=3D0") for the purpose of allowing CPU hotplug within the guest. Comment from QEMU function pc_madt_cpu_entry(): /* ACPI spec says that LAPIC entry for non present * CPU may be omitted from MADT or it must be marked * as disabled. However omitting non present CPU from * MADT breaks hotplug on linux. So possible CPUs * should be put in MADT but kept disabled. */ Recent Linux topology changes broke the QEMU use case. A following fix for the QEMU use case broke bare metal topology enumeration. Rework the Linux MADT LAPIC flags check to allow the QEMU use case only for guests and to maintain the ACPI spec behavior for bare metal. Remove an unnecessary check added to fix a bare metal case introduced by the QEMU "fix". [ bp: Change logic as Michal suggested. ] [ mingo: Removed misapplied -stable tag. ] Fixes: fed8d8773b8e ("x86/acpi/boot: Correct acpi_is_processor_usable() che= ck") Fixes: f0551af02130 ("x86/topology: Ignore non-present APIC IDs in a presen= t package") Closes: https://lore.kernel.org/r/20251024204658.3da9bf3f.michal.pecio@gmai= l.com Reported-by: Michal Pecio Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Tested-by: Michal Pecio Tested-by: Ricardo Neri Link: https://lore.kernel.org/20251111145357.4031846-1-yazen.ghannam@amd.com Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/kernel/acpi/boot.c | 12 ++++++++---- arch/x86/kernel/cpu/topology.c | 15 --------------- 2 files changed, 8 insertions(+), 19 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 9fa321a95eb33..d6138b2b633a3 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -35,6 +35,7 @@ #include #include #include +#include =20 #include "sleep.h" /* To include x86_acpi_suspend_lowlevel */ static int __initdata acpi_force =3D 0; @@ -164,11 +165,14 @@ static bool __init acpi_is_processor_usable(u32 lapic= _flags) if (lapic_flags & ACPI_MADT_ENABLED) return true; =20 - if (!acpi_support_online_capable || - (lapic_flags & ACPI_MADT_ONLINE_CAPABLE)) - return true; + if (acpi_support_online_capable) + return lapic_flags & ACPI_MADT_ONLINE_CAPABLE; =20 - return false; + /* + * QEMU expects legacy "Enabled=3D0" LAPIC entries to be counted as usable + * in order to support CPU hotplug in guests. + */ + return !hypervisor_is_type(X86_HYPER_NATIVE); } =20 static int __init diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index f55ea3cdbf88e..23190a786d310 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -27,7 +27,6 @@ #include =20 #include -#include #include #include #include @@ -236,20 +235,6 @@ static __init void topo_register_apic(u32 apic_id, u32= acpi_id, bool present) cpuid_to_apicid[cpu] =3D apic_id; topo_set_cpuids(cpu, apic_id, acpi_id); } else { - u32 pkgid =3D topo_apicid(apic_id, TOPO_PKG_DOMAIN); - - /* - * Check for present APICs in the same package when running - * on bare metal. Allow the bogosity in a guest. - */ - if (hypervisor_is_type(X86_HYPER_NATIVE) && - topo_unit_count(pkgid, TOPO_PKG_DOMAIN, phys_cpu_present_map)) { - pr_info_once("Ignoring hot-pluggable APIC ID %x in present package.\n", - apic_id); - topo_info.nr_rejected_cpus++; - return; - } - topo_info.nr_disabled_cpus++; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1612D3DF2D6; Sat, 28 Feb 2026 17:41:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300467; cv=none; b=TspaNUWIJLmhoMEKpp85eb+u7c5r46tdjB/VGyq3ecgHmXFwg55o+UAS0ylcAHj4ArTOqDXRRsshXBguV1aMHEZPWF+v+yW6Cw4gdqLL2I0xs7nqbHPsD8nqeE8QM27jLip13soFqOlA6bY2Iu5yfNg9z8xKtC/ihPU4RkjtKI0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300467; c=relaxed/simple; bh=g/ldiWZ7ZtRtUsTGWptXHCGhnyIJmR/pakE7Kon9wQU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LSmfGPEwEPvPFCY4pXi2jsdt3bmpaRGslWz81OKSlWIwc+6a/uroXpl8NYE6p4OjsNahcE8MiNH1I9X5MCC+iyyfR5WtNq4+KGzsTg5fWhNYvcvSLTe266plMcWWXkEia513x13T8hnuh0LAJzpmkDfjQOi9W5D7YLkg2OAvmOU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p33qvdKL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p33qvdKL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2133FC19425; Sat, 28 Feb 2026 17:41:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300466; bh=g/ldiWZ7ZtRtUsTGWptXHCGhnyIJmR/pakE7Kon9wQU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p33qvdKLsrUzJUzUqojWN4n2HROfuea6GbiENnd9MBrs3GuhagK+EdjMl54FfUydo yvo3Vagbu+ESW92fyon4hBYdj/NN1cKY6ZgF3D/azIzLhtntyrtKUfG3yELSFG1m1Z KYAq+ZXee+yKLGyczZkstn/hoAIBDR7MIcXekbvRziNySakTK0dI74mkVkmxh7dUNv Qn06f5eU/e6iplUR9VTADnjXTb1XjcITU+xuKL7roC71PQ0gl8jYFNstcymyeqjSQQ Uj6C01/WcPFiOLpM92pEX3pWrfhrnp1lwhQvscJSukcYwN3OLINxxgsnSzMLOptdXW nW/H5AMcyExAA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gui-Dong Han , Mathieu Poirier , Sasha Levin Subject: [PATCH 6.19 505/844] rpmsg: core: fix race in driver_override_show() and use core helper Date: Sat, 28 Feb 2026 12:26:58 -0500 Message-ID: <20260228173244.1509663-506-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gui-Dong Han [ Upstream commit 42023d4b6d2661a40ee2dcf7e1a3528a35c638ca ] The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code. Fixes: 39e47767ec9b ("rpmsg: Add driver_override device attribute for rpmsg= _device") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Link: https://lore.kernel.org/r/20251202174948.12693-1-hanguidong02@gmail.c= om Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/rpmsg/rpmsg_core.c | 66 ++++++++++++++++---------------------- 1 file changed, 27 insertions(+), 39 deletions(-) diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c index 5d661681a9b6c..96964745065b1 100644 --- a/drivers/rpmsg/rpmsg_core.c +++ b/drivers/rpmsg/rpmsg_core.c @@ -352,50 +352,38 @@ field##_show(struct device *dev, \ } \ static DEVICE_ATTR_RO(field); =20 -#define rpmsg_string_attr(field, member) \ -static ssize_t \ -field##_store(struct device *dev, struct device_attribute *attr, \ - const char *buf, size_t sz) \ -{ \ - struct rpmsg_device *rpdev =3D to_rpmsg_device(dev); \ - const char *old; \ - char *new; \ - \ - new =3D kstrndup(buf, sz, GFP_KERNEL); \ - if (!new) \ - return -ENOMEM; \ - new[strcspn(new, "\n")] =3D '\0'; \ - \ - device_lock(dev); \ - old =3D rpdev->member; \ - if (strlen(new)) { \ - rpdev->member =3D new; \ - } else { \ - kfree(new); \ - rpdev->member =3D NULL; \ - } \ - device_unlock(dev); \ - \ - kfree(old); \ - \ - return sz; \ -} \ -static ssize_t \ -field##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - struct rpmsg_device *rpdev =3D to_rpmsg_device(dev); \ - \ - return sprintf(buf, "%s\n", rpdev->member); \ -} \ -static DEVICE_ATTR_RW(field) - /* for more info, see Documentation/ABI/testing/sysfs-bus-rpmsg */ rpmsg_show_attr(name, id.name, "%s\n"); rpmsg_show_attr(src, src, "0x%x\n"); rpmsg_show_attr(dst, dst, "0x%x\n"); rpmsg_show_attr(announce, announce ? "true" : "false", "%s\n"); -rpmsg_string_attr(driver_override, driver_override); + +static ssize_t driver_override_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct rpmsg_device *rpdev =3D to_rpmsg_device(dev); + int ret; + + ret =3D driver_set_override(dev, &rpdev->driver_override, buf, count); + if (ret) + return ret; + + return count; +} + +static ssize_t driver_override_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct rpmsg_device *rpdev =3D to_rpmsg_device(dev); + ssize_t len; + + device_lock(dev); + len =3D sysfs_emit(buf, "%s\n", rpdev->driver_override); + device_unlock(dev); + return len; +} +static DEVICE_ATTR_RW(driver_override); =20 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr, char *buf) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA9483DF2ED; Sat, 28 Feb 2026 17:41:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300468; cv=none; b=GHExJsv60r9zxXWkXiBXcv51v6u1AASngznaklusPB7dLcxYxNy8746A0mjAJSRbrh846hGVjW/v7jRtlpYTm+3p/R+XuUHnbm6N2lHUhRawiRe7gA1hEXVQUPmIK2+/m5829iIrnPn8w3QiKfCsoof3I9O5G3bRqHOnhSdLg/4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300468; c=relaxed/simple; bh=lq9pbET41eTADkA04/3fMhGAUFXStKN4jarW1nJnt7Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b7ABc5g9G+6RudVrpXStxXQqSNmNMs811c3dG2n4Kt9/0LmI2Kztqxy788p2xrTk+1e0UNth3caw1LPLyFadT/iLKg1/jjRF3dRGQCOnX1Uodr/8nVIuh/sBlQuCFNPRoJMrlSb97BwbpfAfnkwi63lqyom4c8+cIZ7BXj0sm5Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YmIiuByW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YmIiuByW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 032DAC116D0; Sat, 28 Feb 2026 17:41:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300467; bh=lq9pbET41eTADkA04/3fMhGAUFXStKN4jarW1nJnt7Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YmIiuByWzaKq4IyOSTTT20n+pnyagG2VFULPl51Tafdoy+sHgrHZQPfzW9psK+b4i kdK3k6LT39sT4/UGY52ikIqjE2XOJK43Ds4gY9sJVs5/bPyJRaUTsghLfeo5xK45KX SAxA1zs3cZQpie1xnLbr0Vl7jOef8UYjsDsPincz3JY6215WBa+TIgER/sjNUWjbpv jnJunVvJZdz+FkU/0wbRnq3Jq40WviXV2EzqNz2Vs4L7/SP9KDm5xyjg0fERmsqeao NI4SpwVCNm4F84Ki+3XogJuTM+mDO1BIV378dRYbIn2981hN7rZnzrgEz6/YXi2K98 qQAMJfbUorGsA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chris Brandt , Hugo Villeneuve , Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.19 506/844] clk: renesas: rzg2l: Fix intin variable size Date: Sat, 28 Feb 2026 12:26:59 -0500 Message-ID: <20260228173244.1509663-507-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chris Brandt [ Upstream commit a00655d98cd885472c311f01dff3e668d1288d0a ] INTIN is a 12-bit register value, so u8 is too small. Fixes: 1561380ee72f ("clk: renesas: rzg2l: Add FOUTPOSTDIV clk support") Cc: stable@vger.kernel.org Reported-by: Hugo Villeneuve Closes: https://lore.kernel.org/20251107113058.f334957151d1a8dd94dd740b@hug= ovil.com Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251114193711.3277912-1-chris.brandt@renesa= s.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clk/renesas/rzg2l-cpg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/renesas/rzg2l-cpg.c b/drivers/clk/renesas/rzg2l-cp= g.c index c20ea1212b360..de58a960a922b 100644 --- a/drivers/clk/renesas/rzg2l-cpg.c +++ b/drivers/clk/renesas/rzg2l-cpg.c @@ -122,8 +122,8 @@ struct div_hw_data { =20 struct rzg2l_pll5_param { u32 pl5_fracin; + u16 pl5_intin; u8 pl5_refdiv; - u8 pl5_intin; u8 pl5_postdiv1; u8 pl5_postdiv2; u8 pl5_spread; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E27FB3DEAAE; Sat, 28 Feb 2026 17:41:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300469; cv=none; b=As+oryx8sU5ugSgXZGrGsA12GpsydfoZ96n92g7M/cEpA6aVRpuYjOgWuEsKaMSrX3szXiU25eftAWO9cJE0v/YxrvzIvI+12a1bq+/Nnnv4znffyH5+xr0DXScR6gFFCkLl6No0RrbdYFpWqYmLDLBF0a1bxYa7EpY4k++kO1E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300469; c=relaxed/simple; bh=p9/AMJMKGGl78rdr2Pf3AjZ6BpFq4chl9Uva3fCCGl4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RPKx0BgI7MwnGeQLvaYVQSbaq3fgORAI4rt6tpnt36BqnWuP+vE6KAsht3SZcdXVj68k2+pS3WIjLhQMjeNh2P9LBGaQN4gQ7DSxGVzPqZ/eH3a4/yzLQnjt3tMCCADN/KOqbDcWDBXAaBMjO+z05dAXb3MWxQqM8un+1YCSkE8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s6UMvXBx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s6UMvXBx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDB5AC19424; Sat, 28 Feb 2026 17:41:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300468; bh=p9/AMJMKGGl78rdr2Pf3AjZ6BpFq4chl9Uva3fCCGl4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s6UMvXBxHGKO42c0iWhX4B+NY5Ci7lDCxxScd+OavqvhBrlzKm1+DyXd8bneqlieY SPAozLm67GvjRyRJu1nmZcY4OX+Gr4MNYW8AEqxy3l/TtbElTwFHhHOGCkoD/cYuFl rC192z2vHly7/aNoTsdiqUYaVzCgsMRLSGebweGSzR+E4p0yVgYzU+ILn0xksnUZkn fGb32OgXUf8wTRP+IKHO54dwb+Bx1v/Fqax7Gc08M8Jl981tEI6cX/ydUUKBR3ogKE q/rgyOV1wvcv9TciI1oRknlJ4JDgFRbvnfbwcTQPiFx8YSwjXSaDHLR4TKwnjomIYE tvisWOzGBRomQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chris Brandt , stable@kernel.org, Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.19 507/844] clk: renesas: rzg2l: Select correct div round macro Date: Sat, 28 Feb 2026 12:27:00 -0500 Message-ID: <20260228173244.1509663-508-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chris Brandt [ Upstream commit f9451374dcfdfe669ee55b58ee6c11e8638980e4 ] Variable foutvco_rate is an unsigned long, not an unsigned long long. Cc: stable@kernel.org Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/CAMuHMdVf7dSeqAhtyxDCFuCheQRzwS-8996Rr2Ntui= 21uiBgdA@mail.gmail.com Fixes: dabf72b85f29 ("clk: renesas: rzg2l: Fix FOUTPOSTDIV clk") Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251114194529.3304361-1-chris.brandt@renesa= s.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clk/renesas/rzg2l-cpg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/renesas/rzg2l-cpg.c b/drivers/clk/renesas/rzg2l-cp= g.c index de58a960a922b..f670c6408ea15 100644 --- a/drivers/clk/renesas/rzg2l-cpg.c +++ b/drivers/clk/renesas/rzg2l-cpg.c @@ -572,8 +572,8 @@ rzg2l_cpg_get_foutpostdiv_rate(struct rzg2l_pll5_param = *params, foutvco_rate =3D div_u64(mul_u32_u32(EXTAL_FREQ_IN_MEGA_HZ * MEGA, (params->pl5_intin << 24) + params->pl5_fracin), params->pl5_refdiv) >> 24; - foutpostdiv_rate =3D DIV_ROUND_CLOSEST_ULL(foutvco_rate, - params->pl5_postdiv1 * params->pl5_postdiv2); + foutpostdiv_rate =3D DIV_ROUND_CLOSEST(foutvco_rate, + params->pl5_postdiv1 * params->pl5_postdiv2); =20 return foutpostdiv_rate; } --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C7A143DFC77; Sat, 28 Feb 2026 17:41:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300469; cv=none; b=BhgX2YZexhb0lSw7ulKV7pbEWBnaa2Q8dvtWtLP4ckimeewv0sSbOtYua3JjZP9M1SkiW0dKSlXQ1nBz/TCHbhIOIorXSFVyswYGDm/3RueOKJI4FWQ6heCAurgIcortO5gZWzSPd3vK6v1GkZMd0Q7MrZUEk2iOZJfj/VNKujw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300469; c=relaxed/simple; bh=6Y+xZCTR+Bzy3g0YLhogsNBKc2RpGqJPlFj0zQ0zzvA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I0z+LT9R8AjHpdz+jOxVIGr464W/oLhp511p2AIc3dYYUiaJQBjpVK5jbkFI1gXV/iog3hDE8Hsa/y+GkGEIiXZBBaoQGhfOMQf0dLlIQ1mG3+zpIGQkyqtxLjZauMStsbcuZpacerEXLTXaUMnv4lG2XhMWP0AH1+VEoxtaljA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DFgsNxsN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DFgsNxsN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5BD2C19423; Sat, 28 Feb 2026 17:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300469; bh=6Y+xZCTR+Bzy3g0YLhogsNBKc2RpGqJPlFj0zQ0zzvA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DFgsNxsNpyY471OoMpunMOJ9FBJYB8ws4Gue+cKzxI0o+375SpeTdJpLwVGJowpYQ 3N6ng6ApacXLuw0VCMBQxfap2HzRPye4XIxK8HNPuhXbdny7Fwc54jAP21qbdjQuk7 HnxHQyLSYwHNl/A+N8W3S31PlNeSvGECuBe/nnCUUjaMaQ5NinbQjhn+yOO4/RkSvC KpKwr0XZtflQZYBjWziVwbDAxqEuiR/jmEdQMz9vAtkcvh6RleduDsybnEKexPuoN0 FPPlXNP8WhtpUnZfLcCCl5xCfag390NXLiow6f3DEDFNKfgVaT0IUg4GiqGsSMkOo1 A4wi0VhITiWOw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mehdi Ben Hadj Khelifa , Viacheslav Dubeyko , Christian Brauner , Viacheslav Dubeyko , Sasha Levin Subject: [PATCH 6.19 508/844] hfsplus: ensure sb->s_fs_info is always cleaned up Date: Sat, 28 Feb 2026 12:27:01 -0500 Message-ID: <20260228173244.1509663-509-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mehdi Ben Hadj Khelifa [ Upstream commit 126fb0ce99431126b44a6c360192668c818f641f ] When hfsplus was converted to the new mount api a bug was introduced by changing the allocation pattern of sb->s_fs_info. If setup_bdev_super() fails after a new superblock has been allocated by sget_fc(), but before hfsplus_fill_super() takes ownership of the filesystem-specific s_fs_info data it was leaked. Fix this by freeing sb->s_fs_info in hfsplus_kill_super(). Cc: stable@vger.kernel.org Fixes: 432f7c78cb00 ("hfsplus: convert hfsplus to use the new mount api") Reported-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Signed-off-by: Christian Brauner Signed-off-by: Mehdi Ben Hadj Khelifa Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20251201222843.82310-3-mehdi.benhadjkhelifa= @gmail.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/hfsplus/super.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index 7f327b777ece8..942b8ff01ad07 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -350,8 +350,6 @@ static void hfsplus_put_super(struct super_block *sb) hfs_btree_close(sbi->ext_tree); kfree(sbi->s_vhdr_buf); kfree(sbi->s_backup_vhdr_buf); - call_rcu(&sbi->rcu, delayed_free); - hfs_dbg("finished\n"); } =20 @@ -656,7 +654,6 @@ static int hfsplus_fill_super(struct super_block *sb, s= truct fs_context *fc) out_unload_nls: unload_nls(sbi->nls); unload_nls(nls); - kfree(sbi); return err; } =20 @@ -715,10 +712,18 @@ static int hfsplus_init_fs_context(struct fs_context = *fc) return 0; } =20 +static void hfsplus_kill_super(struct super_block *sb) +{ + struct hfsplus_sb_info *sbi =3D HFSPLUS_SB(sb); + + kill_block_super(sb); + call_rcu(&sbi->rcu, delayed_free); +} + static struct file_system_type hfsplus_fs_type =3D { .owner =3D THIS_MODULE, .name =3D "hfsplus", - .kill_sb =3D kill_block_super, + .kill_sb =3D hfsplus_kill_super, .fs_flags =3D FS_REQUIRES_DEV, .init_fs_context =3D hfsplus_init_fs_context, }; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24E193DFC9E; Sat, 28 Feb 2026 17:41:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300471; cv=none; b=YZzLHD3u567qsfrTTCmNwrfHbhqdVkBtkRqkYfcTlD3HOWGkRXsKEL7R/lKR5K0extLvf5+5Fox6xT7FglLFsZTrYKzC9VXfL9xfI4kbIhRffswC6jroeqcfDKPyaxdKd76pmyLifcIE0OIspqjS/c3snsB3DbM/QrWhEmNeyLw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300471; c=relaxed/simple; bh=FcnjzuTrYxOdD1uVVsCw+4SQEAEj0Gn+2o0dyJvm8ks=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GFW1pH9lqnmwKHFdu7mfQJ77SQz+cigRCmXE6IeR523GROUCPalxM02QLANoXVvbYlNvl18Jqz6doTpmPEe4C2R1dcaZ06dax9zrK5cNxfj/qGWKbG7SfN1Bg7t6WZedmhr5xEa4mQEmulQWdKiXgLNizVKMEtA0qj5/Sg/HP3k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VTUpppNz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VTUpppNz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05A52C116D0; Sat, 28 Feb 2026 17:41:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300470; bh=FcnjzuTrYxOdD1uVVsCw+4SQEAEj0Gn+2o0dyJvm8ks=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VTUpppNzrXu8qIFRoaduKrzyPvZRjKrQj5G4nguGS+UIx/h5JxQN1wRncKQuuVGjb bDMpczKnUGJqH/a2Qbk1EY6I8JcneXKVMX1S3pcOK9vUuMYZ959U76KmqOCjjdTSKZ FXUY/wRnJz21gKhoPLQu6TGSwAkrvfxIq564gWnCrMYnilDR+9b7my0PCaMDRntsM2 xicmO1LtQiZsO98ZR3KQmI4dInpl3VYyXeaeYrztAHevaZRhZpxWpnHnrG5cvzq3jG TY3uBijT2+GHBahYmsy0eXJ0mAy3rQbaP5yL8LrurCxE5ENHNjxvRIKiRJHesP2QdE JLZUOI1Vs9sFA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Yong Wu , Miaoqian Lin , Krzysztof Kozlowski , Sasha Levin Subject: [PATCH 6.19 509/844] memory: mtk-smi: fix device leaks on common probe Date: Sat, 28 Feb 2026 12:27:02 -0500 Message-ID: <20260228173244.1509663-510-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit 6cfa038bddd710f544076ea2ef7792fc82fbedd6 ] Make sure to drop the reference taken when looking up the SMI device during common probe on late probe failure (e.g. probe deferral) and on driver unbind. Fixes: 47404757702e ("memory: mtk-smi: Add device link for smi-sub-common") Fixes: 038ae37c510f ("memory: mtk-smi: add missing put_device() call in mtk= _smi_device_link_common") Cc: stable@vger.kernel.org # 5.16: 038ae37c510f Cc: stable@vger.kernel.org # 5.16 Cc: Yong Wu Cc: Miaoqian Lin Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251121164624.13685-2-johan@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/memory/mtk-smi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c index 733e22f695ab7..dd6150d200e89 100644 --- a/drivers/memory/mtk-smi.c +++ b/drivers/memory/mtk-smi.c @@ -674,6 +674,7 @@ static int mtk_smi_larb_probe(struct platform_device *p= dev) err_pm_disable: pm_runtime_disable(dev); device_link_remove(dev, larb->smi_common_dev); + put_device(larb->smi_common_dev); return ret; } =20 @@ -917,6 +918,7 @@ static void mtk_smi_common_remove(struct platform_devic= e *pdev) if (common->plat->type =3D=3D MTK_SMI_GEN2_SUB_COMM) device_link_remove(&pdev->dev, common->smi_common_dev); pm_runtime_disable(&pdev->dev); + put_device(common->smi_common_dev); } =20 static int __maybe_unused mtk_smi_common_resume(struct device *dev) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB48E3E04A4; Sat, 28 Feb 2026 17:41:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300472; cv=none; b=UEIML/JFAYQ2oieBIlV8uLPd/yNSSl3K3Ut6ai6SAS7At0/+F0izjo52IwObzXsApjGzRBWmpBhH6n0UoCFH8sRLX+pcTJrHMy1kIPZUTxdpDv1bZ/H63n7Ee2Sy1GUejCcvi2pfJtq0tYdhzbA4hIVeoKm0U+6Lpza+uIByNjw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300472; c=relaxed/simple; bh=7mEMJvo5X8owgK7L/9oWkHE42x320z0Z8ypcbUH9IrE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ajIx64PaIj4yNZiU57RXPrZDnhmpLQqGSSANdHeYuZ6lFv38ioS/5/rKdQGXnettsBNmtjYIkvwbqiEICO956GPIwYabZdc9XuBpGTMa9tcP3h7KQ2MNP9uheFaWMOQkJcbLsMTF0CAm0Xc7Gh8yZw3gVSBxtaO83ce/C3j+fao= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fFUIlxjX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fFUIlxjX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14666C19424; Sat, 28 Feb 2026 17:41:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300471; bh=7mEMJvo5X8owgK7L/9oWkHE42x320z0Z8ypcbUH9IrE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fFUIlxjXeeuL2WqN9SJpu6S7/E2uujNmjlHnWs0sBo3RJaUMsLEbNcsFk14hjBACr uW1irAmhIdm9d2J2hTI3g6Ygqb8WjO+0v29sUMMpNwLufu5WAh2VUm78D7+63X056P NdDIRPuii2C6tPFnx/iadA39y9vik8bYLOEgBT0Pg4O/ZNtbErRKkESeApDuptS1rK 5QzNuTuVG03eINhZZLIcTvk0X9mZ7488wfxcyOlKX7gm0lJpWspIXX24pgJKFY3kf+ LLs5AkgCjDBkmclKTwLAobY1ninQjs4XNuXn+c7JVv0VzXa8VIAHclLmGldewTXSsU UGF2zoOnVXTyA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Yong Wu , Miaoqian Lin , Krzysztof Kozlowski , Sasha Levin Subject: [PATCH 6.19 510/844] memory: mtk-smi: fix device leak on larb probe Date: Sat, 28 Feb 2026 12:27:03 -0500 Message-ID: <20260228173244.1509663-511-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit 9dae65913b32d05dbc8ff4b8a6bf04a0e49a8eb6 ] Make sure to drop the reference taken when looking up the SMI device during larb probe on late probe failure (e.g. probe deferral) and on driver unbind. Fixes: cc8bbe1a8312 ("memory: mediatek: Add SMI driver") Fixes: 038ae37c510f ("memory: mtk-smi: add missing put_device() call in mtk= _smi_device_link_common") Cc: stable@vger.kernel.org # 4.6: 038ae37c510f Cc: stable@vger.kernel.org # 4.6 Cc: Yong Wu Cc: Miaoqian Lin Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251121164624.13685-3-johan@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/memory/mtk-smi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c index dd6150d200e89..3609bfd3c64be 100644 --- a/drivers/memory/mtk-smi.c +++ b/drivers/memory/mtk-smi.c @@ -685,6 +685,7 @@ static void mtk_smi_larb_remove(struct platform_device = *pdev) device_link_remove(&pdev->dev, larb->smi_common_dev); pm_runtime_disable(&pdev->dev); component_del(&pdev->dev, &mtk_smi_larb_component_ops); + put_device(larb->smi_common_dev); } =20 static int __maybe_unused mtk_smi_larb_resume(struct device *dev) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 077453E04C1; Sat, 28 Feb 2026 17:41:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300473; cv=none; b=RoihnyXHzu/SZ3VUM31qjvPxgKsk3dfcHSq4CqZ7MPfluk5lSxLTIOa2GMzIk4nTepX/YuyNC+vCb0ZurlVVmpVRjE1dcbMr3F2Qse3mMTplEJZR0euxBqE6qJ55Dsw4D+C4+lgp6klJ0JxYNNJo5i0Aa6aU827eFtxq/4Y8K3k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300473; c=relaxed/simple; bh=sRSClu2eF+jcLFV57f7tFFz9qyLvjcSA+nwo7d2RalU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MZL6PesQSbwAuqx02VSkzxPtbzXgZAQyayyxO5GtdOM6bQEBNdshaASzL9sgfLeFACPFOD1fa/t8cjZZE4135XXr2BWWCjvWiBAPj0AzRxxXRQPM/ah9ruakJEOCPU1WhI9xW2+FmtoCrkzLTWFYv00vFBhxc/etJIGDVVkP1Y0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kDIx5jag; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kDIx5jag" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21B7CC2BC9E; Sat, 28 Feb 2026 17:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300472; bh=sRSClu2eF+jcLFV57f7tFFz9qyLvjcSA+nwo7d2RalU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kDIx5jagKoAfkeCa7MAK6EOO+WEN0c7hYecQZp6NOGpINBzl753sGgYqF9Xp4LqvB GAQ1NAj7pKXCvYdHVs5qjf3/ADNqI/Yg0J2vobLz3XRuxzt/jMliJ8RJZVEEbKXF66 TjF4Ix+5m0OzN1r1SHWqYEMXg/uJIDFEV0tQZwpUchgP9QBseVvdSOtkZ4jQBO2Xzg OzjobXqPGCESPnM6BV9RruhVIbQx2YbOxGg3+3xdgu/7O+KYtxBUvMKsEdiWBNz/mZ suoutQFQVSa2sU6QBNMaitwEGZLzeBpkZ4yCiAQa/qo7wCfdEWnYmR51fMep73M/e5 IqZRm/PMvX1eA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Francesco Dolcini , Nishanth Menon , Sasha Levin Subject: [PATCH 6.19 511/844] arm64: dts: ti: am62p-verdin: Fix SD regulator startup delay Date: Sat, 28 Feb 2026 12:27:04 -0500 Message-ID: <20260228173244.1509663-512-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Francesco Dolcini [ Upstream commit de86dbc0fb00bd3773db4b05d9f5926f0faa2244 ] The power switch used to power the SD card interface might have more than 2ms turn-on time, increase the startup delay to 20ms to prevent failures. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Link: https://patch.msgid.link/20251209084126.33282-1-francesco@dolcini.it Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi b/arch/arm64/boot/= dts/ti/k3-am62p-verdin.dtsi index 5e050cbb9eaf3..ec9dd931fe922 100644 --- a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi @@ -112,7 +112,7 @@ reg_sd1_vmmc: regulator-sdhci1-vmmc { regulator-max-microvolt =3D <3300000>; regulator-min-microvolt =3D <3300000>; regulator-name =3D "+V3.3_SD"; - startup-delay-us =3D <2000>; + startup-delay-us =3D <20000>; }; =20 reg_sd1_vqmmc: regulator-sdhci1-vqmmc { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FA093DFC77; Sat, 28 Feb 2026 17:41:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300474; cv=none; b=Uy59xACCQo/RLccuNIWeXVBBcY3ejonTY0KG/iCk37ACcFsa9I2bYNIegZaHj6LMNFqoZobXBlPNGldjapGonYV/o7zbTUGV1R5gSk62+KnSrul9q+WDzuO2PiqZDfNNShjl3yqCqTnHyvFTP5qhtI6VUEWqX0fMhZgQWQfMGZI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300474; c=relaxed/simple; bh=9XEM5KECmNQtwp7tgi+FFNvVL4pDMPVGmBujC3r2VIo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rmlSPMOdDEZfC4Znj1E5fuLvoet97iX+Xn56p9JqV/TpT2L1PPQH3jxD1yV0OAZb1LpLC5rR9BlQdRzG/E6gb8Z0BFoH1PgU8EmR0VQZzD+Q3wvr0UI+QO76odj2PoGUlmXskntp7I2MU6rUR6QOi+wf24ADdXUCl2BYZci4elA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=raU7AH67; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="raU7AH67" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0437CC2BC87; Sat, 28 Feb 2026 17:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300473; bh=9XEM5KECmNQtwp7tgi+FFNvVL4pDMPVGmBujC3r2VIo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=raU7AH67VPvWjb7YfXcsc/Mk1GF5cNLJkNfbYef+z3xwgPpVxBicNu678RecclFwE UkmqAiC+31cNwcnFSsqh5Xs0Tj8/nSGDlTXEfkajOHVT6UWFou5sN+A4yy8cvP1WXl WNEYD1NOxZLFl06QADbh4oaFryYw1iC5SiparVHrxzQr3OV+hHrErWAveyetUnQATf jBiI9yVjvMiwMAHVi3sg3KxGvuMxq1k8gnxkE0zEu6XEmXviL/Tnc0axv/KF19tpPC Xbb0YB5KVSnq/CtJ+wIbFYdmtMk6PuBE4VGX9kWfqLU02JkqEGqft0SO1gUcJzwUdZ YvxLlhyQVVLJw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chia-I Wu , Boris Brezillon , Liviu Dudau , Steven Price , Sasha Levin Subject: [PATCH 6.19 512/844] drm/panthor: fix for dma-fence safe access rules Date: Sat, 28 Feb 2026 12:27:05 -0500 Message-ID: <20260228173244.1509663-513-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chia-I Wu [ Upstream commit efe24898485c5c831e629d9c6fb9350c35cb576f ] Commit 506aa8b02a8d6 ("dma-fence: Add safe access helpers and document the rules") details the dma-fence safe access rules. The most common culprit is that drm_sched_fence_get_timeline_name may race with group_free_queue. Signed-off-by: Chia-I Wu Reviewed-by: Boris Brezillon Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Cc: stable@vger.kernel.org # v6.17+ Signed-off-by: Steven Price Link: https://patch.msgid.link/20251204174545.399059-1-olvaffe@gmail.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/panthor/panthor_sched.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/pant= hor/panthor_sched.c index bd397d773d72b..5c55ba593b244 100644 --- a/drivers/gpu/drm/panthor/panthor_sched.c +++ b/drivers/gpu/drm/panthor/panthor_sched.c @@ -23,6 +23,7 @@ #include #include #include +#include =20 #include "panthor_devfreq.h" #include "panthor_device.h" @@ -939,6 +940,9 @@ static void group_release_work(struct work_struct *work) release_work); u32 i; =20 + /* dma-fences may still be accessing group->queues under rcu lock. */ + synchronize_rcu(); + for (i =3D 0; i < group->queue_count; i++) group_free_queue(group, group->queues[i]); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21FE73E0C4E; Sat, 28 Feb 2026 17:41:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300475; cv=none; b=IhJUfxUyiOHnIMR87FggNu4B7zmwjreBcSa3GcNMVd8EHvmRZfyG08VP3PoEqKgO5EU9cpjPeCYFL/Uthjf/UdGroQc+gi3rKSWpeIecRXyS7SKRibJ/aGhly6/siU+IkRH1wfk0cPRiWy1HNcjmFdONNLxt9iMe95hbU1SutEM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300475; c=relaxed/simple; bh=uTqbPw591zXdfTsTtnbae2IXUOtbUZZJRiNlboZWmbM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f40Gla8ApYYwPQ+S8tHn2sYXUoWNxablvPbAI7ew5IgiKTKBg8udUUGtMHLCEfgZ8mfXoWnvGtybW/27FRxtgQb4eAsvpHEOUdd7YiiSvvgc/UwW1pH9IdPHRI6Im87nrKZR0Wz1EliGdfGIZhKajiu3GIewEk9lWp3S9v8tgTQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fJW379T+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fJW379T+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 148B1C19423; Sat, 28 Feb 2026 17:41:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300475; bh=uTqbPw591zXdfTsTtnbae2IXUOtbUZZJRiNlboZWmbM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fJW379T+jO89UxQsw7oRR9Ng8M/khIEFYqJnoM3ooUc4GxOLzzvgaYHubNI0iDOT/ g9yCDjuBUBfel7eZeBnPEb18xpdCayou6GyLmxUx/jyglB8FwV8fDblggwWIHHWKjt d7Cd5rnnE5xSjQh6WTz9cD6zqrbrM4S5nsWRaDopbJgbZLRw2FbF4mzd2LypeCE1gl LV9mXG5qvjrEC1JxLnOCszf0sT3NZRcDYsxGaiL6R3mGFJdsplrirtcOUfX2A17Mkw s/Flp+bCiag5I8/5JzHJxco3mMXF9O/fMPG/AYsoIVdsxGD6Rq9gIDv+Haxr2xNc5y OLxwXCMsprB7w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Ujfalusi , Seppo Ingalsuo , Ranjani Sridharan , Bard Liao , Kai Vehmanen , Mark Brown , Sasha Levin Subject: [PATCH 6.19 513/844] ASoC: SOF: ipc4-control: If there is no data do not send bytes update Date: Sat, 28 Feb 2026 12:27:06 -0500 Message-ID: <20260228173244.1509663-514-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Ujfalusi [ Upstream commit 2fa74713744dc5e908fff851c20f5f89fd665fb7 ] When the bytes control have no data (payload) then there is no need to send an IPC message as there is nothing to send. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes contro= l get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-2-peter.ujfalusi@linux.i= ntel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/sof/ipc4-control.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/ipc4-control.c b/sound/soc/sof/ipc4-control.c index 976a4794d6100..0a05f66ec7d92 100644 --- a/sound/soc/sof/ipc4-control.c +++ b/sound/soc/sof/ipc4-control.c @@ -412,8 +412,16 @@ static int sof_ipc4_set_get_bytes_data(struct snd_sof_= dev *sdev, int ret =3D 0; =20 /* Send the new data to the firmware only if it is powered up */ - if (set && !pm_runtime_active(sdev->dev)) - return 0; + if (set) { + if (!pm_runtime_active(sdev->dev)) + return 0; + + if (!data->size) { + dev_dbg(sdev->dev, "%s: No data to be sent.\n", + scontrol->name); + return 0; + } + } =20 msg->extension =3D SOF_IPC4_MOD_EXT_MSG_PARAM_ID(data->type); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 684733E0C6E; Sat, 28 Feb 2026 17:41:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300476; cv=none; b=fhGPngikHFiQ9vqZg5jd7jZBqah0TgILtX3jS0fypr66K3MzcpwwosJ5q7jefVRu46hFkK9ucuy1cPIrpAk/7DycMLs5DDM0mnArtbim/zCMX2rtYbJlgUpHoYjzr6UcnSYeYywJTTJhUD+gJ7Ab/NYEPfSAujlAJSVgWKXbt4o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300476; c=relaxed/simple; bh=dkFO4AZNEeKNS+tIE3jT5PdA697aWRxvoKmc/4c31j4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DsStSCepYJEQhhwSanNTW0aUPZoLHyBvF80wiql1JN260Ge1UMSPli6kRhlAAZ3nMORUjEM2ezk92gMcPT5COwgNIOJeNSCBH7Zs6ALafKk4khxr5OpZ1tlVvqbEtpAD6maNV2W+pIT7EYKvvwpnIvPIAf4SfUCZ9zdpZYq4G1U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lTSLZkmH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lTSLZkmH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52BC0C116D0; Sat, 28 Feb 2026 17:41:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300476; bh=dkFO4AZNEeKNS+tIE3jT5PdA697aWRxvoKmc/4c31j4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lTSLZkmHUuNuTxIamgJgPYrG4KNEvziVP/S3v4OMaFwISJt0JmJyphUZ+WjL48SSW yxgPQhriJaNnN+Tj7VP4vnF/hyI0mnUFNXRXaiSRlGzn5CfvlMk2DFhF1Zci+gNd9H VsPhZ5IaNnZKJDNAvGpFbb6NlVxvWGlT3QUsjTw8n9Ou8yhiyqdBWb3dt75F11jD4J Y6NXUjTQf9j2+E9nlMuz5OGlIUtjWLnWZgzpKz0B88CygJNQ4jZ4kyLAA6fT2nGAYX ucmWxi5b9pCjSwzQzUgvUQXZYxsaK8/jkOvFCXFlEGF0ygPv1+OpLvANUQ5CDnRsDl hcYMYA6rz74Fg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Ujfalusi , Seppo Ingalsuo , Ranjani Sridharan , Bard Liao , Kai Vehmanen , Mark Brown , Sasha Levin Subject: [PATCH 6.19 514/844] ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls Date: Sat, 28 Feb 2026 12:27:07 -0500 Message-ID: <20260228173244.1509663-515-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Ujfalusi [ Upstream commit a653820700b81c9e6f05ac23b7969ecec1a18e85 ] The size of the data behind of scontrol->ipc_control_data for bytes controls is: [1] sizeof(struct sof_ipc4_control_data) + // kernel only struct [2] sizeof(struct sof_abi_hdr)) + payload The max_size specifies the size of [2] and it is coming from topology. Change the function to take this into account and allocate adequate amount of memory behind scontrol->ipc_control_data. With the change we will allocate [1] amount more memory to be able to hold the full size of data. Fixes: a382082ff74b ("ASoC: SOF: ipc4-topology: Add support for TPLG_CTL_BY= TES") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-3-peter.ujfalusi@linux.i= ntel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/sof/ipc4-topology.c | 35 +++++++++++++++++++++++++++-------- 1 file changed, 27 insertions(+), 8 deletions(-) diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c index d621e7914a73c..4854903654364 100644 --- a/sound/soc/sof/ipc4-topology.c +++ b/sound/soc/sof/ipc4-topology.c @@ -2870,22 +2870,41 @@ static int sof_ipc4_control_load_bytes(struct snd_s= of_dev *sdev, struct snd_sof_ struct sof_ipc4_msg *msg; int ret; =20 - if (scontrol->max_size < (sizeof(*control_data) + sizeof(struct sof_abi_h= dr))) { - dev_err(sdev->dev, "insufficient size for a bytes control %s: %zu.\n", + /* + * The max_size is coming from topology and indicates the maximum size + * of sof_abi_hdr plus the payload, which excludes the local only + * 'struct sof_ipc4_control_data' + */ + if (scontrol->max_size < sizeof(struct sof_abi_hdr)) { + dev_err(sdev->dev, + "insufficient maximum size for a bytes control %s: %zu.\n", scontrol->name, scontrol->max_size); return -EINVAL; } =20 - if (scontrol->priv_size > scontrol->max_size - sizeof(*control_data)) { - dev_err(sdev->dev, "scontrol %s bytes data size %zu exceeds max %zu.\n", - scontrol->name, scontrol->priv_size, - scontrol->max_size - sizeof(*control_data)); + if (scontrol->priv_size > scontrol->max_size) { + dev_err(sdev->dev, + "bytes control %s initial data size %zu exceeds max %zu.\n", + scontrol->name, scontrol->priv_size, scontrol->max_size); + return -EINVAL; + } + + if (scontrol->priv_size < sizeof(struct sof_abi_hdr)) { + dev_err(sdev->dev, + "bytes control %s initial data size %zu is insufficient.\n", + scontrol->name, scontrol->priv_size); return -EINVAL; } =20 - scontrol->size =3D sizeof(struct sof_ipc4_control_data) + scontrol->priv_= size; + /* + * The used size behind the cdata pointer, which can be smaller than + * the maximum size + */ + scontrol->size =3D sizeof(*control_data) + scontrol->priv_size; =20 - scontrol->ipc_control_data =3D kzalloc(scontrol->max_size, GFP_KERNEL); + /* Allocate the cdata: local struct size + maximum payload size */ + scontrol->ipc_control_data =3D kzalloc(sizeof(*control_data) + scontrol->= max_size, + GFP_KERNEL); if (!scontrol->ipc_control_data) return -ENOMEM; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 91AA148AE0D; Sat, 28 Feb 2026 17:41:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300477; cv=none; b=Ufw2DnYBi4fGoirN6RqgSMtB0D6ZZKdAG1LWnTw7G7Lsrk30hH+Eb2zf0KQRNDqZbthINCjGLBbtoAL77/f0zTR6XpV/8JC1iaDOy8vYCtlmXNpN+DKVQ0TmxPXXr8Nk636DuY49E6LEugCmfnHS/tA6CoIVdB01NZO2nlLI/aw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300477; c=relaxed/simple; bh=kU/f+89gQX8msH1ELgzNKPQu5/7ZsX59MFBTN+0lF0Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=S/YL1GHVfE9croA0FCPQFRjxRiIQL0Wt7jm7EKuonOdy0mA6XMp07gz6F6QiManJoItyBJjbjmG1O4CVBwyX/0FxL5SGmsKXILEzYAbDxxwmbdvD/ptaCrGr08K61LdTG6f84cpdx8l2+mpdl5oHVPwCiPbMHcnPypE9IW7E80Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=REA176Zf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="REA176Zf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 867AEC19425; Sat, 28 Feb 2026 17:41:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300477; bh=kU/f+89gQX8msH1ELgzNKPQu5/7ZsX59MFBTN+0lF0Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=REA176ZfPPd44zwGwlcnlGu6liHfjKAdY+MUDuFk5CQYEURO8IQpA+EGz1BtwiK9k Pkf5Vxey0q1/rMmF1R23odV4QH2X7ehbG5e4vxGENNoidk3VJMjubrF6Qjx9bAM4zp j62NryKzQ/1dsvWVByIHvhvbOgSUkLbYVFCldN8pXfs+nt+mM82R+SXBZ2bf2uhzVi j9mr5q2nxphp1Wh+QGEDODTCE+MCV/jYxUBnwjabBRGt8AI2ae/jOkz7n+m1QrS2+V iPr90nnB1rHcm8HNRMIxqwXHuHDJsx8p6awzHLho6BDAdxw0L6/gQcKenhRV4aSeFe hdIy8Su6dwyyQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Ujfalusi , Seppo Ingalsuo , Ranjani Sridharan , Bard Liao , Kai Vehmanen , Mark Brown , Sasha Levin Subject: [PATCH 6.19 515/844] ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data Date: Sat, 28 Feb 2026 12:27:08 -0500 Message-ID: <20260228173244.1509663-516-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Ujfalusi [ Upstream commit c1876fc33c5976837e4c73719c7582617efc6919 ] The size of the data behind scontrol->ipc_control_data is stored in scontrol->size, use this when copying data for backup/restore. Fixes: db38d86d0c54 ("ASoC: sof: Improve sof_ipc4_bytes_ext_put function") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-4-peter.ujfalusi@linux.i= ntel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/sof/ipc4-control.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/sof/ipc4-control.c b/sound/soc/sof/ipc4-control.c index 0a05f66ec7d92..80111672c1796 100644 --- a/sound/soc/sof/ipc4-control.c +++ b/sound/soc/sof/ipc4-control.c @@ -66,7 +66,7 @@ static int sof_ipc4_set_get_kcontrol_data(struct snd_sof_= control *scontrol, * configuration */ memcpy(scontrol->ipc_control_data, scontrol->old_ipc_control_data, - scontrol->max_size); + scontrol->size); kfree(scontrol->old_ipc_control_data); scontrol->old_ipc_control_data =3D NULL; /* Send the last known good configuration to firmware */ @@ -567,7 +567,7 @@ static int sof_ipc4_bytes_ext_put(struct snd_sof_contro= l *scontrol, if (!scontrol->old_ipc_control_data) { /* Create a backup of the current, valid bytes control */ scontrol->old_ipc_control_data =3D kmemdup(scontrol->ipc_control_data, - scontrol->max_size, GFP_KERNEL); + scontrol->size, GFP_KERNEL); if (!scontrol->old_ipc_control_data) return -ENOMEM; } @@ -575,7 +575,7 @@ static int sof_ipc4_bytes_ext_put(struct snd_sof_contro= l *scontrol, /* Copy the whole binary data which includes the ABI header and the paylo= ad */ if (copy_from_user(data, tlvd->tlv, header.length)) { memcpy(scontrol->ipc_control_data, scontrol->old_ipc_control_data, - scontrol->max_size); + scontrol->size); kfree(scontrol->old_ipc_control_data); scontrol->old_ipc_control_data =3D NULL; return -EFAULT; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C05E93E1519; Sat, 28 Feb 2026 17:41:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300478; cv=none; b=b88k9RZ/qosy1B5JUF1dOa8kpa4hZcjYm1qxYOFW5iRsCcOI/1Wj7nVA1cL4VFuRUL5S26ryyxAotoVzWFq+koY8muem7esHi4heXNI1alJsWnnc9KELouHmot6tofRt+DCx7ul0LLj2eEDQFIPowFYX/7kS70XBB9hUX7Oa5vk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300478; c=relaxed/simple; bh=auVoWXV1RNh0FwXOVbRVyFBpw7870SHSuTh2DfWtG9A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Vtb+cxTIF9wluW1I/qjxh6oMk3oPVCyPJCWt/R/+39MGvUP07UVW+mq8XDsQLf2QnFi92PFKPXJFwg4H4kqSKP47wSfeXhZ8mEz/lcB8JTkape/TAAp8WRvn/TVbRhk71b7AwTgNyU2vYqNwUs/a5neDE8kxz2w79UeTzvM1Mm4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ecrn5M49; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ecrn5M49" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B74E3C116D0; Sat, 28 Feb 2026 17:41:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300478; bh=auVoWXV1RNh0FwXOVbRVyFBpw7870SHSuTh2DfWtG9A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ecrn5M4923d8Ytqqyo2tpT1X8eLRXYwW+UuUQxhTmVi546Je3eTy6nVkjS4VpyL1l CX+MAE5+GNvTyhWhOLgP6p+KuTPGteh50y+VMg+vgV6E8LauqP9S0uVIkp09XxwvxE HAdm28xKNezURKEAUofE4Rf9bjmiFrT7V/wTABc5r2yojaO/YrpIIl3kSyQJAGyBWO 2jgJnDyGtFL/9eIh0Lc9sA4RrJfAJTtlTGOGHRui6z0NzoveWlSuQucifV1E8OAnBd LLMx+VmAB1Qm3nZFeDaAqiDjUlnxYVWsFpM4Oc7ZJcpQXOTIeUcguC4aENJlG7l9B4 eB7qWxCe/lWdQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Ujfalusi , Seppo Ingalsuo , Ranjani Sridharan , Bard Liao , Kai Vehmanen , Mark Brown , Sasha Levin Subject: [PATCH 6.19 516/844] ASoC: SOF: ipc4-control: Keep the payload size up to date Date: Sat, 28 Feb 2026 12:27:09 -0500 Message-ID: <20260228173244.1509663-517-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Ujfalusi [ Upstream commit ebcfdbe4add923dfb690e6fb9d158da87ae0b6bf ] When the bytes data is read from the firmware, the size of the payload can be different than what it was previously. For example when the topology did not contained payload data at all for the control, the data size was 0. For get operation allow maximum size of payload to be read and then update the sizes according to the completed message. Similarly, keep the size in sync when updating the data in firmware. With the change we will be able to read data from firmware for bytes controls which did not had initial payload defined in topology. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes contro= l get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-5-peter.ujfalusi@linux.i= ntel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/sof/ipc4-control.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/sound/soc/sof/ipc4-control.c b/sound/soc/sof/ipc4-control.c index 80111672c1796..453ed1643b89c 100644 --- a/sound/soc/sof/ipc4-control.c +++ b/sound/soc/sof/ipc4-control.c @@ -426,13 +426,21 @@ static int sof_ipc4_set_get_bytes_data(struct snd_sof= _dev *sdev, msg->extension =3D SOF_IPC4_MOD_EXT_MSG_PARAM_ID(data->type); =20 msg->data_ptr =3D data->data; - msg->data_size =3D data->size; + if (set) + msg->data_size =3D data->size; + else + msg->data_size =3D scontrol->max_size - sizeof(*data); =20 ret =3D sof_ipc4_set_get_kcontrol_data(scontrol, set, lock); - if (ret < 0) + if (ret < 0) { dev_err(sdev->dev, "Failed to %s for %s\n", set ? "set bytes update" : "get bytes", scontrol->name); + } else if (!set) { + /* Update the sizes according to the received payload data */ + data->size =3D msg->data_size; + scontrol->size =3D sizeof(*cdata) + sizeof(*data) + data->size; + } =20 msg->data_ptr =3D NULL; msg->data_size =3D 0; @@ -448,6 +456,7 @@ static int sof_ipc4_bytes_put(struct snd_sof_control *s= control, struct snd_sof_dev *sdev =3D snd_soc_component_get_drvdata(scomp); struct sof_abi_hdr *data =3D cdata->data; size_t size; + int ret; =20 if (scontrol->max_size > sizeof(ucontrol->value.bytes.data)) { dev_err_ratelimited(scomp->dev, @@ -469,9 +478,12 @@ static int sof_ipc4_bytes_put(struct snd_sof_control *= scontrol, /* copy from kcontrol */ memcpy(data, ucontrol->value.bytes.data, size); =20 - sof_ipc4_set_get_bytes_data(sdev, scontrol, true, true); + ret =3D sof_ipc4_set_get_bytes_data(sdev, scontrol, true, true); + if (!ret) + /* Update the cdata size */ + scontrol->size =3D sizeof(*cdata) + size; =20 - return 0; + return ret; } =20 static int sof_ipc4_bytes_get(struct snd_sof_control *scontrol, @@ -581,6 +593,9 @@ static int sof_ipc4_bytes_ext_put(struct snd_sof_contro= l *scontrol, return -EFAULT; } =20 + /* Update the cdata size */ + scontrol->size =3D sizeof(*cdata) + header.length; + return sof_ipc4_set_get_bytes_data(sdev, scontrol, true, true); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6DEA3E1530; Sat, 28 Feb 2026 17:41:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300479; cv=none; b=GCxOgGtjQa7YNgWiPpQHScfNYRUAk/ilbTuPtoHTYZFQHkuViWCigZ22/ALRh6Qt7aUewj6uYJ3eDYahxKyIX5ZgZ/1zNlc/2ko9FzPVsdg/IY7sB8kMiSb4C1CqehewwOJuyo5bv9WLMELFuBr4zL5czOmkjP56tpNoHxQGe6U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300479; c=relaxed/simple; bh=tamOyq6IAL5SDbOHCmqS4c8s5kRsFwFTV/XBNSIvxJI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iIrsfkhwl9IoTgq2L8hM22pod8RzEidkjfsLPl3LAdAR8zmQt4dOQy/X9qBJeHJ78vv8tuzyosgw+X7QBDLbPnTD1YD/iHLSqEZ/KV59ayQBHRg110/YKwfK9bG8EHD+FUZA1LR4JOs1OcVIu9VHBvKEFCYbtWbSmCFVCgx28iY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y4x9H+Hl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y4x9H+Hl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8285C116D0; Sat, 28 Feb 2026 17:41:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300479; bh=tamOyq6IAL5SDbOHCmqS4c8s5kRsFwFTV/XBNSIvxJI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y4x9H+Hlp4a36FQlrjYkvNSDIxJw5D05NOI70NKXHfv9aM/F08Y25847CXQ8H4AhQ cKqK6ozLYQdIK8ocYzO5lviygupPa8hoxkJAn6TuY/fbuIfgVljluAatOxO6ZBGpe+ CsnrX9yM66kBCUztvUVrO90WxxNoC02WIahdTp9LAvyEldsGwDmqysFgoagY9VopMl /SJGhCsR3opNRC7QVtBJZ+WvVY334Fhr6JxukCicxitTp78ctRRp1gshFZOPxYNt3i 6hGj+CZh/IZmuT1RBAMb6Fgda/EkcNuzk7KdlmD8rC4eojDcecBU/fnv9/ynlHfxJF 2PCz+4syFSyQQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Siddharth Vadapalli , kernel test robot , Arnd Bergmann , Manivannan Sadhasivam , Sasha Levin Subject: [PATCH 6.19 517/844] PCI: j721e: Add config guards for Cadence Host and Endpoint library APIs Date: Sat, 28 Feb 2026 12:27:10 -0500 Message-ID: <20260228173244.1509663-518-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Siddharth Vadapalli [ Upstream commit 4b361b1e92be255ff923453fe8db74086cc7cf66 ] Commit under Fixes enabled loadable module support for the driver under the assumption that it shall be the sole user of the Cadence Host and Endpoint library APIs. This assumption guarantees that we won't end up in a case where the driver is built-in and the library support is built as a loadable module. With the introduction of [1], this assumption is no longer valid. The SG2042 driver could be built as a loadable module, implying that the Cadence Host library is also selected as a loadable module. However, the pci-j721e.c driver could be built-in as indicated by CONFIG_PCI_J721E=3Dy due to which the Cadence Endpoint library is built-in. Despite the library drivers being built as specified by their respective consumers, since the 'pci-j721e.c' driver has references to the Cadence Host library APIs as well, we run into a build error as reported at [0]. Fix this by adding config guards as a temporary workaround. The proper fix is to split the 'pci-j721e.c' driver into independent Host and Endpoint drivers as aligned at [2]. [0]: https://lore.kernel.org/r/202511111705.MZ7ls8Hm-lkp@intel.com/ [1]: commit 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver") [2]: https://lore.kernel.org/r/37f6f8ce-12b2-44ee-a94c-f21b29c98821@app.fas= tmail.com/ Fixes: a2790bf81f0f ("PCI: j721e: Add support to build as a loadable module= ") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511111705.MZ7ls8Hm-lkp@int= el.com/ Suggested-by: Arnd Bergmann Signed-off-by: Siddharth Vadapalli Signed-off-by: Manivannan Sadhasivam Reviewed-by: Arnd Bergmann Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251117113246.1460644-1-s-vadapalli@ti.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/cadence/pci-j721e.c | 41 +++++++++++++--------- 1 file changed, 25 insertions(+), 16 deletions(-) diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/contr= oller/cadence/pci-j721e.c index ecd1b03124006..6f2501479c701 100644 --- a/drivers/pci/controller/cadence/pci-j721e.c +++ b/drivers/pci/controller/cadence/pci-j721e.c @@ -620,9 +620,11 @@ static int j721e_pcie_probe(struct platform_device *pd= ev) gpiod_set_value_cansleep(pcie->reset_gpio, 1); } =20 - ret =3D cdns_pcie_host_setup(rc); - if (ret < 0) - goto err_pcie_setup; + if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) { + ret =3D cdns_pcie_host_setup(rc); + if (ret < 0) + goto err_pcie_setup; + } =20 break; case PCI_MODE_EP: @@ -632,9 +634,11 @@ static int j721e_pcie_probe(struct platform_device *pd= ev) goto err_get_sync; } =20 - ret =3D cdns_pcie_ep_setup(ep); - if (ret < 0) - goto err_pcie_setup; + if (IS_ENABLED(CONFIG_PCI_J721E_EP)) { + ret =3D cdns_pcie_ep_setup(ep); + if (ret < 0) + goto err_pcie_setup; + } =20 break; } @@ -659,10 +663,11 @@ static void j721e_pcie_remove(struct platform_device = *pdev) struct cdns_pcie_ep *ep; struct cdns_pcie_rc *rc; =20 - if (pcie->mode =3D=3D PCI_MODE_RC) { + if (IS_ENABLED(CONFIG_PCI_J721E_HOST) && + pcie->mode =3D=3D PCI_MODE_RC) { rc =3D container_of(cdns_pcie, struct cdns_pcie_rc, pcie); cdns_pcie_host_disable(rc); - } else { + } else if (IS_ENABLED(CONFIG_PCI_J721E_EP)) { ep =3D container_of(cdns_pcie, struct cdns_pcie_ep, pcie); cdns_pcie_ep_disable(ep); } @@ -728,10 +733,12 @@ static int j721e_pcie_resume_noirq(struct device *dev) gpiod_set_value_cansleep(pcie->reset_gpio, 1); } =20 - ret =3D cdns_pcie_host_link_setup(rc); - if (ret < 0) { - clk_disable_unprepare(pcie->refclk); - return ret; + if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) { + ret =3D cdns_pcie_host_link_setup(rc); + if (ret < 0) { + clk_disable_unprepare(pcie->refclk); + return ret; + } } =20 /* @@ -741,10 +748,12 @@ static int j721e_pcie_resume_noirq(struct device *dev) for (enum cdns_pcie_rp_bar bar =3D RP_BAR0; bar <=3D RP_NO_BAR; bar++) rc->avail_ib_bar[bar] =3D true; =20 - ret =3D cdns_pcie_host_init(rc); - if (ret) { - clk_disable_unprepare(pcie->refclk); - return ret; + if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) { + ret =3D cdns_pcie_host_init(rc); + if (ret) { + clk_disable_unprepare(pcie->refclk); + return ret; + } } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E517E48A2A4; Sat, 28 Feb 2026 17:41:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300481; cv=none; b=bu3nipAl3KHS4PT3PKlezbY+JTUyn6O37F/6m1k/HTANLxJi5ZtClWfSEeBja0c0+YdWIKB+3KpsFzIWD+9gTReb4VfO6VTshHVk0L6dJ1y5WDw9FpXzW/Vbp5mFxETS4OuHQtksDcRZgTG4HN0dbKdFOUK6najpoMrYLPVTTO4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300481; c=relaxed/simple; bh=gFiBiJN5gHtn8/5nUyXBJeb3LWUklhye6VF7SCOesm4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ssgvTBdKnRXScY5UDeRHMBhHfxuXcdAVOpoGOTWNnHTaGo01LEH+Rg3GtCIxKSfA9dFLO/YUwwipQR7q7knb7ha4XNZgVJw1NNt3FQepFws3OS4KiJfr/qvQ/hy8IymS1fQVy1WXtcX/aGfiOurivLrFyLlOA3c18BTHcRNe2hk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SKMzxnU1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SKMzxnU1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14518C19423; Sat, 28 Feb 2026 17:41:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300480; bh=gFiBiJN5gHtn8/5nUyXBJeb3LWUklhye6VF7SCOesm4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SKMzxnU1YVnRW2bDJS/7BayCW/03mVlEOMyIIecCkJftC4ajDehUoTHOAgvVbfzDo nldFvswg5wvr5Q8mtvM4SDmc1SZliPCSCj7HVXs11oH/A7gGwUTeTfBNBhYnzUjCj9 rG/m5QAAh7M5UG4ysnr86wg5cNQX1/7pNCf2OYOSSY9U3m1MSh3IhRJQdLp808XOGH NrriJ2kO9/+ZAxU6Z73iweY7Vhn3BtYcql2203lm11rnceDP58A1MfCAJ5aqVkKTa4 9ujIC9NQ+RiT2di6iPoNeINeIBVoPKZGOOQjmY3Se6Jckh7GdIKTgyDtjUyhSEtmjN l/LILz85GgFZA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thadeu Lima de Souza Cascardo , Xu Yilun , Xu Yilun , Sasha Levin Subject: [PATCH 6.19 518/844] fpga: dfl: use subsys_initcall to allow built-in drivers to be added Date: Sat, 28 Feb 2026 12:27:11 -0500 Message-ID: <20260228173244.1509663-519-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thadeu Lima de Souza Cascardo [ Upstream commit 267f53140c9d0bf270bbe0148082e9b8e5011273 ] The dfl code adds a bus. If it is built-in and there is a built-in driver as well, the dfl module_init may be called after the driver module_init, leading to a failure to register the driver as the bus has not been added yet. Use subsys_initcall, which guarantees it will be called before the drivers init code. Without the fix, we see failures like this: [ 0.479475] Driver 'intel-m10-bmc' was unable to register with bus_type = 'dfl' because the bus was not initialized. Cc: stable@vger.kernel.org Fixes: 9ba3a0aa09fe ("fpga: dfl: create a dfl bus type to support DFL devic= es") Signed-off-by: Thadeu Lima de Souza Cascardo Link: https://lore.kernel.org/r/20251215-dfl_subsys-v1-1-21807bad6b10@igali= a.com Reviewed-by: Xu Yilun Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/fpga/dfl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c index 7022657243c0a..449c3a082e232 100644 --- a/drivers/fpga/dfl.c +++ b/drivers/fpga/dfl.c @@ -2018,7 +2018,7 @@ static void __exit dfl_fpga_exit(void) bus_unregister(&dfl_bus_type); } =20 -module_init(dfl_fpga_init); +subsys_initcall(dfl_fpga_init); module_exit(dfl_fpga_exit); =20 MODULE_DESCRIPTION("FPGA Device Feature List (DFL) Support"); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE7EC3E1F2A; Sat, 28 Feb 2026 17:41:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300481; cv=none; b=SJm4dITCD06sH9eBMB5FT6m71q5vgG4SHAA2VQhGIPbR7s4Q5YPhmM3ZyzVL3II/MU4VlJqcMVBWLQZcavUR9+ailAA6rqoNZzFoLCgOZ6WWdipTsf1uotfjqQ6Sfb3WGk9RaYAsNTdxJjcvrz+M24tX2weqhcHHIqNKzroezhc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300481; c=relaxed/simple; bh=zyf+gpSoNDKeLFptf7hUU0gxUFJbg75B1a0fm/er4Mc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WeJbWw/w5uGXisg210297drJIl/gJJVnYJealCc8RIZz9otw39k9ggjE+oqsix0RuVRRFo3EOxKGqr/0tAHtswH7NWSdAKfdgmUuHtGYp7i6q75LnAzDNS7YAETzw+adH+87mBb9HJkagoMwecnWqfkCDpqzR759vgvHXetHVgw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fZX0vlMQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fZX0vlMQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1321FC116D0; Sat, 28 Feb 2026 17:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300481; bh=zyf+gpSoNDKeLFptf7hUU0gxUFJbg75B1a0fm/er4Mc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fZX0vlMQ2yt/2BC6R/t6rDgHPcI27zP4BiUt8oTlQ4H5giBWdLafokz/ZBCp4Rg6S qKfppMUfkbStQdnLqIICuar16jqabYyouafVwas7qWfheoEXh2qu3SWS/mxmPohivP JwhsEX14v3wMnSjG9mukR8z7vE7juXUdqhx2UcmDcEwekuxefj51nyKJJRGAc70vPz gzAwROOJnGq5y+B0kQtonvELFGfY8JQIyHKWp82X/t+LAgRTS/gAublX6aEvmjIxJY ukZ0iaVeMKOV2lsi33uRhLveQtATta1dM/bQeDbDoikXaFEIGgjnGoymAa6cz8rMnU IRXJ/yv2+U+TA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Zimmermann , dri-devel@lists.freedesktop.org, Boris Brezillon , Sasha Levin Subject: [PATCH 6.19 519/844] drm/tests: shmem: Swap names of export tests Date: Sat, 28 Feb 2026 12:27:12 -0500 Message-ID: <20260228173244.1509663-520-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Zimmermann [ Upstream commit 89f23d42006630dd94c01a8c916f8c648141ad8e ] GEM SHMEM has 2 helpers for exporting S/G tables. Swap the names of the rsp. tests, so that each matches the helper it tests. Signed-off-by: Thomas Zimmermann Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by = shmem") Cc: dri-devel@lists.freedesktop.org Cc: # v6.8+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-2-tzimmermann@suse.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/tests/drm_gem_shmem_test.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c b/drivers/gpu/drm/t= ests/drm_gem_shmem_test.c index 68f2c31623547..872881ec9c30d 100644 --- a/drivers/gpu/drm/tests/drm_gem_shmem_test.c +++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c @@ -194,7 +194,7 @@ static void drm_gem_shmem_test_vmap(struct kunit *test) * scatter/gather table large enough to accommodate the backing memory * is successfully exported. */ -static void drm_gem_shmem_test_get_pages_sgt(struct kunit *test) +static void drm_gem_shmem_test_get_sg_table(struct kunit *test) { struct drm_device *drm_dev =3D test->priv; struct drm_gem_shmem_object *shmem; @@ -236,7 +236,7 @@ static void drm_gem_shmem_test_get_pages_sgt(struct kun= it *test) * backing pages are pinned and a scatter/gather table large enough to * accommodate the backing memory is successfully exported. */ -static void drm_gem_shmem_test_get_sg_table(struct kunit *test) +static void drm_gem_shmem_test_get_pages_sgt(struct kunit *test) { struct drm_device *drm_dev =3D test->priv; struct drm_gem_shmem_object *shmem; @@ -366,8 +366,8 @@ static struct kunit_case drm_gem_shmem_test_cases[] =3D= { KUNIT_CASE(drm_gem_shmem_test_obj_create_private), KUNIT_CASE(drm_gem_shmem_test_pin_pages), KUNIT_CASE(drm_gem_shmem_test_vmap), - KUNIT_CASE(drm_gem_shmem_test_get_pages_sgt), KUNIT_CASE(drm_gem_shmem_test_get_sg_table), + KUNIT_CASE(drm_gem_shmem_test_get_pages_sgt), KUNIT_CASE(drm_gem_shmem_test_madvise), KUNIT_CASE(drm_gem_shmem_test_purge), {} --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C59213E1F4B; Sat, 28 Feb 2026 17:41:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300482; cv=none; b=h+JJ6+G8w64pSor+EffyOJO7OORij2Wq/iqR/OgaaPCp3DzXXi0jfrFQQ7I6z/C2T5eVXlBIfMOesYmG+jlBOdCNVSZBVl+8ukCBxsLV0XJv0kDY+dAzhE3nmyEQuHfux6tdFPngyMmod3k2PH89RA8ngx9qW8/KvF+FDbO5Tgg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300482; c=relaxed/simple; bh=felfZVWaTMWH2Djom74FA5Dp7sfnSOwZg8jUAQkEqq4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JQqtsy+aFv4uXYWnuWreWLY7sJzO2AN8q43rUiseHW4HCFM/UDFn98fEKp+/qpBAHWdDB8BWG9pdP8N5pmS+MzYcxm/16QD9WnNgzlegUa/0DT1/8hk7/g/U1dHxDAXwWo0VwvkJxaD7P+gUTwKYOPLcz79bsHNjoPPrScuXAn4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ekzoLZrs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ekzoLZrs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0522BC19424; Sat, 28 Feb 2026 17:41:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300482; bh=felfZVWaTMWH2Djom74FA5Dp7sfnSOwZg8jUAQkEqq4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ekzoLZrskDG0s+Q5Y05jlY86xokE4O+E7hGQa2JtjWGz0JtshxGQueTxkQiAxD9xh 49RU1jKFlfgTJX3dwh76jePTu5W+cUAMyc5DzanWc2+0iZLWLrKPWcz8acItWtfm2V lb6ECNGgRh/IpN2fxO3K75pwCjN69Z1MfsCr3HFj19107BUQParaWuf9G3a7j/lZiX WEZMbbCdnDR6aEg8UdlvcSn70ck7ZHfaVaeLmWQFvun2S9hZ3RFepn/LGHVyMLLNu5 GyBRA0cwznEbv6/VIApntSCFDQ1cpeTcTjyuf0l9rxlt9y9tEZ7CtSztZfD1lNt2r+ LZyiBy2NgBqdQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Zimmermann , dri-devel@lists.freedesktop.org, Boris Brezillon , Sasha Levin Subject: [PATCH 6.19 520/844] drm/tests: shmem: Add clean-up action to unpin pages Date: Sat, 28 Feb 2026 12:27:13 -0500 Message-ID: <20260228173244.1509663-521-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Zimmermann [ Upstream commit b47b9ecef309459278eb52f02b50eefdeaac4f6d ] Automatically unpin pages on cleanup. The test currently fails with the error [ 58.246263] drm-kunit-mock-device drm_gem_shmem_test_get_sg_table.drm-ku= nit-mock-device: [drm] drm_WARN_ON(refcount_read(&shmem->pages_pin_count)) while cleaning up the GEM object. The pin count has to be zero at this point. Signed-off-by: Thomas Zimmermann Fixes: d586b535f144 ("drm/shmem-helper: Add and use pages_pin_count") Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-3-tzimmermann@suse.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/tests/drm_gem_shmem_test.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c b/drivers/gpu/drm/t= ests/drm_gem_shmem_test.c index 872881ec9c30d..1d50bab51ef3f 100644 --- a/drivers/gpu/drm/tests/drm_gem_shmem_test.c +++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c @@ -34,6 +34,9 @@ KUNIT_DEFINE_ACTION_WRAPPER(sg_free_table_wrapper, sg_fre= e_table, KUNIT_DEFINE_ACTION_WRAPPER(drm_gem_shmem_free_wrapper, drm_gem_shmem_free, struct drm_gem_shmem_object *); =20 +KUNIT_DEFINE_ACTION_WRAPPER(drm_gem_shmem_unpin_wrapper, drm_gem_shmem_unp= in, + struct drm_gem_shmem_object *); + /* * Test creating a shmem GEM object backed by shmem buffer. The test * case succeeds if the GEM object is successfully allocated with the @@ -212,6 +215,9 @@ static void drm_gem_shmem_test_get_sg_table(struct kuni= t *test) ret =3D drm_gem_shmem_pin(shmem); KUNIT_ASSERT_EQ(test, ret, 0); =20 + ret =3D kunit_add_action_or_reset(test, drm_gem_shmem_unpin_wrapper, shme= m); + KUNIT_ASSERT_EQ(test, ret, 0); + sgt =3D drm_gem_shmem_get_sg_table(shmem); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, sgt); KUNIT_EXPECT_NULL(test, shmem->sgt); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED7EE3E27E2; Sat, 28 Feb 2026 17:41:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300484; cv=none; b=oLVHR/fjqtc+wU7pfhm62FBOa9T7+58cVW90Ei78ChkIp4z+2ODffIGbqs78AFcsAmvH+O5mvKzHuH4kOndF8fJQavv9VrCSI/y6g35GBBKrAthEObSzifxVwmRzKqY7CouFzOwQRC//qExzHs417n5iYJ5zjyA4T9kvBS76Gtc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300484; c=relaxed/simple; bh=woVw7RupdfUN26E495+pHA7Ft8zUjT4p/GDj8wqKJGY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RMwmyzMd5tDnrEiWeZkWh0A+D7/HNH+9NWrXNYkTTu4VyPZoo427Jzfq4sKRZwKAfOtj7V57WxmiXgW50DK0gbmPTtnT8FV7vH2eNRxrEmJc1mwTyYyGIa5ClNDfKsG6FG3BItBNBMe7SuMafdgSZcxuBgjO9uTFyRnWOhoj6+4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qSIAMWeK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qSIAMWeK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDCECC19423; Sat, 28 Feb 2026 17:41:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300483; bh=woVw7RupdfUN26E495+pHA7Ft8zUjT4p/GDj8wqKJGY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qSIAMWeKWNwLIqPbS9a4/AbpnzfYp7+aTrbvovTaKLVxn49QaQb2gbYR11izTyFpv z4Rc2RNzDU4CPQMH5hhzWYmUw5zadeTckYIRJRke8T16QfzqAeEAd9ri+rvjEmZlM1 im4q10bDO4nsZoIvk7n8ckQmF3WB5khDh/w9cVv3fabjIHJI7A27dmizuUVa8Sjm2v bfwZ3wmNI7QRvEoPxyn6vjeYPjr/inkTsGkGIvLsZIzaLMYH5q9pORZrbsKHb1mJLW s7Mf6wXqh+Xrx2Y9+vMV3pGAsH7Ldyc9h1yKGBTAJq5CpfnJAW8izLB22h43rGVBv3 QoUEIyP9AFiyA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Zimmermann , dri-devel@lists.freedesktop.org, Boris Brezillon , Sasha Levin Subject: [PATCH 6.19 521/844] drm/tests: shmem: Hold reservation lock around vmap/vunmap Date: Sat, 28 Feb 2026 12:27:14 -0500 Message-ID: <20260228173244.1509663-522-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Zimmermann [ Upstream commit cda83b099f117f2a28a77bf467af934cb39e49cf ] Acquire and release the GEM object's reservation lock around vmap and vunmap operations. The tests use vmap_locked, which led to errors such as show below. [ 122.292030] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_h= elper.c:390 drm_gem_shmem_vmap_locked+0x3a3/0x6f0 [ 122.468066] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_h= elper.c:293 drm_gem_shmem_pin_locked+0x1fe/0x350 [ 122.563504] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_h= elper.c:234 drm_gem_shmem_get_pages_locked+0x23c/0x370 [ 122.662248] WARNING: CPU: 2 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_h= elper.c:452 drm_gem_shmem_vunmap_locked+0x101/0x330 Only export the new vmap/vunmap helpers for Kunit tests. These are not interfaces for regular drivers. Signed-off-by: Thomas Zimmermann Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-4-tzimmermann@suse.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/drm_gem_shmem_helper.c | 33 ++++++++++++++++++++++ drivers/gpu/drm/tests/drm_gem_shmem_test.c | 6 ++-- include/drm/drm_gem_shmem_helper.h | 9 ++++++ 3 files changed, 46 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_g= em_shmem_helper.c index f13eb5f36e8a9..b7064b8333e89 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -15,6 +15,8 @@ #include #endif =20 +#include + #include #include #include @@ -894,6 +896,37 @@ struct drm_gem_object *drm_gem_shmem_prime_import_no_m= ap(struct drm_device *dev, } EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_no_map); =20 +/* + * Kunit helpers + */ + +#if IS_ENABLED(CONFIG_KUNIT) +int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem, struct iosys_ma= p *map) +{ + struct drm_gem_object *obj =3D &shmem->base; + int ret; + + ret =3D dma_resv_lock_interruptible(obj->resv, NULL); + if (ret) + return ret; + ret =3D drm_gem_shmem_vmap_locked(shmem, map); + dma_resv_unlock(obj->resv); + + return ret; +} +EXPORT_SYMBOL_IF_KUNIT(drm_gem_shmem_vmap); + +void drm_gem_shmem_vunmap(struct drm_gem_shmem_object *shmem, struct iosys= _map *map) +{ + struct drm_gem_object *obj =3D &shmem->base; + + dma_resv_lock_interruptible(obj->resv, NULL); + drm_gem_shmem_vunmap_locked(shmem, map); + dma_resv_unlock(obj->resv); +} +EXPORT_SYMBOL_IF_KUNIT(drm_gem_shmem_vunmap); +#endif + MODULE_DESCRIPTION("DRM SHMEM memory-management helpers"); MODULE_IMPORT_NS("DMA_BUF"); MODULE_LICENSE("GPL"); diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c b/drivers/gpu/drm/t= ests/drm_gem_shmem_test.c index 1d50bab51ef3f..3e7c6f20fbcca 100644 --- a/drivers/gpu/drm/tests/drm_gem_shmem_test.c +++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c @@ -19,6 +19,8 @@ #include #include =20 +MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING"); + #define TEST_SIZE SZ_1M #define TEST_BYTE 0xae =20 @@ -176,7 +178,7 @@ static void drm_gem_shmem_test_vmap(struct kunit *test) ret =3D kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem= ); KUNIT_ASSERT_EQ(test, ret, 0); =20 - ret =3D drm_gem_shmem_vmap_locked(shmem, &map); + ret =3D drm_gem_shmem_vmap(shmem, &map); KUNIT_ASSERT_EQ(test, ret, 0); KUNIT_ASSERT_NOT_NULL(test, shmem->vaddr); KUNIT_ASSERT_FALSE(test, iosys_map_is_null(&map)); @@ -186,7 +188,7 @@ static void drm_gem_shmem_test_vmap(struct kunit *test) for (i =3D 0; i < TEST_SIZE; i++) KUNIT_EXPECT_EQ(test, iosys_map_rd(&map, i, u8), TEST_BYTE); =20 - drm_gem_shmem_vunmap_locked(shmem, &map); + drm_gem_shmem_vunmap(shmem, &map); KUNIT_EXPECT_NULL(test, shmem->vaddr); KUNIT_EXPECT_EQ(test, refcount_read(&shmem->vmap_use_count), 0); } diff --git a/include/drm/drm_gem_shmem_helper.h b/include/drm/drm_gem_shmem= _helper.h index 589f7bfe7506e..6924ee226655a 100644 --- a/include/drm/drm_gem_shmem_helper.h +++ b/include/drm/drm_gem_shmem_helper.h @@ -303,4 +303,13 @@ struct drm_gem_object *drm_gem_shmem_prime_import_no_m= ap(struct drm_device *dev, .gem_prime_import =3D drm_gem_shmem_prime_import_no_map, \ .dumb_create =3D drm_gem_shmem_dumb_create =20 +/* + * Kunit helpers + */ + +#if IS_ENABLED(CONFIG_KUNIT) +int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem, struct iosys_ma= p *map); +void drm_gem_shmem_vunmap(struct drm_gem_shmem_object *shmem, struct iosys= _map *map); +#endif + #endif /* __DRM_GEM_SHMEM_HELPER_H__ */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C15FD3E27F8; Sat, 28 Feb 2026 17:41:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300484; cv=none; b=hqSmVCfsffsh3SYHpNBXLbH3eO2kpAPFq87cTxMfjPnjjlkFVCwOGk0/pYjWQcDI9cjOoAn0zYedbUgIiOAnqgF/BlT7Gwfpwmg7DCgO4/rCjFTW1+uDCjMA/V1K/XyXv5Uiufuc6GWMKBtQzOQfop1lK+yfv5/XwFugrGSRLXo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300484; c=relaxed/simple; bh=PaP8xmVX6DAgu/ZJhy0ky3LLPoRAImQyNvWyoInYIuo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CVPcxP2UkRzsKl+EkW9Hp/zkm5xEL33Lf6i1GIwnZYLdLiWBsyT21HrE3OT3l5EkMu5XGTEmVG6vgDAEmKarm2vYAaVknzXV728etot+1k//QUov7uK9k6U2tddlwNQqQQnn8wymP62ZhGOVpWDhSvY6aUiHNOygOSV3VM0eVKc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ob1Dmt9l; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ob1Dmt9l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DFAD8C19424; Sat, 28 Feb 2026 17:41:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300484; bh=PaP8xmVX6DAgu/ZJhy0ky3LLPoRAImQyNvWyoInYIuo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ob1Dmt9lzTs+pbuQ6WZZkbgrKQou6kvYtcc/Wys3HWB+c2/PHSLc2jhHt7WSUlEPU CRkdfX094goLOuCZ5hzeILbO4llx7mO9L7sgzw5MtH2bFgar3bjjIhREjhfcp9SVGD 3Vxjoq3/LAmHGjDpdXC2zJkdaYF1+b+U3i87g+VHXoGk/lCc2HguqG1yzE3zO2cmU9 +89k0pdhNrD4K5SN5/lytGMblPyRP7CawMgBwnCzH5SjF1s8YwPtRdW7gqp8dOVsE0 EYeVI/S6/oMlczxVD6ICT017b6AunL5W96abozb/XWQ0D3i/gI3i2t+OpiGzfMwm4L HGady3S1/RTVg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Zimmermann , dri-devel@lists.freedesktop.org, Boris Brezillon , Sasha Levin Subject: [PATCH 6.19 522/844] drm/tests: shmem: Hold reservation lock around madvise Date: Sat, 28 Feb 2026 12:27:15 -0500 Message-ID: <20260228173244.1509663-523-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Zimmermann [ Upstream commit 607d07d8cc0b835a8701259f08a03dc149b79b4f ] Acquire and release the GEM object's reservation lock around calls to the object's madvide operation. The tests use drm_gem_shmem_madvise_locked(), which led to errors such as show below. [ 58.339389] WARNING: CPU: 1 PID: 1352 at drivers/gpu/drm/drm_gem_shmem_h= elper.c:499 drm_gem_shmem_madvise_locked+0xde/0x140 Only export the new helper drm_gem_shmem_madvise() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-5-tzimmermann@suse.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/drm_gem_shmem_helper.c | 15 +++++++++++++++ drivers/gpu/drm/tests/drm_gem_shmem_test.c | 8 ++++---- include/drm/drm_gem_shmem_helper.h | 1 + 3 files changed, 20 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_g= em_shmem_helper.c index b7064b8333e89..1dfc9c4089587 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -925,6 +925,21 @@ void drm_gem_shmem_vunmap(struct drm_gem_shmem_object = *shmem, struct iosys_map * dma_resv_unlock(obj->resv); } EXPORT_SYMBOL_IF_KUNIT(drm_gem_shmem_vunmap); + +int drm_gem_shmem_madvise(struct drm_gem_shmem_object *shmem, int madv) +{ + struct drm_gem_object *obj =3D &shmem->base; + int ret; + + ret =3D dma_resv_lock_interruptible(obj->resv, NULL); + if (ret) + return ret; + ret =3D drm_gem_shmem_madvise_locked(shmem, madv); + dma_resv_unlock(obj->resv); + + return ret; +} +EXPORT_SYMBOL_IF_KUNIT(drm_gem_shmem_madvise); #endif =20 MODULE_DESCRIPTION("DRM SHMEM memory-management helpers"); diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c b/drivers/gpu/drm/t= ests/drm_gem_shmem_test.c index 3e7c6f20fbcca..d639848e3c8ea 100644 --- a/drivers/gpu/drm/tests/drm_gem_shmem_test.c +++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c @@ -292,17 +292,17 @@ static void drm_gem_shmem_test_madvise(struct kunit *= test) ret =3D kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem= ); KUNIT_ASSERT_EQ(test, ret, 0); =20 - ret =3D drm_gem_shmem_madvise_locked(shmem, 1); + ret =3D drm_gem_shmem_madvise(shmem, 1); KUNIT_EXPECT_TRUE(test, ret); KUNIT_ASSERT_EQ(test, shmem->madv, 1); =20 /* Set madv to a negative value */ - ret =3D drm_gem_shmem_madvise_locked(shmem, -1); + ret =3D drm_gem_shmem_madvise(shmem, -1); KUNIT_EXPECT_FALSE(test, ret); KUNIT_ASSERT_EQ(test, shmem->madv, -1); =20 /* Check that madv cannot be set back to a positive value */ - ret =3D drm_gem_shmem_madvise_locked(shmem, 0); + ret =3D drm_gem_shmem_madvise(shmem, 0); KUNIT_EXPECT_FALSE(test, ret); KUNIT_ASSERT_EQ(test, shmem->madv, -1); } @@ -330,7 +330,7 @@ static void drm_gem_shmem_test_purge(struct kunit *test) ret =3D drm_gem_shmem_is_purgeable(shmem); KUNIT_EXPECT_FALSE(test, ret); =20 - ret =3D drm_gem_shmem_madvise_locked(shmem, 1); + ret =3D drm_gem_shmem_madvise(shmem, 1); KUNIT_EXPECT_TRUE(test, ret); =20 /* The scatter/gather table will be freed by drm_gem_shmem_free */ diff --git a/include/drm/drm_gem_shmem_helper.h b/include/drm/drm_gem_shmem= _helper.h index 6924ee226655a..3dd93e2df7092 100644 --- a/include/drm/drm_gem_shmem_helper.h +++ b/include/drm/drm_gem_shmem_helper.h @@ -310,6 +310,7 @@ struct drm_gem_object *drm_gem_shmem_prime_import_no_ma= p(struct drm_device *dev, #if IS_ENABLED(CONFIG_KUNIT) int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem, struct iosys_ma= p *map); void drm_gem_shmem_vunmap(struct drm_gem_shmem_object *shmem, struct iosys= _map *map); +int drm_gem_shmem_madvise(struct drm_gem_shmem_object *shmem, int madv); #endif =20 #endif /* __DRM_GEM_SHMEM_HELPER_H__ */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCB883E2814; Sat, 28 Feb 2026 17:41:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300485; cv=none; b=m7zY4kab3TFETPFXWg0lRzKhpAIlQ+oblNCvJdGWATlzKto3YtIAkJyKqRxrlx8WVogK8MqbDHSoibeKAJ8gRkPrYxcdicdhuP/FqxhpEV2sCWlM/YAcK1lWTz3s0B5tRLBTt2bWG86UgFhgJhDejvWyOsS015r8u5B9uvSnFho= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300485; c=relaxed/simple; bh=oJ+fRIDJzuhUNlGePCiimaDZMppSI5Nw9MhP5u2/hUM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h5Z3jnbs1aVkM0daZ7mekNF7dOsaI7/PO1e3btnuuqRPIFoI6ZA79lAtPNIjxuWUFXAE79a/8alV5QeVKRnXuOO2WvNPL3DlL/l0HnWspNXzFCJxTbkpAKaabuffFBTE2LhoEDBJcQGHVcbe0/WUtaJ5EgjxpKqlj7aBOyNcwnc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aG9IgV0n; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aG9IgV0n" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCD7AC116D0; Sat, 28 Feb 2026 17:41:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300485; bh=oJ+fRIDJzuhUNlGePCiimaDZMppSI5Nw9MhP5u2/hUM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aG9IgV0nIxZd1rBB/gUbbRM23Rs5hvY0OPqFpqupsHkwPAJL5NMvqUGK6rTd8jTre CQW0BJmd8KVyb79a2+zAFR4G2Q/LANoTsNdbZ6StXg9ECOoQyKJPrDjnu8PzXp5qLK ckJlQwunjZvLCod2y/Kwpos3a9SzVxgZOfhyxGH5GmdNS03V2XcyLYVP2hCuyPyIqu OZbnYZDKNQIO0fpvtr1tbBSYiH8VCEzjg6ILleBRVUJwsNpblO5uk4CFLcubxRD3FZ MKDoUTWGQ2CB6KNt6MA2NMHtiyB94pYb7ffWF1Yp+C3uwEB9bnXC8W8Bvp2ZRIzTlG RLTGrLh0HA8Ng== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Zimmermann , dri-devel@lists.freedesktop.org, Boris Brezillon , Sasha Levin Subject: [PATCH 6.19 523/844] drm/tests: shmem: Hold reservation lock around purge Date: Sat, 28 Feb 2026 12:27:16 -0500 Message-ID: <20260228173244.1509663-524-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Zimmermann [ Upstream commit 3f41307d589c2f25d556d47b165df808124cd0c4 ] Acquire and release the GEM object's reservation lock around calls to the object's purge operation. The tests use drm_gem_shmem_purge_locked(), which led to errors such as show below. [ 58.709128] WARNING: CPU: 1 PID: 1354 at drivers/gpu/drm/drm_gem_shmem_h= elper.c:515 drm_gem_shmem_purge_locked+0x51c/0x740 Only export the new helper drm_gem_shmem_purge() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-6-tzimmermann@suse.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/drm_gem_shmem_helper.c | 15 +++++++++++++++ drivers/gpu/drm/tests/drm_gem_shmem_test.c | 4 +++- include/drm/drm_gem_shmem_helper.h | 1 + 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_g= em_shmem_helper.c index 1dfc9c4089587..0db3fe08a57b7 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -940,6 +940,21 @@ int drm_gem_shmem_madvise(struct drm_gem_shmem_object = *shmem, int madv) return ret; } EXPORT_SYMBOL_IF_KUNIT(drm_gem_shmem_madvise); + +int drm_gem_shmem_purge(struct drm_gem_shmem_object *shmem) +{ + struct drm_gem_object *obj =3D &shmem->base; + int ret; + + ret =3D dma_resv_lock_interruptible(obj->resv, NULL); + if (ret) + return ret; + drm_gem_shmem_purge_locked(shmem); + dma_resv_unlock(obj->resv); + + return 0; +} +EXPORT_SYMBOL_IF_KUNIT(drm_gem_shmem_purge); #endif =20 MODULE_DESCRIPTION("DRM SHMEM memory-management helpers"); diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c b/drivers/gpu/drm/t= ests/drm_gem_shmem_test.c index d639848e3c8ea..4b459f21acfd9 100644 --- a/drivers/gpu/drm/tests/drm_gem_shmem_test.c +++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c @@ -340,7 +340,9 @@ static void drm_gem_shmem_test_purge(struct kunit *test) ret =3D drm_gem_shmem_is_purgeable(shmem); KUNIT_EXPECT_TRUE(test, ret); =20 - drm_gem_shmem_purge_locked(shmem); + ret =3D drm_gem_shmem_purge(shmem); + KUNIT_ASSERT_EQ(test, ret, 0); + KUNIT_EXPECT_NULL(test, shmem->pages); KUNIT_EXPECT_NULL(test, shmem->sgt); KUNIT_EXPECT_EQ(test, shmem->madv, -1); diff --git a/include/drm/drm_gem_shmem_helper.h b/include/drm/drm_gem_shmem= _helper.h index 3dd93e2df7092..8d56970d7eed1 100644 --- a/include/drm/drm_gem_shmem_helper.h +++ b/include/drm/drm_gem_shmem_helper.h @@ -311,6 +311,7 @@ struct drm_gem_object *drm_gem_shmem_prime_import_no_ma= p(struct drm_device *dev, int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem, struct iosys_ma= p *map); void drm_gem_shmem_vunmap(struct drm_gem_shmem_object *shmem, struct iosys= _map *map); int drm_gem_shmem_madvise(struct drm_gem_shmem_object *shmem, int madv); +int drm_gem_shmem_purge(struct drm_gem_shmem_object *shmem); #endif =20 #endif /* __DRM_GEM_SHMEM_HELPER_H__ */ --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4EB23E3147; Sat, 28 Feb 2026 17:41:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300487; cv=none; b=fTxY2JVJm9pWEvuLbsQTmDRLwnqjsB3YzZ0F9tv5o1B6g9+gMu+TOaWmQmAZ0kruAn2P61AnI8h2mLnQisvQgh06F1/gABW4ng2tygRsZ4TvhzkGPjf4XD2zQRGsaxH8hH8K+FJsO+HkkK7AB+or4wqTjvRBmH1L0jGpHa279s4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300487; c=relaxed/simple; bh=kV156b6234C9zhtVhVOBCETWGG2U4H/YWhUB6BkccCU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cIWpOkwpniCnipEjzsFVierebwlcMIlF4dkz/6kY8XkBm7SMOcsD0jCiGQqUG21nmZbi5IF7NXSQRn9krW4VNRdrVYgU65DKU4Pg4xYcuQblQxA27NkT9YcuhwZgd8uLeFELcJJ47wdizqQql0WPI7GnJFJzoDZMH0HG8byzLL0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iqsktQ9C; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iqsktQ9C" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08FAEC19425; Sat, 28 Feb 2026 17:41:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300486; bh=kV156b6234C9zhtVhVOBCETWGG2U4H/YWhUB6BkccCU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iqsktQ9Cl5gJovgzqZepZ+Reigv0SepyEWsc1kZnrLXvZQWUab0ZgDXUKzkuyupSF pSC5PrwGA1LDAgycvzn0vyXBdLcK7sTdscKBO3Md8BuOwEdMqGQJIUZhWWXe6KnE3a ROrKVWGDAInhU0Un33oJ2r5Sj/xiVib6yVd0bIzXyNi4NLGDul9Oza92SAypgv+weM 9cuApeEWrlrSm6F/5WY1Ijg9/ojEZPVaWW38nrKw6A5penhCsN5Yqjedn/+Up3wyYs Gnx2PwxHp4oHEL0LVUJATGCShYq2+YO6gZoupr646uICiFtADTcOzUhBFVCsY7g3Rd Du3aRbB583brg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tvrtko Ursulin , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Juha-Pekka Heikkila , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Sasha Levin Subject: [PATCH 6.19 524/844] drm/xe: Fix ggtt fb alignment Date: Sat, 28 Feb 2026 12:27:17 -0500 Message-ID: <20260228173244.1509663-525-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Tvrtko Ursulin [ Upstream commit a61bf068f1fe359203f1af191cb523b77dc32752 ] Pass the correct alignment from intel_fb_pin_to_ggtt() down to __xe_pin_fb_vma(). Signed-off-by: Tvrtko Ursulin Reported-by: Ville Syrj=C3=A4l=C3=A4 Closes: https://lore.kernel.org/intel-xe/aNL_RgLy13fXJbYx@intel.com/ Cc: Juha-Pekka Heikkila Reviewed-by: Ville Syrj=C3=A4l=C3=A4 Fixes: b0228a337de8 ("drm/xe/display: align framebuffers according to hw re= quirements") Cc: # v6.13+ Signed-off-by: Thomas Hellstr=C3=B6m Link: https://patch.msgid.link/20251208181550.6618-1-tursulin@igalia.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/xe/display/xe_fb_pin.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/di= splay/xe_fb_pin.c index 1fd4a815e784b..b18d15cc3c53d 100644 --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c @@ -378,7 +378,7 @@ intel_fb_pin_to_ggtt(const struct drm_framebuffer *fb, { *out_flags =3D 0; =20 - return __xe_pin_fb_vma(to_intel_framebuffer(fb), view, phys_alignment); + return __xe_pin_fb_vma(to_intel_framebuffer(fb), view, alignment); } =20 void intel_fb_unpin_vma(struct i915_vma *vma, unsigned long flags) --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF4CE3E3162; Sat, 28 Feb 2026 17:41:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300487; cv=none; b=mIT58pdbp9SBJHKLt9Y/MnLVHZQknRvlN7Hwc/xCo7AA1/gXdZONZzGCkKZGgj4B7IPxs3JyH31Ob0yHF5k/lQ2J28qI3GzoEwxQb0uVCSERTg1I0+tBMwXtVkX6aRpDNclfr/2bKTNcbXm1ezEitgKHFYcX6LNn+BVs1+9R60I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300487; c=relaxed/simple; bh=rSrXcnCrRrby3HXDaclTuPm6p5hszZnn4GCrBaiQyfA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=c7Wf9S8P0RpOQ09ZK9I7ZGCgxQ42HREwZ4Ql5Db1d4zlL/8kQ5i3TdE5lg54LmiNL+B//Rd1nYr+qrf9/3R2V6vsj155i9gSQ7JAScPrvKRJSSyUsWXElF6YoZzGDFUoxgrcdTZ7/zixZYP+w6dQVCGp4dhaUqKTkfOA5Xy7XXI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GSHPldJX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GSHPldJX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C54DC19424; Sat, 28 Feb 2026 17:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300487; bh=rSrXcnCrRrby3HXDaclTuPm6p5hszZnn4GCrBaiQyfA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GSHPldJX1qs4q2w5Tob+P8PshLSEQtL7oC+/TTuMcXYdjdOP2ubs1/UQVcoaqX34m mYFxJ1GNsJKu4YQFKLd8fUtTUqJoNZLeYrutAJzEs1B2LtHHuGxm4KN0kElOzQkY2m YcGSuVIKJ/Ia9XtC41JsJUtxBcLtILLrXz/3ZF7ucw8Tw3OUK5NfZ95n0IYwx1ULNR wHRslkXnjVAoQikNPAYDNoGljengKnEt0bDOmOTWVvRzxGVrhD+vpgq88Ekdm4xOHR 2/82wjQ/AdFxbYh3PbiBu0FjWhhe78Yqe30vPe+JnlOxtKYrQHKexH91xUZeFhut6n og4CmYIIIDwaw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Cassel , Manivannan Sadhasivam , Shawn Lin , Sasha Levin Subject: [PATCH 6.19 525/844] Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link Up" Date: Sat, 28 Feb 2026 12:27:18 -0500 Message-ID: <20260228173244.1509663-526-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Cassel [ Upstream commit fc6298086bfacaa7003b0bd1da4e4f42b29f7d77 ] This reverts commit ec9fd499b9c60a187ac8d6414c3c343c77d32e42. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] canno= t be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] canno= t be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] canno= t be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] canno= t be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (confl= icts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] ca= nnot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-9-cassel@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/co= ntroller/dwc/pcie-dw-rockchip.c index a3daac74d3f18..59396db3f4812 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -588,7 +588,6 @@ static int rockchip_pcie_configure_rc(struct platform_d= evice *pdev, =20 pp =3D &rockchip->pci.pp; pp->ops =3D &rockchip_pcie_host_ops; - pp->use_linkup_irq =3D true; =20 ret =3D dw_pcie_host_init(pp); if (ret) { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE4463E317B; Sat, 28 Feb 2026 17:41:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300488; cv=none; b=MaiaJ76DPnfp/dOIvsyf59AoITApAf3QXvR1LVSRvPEFCJP5aW3oeZxTTAndLb8gpuVmp1e8CQP0CS4hsxEKui4kILfonUFwGohGdjYVuKaxT6H5PSVdnLBkrV0OnoNwwC30hWQLKvp1nwCA33GfU2FEB0gYQJ0xQoK+Er9iRIA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300488; c=relaxed/simple; bh=hPSoMhZ8J+PtXAVYzZfG4+vY13vMdHJHn1PTtmsVAqI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=urNjUf6vGr8aruuqBcnHbk35x+d2nfLisxIPmIc+FEo/QhvtGfu2+S7R8aQoS2ufFDVBgA0VUhnsZapZLCDqKWzPH7HmSlNAt8AE9Bs5v+41UFCugT/H2z6llQoYtDtvjgasmkg9CWgo1OIh49b4bGUZMoczj5yJDR+AdaBeGuU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oqTTa888; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oqTTa888" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14262C116D0; Sat, 28 Feb 2026 17:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300488; bh=hPSoMhZ8J+PtXAVYzZfG4+vY13vMdHJHn1PTtmsVAqI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oqTTa888qC9NhtU/sXCKhQGU5fixpS+VguWxo9nGmcgAxPtK0Oj6W1oQamaDAfbuT viXj0FiU0wXdoV9qi8/EeyL5ludsX9vG9l4LVxVbibo73x/rVxFCoKfR5C8YXqLn1H gBGymbjdPLrg/VvgySE2BnBB1aOhi+wyRdk79PADLU5mp7kd9zMy9IgA0+Xgn3kyiU UytB1888FcmwJXMaEwz18b/ep+gmYo6pFP5x9O34vHfSTgG2SCReumdshn09pfzTbp vSZlweFL2tFI6MkaHFQa6kGsJbZsZqOWk30kjwXr68vVGc+vQNjvvqHgIXq4pidXlO V/AmAmQhdm4jQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shawn Lin , Manivannan Sadhasivam , Sasha Levin Subject: [PATCH 6.19 526/844] PCI: dwc: Add L1 Substates context to ltssm_status of debugfs Date: Sat, 28 Feb 2026 12:27:19 -0500 Message-ID: <20260228173244.1509663-527-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shawn Lin [ Upstream commit 679ec639f29cbdaf36bd79bf3e98240fffa335ee ] DWC core couldn't distinguish LTSSM state among L1.0, L1.1 and L1.2. But the vendor glue driver may implement additional logic to convey this information. So add two pseudo definitions for vendor glue drivers to translate their internal L1 Substates for debugfs to show. Signed-off-by: Shawn Lin Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/1765503205-22184-1-git-send-email-shawn.lin@= rock-chips.com Stable-dep-of: 180c3cfe3678 ("Revert "PCI: dw-rockchip: Enumerate endpoints= based on dll_link_up IRQ"") Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-designware-debugfs.c | 2 ++ drivers/pci/controller/dwc/pcie-designware.h | 4 ++++ 2 files changed, 6 insertions(+) diff --git a/drivers/pci/controller/dwc/pcie-designware-debugfs.c b/drivers= /pci/controller/dwc/pcie-designware-debugfs.c index 0fbf86c0b97e0..df98fee69892b 100644 --- a/drivers/pci/controller/dwc/pcie-designware-debugfs.c +++ b/drivers/pci/controller/dwc/pcie-designware-debugfs.c @@ -485,6 +485,8 @@ static const char *ltssm_status_string(enum dw_pcie_lts= sm ltssm) DW_PCIE_LTSSM_NAME(DW_PCIE_LTSSM_RCVRY_EQ1); DW_PCIE_LTSSM_NAME(DW_PCIE_LTSSM_RCVRY_EQ2); DW_PCIE_LTSSM_NAME(DW_PCIE_LTSSM_RCVRY_EQ3); + DW_PCIE_LTSSM_NAME(DW_PCIE_LTSSM_L1_1); + DW_PCIE_LTSSM_NAME(DW_PCIE_LTSSM_L1_2); default: str =3D "DW_PCIE_LTSSM_UNKNOWN"; break; diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/con= troller/dwc/pcie-designware.h index 5c429b62cb086..ed1801dd8e39a 100644 --- a/drivers/pci/controller/dwc/pcie-designware.h +++ b/drivers/pci/controller/dwc/pcie-designware.h @@ -392,6 +392,10 @@ enum dw_pcie_ltssm { DW_PCIE_LTSSM_RCVRY_EQ2 =3D 0x22, DW_PCIE_LTSSM_RCVRY_EQ3 =3D 0x23, =20 + /* Vendor glue drivers provide pseudo L1 substates from get_ltssm() */ + DW_PCIE_LTSSM_L1_1 =3D 0x141, + DW_PCIE_LTSSM_L1_2 =3D 0x142, + DW_PCIE_LTSSM_UNKNOWN =3D 0xFFFFFFFF, }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9FF723E3A6B; Sat, 28 Feb 2026 17:41:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300489; cv=none; b=nezvvLUt7bRYh5jV6gNlSp0dZ34Wy1Y9XjhBcstdUcEsA5oy7CDKmKlrcFeiSR9qHfpiKmIoS6ufSc5xmFnTz19Rz5TQu7uMu3lWBu0wMGZPkscqhyZDbj8WphLll9FEtuKIiOt05dpByZCBDHO7qiT7SPwhj2LV3eWcmYlumPE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300489; c=relaxed/simple; bh=nGxuxuVtz//C45ppm+cQRTzhofN5GXlYDTDFuBNsmtg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fWF5M2E3Z5aOy3Tq/wkfWorXKDRt0kLfBmIJl7FjtmSkk1t54C9XET4dy/OLGa8u3ipZYEDrvzCcQXbwrjLraV8Thj0FcYeit1ncsa7urw9P46lp+fH4elLLkScyiTgPWYQH7lwGGAGa7MBnHBQuQJrtpwfBm1pBkWVtMN7eGK8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Obx1wkq8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Obx1wkq8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB457C19425; Sat, 28 Feb 2026 17:41:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300489; bh=nGxuxuVtz//C45ppm+cQRTzhofN5GXlYDTDFuBNsmtg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Obx1wkq8sEcyqCkyZ5uQNHFkYFn4+Hy1EulE/aa9dSRrYiQh3wmvzHzF3rB1zoMKF yBzPRqbR1903xstJc0EdAryicf7os7iW9k9OWoC129d24YZIkiRBKuwWa0d4c7lSlv UuvclK0h3WEagBnYr+YKytdS6N3az/3i0t9th07kE+UIYQ1D8NjcnfO7rnxFUrBpgA PEVLwkCskCr4oNPO/zbmOKoD1064lKIIcsuArZlgbDPDgt3Qmp4p4g+V5wqVc61vc5 8AH4wdvZ27/AoB0kq22uV6nCPkTp5BOquSPqVBW9ICR+z+F+EgNiAVGLarXua8NRbq h77NLLJMtWZzw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shawn Lin , Manivannan Sadhasivam , Sasha Levin Subject: [PATCH 6.19 527/844] PCI: dw-rockchip: Change get_ltssm() to provide L1 Substates info Date: Sat, 28 Feb 2026 12:27:20 -0500 Message-ID: <20260228173244.1509663-528-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shawn Lin [ Upstream commit f994bb8f1c94726e0124356ccd31c3c23a8a69f4 ] Rename rockchip_pcie_get_ltssm() to rockchip_pcie_get_ltssm_reg() and add rockchip_pcie_get_ltssm() to get_ltssm() callback in order to show the proper L1 Substates. The PCIE_CLIENT_LTSSM_STATUS[5:0] register returns the same LTSSM layout as enum dw_pcie_ltssm. So the driver just need to convey L1 PM Substates by returning the proper value defined in pcie-designware.h. cat /sys/kernel/debug/dwc_pcie_a40000000.pcie/ltssm_status L1_2 (0x142) Signed-off-by: Shawn Lin Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/1765503205-22184-2-git-send-email-shawn.lin@= rock-chips.com Stable-dep-of: 180c3cfe3678 ("Revert "PCI: dw-rockchip: Enumerate endpoints= based on dll_link_up IRQ"") Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-dw-rockchip.c | 29 ++++++++++++++++--- 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/co= ntroller/dwc/pcie-dw-rockchip.c index 59396db3f4812..0ec12e5edf62f 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -68,6 +68,11 @@ #define PCIE_CLKREQ_NOT_READY FIELD_PREP_WM16(BIT(0), 0) #define PCIE_CLKREQ_PULL_DOWN FIELD_PREP_WM16(GENMASK(13, 12), 1) =20 +/* RASDES TBA information */ +#define PCIE_CLIENT_CDM_RASDES_TBA_INFO_CMN 0x154 +#define PCIE_CLIENT_CDM_RASDES_TBA_L1_1 BIT(4) +#define PCIE_CLIENT_CDM_RASDES_TBA_L1_2 BIT(5) + /* Hot Reset Control Register */ #define PCIE_CLIENT_HOT_RESET_CTRL 0x180 #define PCIE_LTSSM_APP_DLY2_EN BIT(1) @@ -183,11 +188,26 @@ static int rockchip_pcie_init_irq_domain(struct rockc= hip_pcie *rockchip) return 0; } =20 -static u32 rockchip_pcie_get_ltssm(struct rockchip_pcie *rockchip) +static u32 rockchip_pcie_get_ltssm_reg(struct rockchip_pcie *rockchip) { return rockchip_pcie_readl_apb(rockchip, PCIE_CLIENT_LTSSM_STATUS); } =20 +static enum dw_pcie_ltssm rockchip_pcie_get_ltssm(struct dw_pcie *pci) +{ + struct rockchip_pcie *rockchip =3D to_rockchip_pcie(pci); + u32 val =3D rockchip_pcie_readl_apb(rockchip, + PCIE_CLIENT_CDM_RASDES_TBA_INFO_CMN); + + if (val & PCIE_CLIENT_CDM_RASDES_TBA_L1_1) + return DW_PCIE_LTSSM_L1_1; + + if (val & PCIE_CLIENT_CDM_RASDES_TBA_L1_2) + return DW_PCIE_LTSSM_L1_2; + + return rockchip_pcie_get_ltssm_reg(rockchip) & PCIE_LTSSM_STATUS_MASK; +} + static void rockchip_pcie_enable_ltssm(struct rockchip_pcie *rockchip) { rockchip_pcie_writel_apb(rockchip, PCIE_CLIENT_ENABLE_LTSSM, @@ -203,7 +223,7 @@ static void rockchip_pcie_disable_ltssm(struct rockchip= _pcie *rockchip) static bool rockchip_pcie_link_up(struct dw_pcie *pci) { struct rockchip_pcie *rockchip =3D to_rockchip_pcie(pci); - u32 val =3D rockchip_pcie_get_ltssm(rockchip); + u32 val =3D rockchip_pcie_get_ltssm_reg(rockchip); =20 return FIELD_GET(PCIE_LINKUP_MASK, val) =3D=3D PCIE_LINKUP; } @@ -493,6 +513,7 @@ static const struct dw_pcie_ops dw_pcie_ops =3D { .link_up =3D rockchip_pcie_link_up, .start_link =3D rockchip_pcie_start_link, .stop_link =3D rockchip_pcie_stop_link, + .get_ltssm =3D rockchip_pcie_get_ltssm, }; =20 static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg) @@ -507,7 +528,7 @@ static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int = irq, void *arg) rockchip_pcie_writel_apb(rockchip, reg, PCIE_CLIENT_INTR_STATUS_MISC); =20 dev_dbg(dev, "PCIE_CLIENT_INTR_STATUS_MISC: %#x\n", reg); - dev_dbg(dev, "LTSSM_STATUS: %#x\n", rockchip_pcie_get_ltssm(rockchip)); + dev_dbg(dev, "LTSSM_STATUS: %#x\n", rockchip_pcie_get_ltssm_reg(rockchip)= ); =20 if (reg & PCIE_RDLH_LINK_UP_CHGED) { if (rockchip_pcie_link_up(pci)) { @@ -534,7 +555,7 @@ static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int = irq, void *arg) rockchip_pcie_writel_apb(rockchip, reg, PCIE_CLIENT_INTR_STATUS_MISC); =20 dev_dbg(dev, "PCIE_CLIENT_INTR_STATUS_MISC: %#x\n", reg); - dev_dbg(dev, "LTSSM_STATUS: %#x\n", rockchip_pcie_get_ltssm(rockchip)); + dev_dbg(dev, "LTSSM_STATUS: %#x\n", rockchip_pcie_get_ltssm_reg(rockchip)= ); =20 if (reg & PCIE_LINK_REQ_RST_NOT_INT) { dev_dbg(dev, "hot reset or link-down reset\n"); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CC163E3A8B; Sat, 28 Feb 2026 17:41:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300490; cv=none; b=LIaqC+JDkaldL/irc+/TOrXVGJbkMSeNH2lasj+YlSvljT8L3tC1LQ9QaWWfPnbMM92L5V7w8l8QsqG4NrJFkjg3IqbTjTAufB9GlCXkVVW4e2qv0MOgQc/WcURQT8TLgWwyYJLC9sGHUUPr9mHhwssaw1tKMp47GZoRow+tyAU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300490; c=relaxed/simple; bh=1HFjrmqa8ATchi2ivor7YSEZP5uNiuSb79PfGecaPss=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iKA/Qfqcbzani2xb4CXDWe3M+qypmj//6wFMZZM6Aw4Y24A9SldcrycwS4vT6my2y4tp0Oc4Dqa5EYtYfVZBu29AsSgp4bG7gLJSedJQL2nqvEJ0lszUQsI4WKGo/bvchgU0uGdYgecKob3DqzPE1Iv6wDwkiw5MBPiJc4nKbXQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ffVoYd7d; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ffVoYd7d" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8D90C116D0; Sat, 28 Feb 2026 17:41:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300490; bh=1HFjrmqa8ATchi2ivor7YSEZP5uNiuSb79PfGecaPss=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ffVoYd7dvN6NJZqd3fdNpeGsiwOJtCrEVUPsoJ5OImG5/WHrhiYvT8P6L3XyMS+4H So9ARtBMMv+OmyI1pCOr+kZsY8JzPGdlpsnMHnxPTmweZvgP6JanABORRPvqosvBy0 vo21a/43Uo1nFd2RCenxog4HhfzkcdZ5TcW9hvPd6UntaGwJXoNre/VRyM+YXgkmLz /rCLeu9kNY6MPClTiiAhEN7xsm9Ce36eUrho7lihVV1abb1M0Q/PW8GNozKcPnInH7 hCd2FEAzWvZ3oTXAwfJbUn0BoJcGJ6mNwC4aTvfftmyM5rGwueRS7ZcpUGa8p6emto od2Lya5RQsP2A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Cassel , Manivannan Sadhasivam , Shawn Lin , Sasha Levin Subject: [PATCH 6.19 528/844] Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ" Date: Sat, 28 Feb 2026 12:27:21 -0500 Message-ID: <20260228173244.1509663-529-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Cassel [ Upstream commit 180c3cfe36786d261a55da52a161f9e279b19a6f ] This reverts commit 0e0b45ab5d770a748487ba0ae8f77d1fb0f0de3e. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] canno= t be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] canno= t be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] canno= t be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] canno= t be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (confl= icts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] ca= nnot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-10-cassel@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-dw-rockchip.c | 59 +------------------ 1 file changed, 3 insertions(+), 56 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/co= ntroller/dwc/pcie-dw-rockchip.c index 0ec12e5edf62f..5b17da63151d5 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -516,34 +516,6 @@ static const struct dw_pcie_ops dw_pcie_ops =3D { .get_ltssm =3D rockchip_pcie_get_ltssm, }; =20 -static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg) -{ - struct rockchip_pcie *rockchip =3D arg; - struct dw_pcie *pci =3D &rockchip->pci; - struct dw_pcie_rp *pp =3D &pci->pp; - struct device *dev =3D pci->dev; - u32 reg; - - reg =3D rockchip_pcie_readl_apb(rockchip, PCIE_CLIENT_INTR_STATUS_MISC); - rockchip_pcie_writel_apb(rockchip, reg, PCIE_CLIENT_INTR_STATUS_MISC); - - dev_dbg(dev, "PCIE_CLIENT_INTR_STATUS_MISC: %#x\n", reg); - dev_dbg(dev, "LTSSM_STATUS: %#x\n", rockchip_pcie_get_ltssm_reg(rockchip)= ); - - if (reg & PCIE_RDLH_LINK_UP_CHGED) { - if (rockchip_pcie_link_up(pci)) { - msleep(PCIE_RESET_CONFIG_WAIT_MS); - dev_dbg(dev, "Received Link up event. Starting enumeration!\n"); - /* Rescan the bus to enumerate endpoint devices */ - pci_lock_rescan_remove(); - pci_rescan_bus(pp->bridge->bus); - pci_unlock_rescan_remove(); - } - } - - return IRQ_HANDLED; -} - static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int irq, void *arg) { struct rockchip_pcie *rockchip =3D arg; @@ -576,29 +548,14 @@ static irqreturn_t rockchip_pcie_ep_sys_irq_thread(in= t irq, void *arg) return IRQ_HANDLED; } =20 -static int rockchip_pcie_configure_rc(struct platform_device *pdev, - struct rockchip_pcie *rockchip) +static int rockchip_pcie_configure_rc(struct rockchip_pcie *rockchip) { - struct device *dev =3D &pdev->dev; struct dw_pcie_rp *pp; - int irq, ret; u32 val; =20 if (!IS_ENABLED(CONFIG_PCIE_ROCKCHIP_DW_HOST)) return -ENODEV; =20 - irq =3D platform_get_irq_byname(pdev, "sys"); - if (irq < 0) - return irq; - - ret =3D devm_request_threaded_irq(dev, irq, NULL, - rockchip_pcie_rc_sys_irq_thread, - IRQF_ONESHOT, "pcie-sys-rc", rockchip); - if (ret) { - dev_err(dev, "failed to request PCIe sys IRQ\n"); - return ret; - } - /* LTSSM enable control mode */ val =3D FIELD_PREP_WM16(PCIE_LTSSM_ENABLE_ENHANCE, 1); rockchip_pcie_writel_apb(rockchip, val, PCIE_CLIENT_HOT_RESET_CTRL); @@ -610,17 +567,7 @@ static int rockchip_pcie_configure_rc(struct platform_= device *pdev, pp =3D &rockchip->pci.pp; pp->ops =3D &rockchip_pcie_host_ops; =20 - ret =3D dw_pcie_host_init(pp); - if (ret) { - dev_err(dev, "failed to initialize host\n"); - return ret; - } - - /* unmask DLL up/down indicator */ - val =3D FIELD_PREP_WM16(PCIE_RDLH_LINK_UP_CHGED, 0); - rockchip_pcie_writel_apb(rockchip, val, PCIE_CLIENT_INTR_MASK_MISC); - - return ret; + return dw_pcie_host_init(pp); } =20 static int rockchip_pcie_configure_ep(struct platform_device *pdev, @@ -739,7 +686,7 @@ static int rockchip_pcie_probe(struct platform_device *= pdev) =20 switch (data->mode) { case DW_PCIE_RC_TYPE: - ret =3D rockchip_pcie_configure_rc(pdev, rockchip); + ret =3D rockchip_pcie_configure_rc(rockchip); if (ret) goto deinit_clk; break; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8AB3B3E3A68; Sat, 28 Feb 2026 17:41:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300491; cv=none; b=PZ2Xfl2h63uVF11Cgmx/oOgGze0iDM+44FWgzAZwziNQk1rT1i5Zw5DYrXhMLEIiOhbFj/ofp4iDMOKqlDeg7e+fWmffoS8RJx0HaATp4LP2ysDyK1TS5jbA/ZdFT3Ue7h6QxAHZUgrUfVuvo1Rj8nxvwj1IFuVvkYail5FkuLg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300491; c=relaxed/simple; bh=9xWAJXabUR5GK/ln/eAx2cJ9fh0H1iqoBE+zwqWiD8I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aWX+YwrK5yJnqQQiSzKtSvNHqIP25QY+40V1bHuZ3s2Gu/uAksNXiWUDwMd7gpGAJGNXCmmYU8MPl2Ih4XjA4tLTSOc03a9sggQNMp0J77RTIY0MA4PCG8AbEO/iTZtJTautJdadH4yIin7Z5BQ126XFXzPdKg0gFyj2weyzOXQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oUkdAUxs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oUkdAUxs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C05EDC19424; Sat, 28 Feb 2026 17:41:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300491; bh=9xWAJXabUR5GK/ln/eAx2cJ9fh0H1iqoBE+zwqWiD8I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oUkdAUxsPBcjSH3E4re/ypdiYmfUGpubxr5WjvdLmH01WkY8GXn1QSqiSfPBpQc6m PvKTBKSV0rqCrFEJKkMidP2WMS0PwexOWGKI7BBXPStUiINspNV0xZDU6nYW+jDJVU Oa9qVfI4UtgxLCOlWK8ZrSg37vyYsyZ3hfQCqIloSwhBWIH7Qmct8/4qVIH7sAfYmB uNaNlYI71FYUl9yy8Hxqu7uprvH6xssIVNO5ZxopNoWF1CuaKYTPgsLcZT3BZaSnbX KrROwtsJ7jN0XHK4YIkCDN5V6lfvCXCV0iAN7Oupw0Auu/Wx0e6yfn3sWAoSvZPaxY Z4oUVd6GaHWmg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Cassel , Manivannan Sadhasivam , Shawn Lin , Sasha Levin Subject: [PATCH 6.19 529/844] Revert "PCI: qcom: Don't wait for link if we can detect Link Up" Date: Sat, 28 Feb 2026 12:27:22 -0500 Message-ID: <20260228173244.1509663-530-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Cassel [ Upstream commit e9ce5b3804436301ab343bc14203a4c14b336d1b ] This reverts commit 36971d6c5a9a134c15760ae9fd13c6d5f9a36abb. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] canno= t be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] canno= t be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] canno= t be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] canno= t be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (confl= icts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] ca= nnot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-11-cassel@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-qcom.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controlle= r/dwc/pcie-qcom.c index 5a318487b2b3f..9a115bacd3ad1 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -1957,10 +1957,6 @@ static int qcom_pcie_probe(struct platform_device *p= dev) =20 platform_set_drvdata(pdev, pcie); =20 - irq =3D platform_get_irq_byname_optional(pdev, "global"); - if (irq > 0) - pp->use_linkup_irq =3D true; - ret =3D dw_pcie_host_init(pp); if (ret) { dev_err(dev, "cannot initialize host\n"); @@ -1974,6 +1970,7 @@ static int qcom_pcie_probe(struct platform_device *pd= ev) goto err_host_deinit; } =20 + irq =3D platform_get_irq_byname_optional(pdev, "global"); if (irq > 0) { ret =3D devm_request_threaded_irq(&pdev->dev, irq, NULL, qcom_pcie_global_irq_thread, --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7ACB83E42B5; Sat, 28 Feb 2026 17:41:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300492; cv=none; b=Ns1Aw+mt4hllOqLSVcNWJT2b1HI3/1HuSFNYMnW6KbVbSx7lXwThiYk3pIDbJPLFDQnGPB5BOjz7j1S2ruqwTo42VmCpxD2SGmeWZGKIkoRHSrBkPCqaI06IiQDF6NhOTedzHYW0+yleVjs7fquewYGqykiqCvCtihmB/MGZO3Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300492; c=relaxed/simple; bh=CNNGRB+/cSD43pQ/yw1uq33wcrqwH0JA2at0sYhwcaQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tyhMPIaRFDgHGQ11zqFCxVHbSOoXHohmnxIn40FH0nWbwA0v+DZMbRWcKKBHkRFj/ddbDmmWnZOylWK3nh11xNqpn5afN9XzIAFc3ndD2IxQ1ZQjH9TcPouTgksmzgoBuKDtHfS8/Ak0cj0Y3lu+awpTHCnseCBpMe4ApAEjR9Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T8W7GZ//; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T8W7GZ//" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B285AC19423; Sat, 28 Feb 2026 17:41:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300492; bh=CNNGRB+/cSD43pQ/yw1uq33wcrqwH0JA2at0sYhwcaQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T8W7GZ//updzOm3STaogEvrzsEM0qEztZQQLJRk3Hsm93XRanL0ZlDcV776fPO+kA lwulbvODqQtPywyTeU0na+Nygo9utEIY8QBhcwiE7mKgtPgF2KJtGdov/qQKFl4ujG WseXfb2dqDYIQY9BQOXmE/bwQhhMKNzWXhiBQIqEeqsoXtonXxQH8htupqn4vM3C2s GrdOjPCLIyzeROy1CO3FlOYP8/icNQU73msqhsROv+GcAPtows7oj0YF4hAzu0ueoh klg6G4AG/2PCtXazYgrtYfcwtQej+UQ0QUzliRgGkdSbSzApLAOLitGLZ6GH3tGec0 1YSHMOEaHyQLw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Cassel , Manivannan Sadhasivam , Shawn Lin , Sasha Levin Subject: [PATCH 6.19 530/844] Revert "PCI: qcom: Enable MSI interrupts together with Link up if 'Global IRQ' is supported" Date: Sat, 28 Feb 2026 12:27:23 -0500 Message-ID: <20260228173244.1509663-531-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Cassel [ Upstream commit 7ebdefb87942073679e56cfbc5a72e8fc5441bfc ] This reverts commit ba4a2e2317b9faeca9193ed6d3193ddc3cf2aba3. Since the Link up IRQ support is going away, revert the MSI logic that got added for it too. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel [mani: reworded the description] Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-12-cassel@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-qcom.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controlle= r/dwc/pcie-qcom.c index 9a115bacd3ad1..39e5993d01e7c 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -136,7 +136,6 @@ =20 /* PARF_INT_ALL_{STATUS/CLEAR/MASK} register fields */ #define PARF_INT_ALL_LINK_UP BIT(13) -#define PARF_INT_MSI_DEV_0_7 GENMASK(30, 23) =20 /* PARF_NO_SNOOP_OVERRIDE register fields */ #define WR_NO_SNOOP_OVERRIDE_EN BIT(1) @@ -1981,8 +1980,7 @@ static int qcom_pcie_probe(struct platform_device *pd= ev) goto err_host_deinit; } =20 - writel_relaxed(PARF_INT_ALL_LINK_UP | PARF_INT_MSI_DEV_0_7, - pcie->parf + PARF_INT_ALL_MASK); + writel_relaxed(PARF_INT_ALL_LINK_UP, pcie->parf + PARF_INT_ALL_MASK); } =20 qcom_pcie_icc_opp_update(pcie); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9EB093E42D9; Sat, 28 Feb 2026 17:41:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300493; cv=none; b=J/3HLXG1WM8hS0AgY+LuTz+Ob1jfHBB0YV595/tOcbUAjSlcE9kIp8JODfhNiwaE2MU8JX5FxhMmDICcB60wtW/4iCn60E1ISVSk5roZs/x9X+4xuOMbQ5Myprwkwve4XFoCmIJfOugwFHQqS3zUxZuEWNBCOq1SICDot4aMS7M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300493; c=relaxed/simple; bh=1f5GrlWwRRZ4EonYB2QAeuWOl6xh/ytzWlhEoR/1f+8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H27Oi5LGyH1pOnrFMZeQQQUMYDVfdWtdBlcBag9uq6dtDwvLL/Zwf/oOYXJVgLg6ePhgfP4vL0Es3PTBkj5ZpKlK2YYjGogLlc9Cau/ICpWdf1gZf24KV/mUDk5T1HGX9R1OF9b5uzKx6Q4qETso3TjqwAoaMl7DW+pNwA4Dl4E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lKrJ96fY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lKrJ96fY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0B84C19425; Sat, 28 Feb 2026 17:41:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300493; bh=1f5GrlWwRRZ4EonYB2QAeuWOl6xh/ytzWlhEoR/1f+8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lKrJ96fYt/St0Wo39MD7bjMN0drmwbp1o2qa6S6b3Aa2IaAH15jayNiITfIauy6Cq fTIcAJZwqOmxFX8bpfV0cvPY9T4ZsvZdqBYzCcEQWj6Xm4Whcs5jVeMTs/abL1yAFN sfHXsOvZyfyRqm5elywcM9Ggg609FxcPmOApd3l+LpqSXRG3qA1f1u4h1eLxsBKooc JlyGkK8T803WPhwAwKb6ETABTRi+sWIyaZGCkw7K2SDiMppi251dXQB2JQmAG/4zUf c643x7LMtwjqETr4Ml4+IkCRFaqXvrLozzOGMTSNyiWZwoenedZilWTDoEQwC6Sw4w F6IC5G1Lz9r/A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Cassel , Manivannan Sadhasivam , Shawn Lin , Sasha Levin Subject: [PATCH 6.19 531/844] Revert "PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt" Date: Sat, 28 Feb 2026 12:27:24 -0500 Message-ID: <20260228173244.1509663-532-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Cassel [ Upstream commit 9a9793b55854422652ea92625e48277c4651c0fd ] This reverts commit 4581403f67929d02c197cb187c4e1e811c9e762a. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] canno= t be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] canno= t be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] canno= t be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] canno= t be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (confl= icts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] ca= nnot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-13-cassel@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-qcom.c | 58 +------------------------- 1 file changed, 1 insertion(+), 57 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controlle= r/dwc/pcie-qcom.c index 39e5993d01e7c..cf1cc7279c10d 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -55,9 +55,6 @@ #define PARF_AXI_MSTR_WR_ADDR_HALT_V2 0x1a8 #define PARF_Q2A_FLUSH 0x1ac #define PARF_LTSSM 0x1b0 -#define PARF_INT_ALL_STATUS 0x224 -#define PARF_INT_ALL_CLEAR 0x228 -#define PARF_INT_ALL_MASK 0x22c #define PARF_SID_OFFSET 0x234 #define PARF_BDF_TRANSLATE_CFG 0x24c #define PARF_DBI_BASE_ADDR_V2 0x350 @@ -134,9 +131,6 @@ /* PARF_LTSSM register fields */ #define LTSSM_EN BIT(8) =20 -/* PARF_INT_ALL_{STATUS/CLEAR/MASK} register fields */ -#define PARF_INT_ALL_LINK_UP BIT(13) - /* PARF_NO_SNOOP_OVERRIDE register fields */ #define WR_NO_SNOOP_OVERRIDE_EN BIT(1) #define RD_NO_SNOOP_OVERRIDE_EN BIT(3) @@ -1634,32 +1628,6 @@ static void qcom_pcie_init_debugfs(struct qcom_pcie = *pcie) qcom_pcie_link_transition_count); } =20 -static irqreturn_t qcom_pcie_global_irq_thread(int irq, void *data) -{ - struct qcom_pcie *pcie =3D data; - struct dw_pcie_rp *pp =3D &pcie->pci->pp; - struct device *dev =3D pcie->pci->dev; - u32 status =3D readl_relaxed(pcie->parf + PARF_INT_ALL_STATUS); - - writel_relaxed(status, pcie->parf + PARF_INT_ALL_CLEAR); - - if (FIELD_GET(PARF_INT_ALL_LINK_UP, status)) { - msleep(PCIE_RESET_CONFIG_WAIT_MS); - dev_dbg(dev, "Received Link up event. Starting enumeration!\n"); - /* Rescan the bus to enumerate endpoint devices */ - pci_lock_rescan_remove(); - pci_rescan_bus(pp->bridge->bus); - pci_unlock_rescan_remove(); - - qcom_pcie_icc_opp_update(pcie); - } else { - dev_WARN_ONCE(dev, 1, "Received unknown event. INT_STATUS: 0x%08x\n", - status); - } - - return IRQ_HANDLED; -} - static void qcom_pci_free_msi(void *ptr) { struct dw_pcie_rp *pp =3D (struct dw_pcie_rp *)ptr; @@ -1804,8 +1772,7 @@ static int qcom_pcie_probe(struct platform_device *pd= ev) struct dw_pcie_rp *pp; struct resource *res; struct dw_pcie *pci; - int ret, irq; - char *name; + int ret; =20 pcie_cfg =3D of_device_get_match_data(dev); if (!pcie_cfg) { @@ -1962,27 +1929,6 @@ static int qcom_pcie_probe(struct platform_device *p= dev) goto err_phy_exit; } =20 - name =3D devm_kasprintf(dev, GFP_KERNEL, "qcom_pcie_global_irq%d", - pci_domain_nr(pp->bridge->bus)); - if (!name) { - ret =3D -ENOMEM; - goto err_host_deinit; - } - - irq =3D platform_get_irq_byname_optional(pdev, "global"); - if (irq > 0) { - ret =3D devm_request_threaded_irq(&pdev->dev, irq, NULL, - qcom_pcie_global_irq_thread, - IRQF_ONESHOT, name, pcie); - if (ret) { - dev_err_probe(&pdev->dev, ret, - "Failed to request Global IRQ\n"); - goto err_host_deinit; - } - - writel_relaxed(PARF_INT_ALL_LINK_UP, pcie->parf + PARF_INT_ALL_MASK); - } - qcom_pcie_icc_opp_update(pcie); =20 if (pcie->mhi) @@ -1990,8 +1936,6 @@ static int qcom_pcie_probe(struct platform_device *pd= ev) =20 return 0; =20 -err_host_deinit: - dw_pcie_host_deinit(pp); err_phy_exit: list_for_each_entry_safe(port, tmp, &pcie->ports, list) { phy_exit(port->phy); --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DA173E4C2B; Sat, 28 Feb 2026 17:41:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300494; cv=none; b=ntLL6lEhoAvI91NW7EX72bnWmHWnClzVHh2wucDOZ9DEn6Bv+Hg6yUkV3jg02814Jfis8Yu8SYZJ/byBrtCSNCUs94I3jCLVAfWjKleMAk7I1MitehHiSkpj9cD7Jue3X/plj7usCjjKhTki8zO3HFT3fLl6Bv3HgNE4IjpIM7Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300494; c=relaxed/simple; bh=mvRK+eJFC/K0QtufeUzejxGBrxL/D/eHAMBbFeIM1/4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hmvIE7tOkZYvQZL1W1NX2u8aNxMSeRz/J2ZK/jgXe/wHUumU/ABAoUBQ4F7hHT42XblpIyzQzFqiLavi3EGG6Go2nMKyVYGIHVREDXtT6Nz/wS6saE94djhAX9YdQRJ8cXBAZxYNFJukBMwwp02ocW+Sb5hdKqw7a32cHbwrVbs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qf7hFa8r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qf7hFa8r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E681C2BC9E; Sat, 28 Feb 2026 17:41:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300494; bh=mvRK+eJFC/K0QtufeUzejxGBrxL/D/eHAMBbFeIM1/4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qf7hFa8rWkZBvEQl3nOawODlMF1c2cgXa0N2pU88Fl7bcNC6lmYlGYFu7Gfc2woJA MvD4ZxJkBeRQPrN/CmqgxFm9ilCsDDAfmiIoDlcjP5dxjuHE+DC9DPU70a/p6Q8p4+ k+AEll/q+qiT0ez7FlM45MX1td4WhhXijfGfL+2wpFTPnbdO3d5D+hISaRglZD3lVH 5Jyi+kxndZ0yvU5UKoujImEuS/qZqnHu9o/da/CmiBrS1v+/RpiJyGdZRJUfF5ZhuV 7HsDE7Ll5gOTNALJCJUS+WuJoXDs3gOErnVQvXj7rKstDQpGuAKW1BjVR8qhCX7Dez 2R+4vUZQx0Wcg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Cassel , Manivannan Sadhasivam , Shawn Lin , Sasha Levin Subject: [PATCH 6.19 532/844] Revert "PCI: dwc: Don't wait for link up if driver can detect Link Up event" Date: Sat, 28 Feb 2026 12:27:25 -0500 Message-ID: <20260228173244.1509663-533-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Cassel [ Upstream commit 142d5869f6eec3110adda0ad2d931f5b3c22371d ] This reverts commit 8d3bf19f1b585a3cc0027f508b64c33484db8d0d. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] canno= t be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] canno= t be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] canno= t be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (co= nflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (confl= icts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] canno= t be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (confl= icts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] ca= nnot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. So revert the change that skipped dw_pcie_wait_for_link() if the Link up IRQ was used by a vendor glue driver. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-14-cassel@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-designware-host.c | 10 ++-------- drivers/pci/controller/dwc/pcie-designware.h | 1 - 2 files changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pc= i/controller/dwc/pcie-designware-host.c index 250725ced9026..f1c7d50eba746 100644 --- a/drivers/pci/controller/dwc/pcie-designware-host.c +++ b/drivers/pci/controller/dwc/pcie-designware-host.c @@ -665,14 +665,8 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp) goto err_remove_edma; } =20 - /* - * Note: Skip the link up delay only when a Link Up IRQ is present. - * If there is no Link Up IRQ, we should not bypass the delay - * because that would require users to manually rescan for devices. - */ - if (!pp->use_linkup_irq) - /* Ignore errors, the link may come up later */ - dw_pcie_wait_for_link(pci); + /* Ignore errors, the link may come up later */ + dw_pcie_wait_for_link(pci); =20 ret =3D pci_host_probe(bridge); if (ret) diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/con= troller/dwc/pcie-designware.h index ed1801dd8e39a..6f0dfdde1d577 100644 --- a/drivers/pci/controller/dwc/pcie-designware.h +++ b/drivers/pci/controller/dwc/pcie-designware.h @@ -442,7 +442,6 @@ struct dw_pcie_rp { bool use_atu_msg; int msg_atu_index; struct resource *msg_res; - bool use_linkup_irq; struct pci_eq_presets presets; struct pci_config_window *cfg; bool ecam_enabled; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7142A3E4C43; Sat, 28 Feb 2026 17:41:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300495; cv=none; b=rC0PKb3UYI9iqGBvDzdpbVJ8PGGkHEaf47SsCtVsCdLNvZqCJrby5X1UOa9RBsLKcNtlcSHk5bx61eoorAqG/sE0Lday3xVl32l2m39f+ZUgjj4T39xggN5dqcHDNSvELiOV13AGUOKdxTNF8t8mfCAigwuYSyNgTOkDMcAcdn0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300495; c=relaxed/simple; bh=H0ovsNNbol36+Kife4HmUx+3WE90tqwXkjqiM5xAd+w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OQzB8FJzQCDeYqL1Hn49MtB5zfUceheuIxluH3fUESfKTFjhp83+uGsEEoDRiST+Rpk85PX5nes0UnR2S7dXrNDqBXGGMqdhhftjJh1NdSvw7632UJnmpAN5yRdk5IEbNbW/v2BA/NlRcvLUYNI6G9lXj2LQ8f5xCNRjqYrTBeA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FNS1as3n; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FNS1as3n" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E462C116D0; Sat, 28 Feb 2026 17:41:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300495; bh=H0ovsNNbol36+Kife4HmUx+3WE90tqwXkjqiM5xAd+w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FNS1as3nYMx/NT903vP91IA1NY9tTXiSq0BQ0N488IrgjfFiF0SgRxKPqerbxpj6/ bv7imBtxatf+uYGWgW3HmkIIdoflGgeGTw6xegh3fmnAfRoQ7fnyc4mBBZFEbcWIlb wRcrp+I/SM3BAJod7Kpip+K8I13b/2BcJxVXya7BnQ8LEwzLl4nAaHXofDc4WhIi0r plokd2nEz/wIurZ5ftyhBSV581mu/FoQgtNVn3HWT6Uqix9SxHmoeBf3xuFW6vNTWv qg1rozxYHMlMecA1ZpOt/fFa63q5KelC1GoCpsbtnRvKovzv+yQP+/4CN7ifRc9H/t TjoF8aCglks0A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Bjorn Helgaas , Andy Shevchenko , Christian Marangi , Sasha Levin Subject: [PATCH 6.19 533/844] PCI: Use resource_set_range() that correctly sets ->end Date: Sat, 28 Feb 2026 12:27:26 -0500 Message-ID: <20260228173244.1509663-534-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ilpo J=C3=A4rvinen [ Upstream commit 11721c45a8266a9d0c9684153d20e37159465f96 ] __pci_read_base() sets resource start and end addresses when resource is larger than 4G but pci_bus_addr_t or resource_size_t are not capable of representing 64-bit PCI addresses. This creates a problematic resource that has non-zero flags but the start and end addresses do not yield to resource size of 0 but 1. Replace custom resource addresses setup with resource_set_range() that correctly sets end address as -1 which results in resource_size() returning 0. For consistency, also use resource_set_range() in the other branch that does size based resource setup. Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than = 4GB") Link: https://lore.kernel.org/all/20251207215359.28895-1-ansuelsmth@gmail.c= om/T/#m990492684913c5a158ff0e5fc90697d8ad95351b Signed-off-by: Ilpo J=C3=A4rvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Cc: Christian Marangi Link: https://patch.msgid.link/20251208145654.5294-1-ilpo.jarvinen@linux.in= tel.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/probe.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index c791bca2891f6..cd1cd044aaf9d 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -287,8 +287,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_t= ype type, if ((sizeof(pci_bus_addr_t) < 8 || sizeof(resource_size_t) < 8) && sz64 > 0x100000000ULL) { res->flags |=3D IORESOURCE_UNSET | IORESOURCE_DISABLED; - res->start =3D 0; - res->end =3D 0; + resource_set_range(res, 0, 0); pci_err(dev, "%s: can't handle BAR larger than 4GB (size %#010llx)\n", res_name, (unsigned long long)sz64); goto out; @@ -297,8 +296,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_t= ype type, if ((sizeof(pci_bus_addr_t) < 8) && l) { /* Above 32-bit boundary; try to reallocate */ res->flags |=3D IORESOURCE_UNSET; - res->start =3D 0; - res->end =3D sz64 - 1; + resource_set_range(res, 0, sz64); pci_info(dev, "%s: can't handle BAR above 4GB (bus address %#010llx)\n", res_name, (unsigned long long)l64); goto out; --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 116253E5561; Sat, 28 Feb 2026 17:41:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300497; cv=none; b=CMp8gfFlXvUuWMkx5UtYDxmo+ZawhvDD3BQ2KJKJ583PVQCjCgg65+ytZk+POE9Zn6c3gCs2gLMQWRouHLOH/JjO7YwBhMfeNE2bgTUeblvyhtoo2UrG9IBKyEjMT3o94QmLq80JCMjMBQ14Bpzo8NGgroO7EK5tYyeW7bfvFdE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300497; c=relaxed/simple; bh=AjAQXFisJm/Eas+GLafEiwdUxi1bQw/9vGwZ4WFuURU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=D7xqLfn6vow36e19ohYuGv/r4S+jZ0amiUQ1xepiU4qi3t3qhq4fiObaHE8j74puESu1P6W2RhQMGq6RuQQHSNX1jxVv0tqgQHHHIK+U8Z8JQHYRtCBxb+kBZNyMGucC1kEWtm4cLjQi5CwqCUKLpr/Q3m92hEAz9+V91dZEs24= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=edMqcdeq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="edMqcdeq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1C24C19423; Sat, 28 Feb 2026 17:41:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300496; bh=AjAQXFisJm/Eas+GLafEiwdUxi1bQw/9vGwZ4WFuURU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=edMqcdeqNNpgfjY0QzWjCOdEVAX3zukM8a6I2fZLFMXT8XGZSb/GBnpZ1Vuyc4POg uMrOsom5UfhGpjS6jt6cKPWjzzqwkQKEW5+PHTFp56R4WO8WM0eP6QHfK/981nwB45 XGsQ38Mr/gKqgH9O8X5gE2vGNfnemjZ4staHT+i0xzGfiCwIBIjiTBGQUT0RUe6gLt Dljxm3jaYnRLP+4qSaMjsxcdwh46DZROEV/9O7Ysipur3bylSn2NOhBEVpl/JeexAC H9FnE94wRfCpgxrF4/dNo1O+2kJdhWruSQMAReu6zTxGThhzA/hvEfXodG0mvUoWnW AWAmfl6Qyu9Vg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Manivannan Sadhasivam , Johan Hovold , Chris Lew , Jeff Hugo , Loic Poulain , Jeff Johnson , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 534/844] net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels Date: Sat, 28 Feb 2026 12:27:27 -0500 Message-ID: <20260228173244.1509663-535-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Manivannan Sadhasivam [ Upstream commit 51731792a25cb312ca94cdccfa139eb46de1b2ef ] MHI stack offers the 'auto_queue' feature, which allows the MHI stack to auto queue the buffers for the RX path (DL channel). Though this feature simplifies the client driver design, it introduces race between the client drivers and the MHI stack. For instance, with auto_queue, the 'dl_callback' for the DL channel may get called before the client driver is fully probed. This means, by the time the dl_callback gets called, the client driver's structures might not be initialized, leading to NULL ptr dereference. Currently, the drivers have to workaround this issue by initializing the internal structures before calling mhi_prepare_for_transfer_autoqueue(). But even so, there is a chance that the client driver's internal code path may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is called, leading to similar NULL ptr dereference. This issue has been reported on the Qcom X1E80100 CRD machines affecting boot. So to properly fix all these races, drop the MHI 'auto_queue' feature altogether and let the client driver (QRTR) manage the RX buffers manually. In the QRTR driver, queue the RX buffers based on the ring length during probe and recycle the buffers in 'dl_callback' once they are consumed. This also warrants removing the setting of 'auto_queue' flag from controller drivers. Currently, this 'auto_queue' feature is only enabled for IPCR DL channel. So only the QRTR client driver requires the modification. Fixes: 227fee5fc99e ("bus: mhi: core: Add an API for auto queueing buffers = for DL channel") Fixes: 68a838b84eff ("net: qrtr: start MHI channel after endpoit creation") Reported-by: Johan Hovold Closes: https://lore.kernel.org/linux-arm-msm/ZyTtVdkCCES0lkl4@hovoldconsul= ting.com Suggested-by: Chris Lew Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeff Hugo Reviewed-by: Loic Poulain Acked-by: Jeff Johnson # drivers/net/wireless/ath/... Acked-by: Jeff Hugo Acked-by: Paolo Abeni Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251218-qrtr-fix-v2-1-c7499bfcfbe0@oss.qual= comm.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/accel/qaic/mhi_controller.c | 44 ----------------- drivers/bus/mhi/host/pci_generic.c | 20 +------- drivers/net/wireless/ath/ath11k/mhi.c | 4 -- drivers/net/wireless/ath/ath12k/mhi.c | 4 -- net/qrtr/mhi.c | 69 ++++++++++++++++++++++----- 5 files changed, 60 insertions(+), 81 deletions(-) diff --git a/drivers/accel/qaic/mhi_controller.c b/drivers/accel/qaic/mhi_c= ontroller.c index 13a14c6c61689..4d787f77ce419 100644 --- a/drivers/accel/qaic/mhi_controller.c +++ b/drivers/accel/qaic/mhi_controller.c @@ -39,7 +39,6 @@ static const struct mhi_channel_config aic100_channels[] = =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -55,7 +54,6 @@ static const struct mhi_channel_config aic100_channels[] = =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -71,7 +69,6 @@ static const struct mhi_channel_config aic100_channels[] = =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -87,7 +84,6 @@ static const struct mhi_channel_config aic100_channels[] = =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -103,7 +99,6 @@ static const struct mhi_channel_config aic100_channels[]= =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -119,7 +114,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -135,7 +129,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -151,7 +144,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -167,7 +159,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -183,7 +174,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -199,7 +189,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -215,7 +204,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -231,7 +219,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -247,7 +234,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -263,7 +249,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -279,7 +264,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -295,7 +279,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -311,7 +294,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -327,7 +309,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -343,7 +324,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -359,7 +339,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -375,7 +354,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -391,7 +369,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -407,7 +384,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -423,7 +399,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -439,7 +414,6 @@ static const struct mhi_channel_config aic100_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D true, .wake_capable =3D false, }, }; @@ -458,7 +432,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -474,7 +447,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -490,7 +462,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -506,7 +477,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -522,7 +492,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -538,7 +507,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -554,7 +522,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -570,7 +537,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -586,7 +552,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -602,7 +567,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -618,7 +582,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -634,7 +597,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -650,7 +612,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -666,7 +627,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -682,7 +642,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -698,7 +657,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -714,7 +672,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, .wake_capable =3D false, }, { @@ -730,7 +687,6 @@ static const struct mhi_channel_config aic200_channels[= ] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D true, .wake_capable =3D false, }, }; diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_= generic.c index e3bc737313a2f..0884a384b77fc 100644 --- a/drivers/bus/mhi/host/pci_generic.c +++ b/drivers/bus/mhi/host/pci_generic.c @@ -94,22 +94,6 @@ struct mhi_pci_dev_info { .doorbell_mode_switch =3D false, \ } =20 -#define MHI_CHANNEL_CONFIG_DL_AUTOQUEUE(ch_num, ch_name, el_count, ev_ring= ) \ - { \ - .num =3D ch_num, \ - .name =3D ch_name, \ - .num_elements =3D el_count, \ - .event_ring =3D ev_ring, \ - .dir =3D DMA_FROM_DEVICE, \ - .ee_mask =3D BIT(MHI_EE_AMSS), \ - .pollcfg =3D 0, \ - .doorbell =3D MHI_DB_BRST_DISABLE, \ - .lpm_notify =3D false, \ - .offload_channel =3D false, \ - .doorbell_mode_switch =3D false, \ - .auto_queue =3D true, \ - } - #define MHI_EVENT_CONFIG_CTRL(ev_ring, el_count) \ { \ .num_elements =3D el_count, \ @@ -329,7 +313,7 @@ static const struct mhi_channel_config modem_qcom_v1_mh= i_channels[] =3D { MHI_CHANNEL_CONFIG_UL(14, "QMI", 4, 0), MHI_CHANNEL_CONFIG_DL(15, "QMI", 4, 0), MHI_CHANNEL_CONFIG_UL(20, "IPCR", 8, 0), - MHI_CHANNEL_CONFIG_DL_AUTOQUEUE(21, "IPCR", 8, 0), + MHI_CHANNEL_CONFIG_DL(21, "IPCR", 8, 0), MHI_CHANNEL_CONFIG_UL_FP(34, "FIREHOSE", 32, 0), MHI_CHANNEL_CONFIG_DL_FP(35, "FIREHOSE", 32, 0), MHI_CHANNEL_CONFIG_UL(46, "IP_SW0", 64, 2), @@ -762,7 +746,7 @@ static const struct mhi_channel_config mhi_telit_fn980_= hw_v1_channels[] =3D { MHI_CHANNEL_CONFIG_UL(14, "QMI", 32, 0), MHI_CHANNEL_CONFIG_DL(15, "QMI", 32, 0), MHI_CHANNEL_CONFIG_UL(20, "IPCR", 16, 0), - MHI_CHANNEL_CONFIG_DL_AUTOQUEUE(21, "IPCR", 16, 0), + MHI_CHANNEL_CONFIG_DL(21, "IPCR", 16, 0), MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0", 128, 1), MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0", 128, 2), }; diff --git a/drivers/net/wireless/ath/ath11k/mhi.c b/drivers/net/wireless/a= th/ath11k/mhi.c index acd76e9392d31..d2c44f7f9b622 100644 --- a/drivers/net/wireless/ath/ath11k/mhi.c +++ b/drivers/net/wireless/ath/ath11k/mhi.c @@ -34,7 +34,6 @@ static const struct mhi_channel_config ath11k_mhi_channel= s_qca6390[] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, }, { .num =3D 21, @@ -48,7 +47,6 @@ static const struct mhi_channel_config ath11k_mhi_channel= s_qca6390[] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D true, }, }; =20 @@ -99,7 +97,6 @@ static const struct mhi_channel_config ath11k_mhi_channel= s_qcn9074[] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, }, { .num =3D 21, @@ -113,7 +110,6 @@ static const struct mhi_channel_config ath11k_mhi_chann= els_qcn9074[] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D true, }, }; =20 diff --git a/drivers/net/wireless/ath/ath12k/mhi.c b/drivers/net/wireless/a= th/ath12k/mhi.c index 08f44baf182a5..2dbdb95ae7bea 100644 --- a/drivers/net/wireless/ath/ath12k/mhi.c +++ b/drivers/net/wireless/ath/ath12k/mhi.c @@ -31,7 +31,6 @@ static const struct mhi_channel_config ath12k_mhi_channel= s_qcn9274[] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, }, { .num =3D 21, @@ -45,7 +44,6 @@ static const struct mhi_channel_config ath12k_mhi_channel= s_qcn9274[] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D true, }, }; =20 @@ -96,7 +94,6 @@ static const struct mhi_channel_config ath12k_mhi_channel= s_wcn7850[] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D false, }, { .num =3D 21, @@ -110,7 +107,6 @@ static const struct mhi_channel_config ath12k_mhi_chann= els_wcn7850[] =3D { .lpm_notify =3D false, .offload_channel =3D false, .doorbell_mode_switch =3D false, - .auto_queue =3D true, }, }; =20 diff --git a/net/qrtr/mhi.c b/net/qrtr/mhi.c index 69f53625a049d..80e341d2f8a45 100644 --- a/net/qrtr/mhi.c +++ b/net/qrtr/mhi.c @@ -24,13 +24,25 @@ static void qcom_mhi_qrtr_dl_callback(struct mhi_device= *mhi_dev, struct qrtr_mhi_dev *qdev =3D dev_get_drvdata(&mhi_dev->dev); int rc; =20 - if (!qdev || mhi_res->transaction_status) + if (!qdev || (mhi_res->transaction_status && mhi_res->transaction_status = !=3D -ENOTCONN)) return; =20 + /* Channel got reset. So just free the buffer */ + if (mhi_res->transaction_status =3D=3D -ENOTCONN) { + devm_kfree(&mhi_dev->dev, mhi_res->buf_addr); + return; + } + rc =3D qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd); if (rc =3D=3D -EINVAL) dev_err(qdev->dev, "invalid ipcrouter packet\n"); + + /* Done with the buffer, now recycle it for future use */ + rc =3D mhi_queue_buf(mhi_dev, DMA_FROM_DEVICE, mhi_res->buf_addr, + mhi_dev->mhi_cntrl->buffer_len, MHI_EOT); + if (rc) + dev_err(&mhi_dev->dev, "Failed to recycle the buffer: %d\n", rc); } =20 /* From QRTR to MHI */ @@ -72,6 +84,29 @@ static int qcom_mhi_qrtr_send(struct qrtr_endpoint *ep, = struct sk_buff *skb) return rc; } =20 +static int qcom_mhi_qrtr_queue_dl_buffers(struct mhi_device *mhi_dev) +{ + u32 free_desc; + void *buf; + int ret; + + free_desc =3D mhi_get_free_desc_count(mhi_dev, DMA_FROM_DEVICE); + while (free_desc--) { + buf =3D devm_kmalloc(&mhi_dev->dev, mhi_dev->mhi_cntrl->buffer_len, GFP_= KERNEL); + if (!buf) + return -ENOMEM; + + ret =3D mhi_queue_buf(mhi_dev, DMA_FROM_DEVICE, buf, mhi_dev->mhi_cntrl-= >buffer_len, + MHI_EOT); + if (ret) { + dev_err(&mhi_dev->dev, "Failed to queue buffer: %d\n", ret); + return ret; + } + } + + return 0; +} + static int qcom_mhi_qrtr_probe(struct mhi_device *mhi_dev, const struct mhi_device_id *id) { @@ -87,20 +122,30 @@ static int qcom_mhi_qrtr_probe(struct mhi_device *mhi_= dev, qdev->ep.xmit =3D qcom_mhi_qrtr_send; =20 dev_set_drvdata(&mhi_dev->dev, qdev); - rc =3D qrtr_endpoint_register(&qdev->ep, QRTR_EP_NID_AUTO); - if (rc) - return rc; =20 /* start channels */ - rc =3D mhi_prepare_for_transfer_autoqueue(mhi_dev); - if (rc) { - qrtr_endpoint_unregister(&qdev->ep); + rc =3D mhi_prepare_for_transfer(mhi_dev); + if (rc) return rc; - } + + rc =3D qrtr_endpoint_register(&qdev->ep, QRTR_EP_NID_AUTO); + if (rc) + goto err_unprepare; + + rc =3D qcom_mhi_qrtr_queue_dl_buffers(mhi_dev); + if (rc) + goto err_unregister; =20 dev_dbg(qdev->dev, "Qualcomm MHI QRTR driver probed\n"); =20 return 0; + +err_unregister: + qrtr_endpoint_unregister(&qdev->ep); +err_unprepare: + mhi_unprepare_from_transfer(mhi_dev); + + return rc; } =20 static void qcom_mhi_qrtr_remove(struct mhi_device *mhi_dev) @@ -151,11 +196,13 @@ static int __maybe_unused qcom_mhi_qrtr_pm_resume_ear= ly(struct device *dev) if (state =3D=3D MHI_STATE_M3) return 0; =20 - rc =3D mhi_prepare_for_transfer_autoqueue(mhi_dev); - if (rc) + rc =3D mhi_prepare_for_transfer(mhi_dev); + if (rc) { dev_err(dev, "failed to prepare for autoqueue transfer %d\n", rc); + return rc; + } =20 - return rc; + return qcom_mhi_qrtr_queue_dl_buffers(mhi_dev); } =20 static const struct dev_pm_ops qcom_mhi_qrtr_pm_ops =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:11 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB2973E557D; Sat, 28 Feb 2026 17:41:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300497; cv=none; b=dJUmI4oTQ1ol1LPjt6D7eMqVEuhm5wX6/H2DvHTuQx4iuFanizfazOhvTzXgOUW+SecMvlNBtu6m6oAOTbULmY4EVu4lRmb2TYqI2jQ62hT8ueXqTwBqpyYrGtnJkbc6thTZCplATF4NUEF1CQCYUPOK3+Pry6wXAL/LUePb3uA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300497; c=relaxed/simple; bh=FbUwHqWJZ1clU++cKGaAtloRHsD74SCvaxpYluc92Qg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=C3KwSWSL7uwo0Ta+RmUC9qpTyGVe3Vd5hxBI4D4SSeRqo5IrM/YerMmRtoW7uyEiefgNrJ4E8wZzBtqFmrypA8UER8j/i2aoAfOSRiLaIllMQUSJZz3u6J3HsJujC2lE/8I+QeCcXWTfkaCwcmqdyOh5mtRzoS/WBDhQ+DlX5QI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RgFCyxPA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RgFCyxPA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1E9DC19425; Sat, 28 Feb 2026 17:41:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300497; bh=FbUwHqWJZ1clU++cKGaAtloRHsD74SCvaxpYluc92Qg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RgFCyxPAVziZYRjns7YfVJ8Gz40rhoEm7iobZwnPMop0kzUfF1kTngVo8VryjvkhA yn9x3nToH3z32qGqx/i+iF4O0rDWn+iZHVi9wlybOSGf7hbYjoKizMloUuad86K+wT Jh1hVAhviy5ZnSQauz5h0etnbsfTqKNyxBJPUVjC0jv83U/AfIUvkcYWRCbbBu7vsh eF5QVMjDmW75Y/WcSRbiAE1OS5v24gTy/h4jvjRQ2bwSrw+1Vnez1vhCs3IOWHjyc5 VJiZxCkNrSigsq0iYZ8yLeWwy3ICzxWAhz40OTROQcxBoDUAo+mOtMSLVjMqVULD3t lRxKAxsZ5Uozw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Abel Vesa , Dmitry Baryshkov , Bjorn Andersson , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 535/844] phy: qcom: edp: Make the number of clocks flexible Date: Sat, 28 Feb 2026 12:27:28 -0500 Message-ID: <20260228173244.1509663-536-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Abel Vesa [ Upstream commit 7d51b709262c5aa31d2b9cd31444112c1b2dae03 ] On X Elite, the DP PHY needs another clock called ref, while all other platforms do not. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So in order to handle these clocks on different platforms, make the driver get all the clocks regardless of how many there are provided. Cc: stable@vger.kernel.org # v6.10 Fixes: db83c107dc29 ("phy: qcom: edp: Add v6 specific ops and X1E80100 plat= form support") Reviewed-by: Dmitry Baryshkov Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-missing-refclk-v5-= 2-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/phy/qualcomm/phy-qcom-edp.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy= -qcom-edp.c index f1b51018683d5..06a08c9ea0f70 100644 --- a/drivers/phy/qualcomm/phy-qcom-edp.c +++ b/drivers/phy/qualcomm/phy-qcom-edp.c @@ -103,7 +103,9 @@ struct qcom_edp { =20 struct phy_configure_opts_dp dp_opts; =20 - struct clk_bulk_data clks[2]; + struct clk_bulk_data *clks; + int num_clks; + struct regulator_bulk_data supplies[2]; =20 bool is_edp; @@ -218,7 +220,7 @@ static int qcom_edp_phy_init(struct phy *phy) if (ret) return ret; =20 - ret =3D clk_bulk_prepare_enable(ARRAY_SIZE(edp->clks), edp->clks); + ret =3D clk_bulk_prepare_enable(edp->num_clks, edp->clks); if (ret) goto out_disable_supplies; =20 @@ -885,7 +887,7 @@ static int qcom_edp_phy_exit(struct phy *phy) { struct qcom_edp *edp =3D phy_get_drvdata(phy); =20 - clk_bulk_disable_unprepare(ARRAY_SIZE(edp->clks), edp->clks); + clk_bulk_disable_unprepare(edp->num_clks, edp->clks); regulator_bulk_disable(ARRAY_SIZE(edp->supplies), edp->supplies); =20 return 0; @@ -1092,11 +1094,9 @@ static int qcom_edp_phy_probe(struct platform_device= *pdev) if (IS_ERR(edp->pll)) return PTR_ERR(edp->pll); =20 - edp->clks[0].id =3D "aux"; - edp->clks[1].id =3D "cfg_ahb"; - ret =3D devm_clk_bulk_get(dev, ARRAY_SIZE(edp->clks), edp->clks); - if (ret) - return ret; + edp->num_clks =3D devm_clk_bulk_get_all(dev, &edp->clks); + if (edp->num_clks < 0) + return dev_err_probe(dev, edp->num_clks, "failed to get clocks\n"); =20 edp->supplies[0].supply =3D "vdda-phy"; edp->supplies[1].supply =3D "vdda-pll"; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F3A873E558F; Sat, 28 Feb 2026 17:41:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300499; cv=none; b=HvEt93gLXOmu49kE9EWKwSgxs/goCh1fFJ6nMk6jkHlQ6ygCKKAOIL2CpiMBL6u/vHnu58JUoHb0O5I91PkugWPCsPx+wfDW+/f1wYgHRh50DPrzkjTG0nZHaL8QtGnpVr6meJY70S0gmxmx/Ic7YLWAGb2UVExZjgQHQxRS9AQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300499; c=relaxed/simple; bh=lcawo1snmYO4JkAn7IB+DhZ12UD686+CTTT4COmR6yE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FtWuyL+2REAE9DwfgoQ/Fd+DealnYVjHtpXoAK7hN+f3RAz7GkvPzXQ9ROB0cF2ME/PrLYkazIlR3NJsVvaeUrLlm1tuQHY7+BPhog6T+4VIgTNRYMcX7GmrnMsDomRw72tYas5lukpaCRyNg/VkknDL6eRFzrn1FtfjiHvtlPQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IwyNQYxf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IwyNQYxf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03926C116D0; Sat, 28 Feb 2026 17:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300498; bh=lcawo1snmYO4JkAn7IB+DhZ12UD686+CTTT4COmR6yE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IwyNQYxfMl4ZjAaLdEpqYQas04OtobQqKGKRlsi8+nPo5D0RB7FUGfkqlYWe0N1Gq b5yD03ONIXrRjhNrpqDCscj4AfpOyKKkQv0UIYhGWxbH5LkLbaqYKq8eKghRHi2lwf gz9u5ajUoqGXwHCNGac0j3dc0INSr4OjR7FZLwRMdkQDKu0yJqwxnLvHDzYqRWBqBi 1x5MJkZhQlBj5LgLXRVvvG6h+BN99tSCF/E3oLr93vXArqnxpCCyMjRTHVJEGWc+W5 l0tbFnB0E/KxbKXiJzp9iuE3fydene4rbNR1sJ4ELBR1pkEWboyaM7CrGEYFRHLi1W tIyss/u0yGjjw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alexey Minnekhanov , Dmitry Baryshkov , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.19 536/844] arm64: dts: qcom: sdm630: Add missing MDSS reset Date: Sat, 28 Feb 2026 12:27:29 -0500 Message-ID: <20260228173244.1509663-537-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexey Minnekhanov [ Upstream commit 0c1d1591f898d54eaa4c8f2a1535ab21bf4e42e4 ] If the OS does not support recovering the state left by the bootloader it needs a way to reset display hardware, so that it can start from a clean state. Add a reference to the relevant reset. It fixes display init issue appeared in Linux v6.17: without reset device boots into black screen and you need to turn display off/on to "fix" it. Also sometimes it can boot into solid blue color with these messages in kernel log: hw recovery is not complete for ctl:2 [drm:dpu_encoder_phys_vid_prepare_for_kickoff:569] [dpu error]enc33 intf1 ctl 2 reset failure: -22 [drm:dpu_encoder_frame_done_timeout:2727] [dpu error]enc33 frame done timeout Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync= _state") Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Alexey Minnekhanov Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251116-sdm660-mdss-reset-v2-3-6219bec0a97= f@postmarketos.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/qcom/sdm630.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qco= m/sdm630.dtsi index b383e480a394d..876a6871745cf 100644 --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi @@ -1563,6 +1563,7 @@ mdss: display-subsystem@c900000 { reg-names =3D "mdss_phys", "vbif_phys"; =20 power-domains =3D <&mmcc MDSS_GDSC>; + resets =3D <&mmcc MDSS_BCR>; =20 clocks =3D <&mmcc MDSS_AHB_CLK>, <&mmcc MDSS_AXI_CLK>, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D07263E4C37; Sat, 28 Feb 2026 17:41:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300499; cv=none; b=aRL8dVsoOObiUX6zPJ4C/1ksO1G9qgVFfWRneqkCqT+TixTyGyxonsBUSiKEyUR2lh+6Wyx9wBhFU5rA7FsOGZzev90bjI8lOEM//0o7jRSPwkijPAf8cwHcEnFqgOR6G8IFNnJFeocol69Ry84gwux3BZj0m3ihu6Sz5UzDQE0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300499; c=relaxed/simple; bh=N3whK/Qab7sabZq+ciegNfhuZ8/gv7147eDSqfVOTMY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cneME1tAohqzIEOEg+9YGou1jU4SSrTf+WHMsxe6h/C2+Zpj26A2tO6qGGS9AVWhf/afvM745X20cAMBUmhar6CqDfBdjMFGHukNXbU3V7xyVQcLZFO9ZcsD/aoLa0cyl9cjrnFU8Ri9XbohDgQLOoUnaEyvFcUNq/h3LyzNTnM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OdybXHUi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OdybXHUi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7DBBC2BC87; Sat, 28 Feb 2026 17:41:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300499; bh=N3whK/Qab7sabZq+ciegNfhuZ8/gv7147eDSqfVOTMY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OdybXHUivm5iwmm7UMzM/DaooU7TKbpFVB1BuoSNAPABA4/VYhDsD3qozRjFm5SUR cwSx4w0Nos4wW+S4lwVB4LJRlMmAFb+1RZUbIp6x9lx7nXm0gdNDRnw0SH1hnkVkBU BRobFmCXX+r52va2Agx4n8nMk0jYe78e35/YI7uRb0nX5uIC945NjNusaDyzIFzUS9 0hB/B8oNt+YIeWZzm0lowey1z0noKOkKn25xY4OfWvt9y9D0kbhCa/Kwwi3q55FOBC Y8IlJyNuctDOanhvRAAhEEMrqXpGuXMemkv4KGoNx9Bm2T7psHum8OTmzvO7N6Gmjf 4y6GyXKIQvV9Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Biggers , Sami Tolvanen , Mikulas Patocka , Sasha Levin Subject: [PATCH 6.19 537/844] dm-verity: correctly handle dm_bufio_client_create() failure Date: Sat, 28 Feb 2026 12:27:30 -0500 Message-ID: <20260228173244.1509663-538-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Biggers [ Upstream commit 119f4f04186fa4f33ee6bd39af145cdaff1ff17f ] If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this. Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Cc: stable@vger.kernel.org Reviewed-by: Sami Tolvanen Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-verity-fec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/md/dm-verity-fec.c b/drivers/md/dm-verity-fec.c index c79de517afee7..0ac98a620f3ac 100644 --- a/drivers/md/dm-verity-fec.c +++ b/drivers/md/dm-verity-fec.c @@ -534,9 +534,9 @@ void verity_fec_dtr(struct dm_verity *v) mempool_exit(&f->output_pool); kmem_cache_destroy(f->cache); =20 - if (f->data_bufio) + if (!IS_ERR_OR_NULL(f->data_bufio)) dm_bufio_client_destroy(f->data_bufio); - if (f->bufio) + if (!IS_ERR_OR_NULL(f->bufio)) dm_bufio_client_destroy(f->bufio); =20 if (f->dev) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7FF83E5F79; Sat, 28 Feb 2026 17:41:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300500; cv=none; b=H6BLIZwOOUtglYdR4Sbirhn331T8zZUupUb/wj3wQ7MtZRbAKxgcSBsM1CV3MnpMHSphpOxHO2Jq2IybpkGy7i1w48hETslBZOdTAXY3J5C/0DCCWSJTvWaPpHc7VFmC3RI64+2tNVTfBO5Ts9xdiPSIXtqced+hVacjoqbhZrs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300500; c=relaxed/simple; bh=fdZxNkDEir7Gj+h8PL+4WK7qPvK1K5hf3Uh8lZeH47E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QYTaNPT4fR9xwIfw2mhV505m/e/Zn+2V4BWskvpLF5HA/eqHcc7o/bSVEwUz0JRhKpyh02nanr6JnbOd+NJMsgZW0HgD+5I1bY3FdS8Q8A0kRsfbAWnubE63PxGlKpYsjmMo7bgo29pXYZ3OGf/3dkId+drT/Q46KtwdnwS4dVA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vGMPkLPK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vGMPkLPK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6F48C116D0; Sat, 28 Feb 2026 17:41:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300500; bh=fdZxNkDEir7Gj+h8PL+4WK7qPvK1K5hf3Uh8lZeH47E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vGMPkLPKEEqViOrbg2J6kkGH8ArFAPuL3auRUGAUy68fWg5bn2h1+V85haKqHMK+7 ZhILnqBLEI2k29X2wHrNl0dftVg6ZOffMmAosCL2fdSibMDlYGcokJbrUoOurhoRVI W4+08U46v3zEfspcP+G059Q0htf2wbj8OnhiqYJDrbeTOWpFIEcD4NqMEm9kYN2Y3V yfuiPlmbRI0efzVjhTL4Y/q3o39u+D/GdwfenHClvccG1pv0DXW3Mifd/bSjas6zsH N5roOiWFVaYEzZ1EDbfj9a1FHELPOdiTw78z6nxfE/qv9VlW+5VSW56Gb+lTVy7Ojw 8oIOL+GGtJIOg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ricardo Ribalda , Hans de Goede , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 538/844] media: uvcvideo: Fix support for V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX Date: Sat, 28 Feb 2026 12:27:31 -0500 Message-ID: <20260228173244.1509663-539-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ricardo Ribalda [ Upstream commit 4238bd6dc6ba36f44d89a60338223d5a4f708cbf ] The VIDIOC_G_EXT_CTRLS with which V4L2_CTRL_WHICH_(MIN|MAX)_VAL can only work for controls that have previously announced support for it. This patch fixes the following v4l2-compliance error: info: checking extended control 'User Controls' (0x00980001) fail: v4l2-test-controls.cpp(980): ret !=3D EINVAL (got 13) test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL Fixes: 39d2c891c96e ("media: uvcvideo: support V4L2_CTRL_WHICH_MIN/MAX_VAL") Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/usb/uvc/uvc_ctrl.c | 14 ++++++++++++-- drivers/media/usb/uvc/uvc_v4l2.c | 10 ++++++---- drivers/media/usb/uvc/uvcvideo.h | 2 +- 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_c= trl.c index 2905505c240c0..2738ef74c7373 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -1432,7 +1432,7 @@ static bool uvc_ctrl_is_readable(u32 which, struct uv= c_control *ctrl, * auto_exposure=3D1, exposure_time_absolute=3D251. */ int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id, - const struct v4l2_ext_controls *ctrls, + const struct v4l2_ext_controls *ctrls, u32 which, unsigned long ioctl) { struct uvc_control_mapping *master_map =3D NULL; @@ -1442,14 +1442,24 @@ int uvc_ctrl_is_accessible(struct uvc_video_chain *= chain, u32 v4l2_id, s32 val; int ret; int i; + /* + * There is no need to check the ioctl, all the ioctls except + * VIDIOC_G_EXT_CTRLS use which=3DV4L2_CTRL_WHICH_CUR_VAL. + */ + bool is_which_min_max =3D which =3D=3D V4L2_CTRL_WHICH_MIN_VAL || + which =3D=3D V4L2_CTRL_WHICH_MAX_VAL; =20 if (__uvc_query_v4l2_class(chain, v4l2_id, 0) >=3D 0) - return -EACCES; + return is_which_min_max ? -EINVAL : -EACCES; =20 ctrl =3D uvc_find_control(chain, v4l2_id, &mapping); if (!ctrl) return -EINVAL; =20 + if ((!(ctrl->info.flags & UVC_CTRL_FLAG_GET_MIN) || + !(ctrl->info.flags & UVC_CTRL_FLAG_GET_MAX)) && is_which_min_max) + return -EINVAL; + if (ioctl =3D=3D VIDIOC_G_EXT_CTRLS) return uvc_ctrl_is_readable(ctrls->which, ctrl, mapping); =20 diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v= 4l2.c index 9e4a251eca880..30c160daed8cb 100644 --- a/drivers/media/usb/uvc/uvc_v4l2.c +++ b/drivers/media/usb/uvc/uvc_v4l2.c @@ -765,14 +765,15 @@ static int uvc_ioctl_query_ext_ctrl(struct file *file= , void *priv, =20 static int uvc_ctrl_check_access(struct uvc_video_chain *chain, struct v4l2_ext_controls *ctrls, - unsigned long ioctl) + u32 which, unsigned long ioctl) { struct v4l2_ext_control *ctrl =3D ctrls->controls; unsigned int i; int ret =3D 0; =20 for (i =3D 0; i < ctrls->count; ++ctrl, ++i) { - ret =3D uvc_ctrl_is_accessible(chain, ctrl->id, ctrls, ioctl); + ret =3D uvc_ctrl_is_accessible(chain, ctrl->id, ctrls, which, + ioctl); if (ret) break; } @@ -806,7 +807,7 @@ static int uvc_ioctl_g_ext_ctrls(struct file *file, voi= d *priv, which =3D V4L2_CTRL_WHICH_CUR_VAL; } =20 - ret =3D uvc_ctrl_check_access(chain, ctrls, VIDIOC_G_EXT_CTRLS); + ret =3D uvc_ctrl_check_access(chain, ctrls, which, VIDIOC_G_EXT_CTRLS); if (ret < 0) return ret; =20 @@ -840,7 +841,8 @@ static int uvc_ioctl_s_try_ext_ctrls(struct uvc_fh *han= dle, if (!ctrls->count) return 0; =20 - ret =3D uvc_ctrl_check_access(chain, ctrls, ioctl); + ret =3D uvc_ctrl_check_access(chain, ctrls, V4L2_CTRL_WHICH_CUR_VAL, + ioctl); if (ret < 0) return ret; =20 diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvi= deo.h index 3f2e832025e71..8480d65ecb85e 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -787,7 +787,7 @@ int uvc_ctrl_get(struct uvc_video_chain *chain, u32 whi= ch, struct v4l2_ext_control *xctrl); int uvc_ctrl_set(struct uvc_fh *handle, struct v4l2_ext_control *xctrl); int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id, - const struct v4l2_ext_controls *ctrls, + const struct v4l2_ext_controls *ctrls, u32 which, unsigned long ioctl); =20 int uvc_xu_ctrl_query(struct uvc_video_chain *chain, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A52573E5F97; Sat, 28 Feb 2026 17:41:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300501; cv=none; b=Zd7qM0IN4vMbyxAdYYrVb2CllEi6eb3iK+tpBMQ014a3+pOgKKnrnxWLCwHJrNz0r9+1c0ke99Dx9p+xShtPaLGNThcUnZX7uVcsP+IG65ETG120vrGmicIViVX9pydM+fvQLZ2QWLipqLytMkdNRkG4YCeOnLI5Lz4x8hpN82I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300501; c=relaxed/simple; bh=qqRWgnvIGox1KHnAYmILXu14oWvjgZmGY2Y4Du0zM/E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YY9q3t9bl6WBzikbcoQoZcQmfEiMbaTRv8oE0OZrupKcOKMW9RcqYPm34J+xfAmz0DuUYJ7nvXbcZWQQZfE1WzJzwtunL/IxQ6JcKWDsbRDjnq17e5LzsowAPaYA1kbto3R/jn1SDEkqDKmY14Q2qmEzXdoqIPWVXF7dyuQ/LjQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hBXWnjH+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hBXWnjH+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7A7AC2BC9E; Sat, 28 Feb 2026 17:41:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300501; bh=qqRWgnvIGox1KHnAYmILXu14oWvjgZmGY2Y4Du0zM/E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hBXWnjH+3Z3n7F+2msFqIKXIaEhgI/ks7O9zXQACwHuJJnHnagxfIQ3YnM5gWwpmE ++Cbew6eqdIx63g4uyNP6XaNRbskFhkr1k/Q6GN/fOtdomc53OiPQmnfQjOnUI3VYB aaLiQEn9rWtW2g4qnQ5a6sVVxCwgLDuZKuNbU8bQzgyzRT36En7hoAVH5IGxmugGuG C45EE/svCqKSoonc3xGE1udcohwQ9r1YZAlQ0e3BZ0yYL2M7j1w/LmXL0KhWncvvkQ Mf1h1OeBqLkFmWrNxpggohUuh1z17ph70QlFiO5gO7sgJiE9asYlacTraYVhXkI/ZK YbNCLGjtGwSpg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Irui Wang , AngeloGioacchino Del Regno , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 539/844] media: mediatek: encoder: Fix uninitialized scalar variable issue Date: Sat, 28 Feb 2026 12:27:32 -0500 Message-ID: <20260228173244.1509663-540-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Irui Wang [ Upstream commit 88e935de7cf8795d7a6a51385db87ecb361a7050 ] UNINIT checker finds some instances of variables that are used without being initialized, for example using the uninitialized value enc_result.is_key_frm can result in unpredictable behavior, so initialize these variables after declaring. Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Enc= oder Driver") Cc: stable@vger.kernel.org Signed-off-by: Irui Wang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.= c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c index 6faf3f659e751..b3a0a1d8b7a8e 100644 --- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c +++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c @@ -850,7 +850,7 @@ static void vb2ops_venc_buf_queue(struct vb2_buffer *vb) static int vb2ops_venc_start_streaming(struct vb2_queue *q, unsigned int c= ount) { struct mtk_vcodec_enc_ctx *ctx =3D vb2_get_drv_priv(q); - struct venc_enc_param param; + struct venc_enc_param param =3D { }; int ret; int i; =20 @@ -1004,7 +1004,7 @@ static int mtk_venc_encode_header(void *priv) int ret; struct vb2_v4l2_buffer *src_buf, *dst_buf; struct mtk_vcodec_mem bs_buf; - struct venc_done_result enc_result; + struct venc_done_result enc_result =3D { }; =20 dst_buf =3D v4l2_m2m_dst_buf_remove(ctx->m2m_ctx); if (!dst_buf) { @@ -1125,7 +1125,7 @@ static void mtk_venc_worker(struct work_struct *work) struct vb2_v4l2_buffer *src_buf, *dst_buf; struct venc_frm_buf frm_buf; struct mtk_vcodec_mem bs_buf; - struct venc_done_result enc_result; + struct venc_done_result enc_result =3D { }; int ret, i; =20 /* check dst_buf, dst_buf may be removed in device_run --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF78D35E93A; Sat, 28 Feb 2026 17:41:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300503; cv=none; b=H5jxjygz1Ej31ottlXL5PpUlbbxMtZyEaIgyc3czdv6bNLomzxng1B9cBjCQkeXskI9sCk98l5SYVHf+Sn8V1KMg27c4B9ud+Qv6ib+u7fvQIyqmWGA4viJ8Nq/o5qiX6d9Kk8FNRc+xSg/izMydHl/oOO3AjTfPBYFmq9QUMw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300503; c=relaxed/simple; bh=5if/RWMvFd/l30E/2EEFXgocpt+vp6WLqSuHhSUwgdI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ojot0FsWHmW8SWGPy1COjfhE+GehPREYynv0nhkoT8M1xh2HoC5G/MTIxwHfMTtlEBJ+LYqHJ9ERBfXay4KNsdXRwKPiT5zsBP0R0SDiVseVWWG5lGB/iYVkBTh0JZowzgf8bU+y4wxMjzQck4tGnXAVdfLXhwCb+3iNpos07xw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bBblxYb4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bBblxYb4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD70BC2BC87; Sat, 28 Feb 2026 17:41:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300502; bh=5if/RWMvFd/l30E/2EEFXgocpt+vp6WLqSuHhSUwgdI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bBblxYb4QqJmc19N/ya+cVKxNu24qUdT2vlYyu8x+Wq+cRWcKTGFoqdiULwADp6Sc QjXlRjabvYXkLbdHGeSpJ/0cx2zEinVhRb2IOXMe1u/dUKOssXqzU48j/ghfcRmp2o Je0w4lkLROkTzeI4GB2pMZTaiyGjUQ9tKiLHKSiPKgUWMt1KjbyJjM2URe0QU9JydT GjtC1YY48yb3ym4F6YJSTCS2pEJg92/RUSFrzqHfn68WZSM9wDg4lXocF08twTWaAp fVT/fcTfYT+U9W/56GYPN5eZnAXUe2TTC9qFE3Lq2w/LdHba7ZeorOzVsppBBWBwj4 j1EzjR8pqcrwg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 540/844] media: mtk-mdp: Fix error handling in probe function Date: Sat, 28 Feb 2026 12:27:33 -0500 Message-ID: <20260228173244.1509663-541-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit 8a8a3232abac5b972058a5f2cb3e33199d2a8648 ] Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../media/platform/mediatek/mdp/mtk_mdp_core.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c b/drivers/m= edia/platform/mediatek/mdp/mtk_mdp_core.c index 80fdc6ff57e0e..f78fa30f18648 100644 --- a/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c +++ b/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c @@ -194,11 +194,17 @@ static int mtk_mdp_probe(struct platform_device *pdev) } =20 mdp->vpu_dev =3D vpu_get_plat_device(pdev); + if (!mdp->vpu_dev) { + dev_err(&pdev->dev, "Failed to get vpu device\n"); + ret =3D -ENODEV; + goto err_vpu_get_dev; + } + ret =3D vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp, VPU_RST_MDP); if (ret) { dev_err(&pdev->dev, "Failed to register reset handler\n"); - goto err_m2m_register; + goto err_reg_handler; } =20 platform_set_drvdata(pdev, mdp); @@ -206,7 +212,7 @@ static int mtk_mdp_probe(struct platform_device *pdev) ret =3D vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32)); if (ret) { dev_err(&pdev->dev, "Failed to set vb2 dma mag seg size\n"); - goto err_m2m_register; + goto err_reg_handler; } =20 pm_runtime_enable(dev); @@ -214,6 +220,12 @@ static int mtk_mdp_probe(struct platform_device *pdev) =20 return 0; =20 +err_reg_handler: + platform_device_put(mdp->vpu_dev); + +err_vpu_get_dev: + mtk_mdp_unregister_m2m_device(mdp); + err_m2m_register: v4l2_device_unregister(&mdp->v4l2_dev); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B8E2A35E94C; Sat, 28 Feb 2026 17:41:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300503; cv=none; b=ilk2ZhZDLo1D9ZnkbSmOHqefAV7QMZ1ylsV2HaYDYkfljC+XJ+UpUvx0g2FO2SPDi8rwdB/I8N890oN2ssilvc6k5GYRcKopL6trYZA+9SSc/tFrjO2gVO5XuEvJ9I/+EKbfAPIkbx/TR4vgluw0N1Y1VGhkK7JYdG4HZ5O6a+I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300503; c=relaxed/simple; bh=uDhIBphmjVucBZEpMpnFI3pSvL0pshqOZ7AL5MqU1Qk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=e4wIS37XKd4n4VYWEqcxWIg5gc1+3a3sVueLIHx7plC458UQYffO30earSzdS3x0SL4BgdTJ0IrdpUQQl02uNqWyVMi7VfAhIM7uXftInEikmgivPrdmeGODdyqZuqcu5KReC3N3jN4+TXRAUTSMH5wtwfO6QnIhoYPKcicxO30= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bdHj+sNM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bdHj+sNM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C463CC19423; Sat, 28 Feb 2026 17:41:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300503; bh=uDhIBphmjVucBZEpMpnFI3pSvL0pshqOZ7AL5MqU1Qk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bdHj+sNMSFcOJQvUB+xdx1bUICShjsomHiDtm+yyO7Py2f/Gl4K/oDeQIR36zODPv DkEhkYTykhIi8VcRdJosMHLoUFwwHWfNieaa5kIKU5lYFsDS+OKvl8SXs5y0AdazHC 0dvgZGiLDn7gGmhK2H/Lt+9t/oIIwnTvN83bMDDiRBIgX0NFfYte292XcV5VS5R8vy JX7sOL2hQaaL912hzGCIeq1wNgUO5ioAWkC0auBm/GuP+LXPrtwTd8u5AIHZmcoJDs xILVzutHX6GgSPNWgaDACEw9K9Vhv7e2cy9+ggJeJrGJkJdlgweNdvXI2Li4RksRwD di95q9YVhGoow== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 541/844] media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() Date: Sat, 28 Feb 2026 12:27:34 -0500 Message-ID: <20260228173244.1509663-542-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit f128bab57b8018e526b7eda854ca20069863af47 ] In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/mediatek/mdp/mtk_mdp_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c b/drivers/m= edia/platform/mediatek/mdp/mtk_mdp_core.c index f78fa30f18648..8432833814f31 100644 --- a/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c +++ b/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c @@ -254,6 +254,7 @@ static void mtk_mdp_remove(struct platform_device *pdev) =20 pm_runtime_disable(&pdev->dev); vb2_dma_contig_clear_max_seg_size(&pdev->dev); + platform_device_put(mdp->vpu_dev); mtk_mdp_unregister_m2m_device(mdp); v4l2_device_unregister(&mdp->v4l2_dev); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1D4835E95D; Sat, 28 Feb 2026 17:41:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300504; cv=none; b=mhgc/Eh5WicRjZ113fmBm7ecPxaRBfpHb/6Vdjipp71f4Kc6bUpfgdSlsvM5wo7YShncecAsneHIluadD3LGEj0WJ7HZfypkYucHtIsqZ4xiZZ/RS1Dzh2gK6VhxwoQ1XGpCuqGjUEF1rpQDAb9TPQCphrr7u/V1mrBKXmUcDsc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300504; c=relaxed/simple; bh=urhlAVyJVrIQmbbWAZrRGMlFqaW3ozV6GJGeuHGKLvY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=It4Rb5SGpBSO/Ug4VuRiLAo9hQzN+2hzJCH1FBcMqqcN/RceUj6NkQ0jix/CsI66w5iGAsG1K0LY16MLcbwAKLVIhN8uz7YP5bYaydKY4D4kTmVduKIhEw/qVP7RKViY7m0MJnNUgaw80j74jngX9Ewqn99E+pqtzq1Otz9FvcI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r80BTX+z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="r80BTX+z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B846AC116D0; Sat, 28 Feb 2026 17:41:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300504; bh=urhlAVyJVrIQmbbWAZrRGMlFqaW3ozV6GJGeuHGKLvY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r80BTX+zXv3bISyLRMR9e1hL/H1xjkgDWzp/FspdL/wgTg278CiomBLtJjNnCxTvM /JkfCdehgGycEX7u8Ve1t+p5JmcSrpABVkQF5Hrc/hBtcenUGacCZElR2sfS3GjTfi aDNMXzpIcKOrBNyzQFCSF2FSTpmxidtVdIpK0R8UL3QU+OmrLfwsK6WW8iuwlZ0S1H 0j7gC7zJh7zY6WCSW79b3cwgnwVQ0Z+yh4O79pVuwhsvRi61+NTZ7yNXzpwYRBLDPm 26vLgWrUHs+ADjPPYRVvG91PuuS3qJRyGa2dv+TMNgxemxbGOWqJ+k7uTc9ei5vKHV W4GhuhZ4qmn4g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xulin Sun , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 542/844] media: chips-media: wave5: Fix PM runtime usage count underflow Date: Sat, 28 Feb 2026 12:27:35 -0500 Message-ID: <20260228173244.1509663-543-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xulin Sun [ Upstream commit 9cf4452e824c1e2d41c9c0b13cc8a32a0a7dec38 ] Replace pm_runtime_put_sync() with pm_runtime_dont_use_autosuspend() in the remove path to properly pair with pm_runtime_use_autosuspend() from probe. This allows pm_runtime_disable() to handle reference count cleanup correctly regardless of current suspend state. The driver calls pm_runtime_put_sync() unconditionally in remove, but the device may already be suspended due to autosuspend configured in probe. When autosuspend has already suspended the device, the usage count is 0, and pm_runtime_put_sync() decrements it to -1. This causes the following warning on module unload: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98 ... vdec 30210000.video-codec: Runtime PM usage count underflow! Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Xulin Sun Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/chips-media/wave5/wave5-vpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers= /media/platform/chips-media/wave5/wave5-vpu.c index e1715d3f43b0d..23aa3ab51a0ef 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c @@ -356,7 +356,7 @@ static void wave5_vpu_remove(struct platform_device *pd= ev) hrtimer_cancel(&dev->hrtimer); } =20 - pm_runtime_put_sync(&pdev->dev); + pm_runtime_dont_use_autosuspend(&pdev->dev); pm_runtime_disable(&pdev->dev); =20 mutex_destroy(&dev->dev_lock); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C66AA3E5F6E; Sat, 28 Feb 2026 17:41:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300505; cv=none; b=NZWJ7VCJwRxmsl7YK1+tGCouz8h+dzPDRQxTtGdDV6aMfb/BQVelm/HpJnLZER26EoXZaEzYloNWODxlVAPYqh09Rxy3DRBFTZKbGE2ppTlCpBxnPEre0bVIKQJ8Ve1Rmj6/dKldjlvmGFipSg6/t0TPD+aGF5qdpx9q4Dj4s0Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300505; c=relaxed/simple; bh=GxDXmstvReh/VpnhcvzNewuHYQd1fFD24YPjiqH04vQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GENavErQfP6IUjp90J62pimw56+JZWj8zxX1+eanXhaZ7tdeMnvyar4gzLWtOQvTSY8Q58EC6aoKnQ9SbzyLXptC+A4MykOd5HhnhZBEkR2f2X2e9r5B4yhr3ymHq6CJO28GQVBfJEymqFCAdQy/eYdqJ9ZZdDebQ509bPwK3Oc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZXH0q7ls; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZXH0q7ls" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A730DC19423; Sat, 28 Feb 2026 17:41:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300505; bh=GxDXmstvReh/VpnhcvzNewuHYQd1fFD24YPjiqH04vQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZXH0q7lsRsigxTkVYDEt97wxSJ42xe2HAdyFMcdFaiv72WiOXSvwb5+JfgACKeTjA rQsF0uMs5jJ6U/QbB22frc+/LP0ustbRIU9xEMCeefeSaSJSDACOUx+vfos6Z/UtNm rToiS68Zc+KOI1+Mpy5EgNgbq3gMh3x2aq3oXWhZrk6bmq62IjS1yrbcaw9vb7XuPY NIlfWjcy7zr37i3cHbO1s1CjKLenNHeWCaXV1pnPO0zRad/zuJT1KwoWST/Ka3DlY7 nLowqfCs4FijE+6BeIuONNYK4yc0lwxsOhu/7IdPVUe18bejR+ARn8av/revftUP3y AEWmiZSwwSNHA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xulin Sun , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 543/844] media: chips-media: wave5: Fix kthread worker destruction in polling mode Date: Sat, 28 Feb 2026 12:27:36 -0500 Message-ID: <20260228173244.1509663-544-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xulin Sun [ Upstream commit 5a0c122e834b2f7f029526422c71be922960bf03 ] Fix the cleanup order in polling mode (irq < 0) to prevent kernel warnings during module removal. Cancel the hrtimer before destroying the kthread worker to ensure work queues are empty. In polling mode, the driver uses hrtimer to periodically trigger wave5_vpu_timer_callback() which queues work via kthread_queue_work(). The kthread_destroy_worker() function validates that both work queues are empty with WARN_ON(!list_empty(&worker->work_list)) and WARN_ON(!list_empty(&worker->delayed_work_list)). The original code called kthread_destroy_worker() before hrtimer_cancel(), creating a race condition where the timer could fire during worker destruction and queue new work, triggering the WARN_ON. This causes the following warning on every module unload in polling mode: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1034 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98 Modules linked in: wave5(-) rpmsg_ctrl rpmsg_char ... Call trace: kthread_destroy_worker+0x84/0x98 wave5_vpu_remove+0xc8/0xe0 [wave5] platform_remove+0x30/0x58 ... ---[ end trace 0000000000000000 ]--- Fixes: ed7276ed2fd0 ("media: chips-media: wave5: Add hrtimer based polling = support") Cc: stable@vger.kernel.org Signed-off-by: Xulin Sun Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/chips-media/wave5/wave5-vpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers= /media/platform/chips-media/wave5/wave5-vpu.c index 23aa3ab51a0ef..0bcd48df49d0f 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c @@ -352,8 +352,9 @@ static void wave5_vpu_remove(struct platform_device *pd= ev) struct vpu_device *dev =3D dev_get_drvdata(&pdev->dev); =20 if (dev->irq < 0) { - kthread_destroy_worker(dev->worker); hrtimer_cancel(&dev->hrtimer); + kthread_cancel_work_sync(&dev->work); + kthread_destroy_worker(dev->worker); } =20 pm_runtime_dont_use_autosuspend(&pdev->dev); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FE8948B377; Sat, 28 Feb 2026 17:41:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300506; cv=none; b=HSyKBJFZLXDBhupTtXYSatu0TVClq1fDlZQTNjZe+nkeymlk+0UaygP34xTyYyhOV0xe/Ytx8hQB3iFHIp/pb6dmswmPeQeONKhpY4kQwkRBqv6VbVVEldOgH4MUKzLCTIdmu1+b66BjRNAVVljh9fY4XyLRl+hZK6bOjXprWDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300506; c=relaxed/simple; bh=pRAkqO8gN4BpI84SWXWE6HO6Q2oIxqqA0dQ28+mYDoQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pYnxXAwzVZOcMrUboFz/ACJ5rVyBueYW44eRGt7+bHWHHBxoA5b7JzT/+S9p4MhEPeNE6w9oF98uB1ACG4ljYU8e5LnuoVDA4ZYH6U/KNASX4AcJtBOkDxy20prnLS9yf2vNtN4rxKYpHK+W4+hQbqkSXZzXabYcrRBi8lpqCWs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LBL/bXUP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LBL/bXUP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9843FC116D0; Sat, 28 Feb 2026 17:41:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300506; bh=pRAkqO8gN4BpI84SWXWE6HO6Q2oIxqqA0dQ28+mYDoQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LBL/bXUP81RYd1ZM7yKeJvNT+0m33U3jzHZJyPAUYWJD/PPeerOl8pNRuIneQDXbV SQnrXkPGi3MQDDRT69p/kKOSGqmr/mJYt2LJRepuX0KHtaNrdihuhP3kQVS85kXlyY nwgb2EE3hZtvct9Xi7QarwqzR5/CFP6Wes+MhubqdwSYM5Cs9z4S0TITTlhowywkpY 6WzCa+bvGPA3Hu0zHhYd55B5a0NBUiuZC8kNsA6El9LrlygywFCPivVarMYODEe6R7 covZK+3t+dVkKwsWMgfxbLqfQfwgS9slySY5yq88kNeB/FVaSxzz8uNFjjc32eg1xg Rjnk/lAk7Fqgg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xulin Sun , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 544/844] media: chips-media: wave5: Fix device cleanup order to prevent kernel panic Date: Sat, 28 Feb 2026 12:27:37 -0500 Message-ID: <20260228173244.1509663-545-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xulin Sun [ Upstream commit b74cedac643b02aefa7da881b58a3792859d9748 ] Move video device unregistration to the beginning of the remove function to ensure all video operations are stopped before cleaning up the worker thread and disabling PM runtime. This prevents hardware register access after the device has been powered down. In polling mode, the hrtimer periodically triggers wave5_vpu_timer_callback() which queues work to the kthread worker. The worker executes wave5_vpu_irq_work_fn() which reads hardware registers via wave5_vdi_read_register(). The original cleanup order disabled PM runtime and powered down hardware before unregistering video devices. When autosuspend triggers and powers off the hardware, the video devices are still registered and the worker thread can still be triggered by the hrtimer, causing it to attempt reading registers from powered-off hardware. This results in a bus error (synchronous external abort) and kernel panic. This causes random kernel panics during encoding operations: Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Modules linked in: wave5 rpmsg_ctrl rpmsg_char ... CPU: 0 UID: 0 PID: 1520 Comm: vpu_irq_thread Tainted: G M W pc : wave5_vdi_read_register+0x10/0x38 [wave5] lr : wave5_vpu_irq_work_fn+0x28/0x60 [wave5] Call trace: wave5_vdi_read_register+0x10/0x38 [wave5] kthread_worker_fn+0xd8/0x238 kthread+0x104/0x120 ret_from_fork+0x10/0x20 Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: synchronous external abort: Fatal exception Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Xulin Sun Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/chips-media/wave5/wave5-vpu.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers= /media/platform/chips-media/wave5/wave5-vpu.c index 0bcd48df49d0f..77d6c934d0b9d 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c @@ -351,6 +351,10 @@ static void wave5_vpu_remove(struct platform_device *p= dev) { struct vpu_device *dev =3D dev_get_drvdata(&pdev->dev); =20 + wave5_vpu_enc_unregister_device(dev); + wave5_vpu_dec_unregister_device(dev); + v4l2_device_unregister(&dev->v4l2_dev); + if (dev->irq < 0) { hrtimer_cancel(&dev->hrtimer); kthread_cancel_work_sync(&dev->work); @@ -364,9 +368,6 @@ static void wave5_vpu_remove(struct platform_device *pd= ev) mutex_destroy(&dev->hw_lock); reset_control_assert(dev->resets); clk_bulk_disable_unprepare(dev->num_clks, dev->clks); - wave5_vpu_enc_unregister_device(dev); - wave5_vpu_dec_unregister_device(dev); - v4l2_device_unregister(&dev->v4l2_dev); wave5_vdi_release(&pdev->dev); ida_destroy(&dev->inst_ida); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98DE33E715A; Sat, 28 Feb 2026 17:41:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300507; cv=none; b=kZK25Uv/ZVwzdzmG3LhskrxdD4n9gAzISZrI/RKTiUz4Itotcz24rq0QhOKNM6qzmurhA1r8CUT13Uf/V4ZsTD2yA/HqlRKv303cyaV79p86pSlRBt9Jf2guTKwmzVmHXAvfs4GByAJDzItJu6HcYgj9JzsL1ivebCrOYJpo7mQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300507; c=relaxed/simple; bh=G/i0yfCCMTH7ld5/Si79o0hJH+R6OBJtdI8UewSx2UE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G/CIiHlwmxk7f6wU+tStKT009l3IGItgmrRr5IolV9rXm6HTwrWH36+GkT5BeY8gAUtSi8zOXp6H3O5HLn2otq10yDGQ86J/cDbF3iUJ1zoPEJB7Ja2FoI/CFzDYFvPK5QTa7AVzu2zzZu3ZAxJcLSDsD4x0+2jpzNF/DlDjF7g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H11rmRrv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H11rmRrv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8948DC19423; Sat, 28 Feb 2026 17:41:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300507; bh=G/i0yfCCMTH7ld5/Si79o0hJH+R6OBJtdI8UewSx2UE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H11rmRrvmhZkYKhJfCl6H/WYDRi26AQl5QXYaXnIrb+LDBF6vK8PCP2WPkuSZmhIY Bd4vdaYXPmg1A3Azj+fsw1vjBlPZE7yriB0zTp8eELMNdOUMYE7B5qbJQ5F4D1MPFm 8XPqbnStCHXJyZsiC/8sQiogelMh7tO+mtr61g6ZRnknXZ1vxrCgayRNpeeBNmDkTZ qVTj7sIaTFsU1HdqaJkrd2RzI9PHSCBmdLva59qYw3MzjwcfHdikbBAdqRwBySnNOA gRFQYyl9Wnen288hbEiPS2PrTBYifOz9+ClPQfzRBgyhv2pDQ59PIfQClPGOfny6og Ptt8w5LHqP8MA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jackson Lee , Nas Chung , Nicolas Dufresne , Brandon Brnich , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 545/844] media: chips-media: wave5: Fix SError of kernel panic when closed Date: Sat, 28 Feb 2026 12:27:38 -0500 Message-ID: <20260228173244.1509663-546-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jackson Lee [ Upstream commit cbb9c0d50e471483cced55f5b7db4569dcd959a6 ] SError of kernel panic rarely happened while testing fluster. The root cause was to enter suspend mode because timeout of autosuspend delay happened. [ 48.834439] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 48.834455] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.= 12.9-gc9e21a1ebd75-dirty #7 [ 48.834461] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instrum= ents J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025 [ 48.834464] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE= =3D--) [ 48.834468] pc : wave5_dec_clr_disp_flag+0x40/0x80 [wave5] [ 48.834488] lr : wave5_dec_clr_disp_flag+0x40/0x80 [wave5] [ 48.834495] sp : ffff8000856e3a30 [ 48.834497] x29: ffff8000856e3a30 x28: ffff0008093f6010 x27: ffff0008091= 58130 [ 48.834504] x26: 0000000000000000 x25: ffff00080b625000 x24: ffff000804a= 9ba80 [ 48.834509] x23: ffff000802343028 x22: ffff000809158150 x21: ffff0008022= 18000 [ 48.834513] x20: ffff0008093f6000 x19: ffff0008093f6000 x18: 00000000000= 00000 [ 48.834518] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff740= 09618 [ 48.834523] x14: 000000010000000c x13: 0000000000000000 x12: 00000000000= 00000 [ 48.834527] x11: ffffffffffffffff x10: ffffffffffffffff x9 : ffff0008023= 43028 [ 48.834532] x8 : ffff00080b6252a0 x7 : 0000000000000038 x6 : 00000000000= 00000 [ 48.834536] x5 : ffff00080b625060 x4 : 0000000000000000 x3 : 00000000000= 00000 [ 48.834541] x2 : 0000000000000000 x1 : ffff800084bf0118 x0 : ffff800084b= f0000 [ 48.834547] Kernel panic - not syncing: Asynchronous SError Interrupt [ 48.834549] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.= 12.9-gc9e21a1ebd75-dirty #7 [ 48.834554] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instrum= ents J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025 [ 48.834556] Call trace: [ 48.834559] dump_backtrace+0x94/0xec [ 48.834574] show_stack+0x18/0x24 [ 48.834579] dump_stack_lvl+0x38/0x90 [ 48.834585] dump_stack+0x18/0x24 [ 48.834588] panic+0x35c/0x3e0 [ 48.834592] nmi_panic+0x40/0x8c [ 48.834595] arm64_serror_panic+0x64/0x70 [ 48.834598] do_serror+0x3c/0x78 [ 48.834601] el1h_64_error_handler+0x34/0x4c [ 48.834605] el1h_64_error+0x64/0x68 [ 48.834608] wave5_dec_clr_disp_flag+0x40/0x80 [wave5] [ 48.834615] wave5_vpu_dec_clr_disp_flag+0x54/0x80 [wave5] [ 48.834622] wave5_vpu_dec_buf_queue+0x19c/0x1a0 [wave5] [ 48.834628] __enqueue_in_driver+0x3c/0x74 [videobuf2_common] [ 48.834639] vb2_core_qbuf+0x508/0x61c [videobuf2_common] [ 48.834646] vb2_qbuf+0xa4/0x168 [videobuf2_v4l2] [ 48.834656] v4l2_m2m_qbuf+0x80/0x238 [v4l2_mem2mem] [ 48.834666] v4l2_m2m_ioctl_qbuf+0x18/0x24 [v4l2_mem2mem] [ 48.834673] v4l_qbuf+0x48/0x5c [videodev] [ 48.834704] __video_do_ioctl+0x180/0x3f0 [videodev] [ 48.834725] video_usercopy+0x2ec/0x68c [videodev] [ 48.834745] video_ioctl2+0x18/0x24 [videodev] [ 48.834766] v4l2_ioctl+0x40/0x60 [videodev] [ 48.834786] __arm64_sys_ioctl+0xa8/0xec [ 48.834793] invoke_syscall+0x44/0x100 [ 48.834800] el0_svc_common.constprop.0+0xc0/0xe0 [ 48.834804] do_el0_svc+0x1c/0x28 [ 48.834809] el0_svc+0x30/0xd0 [ 48.834813] el0t_64_sync_handler+0xc0/0xc4 [ 48.834816] el0t_64_sync+0x190/0x194 [ 48.834820] SMP: stopping secondary CPUs [ 48.834831] Kernel Offset: disabled [ 48.834833] CPU features: 0x08,00002002,80200000,4200421b [ 48.834837] Memory Limit: none [ 49.161404] ---[ end Kernel panic - not syncing: Asynchronous SError Int= errupt ]--- Fixes: 2092b3833487 ("media: chips-media: wave5: Support runtime suspend/re= sume") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Tested-by: Brandon Brnich Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../platform/chips-media/wave5/wave5-vpu-dec.c | 5 ++--- .../platform/chips-media/wave5/wave5-vpu-enc.c | 3 --- .../media/platform/chips-media/wave5/wave5-vpu.c | 2 +- .../platform/chips-media/wave5/wave5-vpuapi.c | 15 --------------- 4 files changed, 3 insertions(+), 22 deletions(-) diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c b/dri= vers/media/platform/chips-media/wave5/wave5-vpu-dec.c index a4387ed58cac3..a90f00f589e04 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c @@ -1243,6 +1243,7 @@ static void wave5_vpu_dec_buf_queue_dst(struct vb2_bu= ffer *vb) struct vpu_instance *inst =3D vb2_get_drv_priv(vb->vb2_queue); struct v4l2_m2m_ctx *m2m_ctx =3D inst->v4l2_fh.m2m_ctx; =20 + pm_runtime_resume_and_get(inst->dev->dev); vbuf->sequence =3D inst->queued_dst_buf_num++; =20 if (inst->state =3D=3D VPU_INST_STATE_PIC_RUN) { @@ -1275,6 +1276,7 @@ static void wave5_vpu_dec_buf_queue_dst(struct vb2_bu= ffer *vb) } else { v4l2_m2m_buf_queue(m2m_ctx, vbuf); } + pm_runtime_put_autosuspend(inst->dev->dev); } =20 static void wave5_vpu_dec_buf_queue(struct vb2_buffer *vb) @@ -1827,9 +1829,6 @@ static int wave5_vpu_open_dec(struct file *filp) if (ret) goto cleanup_inst; =20 - if (list_empty(&dev->instances)) - pm_runtime_use_autosuspend(inst->dev->dev); - list_add_tail(&inst->list, &dev->instances); =20 mutex_unlock(&dev->dev_lock); diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c b/dri= vers/media/platform/chips-media/wave5/wave5-vpu-enc.c index a254830e4009e..5388efa63f73d 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c @@ -1773,9 +1773,6 @@ static int wave5_vpu_open_enc(struct file *filp) if (ret) goto cleanup_inst; =20 - if (list_empty(&dev->instances)) - pm_runtime_use_autosuspend(inst->dev->dev); - list_add_tail(&inst->list, &dev->instances); =20 mutex_unlock(&dev->dev_lock); diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers= /media/platform/chips-media/wave5/wave5-vpu.c index 77d6c934d0b9d..0026f58403620 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c @@ -322,7 +322,7 @@ static int wave5_vpu_probe(struct platform_device *pdev) dev_info(&pdev->dev, "Product Code: 0x%x\n", dev->product_code); dev_info(&pdev->dev, "Firmware Revision: %u\n", fw_revision); =20 - pm_runtime_set_autosuspend_delay(&pdev->dev, 100); + pm_runtime_set_autosuspend_delay(&pdev->dev, 500); pm_runtime_use_autosuspend(&pdev->dev); pm_runtime_enable(&pdev->dev); wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0); diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c b/driv= ers/media/platform/chips-media/wave5/wave5-vpuapi.c index e5e879a13e8b8..e94d6ebc9f816 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c @@ -207,8 +207,6 @@ int wave5_vpu_dec_close(struct vpu_instance *inst, u32 = *fail_res) int retry =3D 0; struct vpu_device *vpu_dev =3D inst->dev; int i; - int inst_count =3D 0; - struct vpu_instance *inst_elm; =20 *fail_res =3D 0; if (!inst->codec_info) @@ -250,11 +248,6 @@ int wave5_vpu_dec_close(struct vpu_instance *inst, u32= *fail_res) =20 wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_task); =20 - list_for_each_entry(inst_elm, &vpu_dev->instances, list) - inst_count++; - if (inst_count =3D=3D 1) - pm_runtime_dont_use_autosuspend(vpu_dev->dev); - unlock_and_return: mutex_unlock(&vpu_dev->hw_lock); pm_runtime_put_sync(inst->dev->dev); @@ -720,8 +713,6 @@ int wave5_vpu_enc_close(struct vpu_instance *inst, u32 = *fail_res) int ret; int retry =3D 0; struct vpu_device *vpu_dev =3D inst->dev; - int inst_count =3D 0; - struct vpu_instance *inst_elm; =20 *fail_res =3D 0; if (!inst->codec_info) @@ -764,12 +755,6 @@ int wave5_vpu_enc_close(struct vpu_instance *inst, u32= *fail_res) } =20 wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_task); - - list_for_each_entry(inst_elm, &vpu_dev->instances, list) - inst_count++; - if (inst_count =3D=3D 1) - pm_runtime_dont_use_autosuspend(vpu_dev->dev); - mutex_unlock(&vpu_dev->hw_lock); pm_runtime_put_sync(inst->dev->dev); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4EEB35E95F; Sat, 28 Feb 2026 17:41:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300509; cv=none; b=WhUZWZKl+70Gs3ipXCoPyEaA1exsSQ/FTBtCba75cPPlyHx2e5yKLaJrmqSX7sjgseXgGN909JLvlgU7JkoWHmYilF4L6g3gV8UCjQSINsu7sgkMWhWUBoDcIBFU8bGx4jsQvsrcMGWkWllJ7vNvF9XMRdxPl2TN55kJR77LSlo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300509; c=relaxed/simple; bh=6mul+C4Zr0g2CIAVG+pYAsxIYMQbrkjwWpYq3wpY9+U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dphFyPWHRIdkBgxyg5ilFZKgkn+bcgE9C4D1FWlEfDJ6UcJNxQei2BVPh+V+sx4Wu7QjRADsV8mC8T0RSvype0itCI5G0EUzdA7LbCugFScXZ1YwkWULMpPIXkN7B3Z7J7YbxkfO4n9I66+6aMM58jJaLFzx3QX1sAvKikWl2a8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l3FpPxVy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="l3FpPxVy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A77AEC116D0; Sat, 28 Feb 2026 17:41:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300508; bh=6mul+C4Zr0g2CIAVG+pYAsxIYMQbrkjwWpYq3wpY9+U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=l3FpPxVyCz1Ji6V+bj1uJBFU8wlZ3k2DPgxkCg8eO44dWdC1wk6j8cfnD3+P0dNT1 K7qPMJ0rT3R8X08A/RSOcL96/+EjIgLMC//c0RvQUIwziCLTJ5Vq2tvfO6eEw8fmV5 TH+d7k0aEdVuFMIe4WMvwn9AJ2vnXtBFV0Yn3VGPohFllmG25kr4LVSK0k9n83XiMp UcKnwxATatYWAQrdNKFQUVpuL0soIalZeoxrb0Ntb1cvwHIHHg7kWxCJDnTzotVVWg /UsWq7Wic9bRarO0s+QudJnosYywDm1Ch2VYgFecAMrVualnFn4w7RyhscqOK1/ED6 zjXD640rVPp1g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jackson Lee , Nas Chung , Brandon Brnich , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 546/844] media: chips-media: wave5: Fix Null reference while testing fluster Date: Sat, 28 Feb 2026 12:27:39 -0500 Message-ID: <20260228173244.1509663-547-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jackson Lee [ Upstream commit e66ff2b08e4ee1c4d3b84f24818e5bcc178cc3a4 ] When multi instances are created/destroyed, many interrupts happens and structures for decoder are removed. "struct vpu_instance" this structure is shared for all flow in the decoder, so if the structure is not protected by lock, Null dereference could happens sometimes. IRQ Handler was spilt to two phases and Lock was added as well. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Tested-by: Brandon Brnich Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../platform/chips-media/wave5/wave5-helper.c | 28 +++++- .../platform/chips-media/wave5/wave5-helper.h | 1 + .../chips-media/wave5/wave5-vpu-dec.c | 5 + .../chips-media/wave5/wave5-vpu-enc.c | 5 + .../platform/chips-media/wave5/wave5-vpu.c | 97 +++++++++++++++++-- .../platform/chips-media/wave5/wave5-vpuapi.h | 6 ++ 6 files changed, 131 insertions(+), 11 deletions(-) diff --git a/drivers/media/platform/chips-media/wave5/wave5-helper.c b/driv= ers/media/platform/chips-media/wave5/wave5-helper.c index f03ad9c0de221..53a0ac068c2e2 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-helper.c +++ b/drivers/media/platform/chips-media/wave5/wave5-helper.c @@ -27,6 +27,11 @@ const char *state_to_str(enum vpu_instance_state state) } } =20 +int wave5_kfifo_alloc(struct vpu_instance *inst) +{ + return kfifo_alloc(&inst->irq_status, 16 * sizeof(int), GFP_KERNEL); +} + void wave5_cleanup_instance(struct vpu_instance *inst, struct file *filp) { int i; @@ -49,7 +54,7 @@ void wave5_cleanup_instance(struct vpu_instance *inst, st= ruct file *filp) v4l2_fh_del(&inst->v4l2_fh, filp); v4l2_fh_exit(&inst->v4l2_fh); } - list_del_init(&inst->list); + kfifo_free(&inst->irq_status); ida_free(&inst->dev->inst_ida, inst->id); kfree(inst->codec_info); kfree(inst); @@ -61,8 +66,29 @@ int wave5_vpu_release_device(struct file *filp, { struct vpu_instance *inst =3D file_to_vpu_inst(filp); int ret =3D 0; + unsigned long flags; =20 v4l2_m2m_ctx_release(inst->v4l2_fh.m2m_ctx); + /* + * To prevent Null reference exception, the existing irq handler were + * separated to two modules. + * One is to queue interrupt reason into the irq handler, + * the other is irq_thread to call the wave5_vpu_dec_finish_decode + * to get decoded frame. + * The list of instances should be protected between all flow of the + * decoding process, but to protect the list in the irq_handler, spin lock + * should be used, and mutex should be used in the irq_thread because spi= n lock + * is not able to be used because mutex is already being used + * in the wave5_vpu_dec_finish_decode. + * So the spin lock and mutex were used to protect the list in the releas= e function. + */ + ret =3D mutex_lock_interruptible(&inst->dev->irq_lock); + if (ret) + return ret; + spin_lock_irqsave(&inst->dev->irq_spinlock, flags); + list_del_init(&inst->list); + spin_unlock_irqrestore(&inst->dev->irq_spinlock, flags); + mutex_unlock(&inst->dev->irq_lock); if (inst->state !=3D VPU_INST_STATE_NONE) { u32 fail_res; =20 diff --git a/drivers/media/platform/chips-media/wave5/wave5-helper.h b/driv= ers/media/platform/chips-media/wave5/wave5-helper.h index 976a402e426ff..d61fdbda359d6 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-helper.h +++ b/drivers/media/platform/chips-media/wave5/wave5-helper.h @@ -33,4 +33,5 @@ void wave5_update_pix_fmt(struct v4l2_pix_format_mplane *= pix_mp, unsigned int width, unsigned int height, const struct v4l2_frmsize_stepwise *frmsize); +int wave5_kfifo_alloc(struct vpu_instance *inst); #endif diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c b/dri= vers/media/platform/chips-media/wave5/wave5-vpu-dec.c index a90f00f589e04..cff2fa17c3f59 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c @@ -1810,6 +1810,11 @@ static int wave5_vpu_open_dec(struct file *filp) inst->xfer_func =3D V4L2_XFER_FUNC_DEFAULT; =20 init_completion(&inst->irq_done); + ret =3D wave5_kfifo_alloc(inst); + if (ret) { + dev_err(inst->dev->dev, "failed to allocate fifo\n"); + goto cleanup_inst; + } =20 inst->id =3D ida_alloc(&inst->dev->inst_ida, GFP_KERNEL); if (inst->id < 0) { diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c b/dri= vers/media/platform/chips-media/wave5/wave5-vpu-enc.c index 5388efa63f73d..24fc0d0d3f4aa 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c @@ -1759,6 +1759,11 @@ static int wave5_vpu_open_enc(struct file *filp) inst->frame_rate =3D 30; =20 init_completion(&inst->irq_done); + ret =3D wave5_kfifo_alloc(inst); + if (ret) { + dev_err(inst->dev->dev, "failed to allocate fifo\n"); + goto cleanup_inst; + } =20 inst->id =3D ida_alloc(&inst->dev->inst_ida, GFP_KERNEL); if (inst->id < 0) { diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers= /media/platform/chips-media/wave5/wave5-vpu.c index 0026f58403620..3216b49976447 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c @@ -51,8 +51,11 @@ static void wave5_vpu_handle_irq(void *dev_id) u32 seq_done; u32 cmd_done; u32 irq_reason; - struct vpu_instance *inst; + u32 irq_subreason; + struct vpu_instance *inst, *tmp; struct vpu_device *dev =3D dev_id; + int val; + unsigned long flags; =20 irq_reason =3D wave5_vdi_read_register(dev, W5_VPU_VINT_REASON); seq_done =3D wave5_vdi_read_register(dev, W5_RET_SEQ_DONE_INSTANCE_INFO); @@ -60,7 +63,8 @@ static void wave5_vpu_handle_irq(void *dev_id) wave5_vdi_write_register(dev, W5_VPU_VINT_REASON_CLR, irq_reason); wave5_vdi_write_register(dev, W5_VPU_VINT_CLEAR, 0x1); =20 - list_for_each_entry(inst, &dev->instances, list) { + spin_lock_irqsave(&dev->irq_spinlock, flags); + list_for_each_entry_safe(inst, tmp, &dev->instances, list) { =20 if (irq_reason & BIT(INT_WAVE5_INIT_SEQ) || irq_reason & BIT(INT_WAVE5_ENC_SET_PARAM)) { @@ -82,22 +86,54 @@ static void wave5_vpu_handle_irq(void *dev_id) irq_reason & BIT(INT_WAVE5_ENC_PIC)) { if (cmd_done & BIT(inst->id)) { cmd_done &=3D ~BIT(inst->id); - wave5_vdi_write_register(dev, W5_RET_QUEUE_CMD_DONE_INST, - cmd_done); - inst->ops->finish_process(inst); + if (dev->irq >=3D 0) { + irq_subreason =3D + wave5_vdi_read_register(dev, W5_VPU_VINT_REASON); + if (!(irq_subreason & BIT(INT_WAVE5_DEC_PIC))) + wave5_vdi_write_register(dev, + W5_RET_QUEUE_CMD_DONE_INST, + cmd_done); + } + val =3D BIT(INT_WAVE5_DEC_PIC); + kfifo_in(&inst->irq_status, &val, sizeof(int)); } } + } + spin_unlock_irqrestore(&dev->irq_spinlock, flags); + + if (dev->irq < 0) + up(&dev->irq_sem); +} + +static irqreturn_t wave5_vpu_irq(int irq, void *dev_id) +{ + struct vpu_device *dev =3D dev_id; =20 - wave5_vpu_clear_interrupt(inst, irq_reason); + if (wave5_vdi_read_register(dev, W5_VPU_VPU_INT_STS)) { + wave5_vpu_handle_irq(dev); + return IRQ_WAKE_THREAD; } + + return IRQ_HANDLED; } =20 static irqreturn_t wave5_vpu_irq_thread(int irq, void *dev_id) { struct vpu_device *dev =3D dev_id; + struct vpu_instance *inst, *tmp; + int irq_status, ret; =20 - if (wave5_vdi_read_register(dev, W5_VPU_VPU_INT_STS)) - wave5_vpu_handle_irq(dev); + mutex_lock(&dev->irq_lock); + list_for_each_entry_safe(inst, tmp, &dev->instances, list) { + while (kfifo_len(&inst->irq_status)) { + ret =3D kfifo_out(&inst->irq_status, &irq_status, sizeof(int)); + if (!ret) + break; + + inst->ops->finish_process(inst); + } + } + mutex_unlock(&dev->irq_lock); =20 return IRQ_HANDLED; } @@ -121,6 +157,35 @@ static enum hrtimer_restart wave5_vpu_timer_callback(s= truct hrtimer *timer) return HRTIMER_RESTART; } =20 +static int irq_thread(void *data) +{ + struct vpu_device *dev =3D (struct vpu_device *)data; + struct vpu_instance *inst, *tmp; + int irq_status, ret; + + while (!kthread_should_stop()) { + if (down_interruptible(&dev->irq_sem)) + continue; + + if (kthread_should_stop()) + break; + + mutex_lock(&dev->irq_lock); + list_for_each_entry_safe(inst, tmp, &dev->instances, list) { + while (kfifo_len(&inst->irq_status)) { + ret =3D kfifo_out(&inst->irq_status, &irq_status, sizeof(int)); + if (!ret) + break; + + inst->ops->finish_process(inst); + } + } + mutex_unlock(&dev->irq_lock); + } + + return 0; +} + static int wave5_vpu_load_firmware(struct device *dev, const char *fw_name, u32 *revision) { @@ -224,6 +289,8 @@ static int wave5_vpu_probe(struct platform_device *pdev) =20 mutex_init(&dev->dev_lock); mutex_init(&dev->hw_lock); + mutex_init(&dev->irq_lock); + spin_lock_init(&dev->irq_spinlock); dev_set_drvdata(&pdev->dev, dev); dev->dev =3D &pdev->dev; =20 @@ -266,9 +333,13 @@ static int wave5_vpu_probe(struct platform_device *pde= v) } dev->product =3D wave5_vpu_get_product_id(dev); =20 + INIT_LIST_HEAD(&dev->instances); + dev->irq =3D platform_get_irq(pdev, 0); if (dev->irq < 0) { dev_err(&pdev->dev, "failed to get irq resource, falling back to polling= \n"); + sema_init(&dev->irq_sem, 1); + dev->irq_thread =3D kthread_run(irq_thread, dev, "irq thread"); hrtimer_setup(&dev->hrtimer, &wave5_vpu_timer_callback, CLOCK_MONOTONIC, HRTIMER_MODE_REL_PINNED); dev->worker =3D kthread_run_worker(0, "vpu_irq_thread"); @@ -280,7 +351,7 @@ static int wave5_vpu_probe(struct platform_device *pdev) dev->vpu_poll_interval =3D vpu_poll_interval; kthread_init_work(&dev->work, wave5_vpu_irq_work_fn); } else { - ret =3D devm_request_threaded_irq(&pdev->dev, dev->irq, NULL, + ret =3D devm_request_threaded_irq(&pdev->dev, dev->irq, wave5_vpu_irq, wave5_vpu_irq_thread, IRQF_ONESHOT, "vpu_irq", dev); if (ret) { dev_err(&pdev->dev, "Register interrupt handler, fail: %d\n", ret); @@ -288,7 +359,6 @@ static int wave5_vpu_probe(struct platform_device *pdev) } } =20 - INIT_LIST_HEAD(&dev->instances); ret =3D v4l2_device_register(&pdev->dev, &dev->v4l2_dev); if (ret) { dev_err(&pdev->dev, "v4l2_device_register, fail: %d\n", ret); @@ -356,6 +426,12 @@ static void wave5_vpu_remove(struct platform_device *p= dev) v4l2_device_unregister(&dev->v4l2_dev); =20 if (dev->irq < 0) { + if (dev->irq_thread) { + kthread_stop(dev->irq_thread); + up(&dev->irq_sem); + dev->irq_thread =3D NULL; + } + hrtimer_cancel(&dev->hrtimer); kthread_cancel_work_sync(&dev->work); kthread_destroy_worker(dev->worker); @@ -366,6 +442,7 @@ static void wave5_vpu_remove(struct platform_device *pd= ev) =20 mutex_destroy(&dev->dev_lock); mutex_destroy(&dev->hw_lock); + mutex_destroy(&dev->irq_lock); reset_control_assert(dev->resets); clk_bulk_disable_unprepare(dev->num_clks, dev->clks); wave5_vdi_release(&pdev->dev); diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.h b/driv= ers/media/platform/chips-media/wave5/wave5-vpuapi.h index 45615c15beca3..bc101397204da 100644 --- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.h +++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.h @@ -8,6 +8,7 @@ #ifndef VPUAPI_H_INCLUDED #define VPUAPI_H_INCLUDED =20 +#include #include #include #include @@ -747,6 +748,7 @@ struct vpu_device { struct video_device *video_dev_enc; struct mutex dev_lock; /* lock for the src, dst v4l2 queues */ struct mutex hw_lock; /* lock hw configurations */ + struct mutex irq_lock; int irq; enum product_id product; struct vpu_attr attr; @@ -764,7 +766,10 @@ struct vpu_device { struct kthread_worker *worker; int vpu_poll_interval; int num_clks; + struct task_struct *irq_thread; + struct semaphore irq_sem; /* signal to irq_thread when interrupt happens*/ struct reset_control *resets; + spinlock_t irq_spinlock; /* protect instances list */ }; =20 struct vpu_instance; @@ -788,6 +793,7 @@ struct vpu_instance { enum v4l2_ycbcr_encoding ycbcr_enc; enum v4l2_quantization quantization; =20 + struct kfifo irq_status; enum vpu_instance_state state; enum vpu_instance_type type; const struct vpu_instance_ops *ops; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D4E8A3E7C5A; Sat, 28 Feb 2026 17:41:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300509; cv=none; b=hvDWvl2aLBRYqT3tWLv49WAiW25e472a2vPeq6uoCP/goFwJyZvqPXaEZfzcIgwf8eqjJ4z1MCm0u27GlxvIDY5/uLSI92TWvAEV/yW+iynFd5qQEQgrSGaO3aqgxNyBh7O4iydqD3YnSfMicmrTAoxxMY9eok/VT3Vcstkay64= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300509; c=relaxed/simple; bh=KfCY36v7csohLFe6Tj9FcXVGf/LUUQD4ry8UwLdhics=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cSbUe0iplad/PhpHLMJAADYc825K6GG2iVtS+IeKsw3vnxA4P46nbblqpnyQvWuScGQAkD0t3q/qDdmY7hZy276kovYRo1mYPO9X65gGV/sPwUBH7Ypm0eFPsVV0Co8MsUEvkAw57NZrXggagDKpZH19OXATpklJZFE0njHLvtk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KwKb2chR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KwKb2chR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6DEEC19424; Sat, 28 Feb 2026 17:41:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300509; bh=KfCY36v7csohLFe6Tj9FcXVGf/LUUQD4ry8UwLdhics=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KwKb2chRJs6RnosDunUb4x1z4kukafK9rdxqZ8zKUJysEOhdo9zo51b+Soki+SPiu 9pvrdjDa0a/AGK+J4N2ZQojoUcgDQK21poipIC203VDlpps/qABj6qmit8gPcJbY2R 93S04h8JNgdm+M30hQAFk/lh/ki+6gBK8b4ZmhxWuC+y5TnPDQLvy1xHRnhMph4BW+ w6JNomUQlRSNevz1SUf0Tep7Oa4apO0bcN15ezQORgEatJPlSwpC/37AP0AuPqRLWT Xrocdu+4CZ3jDModJrUqzdvcKpwakPmhJiroQImf9O6LZwU9UTO4UMqyRXy6fHGLET Wppp0oDp6kZKQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nicolas Dufresne , Ming Qian , Frank Li , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 547/844] media: v4l2-mem2mem: Add a kref to the v4l2_m2m_dev structure Date: Sat, 28 Feb 2026 12:27:40 -0500 Message-ID: <20260228173244.1509663-548-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicolas Dufresne [ Upstream commit db6b97a4f8041e479be9ef4b8b07022636c96f50 ] Adding a reference count to the v4l2_m2m_dev structure allow safely sharing it across multiple hardware nodes. This can be used to prevent running jobs concurrently on m2m cores that have some internal resource sharing. Signed-off-by: Ming Qian Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [hverkuil: fix typos in v4l2_m2m_put documentation] Stable-dep-of: e0203ddf9af7 ("media: verisilicon: Avoid G2 bus error while = decoding H.264 and HEVC") Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/v4l2-core/v4l2-mem2mem.c | 23 +++++++++++++++++++++++ include/media/v4l2-mem2mem.h | 21 +++++++++++++++++++++ 2 files changed, 44 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-co= re/v4l2-mem2mem.c index fec93c1a92317..ae0de54d4c3e1 100644 --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -90,6 +90,7 @@ static const char * const m2m_entity_name[] =3D { * @job_work: worker to run queued jobs. * @job_queue_flags: flags of the queue status, %QUEUE_PAUSED. * @m2m_ops: driver callbacks + * @kref: device reference count */ struct v4l2_m2m_dev { struct v4l2_m2m_ctx *curr_ctx; @@ -109,6 +110,8 @@ struct v4l2_m2m_dev { unsigned long job_queue_flags; =20 const struct v4l2_m2m_ops *m2m_ops; + + struct kref kref; }; =20 static struct v4l2_m2m_queue_ctx *get_queue_ctx(struct v4l2_m2m_ctx *m2m_c= tx, @@ -1200,6 +1203,7 @@ struct v4l2_m2m_dev *v4l2_m2m_init(const struct v4l2_= m2m_ops *m2m_ops) INIT_LIST_HEAD(&m2m_dev->job_queue); spin_lock_init(&m2m_dev->job_spinlock); INIT_WORK(&m2m_dev->job_work, v4l2_m2m_device_run_work); + kref_init(&m2m_dev->kref); =20 return m2m_dev; } @@ -1211,6 +1215,25 @@ void v4l2_m2m_release(struct v4l2_m2m_dev *m2m_dev) } EXPORT_SYMBOL_GPL(v4l2_m2m_release); =20 +void v4l2_m2m_get(struct v4l2_m2m_dev *m2m_dev) +{ + kref_get(&m2m_dev->kref); +} +EXPORT_SYMBOL_GPL(v4l2_m2m_get); + +static void v4l2_m2m_release_from_kref(struct kref *kref) +{ + struct v4l2_m2m_dev *m2m_dev =3D container_of(kref, struct v4l2_m2m_dev, = kref); + + v4l2_m2m_release(m2m_dev); +} + +void v4l2_m2m_put(struct v4l2_m2m_dev *m2m_dev) +{ + kref_put(&m2m_dev->kref, v4l2_m2m_release_from_kref); +} +EXPORT_SYMBOL_GPL(v4l2_m2m_put); + struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(struct v4l2_m2m_dev *m2m_dev, void *drv_priv, int (*queue_init)(void *priv, struct vb2_queue *src_vq, struct vb2_queue= *dst_vq)) diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h index bf6a09a04dcf8..31de25d792b98 100644 --- a/include/media/v4l2-mem2mem.h +++ b/include/media/v4l2-mem2mem.h @@ -547,6 +547,27 @@ v4l2_m2m_register_media_controller(struct v4l2_m2m_dev= *m2m_dev, */ void v4l2_m2m_release(struct v4l2_m2m_dev *m2m_dev); =20 +/** + * v4l2_m2m_get() - take a reference to the m2m_dev structure + * + * @m2m_dev: opaque pointer to the internal data to handle M2M context + * + * This is used to share the M2M device across multiple devices. This + * can be used to avoid scheduling two hardware nodes concurrently. + */ +void v4l2_m2m_get(struct v4l2_m2m_dev *m2m_dev); + +/** + * v4l2_m2m_put() - remove a reference to the m2m_dev structure + * + * @m2m_dev: opaque pointer to the internal data to handle M2M context + * + * Once the M2M device has no more references, v4l2_m2m_release() will be + * called automatically. Users of this method should never call + * v4l2_m2m_release() directly. See v4l2_m2m_get() for more details. + */ +void v4l2_m2m_put(struct v4l2_m2m_dev *m2m_dev); + /** * v4l2_m2m_ctx_init() - allocate and initialize a m2m context * --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA13D3E7C79; Sat, 28 Feb 2026 17:41:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300510; cv=none; b=nv/JVZsTSUs+nFtU9zaSDrkF02MhE60z4y4P9dyHKG4F9b0LJtLgHhwZP/SfF0QnJEreHyvvIlSkVilD/TuzoloqiTlkXGJzAfLTbb7sHUaiTWL82g6FCd3qIJXybSIsabJE4TOYgDkmC0VRgsE3imuJvCZcVnef/5SHC1FE7/s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300510; c=relaxed/simple; bh=WA+kJV/Oqg5sL3gyOoftt63DsuDFiX0tKX+nh5dcJng=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CAlbA9i8WI7PcRFJufjcYrlbYdncswiHXpNnonjaGjwz1r5IIKSAFGujdl+1+WuLxc4ulT9aQXQNu2fIeg95NhBlQx0xJ+nQ7nQp+PUm0j5TMVXwOQBLaGwHDd69+y6UFiP4bq7mlcxKPNW+3dfxpwrv90F4NaLUHZgoWRtenZE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Mxnb09wY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Mxnb09wY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBA5DC2BC87; Sat, 28 Feb 2026 17:41:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300510; bh=WA+kJV/Oqg5sL3gyOoftt63DsuDFiX0tKX+nh5dcJng=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Mxnb09wYE221mxNYrak/OCL9e4yBg/L/efvRAQNpYjr4KDspLlZy/+5kiU+CrUAa9 /EfJtQcHr2CaRWoS4LjGzdvJPMG++TQlZK1rixMVboox+NURoJnmiY6waorF2Zvg+L fFKaAh3SfLLv8QfJHtBhdmqneQOTH4RyeHHSSk1mj3vc1GpRsCXhSaqSHYZdxy1f1I 2vPRwYHjyAowGaIr9b7WQXwHieBsYHxWY/s4ZKAZp2matzH84wKsfiwJAfrEqzR4pu 52xuwOpYwQPOOs9w5eQlA1fkpZ3S7EQ6PIPbZ7MDVlmpxzb2gVWCq9FWIuRbnqqYGU CY/FvuT+6NqrA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Qian , Frank Li , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 548/844] media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC Date: Sat, 28 Feb 2026 12:27:41 -0500 Message-ID: <20260228173244.1509663-549-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Qian [ Upstream commit e0203ddf9af7c8e170e1e99ce83b4dc07f0cd765 ] For the i.MX8MQ platform, there is a hardware limitation: the g1 VPU and g2 VPU cannot decode simultaneously; otherwise, it will cause below bus error and produce corrupted pictures, even potentially lead to system hang. [ 110.527986] hantro-vpu 38310000.video-codec: frame decode timed out. [ 110.583517] hantro-vpu 38310000.video-codec: bus error detected. Therefore, it is necessary to ensure that g1 and g2 operate alternately. This allows for successful multi-instance decoding of H.264 and HEVC. To achieve this, g1 and g2 share the same v4l2_m2m_dev, and then the v4l2_m2m_dev can handle the scheduling. Fixes: cb5dd5a0fa518 ("media: hantro: Introduce G2/HEVC decoder") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Frank Li Co-developed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/verisilicon/hantro.h | 2 + .../media/platform/verisilicon/hantro_drv.c | 42 +++++++++++++++++-- .../media/platform/verisilicon/imx8m_vpu_hw.c | 8 ++++ 3 files changed, 49 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/verisilicon/hantro.h b/drivers/media/pl= atform/verisilicon/hantro.h index e0fdc4535b2d7..0353de154a1ec 100644 --- a/drivers/media/platform/verisilicon/hantro.h +++ b/drivers/media/platform/verisilicon/hantro.h @@ -77,6 +77,7 @@ struct hantro_irq { * @double_buffer: core needs double buffering * @legacy_regs: core uses legacy register set * @late_postproc: postproc must be set up at the end of the job + * @shared_devices: an array of device ids that cannot run concurrently */ struct hantro_variant { unsigned int enc_offset; @@ -101,6 +102,7 @@ struct hantro_variant { unsigned int double_buffer : 1; unsigned int legacy_regs : 1; unsigned int late_postproc : 1; + const struct of_device_id *shared_devices; }; =20 /** diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/medi= a/platform/verisilicon/hantro_drv.c index 60b95b5d8565f..94f58f4e4a4e5 100644 --- a/drivers/media/platform/verisilicon/hantro_drv.c +++ b/drivers/media/platform/verisilicon/hantro_drv.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include #include @@ -1035,6 +1036,41 @@ static int hantro_disable_multicore(struct hantro_de= v *vpu) return 0; } =20 +static struct v4l2_m2m_dev *hantro_get_v4l2_m2m_dev(struct hantro_dev *vpu) +{ + struct device_node *node; + struct hantro_dev *shared_vpu; + + if (!vpu->variant || !vpu->variant->shared_devices) + goto init_new_m2m_dev; + + for_each_matching_node(node, vpu->variant->shared_devices) { + struct platform_device *pdev; + struct v4l2_m2m_dev *m2m_dev; + + pdev =3D of_find_device_by_node(node); + if (!pdev) + continue; + + shared_vpu =3D platform_get_drvdata(pdev); + if (IS_ERR_OR_NULL(shared_vpu) || shared_vpu =3D=3D vpu) { + platform_device_put(pdev); + continue; + } + + v4l2_m2m_get(shared_vpu->m2m_dev); + m2m_dev =3D shared_vpu->m2m_dev; + platform_device_put(pdev); + + of_node_put(node); + + return m2m_dev; + } + +init_new_m2m_dev: + return v4l2_m2m_init(&vpu_m2m_ops); +} + static int hantro_probe(struct platform_device *pdev) { const struct of_device_id *match; @@ -1186,7 +1222,7 @@ static int hantro_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, vpu); =20 - vpu->m2m_dev =3D v4l2_m2m_init(&vpu_m2m_ops); + vpu->m2m_dev =3D hantro_get_v4l2_m2m_dev(vpu); if (IS_ERR(vpu->m2m_dev)) { v4l2_err(&vpu->v4l2_dev, "Failed to init mem2mem device\n"); ret =3D PTR_ERR(vpu->m2m_dev); @@ -1225,7 +1261,7 @@ static int hantro_probe(struct platform_device *pdev) hantro_remove_enc_func(vpu); err_m2m_rel: media_device_cleanup(&vpu->mdev); - v4l2_m2m_release(vpu->m2m_dev); + v4l2_m2m_put(vpu->m2m_dev); err_v4l2_unreg: v4l2_device_unregister(&vpu->v4l2_dev); err_clk_unprepare: @@ -1248,7 +1284,7 @@ static void hantro_remove(struct platform_device *pde= v) hantro_remove_dec_func(vpu); hantro_remove_enc_func(vpu); media_device_cleanup(&vpu->mdev); - v4l2_m2m_release(vpu->m2m_dev); + v4l2_m2m_put(vpu->m2m_dev); v4l2_device_unregister(&vpu->v4l2_dev); clk_bulk_unprepare(vpu->variant->num_clocks, vpu->clocks); reset_control_assert(vpu->resets); diff --git a/drivers/media/platform/verisilicon/imx8m_vpu_hw.c b/drivers/me= dia/platform/verisilicon/imx8m_vpu_hw.c index 5be0e2e76882f..6f8e43b7f1575 100644 --- a/drivers/media/platform/verisilicon/imx8m_vpu_hw.c +++ b/drivers/media/platform/verisilicon/imx8m_vpu_hw.c @@ -343,6 +343,12 @@ const struct hantro_variant imx8mq_vpu_variant =3D { .num_regs =3D ARRAY_SIZE(imx8mq_reg_names) }; =20 +static const struct of_device_id imx8mq_vpu_shared_resources[] __initconst= =3D { + { .compatible =3D "nxp,imx8mq-vpu-g1", }, + { .compatible =3D "nxp,imx8mq-vpu-g2", }, + { /* sentinel */ } +}; + const struct hantro_variant imx8mq_vpu_g1_variant =3D { .dec_fmts =3D imx8m_vpu_dec_fmts, .num_dec_fmts =3D ARRAY_SIZE(imx8m_vpu_dec_fmts), @@ -356,6 +362,7 @@ const struct hantro_variant imx8mq_vpu_g1_variant =3D { .num_irqs =3D ARRAY_SIZE(imx8mq_irqs), .clk_names =3D imx8mq_g1_clk_names, .num_clocks =3D ARRAY_SIZE(imx8mq_g1_clk_names), + .shared_devices =3D imx8mq_vpu_shared_resources, }; =20 const struct hantro_variant imx8mq_vpu_g2_variant =3D { @@ -371,6 +378,7 @@ const struct hantro_variant imx8mq_vpu_g2_variant =3D { .num_irqs =3D ARRAY_SIZE(imx8mq_g2_irqs), .clk_names =3D imx8mq_g2_clk_names, .num_clocks =3D ARRAY_SIZE(imx8mq_g2_clk_names), + .shared_devices =3D imx8mq_vpu_shared_resources, }; =20 const struct hantro_variant imx8mm_vpu_g1_variant =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10DD73E8891; Sat, 28 Feb 2026 17:41:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300512; cv=none; b=pWWlx+XurKA8zjxocmlbOrMvNLMegCDH6iNPNxOSIasVhUzNEAaObojYE+w5+3UPtXNZQ0MVneNh0F/BdEf2M4ONVNCgATrK8tcflOkKcgmtd08d2hr7Vn26cM0b/NjloF4OvClNWtXiAjMKMWbPn089sZKZ+8powLG0zRTAu2k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300512; c=relaxed/simple; bh=zg1h++2Onp1Py0Wdm8niZwzIbpzCaE8f1VPplrFScIk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tY4QD4JqXFzhs2jSWfMAz1VWx/G80OogCU70tQ7QLYlrGgdhvOyyEgyKK5qMKPQGb3yM5nEzdirz6n7sfWIGktZ6k8E7iSzEhwyxnNyRr3JsQuH5JGAz9PZ4brPtq2iG1g/vbDNHQT7AanRyRfaDXOq4eCP1QGDLEMef2XP5Lgc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g4uxuX3M; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g4uxuX3M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2E29C19424; Sat, 28 Feb 2026 17:41:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300511; bh=zg1h++2Onp1Py0Wdm8niZwzIbpzCaE8f1VPplrFScIk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g4uxuX3MPWkb51q+cFugoVsEqYjHWEyw6cLw5cTxWUbWjQkPTFr+JTBb3cHWvH5Ir kjjfmRUqJJYa4cwWECzUr+N5XUWPDZkR49ojDTcukeA2+EVngblYzPixV+JH7VxqRg FmtVopKHstEGVagLdiM1EETGIgzE4njQEnt71vj1OHRxvmL8L4jS/KkCiDMTl5Vt9C ytmBwzVhs2Wd2Mj/pKcRUgjL0eMw66VgL+Ib6V/2mQA3cht0BMVdLJ01d2kcaQfPer YF/t9lmxddRjIXtUNz8FlY9N/Q+N/JdwQZA07X1GqgiN46URvbWJSvu3Sl2GU9Kg4Y prc+XacJAISbw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Gaignard , Jianfeng Liu , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 549/844] media: verisilicon: AV1: Fix enable cdef computation Date: Sat, 28 Feb 2026 12:27:42 -0500 Message-ID: <20260228173244.1509663-550-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Gaignard [ Upstream commit e0f99b810e1181374370f91cd996d761549e147f ] If all the fields of the CDEF parameters are zero (which is the default), then av1_enable_cdef register needs to be unset (despite the V4L2_AV1_SEQUENCE_FLAG_ENABLE_CDEF possibly being set). Signed-off-by: Benjamin Gaignard Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reported-by: Jianfeng Liu Closes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4786 Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [hverkuil: dropped Link tag since it just duplicated the Closes: URL] Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../platform/verisilicon/rockchip_vpu981_hw_av1_dec.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.= c b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c index e4703bb6be7c1..f4f7cb45b1f1b 100644 --- a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c +++ b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c @@ -1396,8 +1396,16 @@ static void rockchip_vpu981_av1_dec_set_cdef(struct = hantro_ctx *ctx) u16 luma_sec_strength =3D 0; u32 chroma_pri_strength =3D 0; u16 chroma_sec_strength =3D 0; + bool enable_cdef; int i; =20 + enable_cdef =3D !(cdef->bits =3D=3D 0 && + cdef->damping_minus_3 =3D=3D 0 && + cdef->y_pri_strength[0] =3D=3D 0 && + cdef->y_sec_strength[0] =3D=3D 0 && + cdef->uv_pri_strength[0] =3D=3D 0 && + cdef->uv_sec_strength[0] =3D=3D 0); + hantro_reg_write(vpu, &av1_enable_cdef, enable_cdef); hantro_reg_write(vpu, &av1_cdef_bits, cdef->bits); hantro_reg_write(vpu, &av1_cdef_damping, cdef->damping_minus_3); =20 @@ -1953,8 +1961,6 @@ static void rockchip_vpu981_av1_dec_set_parameters(st= ruct hantro_ctx *ctx) !!(ctrls->frame->flags & V4L2_AV1_FRAME_FLAG_SHOW_FRAME)); hantro_reg_write(vpu, &av1_switchable_motion_mode, !!(ctrls->frame->flags & V4L2_AV1_FRAME_FLAG_IS_MOTION_MODE_SWITCHABLE= )); - hantro_reg_write(vpu, &av1_enable_cdef, - !!(ctrls->sequence->flags & V4L2_AV1_SEQUENCE_FLAG_ENABLE_CDEF)); hantro_reg_write(vpu, &av1_allow_masked_compound, !!(ctrls->sequence->flags & V4L2_AV1_SEQUENCE_FLAG_ENABLE_MASKED_COMPOUND)); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC18B3E88A9; Sat, 28 Feb 2026 17:41:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300512; cv=none; b=uRfPveBRV7mr67IQhWDfP8cz6lwY9M8v71RLraPBwbv+RLFAmS6lxzw/0DlYExdcUg1AVubuEhlB/YhM7vjw+82qDwar08ZabEmBsKzWE4STcSGAud3SPLeuZHNrkvzkv4Zw0IFau8HCwp/NR8o3R8SfuwFGCJlrzJ5bsxhryMI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300512; c=relaxed/simple; bh=CQIVdnlJyMptctFBerqJivMDLHUFVdKTfhlLmAJ14vU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Cr6p91kzZUYMrPEnB2HbP1QNIXbFj01aTA03n+mdZuhGMgO1Z/Uz3800vlxREo5nXzOSo1w2AOL4AwFXYnCSZD6M+OgxdxFqpsYIZL/IQ4Bhnav1Gwt0mafgSQzglCMRo/r7KyMP57KREW0p/VjK3Sz6L7i/8gPuxXXV+lhb7yw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dVaww0kT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dVaww0kT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6F79C116D0; Sat, 28 Feb 2026 17:41:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300512; bh=CQIVdnlJyMptctFBerqJivMDLHUFVdKTfhlLmAJ14vU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dVaww0kTx1gwHrYt8dypQ+GT9dVgxNE+jlKUtjadY6cFfmcHjh8o7vyL0fJk788nF hWXGEaOX4kMCA8HD3BYt2EJAJDc2ZnKgzIxP54HtaqRIhkD1WknosFQPG11Fm+Nufd W9wRrMtxBzeZQ9MxG68vL+xqkQd13UgCZDWdKHEmB0VNVm0HjFJ0k5mGpPA+Ua05LU 8/naSvtplKqObb0NnNiYd6G1XKDQOoXugzmhHerZJvp4mQ7vUclb3IhrnywrgcK9Z9 BU9kt0ZmoUgtMiCXCoN22uKa8PCVJsrSCHqYsvtIgD+4BFzsWhN24enGSZGVxh0FJQ YqM/IWMBT5S3g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Gaignard , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 550/844] media: verisilicon: AV1: Fix tx mode bit setting Date: Sat, 28 Feb 2026 12:27:43 -0500 Message-ID: <20260228173244.1509663-551-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Gaignard [ Upstream commit cb3f945c012ab152fd2323e0df34c2b640071738 ] AV1 specification describes 3 possibles tx modes: 4x4 only, largest and select. The hardware allows 5 possibles tx modes: 4x4 only, 8x8, 16x16, 32x32 and select. Since the both aren't exactly matching we need to add a mapping function to set the correct mode on hardware. Signed-off-by: Benjamin Gaignard Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../verisilicon/rockchip_vpu981_hw_av1_dec.c | 27 ++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.= c b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c index f4f7cb45b1f1b..f52b8208e6b93 100644 --- a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c +++ b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c @@ -72,6 +72,14 @@ : AV1_DIV_ROUND_UP_POW2((_value_), (_n_))); \ }) =20 +enum rockchip_av1_tx_mode { + ROCKCHIP_AV1_TX_MODE_ONLY_4X4 =3D 0, + ROCKCHIP_AV1_TX_MODE_8X8 =3D 1, + ROCKCHIP_AV1_TX_MODE_16x16 =3D 2, + ROCKCHIP_AV1_TX_MODE_32x32 =3D 3, + ROCKCHIP_AV1_TX_MODE_SELECT =3D 4, +}; + struct rockchip_av1_film_grain { u8 scaling_lut_y[256]; u8 scaling_lut_cb[256]; @@ -1935,11 +1943,26 @@ static void rockchip_vpu981_av1_dec_set_reference_f= rames(struct hantro_ctx *ctx) rockchip_vpu981_av1_dec_set_other_frames(ctx); } =20 +static int rockchip_vpu981_av1_get_hardware_tx_mode(enum v4l2_av1_tx_mode = tx_mode) +{ + switch (tx_mode) { + case V4L2_AV1_TX_MODE_ONLY_4X4: + return ROCKCHIP_AV1_TX_MODE_ONLY_4X4; + case V4L2_AV1_TX_MODE_LARGEST: + return ROCKCHIP_AV1_TX_MODE_32x32; + case V4L2_AV1_TX_MODE_SELECT: + return ROCKCHIP_AV1_TX_MODE_SELECT; + } + + return ROCKCHIP_AV1_TX_MODE_32x32; +} + static void rockchip_vpu981_av1_dec_set_parameters(struct hantro_ctx *ctx) { struct hantro_dev *vpu =3D ctx->dev; struct hantro_av1_dec_hw_ctx *av1_dec =3D &ctx->av1_dec; struct hantro_av1_dec_ctrls *ctrls =3D &av1_dec->ctrls; + int tx_mode; =20 hantro_reg_write(vpu, &av1_skip_mode, !!(ctrls->frame->flags & V4L2_AV1_FRAME_FLAG_SKIP_MODE_PRESENT)); @@ -2005,7 +2028,9 @@ static void rockchip_vpu981_av1_dec_set_parameters(st= ruct hantro_ctx *ctx) !!(ctrls->frame->flags & V4L2_AV1_FRAME_FLAG_ALLOW_HIGH_PRECISION_MV)); hantro_reg_write(vpu, &av1_comp_pred_mode, (ctrls->frame->flags & V4L2_AV1_FRAME_FLAG_REFERENCE_SELECT) ? 2 : 0); - hantro_reg_write(vpu, &av1_transform_mode, (ctrls->frame->tx_mode =3D=3D = 1) ? 3 : 4); + + tx_mode =3D rockchip_vpu981_av1_get_hardware_tx_mode(ctrls->frame->tx_mod= e); + hantro_reg_write(vpu, &av1_transform_mode, tx_mode); hantro_reg_write(vpu, &av1_max_cb_size, (ctrls->sequence->flags & V4L2_AV1_SEQUENCE_FLAG_USE_128X128_SUPERBLOCK) ? 7 : 6); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B064E3E8886; Sat, 28 Feb 2026 17:41:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300513; cv=none; b=BrXPTdeS+TM4U4tnik9XNZKxNFRwvUfGXk3/NlDBhu5mO7CGuQe+25r8lnnGIa2guGkcRF76sNXy7+4jcbTHDwPoIgkCSgA349bbWObY6jgx79Nj1wg9w6joUsASh11KkqgE70RRJdcjp9NaBX3DeCLfs3nF9+Dc4Hj1W3iF4Mk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300513; c=relaxed/simple; bh=TtWiXUJEcIzPQTPR8skO0mNuCG8o8MRv7xf2wd9NKls=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uCnSNJxYJvJX6ghUe86v2aRW9JdzMZ6upgYcpIE6ghuxCJLDMX6PP6KfR4EQ/TXcFCxReooKqDxFunT+ZlelKMRSzrVBFYnOq4F0gt+lkcDMj0oqU86iIB0Nb2cpeDKvGvz7VXmSl6yLFiFKvo4LzMRuZSZdGj+HY7SAcddY3IE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mzLMXSvx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mzLMXSvx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C98BCC2BC87; Sat, 28 Feb 2026 17:41:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300513; bh=TtWiXUJEcIzPQTPR8skO0mNuCG8o8MRv7xf2wd9NKls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mzLMXSvxeAlrZZXQENWFQpgocOvx0eEHfCUsMjL8t2sc01FS4f12t3vl+FK2PSVT5 VrelEiYGaXuvGSRRsVB9Qfj2PUneJU8LFn1P8ggcNv7kGdx+WinazszPSwGxot00gZ ZCUIpgpPLczog9T4X8SOJZmkPjt4gM5EBI0I4Mx7dXzdNcGtJIFT6fnjIEqiBcb3Tw qvvSouJD3Vfa4mVPS7FEG8FUgux4AjEHgmwkoNkDqLiWPTgsLeW6PWdQupdhFd8GzT l0UZNnYWJngQeAwt35Y62KJ85R8phr/511CCv9/LxUzE8qItdkJhVbtJWApl+Kly6y qruGUe34XD9cQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Abel Vesa , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.19 551/844] arm64: dts: qcom: x1e80100: Add missing TCSR ref clock to the DP PHYs Date: Sat, 28 Feb 2026 12:27:44 -0500 Message-ID: <20260228173244.1509663-552-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Abel Vesa [ Upstream commit 0907cab01ff9746ecf08592edd9bd85d2636be58 ] The DP PHYs on X1E80100 need the ref clock which is provided by the TCSR CC. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So lets attach it to each of the DP PHYs in order to do that. Cc: stable@vger.kernel.org # v6.9 Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes") Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20251224-phy-qcom-edp-add-missing-refclk-v5= -3-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/qcom/hamoa.dtsi | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom= /hamoa.dtsi index 83a0a0c3239d2..9e0934b302c3e 100644 --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi @@ -5896,9 +5896,11 @@ mdss_dp2_phy: phy@aec2a00 { <0 0x0aec2000 0 0x1c8>; =20 clocks =3D <&dispcc DISP_CC_MDSS_DPTX2_AUX_CLK>, - <&dispcc DISP_CC_MDSS_AHB_CLK>; + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&tcsr TCSR_EDP_CLKREF_EN>; clock-names =3D "aux", - "cfg_ahb"; + "cfg_ahb", + "ref"; =20 power-domains =3D <&rpmhpd RPMHPD_MX>; =20 @@ -5916,9 +5918,11 @@ mdss_dp3_phy: phy@aec5a00 { <0 0x0aec5000 0 0x1c8>; =20 clocks =3D <&dispcc DISP_CC_MDSS_DPTX3_AUX_CLK>, - <&dispcc DISP_CC_MDSS_AHB_CLK>; + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&tcsr TCSR_EDP_CLKREF_EN>; clock-names =3D "aux", - "cfg_ahb"; + "cfg_ahb", + "ref"; =20 power-domains =3D <&rpmhpd RPMHPD_MX>; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6ED9D3EA5BE; Sat, 28 Feb 2026 17:41:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300514; cv=none; b=cldNbRf+cuY26L3iZbRuYKHR9X4tS0/ykwwPvnc0Cas1Aa/wLG9xZ1WR8E1/ulxUihA4j7b2++WB0vueAqhyMJEpT3CiJphbTEUdYFmJcQNbTtZPCvUBdpW9cviluEkDhQ1gxdL1WGZCyxpLJ9RyZTYNnN3krJkhEhDX4rc/Q8o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300514; c=relaxed/simple; bh=9TDccymzhbg0uNBI2s6j0V/aOaYjuZ7T4QGlrk/QbuA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=u0LuS+qOCGIfFud5O9E4XONtP9c893ZUO8Bq061Q31HRA0VCTCzzkGdYnlD9fNOiyUG3+oAbzc+UaKOFrscYgoj/fMVoF4zFiZqfI0kO/+GoxaOye2U1mcsHpdU0HmBGGxlNtOSzluDmaa0GjqHd619H7NU0Ac0HpcIU8NH63z8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H1NeDnzM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H1NeDnzM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5774C19423; Sat, 28 Feb 2026 17:41:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300514; bh=9TDccymzhbg0uNBI2s6j0V/aOaYjuZ7T4QGlrk/QbuA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H1NeDnzMc2O1ncx1+3a1W48h9pzoJ/0JcSjqR+g7+ia9YLgnbooqdv1spm1vw8wxP WKCsQZkWahWLW0NUsM2zQda5LWvrT4y3haF/vyKyiIVTolpib2VtPguLcuswjpZo1t +Z0d0FaVx/8Hm7gk/GlMFnP1mge1OBozldPV3snbV2xKhUjKp/9TJQ4sZMd4lbg3ne iEUNLfiLh39BZSrEO0TjpjEJf549tAX9xyLmYiKUAvP0lxpHVM5JtIDYeNrbD82h7l oLrKgqAzF4+gmol6FIKS4Z5IAN98iBdMoKx85vO6K/KnJJy8IqsKe1Hhce3bl21bw2 g5Ap/+6rJKslw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Krzysztof Kozlowski , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.19 552/844] arm64: dts: qcom: sm8750: Fix BAM DMA probing Date: Sat, 28 Feb 2026 12:27:45 -0500 Message-ID: <20260228173244.1509663-553-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Krzysztof Kozlowski [ Upstream commit 1c6192ec9c4ab8bdb7b2cf8763b7ef7e38671ffe ] Bindings always required "qcom,num-ees" and "num-channels" properties, as reported by dtbs_check: sm8750-mtp.dtb: dma-controller@1dc4000 (qcom,bam-v1.7.4): 'anyOf' conditi= onal failed, one must be fixed: 'qcom,powered-remotely' is a required property 'num-channels' is a required property 'qcom,num-ees' is a required property 'clocks' is a required property 'clock-names' is a required property However since commit 5068b5254812 ("dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees") missing properties are actually fatal and BAM does not probe: bam-dma-engine 1dc4000.dma-controller: num-channels unspecified in dt bam-dma-engine 1dc4000.dma-controller: probe with driver bam-dma-engine f= ailed with error -22 Fixes: eeb0f3e4ea67 ("arm64: dts: qcom: sm8750: Add QCrypto nodes") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251229115734.205744-2-krzysztof.kozlowski= @oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qco= m/sm8750.dtsi index 3f0b57f428bbb..0efbf5e29f0f7 100644 --- a/arch/arm64/boot/dts/qcom/sm8750.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi @@ -2073,6 +2073,8 @@ cryptobam: dma-controller@1dc4000 { <&apps_smmu 0x481 0>; =20 qcom,ee =3D <0>; + qcom,num-ees =3D <4>; + num-channels =3D <20>; qcom,controlled-remotely; }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99ADA3EA5B7; Sat, 28 Feb 2026 17:41:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300515; cv=none; b=GcqYylLGUxJLY/jFVKL1Bqo3sGa2T5oz6nY9ENgeWZsSSlYUMuN+7cMNH6fXNh0vpm1cgRFug0t9Khw+se0uFyzV+QwAIiIrYqoDk2AsJ2stP/JGJBMjkUNQwLNUebMaXMjFv2anEVfE4CQ3WmG1QscRc/eJuh9Je6PUHriC/X8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300515; c=relaxed/simple; bh=jVAGHU9MsljkJMXVer6SXYH4Vq7rqfsrTM50qaL2KMM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=APWFoaC7vbhZwEm/dGMtgNunqrELdCN7BPi7pydf0dkNqyIXfDVsm8MjBrYkp5ZWovNxwNOQTFqZ+JtwWY7fwwpvpYV3idiA/9fesHZQD1Gab1VC9ex5pO4dV00hmG/tg9knwlKFQMzReUOUaqFu2feUDAms5CSYDTb0l7bpST8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WVs3yW2U; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WVs3yW2U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 988A4C19424; Sat, 28 Feb 2026 17:41:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300515; bh=jVAGHU9MsljkJMXVer6SXYH4Vq7rqfsrTM50qaL2KMM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WVs3yW2Uze3arUGlg/OhLqu4Cyl4m+RuDFZTTiimpRzPLKlJcj0n7QVqNMm2lmOT/ tiE0iSFBqYfPS6KAbtpOg7cBzTlHdKV5DeG1BUw7720PXEFtBG4Yl8WqOFPTZI47ov 8k5BF56wWr/Pl4Qy2PEweeV/kLZK3VpKK7x9uVen4Q9vY06ic0OxmfL7nqAq6AVWzP YCf29vcwPm8wfDUVy6sneC9wqMwVbxCDn4tODN0sWdpi6SETNS+7a+YBT2qMXNU2mK LPsZ68gB3HWwXevjdzrWSimDA4NhLzt1IpinRI6dw7uT7T8R5Xx0muXuEmKoAnt8/S 1HlHzbNftVjRA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Wentao Liang , Andreas Kemnade , Kevin Hilman , Sasha Levin Subject: [PATCH 6.19 553/844] ARM: omap2: Fix reference count leaks in omap_control_init() Date: Sat, 28 Feb 2026 12:27:46 -0500 Message-ID: <20260228173244.1509663-554-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wentao Liang [ Upstream commit 93a04ab480c8bbcb7d9004be139c538c8a0c1bc8 ] The of_get_child_by_name() function increments the reference count of child nodes, causing multiple reference leaks in omap_control_init(): 1. scm_conf node never released in normal/error paths 2. clocks node leak when checking existence 3. Missing scm_conf release before np in error paths Fix these leaks by adding proper of_node_put() calls and separate error handling. Fixes: e5b635742e98 ("ARM: OMAP2+: control: add syscon support for register= accesses") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20251217142122.1861292-1-vulab@iscas.ac.cn Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm/mach-omap2/control.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 79860b23030de..eb6fc7c61b6e0 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -732,7 +732,7 @@ int __init omap2_control_base_init(void) */ int __init omap_control_init(void) { - struct device_node *np, *scm_conf; + struct device_node *np, *scm_conf, *clocks_node; const struct of_device_id *match; const struct omap_prcm_init_data *data; int ret; @@ -753,16 +753,19 @@ int __init omap_control_init(void) =20 if (IS_ERR(syscon)) { ret =3D PTR_ERR(syscon); - goto of_node_put; + goto err_put_scm_conf; } =20 - if (of_get_child_by_name(scm_conf, "clocks")) { + clocks_node =3D of_get_child_by_name(scm_conf, "clocks"); + if (clocks_node) { + of_node_put(clocks_node); ret =3D omap2_clk_provider_init(scm_conf, data->index, syscon, NULL); if (ret) - goto of_node_put; + goto err_put_scm_conf; } + of_node_put(scm_conf); } else { /* No scm_conf found, direct access */ ret =3D omap2_clk_provider_init(np, data->index, NULL, @@ -780,6 +783,9 @@ int __init omap_control_init(void) =20 return 0; =20 +err_put_scm_conf: + if (scm_conf) + of_node_put(scm_conf); of_node_put: of_node_put(np); return ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8EE6A3EAE71; Sat, 28 Feb 2026 17:41:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300516; cv=none; b=eftbr+F9QhscmUpAIatxVyUUriLzbYu5cjvwla6szKjhtDjtx3m2P426T4SyKcenX6R/WO0Zizs8+BEzv6Ilbigf9bWex6PWvQ9b0x+dBa5/LL61GjfmsI41KrZruQ1coXtY1XfDTy5qQ+mM2S9hyO0xnl5/swbx67a64fimVrY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300516; c=relaxed/simple; bh=XMJpDTLdhtk0HnBKXtLfwrh8DmxRCR19o+jYxY50M94=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IUG5sU5tOmZBo/cQVzsq6Tv4YRkt4k4ZwTOS4F40n8qtEAnBZBrueosrz/0i93RCawKbWeHMBUIQ+ld2LHvO3QX1dNVC7YlqEOmut9egj4lJmmgksGbwnqaia1FmuQcYGVqsH3UuaE3g4J/dqKHcKOXyWdg3Pbt2QaF7h5ixUr4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c3sZlu6b; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c3sZlu6b" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D2E1C2BC9E; Sat, 28 Feb 2026 17:41:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300516; bh=XMJpDTLdhtk0HnBKXtLfwrh8DmxRCR19o+jYxY50M94=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c3sZlu6b3XhzgwPyyBCRxFwsrwzUQswOx9EOWXwrkdJf5YWnVLuv47qkrrrK7k5if ssLtYdx/SDa3cWHcaJ5WRPeLoJaLFy8P2KbinEVdyWk03u0yIRaT+eGCtebNoFFG1Q q0KJiFnDIlrFnW8bOFID/D/GqV9s69tA1xegMem0MkBHdLhbDM+Nz8u4fbU+b0xAy4 Uj9tpsGqarvgzyaxR6OT+PPzb0nKMD3JslIB9ZEiNOeWPtwDoiW5H31cXCzfaAR2NJ 5KsYIHZ4/csAKjWmEJaiMxWN61ReeP8GCyMIiRx/dKhMg6uZK67RtUJHKiODkeMpn3 IizJ5uk4GIsmg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yeoreum Yun , Breno Leitao , Andrew Morton , Pratyush Yadav , Will Deacon , Sasha Levin Subject: [PATCH 6.19 554/844] arm64: kernel: initialize missing kexec_buf->random field Date: Sat, 28 Feb 2026 12:27:47 -0500 Message-ID: <20260228173244.1509663-555-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yeoreum Yun [ Upstream commit 15dd20dda979ebab72f6df97845828e78d63ab91 ] Commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") introduced the kexec_buf->random field to enable random placement of kexec_buf. However, this field was never properly initialized for kexec images that do not need to be placed randomly, leading to the following UBSAN warning: [ +0.364528] ------------[ cut here ]------------ [ +0.000019] UBSAN: invalid-load in ./include/linux/kexec.h:210:12 [ +0.000131] load of value 2 is not a valid value for type 'bool' (aka '_B= ool') [ +0.000003] CPU: 4 UID: 0 PID: 927 Comm: kexec Not tainted 6.18.0-rc7+ #3= PREEMPT(full) [ +0.000002] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/20= 15 [ +0.000000] Call trace: [ +0.000001] show_stack+0x24/0x40 (C) [ +0.000006] __dump_stack+0x28/0x48 [ +0.000002] dump_stack_lvl+0x7c/0xb0 [ +0.000002] dump_stack+0x18/0x34 [ +0.000001] ubsan_epilogue+0x10/0x50 [ +0.000002] __ubsan_handle_load_invalid_value+0xc8/0xd0 [ +0.000003] locate_mem_hole_callback+0x28c/0x2a0 [ +0.000003] kexec_locate_mem_hole+0xf4/0x2f0 [ +0.000001] kexec_add_buffer+0xa8/0x178 [ +0.000002] image_load+0xf0/0x258 [ +0.000001] __arm64_sys_kexec_file_load+0x510/0x718 [ +0.000002] invoke_syscall+0x68/0xe8 [ +0.000001] el0_svc_common+0xb0/0xf8 [ +0.000002] do_el0_svc+0x28/0x48 [ +0.000001] el0_svc+0x40/0xe8 [ +0.000002] el0t_64_sync_handler+0x84/0x140 [ +0.000002] el0t_64_sync+0x1bc/0x1c0 To address this, initialise kexec_buf->random field properly. Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Suggested-by: Breno Leitao Cc: stable@vger.kernel.org Signed-off-by: Yeoreum Yun Reviewed-by: Breno Leitao Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggm= pukpnzadw@c67o7njgdgm3/ [1] Link: https://lore.kernel.org/all/20250825180531.94bfb86a26a43127c0a1296f@l= inux-foundation.org/ [2] Link: https://lkml.kernel.org/r/20250826-akpm-v1-1-3c831f0e3799@debian.org Signed-off-by: Breno Leitao Suggested-by: Andrew Morton Signed-off-by: Andrew Morton Reviewed-by: Pratyush Yadav Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/kernel/kexec_image.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_imag= e.c index 532d72ea42ee8..b70f4df15a1ae 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -41,7 +41,7 @@ static void *image_load(struct kimage *image, struct arm64_image_header *h; u64 flags, value; bool be_image, be_kernel; - struct kexec_buf kbuf; + struct kexec_buf kbuf =3D {}; unsigned long text_offset, kernel_segment_number; struct kexec_segment *kernel_segment; int ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA0B23EAE8D; Sat, 28 Feb 2026 17:41:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300517; cv=none; b=XIHMrkenP1LXUDgHMBTCbdi4RgVOZFPSoeHMWHj4XmLjK87d91IEtphIL+5cUzXIAtK3lHHYpAXmMqkvQbOr9pIw8JkfoncEcP/waUUm979tBDYLcBScrtgNGtCAVy5KINoAZc0LOtkV0HO101ALYe3f8ckoiA+F67peag7rMnQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300517; c=relaxed/simple; bh=uo0zheTrvVxNjJYDzhSfBNrPEoWnK7upvG0njhOADD0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JWjpHnTF5obMnT+4kmrnsa7MDt9JHu3Bz90lfV9gm/4QjI1tWPq5hXqmW1H53U12dtclIcgFmkwcRXA3YzrGrvbsa6+6m9R4TThC7OjtndLOwATiFwqgpqUOc55LyEGse9EDa36MQekmI4WWEcr5fIMB23nsVLV1VjcJBuDVVGI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=di0wJn0G; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="di0wJn0G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A98DBC2BC87; Sat, 28 Feb 2026 17:41:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300517; bh=uo0zheTrvVxNjJYDzhSfBNrPEoWnK7upvG0njhOADD0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=di0wJn0GVNXKDhtvgK0WAIBMG9ytov6uBQ3E0zxridn8S1M6ONZeojR+84Tt7V3lV j/sp06qeZFGoBI8PL9SndksW8/7SL+CUZUT7uKdkTXwW6BxgHsYVuu4wszs0FKcFSR MV7aLV5w7zWutzXWXyuaVaPXp/cWVQOgOGpIqYcZ9PDV8MmnJXzrV5hfOfankAufAG ILrtVEEJU/e7QKd2Hp3Z3Z8fUzsbCHDlKGw8SfW58Mq+GcOo/j6NARMijBqRFDFSjg 90pZ7XCziHamtizaNV57MRgz6uvFvWf2jsU7eFTSwU/d61bGun4yAKIeHkOS8UPi/L CoFdAzxbbqZog== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nam Cao , Nilay Shroff , Madhavan Srinivasan , Sasha Levin Subject: [PATCH 6.19 555/844] powerpc/pseries: Fix MSI-X allocation failure when quota is exceeded Date: Sat, 28 Feb 2026 12:27:48 -0500 Message-ID: <20260228173244.1509663-556-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nam Cao [ Upstream commit c0215e2d72debcd9cbc1c002fb012d50a3140387 ] Nilay reported that since commit daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_domain()"), the NVMe driver cannot enable MSI-X when the device's MSI-X table size is larger than the firmware's MSI quota for the device. This is because the commit changes how rtas_prepare_msi_irqs() is called: - Before, it is called when interrupts are allocated at the global interrupt domain with nvec_in being the number of allocated interrupts. rtas_prepare_msi_irqs() can return a positive number and the allocation will be retried. - Now, it is called at the creation of per-device interrupt domain with nvec_in being the number of interrupts that the device supports. If rtas_prepare_msi_irqs() returns positive, domain creation just fails. For Nilay's NVMe driver case, rtas_prepare_msi_irqs() returns a positive number (the quota). This causes per-device interrupt domain creation to fail and thus the NVMe driver cannot enable MSI-X. Rework to make this scenario works again: - pseries_msi_ops_prepare() only prepares as many interrupts as the quota permit. - pseries_irq_domain_alloc() fails if the device's quota is exceeded. Now, if the quota is exceeded, pseries_msi_ops_prepare() will only prepare as allowed by the quota. If device drivers attempt to allocate more interrupts than the quota permits, pseries_irq_domain_alloc() will return an error code and msi_handle_pci_fail() will allow device drivers a retry. Reported-by: Nilay Shroff Closes: https://lore.kernel.org/linuxppc-dev/6af2c4c2-97f6-4758-be33-256638= ef39e5@linux.ibm.com/ Fixes: daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_= domain()") Signed-off-by: Nam Cao Cc: stable@vger.kernel.org Tested-by: Nilay Shroff Acked-by: Nilay Shroff Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260107100230.1466093-1-namcao@linutronix.de Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/powerpc/platforms/pseries/msi.c | 44 ++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/= pseries/msi.c index a82aaa786e9e0..edc30cda5dbcb 100644 --- a/arch/powerpc/platforms/pseries/msi.c +++ b/arch/powerpc/platforms/pseries/msi.c @@ -19,6 +19,11 @@ =20 #include "pseries.h" =20 +struct pseries_msi_device { + unsigned int msi_quota; + unsigned int msi_used; +}; + static int query_token, change_token; =20 #define RTAS_QUERY_FN 0 @@ -433,8 +438,28 @@ static int pseries_msi_ops_prepare(struct irq_domain *= domain, struct device *dev struct msi_domain_info *info =3D domain->host_data; struct pci_dev *pdev =3D to_pci_dev(dev); int type =3D (info->flags & MSI_FLAG_PCI_MSIX) ? PCI_CAP_ID_MSIX : PCI_CA= P_ID_MSI; + int ret; + + struct pseries_msi_device *pseries_dev __free(kfree) + =3D kmalloc(sizeof(*pseries_dev), GFP_KERNEL); + if (!pseries_dev) + return -ENOMEM; + + while (1) { + ret =3D rtas_prepare_msi_irqs(pdev, nvec, type, arg); + if (!ret) + break; + else if (ret > 0) + nvec =3D ret; + else + return ret; + } =20 - return rtas_prepare_msi_irqs(pdev, nvec, type, arg); + pseries_dev->msi_quota =3D nvec; + pseries_dev->msi_used =3D 0; + + arg->scratchpad[0].ptr =3D no_free_ptr(pseries_dev); + return 0; } =20 /* @@ -443,9 +468,13 @@ static int pseries_msi_ops_prepare(struct irq_domain *= domain, struct device *dev */ static void pseries_msi_ops_teardown(struct irq_domain *domain, msi_alloc_= info_t *arg) { + struct pseries_msi_device *pseries_dev =3D arg->scratchpad[0].ptr; struct pci_dev *pdev =3D to_pci_dev(domain->dev); =20 rtas_disable_msi(pdev); + + WARN_ON(pseries_dev->msi_used); + kfree(pseries_dev); } =20 static void pseries_msi_shutdown(struct irq_data *d) @@ -546,12 +575,18 @@ static int pseries_irq_domain_alloc(struct irq_domain= *domain, unsigned int virq unsigned int nr_irqs, void *arg) { struct pci_controller *phb =3D domain->host_data; + struct pseries_msi_device *pseries_dev; msi_alloc_info_t *info =3D arg; struct msi_desc *desc =3D info->desc; struct pci_dev *pdev =3D msi_desc_to_pci_dev(desc); int hwirq; int i, ret; =20 + pseries_dev =3D info->scratchpad[0].ptr; + + if (pseries_dev->msi_used + nr_irqs > pseries_dev->msi_quota) + return -ENOSPC; + hwirq =3D rtas_query_irq_number(pci_get_pdn(pdev), desc->msi_index); if (hwirq < 0) { dev_err(&pdev->dev, "Failed to query HW IRQ: %d\n", hwirq); @@ -567,9 +602,10 @@ static int pseries_irq_domain_alloc(struct irq_domain = *domain, unsigned int virq goto out; =20 irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i, - &pseries_msi_irq_chip, domain->host_data); + &pseries_msi_irq_chip, pseries_dev); } =20 + pseries_dev->msi_used++; return 0; =20 out: @@ -582,9 +618,11 @@ static void pseries_irq_domain_free(struct irq_domain = *domain, unsigned int virq unsigned int nr_irqs) { struct irq_data *d =3D irq_domain_get_irq_data(domain, virq); - struct pci_controller *phb =3D irq_data_get_irq_chip_data(d); + struct pseries_msi_device *pseries_dev =3D irq_data_get_irq_chip_data(d); + struct pci_controller *phb =3D domain->host_data; =20 pr_debug("%s bridge %pOF %d #%d\n", __func__, phb->dn, virq, nr_irqs); + pseries_dev->msi_used -=3D nr_irqs; irq_domain_free_irqs_parent(domain, virq, nr_irqs); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 675A03EA5BE; Sat, 28 Feb 2026 17:41:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300518; cv=none; b=HrpUNNazjg1g6gehOhxiioCmLC7/J4fvWImUcU5ZLAz/2Cp+bTqgkTdTyuqN8QjKdHNEL1B1c3LSm9l2ri7hCl2+YodXacFoc5OGUzRbC4AdNGlqJvj9qD/N89ijIqyW1UwexOAWtXXamde+xz3ny7Ec/qRhTFdIOUzo/jHSiVc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300518; c=relaxed/simple; bh=eEEVN9oLK40Dq0Ox1VO1dkFABqXhehEfPgc1pr5Ax4w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YIoo42mtHhMCWXp3QP9/XKrYoXKALSWsqXSWxavfaHKRvbV8+lIvODRDTe5gB/9tiaNGZNhxFlhO2xSEAhq5u58CT3GGQrDdDwCKVvFjD9N15y2XE05oK8GmSIECPqhS2XSU6RszqlZv+vzwSgfbFS0U+YU7tuloJWPgWNolhHw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=skV72/zd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="skV72/zd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96C6FC19423; Sat, 28 Feb 2026 17:41:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300518; bh=eEEVN9oLK40Dq0Ox1VO1dkFABqXhehEfPgc1pr5Ax4w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=skV72/zdAqq3SVUpQ9514HCBhO3/QNgDrLwmevvmYDrBkFhV2A6W0kElMkxXHDKxA A+pMboAA+lr5ddE/2EYF4UkYg9jvCJG8YoJPOi10IF3Ytogv/PR0RJkaS4Mha4Qy7m Xa4S/080ZrTnL9FxePDXMt3SheEruT3Pc8PL/du67qESON1ohm0QOgKGUonkam1U63 dDXEIeWSu2z5MWjJko2fUkdSIlU2RlzacuuF7TOTqIEo4MwGFb8WRdn33egKtVz36v 0hWrFwKcTqC7YuFaol+gF6PgH1XQG16C7JsJQNv2dAw1kfGfiXEOizLkvHrLwTLAnf cspHAP/ujPweQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sean Christopherson , Jim Mattson , Sasha Levin Subject: [PATCH 6.19 556/844] KVM: x86: Return "unsupported" instead of "invalid" on access to unsupported PV MSR Date: Sat, 28 Feb 2026 12:27:49 -0500 Message-ID: <20260228173244.1509663-557-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sean Christopherson [ Upstream commit 5bb9ac1865123356337a389af935d3913ee917ed ] Return KVM_MSR_RET_UNSUPPORTED instead of '1' (which for all intents and purposes means "invalid") when rejecting accesses to KVM PV MSRs to adhere to KVM's ABI of allowing host reads and writes of '0' to MSRs that are advertised to userspace via KVM_GET_MSR_INDEX_LIST, even if the vCPU model doesn't support the MSR. E.g. running a QEMU VM with -cpu host,-kvmclock,kvm-pv-enforce-cpuid yields: qemu: error: failed to set MSR 0x12 to 0x0 qemu: target/i386/kvm/kvm.c:3301: kvm_buf_set_msrs: Assertion `ret =3D=3D cpu->kvm_msr_buf->nmsrs' failed. Fixes: 66570e966dd9 ("kvm: x86: only provide PV features if enabled in gues= t's CPUID") Cc: stable@vger.kernel.org Reviewed-by: Jim Mattson Link: https://patch.msgid.link/20251230205948.4094097-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/kvm/x86.c | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 72d37c8930ad7..042ebda1a6576 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4096,47 +4096,47 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struc= t msr_data *msr_info) break; case MSR_KVM_WALL_CLOCK_NEW: if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE2)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 vcpu->kvm->arch.wall_clock =3D data; kvm_write_wall_clock(vcpu->kvm, data, 0); break; case MSR_KVM_WALL_CLOCK: if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 vcpu->kvm->arch.wall_clock =3D data; kvm_write_wall_clock(vcpu->kvm, data, 0); break; case MSR_KVM_SYSTEM_TIME_NEW: if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE2)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 kvm_write_system_time(vcpu, data, false, msr_info->host_initiated); break; case MSR_KVM_SYSTEM_TIME: if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 kvm_write_system_time(vcpu, data, true, msr_info->host_initiated); break; case MSR_KVM_ASYNC_PF_EN: if (!guest_pv_has(vcpu, KVM_FEATURE_ASYNC_PF)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 if (kvm_pv_enable_async_pf(vcpu, data)) return 1; break; case MSR_KVM_ASYNC_PF_INT: if (!guest_pv_has(vcpu, KVM_FEATURE_ASYNC_PF_INT)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 if (kvm_pv_enable_async_pf_int(vcpu, data)) return 1; break; case MSR_KVM_ASYNC_PF_ACK: if (!guest_pv_has(vcpu, KVM_FEATURE_ASYNC_PF_INT)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; if (data & 0x1) { /* * Pairs with the smp_mb__after_atomic() in @@ -4149,7 +4149,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct = msr_data *msr_info) break; case MSR_KVM_STEAL_TIME: if (!guest_pv_has(vcpu, KVM_FEATURE_STEAL_TIME)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 if (unlikely(!sched_info_on())) return 1; @@ -4167,7 +4167,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct = msr_data *msr_info) break; case MSR_KVM_PV_EOI_EN: if (!guest_pv_has(vcpu, KVM_FEATURE_PV_EOI)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 if (kvm_lapic_set_pv_eoi(vcpu, data, sizeof(u8))) return 1; @@ -4175,7 +4175,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct = msr_data *msr_info) =20 case MSR_KVM_POLL_CONTROL: if (!guest_pv_has(vcpu, KVM_FEATURE_POLL_CONTROL)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 /* only enable bit supported */ if (data & (-1ULL << 1)) @@ -4476,61 +4476,61 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struc= t msr_data *msr_info) break; case MSR_KVM_WALL_CLOCK: if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D vcpu->kvm->arch.wall_clock; break; case MSR_KVM_WALL_CLOCK_NEW: if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE2)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D vcpu->kvm->arch.wall_clock; break; case MSR_KVM_SYSTEM_TIME: if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D vcpu->arch.time; break; case MSR_KVM_SYSTEM_TIME_NEW: if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE2)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D vcpu->arch.time; break; case MSR_KVM_ASYNC_PF_EN: if (!guest_pv_has(vcpu, KVM_FEATURE_ASYNC_PF)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D vcpu->arch.apf.msr_en_val; break; case MSR_KVM_ASYNC_PF_INT: if (!guest_pv_has(vcpu, KVM_FEATURE_ASYNC_PF_INT)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D vcpu->arch.apf.msr_int_val; break; case MSR_KVM_ASYNC_PF_ACK: if (!guest_pv_has(vcpu, KVM_FEATURE_ASYNC_PF_INT)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D 0; break; case MSR_KVM_STEAL_TIME: if (!guest_pv_has(vcpu, KVM_FEATURE_STEAL_TIME)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D vcpu->arch.st.msr_val; break; case MSR_KVM_PV_EOI_EN: if (!guest_pv_has(vcpu, KVM_FEATURE_PV_EOI)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D vcpu->arch.pv_eoi.msr_val; break; case MSR_KVM_POLL_CONTROL: if (!guest_pv_has(vcpu, KVM_FEATURE_POLL_CONTROL)) - return 1; + return KVM_MSR_RET_UNSUPPORTED; =20 msr_info->data =3D vcpu->arch.msr_kvm_poll_control; break; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 239753EB6CE; Sat, 28 Feb 2026 17:41:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300519; cv=none; b=ensRoXGrkXWjjS/cXFvfJlRgIkyu6UdTdTzKX0DCzZooi019EzldMbODI9LwVbIFBNHnxV4cOXa6sszBfeabQVI/nXHMNzHSJTySAkqPVHdl2pueYJEdO59jVDVit9DXV8hJ36ixrhACTin7IZBf6SUURN9hQB/4QdqK/BST85I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300519; c=relaxed/simple; bh=W0qTrvHv2YAPoB46BGrdjXvnMgB2NRqo3POMDi/S+PI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=INKMIFP9nLGuylx2oW5d8U2iBeDf71SUOo5Oh1iSB5fHMf50xFMv5f09CABTIKUJw9uyq4vLmDz0x0CDJCOfb04jIrRkexHDvBa17umn1lGuI1ohfgjHWrVsKhXJ7w6es/XfQjL2/ftP1UES0LsI8DplILwj817YrYsx2RE8Ih8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OhPrqLim; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OhPrqLim" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EF61C19425; Sat, 28 Feb 2026 17:41:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300519; bh=W0qTrvHv2YAPoB46BGrdjXvnMgB2NRqo3POMDi/S+PI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OhPrqLimCKEBBx87cnSwnOTOU6pH2pyIqdviPQJLoTF3Zh7RCmWE/8fjT39JgP49/ VcVGucGKEPZzl/haGdiBqe79kXstX0oOftaR/gjiUmpWIlfwCckZsKLQCgxEoDxAf0 +0v0PK4wRGisJSdQSnaeST9q2B59jKtm2JbxgaZIZFxY/jxvVkrewoL+eYlISbkbyu pFhl3/1jQkvbn7t47Rab2xwJdn4hHaAFA/wlniWbZ/eY2mEZcAwV09ep+Zz1iX0WTA EuK8suXVJWRCBVevtR/dngf0UPz0VdU3sll1Q/jjCcJyxKSQqmzzaZZQBYXw99QomI 1r1DLApPRGxXg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sean Christopherson , Yosry Ahmed , Sasha Levin Subject: [PATCH 6.19 557/844] KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding Date: Sat, 28 Feb 2026 12:27:50 -0500 Message-ID: <20260228173244.1509663-558-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sean Christopherson [ Upstream commit fc3ba56385d03501eb582e4b86691ba378e556f9 ] Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu =3D vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage =3D=3D 4) { + state->sregs.cr3 =3D BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PH= Y_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doi= ng generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_neste= d_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W = 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=3DWARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving "illegal" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline. Fixes: b222b0b88162 ("KVM: nSVM: refactor the CR3 reload on migration") Cc: stable@vger.kernel.org Cc: Yosry Ahmed Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20251216161755.1775409-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/kvm/svm/nested.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index ba0f11c68372b..9be67040e94d9 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -1870,10 +1870,9 @@ static int svm_set_nested_state(struct kvm_vcpu *vcp= u, * thus MMU might not be initialized correctly. * Set it again to fix this. */ - ret =3D nested_svm_load_cr3(&svm->vcpu, vcpu->arch.cr3, nested_npt_enabled(svm), false); - if (WARN_ON_ONCE(ret)) + if (ret) goto out_free; =20 svm->nested.force_msr_bitmap_recalc =3D true; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1529D3EB6EA; Sat, 28 Feb 2026 17:42:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300520; cv=none; b=ndmJwKpCrzjMVyJXybQ/TrXZFO2qiVHqK7ovxMfzQAMN9Ssv5H+ojSEDtdSOzHiC+CVYy49vvP+BVMAKIhp9cTBDRiWQswfg+gnOwesKUp9r2X2L9s6eatZEqE+E82K3iv3BtIW247EcWea1jktt3Ynog91m/GnVrsgOoWzC3EE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300520; c=relaxed/simple; bh=NIe5ewymfBNyGwxS6oPATd5QwlJVEWcZ8T7S1YXObKA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mBHXhG7fEI2oI0oLyJLc3icrWjHW5KVSqJwV+9YokYgCpaXG+yBwB38ybHKxmVFPp9hrQctW/ImzGxNaVN50mIc9R6BY3I1oHsbjW/dtv14zZTXjvajm764+CmKaaMGIo43XWJreqGpzAdFGJz6Ys4J39eTjMqsVpd8D+ACmnww= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g3kufk04; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g3kufk04" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AECAC19423; Sat, 28 Feb 2026 17:41:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300520; bh=NIe5ewymfBNyGwxS6oPATd5QwlJVEWcZ8T7S1YXObKA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g3kufk04BpuzW9DJCkf0BtAqw7taQISi0IQ2bwMYC/QV1gKm86qKEHkay0G18D7E0 FaKpIzYhhHhLLD+EZtsoZ4CMIQU2/SwF59Q0pZ7qEP6XDyaG8O3KZ7KIolndV6KfBb XDCZZBx+jSecJzC0b8gVkQNRzo7lN1NxjOMo7uZcbxya7BYkg/32ZVSF3by5WTcPKW cSbcY2+ujJh/e6X4B2pWRfADUY3y63G5iSuJGD/w6YUlfXAFZM9GKhh9segPOsT4+M FXFwCCHMNjuNQ9P8tLkOhzQa4YEPIpKjTxxGGFb2H/Oves+r7zXc1E5jHAgofvhOqy AsWMpFyzSTdMQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Breno Leitao , Mark Rutland , Will Deacon , Sasha Levin Subject: [PATCH 6.19 558/844] arm64: Disable branch profiling for all arm64 code Date: Sat, 28 Feb 2026 12:27:51 -0500 Message-ID: <20260228173244.1509663-559-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Breno Leitao [ Upstream commit f22c81bebf8bda6e54dc132df0ed54f6bf8756f9 ] The arm64 kernel doesn't boot with annotated branches (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together. Bisecting it, I found that disabling branch profiling in arch/arm64/mm solved the problem. Narrowing down a bit further, I found that physaddr.c is the file that needs to have branch profiling disabled to get the machine to boot. I suspect that it might invoke some ftrace helper very early in the boot process and ftrace is still not enabled(!?). Rather than playing whack-a-mole with individual files, disable branch profiling for the entire arch/arm64 tree, similar to what x86 already does in arch/x86/Kbuild. Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/Kbuild | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Kbuild b/arch/arm64/Kbuild index 5bfbf7d79c99b..d876bc0e54211 100644 --- a/arch/arm64/Kbuild +++ b/arch/arm64/Kbuild @@ -1,4 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only + +# Branch profiling isn't noinstr-safe +subdir-ccflags-$(CONFIG_TRACE_BRANCH_PROFILING) +=3D -DDISABLE_BRANCH_PROF= ILING + obj-y +=3D kernel/ mm/ net/ obj-$(CONFIG_KVM) +=3D kvm/ obj-$(CONFIG_XEN) +=3D xen/ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E7293EC6A1; Sat, 28 Feb 2026 17:42:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300521; cv=none; b=tf7oA5F/d6Mr8ini5X5A98f4gBSGwYTKT9garKLzWHgjQThIRHjS+rdiG1AfshglyjwSXLqIAH9291USDNO4tQAA83HUMj7aJLrIWQymVJvwcvqFW8DKLdEEEuitFHu9lbT7CDuSiCasbvgJiFfZ0hp1cAfe2LsD87Z1BSFzq7k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300521; c=relaxed/simple; bh=utHPXQc9RqqcaVu8J4sNgSzfIU0UZzlEg2GttMHPoY4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KByfVgoL32GYnBtFikOazVF+5RkiMWp+L2xjq4/MREdxLizC3flcBeusZTdHz9bQrTBShfCIsr0do+wQbwRim9XSVccZIajuza5sWgKjSlbidvs5kxv+VRFTLtN7ElGFQLhWK2ykf2V1KEPDumXEKjxHi59s4SvnKcTT4RcdVmk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E5a4AqD+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E5a4AqD+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CBE9C2BC9E; Sat, 28 Feb 2026 17:42:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300521; bh=utHPXQc9RqqcaVu8J4sNgSzfIU0UZzlEg2GttMHPoY4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E5a4AqD+ZrOvc8o9cipDV+js+qDcbS4y0ljpbRy36bF08M8XoAvGziKnQFU2IpvTt Eis08QFI3IoR878yJxlIfQ8HzLaz377nco7Q6vkbzlBVyO380Jxfd4/cOEsFbBxPPa J+Smi+xPzgdWv3Sz6XGyRJ0iL1jwUUTMkZgl6dEcTnFsKCXmGZsBQb2DcT3aK8MLOy XulkJ8SmwlmNnl1KDrtns0BujbxQwyeueW24My/mXEjOHPGQ+WvK+hOb/RG351LtN1 hy9deCJEMOQ8EDvejy/uSbCzOAaowsLvFckTeokCqqpxNlrRyFGEZISRLxhdRWSX+u GU1MupbpiCZ9A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bartosz Golaszewski , Martin Blumenstingl , Neil Armstrong , Linus Walleij , Sasha Levin Subject: [PATCH 6.19 559/844] pinctrl: meson: amlogic-a4: mark the GPIO controller as sleeping Date: Sat, 28 Feb 2026 12:27:52 -0500 Message-ID: <20260228173244.1509663-560-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bartosz Golaszewski [ Upstream commit d6df4abe95a409e812c5d9af9657fe63ac299e3a ] The GPIO controller is configured as non-sleeping but it uses generic pinctrl helpers which use a mutex for synchronization. This will cause lockdep splats when used together with shared GPIOs going through the GPIO shared proxy driver. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Cc: stable@vger.kernel.org Reported-by: Martin Blumenstingl Closes: https://lore.kernel.org/all/CAFBinCAc7CO8gfNQakCu3LfkYXuyTd2iRpMRm8= EKXSL0mwOnJw@mail.gmail.com/ Signed-off-by: Bartosz Golaszewski Reviewed-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pinctrl/meson/pinctrl-amlogic-a4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c b/drivers/pinctrl/m= eson/pinctrl-amlogic-a4.c index f05d8261624a4..40542edd557e0 100644 --- a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c +++ b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c @@ -895,7 +895,7 @@ static const struct gpio_chip aml_gpio_template =3D { .direction_input =3D aml_gpio_direction_input, .direction_output =3D aml_gpio_direction_output, .get_direction =3D aml_gpio_get_direction, - .can_sleep =3D false, + .can_sleep =3D true, }; =20 static void init_bank_register_bit(struct aml_pinctrl *info, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 001693EC6C1; Sat, 28 Feb 2026 17:42:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300522; cv=none; b=siv98ES8W6aLBDSt/V/pnTfP45l7Q4dLVOoV4hWzJFCGwD2TRBsT6xsM2KIUf7ZB0pph1Li5So6DYT7Tb2KATNen6wZ7Nty4azEeck6KBJAYXsDqBFUu2vq8xRLwTNYTS7pslGicGvAA3ErIMwge2N7Dcq3KWCFXuWPY8PeHlMc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300522; c=relaxed/simple; bh=OssYHVtpqWoKQFKjafrGzXcfF6y3P6GuD0ExBSD0byU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cVbq6G6sLaI3OZjxRx540OTTDq8I4iJgt1J4NQE4dRNUdqkKQlV+t7TnEX8rYCGwKYZmEL0nW8nf5R5V459q8W9wdx1xsn3XOy4FUHaAi4iDmWENP5eYs9XH+78ZqWX4/WV7U599ff7yJdgZqKUxOFJnrjZr3mWFJjumWovpisI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hwGzzLDW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hwGzzLDW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 454FFC116D0; Sat, 28 Feb 2026 17:42:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300521; bh=OssYHVtpqWoKQFKjafrGzXcfF6y3P6GuD0ExBSD0byU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hwGzzLDWkxrgFJr+xemMJRTqrNv+51x8Kn3wHLeq4Rn2xqv8ZXIlOoC2+vso99xVz Ac5a9KVYKfW7v+pS65tFPZW2MV44Sy0Eyf2x/Sw9rgYDv8t58M0RPYNK7puZ0jPGzy 6O8HEeiVrdPrCRifrVxa4505URb13bAcHwy7ukmdgHyuMPNcJKmkXrGWIRL+dvQX1a gRUpmXJnPpoUC3ivPgd7XriDPy9XokBdrzDZ3ATLAUbhuQUzBUbQhQ7dDThDDGrpYY Am1UtKarOHv6YUGlO/VGCbN75W8o1yG8aQmH2Mw3CDZ+FyYGvp4im7MXglgTPztBQ9 bbgKR/8eT2hCw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Oliver Neukum , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 560/844] HID: hid-pl: handle probe errors Date: Sat, 28 Feb 2026 12:27:53 -0500 Message-ID: <20260228173244.1509663-561-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Oliver Neukum [ Upstream commit 3756a272d2cf356d2203da8474d173257f5f8521 ] Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used. Fixes: 20eb127906709 ("hid: force feedback driver for PantherLord USB/PS2 2= in1 Adapter") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/hid-pl.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-pl.c b/drivers/hid/hid-pl.c index 3c8827081deae..dc11d5322fc0f 100644 --- a/drivers/hid/hid-pl.c +++ b/drivers/hid/hid-pl.c @@ -194,9 +194,14 @@ static int pl_probe(struct hid_device *hdev, const str= uct hid_device_id *id) goto err; } =20 - plff_init(hdev); + ret =3D plff_init(hdev); + if (ret) + goto stop; =20 return 0; + +stop: + hid_hw_stop(hdev); err: return ret; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C160E3EC6DC; Sat, 28 Feb 2026 17:42:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300522; cv=none; b=Y6fdHmUnXvq9vhJ9RdPOD1ldUEHA7DO6JgmsnUb83doSMbIgAtrqmnXNzDAdvb+orIQuHYwBIpQK3HkrmMAP+P6qNDWX9FJG3H5sWoQimUWylzm2qA/z3Ysfvo8fjdLAwXUI0Qrtd9z96/yAuSaWgrY+wTsJhG/StDjN7xeXAYQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300522; c=relaxed/simple; bh=jTY4FYVwDJIGe5KfCtsL6WWiMnwR77HoDz51E9tumDY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ihityZm5nInNaECZxf7io5l+WSSwORi93ANUhrF2A5LBa7uzkLBrulFJD3NZr1gIyGhw9TO2yuw1KeKKGQH5T1TJj1/07He0lV7JlAEGvw1GeS5fdAPW2c3EzFdEK0axZNnZv0NLE/32avbObRgqYse+Alhbf1+F/VBfuQOB0/s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AJckFi6P; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AJckFi6P" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E444C19423; Sat, 28 Feb 2026 17:42:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300522; bh=jTY4FYVwDJIGe5KfCtsL6WWiMnwR77HoDz51E9tumDY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AJckFi6PtQekcLsrbs4r/sKGjAI3ZXmf72hqwv81OKijOQ8E2HHMlSpi+PpOwOurY WS6lxjcCBva6kPcCmfGgw9tP7wHRPLNWrvt0om4EyAIc29x8MHX8xHd13qohabOi82 fhlP9VyJlmITZWkLJ9iWDSPjo/LyJ58o+u9A9VNMxC0Q5iWcBJR9uofTLs1ELWd2t7 xGUaH6PK7ktmksLEUx9tVo8c6JUHvDibib3q0JVCD9gtJnGjIedujK2+xTzpbCYaPl 2b5NHSmC90blwnAzzKQ3Gm1XhXU3KmcNLtwBnlEil0RyMZtpBP3n+2F7JNBAsLQagz Bqvyz01v0Boug== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?G=C3=BCnther=20Noack?= , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 561/844] HID: magicmouse: Do not crash on missing msc->input Date: Sat, 28 Feb 2026 12:27:54 -0500 Message-ID: <20260228173244.1509663-562-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: G=C3=BCnther Noack [ Upstream commit 17abd396548035fbd6179ee1a431bd75d49676a7 ] Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays N= ULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device. Cc: stable@vger.kernel.org Signed-off-by: G=C3=BCnther Noack Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/hid-magicmouse.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c index 7d4a25c6de0eb..91f621ceb924b 100644 --- a/drivers/hid/hid-magicmouse.c +++ b/drivers/hid/hid-magicmouse.c @@ -725,6 +725,11 @@ static int magicmouse_input_configured(struct hid_devi= ce *hdev, struct magicmouse_sc *msc =3D hid_get_drvdata(hdev); int ret; =20 + if (!msc->input) { + hid_err(hdev, "magicmouse setup input failed (no input)"); + return -EINVAL; + } + ret =3D magicmouse_setup_input(msc->input, hdev); if (ret) { hid_err(hdev, "magicmouse setup input failed (%d)\n", ret); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B0483EDF0B; Sat, 28 Feb 2026 17:42:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300523; cv=none; b=f3KqvE1LCZN6DYzP8EVFuZ/LtvlolPDfKUxE+PE+f+veAC/KFB1OMuMrpN4HQPFUAVv4aLKqz7OHgUgDIgocfhcpkf5ZHxyIwMbvd1k9oTwIjK2o4a9gp9iPRZCxoKBu1+yYscwZiayVAoMtqaoR6XoNwoUy37CgbNWuC8b0WdI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300523; c=relaxed/simple; bh=rSjy6sL5hSnkfOLqqG7zQ/p/cFN7Q4rphq2o6bHZHPo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Hlam2VHmvWBW3Fgu+juD2Ool9nEBP/F3LhBscKFxl1ffr33kKCa2Diythsn+8gUivUy5qC8o7tu3LLvjn5QsJ39qrPLOjcZCItRheQAfcEnMPoDFN+Ys16ny9/HswDiq61yuobCP8AmYUFwbcecOOWlTYJQw+uAyAi9vg1Z8xog= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XgaBsUgP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XgaBsUgP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7792C19423; Sat, 28 Feb 2026 17:42:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300523; bh=rSjy6sL5hSnkfOLqqG7zQ/p/cFN7Q4rphq2o6bHZHPo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XgaBsUgPGFEwuUDvdatHwIkt0/zHTkmBnRfGtSSQMmLd36X3eclswQlqCni66cPCx 0pQqqfQBrMv4ZR8LO1OJj0exoMUECymPig6Ax09QJX5ZQZI4uL2iSlMFfQtxwRDRzj nK3Lw6d73X8bXvZ7LUHP5InseIBEwH52nApE6lzRhEbcoezcILVcpgmlVIfPp04YDE +rUw8ZxNJ6OBmVo8xc/U8L3JS2QpuLY2Kmk4jiNCEYxj4xuPxC13CObf8k+oPWr9HZ krM4LzX3g7+Z3XVDStBWVGdEhCqcA+yb2SYDP5Aomx8sUfgZ+aZ551ACzbAhW+/Ci/ hruLwskd0mkNA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?G=C3=BCnther=20Noack?= , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 562/844] HID: prodikeys: Check presence of pm->input_ep82 Date: Sat, 28 Feb 2026 12:27:55 -0500 Message-ID: <20260228173244.1509663-563-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: G=C3=BCnther Noack [ Upstream commit cee8337e1bad168136aecfe6416ecd7d3aa7529a ] Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 sta= ys NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing = as one. Cc: stable@vger.kernel.org Signed-off-by: G=C3=BCnther Noack Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/hid-prodikeys.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/hid/hid-prodikeys.c b/drivers/hid/hid-prodikeys.c index 74bddb2c3e82e..6e413df38358a 100644 --- a/drivers/hid/hid-prodikeys.c +++ b/drivers/hid/hid-prodikeys.c @@ -378,6 +378,10 @@ static int pcmidi_handle_report4(struct pcmidi_snd *pm= , u8 *data) bit_mask =3D (bit_mask << 8) | data[2]; bit_mask =3D (bit_mask << 8) | data[3]; =20 + /* robustness in case input_mapping hook does not get called */ + if (!pm->input_ep82) + return 0; + /* break keys */ for (bit_index =3D 0; bit_index < 24; bit_index++) { if (!((0x01 << bit_index) & bit_mask)) { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C2E343EDF35; Sat, 28 Feb 2026 17:42:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300524; cv=none; b=pRkZngI2YJFuEIEndaxnhL4MaduuleWQseTpaBImx8oyMbBs1/yVPkD6fLMtDjaVDa/Ou8tgefW6KCMOGosB9oXLUtHHnJZj/4QL0vmttnVUJiXjufuZYj6EgKS+a+1RJNYNS7PCRjsalxfaVJBQJndKXSN02RYPQZaLiay//7U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300524; c=relaxed/simple; bh=DQyDUUNHdxKEpOPzA8AuiATJG9SYp80KZnKbmMotIPI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=O58jAUDASVt129u/nGoOrEcfTIUpsSwDij9NM5dr67rr2WAxUBvJgm6wJ3HKd0aEpdqRbed2yFBhmK2iKir5yPZ6D2YCU/dG8Q9STv3c3kD2qfNTFdgOaauhuseFFUwSAU4kCU+isyS/MNDeFDZc0NZHG6+e7NkAGDJMOPBBD8Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YRj/6iz1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YRj/6iz1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2E73C19425; Sat, 28 Feb 2026 17:42:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300524; bh=DQyDUUNHdxKEpOPzA8AuiATJG9SYp80KZnKbmMotIPI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YRj/6iz19TN6rHaC0tsVP8HdrSbs0JSuooDHpuw8kiinreDWMHpST0hi7c8Xjb1j3 1RJa8x+Y3VWOjBxGepjNviyC6OiP5IUmoP4loq/HbpTylSFx6ZTY4aTidbQyM7EHiV k4b86Beh7etkdtDFbaIfpc4CJMUdNIg/ivxhaHu2blBygs2jRrd7ZlfapWtEjTW3Hg 3czYGxkdYr+vIT+ffA2/qRK+hAHhV/y6qkSy26KXUjceXkRzN+Bk1Nbl2LW6vDs6Mo cZNAoaNSxqxgLhXxvNBWK5XwsoKMsKcjALorWuRl3k/YafJEqiBkIbURak+nDNwNWc LImua0WcD5EcQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?G=C3=BCnther=20Noack?= , Jiri Kosina , Sasha Levin Subject: [PATCH 6.19 563/844] HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() Date: Sat, 28 Feb 2026 12:27:56 -0500 Message-ID: <20260228173244.1509663-564-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: G=C3=BCnther Noack [ Upstream commit 1547d41f9f19d691c2c9ce4c29f746297baef9e9 ] Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define r= eport structures without valid fields. This can be used to crash the kernel over= USB. Cc: stable@vger.kernel.org Signed-off-by: G=C3=BCnther Noack Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hid/hid-logitech-hidpp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hi= dpp.c index ca96102121b85..02d83c3bd73d4 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -4314,7 +4314,7 @@ static int hidpp_get_report_length(struct hid_device = *hdev, int id) =20 re =3D &(hdev->report_enum[HID_OUTPUT_REPORT]); report =3D re->report_id_hash[id]; - if (!report) + if (!report || !report->maxfield) return 0; =20 return report->field[0]->report_count + 1; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 851693EC6DC; Sat, 28 Feb 2026 17:42:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300525; cv=none; b=t8VxExZCkB/k6+TCbuMvLzgtIZVmhXxUYTSSQbpC/spi5e7PMcgXtcqOHlOVO1/uBO15oZ0CdZb/Ldk2TGXnu3CLnqPrp+ajbe0fLZaOf2jBnG0EAATXcdAG7Yp0PgWd6/HNq0hdAPzh4kfZeNarXkcK/gsuWBNoGnxFU6KIgG4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300525; c=relaxed/simple; bh=exy+B1iLimCn8ZjMhAukkTykOgpYGNDzY5W+gbyRLS0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JZT3Jt9D2HZNDvjLiZ+Z4X5dJYHDeuTFTMaE5DuyDOJR0x4299+QrEY3pxtumjyogE8a39b8BUniIb0H6R2mY3eU10v4ZjBeLyq4draX7vdWR0HUz7uq2VLkNbd/J3WDDHF4xWH0PZ4FJ5Sfgsell9ulxTWXyD7zBViU104uPjk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EKHvm9b6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EKHvm9b6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9CBF2C2BCAF; Sat, 28 Feb 2026 17:42:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300525; bh=exy+B1iLimCn8ZjMhAukkTykOgpYGNDzY5W+gbyRLS0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EKHvm9b6fc5siXwjYs/XuGyG1Y166O/e3De6tcbK91/MKWqBrAfx4cysBIW1upcPA ATnvqPByya0pnfS0pWkh8Pn82lbBoIG7yV0XWIhXz0Xevh0BGIuTgvd/rhlALafxT6 PBdXtN++eWoSmx/maN1LjsCMq4KTwk3sPrMh2bMKEYQxzXx/DzjAhOrFfS7oe2m9gg qQ5bmhQwOkvI64rl6O5TpZhuV8wiK12juVb2xwk/Iywnffl6yXz2fOEmLYRc7EupV4 CISqnhcsYCJxffwCN46rY5g70APdjG2aljpKu4CQDmGdTGYH1p+C5nZIr2UWSuqDx2 q4RU5Gr65lPkQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christian Brauner , Jeff Layton , Sasha Levin Subject: [PATCH 6.19 564/844] fs: ensure that internal tmpfs mount gets mount id zero Date: Sat, 28 Feb 2026 12:27:57 -0500 Message-ID: <20260228173244.1509663-565-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christian Brauner [ Upstream commit a2062463e894039a6fdc2334b96afd91d44b64a8 ] and the rootfs get mount id one as it always has. Before we actually mount the rootfs we create an internal tmpfs mount which has mount id zero but is never exposed anywhere. Continue that "tradition". Link: https://patch.msgid.link/20260112-work-immutable-rootfs-v2-1-88dd1c34= a204@kernel.org Fixes: 7f9bfafc5f49 ("fs: use xarray for old mount id") Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index f6879f282daec..ecf0e72ce6cfd 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -221,7 +221,7 @@ static int mnt_alloc_id(struct mount *mnt) int res; =20 xa_lock(&mnt_id_xa); - res =3D __xa_alloc(&mnt_id_xa, &mnt->mnt_id, mnt, XA_LIMIT(1, INT_MAX), G= FP_KERNEL); + res =3D __xa_alloc(&mnt_id_xa, &mnt->mnt_id, mnt, xa_limit_31b, GFP_KERNE= L); if (!res) mnt->mnt_id_unique =3D ++mnt_id_ctr; xa_unlock(&mnt_id_xa); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6CE2F3EE734; Sat, 28 Feb 2026 17:42:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300526; cv=none; b=HWbZ/QhvYN2KWU9cqNTezzjOOFFfDnEQ4hz1NeKV4hQqyiOSue4nPXKYhqx5pVNMNUC6/EQCHWi9rXYr6nGsXsuq0DpbLz8nZA1LURtoJkD2upV7HEGuQlrnpkpHcpb8hNpQRpO1fIggaBt6ipv2VEbb4Oj1/PNpUZFYOCWbYNw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300526; c=relaxed/simple; bh=n0VniU4APJKLrJCnBIPdgoAwN0WnPU4AK3Ij7JCIl2k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DBUFedhmGLRYzdytO5hjHIUo5fAozwdPOhmZapIejHE9jmeUTBBYEFWeQCuEBDzznCpehkUk2SGg7sa8q2yWvX2T2+PG35PCkUporBGnrdEhNE87HyoouAiwawWCC8bwq6/j9YuEF8QD6gvef8bOLlJboG7MdBruDLbw1YcAjAo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AQ/sXSj9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AQ/sXSj9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77903C19425; Sat, 28 Feb 2026 17:42:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300526; bh=n0VniU4APJKLrJCnBIPdgoAwN0WnPU4AK3Ij7JCIl2k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AQ/sXSj9ORbSb+c2YNO+D0gdw/pzrZKAjdHzjdLUNHwQJAO6D2zQ0rhtd7l0YZFFO KpC6DCmyg8exzxPDfgb0fHBucxkkKcBoMx/dSUDau80kFtoiWYE2P8NrPPJD/NwtI4 JmQgAIGSK750jQSATq98gBRqpiKObgZCiqbaLLA/HwtRcN9emntGryQpaNDmlFWw/L b10LzNgtZyb3OepO0az+OcpmInUv9IuzSngdT52TbqBqdH9/Z0i2TU7gtyrAGgGqij hTDiuQkfw6hPi3Cq+ms4Hu1TeKBEZNzn/z1EaBWB9Lt8iaKLSklJy4Qz1hieZV4DHw i5Lm3INpmfN7g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Janne Grunau , Sven Peter , Sasha Levin Subject: [PATCH 6.19 565/844] arm64: dts: apple: t8112-j473: Keep the HDMI port powered on Date: Sat, 28 Feb 2026 12:27:58 -0500 Message-ID: <20260228173244.1509663-566-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Janne Grunau [ Upstream commit 3e4e729325131fe6f7473a0673f7d8cdde53f5a0 ] Add the display controller and DPTX phy power-domains to the framebuffer node to keep the framebuffer and display out working after device probing finished. The OS has more control about the display pipeline used for the HDMI output on M2 based devices. The HDMI output is driven by an integrated DisplayPort to HDMI converter (Parade PS190). The DPTX phy is now controlled by the OS and no longer by firmware running on the display co-processor. This allows using the second display controller on the second USB type-c port or tunneling 2 DisplayPort connections over USB4/Thunderbolt. The m1n1 bootloader uses the second display controller to drive the HDMI output. Adjust for this difference compared to the notebooks as well. Fixes: 2d5ce3fbef32 ("arm64: dts: apple: t8112: Initial t8112 (M2) device t= rees") Cc: stable@vger.kernel.org Signed-off-by: Janne Grunau Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-1-cfdce629c0= a8@jannau.net Signed-off-by: Sven Peter Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/apple/t8112-j473.dts | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/arch/arm64/boot/dts/apple/t8112-j473.dts b/arch/arm64/boot/dts= /apple/t8112-j473.dts index 06fe257f08be4..4ae1ce919dafc 100644 --- a/arch/arm64/boot/dts/apple/t8112-j473.dts +++ b/arch/arm64/boot/dts/apple/t8112-j473.dts @@ -21,6 +21,25 @@ aliases { }; }; =20 +/* + * Keep the power-domains used for the HDMI port on. + */ +&framebuffer0 { + power-domains =3D <&ps_dispext_cpu0>, <&ps_dptx_ext_phy>; +}; + +/* + * The M2 Mac mini uses dispext for the HDMI output so it's not necessary = to + * keep disp0 power-domains always-on. + */ +&ps_disp0_sys { + /delete-property/ apple,always-on; +}; + +&ps_disp0_fe { + /delete-property/ apple,always-on; +}; + /* * Force the bus number assignments so that we can declare some of the * on-board devices and properties that are populated by the bootloader --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 654E93EE756; Sat, 28 Feb 2026 17:42:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300527; cv=none; b=NusbWp37UYRdSas85ZPmWehCKc6/ahYP8ziDb1ihNKdX9rLpaJ0nwh3mpNX+7ahSFs5R8PIWOJL3DBFMI0Y5JKOm5+0zFyRhxhbIM1RhymMDOFIT1Sba9mdFPexvqZ+si9wbXmtzUQc2Lr9dxcfKYFChZBo217YHzTgEWcKR0R0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300527; c=relaxed/simple; bh=9sarrJusHP7eAiZ0RwmOWlsWxVMbOU+eohGE96VMNH8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q8r9Tjka6u7lAttdxREXAincMxHuAut0Tc/0FUVjnCkNeoJ/nY0jTz+83tuzE9VZfI0tLrMqoMyS1s8Ew4JVgKY5p5p6Z50OyAAQThqHZvd1rL48EB15/1tiuiKEOsE7ALxUwIPpEC1gq2bpM6csy1gg73kpNBw5eH0Wu/TJZGE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MFURAGnh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MFURAGnh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57CC6C2BC87; Sat, 28 Feb 2026 17:42:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300527; bh=9sarrJusHP7eAiZ0RwmOWlsWxVMbOU+eohGE96VMNH8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MFURAGnh9aFaDgG/n55NH0FXDSRERk6yYviWhUg1x+Qi4gcED3W+fSrT93bSg1p7b XbI8Zf7G1nHEaTIRtAj3vKe49cF6JZQa6z9xAQer2A6SKaD/n5ziQ+QsIu2o+HR/Zp 6RVeWK2W2VDYCZoWjSrfyyAHeEg+Gd9hLaKHvI5yAIzAYFIH4FbVbioC0f8FJa5hTK d8vu5G+bvHwK0vwzS7rHP4GPV+ttBSZ97BabPhP/ikEw/3YCM+FbQdeklSzb0xz5Yf AEmy7TMalipIE3L1Oh7YtNn3c0QXI0rgm4jK5ba3cWiDKH5B0dJNaSPXiK7CH+tVqr Ni8PWMu8Rwghw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Qian , Nicolas Dufresne , Frank Li , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 566/844] media: amphion: Drop min_queued_buffers assignment Date: Sat, 28 Feb 2026 12:27:59 -0500 Message-ID: <20260228173244.1509663-567-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Qian [ Upstream commit 5633ec763a2a18cef6c5ac9250e4f4b8786e7999 ] The min_queued_buffers field controls when start_streaming() is called by the vb2 core (it delays the callback until at least N buffers are queued). Setting it to 1 affects the timing of start_streaming(), which breaks the seek flow in decoder scenarios and causes test failures. The current driver implementation does not rely on this minimum buffer requirement and handles streaming start correctly with the default value of 0, so remove these assignments. Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/amphion/vpu_v4l2.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/platform/amphion/vpu_v4l2.c b/drivers/media/plat= form/amphion/vpu_v4l2.c index 47dff9a35bb46..1fb887b9098c6 100644 --- a/drivers/media/platform/amphion/vpu_v4l2.c +++ b/drivers/media/platform/amphion/vpu_v4l2.c @@ -670,7 +670,6 @@ static int vpu_m2m_queue_init(void *priv, struct vb2_qu= eue *src_vq, struct vb2_q src_vq->mem_ops =3D &vb2_vmalloc_memops; src_vq->drv_priv =3D inst; src_vq->buf_struct_size =3D sizeof(struct vpu_vb2_buffer); - src_vq->min_queued_buffers =3D 1; src_vq->dev =3D inst->vpu->dev; src_vq->lock =3D &inst->lock; ret =3D vb2_queue_init(src_vq); @@ -687,7 +686,6 @@ static int vpu_m2m_queue_init(void *priv, struct vb2_qu= eue *src_vq, struct vb2_q dst_vq->mem_ops =3D &vb2_vmalloc_memops; dst_vq->drv_priv =3D inst; dst_vq->buf_struct_size =3D sizeof(struct vpu_vb2_buffer); - dst_vq->min_queued_buffers =3D 1; dst_vq->dev =3D inst->vpu->dev; dst_vq->lock =3D &inst->lock; ret =3D vb2_queue_init(dst_vq); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 751093EEEC6; Sat, 28 Feb 2026 17:42:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300528; cv=none; b=lZEzWj8902gFQ78dELkmF1i2I6kpKXRl2s/DWT02r4mh00+6ZWpBEIJe/KDomzgtZvPlqzs0nXwW5LxRRt5Xa5AqGSJPA4mXmvuaygha2eHCyy7KNmPPy1mcfY/P9pJ5J0zLS9yK6wQWbsLFWQ/LFBQDJP8W/tIDaVctFlBhv1k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300528; c=relaxed/simple; bh=IQjvhalWpQwPlwqWdn/YiZ8Y6HjnHhqlE+4DYC5gzl8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fteMP3sxh/swzq4a966gd6j4j5yU8uirpGjp6DB1kVplL7ileIJV14XRj8roiqiy1WqPJCpQj+tSvT4SE68L9JGmEivQlrtndoSlD2w5S43hCih6Cyu7ITzzQrhZav/45UI6wSogiLjM1AIUZKa8sv3Gsh+Ah7HtsdAliCy4bu8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZJ1yQrC4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZJ1yQrC4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F1D9C19423; Sat, 28 Feb 2026 17:42:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300528; bh=IQjvhalWpQwPlwqWdn/YiZ8Y6HjnHhqlE+4DYC5gzl8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZJ1yQrC4yuuJV+t8mv9KZwCOdBVNXogPcteMlEJF65TaXQs7phpv27jUMxjpH9IX6 Iq9DsBhkeai0nJ1fQrTXPbcUrIgN4+xkcxh6XSU1b0IYOX3aQ1ot/YYu5K9rVBfTMM yQ3VZ7UV6au9ZWGnsExiYqcS16rDBTcdFk/w5mF/abnJsYgCkAxRqPzH4q5m/n35kv aCWDQAEmRA1mi9siXj5Yj5OvP9Ew7IE1P0Ctdf9N+fwmjXFPLvPpKRMQucTLctsIqZ /bS44QB+sWP3W/JaJPdS3Aq+IXvHy92imT+6EA75ndmuT5Txvd2Q+/SW2sWAROw9ht BUpC5/9zicYIA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alper Ak , Michael Tretter , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 567/844] media: rockchip: rga: Fix possible ERR_PTR dereference in rga_buf_init() Date: Sat, 28 Feb 2026 12:28:00 -0500 Message-ID: <20260228173244.1509663-568-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alper Ak [ Upstream commit 81f8e0e6a2e115df9274d0289779f8fca694479c ] rga_get_frame() can return ERR_PTR(-EINVAL) when buffer type is unsupported or invalid. rga_buf_init() does not check the return value and unconditionally dereferences the pointer when accessing f->size. Add proper ERR_PTR checking and return the error to prevent dereferencing an invalid pointer. Fixes: 6040702ade23 ("media: rockchip: rga: allocate DMA descriptors per bu= ffer") Cc: stable@vger.kernel.org Signed-off-by: Alper Ak Reviewed-by: Michael Tretter Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/rockchip/rga/rga-buf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/rockchip/rga/rga-buf.c b/drivers/media/= platform/rockchip/rga/rga-buf.c index 730bdf98565a5..bb575873f2b24 100644 --- a/drivers/media/platform/rockchip/rga/rga-buf.c +++ b/drivers/media/platform/rockchip/rga/rga-buf.c @@ -80,6 +80,9 @@ static int rga_buf_init(struct vb2_buffer *vb) struct rga_frame *f =3D rga_get_frame(ctx, vb->vb2_queue->type); size_t n_desc =3D 0; =20 + if (IS_ERR(f)) + return PTR_ERR(f); + n_desc =3D DIV_ROUND_UP(f->size, PAGE_SIZE); =20 rbuf->n_desc =3D n_desc; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43E363EEEDD; Sat, 28 Feb 2026 17:42:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300529; cv=none; b=QPTR3ZIdZrQe1MLNLYJVTLVo9wG2wIHQ731BGp47i2ccRGJhNhmdAMGLHmSKRG+1Yvq/hYwtCl/DDhRVt2VimzeBkOgoCPGhMJeJOc8cqZ7qjhyH4auDUExnhxzy5TJBwXx0jn8sGZwdKy79EU8clscaufRxcAHKWU51bLFKTh0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300529; c=relaxed/simple; bh=IS53KTBMWo9ydqeW1BFesdWD63Lb5PcC6ZpjJOHuW68=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NukdcDSJTnWYX3jCxXmg35TMm6HkWkV08rsOgV7qy3y5mCx84/LAMBz5G0E9tyYDPue5buVlSLVlGSbKLNmS/nNCbdimK5HnyGtjq1eXecSXSm+ZxV9aU1id217XwDpZTc+gJRYTdYdnMqJQY7KskLnN9DW9vcnTqaJnacKtAE8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RUl2hEgb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RUl2hEgb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65B5AC19424; Sat, 28 Feb 2026 17:42:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300529; bh=IS53KTBMWo9ydqeW1BFesdWD63Lb5PcC6ZpjJOHuW68=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RUl2hEgbI0ToHdwfx59xVuZZ7w57Pm3MDFQmWK6QeulnhQ0DYaZzt5fZtsNupWQDk /5Mrq9rY91BXR2rSkAr0wvtD/VEpyvbfCcJHOK78JQJa6no0ywa2Pcg5pVx9ZmcuIB V9DTIg0Rbo7tp3ICJpBWRJP9qtmIqaCKVLj6WzzBieg8A+FUOuI77vIiU6FSQouar5 n5QvcBbtGzcAj1P3N8AOKTfxd8+roU6nflsxVDoeY8F69Q0+rGAtBvYubV9UDpMxOX JVzEJiI4koC8yAnlUC8uGKqUXic40h0AQjKBxzhsVZihK4jubHQk2P6+TB1QNFtvEe ir+VelTqBuF2A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Gaignard , Jianfeng Liu , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 568/844] media: verisilicon: AV1: Set IDR flag for intra_only frame type Date: Sat, 28 Feb 2026 12:28:01 -0500 Message-ID: <20260228173244.1509663-569-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Gaignard [ Upstream commit 1c1b79f40ee4444fa1ac96079751608b724c6b2b ] Intra_only frame could be considered as a key frame so Instantaneous Decoding Refresh (IDR) flag must be set of the both case and not only for key frames. Signed-off-by: Benjamin Gaignard Reported-by: Jianfeng Liu Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.= c b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c index f52b8208e6b93..500e94bcb0293 100644 --- a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c +++ b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c @@ -2018,7 +2018,7 @@ static void rockchip_vpu981_av1_dec_set_parameters(st= ruct hantro_ctx *ctx) !!(ctrls->frame->quantization.flags & V4L2_AV1_QUANTIZATION_FLAG_DELTA_Q_PRESENT)); =20 - hantro_reg_write(vpu, &av1_idr_pic_e, !ctrls->frame->frame_type); + hantro_reg_write(vpu, &av1_idr_pic_e, IS_INTRA(ctrls->frame->frame_type)); hantro_reg_write(vpu, &av1_quant_base_qindex, ctrls->frame->quantization.= base_q_idx); hantro_reg_write(vpu, &av1_bit_depth_y_minus8, ctx->bit_depth - 8); hantro_reg_write(vpu, &av1_bit_depth_c_minus8, ctx->bit_depth - 8); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 224063EEEFA; Sat, 28 Feb 2026 17:42:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300530; cv=none; b=GKGgG7tdkkDAarh1fO03bhT8x/ue0w4uFO1NWDqpC1VYLo5bD3cBEi5O+UUJdcCPovcHwDvA1u1DcsDgf95fUzEDO7IS0jCFHXNXRDRa4EmFw+B7JOvYPP7Wh8iaudBGaF1cL7i25Ej4MdaREnDTb6JXhJ+fTMYS657N0Z8CKho= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300530; c=relaxed/simple; bh=jTSiQC9oqbGfXKaSWS6H02vRGlzbFECj8Q/rj0mZThc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jihl4hkS3+uyH1TTMla6wNLwf5zg4FOQSaO5+2lnRy3i4xXITTMPfv3RHt5oCpnoyyISMf9fKatx4YRLvcrWz0Q6VRCDe878aXQAC8mZgzVwK6u4tp9wAWpyd8itAKc+GoP9wxAyS2IsJ+pAaikndilu0As6V+pUZ4lenDUWg1g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kJ/zi3C8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kJ/zi3C8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C18CC116D0; Sat, 28 Feb 2026 17:42:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300530; bh=jTSiQC9oqbGfXKaSWS6H02vRGlzbFECj8Q/rj0mZThc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kJ/zi3C809uCdo8mxVIsGZGrQETXlWscnE3fyEMPG5IGLyM84FZagk/YZlYXh7bEE 7sHimypY3leO1hv8BjnmPSKn57kkkDPqG2Pf96tp6mHUwwYQ0aZC6HguduA8IuQznp vlzzNzsTf7gBEIY5BAADe/lFUF7FZ9xep/7wBe5wLgDBABBFNZREVzplCBAa8NdvJK PpdZDz4oeRS4a+dcr5i+V1BGQaGRNf7HZlIDvpq+2gQSu+HrP4mMFd+nzJaY2WQRuy 0yjjCkYsR8BMdHz3OFABxjqs0v5WcQAw9r+xXhFpZ3ZlDT0KUcJWEL+OfnSq7GY9i/ mdHVQwDIZv2mQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zilin Guan , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 569/844] media: tegra-video: Fix memory leak in __tegra_channel_try_format() Date: Sat, 28 Feb 2026 12:28:02 -0500 Message-ID: <20260228173244.1509663-570-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zilin Guan [ Upstream commit 43e5302d22334f1183dec3e0d5d8007eefe2817c ] The state object allocated by __v4l2_subdev_state_alloc() must be freed with __v4l2_subdev_state_free() when it is no longer needed. In __tegra_channel_try_format(), two error paths return directly after v4l2_subdev_call() fails, without freeing the allocated 'sd_state' object. This violates the requirement and causes a memory leak. Fix this by introducing a cleanup label and using goto statements in the error paths to ensure that __v4l2_subdev_state_free() is always called before the function returns. Fixes: 56f64b82356b7 ("media: tegra-video: Use zero crop settings if subdev= has no get_selection") Fixes: 1ebaeb09830f3 ("media: tegra-video: Add support for external sensor = capture") Cc: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/staging/media/tegra-video/vi.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/staging/media/tegra-video/vi.c b/drivers/staging/media= /tegra-video/vi.c index c9276ff76157f..14b327afe045e 100644 --- a/drivers/staging/media/tegra-video/vi.c +++ b/drivers/staging/media/tegra-video/vi.c @@ -438,7 +438,7 @@ static int __tegra_channel_try_format(struct tegra_vi_c= hannel *chan, .target =3D V4L2_SEL_TGT_CROP_BOUNDS, }; struct v4l2_rect *try_crop; - int ret; + int ret =3D 0; =20 subdev =3D tegra_channel_get_remote_source_subdev(chan); if (!subdev) @@ -482,8 +482,10 @@ static int __tegra_channel_try_format(struct tegra_vi_= channel *chan, } else { ret =3D v4l2_subdev_call(subdev, pad, get_selection, NULL, &sdsel); - if (ret) - return -EINVAL; + if (ret) { + ret =3D -EINVAL; + goto out_free; + } =20 try_crop->width =3D sdsel.r.width; try_crop->height =3D sdsel.r.height; @@ -495,14 +497,15 @@ static int __tegra_channel_try_format(struct tegra_vi= _channel *chan, =20 ret =3D v4l2_subdev_call(subdev, pad, set_fmt, sd_state, &fmt); if (ret < 0) - return ret; + goto out_free; =20 v4l2_fill_pix_format(pix, &fmt.format); chan->vi->ops->vi_fmt_align(pix, fmtinfo->bpp); =20 +out_free: __v4l2_subdev_state_free(sd_state); =20 - return 0; + return ret; } =20 static int tegra_channel_try_format(struct file *file, void *fh, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 50CFF3EFAD2; Sat, 28 Feb 2026 17:42:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300531; cv=none; b=IQCooHOzBACOBy6kz83FUeSMlnX0AybIUqry6XvbqSlCPwf9qdTv+K0wE7P+YUuA3QbGcckZFegnIdqb+NpI6694eroiVjwMQk6ABVsBJ1En/HbLo/H4d+SG3ZWP+MjRY5sOWTLL/uanvDZMdLzYb5XN/qN4lwXHIqyoiJENCjY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300531; c=relaxed/simple; bh=9FODK//6TYtej7KC85PiWDTKQdHlQO51usadGvKRXD4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jHlO+F/EyD+h5rKIsx7dCWwKoLxxPVlo+lquOVvnkH22gulC8mJJeUpEOKWfwmqnPWx3Dcc+5EiA63KO+EYieiF3AB6wWXSTkFFKGBglF3s7Hfkg5EL8/m0h+Jg54VZyQubzu7J+Q9bnowjaNCkUTwPtolZFeQZKCiWwDGOdk4U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z6IOeRno; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z6IOeRno" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48EE0C19423; Sat, 28 Feb 2026 17:42:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300531; bh=9FODK//6TYtej7KC85PiWDTKQdHlQO51usadGvKRXD4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z6IOeRno3tYChLmd3b4AWPHrpwltk7xaYixctgS0jV+OFSFvSNnnP38IV01KeFAf5 z526nw2ZFUsUwpySeLsnn+yKpe9dD2uN3SW46LUEn00jiXszGK7iTby+grGkc7UhOa CmR4wBFFtUvmuWvZqXsK5qef7uDW9MwuX9XK3CVGdW4ttFyc8ffQr5IaLs/wpcfJyq MB6o6UYfpaOuJ6QfPP6rZpmxAymJ9DIawOLDnKVEKGtBhy80TDdxk/nzPIxdRCnu49 La7m2mspBDhkyfMxZyrMZ69eEM46hXNt7t9pa8QAkIIg9be93DdAtKS+9Hk8wKNcvM RwM7LQdtHmc0g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shaurya Rane , syzbot+a41b73dce23962a74c72@syzkaller.appspotmail.com, Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 570/844] media: radio-keene: fix memory leak in error path Date: Sat, 28 Feb 2026 12:28:03 -0500 Message-ID: <20260228173244.1509663-571-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shaurya Rane [ Upstream commit b8bf939d77c0cd01118e953bbf554e0fa15e9006 ] Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized. Reported-by: syzbot+a41b73dce23962a74c72@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Da41b73dce23962a74c72 Fixes: 1bf20c3a0c61 ("[media] radio-keene: add a driver for the Keene FM Tr= ansmitter") Cc: stable@vger.kernel.org Signed-off-by: Shaurya Rane Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/radio/radio-keene.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/radio/radio-keene.c b/drivers/media/radio/radio-= keene.c index f3b57f0cb1ec4..c133305fd0194 100644 --- a/drivers/media/radio/radio-keene.c +++ b/drivers/media/radio/radio-keene.c @@ -338,7 +338,6 @@ static int usb_keene_probe(struct usb_interface *intf, if (hdl->error) { retval =3D hdl->error; =20 - v4l2_ctrl_handler_free(hdl); goto err_v4l2; } retval =3D v4l2_device_register(&intf->dev, &radio->v4l2_dev); @@ -384,6 +383,7 @@ static int usb_keene_probe(struct usb_interface *intf, err_vdev: v4l2_device_unregister(&radio->v4l2_dev); err_v4l2: + v4l2_ctrl_handler_free(&radio->hdl); kfree(radio->buffer); kfree(radio); err: --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E07B63EFAE6; Sat, 28 Feb 2026 17:42:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300532; cv=none; b=hpFvgGgtZTaMs4hrjstsF0P/5VPbkrEUhXsnsSzfK67eeg9zokB6uag98V6nAKQBCXkqgM1iBWOPWg+gnuSSO1U/IdfB8/GFd+WWodsOlrkZyLZ5YkTF6WjRyXwxRlX21ZuT/tQLOIZ57wEYqAmhU2tBElrjslnY4abOz4lSDBY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300532; c=relaxed/simple; bh=/4+hOPyePWoc2cQ7a3fOGo9JpaAr/zRNdwQUmgjfWPg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=i58OciNUDV2G8iz/TL96HXkh1lfK1iXWtjAVpLB6tMHJyZbUH1HpQ/26D2U3QeJOhyi1YJA70SHGg7NYpSocWdLxDY/wY2Codh1jyizrZNsshVqciercYx74pSq7wFz8QwCJTtDu0QYL3uOBL+bMK1iuKCO166ndYLeEHSZYeFg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OMMiBrfO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OMMiBrfO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36F07C19424; Sat, 28 Feb 2026 17:42:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300531; bh=/4+hOPyePWoc2cQ7a3fOGo9JpaAr/zRNdwQUmgjfWPg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OMMiBrfOs72CVPScdT8F5ZCaFNvLF9Q72ceaPT0Y8MBGCrPa/cIyHkO6OLbz3AFBW 9EkHXZS0MyMrkLYhEGaZ0RSqr7L+ojYhhPTRFFgTtLuq4MXcmq8TBsG1orkI5+13Su 3E9psntXfhax1YwreEQHG3vTrTKB7W2FpVxxQmwA0f36xIZVd81pyaUokwO5YE+ntt 3F5WVHyMpWnBRU8tIQg8gKtasiyvHuVEUkOV2UEkL111nML46CFPVZ1vcSGo4b65WC jHm4Fae8FhTLsPJ8HNVo5BaQIesAKO42jdQWUEN/Qm6+Tf+dwf+Q1nZTQyg/XbjI6R gzPMoIt4uPP8g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 571/844] media: cx88: Add missing unmap in snd_cx88_hw_params() Date: Sat, 28 Feb 2026 12:28:04 -0500 Message-ID: <20260228173244.1509663-572-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit dbc527d980f7ba8559de38f8c1e4158c71a78915 ] In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map(). Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/cx88/cx88-alsa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/cx88/cx88-alsa.c b/drivers/media/pci/cx88/cx= 88-alsa.c index 29fb1311e4434..4e574d8390b4d 100644 --- a/drivers/media/pci/cx88/cx88-alsa.c +++ b/drivers/media/pci/cx88/cx88-alsa.c @@ -483,8 +483,10 @@ static int snd_cx88_hw_params(struct snd_pcm_substream= *substream, =20 ret =3D cx88_risc_databuffer(chip->pci, &buf->risc, buf->sglist, chip->period_size, chip->num_periods, 1); - if (ret < 0) + if (ret < 0) { + cx88_alsa_dma_unmap(chip); goto error; + } =20 /* Loop back to start of program */ buf->risc.jmp[0] =3D cpu_to_le32(RISC_JUMP | RISC_IRQ1 | RISC_CNT_INC); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA33D3EEEC6; Sat, 28 Feb 2026 17:42:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300532; cv=none; b=bP+WBfWUtzJt0dH3qlS/uTctrnEOlD0tqgBZBOt/jjOuik49FJt/NqhZH7h3BcCDEzjnLi+YqFDEocPFw7N7j9rNatxyv0Swvi661tL+460E7CTjmMgXaqOAjFR+55Wsm2Vqa3WHk1Vhgmz6dMUdlnkdGAHKOVE9zau8Fxr+Lng= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300532; c=relaxed/simple; bh=dsRGnfj4WmFvhxIQVRCBtspoV4yLgLut1kN03RfXVo0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K/vKtQMIT0osluTg+UCO6C2qljARfri9zrNHELcWFVcIOD+oz69FXTyyFH+Jd5Kq5kdaiDKqDflCxPR38Xps9+vPIdCORnPdQBeKFgZGnbyZwBVwEL3elBq/C0mONpfiiNpTG3HW0QPCDnInHJqb764C8kWHtIJ4n0uCyoDH/lk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ntqXrEwL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ntqXrEwL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 107D3C19425; Sat, 28 Feb 2026 17:42:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300532; bh=dsRGnfj4WmFvhxIQVRCBtspoV4yLgLut1kN03RfXVo0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ntqXrEwLjirl4OfI1kjiFBjyBQYMP2VR9IbAgIVUzZpccGbJBBDoVJu0REmhGxNyv V24uElV4zA8gy93Ml4hMIBsB5Hu/wv75tuS6KJYO5H1N5oPcYIc8NKl9c45AzZ+DBm +Gppr4v3W2Py42T3lNj7spk/2xYV5w/GOfWAm1VUfRC7Vc5hTpQZGlJ/JGv0F/soek LJwW3L7j+zYkIybxkrYu2dOEaeUM94jX7NhgVfN9WGyJLqq49pPpo7sF0R4bDHXxgq 1vSRsTUxXv+X57cu/sjbVBQqRnoAhRxuyOWyZEyMjhkkXu6NQEELx5Gf7IoZ8aV7S1 dJu7M85ZjuSvg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 572/844] media: cx23885: Add missing unmap in snd_cx23885_hw_params() Date: Sat, 28 Feb 2026 12:28:05 -0500 Message-ID: <20260228173244.1509663-573-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit 141c81849fab2ad4d6e3fdaff7cbaa873e8b5eb2 ] In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map(). Fixes: 9529a4b0cf49 ("[media] cx23885: drop videobuf abuse in cx23885-alsa") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/cx23885/cx23885-alsa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/cx23885/cx23885-alsa.c b/drivers/media/pci/c= x23885/cx23885-alsa.c index 25dc8d4dc5b73..717fc6c9ef21f 100644 --- a/drivers/media/pci/cx23885/cx23885-alsa.c +++ b/drivers/media/pci/cx23885/cx23885-alsa.c @@ -392,8 +392,10 @@ static int snd_cx23885_hw_params(struct snd_pcm_substr= eam *substream, =20 ret =3D cx23885_risc_databuffer(chip->pci, &buf->risc, buf->sglist, chip->period_size, chip->num_periods, 1); - if (ret < 0) + if (ret < 0) { + cx23885_alsa_dma_unmap(chip); goto error; + } =20 /* Loop back to start of program */ buf->risc.jmp[0] =3D cpu_to_le32(RISC_JUMP|RISC_IRQ1|RISC_CNT_INC); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9454E35F16F; Sat, 28 Feb 2026 17:42:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300533; cv=none; b=CiZswSV3tYO8drkJwme6dv9NECNcUncHAb44j9OZ0y/ld482ReQeXJog8cYOHFYwvqT3rXFTU92opWz1b0nJO+rsbedoO8pRpWPwVClqULIwZhCesVq5OiLG5/j4iq0uNhrYDZwgAgRmv1+2Jj1KC3ft1VIqbHJM3Hm0P/UR+Qs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300533; c=relaxed/simple; bh=WVArMy5lotm7UNiAO5vjByf5lyQ+wjhKYbVg3xx3mUw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uMlGu67hIQUEsdWXnhLS7UbjdMWCvQSbrjsFXrZLA1AYvfEV0tcQM6R5s2RO/+0Oc5DKyrhE38Nr+xlnn721mHsjeq/j+1gvYAy2GOoIVc1c3W45H28f9yb1DnHtNhvw02jjGCjmT+D0wz9dj/ozk8JdC52O7qT6LD7N/LUr1LE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MR0jolHL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MR0jolHL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF1B5C116D0; Sat, 28 Feb 2026 17:42:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300533; bh=WVArMy5lotm7UNiAO5vjByf5lyQ+wjhKYbVg3xx3mUw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MR0jolHLDnTN0G021tHhEWZ2UJ23IMWOwSvuaNGSJE2upISNAe325ORJG91uZeZa+ gcYSHl/mJi/Gn0r+FYLcNjtQs7v74M2WSlmXUexnNRU9t9z3zgMJST3ho36d+Z7/J4 K2bBFk0Noi09pVcJJTanmKEL3kwXvo6+GclAUDMmpg1fgRqUwAUSwUAhOdHhUhqyBR lKWP3zURGMjzHwhKNrmId4a+YC3c3Sz1hD94QTlVXMDFFnA+xs4eEy1eMn9C9CPndd XAdNL5iFPVV9PRwuB54WSYYBHH4PFXrqQZsEB3HiPbb9aFpYl3irDHxnWS9iDRzdTN Yw++tZ+kczS6A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 573/844] media: cx25821: Add missing unmap in snd_cx25821_hw_params() Date: Sat, 28 Feb 2026 12:28:06 -0500 Message-ID: <20260228173244.1509663-574-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit 863f50d583445c3c8b28a0fc4bb9c18fd9656f41 ] In error path, add cx25821_alsa_dma_unmap() to release the resource acquired by cx25821_alsa_dma_map() Fixes: 8d8e6d6005de ("[media] cx28521: drop videobuf abuse in cx25821-alsa") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/cx25821/cx25821-alsa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/cx25821/cx25821-alsa.c b/drivers/media/pci/c= x25821/cx25821-alsa.c index a42f0c03a7ca8..f463365163b7e 100644 --- a/drivers/media/pci/cx25821/cx25821-alsa.c +++ b/drivers/media/pci/cx25821/cx25821-alsa.c @@ -535,6 +535,7 @@ static int snd_cx25821_hw_params(struct snd_pcm_substre= am *substream, chip->period_size, chip->num_periods, 1); if (ret < 0) { pr_info("DEBUG: ERROR after cx25821_risc_databuffer_audio()\n"); + cx25821_alsa_dma_unmap(chip); goto error; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C52035F18F; Sat, 28 Feb 2026 17:42:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300534; cv=none; b=J4MbtzpMnMFGEY2DTUiyWpEiDDkPHrTcDJYHfJiAEb3KWt3x8oUfXg0t3tIQoFjIr0TypLE6ZJEMtpT4mGZz3cJX+TAWUXaDrIMNsmMujvCQhHJ14bRTXa+TISjBL+lPjyvyYpVVhwwFoDbGnz4ZxlD5NczzwPt+KapR49PeqD4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300534; c=relaxed/simple; bh=7ZjK1K5DPPtbZAf9IBn6TSSixWGIqv2i6ZRB9f1FDns=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Im8BZnzT0g2+1NTG6jYCbXDCpszzzqMNn6iRzOB9wzunpXAmtoZQNIRoUyiFGx1hwf+mMOPoPJ2aqT08CQ8hIKoRZQXR+qd5VZA9FJ4CYrNW5zibd7pESz3+IJFQ6lEZd2/C1Xcx4Ev0t67SzmqQZkS1z7ZNKAbrCyecVWHfZek= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LgYhxdXZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LgYhxdXZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B759FC19424; Sat, 28 Feb 2026 17:42:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300534; bh=7ZjK1K5DPPtbZAf9IBn6TSSixWGIqv2i6ZRB9f1FDns=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LgYhxdXZBHOJU1jxvq4LtJKqXYVn+Edhcaup7qWGcjlctpTHScNhBrQjaH3acOaxg gAk1RunbPSg7GKDdctcrEgCsukqRIAS5C8yqLTZbDAKFh4LKiGZU0MGrO2uyu5Y1xv hrwbJ7OtWR0CUX5TPD0mC30tTyBkThmcSzBIcxOXYcJbt4aHbjlXDjsaBkZViJIQWC NGEhksX1GRXMpUX46/64VWArJFKhqwZ8fWaWarTqb/w1Td4DVyM6bSwdO+dNjp3nE6 LH82ma51xhl3LLxQkSHLj+2kP2j1Tjt8eG16F9JHFVvQVxMqTaHaSb9UB6YayZGqdA CadUg6BnwkHBw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Abdun Nihaal , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 574/844] media: i2c/tw9903: Fix potential memory leak in tw9903_probe() Date: Sat, 28 Feb 2026 12:28:07 -0500 Message-ID: <20260228173244.1509663-575-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Abdun Nihaal [ Upstream commit 9cea16fea47e5553f51d10957677ff735b1eff03 ] In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: stable@vger.kernel.org Fixes: 0890ec19c65d ("[media] tw9903: add new tw9903 video decoder") Signed-off-by: Abdun Nihaal Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/tw9903.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/tw9903.c b/drivers/media/i2c/tw9903.c index b996a05e56f28..c3eafd5d5dc82 100644 --- a/drivers/media/i2c/tw9903.c +++ b/drivers/media/i2c/tw9903.c @@ -228,6 +228,7 @@ static int tw9903_probe(struct i2c_client *client) =20 if (write_regs(sd, initial_registers) < 0) { v4l2_err(client, "error initializing TW9903\n"); + v4l2_ctrl_handler_free(hdl); return -EINVAL; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 481D448AE15; Sat, 28 Feb 2026 17:42:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300535; cv=none; b=AaLOZuS6+hsVEbgs8bG2Vp4ClCMU4GZhZpd6Y5ty41+NS3X7/2Qro2alN0TdAe7qr32xocWKByHOnCIJv+vDU3sK2nw/jWw6rY7q81SLEtiupFoGt1kc7CMvRvw3JOL8iZr5tcuAZPGI9DM9T7IeHJDZiNmDC773mnlQac5vS1k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300535; c=relaxed/simple; bh=X1qt2O3SpR6BNG/h6kwNGVHFl+CAHWvhjIa/OrInxyQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QgLxJZW2dQvEJvNhB/omHrmlwNNwlcIZTu73u+Hy0OuhmkDqMQlGfAS/mjfw3pyCH0PSgv3yOUGilm+O6oeH2gqYTPo6WYEK68KNeVd9SfWg6cCarv5NxxXNQx6svCOVqyklyqKYNPsz4JShYkjke0zB+DIroI47+RSwHuCqqa8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OVUd7xH+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OVUd7xH+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93F83C116D0; Sat, 28 Feb 2026 17:42:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300535; bh=X1qt2O3SpR6BNG/h6kwNGVHFl+CAHWvhjIa/OrInxyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OVUd7xH+Q1wjz6UCsaIIsARwST3J64lNBzfA4x9zA5n1NuorkmhAml06+EWIhYfKu IIZrYjJ8GyEXSUR8WDl7vosQKfeAFo9xqBj0kT7f9lhl2bPSxTPeLn2wtOL8Zem6eU 0kTjKNSWMjOfe1uParNof4AzJKiUb935+zquPWcRlrW79A8rmCda6o5JVuopNd5yy2 xu8G+mslK2M0/thJ7GHeOjQkWk9bn1GOVz6qd8olSoxGG/FIFFZzKdlrSZMEPfqQxy R1CnSj49ybYkgu6EIFVVnhKnMc4Z8qy/NDeCA3jM1eJuPbRmwK/nPviGT1uWVu+boa ntFj2cOrT09Eg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Abdun Nihaal , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 575/844] media: i2c/tw9906: Fix potential memory leak in tw9906_probe() Date: Sat, 28 Feb 2026 12:28:08 -0500 Message-ID: <20260228173244.1509663-576-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Abdun Nihaal [ Upstream commit cad237b6c875fbee5d353a2b289e98d240d17ec8 ] In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: stable@vger.kernel.org Fixes: a000e9a02b58 ("[media] tw9906: add Techwell tw9906 video decoder") Signed-off-by: Abdun Nihaal Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/tw9906.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/tw9906.c b/drivers/media/i2c/tw9906.c index 6220f4fddbabc..0ab43fe42d7f4 100644 --- a/drivers/media/i2c/tw9906.c +++ b/drivers/media/i2c/tw9906.c @@ -196,6 +196,7 @@ static int tw9906_probe(struct i2c_client *client) =20 if (write_regs(sd, initial_registers) < 0) { v4l2_err(client, "error initializing TW9906\n"); + v4l2_ctrl_handler_free(hdl); return -EINVAL; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 52E9C3F12DB; Sat, 28 Feb 2026 17:42:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300536; cv=none; b=s89dG/y6GxBq/ghMP/cC/DFhAap4DDflbhfF5/h5flAowE0NbVde2dopjn+sXpWj3hlesrWcwhFcheATX5KeWuc0smQmIorjbss4IRP5ludBZiMdcKPmqj7Trlw3FT0ObfVxmx9p6kX77qWfSeq8FCw4H4x4sSn9r3a4Pw/BzSE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300536; c=relaxed/simple; bh=IeEKI5M4X0R0nj1w52Z4QhE2K1LzmG7yNEma1ec3+jM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=A3f3cT4c+FCHCCeYm7UyK5Kvi+lsMhpHJ2bPNjn0am8sxouXm0zHT1yChR/sS+NLU5TnqID/ylPpLoWw4VB8EXDWjVQfIDsFRh2FpaUkMW77Ln23Etuq4ZZhXr+B8fIXeY+v8ZLZaiNd5AE96ldKYxO6OdY1cX84thWQaajB8VU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KB9TWycq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KB9TWycq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70425C19424; Sat, 28 Feb 2026 17:42:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300536; bh=IeEKI5M4X0R0nj1w52Z4QhE2K1LzmG7yNEma1ec3+jM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KB9TWycqCaNR2m+9090WGVLscCLRzkl9VdjLZL8mdv1o+F31/voPk+oqrELq/k97S W8zdhV1St8INFXKoUH8OjgYDUkI5s0YOmZWrEBr4vZBXTWv1sRKEf1S9Aetpd2TI8v tIMDlv7uI+tF6Wy6gDBCIuQiqhqmXVrQiZYKDYMM8/Bj5euKOupny8ixGzuXT8icgM tzd1/7KG70i9TbveJNv54L13du3evRLXCBtn4HCK8tdbF4OCzaVn/yLPjCz75LrZd5 up7VqaErFvBhZEdW5PZSMPTR3WQxTdZPzFED228PG0B4UD9YNKBBlISipdE3bNkX5Y CqSh4zmu88vmw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Mehdi Djait , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 576/844] media: i2c: ov01a10: Fix the horizontal flip control Date: Sat, 28 Feb 2026 12:28:09 -0500 Message-ID: <20260228173244.1509663-577-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit ada20c3db0db4f2834d9515f6105111871f04a4d ] During sensor calibration I noticed that with the hflip control set to false/disabled the image was mirrored. So it seems that the horizontal flip control is inverted and needs to be set to 1 to not flip (just like the similar problem recently fixed on the ov08x40 sensor). Invert the hflip control to fix the sensor mirroring by default. As the comment above the newly added OV01A10_MEDIA_BUS_FMT define explains the control being inverted also means that the native Bayer-order of the sensor actually is GBRG not BGGR, but so as to not break userspace the Bayer-order is kept at BGGR. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov01a10.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index 141cb6f75b555..e5df01f979781 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -75,6 +75,15 @@ #define OV01A10_REG_X_WIN 0x3811 #define OV01A10_REG_Y_WIN 0x3813 =20 +/* + * The native ov01a10 bayer-pattern is GBRG, but there was a driver bug en= abling + * hflip/mirroring by default resulting in BGGR. Because of this bug Intel= 's + * proprietary IPU6 userspace stack expects BGGR. So we report BGGR to not= break + * userspace and fix things up by shifting the crop window-x coordinate by= 1 + * when hflip is *disabled*. + */ +#define OV01A10_MEDIA_BUS_FMT MEDIA_BUS_FMT_SBGGR10_1X10 + struct ov01a10_reg { u16 address; u8 val; @@ -185,14 +194,14 @@ static const struct ov01a10_reg sensor_1280x800_setti= ng[] =3D { {0x380e, 0x03}, {0x380f, 0x80}, {0x3810, 0x00}, - {0x3811, 0x08}, + {0x3811, 0x09}, {0x3812, 0x00}, {0x3813, 0x08}, {0x3814, 0x01}, {0x3815, 0x01}, {0x3816, 0x01}, {0x3817, 0x01}, - {0x3820, 0xa0}, + {0x3820, 0xa8}, {0x3822, 0x13}, {0x3832, 0x28}, {0x3833, 0x10}, @@ -411,7 +420,7 @@ static int ov01a10_set_hflip(struct ov01a10 *ov01a10, u= 32 hflip) int ret; u32 val, offset; =20 - offset =3D hflip ? 0x9 : 0x8; + offset =3D hflip ? 0x8 : 0x9; ret =3D ov01a10_write_reg(ov01a10, OV01A10_REG_X_WIN, 1, offset); if (ret) return ret; @@ -420,8 +429,8 @@ static int ov01a10_set_hflip(struct ov01a10 *ov01a10, u= 32 hflip) if (ret) return ret; =20 - val =3D hflip ? val | FIELD_PREP(OV01A10_HFLIP_MASK, 0x1) : - val & ~OV01A10_HFLIP_MASK; + val =3D hflip ? val & ~OV01A10_HFLIP_MASK : + val | FIELD_PREP(OV01A10_HFLIP_MASK, 0x1); =20 return ov01a10_write_reg(ov01a10, OV01A10_REG_FORMAT1, 1, val); } @@ -610,7 +619,7 @@ static void ov01a10_update_pad_format(const struct ov01= a10_mode *mode, { fmt->width =3D mode->width; fmt->height =3D mode->height; - fmt->code =3D MEDIA_BUS_FMT_SBGGR10_1X10; + fmt->code =3D OV01A10_MEDIA_BUS_FMT; fmt->field =3D V4L2_FIELD_NONE; fmt->colorspace =3D V4L2_COLORSPACE_RAW; } @@ -751,7 +760,7 @@ static int ov01a10_enum_mbus_code(struct v4l2_subdev *s= d, if (code->index > 0) return -EINVAL; =20 - code->code =3D MEDIA_BUS_FMT_SBGGR10_1X10; + code->code =3D OV01A10_MEDIA_BUS_FMT; =20 return 0; } @@ -761,7 +770,7 @@ static int ov01a10_enum_frame_size(struct v4l2_subdev *= sd, struct v4l2_subdev_frame_size_enum *fse) { if (fse->index >=3D ARRAY_SIZE(supported_modes) || - fse->code !=3D MEDIA_BUS_FMT_SBGGR10_1X10) + fse->code !=3D OV01A10_MEDIA_BUS_FMT) return -EINVAL; =20 fse->min_width =3D supported_modes[fse->index].width; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D3333F12FE; Sat, 28 Feb 2026 17:42:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300537; cv=none; b=ChTXxgW5FQYx/yNPFotaiBripN9U+NmRyUWpsd99c76P1D/EFjWpbDBRfSGfL7zAArtHRQs7u3A1A/pF6ikBbjMtrF7ngvnmynpTHOvM8wAxNnOHeIwh7Vggo2P16Tw/yNNqQQ35yxfkBKQ3cZhGGs0icyiW9J+9UPj2Ezwm6qk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300537; c=relaxed/simple; bh=K8cH+cxgDcq/8J4Ln1pD0oHJgmCFDSwmvVWXHw6E38U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KQPBZ7NOpb7+TH1YAw1R+bg3LFsRaTQw5LA7UBCyAJ2KyLfV/D/xmGERkoKsalXy0D7KugmQbIuPKwdV7w/qu1hgWirDyyF/Kbhvq7FaL1j28F3Xm23kGHznyFqEODytDoLwLFMsIXaN3N3WdNNKBUYry4RjLnWGfV24pT25sxs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FhbcHRpz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FhbcHRpz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7936FC19423; Sat, 28 Feb 2026 17:42:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300537; bh=K8cH+cxgDcq/8J4Ln1pD0oHJgmCFDSwmvVWXHw6E38U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FhbcHRpzNMv6//MSEJmtvVLmpYRKGtzYpDs39nblPK5h5BY+nS6s5l6xtLMJYcf3x TODjZ8CS28H/bIb8QDxbO+NpLqixS2zvYo0SB8b3oMEtFx6toZw8SBB7GiQkjGh2A7 LcVCCAo7vAWRNEQ6rZvESHsYNITsM5k5fp2Y8YQ4ItdO00hrAVan3HspUx4rsNPNnt SeenP1PBOm0Tvp8LHjwsr1V8xkskmm/k2W0aD2xyL2Km9JQRDGjv3gsfWn7BFcWpCc JuuPbPo3eS3CfOLWsGhpAYfYjkf8X2ehFUNoliz2SC+AmH/aU+yX8QA+1WAqxwetGz 2SzZUwfFrmIAQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Mehdi Djait , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 577/844] media: i2c: ov01a10: Fix reported pixel-rate value Date: Sat, 28 Feb 2026 12:28:10 -0500 Message-ID: <20260228173244.1509663-578-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit 9c632eebf6af4cb7b0f85503fe1ebc5176ff0db1 ] CSI lanes are double-clocked so with a single lane at 400MHZ the resulting pixel-rate for 10-bits pixels is 400 MHz * 2 / 10 =3D 80 MHz, not 40 MHz. This also matches with the observed frame-rate of 60 fps with the default vblank setting: 80000000 / (1488 * 896) =3D 60. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov01a10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index e5df01f979781..0b1a1ecfffd0e 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -16,7 +16,7 @@ #include =20 #define OV01A10_LINK_FREQ_400MHZ 400000000ULL -#define OV01A10_SCLK 40000000LL +#define OV01A10_SCLK 80000000LL #define OV01A10_DATA_LANES 1 =20 #define OV01A10_REG_CHIP_ID 0x300a --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64D7C3F1BBF; Sat, 28 Feb 2026 17:42:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300538; cv=none; b=a637qSEkhdpUiTEO9c889kXwgrUVwR7KYxj2XvEPxsEEUJfs9BtT6Pm6JzQseK28TEx/k6hAzCt7Zfrpk10QDRRzJ3jYWSS33jsdz6UxvhF2Lxj2/vNZczXCq/LPPdFXJgsPVvs+GGkCqciwvtmf7JKcX7ol4etbvEwNVA9Qkt0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300538; c=relaxed/simple; bh=W+gTu0H6JhHAnfGgON93jd0Og1WUEHEzknCmsh4qEWo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Kj8BD5u66+nVl3XXM5VmOXd5uw6hj3/uy3JRTtH/PpQP0lnxRnkCJh0aCKoemWwMENdHH9JBD3YBP4KfmhmnwTIasGQHutopE1cyvS/3vT5h67h5qkgmogdNwo1VhwCr+2TYW1d4jfEV/KfXIBGmremcgEXT6ROW/O0Zpn2y4o4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tWpa6ZS5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tWpa6ZS5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 831E1C2BC9E; Sat, 28 Feb 2026 17:42:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300538; bh=W+gTu0H6JhHAnfGgON93jd0Og1WUEHEzknCmsh4qEWo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tWpa6ZS5Tla6leVtOQUxJnfx3eFPJjO+Zc9uou2l2z3lopdKpddBAF1XW4p5e56+e TMb04hsmVfg9bQCpS1gHUezc58Se0MBzwJvp5CxHgG8tQ/prKjbkkluTC+zTLSN3// ElXT0nnf+EIEX97spEO71ZZTMcgr88K0Js/lt6mRkdBn2FgB6UaimUK5hijXobuTJa PiKYLVGdwR+buqCcfkXSb80cFg9P2Fu/WHxKSu8Flv4dToxTv6hRRWBar4/fjUWXhI hW2fiMHGyYHzXVj+MAZMQp4IsCgFQxThqCplZjEkS+F4C5nDwNDV2JMus7VXm9OSO6 QIlqbLIaH4igw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Mehdi Djait , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 578/844] media: i2c: ov01a10: Fix analogue gain range Date: Sat, 28 Feb 2026 12:28:11 -0500 Message-ID: <20260228173244.1509663-579-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit 109e0feacaeca5ec2dd71d7d17c73232ce5cbddc ] A analogue maximum gain of 0xffff / 65525 seems unlikely and testing indeed shows that the gain control wraps-around at 16383, so set the maximum gain to 0x3fff / 16383. The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results in the same gain values as setting these bits to 0x1, with bits 0-7 still increasing the gain when going from 0x000 - 0x0ff in the exact same range as when going from 0x100 - 0x1ff. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait [Sakari Ailus: mention analogue gain and update the limit from 4096.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov01a10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index 0b1a1ecfffd0e..834ca46acb75f 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -48,7 +48,7 @@ /* analog gain controls */ #define OV01A10_REG_ANALOG_GAIN 0x3508 #define OV01A10_ANAL_GAIN_MIN 0x100 -#define OV01A10_ANAL_GAIN_MAX 0xffff +#define OV01A10_ANAL_GAIN_MAX 0x3fff #define OV01A10_ANAL_GAIN_STEP 1 =20 /* digital gain controls */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 863C63F1BAA; Sat, 28 Feb 2026 17:42:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300539; cv=none; b=O9nl4dw3mqIL+EK3IOQqZoE1s2CTWkuHOzpEHHKrVk2YUCfrCODVnpBRwSdr9FqQ4EUoUMep4odmnV28JUA1q6C8B6XRdOOaxM73q8LQmOE1OOLbsyJ6tPYW/jdZfwcEjNQeghGrTjx8VAY8LWenUzx1I7nD2qXMb2o5FrvpfHI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300539; c=relaxed/simple; bh=9XiW3GpYli+WyXCsoXLNbi7jTatj6HD3MPaVz1E9SBk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cbrvwSbx3STwySp55nMx28h89AggYcgNsRrajDBoSg5m6AMOvL+cqlDlsgSVEWhPDPuSymjPDxB2QukJ+nRXgMwhbrZZop3OyzZVJ2JgFW6DggpKcBnxNr7ttxPqp9CcBzQN1PRHTKZ9aVD0VtotI6Crm9/3BN8bbZQv527OpG4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gECU2FZD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gECU2FZD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C4B8C19423; Sat, 28 Feb 2026 17:42:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300539; bh=9XiW3GpYli+WyXCsoXLNbi7jTatj6HD3MPaVz1E9SBk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gECU2FZDF7glxGL0iED6I5ACOEI2Ti3p1FMTP08eoMDrKx1BFS3U4i3ZbqCe4/yfg vPHxeNQCXxa4aVPnTNqfsSG2WMYmCj8/3lVxx0LjfRmbxo9AGlQhroc909B9docA7D Oq3WxFXZkHqSnTbLpcXOfnY8rucNswWLjZeDjdAUWqQzkyir9GWM0Ex6fO84KDsGwW Ywb6S2sR6u6lbdUQt06KD/tLfCzCx292lz8yTiJmRPdwnMoXet8ntrpgzVJQKFbXXb TWYexZMHtxwu19912upFHh8KLmeowB/eNp1Aw69LCGo+Ro8Gz10RXyiaqz8nfBHFlV bdRwwWqrM5sfQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Mehdi Djait , Bingbu Cao , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 579/844] media: i2c: ov01a10: Add missing v4l2_subdev_cleanup() calls Date: Sat, 28 Feb 2026 12:28:12 -0500 Message-ID: <20260228173244.1509663-580-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit 0dfec6e30c334364145d0acb38bb8c216b9a7a78 ] Add missing v4l2_subdev_cleanup() calls to cleanup after v4l2_subdev_init_finalize(). Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov01a10.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index 834ca46acb75f..1e22df12989ae 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -864,6 +864,7 @@ static void ov01a10_remove(struct i2c_client *client) struct v4l2_subdev *sd =3D i2c_get_clientdata(client); =20 v4l2_async_unregister_subdev(sd); + v4l2_subdev_cleanup(sd); media_entity_cleanup(&sd->entity); v4l2_ctrl_handler_free(sd->ctrl_handler); =20 @@ -934,6 +935,7 @@ static int ov01a10_probe(struct i2c_client *client) err_pm_disable: pm_runtime_disable(dev); pm_runtime_set_suspended(&client->dev); + v4l2_subdev_cleanup(&ov01a10->sd); =20 err_media_entity_cleanup: media_entity_cleanup(&ov01a10->sd.entity); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D5373F26B9; Sat, 28 Feb 2026 17:42:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300540; cv=none; b=pfw3MQ5gGHtFdvDykOadNUx0I3jV7eU/l9maaB2/vRxDdVzv6hvORsHLDSG1eI8j8wjI0jtZLqfPdEgrBCvxDnHFAf5iHhIS1CIeS4+KIWIGOwepkZoa48POYIf+383ANakf/Df4KYEohv09GtHfgVVr93bOy2FxFAVzrt7cx+I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300540; c=relaxed/simple; bh=tfkBBqKStCnHLqu7rxJkkFEuyEAHDngvzTEOd1OAGIw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mMCQYSGsBhVotiyPSMgfbi81/3fhYGC85Q5w9YEzGkaJBWi5TT3JVTh4Hh99AjvumSkzoDSWe7h9xO1oxMPk/mVFkVCAlakVMb+G7HDEGldfzQbbG29nu4GbmTmEsrVF2qyL+19787HLJq/Yokd4x6H6gqgNsIxoJ9Vu5MgAuOM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B9Wizad8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="B9Wizad8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABE7BC2BC87; Sat, 28 Feb 2026 17:42:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300540; bh=tfkBBqKStCnHLqu7rxJkkFEuyEAHDngvzTEOd1OAGIw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B9Wizad884BX7GgjMVJIh35hDW4URUDTTAdTK0/mRkvD1Qa/aerSQIRRKjr/ZGBJ1 ZwZWPCIKVpNoHyIH+kK4+7Dl2KwRwuAfnIOadabHXfbqVYaSxCiIGNxdhCaF1PsMXe jXKYtB7jUzLS06Bkumnu2pSVx0isu1dJEngkCLTnnKk23jHX3EPhOHrUuQZj9Q4FA+ ffi2iGdVqS4Qft2zG0eW4bIWHA86o7C/BOfcFa/LdJBYirOnkTpZEwVS30Y+OSD3gj iFgNrLE0oZd3cvhgafU/H5ZhZg7/AZM27sKRj8uKFGXtYrk8CbbFmSs7pVFht6i+lp WENrq3zV3aKGg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Mehdi Djait , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 580/844] media: i2c: ov01a10: Fix passing stream instead of pad to v4l2_subdev_state_get_format() Date: Sat, 28 Feb 2026 12:28:13 -0500 Message-ID: <20260228173244.1509663-581-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit f8563a375e7fba7c776eb591d4498be592c19098 ] The 2 argument version of v4l2_subdev_state_get_format() takes the pad as second argument, not the stream. Fixes: bc0e8d91feec ("media: v4l: subdev: Switch to stream-aware state func= tions") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov01a10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index 1e22df12989ae..dd2b6d381175a 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -731,7 +731,7 @@ static int ov01a10_set_format(struct v4l2_subdev *sd, h_blank); } =20 - format =3D v4l2_subdev_state_get_format(sd_state, fmt->stream); + format =3D v4l2_subdev_state_get_format(sd_state, fmt->pad); *format =3D fmt->format; =20 return 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 024FB3F26DA; Sat, 28 Feb 2026 17:42:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300542; cv=none; b=ZzbRTFA7+OG8G5KTddKyRjn9kkMRZo+uAAHI5TRpOiCsPaBYyqvxHv1fwPQ48Jg9UkHqPk390mxz2sIWtSDTn0z2o0xwFbabKjtxSohSzX86uLaWXFU/4YxmM6Y0BAX55fNepr12/WiNwlF8vXTW1rOM1UeHf2Ct7TFbXGPGgWs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300542; c=relaxed/simple; bh=ohQ9CucGTQ18a4Fp4lripQpC9sI6uM+kDC8e0VngH0Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hRC1m1Rg6bbAHvGi6lP0rDvx7caSM4Klqriy3OUjn3eNLcrqDdnUZO6uE0VmpN8F/lfl0374wnrp/jbsiPZx1XzittVNE6/Optpio2qphB0lSsjF6rW0aSyZZvh9vVEm7MZ/ASR20upt6CRvbnN5Zm2S8ebxt6LJmVufl43alTE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m8SzK2KF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m8SzK2KF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B48C5C116D0; Sat, 28 Feb 2026 17:42:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300541; bh=ohQ9CucGTQ18a4Fp4lripQpC9sI6uM+kDC8e0VngH0Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m8SzK2KFbHx1pzmA04KHaaG1hWLwel9OX6UeCjIO5E4r9L6s86ftQkKYWRQVBYsdq ggbzs3tE7rES6IIUKeyh78FDjdODznSOULZeKryRNRU474rstqQuA1Jm3XN4F1pXGY 5nNgASmPf0VkcXIKVxEWkkjek9PUGTOg8qLlIrXeilWub4C8KQh57szk+Zx+D64WgR nBdZQ1QsqlMwViiVwtruImEGgkS8/JHNfB8/D+DSKtC3wkfRwBG+R9eSVyjf5PtI6u Wk0D0hsuuKscFWyVfAca3IPJ5erQSv2mbsfK5cPMGHOgE440E0ScpuqDskPWrpLEAS zYWVvEdC3AGgg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Mehdi Djait , Bingbu Cao , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 581/844] media: i2c: ov01a10: Fix test-pattern disabling Date: Sat, 28 Feb 2026 12:28:14 -0500 Message-ID: <20260228173244.1509663-582-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit 409fb57c1b3deada4b8e153eb6344afb3c2dfb9c ] When the test-pattern control gets set to 0 (Disabled) 0 should be written to the test-pattern register, rather then doing nothing. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov01a10.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index dd2b6d381175a..3ad516e4d3698 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -249,9 +249,8 @@ static const struct ov01a10_reg sensor_1280x800_setting= [] =3D { static const char * const ov01a10_test_pattern_menu[] =3D { "Disabled", "Color Bar", - "Top-Bottom Darker Color Bar", - "Right-Left Darker Color Bar", - "Color Bar type 4", + "Left-Right Darker Color Bar", + "Bottom-Top Darker Color Bar", }; =20 static const s64 link_freq_menu_items[] =3D { @@ -406,10 +405,8 @@ static int ov01a10_update_digital_gain(struct ov01a10 = *ov01a10, u32 d_gain) =20 static int ov01a10_test_pattern(struct ov01a10 *ov01a10, u32 pattern) { - if (!pattern) - return 0; - - pattern =3D (pattern - 1) | OV01A10_TEST_PATTERN_ENABLE; + if (pattern) + pattern |=3D OV01A10_TEST_PATTERN_ENABLE; =20 return ov01a10_write_reg(ov01a10, OV01A10_REG_TEST_PATTERN, 1, pattern); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B215F48BD45; Sat, 28 Feb 2026 17:42:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300542; cv=none; b=uP1I4ZQrBDNmXfXV0T2231okAjapcU8p2kL7DkCdZYhotGM6GImp+Qvm99ef0w7Zu8pVN3JNfMzxXVmbS1clgLJiPqJoZpyUYjjphuXwbgWKZ2by8zMvWKAgoaWmyY8vqsaOVMXEG0LDP8zFqZb3yXg6FL/q3KpSM4DlghAQxqY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300542; c=relaxed/simple; bh=hk7Vevhy52GiAlAeBIvAyEeQV9/hNyiHwDwMTJV5wwg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=u/nkVWCC0KzAn57ODeU4K3cSDKc8FJLHPna0OEEpPksxoeKto+ZK5qeCANJw0sKTW76X+Hj8xjIWDYkxQkgIqoYgbmv9d4YEj605p+MKqs6mA6poUCDqrljAhW58kQvErZWNYTn+msBC42/VcUDZsZ40hha7r8YwmJ5uARgaJew= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tZtfb4pn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tZtfb4pn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1604C19424; Sat, 28 Feb 2026 17:42:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300542; bh=hk7Vevhy52GiAlAeBIvAyEeQV9/hNyiHwDwMTJV5wwg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tZtfb4pnX2VqWSomaNrrqNCPWHabGZ0hzKMgdJoYFTQEjGWNHz7kHljwulPP4mS56 qTkcno6L8rJhAoCbizs0OntKJVj3hqmVR5xYoi3r7ATx5WPTApvBJ4CYS9R9AYGHxg tJdjyKndxLEXJVgsCNlEaehfqicjEf69aM7lh5C3nXX0HHjZl6bb2D4/DjayrhQDAS YXwcQZ0s5jedfikwlk2P1/aERuHpcgD9G8+/hdUROQCC1wUyR4UUWYWY8n3hTflGWF ET3KcDa3f9qEFgctPpbai8Y2PQzJFbSAYn2XsyhiQmbBY5afuOM13kLRoZDDgZaPIJ /vDqMPBXHaPNg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alper Ak , Bryan O'Donoghue , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 582/844] media: qcom: camss: vfe: Fix out-of-bounds access in vfe_isr_reg_update() Date: Sat, 28 Feb 2026 12:28:15 -0500 Message-ID: <20260228173244.1509663-583-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alper Ak [ Upstream commit d965919af524e68cb2ab1a685872050ad2ee933d ] vfe_isr() iterates using MSM_VFE_IMAGE_MASTERS_NUM(7) as the loop bound and passes the index to vfe_isr_reg_update(). However, vfe->line[] array is defined with VFE_LINE_NUM_MAX(4): struct vfe_line line[VFE_LINE_NUM_MAX]; When index is 4, 5, 6, the access to vfe->line[line_id] exceeds the array bounds and resulting in out-of-bounds memory access. Fix this by using separate loops for output lines and write masters. Fixes: 4edc8eae715c ("media: camss: Add initial support for VFE hardware ve= rsion Titan 480") Signed-off-by: Alper Ak Cc: stable@vger.kernel.org Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/camss/camss-vfe-480.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/camss/camss-vfe-480.c b/drivers/me= dia/platform/qcom/camss/camss-vfe-480.c index 4feea590a47bc..d73f733fde045 100644 --- a/drivers/media/platform/qcom/camss/camss-vfe-480.c +++ b/drivers/media/platform/qcom/camss/camss-vfe-480.c @@ -202,11 +202,13 @@ static irqreturn_t vfe_isr(int irq, void *dev) writel_relaxed(status, vfe->base + VFE_BUS_IRQ_CLEAR(0)); writel_relaxed(1, vfe->base + VFE_BUS_IRQ_CLEAR_GLOBAL); =20 - /* Loop through all WMs IRQs */ - for (i =3D 0; i < MSM_VFE_IMAGE_MASTERS_NUM; i++) { + for (i =3D 0; i < MAX_VFE_OUTPUT_LINES; i++) { if (status & BUS_IRQ_MASK_0_RDI_RUP(vfe, i)) vfe_isr_reg_update(vfe, i); + } =20 + /* Loop through all WMs IRQs */ + for (i =3D 0; i < MSM_VFE_IMAGE_MASTERS_NUM; i++) { if (status & BUS_IRQ_MASK_0_COMP_DONE(vfe, RDI_COMP_GROUP(i))) vfe_buf_done(vfe, i); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B780D3F3254; Sat, 28 Feb 2026 17:42:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300543; cv=none; b=S1g7WfgCEMsNkSkr++7td3kAH7eTcRNZf1A6YITPhqsJ5HtWqH+kHmoCcbN+cwhZjWzz5kxk5L/iM3pdFa7UGOmDb2BYdvRM3YplB6kxVJm03iDWGIfV19Uy7eCIS5pFRIT+OD6HPWLhYMUjwc4bmtZ0imozlGN03p5qCdAKB70= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300543; c=relaxed/simple; bh=YH7SUM71e+UxP/mZW5mT01cQ4S9baMEJHd3vHF97weI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RmzT4by8dRohRFRJ4b/McdiWbbvAWtFL3reTfq00wrvTFn4h28rKA6+p0M+u9Og+x68YGBnNhxiHf3CIf0ZiiXjf67hkxfDRvV7PTGiON3jR6IyIpGxOq2rjZ+AoV1ZobDmXVFD053GyzSPTOcM6Ywty5q91k2Tj+plvxfpxShA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OHLDIFt8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OHLDIFt8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5B47C19425; Sat, 28 Feb 2026 17:42:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300543; bh=YH7SUM71e+UxP/mZW5mT01cQ4S9baMEJHd3vHF97weI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OHLDIFt8NsvkzkOQ0m8aiwnedYhOPQvMm8zKJC4efSpCtZvJRIgNLRfE1fGDe33ls RsAo0bLOi7Mo47X5VDQiJ44Kxh0+gwb18j12It76o0V7lt48lwRXM1OyNwB9oVYljn uiyklkl1EceG1yRlWYWMqiDyDOXEzHdrdoaAxcFRNtdrR35NlcuvLwKFjbWA/gwK5Q 7xu489l1mvKECRuiFHZC06FO/rXBJC2B9cFACnC99RfQCFBNeerNWG2utqv6RmSaDM iHd/1bsI36UlXwqJrUBoanNkcXCUOKOuuy2fV9gCjPAM63uKFWbdgJYG1nB7XX1xbc 1RawPaXyOTlVw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sakari Ailus , Josh Poimboeuf , Nathan Chancellor , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 583/844] media: ccs: Avoid possible division by zero Date: Sat, 28 Feb 2026 12:28:16 -0500 Message-ID: <20260228173244.1509663-584-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sakari Ailus [ Upstream commit 679f0b7b6a409750a25754c8833e268e5fdde742 ] Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this. Reported-by: Josh Poimboeuf Closes: https://lore.kernel.org/all/ahukd6b3wonye3zgtptvwzvrxldcruazs2exfvl= l6etjhmcxyj@vq3eh6pd375b/ Fixes: ccfc97bdb5ae ("[media] smiapp: Add driver") Cc: stable@vger.kernel.org # for 5.15 and later Signed-off-by: Sakari Ailus Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor # build Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ccs/ccs-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ccs/ccs-core.c b/drivers/media/i2c/ccs/ccs-c= ore.c index 43f7d515bab67..3cacc7d904935 100644 --- a/drivers/media/i2c/ccs/ccs-core.c +++ b/drivers/media/i2c/ccs/ccs-core.c @@ -2346,7 +2346,7 @@ static void ccs_set_compose_scaler(struct v4l2_subdev= *subdev, * CCS_LIM(sensor, SCALER_N_MIN) / sel->r.height; max_m =3D crops[CCS_PAD_SINK]->width * CCS_LIM(sensor, SCALER_N_MIN) - / CCS_LIM(sensor, MIN_X_OUTPUT_SIZE); + / (CCS_LIM(sensor, MIN_X_OUTPUT_SIZE) ?: 1); =20 a =3D clamp(a, CCS_LIM(sensor, SCALER_M_MIN), CCS_LIM(sensor, SCALER_M_MAX)); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCBCF3F3272; Sat, 28 Feb 2026 17:42:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300544; cv=none; b=EDiKV9qL7m/Z+JkoHd4jf/V08zjZhu/88Jeqna40ubww7BisvFvlYmY2r03rGuPcsahWz/upb8utdhXhjdNrI+W6J1Hg6WggaE64Ee4POznsblTJOI//ZDB++aonqAQOsNikWkTMR+OBRtPIcl/z77J1Syzc3YSJNKEP9zDC3Xo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300544; c=relaxed/simple; bh=MoI6jtW1+tHn1I40ybjJ8CI+qmV3MhZTCStQS/hEr/E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IT5E69ETvJrZVCe02EwYCkuJjet3pFltB+UZc2wkzDPRvDNFzPsJV2o0iymOsj77EnWqXtZnUbzgRsx1oq5LwKx8pxNF32clOFhKLUBZSHF7xtR3m9H9qNc+mIjHJnY5abDUbqni9IfcSEr3Y+wFFlsOgWV6NNLlzg352GCH+Pg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ofBhoYwt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ofBhoYwt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCAB0C116D0; Sat, 28 Feb 2026 17:42:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300544; bh=MoI6jtW1+tHn1I40ybjJ8CI+qmV3MhZTCStQS/hEr/E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ofBhoYwtPWWARYFiw9AtgUbhSh2ind272HvbzR/5wwoKkCSfipndWgllz2nv22B+V mrF9/W69LH6hSPtKNgKLm6cMfF4ovT5R89s904kmo2uEDGdxdJDug3l0zC12voQirH w8R3aNeb+JfuxFnBLbMYAPuM+TuRbwDTy3nevEQNojRMucAZf9fEV97P39x3HP7YLY ZstjMwESpRSLEkLiUlcrQw7biN/nwtVMUbNuQcWheZaqmSw9TxuwsbGIwKwonNzD68 mJWvLJGf21iQEhywMcYtzlVf8bwl/oxDP4EVYB1Q0/famp1K+RwEa6SwVUrywZ2qg2 Ie1F61PHtwfHw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jai Luthra , Jacopo Mondi , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 584/844] media: i2c: ov5647: Initialize subdev before controls Date: Sat, 28 Feb 2026 12:28:17 -0500 Message-ID: <20260228173244.1509663-585-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jai Luthra [ Upstream commit eee13cbccacb6d0a3120c126b8544030905b069d ] In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order. Fixes: 4974c2f19fd8 ("media: ov5647: Support gain, exposure and AWB control= s") Cc: stable@vger.kernel.org Suggested-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov5647.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c index e193fef4fcedf..f9fac858dc7ba 100644 --- a/drivers/media/i2c/ov5647.c +++ b/drivers/media/i2c/ov5647.c @@ -1420,15 +1420,15 @@ static int ov5647_probe(struct i2c_client *client) =20 sensor->mode =3D OV5647_DEFAULT_MODE; =20 - ret =3D ov5647_init_controls(sensor); - if (ret) - goto mutex_destroy; - sd =3D &sensor->sd; v4l2_i2c_subdev_init(sd, client, &ov5647_subdev_ops); sd->internal_ops =3D &ov5647_subdev_internal_ops; sd->flags |=3D V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS; =20 + ret =3D ov5647_init_controls(sensor); + if (ret) + goto mutex_destroy; + sensor->pad.flags =3D MEDIA_PAD_FL_SOURCE; sd->entity.function =3D MEDIA_ENT_F_CAM_SENSOR; ret =3D media_entity_pads_init(&sd->entity, 1, &sensor->pad); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E49103F3A4C; Sat, 28 Feb 2026 17:42:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300546; cv=none; b=T3WpqnfJ289PlhBSF/RDWRCr0i6vE8YcqYyaCuQqVLMtidJtJ361DBKWblsXYyj1cnhGqiLMFGEQWtzgUb5c2Kntw9zA1yFCCEAB3iZjaAVCmC6bc4yrCn9aQ2adUYZLjxQt2W7gPWFhBDip53nDdagiFFT9vXfFbUBC678cGKk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300546; c=relaxed/simple; bh=0QaQnWkvIXvBE9XpsdBu7sO72Xv5kEXcQG12BIWTGsI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DDCiB8gS58ncQ4yQp/B2rMxI/9twGUBpKVkUXILqYG46FxGqXFfSc7Uc+ocxuv4ulzNCRPAUTd18cSiUhknRn0b8ZGdCA+upwLJJgK4sZPEUEeu3ol3c4Ww+rB5/demNLHURKHsvvAyisd1X38debVfMs5ag8uFnEv2clVm53Co= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jbV4k0Sr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jbV4k0Sr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E767FC19423; Sat, 28 Feb 2026 17:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300545; bh=0QaQnWkvIXvBE9XpsdBu7sO72Xv5kEXcQG12BIWTGsI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jbV4k0SrQSsa2/FRZbO1h84t/3KIKSHaatEI271vU16luLdW/S6Z41A/G3wJEbVbQ F7NGHvw1W3pixXhao5lLhx5LCxR+ZswnmFgk1cOtddhCxX1ZAfKZzE/hUwIUWfZAGh Q0iyKnjXbXvyAERvnABYL8F1thst8wjq63fe6JWxJuPo14lSP6r+jQrvugB5qEzCgJ Xje5M0OnrOFr3rh/I0tCx67zy/oks5Li5RUvBC6fZZhha6aPBVEqR5OcgLiBvYcBwy Mw/SIILUzDOjH5FX9uhPIdqgoZplx+ht9DblbuYrgy2sPBB2O078Xo+s+5HAOfDgtJ mQGGYfUZfcZgQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Plowman , Jacopo Mondi , Jai Luthra , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 585/844] media: i2c: ov5647: Correct pixel array offset Date: Sat, 28 Feb 2026 12:28:18 -0500 Message-ID: <20260228173244.1509663-586-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Plowman [ Upstream commit a4e62e597f21bb37db0ad13aca486094e9188167 ] The top offset in the pixel array is actually 6 (see page 3-1 of the OV5647 data sheet). Fixes: 14f70a3232aa ("media: ov5647: Add support for get_selection()") Cc: stable@vger.kernel.org Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov5647.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c index f9fac858dc7ba..d9e300406f58e 100644 --- a/drivers/media/i2c/ov5647.c +++ b/drivers/media/i2c/ov5647.c @@ -69,7 +69,7 @@ #define OV5647_NATIVE_HEIGHT 1956U =20 #define OV5647_PIXEL_ARRAY_LEFT 16U -#define OV5647_PIXEL_ARRAY_TOP 16U +#define OV5647_PIXEL_ARRAY_TOP 6U #define OV5647_PIXEL_ARRAY_WIDTH 2592U #define OV5647_PIXEL_ARRAY_HEIGHT 1944U =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 028243F3A67; Sat, 28 Feb 2026 17:42:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300547; cv=none; b=uarKmPbRTMeP4O3ir8ajF05CVmUvrGezgwfa3lNkm5PhgcmGnymgzOh1LVunvLynlYjgIin2sPP42udWBH2NPCwbRkd1wpmRes6yFLzjWkqUU3cDQHlAPZw0TXhfcuxK3DRsnVUIvrcXnObw+7mogLjyPm5JjjWjy5Wf1SdPUM8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300547; c=relaxed/simple; bh=CwyC21AyPKHvJlpZKOz1p2h18WZw4vJoC4Wy5bvfxR4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UPvqRLhQ+2FPK+JvU+tTrgmtUvQcak0GO5aCYW3MCyyV1ymIpy9h8gcwsulaQ6ABzXOUNIaA1BHsbHQRecLpO70psIuI9GEHSiIP22niOKfMgIDc7SNOssLZK1Yta7Nxyb3KdGAwL69ej/mPCsH4Ux59rlwE/CLg5WWBCU04Yy8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Hg2ZSg1T; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Hg2ZSg1T" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D829C19425; Sat, 28 Feb 2026 17:42:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300546; bh=CwyC21AyPKHvJlpZKOz1p2h18WZw4vJoC4Wy5bvfxR4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hg2ZSg1Tc6HWGLRvi02uvZl1Y7T6xZGjU0EDwBYzck93jm9EsPj3vRilobRKcuCP6 6f4KKd++JCpX4eL0W6sCghix45Sd1N5kKLIIc4MsdtEwhhCjQsbwA69+LyZFluoJqx 2GroOjOY6qBPXGD4YHZkut6Mdx947mAwUyMpQJmowpKSt8z1Vet82+JZWj77rIoALx 6shsmuswZF2ZG2ieTB7nxxwVwh+x9tGT3M0/J2XhQiYDmJ7SzL8ZyrEv0ieCBPXfyo wYkw7ty44MNIkbBrGQDKvLthf4sQSZFGPq2G72UA7BQAoGCaFQGJJhgg1FIl5H56gs MRIWGj5xPmklQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Plowman , Jacopo Mondi , Jai Luthra , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 586/844] media: i2c: ov5647: Correct minimum VBLANK value Date: Sat, 28 Feb 2026 12:28:19 -0500 Message-ID: <20260228173244.1509663-587-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Plowman [ Upstream commit 1438248c5a82c86b4e1f0311c3bb827af747a8cf ] Trial and error reveals that the minimum vblank value appears to be 24 (the OV5647 data sheet does not give any clues). This fixes streaming lock-ups in full resolution mode. Fixes: 2512c06441e3 ("media: ov5647: Support V4L2_CID_VBLANK control") Cc: stable@vger.kernel.org Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov5647.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c index d9e300406f58e..191954497e3db 100644 --- a/drivers/media/i2c/ov5647.c +++ b/drivers/media/i2c/ov5647.c @@ -73,7 +73,7 @@ #define OV5647_PIXEL_ARRAY_WIDTH 2592U #define OV5647_PIXEL_ARRAY_HEIGHT 1944U =20 -#define OV5647_VBLANK_MIN 4 +#define OV5647_VBLANK_MIN 24 #define OV5647_VTS_MAX 32767 =20 #define OV5647_EXPOSURE_MIN 4 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 238893F3254; Sat, 28 Feb 2026 17:42:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300548; cv=none; b=KxxPklSMcXXJVrMd5d/TzzjRfPi1Ri15LhOarVY7yJJGq2gguqUiwqsnoIUySzSUthw0UQLq5kN1HuCjtpCcWmOlpWxOQ71H8LDZX8Sn0dPHcbc6aOQW+D59x6v7iearCW0rrL8Lz6f+9uO+9xQVW7bpFNyT+IfSkA+3kPxvfc4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300548; c=relaxed/simple; bh=b6WhtVEP2p+gcJPlwCLcllZp1eYEWxVNgELP2T2BLQU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bXR1wj6GpJxwm4F3UHALhvXHFdW6NnTJe2+y+ZSfCgKzwjGEX53UkpIwlz/EcvXDHa3Y/XRvJxBj50PzQrOP+XhkfHgzi9RQfXBatZDNtjtDVYShsb//tqdQf2DMCuKMCWAn0fZK1iSTU7AND39kQ8lOt8bQpIjAZZ6jtNpzig0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ceIKT+f0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ceIKT+f0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2EB49C116D0; Sat, 28 Feb 2026 17:42:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300548; bh=b6WhtVEP2p+gcJPlwCLcllZp1eYEWxVNgELP2T2BLQU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ceIKT+f07I0QBPrr7OnFB+c9pydBw3DqDhwTj3cz61rDOUlhXjhxxB3hC+9N5lrd4 Rz9XEOpZ3rFPMfkG83v6LF3ZYCH1jEjYor/bNbcjxYCHjXKzK4acvSOGytq89pnxRk l7dbT8NEhk4MUisAuy/Tq1ogbwjOm5dhBMWgk7FyoTCmYLZhRuKjFzxsanBIMG4qGm LixF7nPOv68xkOajxfifObb5zMybQv4FX3BlrglGWZLZ1Vpjvf7wQ2YAtzl1DeeZxK kmtkOlumiOGqDHIOUD+dqUO457mn1A/pDF5uHlFGfTt2xphfx9IIdRrhSG2byXB6RL FKcMFKLlHyh/A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Plowman , Jacopo Mondi , Jai Luthra , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 587/844] media: i2c: ov5647: Sensor should report RAW color space Date: Sat, 28 Feb 2026 12:28:20 -0500 Message-ID: <20260228173244.1509663-588-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Plowman [ Upstream commit f007586b1e89dcea40168415d0422cb7a0fc31b1 ] As this sensor captures RAW bayer frames, the colorspace should be V4L2_COLORSPACE_RAW instead of SRGB. Fixes: a8df5af695a1 ("media: ov5647: Add SGGBR10_1X10 modes") Cc: stable@vger.kernel.org Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov5647.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c index 191954497e3db..c0f1121b025e5 100644 --- a/drivers/media/i2c/ov5647.c +++ b/drivers/media/i2c/ov5647.c @@ -508,7 +508,7 @@ static const struct ov5647_mode ov5647_modes[] =3D { { .format =3D { .code =3D MEDIA_BUS_FMT_SBGGR10_1X10, - .colorspace =3D V4L2_COLORSPACE_SRGB, + .colorspace =3D V4L2_COLORSPACE_RAW, .field =3D V4L2_FIELD_NONE, .width =3D 2592, .height =3D 1944 @@ -529,7 +529,7 @@ static const struct ov5647_mode ov5647_modes[] =3D { { .format =3D { .code =3D MEDIA_BUS_FMT_SBGGR10_1X10, - .colorspace =3D V4L2_COLORSPACE_SRGB, + .colorspace =3D V4L2_COLORSPACE_RAW, .field =3D V4L2_FIELD_NONE, .width =3D 1920, .height =3D 1080 @@ -550,7 +550,7 @@ static const struct ov5647_mode ov5647_modes[] =3D { { .format =3D { .code =3D MEDIA_BUS_FMT_SBGGR10_1X10, - .colorspace =3D V4L2_COLORSPACE_SRGB, + .colorspace =3D V4L2_COLORSPACE_RAW, .field =3D V4L2_FIELD_NONE, .width =3D 1296, .height =3D 972 @@ -571,7 +571,7 @@ static const struct ov5647_mode ov5647_modes[] =3D { { .format =3D { .code =3D MEDIA_BUS_FMT_SBGGR10_1X10, - .colorspace =3D V4L2_COLORSPACE_SRGB, + .colorspace =3D V4L2_COLORSPACE_RAW, .field =3D V4L2_FIELD_NONE, .width =3D 640, .height =3D 480 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2AFBE3F4270; Sat, 28 Feb 2026 17:42:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300549; cv=none; b=P33wHfidaX4tBZOxL5H6mXnHkPkVpI7ZX//sZA6vaWj6JxLo9pZAuHvSixLbiekOJqe8aKinzmH/aigJ9onS83jrf/vcW7/s6eshgQ1BOTcSwuaLcNIiXvYD3iELM52EaImPFXToCCQ3890EQomEu6ffNDFA5swowel+016Zcm8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300549; c=relaxed/simple; bh=VyZLVXUPkudy58ZFvfqr7Up7sGe3c+Vwfqt4FqfURlE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l22A3OTPkdRjLYNI57KCGQv+NZo2WeGZ9/lw0TG7PUeSv3XnZmQQdeMZ/nOFMwW48AoEXmFKjyoEJqFUG8TPqdZbQbSg3e2hW2uMicz4aq6sM/QLvo/IwP6ybtLYOXuWz6LmcXkaAb15DN96/zRU9YL1Z0N2CWAn2UGFQwuV5VI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LM37nc7Q; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LM37nc7Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49283C116D0; Sat, 28 Feb 2026 17:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300549; bh=VyZLVXUPkudy58ZFvfqr7Up7sGe3c+Vwfqt4FqfURlE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LM37nc7QAY1ctOImJmIdZH/VgcfJ3+5X8zXyBujUPOdBmcXoMntacee7WCitc/gQX OwubHYC25gHSdrkiiCf4UaMG/YkztkPo7sEOArQEol5vMYnhq4F2+iKD7fGYf+gK29 fXP65mm4muPYy2+67LmbakXOR+btnSLmzUBUO9m55yTmbk5YYfNRVKDwjgsUMTGYww laJnUMXCIE0oz4cG8M7HrUynidL7VabjSsk9jo0HCQAIQojsVvi9f+QbKHlp2VPXB2 2xlVsu5qOQVPPsGc7aozUmNUHsU6VocetZ8cXMtAFCKQzaPFqMuBOVxOEVasOM2RuP llRhZ8rwxsJ1Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jai Luthra , Dave Stevenson , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 588/844] media: i2c: ov5647: Fix PIXEL_RATE value for VGA mode Date: Sat, 28 Feb 2026 12:28:21 -0500 Message-ID: <20260228173244.1509663-589-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jai Luthra [ Upstream commit c063632b494b02e891442d10f17e37b7fcfab9b3 ] The pixel rate for VGA (640x480) mode is configured in the mode's table to be 58.333 MPix/s instead of 55 MPix/s, so fix it. Fixes: 911f4516ee2b ("media: ov5647: Support V4L2_CID_PIXEL_RATE") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/CAPY8ntA2TCf9FuB6Nk%2BOn%2By6N_PMuYPAOAr3= Yx8YESwe4skWvw@mail.gmail.com/ Suggested-by: Dave Stevenson Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov5647.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c index c0f1121b025e5..bf5b0bd8d6acb 100644 --- a/drivers/media/i2c/ov5647.c +++ b/drivers/media/i2c/ov5647.c @@ -582,7 +582,7 @@ static const struct ov5647_mode ov5647_modes[] =3D { .width =3D 2560, .height =3D 1920, }, - .pixel_rate =3D 55000000, + .pixel_rate =3D 58333000, .hts =3D 1852, .vts =3D 0x1f8, .reg_list =3D ov5647_640x480_10bpp, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0A7853F428B; Sat, 28 Feb 2026 17:42:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300550; cv=none; b=aH5+cPF7a3HVESg/pgcCO0ddAbAYdbuG7hR9SZ1hPg/U+wmzN2nPSOLr7iDl57W6pMRXf6Sjk6X2tBfLAow0jQ160rLrAiHW4eLnTyUXqboSjJU6DbCDahdkvppwtMgXre87Sh4MruY4L6AMpyEFNqSrDMZzJO9oo5UHkHAu6Rw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300550; c=relaxed/simple; bh=GQKo0lJwUgci+4iLYMerITetvNArF4HuD8WCFFnS5BU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Rh0GW4OMRpHJC1+HpTTCJ01jqQvTXNNe0hFwUqAdXsKJX5H58o89O5vruY5zB83RFQaFdSd9uCg3zYyqIzvyK2JDPzobAEm1c7ddQyBoiYQ10zk7Dwhi09ne6HQE+AKgYYIskB3Nfu4e8DuvHU43SpPdeiPM77nKpSMtxVSgqD4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LPRfWGwF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LPRfWGwF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52E93C19423; Sat, 28 Feb 2026 17:42:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300549; bh=GQKo0lJwUgci+4iLYMerITetvNArF4HuD8WCFFnS5BU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LPRfWGwF84wqBrWy8jGzx3/BW9JHAf6bNWyBZjohBUGU/uslFFuKmvlXSXJiJfZ3o P3jCxNEjqYmFHJg+zSzZO58HdQgaOKygFEOvtLyJQgV/f97fHN44yfTlQ2tRamVKWN VGgkvlI1a7HBQO0j8ISh0ACosTCxBTlnzLkcWEXOzZQ2QTxz5dCrYSTNg9jRtX5EdS VrLauKveQCt1rwAtd1TQ4Fwde/PbWNv6kr+Pjy3lEwozBlVCyjbGacQmB3Nk7fHzyl cxBO8plvG5MImlcQpD4xN+ryoL1jaUIHgrBDf4tHKhUnmbvJgI2GA00vI7FIenOyfj UpSrYCaIWTLJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 589/844] media: ccs: Fix setting initial sub-device state Date: Sat, 28 Feb 2026 12:28:22 -0500 Message-ID: <20260228173244.1509663-590-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sakari Ailus [ Upstream commit 31e5191aa11931b53e1242acef4f4375f00ca523 ] Fix setting sub-device state for non-source sub-devices. Fixes: 5755be5f15d9 ("media: v4l2-subdev: Rename .init_cfg() operation to .= init_state()") Cc: stable@vger.kernel.org # for v6.8 and later Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ccs/ccs-core.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/ccs/ccs-core.c b/drivers/media/i2c/ccs/ccs-c= ore.c index 3cacc7d904935..8d30e808a635b 100644 --- a/drivers/media/i2c/ccs/ccs-core.c +++ b/drivers/media/i2c/ccs/ccs-core.c @@ -2940,6 +2940,8 @@ static void ccs_cleanup(struct ccs_sensor *sensor) ccs_free_controls(sensor); } =20 +static const struct v4l2_subdev_internal_ops ccs_internal_ops; + static int ccs_init_subdev(struct ccs_sensor *sensor, struct ccs_subdev *ssd, const char *name, unsigned short num_pads, u32 function, @@ -2952,8 +2954,10 @@ static int ccs_init_subdev(struct ccs_sensor *sensor, if (!ssd) return 0; =20 - if (ssd !=3D sensor->src) + if (ssd !=3D sensor->src) { v4l2_subdev_init(&ssd->sd, &ccs_ops); + ssd->sd.internal_ops =3D &ccs_internal_ops; + } =20 ssd->sd.flags |=3D V4L2_SUBDEV_FL_HAS_DEVNODE; ssd->sd.entity.function =3D function; @@ -3062,6 +3066,10 @@ static const struct media_entity_operations ccs_enti= ty_ops =3D { .link_validate =3D v4l2_subdev_link_validate, }; =20 +static const struct v4l2_subdev_internal_ops ccs_internal_ops =3D { + .init_state =3D ccs_init_state, +}; + static const struct v4l2_subdev_internal_ops ccs_internal_src_ops =3D { .init_state =3D ccs_init_state, .registered =3D ccs_registered, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ECA5B3F3254; Sat, 28 Feb 2026 17:42:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300551; cv=none; b=iD/iJylXyc72cEAXEyJBjIT0tn276jXEWzOS0H4es0gJjvIwgGducSwevl7mDZkljcfiM8TFlCdTWTWcEnVl8mXeXMgcpxSzQ28siVxCDqXMyM4EwVi9T8V7y7IOqovjo/UzZWUOZJmIGfPX//fOctsrmlnS1OFNDDmVt00+rw8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300551; c=relaxed/simple; bh=C61+88oPQ2DdJ12m9Oocrh9SBD0mftXNOwo8mXk41Wk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=vAWR8+yplkU3rKflvMhpLkC0PRfvmL1LGNAkXtqYYSOP21hnX3xfwFgeEZJHkgkImgIVL+wLR3bFwhVQLtoClmyV3HSO9slocwT07uKqRbIMMXI5mqExWNh+y9aJn65C6zxV32M4sbjoLHPVaYtiiJ6LsAPVcAD2HT5dzk6tBu4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ekk9+jcl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ekk9+jcl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2DD95C19424; Sat, 28 Feb 2026 17:42:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300550; bh=C61+88oPQ2DdJ12m9Oocrh9SBD0mftXNOwo8mXk41Wk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ekk9+jclZhSC84aAzOnnoetbuQkhurQBK6X6vqCQc8j0qj6lWFN+e4XvppSSR9GxB M+mza6teMScpeZkyGcXxbaw65Qj4tfDrjB8lSHi/8G3IK3R8G/erFgrMIc2qIVnPHM oOrV7hJrA2Ad30xdRH822jrvivQqiKLixZUec+4pDIr5gRZgOHH6wY/DerqFdhM0Cg p2uUnSfmAIY53j7e6moe0iGPYOMTlauI+6Vfy2jUmUKPrFdoMOfao5wnl65H1Q3O1E Nx61QFWRjpk8oPkI8iL1wZXc2Rl0j0fquiw/5xsaFTPgqdCAtoo9PrL7cDAP4t32oq CWYkhkcRuVuuQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xiaolei Wang , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 590/844] media: i2c: ov5647: use our own mutex for the ctrl lock Date: Sat, 28 Feb 2026 12:28:23 -0500 Message-ID: <20260228173244.1509663-591-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xiaolei Wang [ Upstream commit 973e42fd5d2b397bff34f0c249014902dbf65912 ] __v4l2_ctrl_handler_setup() and __v4l2_ctrl_modify_range() contains an assertion to verify that the v4l2_ctrl_handler::lock is held, as it should only be called when the lock has already been acquired. Therefore use our own mutex for the ctrl lock, otherwise a warning will be reported. Fixes: 4974c2f19fd8 ("media: ov5647: Support gain, exposure and AWB control= s") Cc: stable@vger.kernel.org Signed-off-by: Xiaolei Wang [Sakari Ailus: Fix a minor conflict.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov5647.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c index bf5b0bd8d6acb..5fb10e02ba6e2 100644 --- a/drivers/media/i2c/ov5647.c +++ b/drivers/media/i2c/ov5647.c @@ -1291,6 +1291,8 @@ static int ov5647_init_controls(struct ov5647 *sensor) =20 v4l2_ctrl_handler_init(&sensor->ctrls, 9); =20 + sensor->ctrls.lock =3D &sensor->lock; + v4l2_ctrl_new_std(&sensor->ctrls, &ov5647_ctrl_ops, V4L2_CID_AUTOGAIN, 0, 1, 1, 0); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A7BD3F4AA0; Sat, 28 Feb 2026 17:42:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300552; cv=none; b=WEqAWtzHucWOHWhSj9u1L4K0hbNXAXgqYctqox1fNGI9r4pKdvZgek8zaZoV3d0caSfss/pBs0zJa6SbAptSBP304P9OfAax8GXE+tfz++Q9CbDIOv7R3OpQuBAu92I8IRNwcSiGtphVLoo/nyZJc/3Jd6y9KArJ+QkvYGrKz98= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300552; c=relaxed/simple; bh=mHbcm3efLdr7ht2qO4sssYcb9ZspIVB/JiuwDFBdiAk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jJ5KX/2ASsvmvZYosuaSP0H2lvmi93JR0tTen1nGNXhM++9ROk8TVPZkBGGRkLPO7Gsb75oe5Ha9u/T85+ACqKWgGdEbVCcloGwhXguw5IjslVqRHEzu/rbjOMXyP4qwR65XXR2tUDqoOptbiAVBqJy604Inwe47sguJF46X9ks= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a58O0OMG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a58O0OMG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2081FC116D0; Sat, 28 Feb 2026 17:42:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300552; bh=mHbcm3efLdr7ht2qO4sssYcb9ZspIVB/JiuwDFBdiAk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a58O0OMGarJkexEaOEoL7nSyWsvlxrHni6KxiFwZfrjK7IxeEry714V8xfStvqOxH 1N2pgmbiF8QfBY/qIEpmbj9436njHtqdMqC2S/TuL7Q4JB5cJuqI/CMNhPk0SYcdpK emtXzuN4RKy2IePdPKpknLRjxvkUWPh4ib6qsun3vl9XGlqVEfnKy/qEFyqQ2yPLZh 13FgnxueHSC/X6PM+4YHjENAilO+Ovnyvf8TGkOg98KOG11Yj9i0i1w4u0ZkEx0PlL RFy8pIJ9vxvZxnLXFUYCPhE1bnVRp+WD8xtv7cbt+wlGhGlS2ySb7tdVU2PMfR8FAP GLhhVbKADNObw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ricardo Ribalda , Hans de Goede , Neil Sun , Naomi Huang , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 591/844] media: dw9714: Fix powerup sequence Date: Sat, 28 Feb 2026 12:28:24 -0500 Message-ID: <20260228173244.1509663-592-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ricardo Ribalda [ Upstream commit 401aec35ac7bd04b4018a519257b945abb88e26c ] We have experienced seen multiple I2C errors while doing stress test on the module: dw9714 i2c-PRP0001:01: dw9714_vcm_resume I2C failure: -5 dw9714 i2c-PRP0001:01: I2C write fail Inspecting the powerup sequence we found that it does not match the documentation at: https://blog.arducam.com/downloads/DW9714A-DONGWOON(Autofocus_motor_manual)= .pdf """ (2) DW9714A requires waiting time of 12ms after power on. During this waiting time, the offset calibration of internal amplifier is operating for minimization of output offset current . """ This patch increases the powerup delay to follow the documentation. Fixes: 9d00ccabfbb5 ("media: i2c: dw9714: Fix occasional probe errors") Signed-off-by: Ricardo Ribalda Reviewed-by: Hans de Goede Tested-by: Neil Sun Reported-by: Naomi Huang Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/dw9714.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/dw9714.c b/drivers/media/i2c/dw9714.c index 1e7ad355a388c..3288de539452e 100644 --- a/drivers/media/i2c/dw9714.c +++ b/drivers/media/i2c/dw9714.c @@ -149,7 +149,7 @@ static int dw9714_power_up(struct dw9714_device *dw9714= _dev) =20 gpiod_set_value_cansleep(dw9714_dev->powerdown_gpio, 0); =20 - usleep_range(1000, 2000); + usleep_range(12000, 14000); =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2948E3F4AB3; Sat, 28 Feb 2026 17:42:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300553; cv=none; b=gXvFsHigl5PaFt4jqqQnQ+jy1DNTSl8KXlBjWi/WC3qEgWJxDotFznIg550FL+zgAZhlBnphUCXy8JhWr/VHnQCkTVqp6OBNabrkoBBRgCoKrG/Sx5mcjI65gonE+gEd57CDE9TDLTnUBlklNzw1lHxsegqltEE/4iiARQZVT98= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300553; c=relaxed/simple; bh=R70Y94bxuJC+tdy1f6T+8F3LOPZ3fkpgjtythSXEU8c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uTXmN+MwoJG+8CyevikEqfNv2d5x8DMtwNag/YWCyHgX0KZoIXJGFK2EAEEuAzSkhTM8GKiJafhLOyB4UmEm+EFofAA9ncznEt7ylFQr776rXdqpw9as9WnsqAqY4fhjpTSkhMWUAN+cIfu2Idwt2uRaybzxjVJRitadRXMzx2c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZBWstIFi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZBWstIFi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5ACA2C19423; Sat, 28 Feb 2026 17:42:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300553; bh=R70Y94bxuJC+tdy1f6T+8F3LOPZ3fkpgjtythSXEU8c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZBWstIFiX58EtfO+dCoD5Vsl/+07wLmHxQVW/FxH+EaIqGI9HFUTBHzouKeJfuu80 MbguVMMXrb8NsEuv7B1egaOuD9+NGzGcKD2zgGS82F6bJ9fnVW/0VIOoJHdIHEOoEP 9zm81Q352XrtNgCx+trVq21bLkmTw22+gq/3Q7v1KzuPBaEnpe8W3CAGn1p8kScw9k /QGqTHSiQnm+nI8h3MqjJJHAJ0a53impEkJrnUScuBtFLYKw74LCGGVOY8rVFT4H96 3GaPPtw8S2qe1Tk1/0C9PxxFKp6o0i39yq33EhCH/saJlC0CxFwCmGhMfRTCObjs7A FHrk0+QWIjsZA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bingbu Cao , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 592/844] media: ipu6: Fix typo and wrong constant in ipu6-mmu.c Date: Sat, 28 Feb 2026 12:28:25 -0500 Message-ID: <20260228173244.1509663-593-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bingbu Cao [ Upstream commit 3e0fcc91277d5af114a58aaa68f34b44e8d8a411 ] Fix two coding errors in ipu6-mmu.c: 1. Fix syntax error in page_table_dump() where the closing parenthesis and semicolon were swapped in the TBL_PHYS_ADDR macro call. 2. Fix incorrect loop bound in alloc_l2_pt(). When initializing L2 page table entries, the loop was incorrectly using ISP_L1PT_PTES instead of ISP_L2PT_PTES. Fixes: 9163d83573e4 ("media: intel/ipu6: add IPU6 DMA mapping API and MMU t= able") Cc: stable@vger.kernel.org Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/intel/ipu6/ipu6-mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/pci/intel/ipu6/ipu6-mmu.c b/drivers/media/pci/in= tel/ipu6/ipu6-mmu.c index 6d1c0b90169d4..85cc6d5b4dd11 100644 --- a/drivers/media/pci/intel/ipu6/ipu6-mmu.c +++ b/drivers/media/pci/intel/ipu6/ipu6-mmu.c @@ -102,7 +102,7 @@ static void page_table_dump(struct ipu6_mmu_info *mmu_i= nfo) if (mmu_info->l1_pt[l1_idx] =3D=3D mmu_info->dummy_l2_pteval) continue; =20 - l2_phys =3D TBL_PHYS_ADDR(mmu_info->l1_pt[l1_idx];) + l2_phys =3D TBL_PHYS_ADDR(mmu_info->l1_pt[l1_idx]); dev_dbg(mmu_info->dev, "l1 entry %u; iovas 0x%8.8x-0x%8.8x, at %pap\n", l1_idx, iova, iova + ISP_PAGE_SIZE, &l2_phys); @@ -248,7 +248,7 @@ static u32 *alloc_l2_pt(struct ipu6_mmu_info *mmu_info) =20 dev_dbg(mmu_info->dev, "alloc_l2: get_zeroed_page() =3D %p\n", pt); =20 - for (i =3D 0; i < ISP_L1PT_PTES; i++) + for (i =3D 0; i < ISP_L2PT_PTES; i++) pt[i] =3D mmu_info->dummy_page_pteval; =20 return pt; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2EC3748BD5E; Sat, 28 Feb 2026 17:42:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300554; cv=none; b=VVM8REQ6mBTxqjLOA4kUDiBqaPRPTHc2Q6rPyiPjfDrCcwdw5Xj+L125C0+Z6D3wbmX2YfSB56ZecvKBOoVf7TLmT1CutDbDotqZyd4zwliS/Cm5Lpn79My0MGINSjswFqJmSjxh2ulLnvsM0U4CibOJdaey0WLjW/iRAQikOWU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300554; c=relaxed/simple; bh=iUjxghbPGpierS2dmoHzYUTfoL1la1uEPilGAtjgPKQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GRrep2ueDO6MRrTU3tZ0+D1WDHSyGeXMXavbBYC4ehg/FHhZlwrMzljJQojb6HfOmqIkdnp0MO6NHf8A4cEt4/kMFsEZNUEfsHtrigxJHKO7FD6bynGsCC39R4EAeZR8Y3iVwpIn+RrEeyB+buJ+vOQAx4YTcLgwR7DOMLVhk30= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GJQVT0d3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GJQVT0d3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EFF2C116D0; Sat, 28 Feb 2026 17:42:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300554; bh=iUjxghbPGpierS2dmoHzYUTfoL1la1uEPilGAtjgPKQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GJQVT0d3co+6DY3erl4irZJlhm3CV41I7G3WCXiU8evQ5czcJwvHc3e7mclU0QAGw 9D0Z1ooJOHqkFkXDN7NEJNsrlGwM1lcfCEjRemubEkwOx+6jwA/aV9ci1XqYobD8Bm GBoSF/pv8MmPPsZnflCgnTndfSF/MfK4NNUxq3GL9Izrp5jTgtYqkmSv9Zr0SXMVUO 8HDUwRChBLSZSLw1nTCVhBj5cOyChkIxKosZeNtk1WxbhQ4KA1vvcRdWqR8LguXNvp 38sLDfAZg7JYqDJl59sq8cnyteJ8Rld3em1AsnLImu+0jxnYbd6oAlfZeeF3xp+59y RncPrMdbpMCyg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bingbu Cao , Stable@vger.kernel.org, Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 593/844] media: ipu6: Fix RPM reference leak in probe error paths Date: Sat, 28 Feb 2026 12:28:26 -0500 Message-ID: <20260228173244.1509663-594-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bingbu Cao [ Upstream commit 6099f78e4c9223f4de4169d2fd1cded01279da1a ] Several error paths in ipu6_pci_probe() were jumping directly to out_ipu6_bus_del_devices without releasing the runtime PM reference. Add pm_runtime_put_sync() before cleaning up other resources. Cc: Stable@vger.kernel.org Fixes: 25fedc021985 ("media: intel/ipu6: add Intel IPU6 PCI device driver") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/pci/intel/ipu6/ipu6.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/pci/intel/ipu6/ipu6.c b/drivers/media/pci/intel/= ipu6/ipu6.c index 1f4f20b9c94dc..a2768f44017a5 100644 --- a/drivers/media/pci/intel/ipu6/ipu6.c +++ b/drivers/media/pci/intel/ipu6/ipu6.c @@ -630,21 +630,21 @@ static int ipu6_pci_probe(struct pci_dev *pdev, const= struct pci_device_id *id) if (ret) { dev_err_probe(&isp->pdev->dev, ret, "Failed to set MMU hardware\n"); - goto out_ipu6_bus_del_devices; + goto out_ipu6_rpm_put; } =20 ret =3D ipu6_buttress_map_fw_image(isp->psys, isp->cpd_fw, &isp->psys->fw_sgt); if (ret) { dev_err_probe(&isp->pdev->dev, ret, "failed to map fw image\n"); - goto out_ipu6_bus_del_devices; + goto out_ipu6_rpm_put; } =20 ret =3D ipu6_cpd_create_pkg_dir(isp->psys, isp->cpd_fw->data); if (ret) { dev_err_probe(&isp->pdev->dev, ret, "failed to create pkg dir\n"); - goto out_ipu6_bus_del_devices; + goto out_ipu6_rpm_put; } =20 ret =3D devm_request_threaded_irq(dev, pdev->irq, ipu6_buttress_isr, @@ -652,7 +652,7 @@ static int ipu6_pci_probe(struct pci_dev *pdev, const s= truct pci_device_id *id) IRQF_SHARED, IPU6_NAME, isp); if (ret) { dev_err_probe(dev, ret, "Requesting irq failed\n"); - goto out_ipu6_bus_del_devices; + goto out_ipu6_rpm_put; } =20 ret =3D ipu6_buttress_authenticate(isp); @@ -683,6 +683,8 @@ static int ipu6_pci_probe(struct pci_dev *pdev, const s= truct pci_device_id *id) =20 out_free_irq: devm_free_irq(dev, pdev->irq, isp); +out_ipu6_rpm_put: + pm_runtime_put_sync(&isp->psys->auxdev.dev); out_ipu6_bus_del_devices: if (isp->psys) { ipu6_cpd_free_pkg_dir(isp->psys); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E9793F527D; Sat, 28 Feb 2026 17:42:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300555; cv=none; b=rGVtNbz5GhSrDZ61i7F/XLaGPXU3fkQmHrDCdrxmijXpPHrFeIYPXrVimmdoQqoufIcuoeJ9dHLGAIF4oOv3+t/3C7P1qUzKjfCs5QroDcZe8Kpm/kd+u8dpL/BrWkPRngWwMrRXK2zuKzRa5odPlug7rFJ0jhqyR1PrSoyM3sM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300555; c=relaxed/simple; bh=j7XjfcggW9wTKQ9kVivPmHRe+sslZnI9iWCZg1j7h3o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U9CU/j5x8B1mKi1IdpBo3gk405mgxHdfWxIv9WM1xO/7QngbzT+UdEMJnbmpmUCUGszhIkHnCR8A03i6h4glFHNWAzMlXTVIT6qGtmh1xiUgbGRMM3mAoIR0I62k+PDgf1LE+WYvBLwzY0bwgJOzgmTwHLx6bnJ16HfS0l0UPpQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U7hEfR0E; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U7hEfR0E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55A70C19423; Sat, 28 Feb 2026 17:42:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300555; bh=j7XjfcggW9wTKQ9kVivPmHRe+sslZnI9iWCZg1j7h3o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U7hEfR0EIocDsKhACI0IQjt9f1iimId25Y9XO7ew37mKVkvbHmXF+A09ti7m+xVwp 3Ye35Y7G8l9b7X5/83QT5/pKhL1mYsit7yPQcyrNa0xZLwm0D4rSMi0TEkCsaR7qON ijjJhhypx6WBcA0KuYj3Zf8n7g6bU4a4x8h4SNCM3bMjBpBZZcJUi/DhaZceDw8lIy 0ay1uDoj9RyVUHNFaBDfUWto4rTiqOk2I0+USVOxfgtz8NlcEeAR0B7la4PjcRiymL CGE5jVUYkeRzl+9/8VRFixfGPY1YM8fUoab9pFZBUw9syuVYPEIqKzQp4mH+uaFiQa IFSdyb7IMBQwQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bingbu Cao , Stable@vger.kernel.org, Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 594/844] media: staging/ipu7: Ignore interrupts when device is suspended Date: Sat, 28 Feb 2026 12:28:27 -0500 Message-ID: <20260228173244.1509663-595-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bingbu Cao [ Upstream commit 9ad65684b9285c5d66fb417d50e91a25ef8c994d ] IPU7 devices have shared interrupts with others. In some case when IPU7 device is suspended, driver get unexpected interrupt and invalid irq status 0xffffffff from ISR_STATUS and PB LOCAL_STATUS registers as interrupt is triggered from other device on shared irq line. In order to avoid this issue use pm_runtime_get_if_active() to check if IPU7 device is resumed, ignore the invalid irq status and use synchronize_irq() in suspend. Cc: Stable@vger.kernel.org Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver= ") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/staging/media/ipu7/ipu7-buttress.c | 17 ++++++++++++++++- drivers/staging/media/ipu7/ipu7.c | 4 ++++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/staging/media/ipu7/ipu7-buttress.c b/drivers/staging/m= edia/ipu7/ipu7-buttress.c index e5707f5e300ba..40c6c8473357c 100644 --- a/drivers/staging/media/ipu7/ipu7-buttress.c +++ b/drivers/staging/media/ipu7/ipu7-buttress.c @@ -342,14 +342,23 @@ irqreturn_t ipu_buttress_isr(int irq, void *isp_ptr) u32 disable_irqs =3D 0; u32 irq_status; unsigned int i; + int active; =20 - pm_runtime_get_noresume(dev); + active =3D pm_runtime_get_if_active(dev); + if (active <=3D 0) + return IRQ_NONE; =20 pb_irq =3D readl(isp->pb_base + INTERRUPT_STATUS); writel(pb_irq, isp->pb_base + INTERRUPT_STATUS); =20 /* check btrs ATS, CFI and IMR errors, BIT(0) is unused for IPU */ pb_local_irq =3D readl(isp->pb_base + BTRS_LOCAL_INTERRUPT_MASK); + if (pb_local_irq =3D=3D 0xffffffff) { + dev_warn_once(dev, "invalid PB irq status\n"); + pm_runtime_put_noidle(dev); + return IRQ_NONE; + } + if (pb_local_irq & ~BIT(0)) { dev_warn(dev, "PB interrupt status 0x%x local 0x%x\n", pb_irq, pb_local_irq); @@ -370,6 +379,12 @@ irqreturn_t ipu_buttress_isr(int irq, void *isp_ptr) return IRQ_NONE; } =20 + if (irq_status =3D=3D 0xffffffff) { + dev_warn_once(dev, "invalid irq status 0x%08x\n", irq_status); + pm_runtime_put_noidle(dev); + return IRQ_NONE; + } + do { writel(irq_status, isp->base + BUTTRESS_REG_IRQ_CLEAR); =20 diff --git a/drivers/staging/media/ipu7/ipu7.c b/drivers/staging/media/ipu7= /ipu7.c index 5cddc09c72bf2..6c8c3eea44acb 100644 --- a/drivers/staging/media/ipu7/ipu7.c +++ b/drivers/staging/media/ipu7/ipu7.c @@ -2684,6 +2684,10 @@ static void ipu7_pci_reset_done(struct pci_dev *pdev) */ static int ipu7_suspend(struct device *dev) { + struct pci_dev *pdev =3D to_pci_dev(dev); + + synchronize_irq(pdev->irq); + return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 379853F5299; Sat, 28 Feb 2026 17:42:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300556; cv=none; b=e/nkkP6gvDf4quIJICDCUB01GSp8TDIbn8CZiR1LFUKP3xW2wa007oOSfKlg+iYEU6jP+QvrMCFS3CzMVhaGg9eYlYxBJSvmRjHjWmPxceqzV/VoEgyFJpHZgdxiVhR7UqlndvkSwLT9VOxHee5ryBbZRtiV48dgV/SUzOIQ1K8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300556; c=relaxed/simple; bh=zMaUWkm3qmMDz0eMNZ10dyiuX56BqHuh7Glw3mA865Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jKrguE07zPW9SWP/ftkM0pvudgauyQngUQZAdTIo+yHGNZ6naHiuQ63n9eIQObPwxEETuG1KQ+U3YCTVhvdLEDo5HmPNBJkcmpos6yK/LqxVMVBDzIGq+aDMRRNQ8Uasn0uGZjPXxmUNLstxl34UWVaNLazCNufBR9gZu74rdvs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tiU7X14Y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tiU7X14Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DB91C19423; Sat, 28 Feb 2026 17:42:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300556; bh=zMaUWkm3qmMDz0eMNZ10dyiuX56BqHuh7Glw3mA865Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tiU7X14YIizonEsz6dEs5N2jb6ZALG/5wmrewess3DMqDHn7UMbxtz/vXYtoUbhnY ge6bZXvp1FmQA/7ztzAk6tMyMzwJpKgmyY2H5Rdv72jNfASaASkj5frPofY4hT793q BngBFS/8G2Q20o9T69d7onI65Qa77MAjc2p+jwHxRJ1toocE2ZmzWFbVjZDtaJgWuJ q1KthEDzT/ZD0IT4tN9VmxxhGyMgSHUkp0g7dUwR6ClrgJxRr5J1S4u4CtMd5tvu37 VnZq/JTdqWoj9+a7FJ/elVZTJK6vA4K7ex6Uf5WP5Gs4OBLgU0XxYqDmdr+Hvt0/Z9 PZWZU2FtggwAA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bingbu Cao , Stable@vger.kernel.org, Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 595/844] media: staging/ipu7: Call synchronous RPM suspend in probe failure Date: Sat, 28 Feb 2026 12:28:28 -0500 Message-ID: <20260228173244.1509663-596-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bingbu Cao [ Upstream commit 1433e6ccc25e9ea596683ab66e1c51f37fc7d491 ] If firmware authentication failed during driver probe, driver call an asynchronous API to suspend the psys device but the bus device will be removed soon, thus runtime PM of bus device will be disabled soon, that will cancel the suspend request, so use synchronous suspend to make sure the runtime suspend before disabling its RPM. IPU7 hardware has constraints that the PSYS device must be powered off before ISYS, otherwise it will cause machine check error. Cc: Stable@vger.kernel.org Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver= ") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/staging/media/ipu7/ipu7.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/ipu7/ipu7.c b/drivers/staging/media/ipu7= /ipu7.c index 6c8c3eea44acb..fa5a1867626f8 100644 --- a/drivers/staging/media/ipu7/ipu7.c +++ b/drivers/staging/media/ipu7/ipu7.c @@ -2620,7 +2620,7 @@ static int ipu7_pci_probe(struct pci_dev *pdev, const= struct pci_device_id *id) if (!IS_ERR_OR_NULL(isp->isys) && !IS_ERR_OR_NULL(isp->isys->mmu)) ipu7_mmu_cleanup(isp->isys->mmu); if (!IS_ERR_OR_NULL(isp->psys)) - pm_runtime_put(&isp->psys->auxdev.dev); + pm_runtime_put_sync(&isp->psys->auxdev.dev); ipu7_bus_del_devices(pdev); release_firmware(isp->cpd_fw); buttress_exit: --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 424683F5A4D; Sat, 28 Feb 2026 17:42:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300557; cv=none; b=d0ERcPIWvEk+ddv1rQXSKAlv+co/8Srg/YD8gZZYiTqg7US4AtLIC9m2z369p57FLWn1cMU+ZnrQgd7yj54aYTi/Pjec3bDPOZtkixCfQCfQdZh09E5wYRDuFsElF2nDFxgLlKpQqL2q7mUpTxsYwFA+RgczBeRse9KCmOH175A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300557; c=relaxed/simple; bh=fXRW22GKIGq9TiIb2fQM4Wiktdfuv2J/Mn6+4IMUBxU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=n3kERc8LoEBGMO7bQ0ApHfFvfVio0J78yuyeFMCGxV3L7y9q21GAPFcDBs2tiF5/+q4bQQm4dMjmL4c3WITxfs9Ywi6ulEQiOSB/DerBh2B+P8zXrdjDE/sjHp3rmssk4S0tr+NOX28gyF1tEfDKxkkgf1YtUdGAc3I65ZAX8m8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UJ3U3I/a; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UJ3U3I/a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FC10C19423; Sat, 28 Feb 2026 17:42:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300557; bh=fXRW22GKIGq9TiIb2fQM4Wiktdfuv2J/Mn6+4IMUBxU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UJ3U3I/aL+z6ydmklzlbx81J0ClkwT9etLE5SnELUwC9kOoOpUeCt5X0Zb++lmgs1 S9AqtI+Ah7PcT9VaWMHiEE3BkZ16GI2X3Iie3KSTBl7XeZ+w7WvioGNMOzTdjHKaaH SyNO6K7pXPf3EfdmTDLxiipoKnzXfxi5aBN0XTYxg71yJJGCb42EXaMCksz0Y8FMQ0 sI74k0xasjg+OGqGoV/LQh9SAB36xJIyDpkJy1EKEpJtrMOYbgwQl9gqFfJIy83cmS C+AD4DkunaTaYwA2+WIhWCdjBqigzd42Ibgr8K5Eq5xMI07HrTBuh5cHRGbspklX6K UPIR8watTIT9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bingbu Cao , Stable@vger.kernel.org, Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 596/844] media: staging/ipu7: Update CDPHY register settings Date: Sat, 28 Feb 2026 12:28:29 -0500 Message-ID: <20260228173244.1509663-597-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bingbu Cao [ Upstream commit f7923e6bafcad686adb51cc100ba1860f8b43922 ] Some CPHY settings needs to updated according to the latest guide from SNPS. This patch program 45ohm for tuning resistance to fix CPHY problem and update the ITMINRX and GMODE for CPHY. Cc: Stable@vger.kernel.org Fixes: a516d36bdc3d ("media: staging/ipu7: add IPU7 input system device dri= ver") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/staging/media/ipu7/ipu7-isys-csi-phy.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/staging/media/ipu7/ipu7-isys-csi-phy.c b/drivers/stagi= ng/media/ipu7/ipu7-isys-csi-phy.c index 2d57178835188..3f15af3b4c799 100644 --- a/drivers/staging/media/ipu7/ipu7-isys-csi-phy.c +++ b/drivers/staging/media/ipu7/ipu7-isys-csi-phy.c @@ -124,6 +124,7 @@ static const struct cdr_fbk_cap_prog_params table7[] = =3D { { 1350, 1589, 4 }, { 1590, 1949, 5 }, { 1950, 2499, 6 }, + { 2500, 3500, 7 }, { } }; =20 @@ -838,9 +839,10 @@ static void ipu7_isys_cphy_config(struct ipu7_isys *is= ys, u8 id, u8 lanes, dwc_phy_write_mask(isys, id, reg + 0x400 * i, reset_thresh, 9, 11); =20 + /* Tuning ITMINRX to 2 for CPHY */ reg =3D CORE_DIG_CLANE_0_RW_LP_0; for (i =3D 0; i < trios; i++) - dwc_phy_write_mask(isys, id, reg + 0x400 * i, 1, 12, 15); + dwc_phy_write_mask(isys, id, reg + 0x400 * i, 2, 12, 15); =20 reg =3D CORE_DIG_CLANE_0_RW_LP_2; for (i =3D 0; i < trios; i++) @@ -860,7 +862,11 @@ static void ipu7_isys_cphy_config(struct ipu7_isys *is= ys, u8 id, u8 lanes, for (i =3D 0; i < (lanes + 1); i++) { reg =3D CORE_DIG_IOCTRL_RW_AFE_LANE0_CTRL_2_9 + 0x400 * i; dwc_phy_write_mask(isys, id, reg, 4U, 0, 2); - dwc_phy_write_mask(isys, id, reg, 0U, 3, 4); + /* Set GMODE to 2 when CPHY >=3D 1.5Gsps */ + if (mbps >=3D 1500) + dwc_phy_write_mask(isys, id, reg, 2U, 3, 4); + else + dwc_phy_write_mask(isys, id, reg, 0U, 3, 4); =20 reg =3D CORE_DIG_IOCTRL_RW_AFE_LANE0_CTRL_2_7 + 0x400 * i; dwc_phy_write_mask(isys, id, reg, cap_prog, 10, 12); @@ -930,8 +936,9 @@ static int ipu7_isys_phy_config(struct ipu7_isys *isys,= u8 id, u8 lanes, 7, 12, 14); dwc_phy_write_mask(isys, id, CORE_DIG_IOCTRL_RW_AFE_CB_CTRL_2_7, 0, 8, 10); + /* resistance tuning: 1 for 45ohm, 0 for 50ohm */ dwc_phy_write_mask(isys, id, CORE_DIG_IOCTRL_RW_AFE_CB_CTRL_2_5, - 0, 8, 8); + 1, 8, 8); =20 if (aggregation) phy_mode =3D isys->csi2[0].phy_mode; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3612F3F5A60; Sat, 28 Feb 2026 17:42:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300558; cv=none; b=u6TO8/iXQieOH6U2ykU9eT/4/zOILOdMItsvFZhi0sT/XHaNGvpyReG6xKDmuOMcEevtk0wdtCvDZbfQoY5AZ263w15btjlIf33KXaCTD/X3Fy3ck6jLlnilSfj7OvtA7nbvCpxEVBKV0lKjHrTzNXjACc0Ol8Hfp3QodLPgtmQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300558; c=relaxed/simple; bh=c3A55tmRUKNtJtG/xnSgd+ZJdr/KmsWNCeJ7nVrLmXk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=o4VdygKSFukydq0dyq8cgKrKZAHm+Q7FF6Fr/z8VhvshX1C7UlKOxPK8NMRivgKrD4k6xjJIaDaWnI3J571jbqsM+HZeoO/+IWu1GqXbJlDke0idQ5bXYBG7VM8uhu39laF6TbLYa0gIuFy4nkNLX8qs3kD21acz5HFpFzsEVD8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eVSblbch; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eVSblbch" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A8CDC19425; Sat, 28 Feb 2026 17:42:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300558; bh=c3A55tmRUKNtJtG/xnSgd+ZJdr/KmsWNCeJ7nVrLmXk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eVSblbchXC2wUkVNn5CXPAxmHwfJb3gYFdTVHviFxG2G5o3LMOdiHOGHOkKA6u1dc FmEL/CVjGvp9OEprLHI6BMoK1Ogq8OKfdfi/5i3U51RiOI8RswXaM+4ew8f4JIXywc lTc6+OQ8ef1O1wgc0jifyRFyHXkmOyT2ggDEFHcR5lESrsZGkTYBU9E3MNVQY2zulz D3a7pgwRVwgN9DdckXS3eobfkgWmY7qKLQeInZ53Rsd63Gi03eQWfj4EFUT5sHwcAJ vkR7Xm0/nkctUFTpn7M/ze6BV77aA79XreB1z374gnfuXZDsDwHeHu3FGuTwrkUcii P2AEnM4cI+v6g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bingbu Cao , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 597/844] media: staging/ipu7: Fix the loop bound in l2 table alloc Date: Sat, 28 Feb 2026 12:28:30 -0500 Message-ID: <20260228173244.1509663-598-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bingbu Cao [ Upstream commit 98cc19a353abc8b48b7d58fd7a455e09e7c3aba3 ] This patch fixes the incorrect loop bound in alloc_l2_pt(). When initializing L2 page table entries, the loop was incorrectly using ISP_L1PT_PTES instead of ISP_L2PT_PTES though the ISP_L1PT_PTES is equal to ISP_L2PT_PTES. Fixes: 71d81c25683a ("media: staging/ipu7: add IPU7 DMA APIs and MMU mappin= g") Cc: stable@vger.kernel.org Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/staging/media/ipu7/ipu7-mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/ipu7/ipu7-mmu.c b/drivers/staging/media/= ipu7/ipu7-mmu.c index ded1986eb8ba3..ea35cce4830ad 100644 --- a/drivers/staging/media/ipu7/ipu7-mmu.c +++ b/drivers/staging/media/ipu7/ipu7-mmu.c @@ -231,7 +231,7 @@ static u32 *alloc_l2_pt(struct ipu7_mmu_info *mmu_info) =20 dev_dbg(mmu_info->dev, "alloc_l2: get_zeroed_page() =3D %p\n", pt); =20 - for (i =3D 0; i < ISP_L1PT_PTES; i++) + for (i =3D 0; i < ISP_L2PT_PTES; i++) pt[i] =3D mmu_info->dummy_page_pteval; =20 return pt; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0E7F23F5A7E; Sat, 28 Feb 2026 17:42:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300559; cv=none; b=abKT/mkWHxGZk0rcicqE15z90wyFQS4W3kFL/U2FL1XgSYt1/FkD23uvak7IMtTwmz3uq0k/UQwq+VWuYVa8Y90SQvuj8tAOu5ipjw4tJSNDUTaU0htf4Jywq0ElSuyMKRNRRdc8i5R2Wf/2pnK1p2udc8npdiVnvLhCVOMk0Zg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300559; c=relaxed/simple; bh=xmQi6+YKV9ITXwuL3p4IK8mL4FzIuikf+SuQGHCJe74=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KHC9y4Nz1yZYOiNSkeNNBk91n1JnGthZjknx/Ygd1YQmEMSB99UNOVcZCSaX27ef/Su/SLF+aRghPm4QEA7b2jiLt0Kx9rz4D/EcQAkGjWph5h3tL/fHx21iCdwTMjYvXI5St6t8Pmq5TL6XJtYhzQvnglR22kjqo6F71wkjUPE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dFDpGdSZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dFDpGdSZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AEC1C19424; Sat, 28 Feb 2026 17:42:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300558; bh=xmQi6+YKV9ITXwuL3p4IK8mL4FzIuikf+SuQGHCJe74=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dFDpGdSZa/Jt3poWhI0N3LY8QLSDiejQWinMe0NcgdGr84IxaSEZsTBoDagd1lFwU 1UHWs3K/PQQ3TQbS08VG6Ywp2AcKp8vQn0K2zaN1PBmv7aB2oV2JmOiPrudQYwEp8k Yl7LMgRMiH9PY+x9xnxY++5M3YITrYydhxJgId+bg2PC45RWF7bPW+iS6r75ykbi+s qE7z01ejkcSfe6c0uakMk4IaIbjVih1kGWnwsBV5DLgujy2p9FRl9IMtFnBzRrDx1U tRV5PG2wzqml0Jfe0qUZKA+7X1Nh8FnLJ0rnzFjNoMVT4/Bwxnf+cZ8+EFG+MYIAh1 q4+QcqX3cjcMA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Srinivas Pandruvada , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Sasha Levin Subject: [PATCH 6.19 598/844] platform/x86: ISST: Add missing write block check Date: Sat, 28 Feb 2026 12:28:31 -0500 Message-ID: <20260228173244.1509663-599-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Srinivas Pandruvada [ Upstream commit 0e5aef2795008c80c515f6fa04e377c6e5715958 ] If writes are blocked, then return error during SST-CP enable command. Add missing write block check in this code path. Fixes: 8bed9ff7dbcc ("platform/x86: ISST: Process read/write blocked featur= e status") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260107060256.1634188-2-srinivas.pandruvada= @linux.intel.com Reviewed-by: Ilpo J=C3=A4rvinen Signed-off-by: Ilpo J=C3=A4rvinen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c b/= drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c index 34bff2f65a835..f587709ddd473 100644 --- a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c +++ b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c @@ -612,6 +612,9 @@ static long isst_if_core_power_state(void __user *argp) return -EINVAL; =20 if (core_power.get_set) { + if (power_domain_info->write_blocked) + return -EPERM; + _write_cp_info("cp_enable", core_power.enable, SST_CP_CONTROL_OFFSET, SST_CP_ENABLE_START, SST_CP_ENABLE_WIDTH, SST_MUL_FACTOR_NONE) _write_cp_info("cp_prio_type", core_power.priority_type, SST_CP_CONTROL_= OFFSET, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF2623F624B; Sat, 28 Feb 2026 17:42:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300559; cv=none; b=Ke6F3kcGl/U3SGdOOozJOjCzUWfMuJCdpONEEkOKYRdkaaud75YywDcIXI5VcGvIww5olhQTjr5wKi57Qxjnr6BG3ZKWwx26looUBtEx66LE4ptaZRZRpctjBBDdBNB3hAZrebMzUho0dtkZM0pN/mqqFJLqGSovXkPirrR/ycc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300559; c=relaxed/simple; bh=bhJ5Yb/Na+yEVffXP00Rs2919cK6E4A6fCdILB2J4UQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FuHxJjkta8GEHrbz2C/3DJ5LhyTpj9CCQnkkTFupIfwQen8aHDDxeRCa/KR4LoHMOpgkH3TwlhOz39Qj2zXGz3dUwfN3HUB6dfodczMj8+bB5iieaRgbiDEJ8FhoVrn5Ya0Z8YdP9toS1SS7YD+qgodQeXzURBnuu0qP0NMh4+k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c5WSiGRz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c5WSiGRz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 353D3C19425; Sat, 28 Feb 2026 17:42:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300559; bh=bhJ5Yb/Na+yEVffXP00Rs2919cK6E4A6fCdILB2J4UQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c5WSiGRzlal6s0hS2JfoRN/QY57rkYHNhziRmrjncOcBIKFvvn8HoiiGUW+QADJGh yiV0pg6HeBfr+4J9OwZsS4ZcFAasL5nlxBkfi+JM6wQqCpp1Xg6VMQSjd9aKgJ6vNZ FvAGgN01YbfAK6Ta7DGHg7YaqAk1qr+rsls8qJrY05WKN+4lZ2ukKB9IqCGdKlFv09 /gkID0LdNRKnqv6rB4rhnOzja574Vwarci2dfa6a84lTLjEbPo7szusnYnogDrTAGz cpccEfsqbnNi+XwWTWHqjobArE6SuxvORLIwySjVz2AVKrTMTGzTNHk5PObojoqLHm MYMtpID6E6wGA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Srinivas Pandruvada , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Sasha Levin Subject: [PATCH 6.19 599/844] platform/x86: ISST: Store and restore all domains data Date: Sat, 28 Feb 2026 12:28:32 -0500 Message-ID: <20260228173244.1509663-600-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Srinivas Pandruvada [ Upstream commit dc7901b5a1563a9c9eb29b3b0b0dac3162065cd8 ] The suspend/resume callbacks currently only store and restore the configuration for power domain 0. However, other power domains may also have modified configurations that need to be preserved across suspend/ resume cycles. Extend the store/restore functionality to handle all power domains. Fixes: 91576acab020 ("platform/x86: ISST: Add suspend/resume callbacks") Signed-off-by: Srinivas Pandruvada CC: stable@vger.kernel.org Link: https://patch.msgid.link/20260107060256.1634188-3-srinivas.pandruvada= @linux.intel.com Reviewed-by: Ilpo J=C3=A4rvinen Signed-off-by: Ilpo J=C3=A4rvinen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../intel/speed_select_if/isst_tpmi_core.c | 54 +++++++++++-------- 1 file changed, 33 insertions(+), 21 deletions(-) diff --git a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c b/= drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c index f587709ddd473..13b11c3a2ec4e 100644 --- a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c +++ b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c @@ -1723,55 +1723,67 @@ EXPORT_SYMBOL_NS_GPL(tpmi_sst_dev_remove, "INTEL_TP= MI_SST"); void tpmi_sst_dev_suspend(struct auxiliary_device *auxdev) { struct tpmi_sst_struct *tpmi_sst =3D auxiliary_get_drvdata(auxdev); - struct tpmi_per_power_domain_info *power_domain_info; + struct tpmi_per_power_domain_info *power_domain_info, *pd_info; struct oobmsm_plat_info *plat_info; void __iomem *cp_base; + int num_resources, i; =20 plat_info =3D tpmi_get_platform_data(auxdev); if (!plat_info) return; =20 power_domain_info =3D tpmi_sst->power_domain_info[plat_info->partition]; + num_resources =3D tpmi_sst->number_of_power_domains[plat_info->partition]; =20 - cp_base =3D power_domain_info->sst_base + power_domain_info->sst_header.c= p_offset; - power_domain_info->saved_sst_cp_control =3D readq(cp_base + SST_CP_CONTRO= L_OFFSET); - - memcpy_fromio(power_domain_info->saved_clos_configs, cp_base + SST_CLOS_C= ONFIG_0_OFFSET, - sizeof(power_domain_info->saved_clos_configs)); + for (i =3D 0; i < num_resources; i++) { + pd_info =3D &power_domain_info[i]; + if (!pd_info || !pd_info->sst_base) + continue; =20 - memcpy_fromio(power_domain_info->saved_clos_assocs, cp_base + SST_CLOS_AS= SOC_0_OFFSET, - sizeof(power_domain_info->saved_clos_assocs)); + cp_base =3D pd_info->sst_base + pd_info->sst_header.cp_offset; + pd_info->saved_sst_cp_control =3D readq(cp_base + SST_CP_CONTROL_OFFSET); + memcpy_fromio(pd_info->saved_clos_configs, cp_base + SST_CLOS_CONFIG_0_O= FFSET, + sizeof(pd_info->saved_clos_configs)); + memcpy_fromio(pd_info->saved_clos_assocs, cp_base + SST_CLOS_ASSOC_0_OFF= SET, + sizeof(pd_info->saved_clos_assocs)); =20 - power_domain_info->saved_pp_control =3D readq(power_domain_info->sst_base= + - power_domain_info->sst_header.pp_offset + - SST_PP_CONTROL_OFFSET); + pd_info->saved_pp_control =3D readq(pd_info->sst_base + + pd_info->sst_header.pp_offset + + SST_PP_CONTROL_OFFSET); + } } EXPORT_SYMBOL_NS_GPL(tpmi_sst_dev_suspend, "INTEL_TPMI_SST"); =20 void tpmi_sst_dev_resume(struct auxiliary_device *auxdev) { struct tpmi_sst_struct *tpmi_sst =3D auxiliary_get_drvdata(auxdev); - struct tpmi_per_power_domain_info *power_domain_info; + struct tpmi_per_power_domain_info *power_domain_info, *pd_info; struct oobmsm_plat_info *plat_info; void __iomem *cp_base; + int num_resources, i; =20 plat_info =3D tpmi_get_platform_data(auxdev); if (!plat_info) return; =20 power_domain_info =3D tpmi_sst->power_domain_info[plat_info->partition]; + num_resources =3D tpmi_sst->number_of_power_domains[plat_info->partition]; =20 - cp_base =3D power_domain_info->sst_base + power_domain_info->sst_header.c= p_offset; - writeq(power_domain_info->saved_sst_cp_control, cp_base + SST_CP_CONTROL_= OFFSET); - - memcpy_toio(cp_base + SST_CLOS_CONFIG_0_OFFSET, power_domain_info->saved_= clos_configs, - sizeof(power_domain_info->saved_clos_configs)); + for (i =3D 0; i < num_resources; i++) { + pd_info =3D &power_domain_info[i]; + if (!pd_info || !pd_info->sst_base) + continue; =20 - memcpy_toio(cp_base + SST_CLOS_ASSOC_0_OFFSET, power_domain_info->saved_c= los_assocs, - sizeof(power_domain_info->saved_clos_assocs)); + cp_base =3D pd_info->sst_base + pd_info->sst_header.cp_offset; + writeq(pd_info->saved_sst_cp_control, cp_base + SST_CP_CONTROL_OFFSET); + memcpy_toio(cp_base + SST_CLOS_CONFIG_0_OFFSET, pd_info->saved_clos_conf= igs, + sizeof(pd_info->saved_clos_configs)); + memcpy_toio(cp_base + SST_CLOS_ASSOC_0_OFFSET, pd_info->saved_clos_assoc= s, + sizeof(pd_info->saved_clos_assocs)); =20 - writeq(power_domain_info->saved_pp_control, power_domain_info->sst_base + - power_domain_info->sst_header.pp_offset + SST_PP_CONTROL_OFFSET); + writeq(pd_info->saved_pp_control, power_domain_info->sst_base + + pd_info->sst_header.pp_offset + SST_PP_CONTROL_OFFSET); + } } EXPORT_SYMBOL_NS_GPL(tpmi_sst_dev_resume, "INTEL_TPMI_SST"); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D18283F626A; Sat, 28 Feb 2026 17:42:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300560; cv=none; b=MphNMhh0WgfuoEoHZYZvdlaGrlcmqdtGndNhkm/GPPuBYynBZK9esiwxlkw5j63fudYkBnvWDuKp5awREKD1uH8YoYVeZUUhWdd6AEA+ib+ejb4wSfAfGM/WJtsgptlaLDRSulisXG2O7bgVvRaLOgw1C9xDmcTsrzacPfpU1kI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300560; c=relaxed/simple; bh=jmP9nu0tcyCOQ6ZWqCiraqPMH4qvU3M7wXK/4ccptq8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KWc1Y+NaGJDSC/MM2Ey6ufnogASUkn//sZfiYwQtjB8xvMrRmVT+M4xtCvh+1XzBODJ6KRKsH/Fd4gAyq4srzrCiunAeSML2r++rg6qPVJrbleOYQT5eSLGPkf1AgHL+UNaNKjXDNUoLhIqAvx/NLggIh7HmzNA0kmMGJR82EDE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RalvNmLb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RalvNmLb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 121C1C19423; Sat, 28 Feb 2026 17:42:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300560; bh=jmP9nu0tcyCOQ6ZWqCiraqPMH4qvU3M7wXK/4ccptq8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RalvNmLb8QIrFeCuw0XswIQXyITk2JEXuvgMy4qljGt8l8ZmeVBq7LckTJ8SCxYQL CD0NCuqdF0aKeK7BP5kk+Pk6e/yBYicMm1FzhaRFcq8qHUdXwps6PTcUOVsMbn4J83 +rETeZySwnakDKH5F8CWuHxBDOMB14LBlwl56BUZ2UJ/cA0cWH3dwo6rs7BoVErwQT FJ/wleRu3G6Z2WE+cvTEtHdUrAYcpvYbal7yIU5ogMxsAWpmNTlsGtgKk7W3FuLdzk DlWCM7qrTwFi9c/p5CNA/DqvqqyCL5P4XTAC7N7va3THCKVjPZd+FQdY6CX3+uriqc K6ZEiJ2Qa0k3A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sean Christopherson , Alessandro Ratti , syzbot+1522459a74d26b0ac33a@syzkaller.appspotmail.com, Sasha Levin Subject: [PATCH 6.19 600/844] KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block() Date: Sat, 28 Feb 2026 12:28:33 -0500 Message-ID: <20260228173244.1509663-601-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sean Christopherson [ Upstream commit ead63640d4e72e6f6d464f4e31f7fecb79af8869 ] Ignore -EBUSY when checking nested events after exiting a blocking state while L2 is active, as exiting to userspace will generate a spurious userspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM's demise. Continuing with the wakeup isn't perfect either, as *something* has gone sideways if a vCPU is awakened in L2 with an injected event (or worse, a nested run pending), but continuing on gives the VM a decent chance of surviving without any major side effects. As explained in the Fixes commits, it _should_ be impossible for a vCPU to be put into a blocking state with an already-injected event (exception, IRQ, or NMI). Unfortunately, userspace can stuff MP_STATE and/or injected events, and thus put the vCPU into what should be an impossible state. Don't bother trying to preserve the WARN, e.g. with an anti-syzkaller Kconfig, as WARNs can (hopefully) be added in paths where _KVM_ would be violating x86 architecture, e.g. by WARNing if KVM attempts to inject an exception or interrupt while the vCPU isn't running. Cc: Alessandro Ratti Cc: stable@vger.kernel.org Fixes: 26844fee6ade ("KVM: x86: never write to memory from kvm_vcpu_check_b= lock()") Fixes: 45405155d876 ("KVM: x86: WARN if a vCPU gets a valid wakeup that KVM= can't yet inject") Link: https://syzkaller.appspot.com/text?tag=3DReproC&x=3D10d4261a580000 Reported-by: syzbot+1522459a74d26b0ac33a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/671bc7a7.050a0220.455e8.022a.GAE@google= .com Link: https://patch.msgid.link/20260109030657.994759-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/kvm/x86.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 042ebda1a6576..d65ebaed18986 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11609,8 +11609,7 @@ static inline int vcpu_block(struct kvm_vcpu *vcpu) if (is_guest_mode(vcpu)) { int r =3D kvm_check_nested_events(vcpu); =20 - WARN_ON_ONCE(r =3D=3D -EBUSY); - if (r < 0) + if (r < 0 && r !=3D -EBUSY) return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AAE23F5A4D; Sat, 28 Feb 2026 17:42:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300561; cv=none; b=C2TtMuHlN7hyK56hFx2HRlsX78DWhOCmnHr4BaWJ/AiL7r697+jc2H/bGlOw51l5F2VSfKZRssmCSiQglQAyHxetFJdnv/aySLLGoK3vnZJBIUCJewIWhPL9jsrDEIN89KFnoE+l5A7tccQuEXRAqV/RpHrbUt0CDs4XGHKxnow= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300561; c=relaxed/simple; bh=wiFr3cqew56q6DCv9ENOeggq/XEDhHnvSs/Luebh4zA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Sg+x4dWtBFJkm8bnHR7JoK3FXWxiGgy01ngYy0FYbRHhbh5Vr3K0EQESmhWnBEW4djKPA5WhgV83T7Czdn1OhwoA6qpsZ6oct/CXc+G/gtuu1v0PvD+rihWCpuL6xVbXFwpe6zL9GdCVmcGZapEJwRi2qAYZZwewNpyhA+2rGhA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oipm+q6x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oipm+q6x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 069C1C19423; Sat, 28 Feb 2026 17:42:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300561; bh=wiFr3cqew56q6DCv9ENOeggq/XEDhHnvSs/Luebh4zA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oipm+q6xqxYrd8jeTCc7jR83xxQ7cpxODvSxNgz7HcDDPtRcPFWqpJzyy6+XUEPl8 oKhg0MVqopSGuZFGgpV4wwSfjVgtjorTVzO7wv7igyR+lDQPSFdzcE4YICCg1Tl9du p9T3N6OckL/jL779gp7QpfT+q/eMr2TRfsErgT620qnh9iptYL8NzPwhorDMmWLv+t glA5CvC8hTpJS7Jg/K4LwhLIJ9IGGpVwZUIwKmJaVuIBL6Rgd2z5A4TPIRkaneGmZQ ChUZi4SC3emFURJhgwnDIRKBt80fJx7aj8dQZnR8HEhBcOpWLDrkA2ip7ipMDdsdbu TvwhCCqN2GF0Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mikulas Patocka , Sasha Levin Subject: [PATCH 6.19 601/844] dm-integrity: fix a typo in the code for write/discard race Date: Sat, 28 Feb 2026 12:28:34 -0500 Message-ID: <20260228173244.1509663-602-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mikulas Patocka [ Upstream commit c698b7f417801fcd79f0dc844250b3361d38e6b8 ] If we send a write followed by a discard, it may be possible that the discarded data end up being overwritten by the previous write from the journal. The code tries to prevent that, but there was a typo in this logic that made it not being activated as it should be. Note that if we end up here the second time (when discard_retried is true), it means that the write bio is actually racing with the discard bio, and in this situation it is not specified which of them should win. Cc: stable@vger.kernel.org Fixes: 31843edab7cb ("dm integrity: improve discard in journal mode") Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-integrity.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c index 170bf67a2edd9..79d60495454a5 100644 --- a/drivers/md/dm-integrity.c +++ b/drivers/md/dm-integrity.c @@ -2411,7 +2411,7 @@ static void dm_integrity_map_continue(struct dm_integ= rity_io *dio, bool from_map =20 new_pos =3D find_journal_node(ic, dio->range.logical_sector, &next_secto= r); if (unlikely(new_pos !=3D NOT_FOUND) || - unlikely(next_sector < dio->range.logical_sector - dio->range.n_sect= ors)) { + unlikely(next_sector < dio->range.logical_sector + dio->range.n_sect= ors)) { remove_range_unlocked(ic, &dio->range); spin_unlock_irq(&ic->endio_wait.lock); queue_work(ic->commit_wq, &ic->commit_work); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1A7A3F6ADA; Sat, 28 Feb 2026 17:42:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300562; cv=none; b=Sk3IwrfuFzPN5R3ESnjgVPbmnzKDQdwT+DYQdXp5G0WIDT1eyY2ZOjwF5SD0CDq3YGMVhIxkxd+fXR/QW/sOV1r+dwRjO1I2w1SSnuw3MHN7m4H8079w6tmJilx6UuRSgRLse1gbYGipFqAPPRMPMklQYJ1d8aQ0w9czrD3TM5E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300562; c=relaxed/simple; bh=g+lQ6eEmCsqoIVmNzQsNBTXxuJYWt6+/ZurWb0pCyQ8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iVhnVMx9NFER3fIvso0HLV8D4H+C+Ik8UOY7x+GEHw4ldqVBRdcfS+BzWi3omvwEwDUMMTQfvh8iQ+L6hIgNtOjPmuQnr7k/YV80SJ8/lTLY9J5Kx1yhEUdQ+WJcGj0qsWr3gHY+Ofw1zZAAODuTEdVsTDxgud5PPTyF/Mdf/io= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BCA9oAB2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BCA9oAB2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BECF4C19423; Sat, 28 Feb 2026 17:42:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300562; bh=g+lQ6eEmCsqoIVmNzQsNBTXxuJYWt6+/ZurWb0pCyQ8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BCA9oAB24od+rO+L47PDP8gxkF+jO2Z/vf2oDY7C2bEIlYrLhfwEq/etvvk/eP/Eo WflEek7a4cpG+njOOnr2mvw9/p4xyK82fkJVXHEMdeYCaqrll62HDiUcLr1I7cnKee F6XxGoAGqMIu33YQC9v7VR1rj8o2mMtDA3pcrfqCZ2DEQFwFuzQ5f8/eTihEMl6JsB Lml1ubTI6ZNoPcl0KqCDVqA9F8aFrfBuhkyv6+ooQhaQ801PBvV7KuixlwxofqmBrm zSDqURZSCeg3L574CpKwFpRXuMIxa4SzcJzVyfXMh4iPac6rxWlL1SIl9yn3hlze4u rjsueGfVSpI8w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Michael Liang , Mohamed Khalfella , Mikulas Patocka , Sasha Levin Subject: [PATCH 6.19 602/844] dm: clear cloned request bio pointer when last clone bio completes Date: Sat, 28 Feb 2026 12:28:35 -0500 Message-ID: <20260228173244.1509663-603-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Michael Liang [ Upstream commit fb8a6c18fb9a6561f7a15b58b272442b77a242dd ] Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios. Signed-off-by: Michael Liang Reviewed-by: Mohamed Khalfella Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-rq.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c index 5e08546696145..923252fb57aec 100644 --- a/drivers/md/dm-rq.c +++ b/drivers/md/dm-rq.c @@ -109,14 +109,21 @@ static void end_clone_bio(struct bio *clone) */ tio->completed +=3D nr_bytes; =20 + if (!is_last) + return; + /* + * At this moment we know this is the last bio of the cloned request, + * and all cloned bios have been released, so reset the clone request's + * bio pointer to avoid double free. + */ + tio->clone->bio =3D NULL; + exit: /* * Update the original request. * Do not use blk_mq_end_request() here, because it may complete * the original request before the clone, and break the ordering. */ - if (is_last) - exit: - blk_update_request(tio->orig, BLK_STS_OK, tio->completed); + blk_update_request(tio->orig, BLK_STS_OK, tio->completed); } =20 static struct dm_rq_target_io *tio_from_request(struct request *rq) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6208E3F6AEF; Sat, 28 Feb 2026 17:42:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300563; cv=none; b=dIL3INJY9oMfmcmLbZt0f/PNRC4/LkXLgA313ijGc49BqQcxrpHtFgpf5JZEr75IhREK0hJsui41SUS3hwCMWB8HtvU5+WScHjr4nL1Cb7tngMVas4L0YB1Fog8d9UwzqXI3Uxc0z0egWt/Hb/zZ1RJNLzxWFO++724Gjw67xsA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300563; c=relaxed/simple; bh=i1HvkQjXWbqm6+cFevEgkfc5JQGm0pBz1zHif6jCYd0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F25rOUT7AnSWX6KLsS5xTyDGUzoPt4lDjedzs7wSSh6YS09Lv13tm6fuMVZKwGR/rDb+SGQsaxhfrgx0fCar+TSBZUtMMqHCPRzDT8T1lkp/FI003/ayFtBOENqWrHEvc7kkWesmsUwr6ea3Yhbvvhu0p6GykivXLeAcn6kqQpY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nUGM0AOV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nUGM0AOV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ACA95C116D0; Sat, 28 Feb 2026 17:42:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300563; bh=i1HvkQjXWbqm6+cFevEgkfc5JQGm0pBz1zHif6jCYd0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nUGM0AOVMqVSB0rqEpN8F7IN9E5cuLcEG8ym/7AXU0PfvNP5y/sjw0SCLUIURU+Zt 87HdRy2OqAO9YObI7Z6rGeVF3c1PMWu04a//Ia9PiWU1m7IMnn2kXGmC+1ZFf7tNoz eWv7/S1KdUV+ttGI8zxiUuT/78FU5W3COuUJa+mn1Mcl6vcQMpTzGzSKJssrNbBY83 OND34Pfwc/ljfZblvgyRUurxdb8aOqx71UAVJUM9iznTuc3L1zro9GJuZKjEyi2/gN uD8mXZ+BGKC9LFTxIqIRS3QIJKlGEuEeyqvbrcR3D29Bm0f9nNXeGGUGros9bknnlj 9A3bYmO0dOjhQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Thierry Reding , Sasha Levin Subject: [PATCH 6.19 603/844] drm/tegra: dsi: fix device leak on probe Date: Sat, 28 Feb 2026 12:28:36 -0500 Message-ID: <20260228173244.1509663-604-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit bfef062695570842cf96358f2f46f4c6642c6689 ] Make sure to drop the reference taken when looking up the companion (ganged) device and its driver data during probe(). Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: e94236cde4d5 ("drm/tegra: dsi: Add ganged mode support") Fixes: 221e3638feb8 ("drm/tegra: Fix reference leak in tegra_dsi_ganged_pro= be") Cc: stable@vger.kernel.org # 3.19: 221e3638feb8 Cc: Thierry Reding Signed-off-by: Johan Hovold Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20251121164201.13188-1-johan@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/tegra/dsi.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c index 175f5f9937b01..8ee96b59fdbc8 100644 --- a/drivers/gpu/drm/tegra/dsi.c +++ b/drivers/gpu/drm/tegra/dsi.c @@ -1542,11 +1542,9 @@ static int tegra_dsi_ganged_probe(struct tegra_dsi *= dsi) return -EPROBE_DEFER; =20 dsi->slave =3D platform_get_drvdata(gangster); - - if (!dsi->slave) { - put_device(&gangster->dev); + put_device(&gangster->dev); + if (!dsi->slave) return -EPROBE_DEFER; - } =20 dsi->slave->master =3D dsi; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5751648C3F4; Sat, 28 Feb 2026 17:42:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300564; cv=none; b=LVC3YmuESFcP4PwWrA8RPj15UIbSRlWKIRUv8ccsWSP56wAfbeNn8l8RHVuife8JxluM1i2wKEDHKD1q2+g6EX6ODBIjZq250m38qTEIeR+qSyTUlu+EsBjyhGwOxZrkOvMGpB62/zBXISw+tkKGWP1AuwybAI5dbQ2y1Vl4lL8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300564; c=relaxed/simple; bh=xXJsk3Lae2xstEARdnH60ETU+GXhtsUK4YIx6sThe1A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K34Ue7zwVFeDGIaQnnShEir5mzaF/aBT8Oqv5AM49wreK2Y3QPwTxOb3nH328GU6dFiYYlTCE6wJs5m4ipkhEWcvkAv/n7/UwGyiI1fLfQFuU6aZWhRBhLO4Nr9Cmgcs0ysbAOHHMEXWBebNDYsNBwcUTpPUQlE+OZN56aV7QnI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O23W/GSt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O23W/GSt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 896F8C19423; Sat, 28 Feb 2026 17:42:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300564; bh=xXJsk3Lae2xstEARdnH60ETU+GXhtsUK4YIx6sThe1A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O23W/GStaAi0v6Zl0ICSd/JHlrWbISV/8mggd6NHPjKuRJsgTEtLFueDU+1i2SImg f7hE7CRo9VmNpyitBjD4Yyz6nw1H3RPvrdFSOk0wjp1TGqv9utOX5SdUYL+dkBBp++ ZB69JfHzIz1MOZA3xsxJISmf3dzdrohTwZ8UNGdXUXd3NBtBUXczBe5Ifgpgbp+IpT HpUf53QIVIGoAqvzU4hTNbOphOeHsVsH8O1wk778MgwbkytJPiL4+czQIT6I8mGZ4C gG44fKod/2rm3SrAOM2/ha8qB5T+TZ4l+M85qnUD0orZ9vOjOhFji77EFxTTL7u1Yf yW/lNURDRoEZQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Andrew Davis , Nishanth Menon , Sasha Levin Subject: [PATCH 6.19 604/844] soc: ti: k3-socinfo: Fix regmap leak on probe failure Date: Sat, 28 Feb 2026 12:28:37 -0500 Message-ID: <20260228173244.1509663-605-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit c933138d45176780fabbbe7da263e04d5b3e525d ] The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: a5caf03188e4 ("soc: ti: k3-socinfo: Do not use syscon helper to buil= d regmap") Cc: stable@vger.kernel.org # 6.15 Cc: Andrew Davis Signed-off-by: Johan Hovold Acked-by: Andrew Davis Link: https://patch.msgid.link/20251127134942.2121-1-johan@kernel.org Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/soc/ti/k3-socinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c index 50c170a995f90..42275cb5ba1c8 100644 --- a/drivers/soc/ti/k3-socinfo.c +++ b/drivers/soc/ti/k3-socinfo.c @@ -141,7 +141,7 @@ static int k3_chipinfo_probe(struct platform_device *pd= ev) if (IS_ERR(base)) return PTR_ERR(base); =20 - regmap =3D regmap_init_mmio(dev, base, &k3_chipinfo_regmap_cfg); + regmap =3D devm_regmap_init_mmio(dev, base, &k3_chipinfo_regmap_cfg); if (IS_ERR(regmap)) return PTR_ERR(regmap); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AE0B3F739D; Sat, 28 Feb 2026 17:42:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300565; cv=none; b=NPZTKzdfmWN9ckDpmlinzzgqIp1xpZohbtAEixwPa3wu8cFxISMl70cocrkT8Bdm/prS7/GKWauT5QCwnliyuWaQFpyvdSfBbKp/btJXVKIS3l9RMMiiU3cTWEbvnmPp7CzSXYX0cwNPwgwV9NnDqhIHMOkh9zjt3IaO8g2/aqE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300565; c=relaxed/simple; bh=9cr3n3gmMpWWaSZjZA2afqSrWBNC6bCrHzSRJ4+2g74=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oglukAxGHt5B58mnElLkDk7iJKPHnraYNzG8y06hW1rz1eb5S4JUAjZOaOyT+PVCk+v3yEsdD5ld8luftixlHcsiE5paxffDa+P1Oux2Jzfk3dna85EjJwEuhJdn0DwOD997ETpLwmO4cSA0COgOUaqPxgLhSBVxXYWKymzKfl8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sj6D9wsE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sj6D9wsE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E1AAC19424; Sat, 28 Feb 2026 17:42:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300565; bh=9cr3n3gmMpWWaSZjZA2afqSrWBNC6bCrHzSRJ4+2g74=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sj6D9wsEL3KpaSfXAhvaWcDaJAZKj3AkKT7RvsvPj5Jzd9MlRTRkCiBMZNVsULSR/ +lSr5Oa5LY8HJ+XtH6vzGH/NjpXoaZghXmRzT8GIlMHE25/JWmW5Uqr2wO6KOE6SkP tYqHCf1tC/RIqAU7eItJUQbusw6bL9QaaocK5LuNRdqx2C5AcHNoOcbczDp3L/Df52 1HpynZv6r6pZ7ekbSzb+8FymuSfSsa2a4YjHD7B6V3Ox4S8mP/sPuyv/6eycvDJY2R 6I8wUD+vtzR/pl79t19Ysbn0Xnd2k+dZ8ZeWzb14Ym6BVXO0iX0snDIJ7pntHRrESv h3xPCFM1wsoOQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Wentao Liang , Nishanth Menon , Sasha Levin Subject: [PATCH 6.19 605/844] soc: ti: pruss: Fix double free in pruss_clk_mux_setup() Date: Sat, 28 Feb 2026 12:28:38 -0500 Message-ID: <20260228173244.1509663-606-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wentao Liang [ Upstream commit 80db65d4acfb9ff12d00172aed39ea8b98261aad ] In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put(). Fixes: ba59c9b43c86 ("soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260113014716.2464741-1-vulab@iscas.ac.cn Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/soc/ti/pruss.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c index 038576805bfa0..0fd59c73f585d 100644 --- a/drivers/soc/ti/pruss.c +++ b/drivers/soc/ti/pruss.c @@ -366,12 +366,10 @@ static int pruss_clk_mux_setup(struct pruss *pruss, s= truct clk *clk_mux, =20 ret =3D devm_add_action_or_reset(dev, pruss_of_free_clk_provider, clk_mux_np); - if (ret) { + if (ret) dev_err(dev, "failed to add clkmux free action %d", ret); - goto put_clk_mux_np; - } =20 - return 0; + return ret; =20 put_clk_mux_np: of_node_put(clk_mux_np); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24DB73F73BB; Sat, 28 Feb 2026 17:42:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300566; cv=none; b=hQzbl/JPzUJ6IMFTEXn2aRHLVfSe6UswvX4xN++C3MPQdlA+s7wTeehX4RnXUvVzcBit8BwkwRhvEf5DapkOJm/rXkQYNP4r/mWL/s7xodTl1Vo+13GH1CIW4TzAVxa41tp/kOOr+ArEJHDBD6xkZ2EvnlEW1atZI8P0THRw6mo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300566; c=relaxed/simple; bh=z/W11taz5qyx+nRC96o5JLotFW31RFx5HMgKlHr4b4o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hTp57xjPZ6wTU/Pis1oqLKjam/Gjx4quXOOMMUrUZ7Z9+mqc+9ywVnBcJ9BvXFDjNt5WphaIDHRLcsV7ZlfmGCCyYPS0Uq1ePNqiZqle7cYxEqJuIWgFnzpkSYjYMmaYVnR+r2MVKFDEq1YcWQiAbfmM6Jbxwm5AapDrQ0lpoEQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oLzKS5xp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oLzKS5xp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59264C116D0; Sat, 28 Feb 2026 17:42:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300566; bh=z/W11taz5qyx+nRC96o5JLotFW31RFx5HMgKlHr4b4o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oLzKS5xpzDdbi7OWRTaq7yTrubaAz2UldkYeMyGZi06Ymg6cjT/qGsFjsssIy3rPr s4MquKkFwI9wBaAxNMYgoBHbWFVbcdLNTX98Y1TE1Xeoy9wE4j1dAZxF/ZYRRuHnM9 AKV3NRzzUKtZHLv/4oH6fIN5rBxmpn6rMB33KXH2iufoTHOOkEpNqgJP8rGdSPm8f0 rOXO0I+ab5oZTmRudXjOpb65zDgGKj5265mYdVSTmo9/7F4QZ3ruJ+rIM+3oi4hx6g 0p8diI0d/J1pIGrk+a53RoEGzPuXCJ+dxAIgDpQ4HDG78OtB3ALvBV/PjRQM8Nl9eh VvUZyYYjwYirQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vitor Soares , Francesco Dolcini , Nishanth Menon , Sasha Levin Subject: [PATCH 6.19 606/844] arm64: dts: ti: k3-am69-aquila: Change main_spi0/2 CS to GPIO mode Date: Sat, 28 Feb 2026 12:28:39 -0500 Message-ID: <20260228173244.1509663-607-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vitor Soares [ Upstream commit 78a123f45a7e9ac2a59f0eff8a37d31773e7a021 ] Hardware chip select does not work correctly on main_spi0 and main_spi2 controllers. Testing shows main_spi2 loses CS state during runtime PM suspend, while main_spi0 cannot drive CS HIGH when bus is idle. Use GPIO-based chip select for both controllers. Fixes: 39ac6623b1d8 ("arm64: dts: ti: Add Aquila AM69 Support") Cc: stable@vger.kernel.org Signed-off-by: Vitor Soares Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260112175350.79270-2-ivitro@gmail.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/ti/k3-am69-aquila.dtsi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-am69-aquila.dtsi b/arch/arm64/boot/d= ts/ti/k3-am69-aquila.dtsi index 0866eb8a6f348..5119baf62a4c2 100644 --- a/arch/arm64/boot/dts/ti/k3-am69-aquila.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am69-aquila.dtsi @@ -479,7 +479,7 @@ J784S4_IOPAD(0x0dc, PIN_OUTPUT, 0) /* (AM36) SPI0_D1 *= / /* AQUILA D17 */ /* Aquila SPI_2 CS */ pinctrl_main_spi0_cs0: main-spi0-cs0-default-pins { pinctrl-single,pins =3D < - J784S4_IOPAD(0x0cc, PIN_OUTPUT, 0) /* (AM37) SPI0_CS0 */ /* AQUILA D16 = */ + J784S4_IOPAD(0x0cc, PIN_OUTPUT, 7) /* (AM37) SPI0_CS0.GPIO0_51 */ /* AQ= UILA D16 */ >; }; =20 @@ -495,7 +495,7 @@ J784S4_IOPAD(0x0ac, PIN_OUTPUT, 10) /* (AE34) MCASP0_AX= R15.SPI2_D1 */ /* AQUILA /* Aquila SPI_1 CS */ pinctrl_main_spi2_cs0: main-spi2-cs0-default-pins { pinctrl-single,pins =3D < - J784S4_IOPAD(0x09c, PIN_OUTPUT, 10) /* (AF35) MCASP0_AXR11.SPI2_CS1 */ = /* AQUILA D9 */ + J784S4_IOPAD(0x09c, PIN_OUTPUT, 7) /* (AF35) MCASP0_AXR11.GPIO0_39 */ /= * AQUILA D9 */ >; }; =20 @@ -1204,6 +1204,7 @@ &main_sdhci1 { &main_spi0 { pinctrl-names =3D "default"; pinctrl-0 =3D <&pinctrl_main_spi0>, <&pinctrl_main_spi0_cs0>; + cs-gpios =3D <&main_gpio0 51 GPIO_ACTIVE_LOW>; status =3D "disabled"; }; =20 @@ -1211,6 +1212,7 @@ &main_spi0 { &main_spi2 { pinctrl-names =3D "default"; pinctrl-0 =3D <&pinctrl_main_spi2>, <&pinctrl_main_spi2_cs0>; + cs-gpios =3D <&main_gpio0 39 GPIO_ACTIVE_LOW>; status =3D "disabled"; }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 130C73F7B2D; Sat, 28 Feb 2026 17:42:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300567; cv=none; b=O72tjZVnXUp+661aaVAwzr8O9iODV0aFcyjfPvExZ69EBOniZKIaw05tQHEWlVnHZxFlAvzBCZZIz1M1sJC1h9SuBI0Z70egsJsjyx/94JLyFPmF0jkTIVsRiGMT0ciQlhjeXqzb6SQJV+X2xqk6UHUV41J+UTBaVX6wNyUPxSA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300567; c=relaxed/simple; bh=Zw7Fg1lIRwec7hh2wkmhaWdAesRtBhhfWAnFdWCw2CU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d83/IGog4zzHxPicXT0jTnEX8vl8A2bJK5NShaOn2EjgyopzAXhwSztpAiYvohP4t7bkZ/cO7lg7ht3//NNsCF4/54g/eSHls+JdLOaAP6zgOAgo9+iYdHOi5+WW8ZMcioDbESJFbbTwzNPA1cFhLdPJOZQ8eNQt790j3D7+sEA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=d6EJdq9r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="d6EJdq9r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49DB7C116D0; Sat, 28 Feb 2026 17:42:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300567; bh=Zw7Fg1lIRwec7hh2wkmhaWdAesRtBhhfWAnFdWCw2CU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d6EJdq9rohut0n/C+7VkMcw22t9Ov58jZRheRrZzjs9MJ+RAzTzaWNy5hYf2AK9xd 2nPru/Rc6yDkjSpHQYiM0f7+2LA7hqBFcrNb1trzNTURxfJmAZrOdZ5XNbLOc9TFQ1 fnmZYe3tli98ZxH8kSCVzOA6YwhhZL3LqdEWlUikD4WWUK3M5owSBHXlux1bX6udMB 3ZVvIou0rQSSl+9b2BvDXSZnb4CRhWT/wc4j3kcEqJiwC48XUNZBlAsC1cghhVv6/T kLPBWp62rFtomjLht5c8ckU2Z8REA+qSoA04TiLYEBeLh3iOkMtlzL0W6aO/iobWp9 qwkF493IAEDuQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vitor Soares , Francesco Dolcini , Nishanth Menon , Sasha Levin Subject: [PATCH 6.19 607/844] arm64: dts: ti: k3-am69-aquila-clover: Change main_spi2 CS0 to GPIO mode Date: Sat, 28 Feb 2026 12:28:40 -0500 Message-ID: <20260228173244.1509663-608-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vitor Soares [ Upstream commit 319fff9c7d620af83d8ab67050a54f63f16ae4e8 ] Change CS0 from hardware chip select to GPIO-based chip select to align with the base aquila device tree configuration. Fixes: 9f748a6177e1 ("arm64: dts: ti: am69-aquila: Add Clover") Cc: stable@vger.kernel.org Signed-off-by: Vitor Soares Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260112175350.79270-3-ivitro@gmail.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/ti/k3-am69-aquila-clover.dts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-am69-aquila-clover.dts b/arch/arm64/= boot/dts/ti/k3-am69-aquila-clover.dts index c816ba3bfbdf7..ec8ff45877157 100644 --- a/arch/arm64/boot/dts/ti/k3-am69-aquila-clover.dts +++ b/arch/arm64/boot/dts/ti/k3-am69-aquila-clover.dts @@ -208,7 +208,8 @@ &main_spi2 { pinctrl-0 =3D <&pinctrl_main_spi2>, <&pinctrl_main_spi2_cs0>, <&pinctrl_gpio_05>; - cs-gpios =3D <0>, <&wkup_gpio0 29 GPIO_ACTIVE_LOW>; + cs-gpios =3D <&main_gpio0 39 GPIO_ACTIVE_LOW>, + <&wkup_gpio0 29 GPIO_ACTIVE_LOW>; status =3D "okay"; =20 tpm@1 { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F32133F7B49; Sat, 28 Feb 2026 17:42:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300568; cv=none; b=Dpxjf3r4Vf7RVneH8aNptMs0PEj7od8nnY6QL/jOgjdp/uP7vg20pjr8o4uWjZ8WAGtvXb8TRbZGELnJp9DAaO8iG3Orqvi0sBwzjkJH/ImwrM0K/099SwZ6YD31owSR/9+PZyN9VVHTZ14NQBlHYknB7XXYFnL/fYgCKIvZMjY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300568; c=relaxed/simple; bh=la9/4Rbx3obCgEA23+q/BfF5J7ml9m6R8U3PHppltxs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EwLzg/pO73tGmygx6x0fUmuV9xWSKcdGWGDviBm/gWDd/NsUo1w31wtN9vJJTg/i8jsSwWIAzCn9zlFPLT+37qwWhf5pSX3er3D0lGRMCivSc+TsI7jggE0KGuFQqUUGuL5zs89rBuENPnf4pBNdZzsLhcdkVdPR1M0EXO0E2IA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=n0jchbKR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="n0jchbKR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38485C19423; Sat, 28 Feb 2026 17:42:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300567; bh=la9/4Rbx3obCgEA23+q/BfF5J7ml9m6R8U3PHppltxs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=n0jchbKRVSthZAer4jD0KsKa5FZrevbgVnN7JBYXl9Yjuxb2ZtWKCEUSDjenedapl awV79qQE0mvuSC+KDhzmWjKEyYUcOfSqj5l6jqIlIJbxh8YDiBUnaNPZ9WrDBNu6e0 OEtvRj8QbWmr6cXa6TMxSTczJc5ok5Ngm06Bx7tHF5S2R5Vi2kUxYvndnEa12h2QdY f5znNd8PkRdyOkz3CE/Kz05UJsay7m2Hoj6yCKZtMu/FDJKIiYFjeCCDrBGv8dTgmW lQXfSu3D3mA3075PoJJuaYTmbEiwx7DOp5fWMLn8WA/GSJOb9GcwqEtsSuv4z7gMo0 7H4G1J3NWE33g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yosry Ahmed , Maxim Levitsky , Sean Christopherson , Sasha Levin Subject: [PATCH 6.19 608/844] KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Date: Sat, 28 Feb 2026 12:28:41 -0500 Message-ID: <20260228173244.1509663-609-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yosry Ahmed [ Upstream commit 127ccae2c185f62e6ecb4bf24f9cb307e9b9c619 ] Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB. Fixes: cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of = guest state") Cc: Maxim Levitsky Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260110004821.3411245-2-yosry.ahmed@linux.d= ev Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/kvm/svm/svm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 4394be40fe78d..a58548b35b858 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -2099,12 +2099,13 @@ static int vmload_vmsave_interception(struct kvm_vc= pu *vcpu, bool vmload) =20 ret =3D kvm_skip_emulated_instruction(vcpu); =20 + /* KVM always performs VMLOAD/VMSAVE on VMCB01 (see __svm_vcpu_run()) */ if (vmload) { - svm_copy_vmloadsave_state(svm->vmcb, vmcb12); + svm_copy_vmloadsave_state(svm->vmcb01.ptr, vmcb12); svm->sysenter_eip_hi =3D 0; svm->sysenter_esp_hi =3D 0; } else { - svm_copy_vmloadsave_state(vmcb12, svm->vmcb); + svm_copy_vmloadsave_state(vmcb12, svm->vmcb01.ptr); } =20 kvm_vcpu_unmap(vcpu, &map); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE1D148C3F4; Sat, 28 Feb 2026 17:42:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300568; cv=none; b=I97eXglwaG0bnv6v998kA/BTb8vjlRpolB+RpssV7LMyVGylCyvkCQIxJ69xqWCGk3KdmBRJNXz8YYhp67dddPcSOqqEVkB93AnVzHjRrGZ8jTR3uwm7UDEKhhae193gbsBJpqTwwX9EJXUTpen5PTassRK9Ujak2Yn5tq5IbBc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300568; c=relaxed/simple; bh=yvWh03IwtFbL8rT7WKyGQQg09oQ6Fd3KWDBq24Cp3PA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AQOvY4WlECPflm878vtTv1sWytHTaKI34C7FTqx9elvRx1Qq2gUm0DaXplN0/JGJFTDrBPVQSkWUpVDJJWFlAPbQBFdXDuT7kQpzILIkENRWzwElO+xzJAa4c9E4oSQAl0gALIs6AXrICj3eOkJijS6yZMVj3qP1VsuEt5R5lmU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZMyB+tO8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZMyB+tO8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2662FC19424; Sat, 28 Feb 2026 17:42:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300568; bh=yvWh03IwtFbL8rT7WKyGQQg09oQ6Fd3KWDBq24Cp3PA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZMyB+tO86aTxC+WcJUt0ePioyJ8WD3qvjygnGK55Fxjlll7TIv8Dvtm2YrQagxoPD O77UMBDa1JAK0/lOTpjeLomqyiRRCnDhSyLBjMFI1g2BHTiH5vwiIgAa75B0ZF0PWZ zc9Ui2NQEf4NDgNGzmmHJHBs/Hj+L5FHmYBTnZmQF9+sPTmCdGn5VIiG45Tx623Jna URyWu2NWK7zC+q5+/0/QbutyTeG8AbBS1tqt1VSrR1icbTNYvWl0ATS/kikCk99+u1 gML70EnuWp41IWt2hAUwxqu6w8f0Y3GKnOw9v3OEJPT/t3vNKf9uxF+aViHangZ7Np +taULbPNNNAuw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Kevin Hilman , Sasha Levin Subject: [PATCH 6.19 609/844] bus: omap-ocp2scp: fix OF populate on driver rebind Date: Sat, 28 Feb 2026 12:28:42 -0500 Message-ID: <20260228173244.1509663-610-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit 5eb63e9bb65d88abde647ced50fe6ad40c11de1a ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251219110119.23507-1-johan@kernel.org Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/bus/omap-ocp2scp.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c index e4dfda7b3b102..eee5ad191ea9c 100644 --- a/drivers/bus/omap-ocp2scp.c +++ b/drivers/bus/omap-ocp2scp.c @@ -17,15 +17,6 @@ #define OCP2SCP_TIMING 0x18 #define SYNC2_MASK 0xf =20 -static int ocp2scp_remove_devices(struct device *dev, void *c) -{ - struct platform_device *pdev =3D to_platform_device(dev); - - platform_device_unregister(pdev); - - return 0; -} - static int omap_ocp2scp_probe(struct platform_device *pdev) { int ret; @@ -79,7 +70,7 @@ static int omap_ocp2scp_probe(struct platform_device *pde= v) pm_runtime_disable(&pdev->dev); =20 err0: - device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices); + of_platform_depopulate(&pdev->dev); =20 return ret; } @@ -87,7 +78,7 @@ static int omap_ocp2scp_probe(struct platform_device *pde= v) static void omap_ocp2scp_remove(struct platform_device *pdev) { pm_runtime_disable(&pdev->dev); - device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices); + of_platform_depopulate(&pdev->dev); } =20 #ifdef CONFIG_OF --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C51EB3F82F7; Sat, 28 Feb 2026 17:42:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300569; cv=none; b=PpA+36fC/LimtZDKkRZGEFiv9RCPiN7NKD1jSpLjFXpq4rVbRTC4LTZ1uGSl9PMNldDU02u76OoSWXfyyTvux8bbI4vDJ+vWId+8MhFkQZhYIr2TMUIbY2tCPx3Avm12N2jg+w8QBmvR9Tq/5aX31vIgn/tOzXvd8Vvp0hSH+6s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300569; c=relaxed/simple; bh=sERlK4cG0sQy2fgQwMEdNxFqpS9791B3HJ5q/wS0nV4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DfIlwefDR0vqty0Tjwaa5T6qe0sOAqKo3bi9pkQBbbBbbeLmqMIBIOMDo+pCgNe65HhCPYwiYhrLCDu+4uQphrmRt3/uxg5RSmuIviRUeKfQa9WogPpCoRTZuWmyQ4WuV7QTC64ztFrOcAXsSbWjb/nR8074z3+P0yJ1MI/dDQ4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QqodeeXY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QqodeeXY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2D95C116D0; Sat, 28 Feb 2026 17:42:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300569; bh=sERlK4cG0sQy2fgQwMEdNxFqpS9791B3HJ5q/wS0nV4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QqodeeXYwLV+BHzvZvtaq0VNc6+y9fzVYjZB1QyMcri6v09mYHS+MxM3mlGp+b6Q/ PF+4oF0M6ueo2mErilhRiWeYejb9J89qYcJ29HkeHUJ+c2gm69CgzyGsqBXJIQGBmq bc1Bx1GF+GABXykC5W0nwx9KKm3JfUosXQwg4mQOI6qWknSxVfmjG1FOG4stpt9dMK AP7NXznKaP7nrAJsoSA5o+x3kSpaZ/avYd61smLUKfysRw92phWoiuK810iYR3eOsJ PcgU2n/idWio67V7ljRpr3FbLWKoIkrdRQ9HIZJXAXYPj5AniDCrwaNAaDgf17FEwI 7CCywbN8gDXAw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Janne Grunau , Stephen Boyd , Neal Gompa , Sasha Levin Subject: [PATCH 6.19 610/844] clk: clk-apple-nco: Add "apple,t8103-nco" compatible Date: Sat, 28 Feb 2026 12:28:43 -0500 Message-ID: <20260228173244.1509663-611-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Janne Grunau [ Upstream commit ef9b3b4dbe767e4ac642a88dc0507927ac545047 ] After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,nco" anymore [1]. Use "apple,t8103-nco" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@ker= nel.org/ Fixes: 6641057d5dba ("clk: clk-apple-nco: Add driver for Apple NCO") Cc: stable@vger.kernel.org Acked-by: Stephen Boyd Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clk/clk-apple-nco.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/clk-apple-nco.c b/drivers/clk/clk-apple-nco.c index d3ced4a0f029e..434c067968bbc 100644 --- a/drivers/clk/clk-apple-nco.c +++ b/drivers/clk/clk-apple-nco.c @@ -320,6 +320,7 @@ static int applnco_probe(struct platform_device *pdev) } =20 static const struct of_device_id applnco_ids[] =3D { + { .compatible =3D "apple,t8103-nco" }, { .compatible =3D "apple,nco" }, { } }; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D53F03F8317; Sat, 28 Feb 2026 17:42:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300570; cv=none; b=Ic7U+nUeYlcIUHCPsl3a7qF+dZTGFBjuYf7G3gxn0Spm43Kx7bI3UAo7csBVDiT0oa1MfykIOHLA4k8zH6BU4i7ZoL9dY9FEKdbyW//T7VYWq9QWhfWBXu7qfNfWw4KTirI+exylbGMZf4gGj6fziic5ixT1g/W5slCU3lnkcVk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300570; c=relaxed/simple; bh=l5zdJmYmZB3TFNe0r0xjIkhgAOkDij8IZ8SN5tJNwx0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YYXGYsI9d4vPIJ1a9sNdUbemns6GnZfSWbBkdQYy3hNyvAeDlpNthUrVhTTGQlvaL3tevvtKP1/Fnle1uHnmGb56xFWPr/aiAzr6kev0pEkYFL/pcQ5JScdgx6aBhmP/LPe798xYs+gsNPGiMY0Ue5x2heBCiZa1SGxqG00tiGQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EwOWe8Oj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EwOWe8Oj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2DD5C19423; Sat, 28 Feb 2026 17:42:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300570; bh=l5zdJmYmZB3TFNe0r0xjIkhgAOkDij8IZ8SN5tJNwx0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EwOWe8OjK9iYAhtNua9FTuSL8ptnEy65xRLgVBrgq7/vkhCy8fOHW24v2uSYwBHSt FSXu8pme8S7u9om6yejdFY1F/tPea42hO0NV2QMSKhyQmbH72S7GNLt2DCR6Aabj6K NL6x0ozAjJL6kfHBUNW+Nw6eOSMFKV4qhH35EaEY3YG5HfAprnDlTI+ff59zqKk6cf m2k0DOngmceTXXBAVm7JXpI2wskAQfZnAxmX0f5wpAaQ2QByO7nZUf8jPt310YZQws Wgc+KjP9kZGsdBrLBmP25H01qU8JYOOvfbj5YSPBGaRX6B6gsOe16tBvQPHhPdx7qE zKq99z3qN9TFg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shawn Lin , Detlev Casanova , Chaoyi Chen , Marco Schirrmeister , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.19 611/844] soc: rockchip: grf: Fix wrong RK3576_IOCGRF_MISC_CON definition Date: Sat, 28 Feb 2026 12:28:44 -0500 Message-ID: <20260228173244.1509663-612-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shawn Lin [ Upstream commit 3cdc30c42d4a87444f6c7afbefd6a9381c4caa27 ] RK3576_IOCGRF_MISC_CON is IOC_GRF + 0x40F0, fix it. Fixes: e1aaecacfa13 ("soc: rockchip: grf: Add rk3576 default GRF values") Cc: stable@vger.kernel.org Cc: Detlev Casanova Signed-off-by: Shawn Lin Reviewed-by: Chaoyi Chen Tested-by: Marco Schirrmeister Link: https://patch.msgid.link/1768524932-163929-2-git-send-email-shawn.lin= @rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/soc/rockchip/grf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c index 27bfa09ff2516..8974d1c6b35dc 100644 --- a/drivers/soc/rockchip/grf.c +++ b/drivers/soc/rockchip/grf.c @@ -146,7 +146,7 @@ static const struct rockchip_grf_info rk3576_sysgrf __i= nitconst =3D { .num_values =3D ARRAY_SIZE(rk3576_defaults_sys_grf), }; =20 -#define RK3576_IOCGRF_MISC_CON 0x04F0 +#define RK3576_IOCGRF_MISC_CON 0x40F0 =20 static const struct rockchip_grf_value rk3576_defaults_ioc_grf[] __initcon= st =3D { { "jtag switching", RK3576_IOCGRF_MISC_CON, FIELD_PREP_WM16_CONST(BIT(1),= 0) }, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DEF9C3F8AE6; Sat, 28 Feb 2026 17:42:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300571; cv=none; b=EXMXLiKvatVb1krmswBsFb6/9ZslrsJ+uOKIX+fuOhlBFYhXAc5qf6RkkvxEPTkz1+iDEIWaRjWFfRxgPuRrndV/bzZVWvlsUd+N9t5/tLcfbadwNoK8vvM4Fbiw5Sh5UvqfoeYQRzkLjtOSXJ0fZPVliY/QYKCk1/R6LIgqEbA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300571; c=relaxed/simple; bh=9urgeHaNSPRzjUKogr5ACw2JNEW7dKjz9dZ2baWpE3A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FrivbqDb8KQmAgWUV0cEb66J6AyuTMVteKFjSNJEWLBp4NMhui2bSrmQ0Bh8mQqSZZ1ag9MdWEDtMe0hNUDaKLs+JAHbhuJYbtc29wJUDrctiLgBsB2IeogH1fHXFIo6W6Zr22UpkrlSN2u7FtUcPTuIicRDvtilpHkjxgIRd3k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OAg++FY4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OAg++FY4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 088AEC116D0; Sat, 28 Feb 2026 17:42:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300571; bh=9urgeHaNSPRzjUKogr5ACw2JNEW7dKjz9dZ2baWpE3A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OAg++FY42SHNcU+hZdgkwdj2bFHvrPmZILK6I0djb9YiHUQoyQKy9Ankr3BhXY4L5 X81NjUiMD0mJ8ZbPlv1hDeokrytmqRU/MDoE6RYhXPVJEpjzehD2wUee3kpBsbF+mf puCOa6UfKIvgwib3o1MMgHIc/0es/f7zuvkihRhQPBoa41iGTQ9Wf+Xq/Pk6hjGSzm bvgPw72I94Lrg0+VO7UrOfqBcs2mcZqVdfKFhFoM9QkMLXmEVHV/S04golakNI6hoX bu3MNcJSaFjDXXaIX35fJDbGqc7kUOCmTtPYXUeRUGmgRI16nBjETo/vHkxZzXorLn OSo2vC5T2RbQg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shawn Lin , Detlev Casanova , Marco Schirrmeister , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.19 612/844] soc: rockchip: grf: Support multiple grf to be handled Date: Sat, 28 Feb 2026 12:28:45 -0500 Message-ID: <20260228173244.1509663-613-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shawn Lin [ Upstream commit 75fb63ae031211e9264ac888fabc2ca9cd3fcccf ] Currently, only the first matched node will be handled. This leads to jtag switching broken for RK3576, as rk3576-sys-grf is found before rk3576-ioc-grf. Change the code to scan all the possible node to fix the problem. Fixes: e1aaecacfa13 ("soc: rockchip: grf: Add rk3576 default GRF values") Cc: stable@vger.kernel.org Cc: Detlev Casanova Signed-off-by: Shawn Lin Tested-by: Marco Schirrmeister Link: https://patch.msgid.link/1768524932-163929-3-git-send-email-shawn.lin= @rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/soc/rockchip/grf.c | 55 +++++++++++++++++++------------------- 1 file changed, 27 insertions(+), 28 deletions(-) diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c index 8974d1c6b35dc..04937c40da471 100644 --- a/drivers/soc/rockchip/grf.c +++ b/drivers/soc/rockchip/grf.c @@ -217,34 +217,33 @@ static int __init rockchip_grf_init(void) struct regmap *grf; int ret, i; =20 - np =3D of_find_matching_node_and_match(NULL, rockchip_grf_dt_match, - &match); - if (!np) - return -ENODEV; - if (!match || !match->data) { - pr_err("%s: missing grf data\n", __func__); - of_node_put(np); - return -EINVAL; - } - - grf_info =3D match->data; - - grf =3D syscon_node_to_regmap(np); - of_node_put(np); - if (IS_ERR(grf)) { - pr_err("%s: could not get grf syscon\n", __func__); - return PTR_ERR(grf); - } - - for (i =3D 0; i < grf_info->num_values; i++) { - const struct rockchip_grf_value *val =3D &grf_info->values[i]; - - pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__, - val->desc, val->reg, val->val); - ret =3D regmap_write(grf, val->reg, val->val); - if (ret < 0) - pr_err("%s: write to %#6x failed with %d\n", - __func__, val->reg, ret); + for_each_matching_node_and_match(np, rockchip_grf_dt_match, &match) { + if (!of_device_is_available(np)) + continue; + if (!match || !match->data) { + pr_err("%s: missing grf data\n", __func__); + of_node_put(np); + return -EINVAL; + } + + grf_info =3D match->data; + + grf =3D syscon_node_to_regmap(np); + if (IS_ERR(grf)) { + pr_err("%s: could not get grf syscon\n", __func__); + return PTR_ERR(grf); + } + + for (i =3D 0; i < grf_info->num_values; i++) { + const struct rockchip_grf_value *val =3D &grf_info->values[i]; + + pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__, + val->desc, val->reg, val->val); + ret =3D regmap_write(grf, val->reg, val->val); + if (ret < 0) + pr_err("%s: write to %#6x failed with %d\n", + __func__, val->reg, ret); + } } =20 return 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E39C93F8AFB; Sat, 28 Feb 2026 17:42:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300573; cv=none; b=QM8p+kuOiIHk/G5nCiXVvbo8XGCYefA7JWyburZAR5rfhqPyZ0uI9TbcK8Dltbak8fh37m0C6kc/Tl071ybfKZ49ouMpM9nK3G65DAU1s1/3PblKck81XPPo07bT+Ca4BFo7mGSOOd6hQLBLd5zEGFohqBNhdO0R2iQNKC71RPE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300573; c=relaxed/simple; bh=OeBiOH2MaUBz2DQS4qmVwqoVgLtnGrd+D6Gji32gUUA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jMZQoXjWVbcPPkXxAgC3L/dS+wB0X4kZe57rtmYk3BCStO3iH8qzv9TuoTNDEiIfYg7gaGcJKoR0rBlMOvhc2n2PJxCvl1/hc6PcSA58vqidds4SqODJnrcPzqwoSqmcW6E8Q744OWyZK4l2I/lo+TIqfFS6Qa349Lbzkt6e22E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cPZogpyt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cPZogpyt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 116AAC116D0; Sat, 28 Feb 2026 17:42:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300572; bh=OeBiOH2MaUBz2DQS4qmVwqoVgLtnGrd+D6Gji32gUUA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cPZogpytS9nfPmIkXntRWjzSjJUkxtTLiFdsqgXPBziMRGoPzCZmm0OOCSfJOMFM6 /fSo+L5ECT9dr0D+5hRBFRC414aK2K5pD4DTlt/s4xhO65ngN9MtaYZ2yUmC+mWqiT FSvB6OC37GKcBGM0ieGugYYUAkiAM3cH+OnodoETuYqtqPUPso3YUzlv3TbNDdoUUm wTUY1WGF05JJTwcQ8sIAw86VhTgyAbEsKQsu7CR8KxqmEZOQrFxHDsRxX3cr7T1A0p Xynsw1bz4sdaSSaKjrbWHZZ4M5bUy+0EtiZpFcbnH192ricU8v+UtdA1qrgm3UcSpq HVgU2vLr+jJoA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alain Volmat , Stable@vger.kernel.org, Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 613/844] media: stm32: dcmipp: avoid naming clock if only one is needed Date: Sat, 28 Feb 2026 12:28:46 -0500 Message-ID: <20260228173244.1509663-614-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alain Volmat [ Upstream commit 2f130245f2143fa8f4da77071f844911d2c69319 ] When DCMIPP requires only a single clock (kclk), avoid relying on its name to obtain it. The introduction of MP25 support added the mclk, which necessitated naming the first clock kclk. However, this breaks backward compatibility with existing MP13 device trees that do not specify clock names. Fixes: 686f27f7ea37 ("media: stm32: dcmipp: add core support for the stm32m= p25") Signed-off-by: Alain Volmat Cc: Stable@vger.kernel.org # 6.14.x: 7f487562af49 media: stm32: dcmipp: cor= rect ret type in dcmipp_graph_notify_bound Cc: Stable@vger.kernel.org # 6.14.x: c715dd62da30 media: stm32: dcmipp: add= has_csi2 & needs_mclk in match data Cc: Stable@vger.kernel.org # 6.14.x: Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c b/d= rivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c index 1b7bae3266c8d..49398d0777646 100644 --- a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c +++ b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c @@ -526,7 +526,12 @@ static int dcmipp_probe(struct platform_device *pdev) return ret; } =20 - kclk =3D devm_clk_get(&pdev->dev, "kclk"); + /* + * In case of the DCMIPP has only 1 clock (such as on MP13), the + * clock might not be named. + */ + kclk =3D devm_clk_get(&pdev->dev, + dcmipp->pipe_cfg->needs_mclk ? "kclk" : NULL); if (IS_ERR(kclk)) return dev_err_probe(&pdev->dev, PTR_ERR(kclk), "Unable to get kclk\n"); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0D1C3F8B1B; Sat, 28 Feb 2026 17:42:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300573; cv=none; b=dRI+C7Y3knbh9zZe3T0+YXmfNRSaE3sIXlJsFMreaUOjo5lu/BLtx64ixyR9ukQa2Cg+wwhICvA1gjq4aUp6R+IqKr+lrGLODEzhyhBQIZ50xKxZoSPXVgkhApHKYzZdNtV594T+EmwMO/Oykz2yWh85pOPhQF9iDaAZOcQOQw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300573; c=relaxed/simple; bh=dTle06lUXDk7SlT5K/JGW0wMzFUKzTs8xoOQno5za78=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KDYENm5m2FVNrEX3+5jIz0o67pc7OGuWpPMLRNGQVU5BVBLqnGz4lQTvMMQdLvLJzjkP3JmrJk7Dveu7XvOwoIoR/Qe3FZjonQtV1o1WdV2/sXMyy57ABBQZesd0IAcUF1A94IIveQ8EplXQ8YYu381d+cLSNzdTDQ9eDdM+f38= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m6JVk3KG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m6JVk3KG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1589DC19423; Sat, 28 Feb 2026 17:42:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300573; bh=dTle06lUXDk7SlT5K/JGW0wMzFUKzTs8xoOQno5za78=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m6JVk3KGXALh0MnzMQ3j0DOvS9tfniQbw4MT/Yn+6GgtMSTRM1D8E+htETv0PyTSb N6qBkDSJ+fl4PwKS9j/1lAvSd/LVL0FiIBETpRkwXcaZc2KFTokoxdXO7Lg4dy1sQR RpD4WetflKdEcg9gMgIrm3ccbLYv/N8yX++u3wY6LCRX6oJs50SPljVBZkA/9ndjJq CRilyXCf7D6msEsisAdansyv7UaMIzZJ54t1Ugpc5e/dOwFEGlVm8WGqMCweFe7d3X wo9KqZ2v48hZe+6dJtn96WDKB2emPBwBIXvHPsX4d61I/VjOkALro1JmuVWY7TrOm+ Rdta4tuB68agg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alain Volmat , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 614/844] media: stm32: dcmipp: bytecap: clear all interrupts upon stream stop Date: Sat, 28 Feb 2026 12:28:47 -0500 Message-ID: <20260228173244.1509663-615-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alain Volmat [ Upstream commit 222f1279edd9008ee35b62de156ddac84e31443c ] Ensure that there are no pending interrupts after we have stopped the pipeline. Indeed, it could happen that new interrupt has been generated during the stop_streaming processing hence clear them in order to avoid getting a new interrupt right from the start of a next start_streaming. Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface dr= iver") Cc: stable@vger.kernel.org Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c = b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c index 1c1b6b48918ee..b18e273ef4a3e 100644 --- a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c +++ b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c @@ -512,6 +512,9 @@ static void dcmipp_bytecap_stop_streaming(struct vb2_qu= eue *vq) /* Disable pipe */ reg_clear(vcap, DCMIPP_P0FSCR, DCMIPP_P0FSCR_PIPEN); =20 + /* Clear any pending interrupts */ + reg_write(vcap, DCMIPP_CMFCR, DCMIPP_CMIER_P0ALL); + spin_lock_irq(&vcap->irqlock); =20 /* Return all queued buffers to vb2 in ERROR state */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BEFDA3F932C; Sat, 28 Feb 2026 17:42:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300574; cv=none; b=KgUzrLg7ch6vA72fzC9DZkgzoTqhAp0tdVlleP+QCGIlfsQUTrDUM3DCF0MMRODFRMY7ohgfEa14DFWJb/pYyqSq9IhDzjqiwPCiNffFQaLfuWeWTq/ad4ZBulZzd28wEAKu7aBgK40rsq4wUyG9FkSmMdnXlALZehPEds3QRS4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300574; c=relaxed/simple; bh=AILmNc2NOtZL77kxlQkF82GxIgCfmUK+qQkkpyrH21E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UtfuwcOeRAnu4j0uRK+xlHIk6Z4vzIC4l6vlgbo5EcI/GRDXfvcHOnqdH7K8ekyPfcqOXvOgq5M/em73S+3GU0aMVmcxHnrDggtUL2Rgby+KXthH0pPPDo3+q8vIAiSHC+3R5eWgYWeDFTciJjIvyLskHnKZZSZutFRjL57Wj5U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gsk51/MS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gsk51/MS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00ACEC19423; Sat, 28 Feb 2026 17:42:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300574; bh=AILmNc2NOtZL77kxlQkF82GxIgCfmUK+qQkkpyrH21E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gsk51/MSJpTkmM/pN7W+9F9+CNImOTiLNICTPxfUeCFlHLhouWrDAREtNqIDul8AG 2eQ0F8avaZCZZtdS9TMiNcBoFBIJ/i68dHx9AqLDUyBo0pYjMSgguggF7De4f7/68d DymzeQlS2wnJmSb+96+P3xevf+rBq3fHnJyIi8ImVpCGwC9Or4IvKHMAfxC2u4zXFj ayekJOG1QnR/HJT108XXNzNjLmmVMVNeMOJObfkdd1v/TuAvbXjYWtKn3QT0VWU1HV FH9kIPw3QI9r/NczTmXZv3w9DFXO+sjJTL6sE79qSzwvJBRdWkWRAq2mN9LZrm0xIK i0FHdRj8yDecA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alain Volmat , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 615/844] media: stm32: dcmipp: byteproc: disable compose for all bayers Date: Sat, 28 Feb 2026 12:28:48 -0500 Message-ID: <20260228173244.1509663-616-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alain Volmat [ Upstream commit 3363aa2640f1738ad7fc56ea56f5e0301ad97196 ] Avoid possibility to perform compose on all frames which mbus code is within the bayer range or jpeg format. Fixes: 822c72eb1519 ("media: stm32: dcmipp: add bayer 10~14 bits formats") Cc: stable@vger.kernel.org Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../media/platform/st/stm32/stm32-dcmipp/dcmipp-byteproc.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-byteproc.c= b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-byteproc.c index db76a02a1848a..ec1d773d5ad12 100644 --- a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-byteproc.c +++ b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-byteproc.c @@ -130,11 +130,8 @@ static void dcmipp_byteproc_adjust_compose(struct v4l2= _rect *r, r->left =3D 0; =20 /* Compose is not possible for JPEG or Bayer formats */ - if (fmt->code =3D=3D MEDIA_BUS_FMT_JPEG_1X8 || - fmt->code =3D=3D MEDIA_BUS_FMT_SBGGR8_1X8 || - fmt->code =3D=3D MEDIA_BUS_FMT_SGBRG8_1X8 || - fmt->code =3D=3D MEDIA_BUS_FMT_SGRBG8_1X8 || - fmt->code =3D=3D MEDIA_BUS_FMT_SRGGB8_1X8) { + if (fmt->code >=3D MEDIA_BUS_FMT_SBGGR8_1X8 && + fmt->code <=3D MEDIA_BUS_FMT_JPEG_1X8) { r->width =3D fmt->width; r->height =3D fmt->height; return; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C20B53F934D; Sat, 28 Feb 2026 17:42:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300575; cv=none; b=nB4vEZLH5i05vgsvS4NXNOTZU16fukcDPdCZpHacpQxMARLQ+9HTiePFtBdnZ3P9w2JZQAO3gWV89VSFFDKcCUEBakfMCM/P0jIkg9kCsK+O7dqKEGiOiFs0UWVwrye6Y4JTr4zxeZt2mRNiclxiaZHi8p7SasVGzyGEZyksGpU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300575; c=relaxed/simple; bh=s3yDxUuIIIvd2yaG41DZabKKL38dVe+r2GKckN3hqmE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TYzKx1PFyGfkqLDzE+b/LJvZ8hK61lhvHPbzGmSMWwbVB9wEQEq5gpDLSPGTXuNIN9rWhpnH/mRcfhQW84RlopKTnux/7G5P75LEH2H55uDNMBQVYNv2YlSoq5xk5Osik9HFhvJbnGpCt68WDVm+8lnxkOdp0ThMHrikQ7Zg9wA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bVTYAUcQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bVTYAUcQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3A2BC19425; Sat, 28 Feb 2026 17:42:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300575; bh=s3yDxUuIIIvd2yaG41DZabKKL38dVe+r2GKckN3hqmE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bVTYAUcQkf2qVItTCgig5BH3VnQ5tZiA/+SL+LhzPvhiepGa8TD9KPYRox6DmWCAP 50hfBdHQxSKmfIAkZRMqyv7sz+kxg16Xb1XxrbCvuuMCa8Lsq0wvCbOHIZjRXWprJA hus8roFgfDkFNetXn7zRCsssLqtFDkmRP6VdUdAOkUbkt1l20FDc/rczqAUJJ6JZYU QOlSRP7gnoiMh28HxkWEBdp8vZ8pynhNjSkyqQC2mHD8cHci9O6j/kw5u/RaW5Tnr9 xCuiMCkCiqS0te++yMRLDzdFHwoDqnnu4U1HjYK7HJWS//3cd+WCXi2sArHSPe2A+G /QrAt4atm9pVA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mehdi Djait , Hans de Goede , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 616/844] media: i2c: ov01a10: Fix digital gain range Date: Sat, 28 Feb 2026 12:28:49 -0500 Message-ID: <20260228173244.1509663-617-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mehdi Djait [ Upstream commit 91848c99ed6a98daf77f4cb7d44cf3f13bc6998f ] Digital gain wraps-around at the maximum of 16838 / 0x3fff. Fix the maximum digital gain by setting it to 0x3fff. Signed-off-by: Mehdi Djait Reviewed-by: Hans de Goede Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/i2c/ov01a10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index 3ad516e4d3698..c1a7373a6311c 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -57,7 +57,7 @@ #define OV01A10_REG_DIGITAL_GAIN_GR 0x3513 #define OV01A10_REG_DIGITAL_GAIN_R 0x3516 #define OV01A10_DGTL_GAIN_MIN 0 -#define OV01A10_DGTL_GAIN_MAX 0x3ffff +#define OV01A10_DGTL_GAIN_MAX 0x3fff #define OV01A10_DGTL_GAIN_STEP 1 #define OV01A10_DGTL_GAIN_DEFAULT 1024 =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D867048C415; Sat, 28 Feb 2026 17:42:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300576; cv=none; b=s/JrcLpEx5Kkw1qsttCC9sQ6NbiJ6vfYEmJeGS6wMgWYtSWJ31kkxQSnUbgLmrurwy0U14l3CB1v1pB0uNdBu3pu04QaztczDRttark6HwEsgQNvL2XTDNoQX4EPUBdYHmAZ5mOZHrSTFGxK7z15jasr3r3VIOBzuoVTOMqAwVQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300576; c=relaxed/simple; bh=yTTyB47Ztk/N1dRwdYvfAmvLvNR6akIwIhIhlTILdN4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DIhmJs+3zER8WWeJAw9BuQnkOI+CRpRfqEoePmoCPYmSBV8qfGVZqOHr9GgRkINJi5ooz29b/SX7Q4ParY+MrEEt1lk4mnzBNKlNgRlScLZ+EfJ+apGQcVkTqcoUZnKUSnPK/H1PjyIDcQWH6uglTah74aLOBQZJPW4ZiWDY7gk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Cn5jF9OA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Cn5jF9OA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8FDFC19423; Sat, 28 Feb 2026 17:42:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300576; bh=yTTyB47Ztk/N1dRwdYvfAmvLvNR6akIwIhIhlTILdN4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Cn5jF9OAdSXd3Fj6jnMGJUDe46zpChAconJcJcylfK6p1BP+9Wh0bqn+nFlgSrWPp d8XwgISHglNSK7c8PUynZh0QW/RcP6xM03BnyZaIgzJmJQaoCPRwU53vKt0bTp+L3m f5mDiSZFjkSSU7JvVQPjBnxK2yx9jZiFNEzqOpnc+M1FauL0LPGGOzFO533I/QWERg yEuVX3MTxvwCQH+BSV2WOETgwhzHvEXoC3V2Z/tCoVd04/Wd6sN0vlMr4jWyQd76/I SvNWb5GQQxUScbtdcX/sKj5rxgdB9qU4gJGiuZRjrjZH9UG99DcQvXLozL60ZbtGqG bb5A8yXRUgXJQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shawn Lin , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.19 617/844] arm64: dts: rockchip: Fix SD card support for RK3576 EVB1 Date: Sat, 28 Feb 2026 12:28:50 -0500 Message-ID: <20260228173244.1509663-618-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shawn Lin [ Upstream commit 7226664bf952c4cfddccd74b154a7d994608d153 ] When runtime suspend is enabled, the associated power domain is powered off, which resets the registers, including the power control bit. As a resu= lt, the card loses power during runtime suspend. The card should still be able to process I/O with the help of mmc_blk_mq_rw_recovery(), which is suboptim= al. To address this issue, we must use vmmc-supply with a GPIO based method to maintain power to the card. Also, add cd-gpios method to make hot-plug work correctly during idle periods. Fixes: f135a1a07352 ("arm64: dts: rockchip: Add rk3576 evb1 board") Cc: stable@vger.kernel.org Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1768524932-163929-5-git-send-email-shawn.lin= @rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../boot/dts/rockchip/rk3576-evb1-v10.dts | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts b/arch/arm64/= boot/dts/rockchip/rk3576-evb1-v10.dts index db8fef7a4f1b9..ffe55f970f461 100644 --- a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts +++ b/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts @@ -223,6 +223,18 @@ vcc_3v3_s0: regulator-vcc-3v3-s0 { vin-supply =3D <&vcc_3v3_s3>; }; =20 + vcc3v3_sd: regulator-vcc-3v3-sd { + compatible =3D "regulator-fixed"; + enable-active-high; + gpios =3D <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>; + pinctrl-names =3D "default"; + pinctrl-0 =3D <&sdmmc_pwren>; + regulator-name =3D "vcc3v3_sd"; + regulator-min-microvolt =3D <3300000>; + regulator-max-microvolt =3D <3300000>; + vin-supply =3D <&vcc_3v3_s0>; + }; + vcc_ufs_s0: regulator-vcc-ufs-s0 { compatible =3D "regulator-fixed"; regulator-name =3D "vcc_ufs_s0"; @@ -810,6 +822,12 @@ pcie0_rst: pcie0-rst { }; }; =20 + sdmmc { + sdmmc_pwren: sdmmc-pwren { + rockchip,pins =3D <0 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + usb { usb_host_pwren: usb-host-pwren { rockchip,pins =3D <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>; @@ -851,11 +869,15 @@ &sdmmc { bus-width =3D <4>; cap-mmc-highspeed; cap-sd-highspeed; + cd-gpios =3D <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>; disable-wp; max-frequency =3D <200000000>; no-sdio; no-mmc; + pinctrl-names =3D "default"; + pinctrl-0 =3D <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_det &sdmmc0_bus4>; sd-uhs-sdr104; + vmmc-supply =3D <&vcc3v3_sd>; vqmmc-supply =3D <&vccio_sd_s0>; status =3D "okay"; }; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D1F83F9AB6; Sat, 28 Feb 2026 17:42:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300577; cv=none; b=BGyXhuuak5wxd5c++6Ag1YZ3lpDLWenNnbpJVmB1nQirR6m1gd3zBeGfdufmsfbD6CvUsQsb0b9ggwUazX4TgNzSFeXSBechL6xnKhjuBUrr5FodyUx6sMz1yK9GikrSSf6TGiFMX7eBfxAI8GagUh3h5ve1Ew8m4Awb0fqG+/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300577; c=relaxed/simple; bh=KoRy7AwJwTQ3Et72oxY0JpXKA9pYLYIwNuspsI8av20=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QvYY/YzjG3ogItOdwfHLVD4bZ4FZX/QCms+1CWOynvrzWcY8Iz+bkzl0pZ09f4BrmhxTAq+7Am4YCRqgtGhNM0bSnMNZOHhrbovspjDhmKlvk2WCMh2RdJmznqWZIL7hz31fLThhqkKWBZX+4s3EPuoMENaddLQi890IPvCVZMI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wb+3c5v4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Wb+3c5v4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C37EAC19424; Sat, 28 Feb 2026 17:42:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300577; bh=KoRy7AwJwTQ3Et72oxY0JpXKA9pYLYIwNuspsI8av20=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Wb+3c5v4FeBwfpLRSsagiz69qh720LR9o19Daf44jdbR3a0nAWL/mB53O2ftv6Brw ePz9WfO3MzF2dgEk+5Zz1Ew1dkU/HkoXS8NBoiue+H0+i8XqzCBQ+YMvgEv8Kf5D6J 58590scu1GISOO1GNQt2ycv5DKFHXcsjazEnlvEW5OBsvtsDHAjMb0hPaQfiQSOrcI lH669dAQf47UPdqEOhtxzmCfZC5Tzn8905dhE8gqSTpP+aU9qUqSEPxPDQdAsBAywy bkFu8vvKGhg2Uzl9sTzWet9ypZM4dKjuULAFqLh9dfV2v1kdRhcohk8x6FodBGLZG2 aAp7vqLgjNTyg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shawn Lin , Marco Schirrmeister , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.19 618/844] arm64: dts: rockchip: Fix SD card support for RK3576 Nanopi R76s Date: Sat, 28 Feb 2026 12:28:51 -0500 Message-ID: <20260228173244.1509663-619-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shawn Lin [ Upstream commit a9c1acebfe0484343a443d082e039ca77186ed22 ] When runtime suspend is enabled, the associated power domain is powered off, which resets the registers, including the power control bit. As a resu= lt, the card loses power during runtime suspend. The card should still be able to process I/O with the help of mmc_blk_mq_rw_recovery(), which is suboptim= al. To address this issue, we must use vmmc-supply with a GPIO based method to maintain power to the card and store valid tuning phases. Also, add cd-gpios method to make hot-plug work correctly during idle periods. Fixes: 7fee88882704 ("arm64: dts: rockchip: Add devicetree for the Friendly= Elec NanoPi R76S") Cc: stable@vger.kernel.org Signed-off-by: Shawn Lin Tested-by: Marco Schirrmeister Link: https://patch.msgid.link/1768524932-163929-6-git-send-email-shawn.lin= @rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../boot/dts/rockchip/rk3576-nanopi-r76s.dts | 23 ++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts b/arch/arm= 64/boot/dts/rockchip/rk3576-nanopi-r76s.dts index 31fbefaeceab4..7ec27b05ff10e 100644 --- a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts +++ b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts @@ -192,6 +192,18 @@ vcc_3v3_s0: regulator-vcc-3v3-s0 { regulator-name =3D "vcc_3v3_s0"; vin-supply =3D <&vcc_3v3_s3>; }; + + vcc3v3_sd: regulator-vcc-3v3-sd { + compatible =3D "regulator-fixed"; + enable-active-high; + gpios =3D <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>; + pinctrl-names =3D "default"; + pinctrl-0 =3D <&sdmmc_pwren>; + regulator-name =3D "vcc3v3_sd"; + regulator-min-microvolt =3D <3300000>; + regulator-max-microvolt =3D <3300000>; + vin-supply =3D <&vcc_3v3_s0>; + }; }; =20 &combphy0_ps { @@ -726,6 +738,12 @@ pcie1_perstn: pcie1-perstn { }; }; =20 + sdmmc { + sdmmc_pwren: sdmmc-pwren { + rockchip,pins =3D <0 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + usb { usb_otg0_pwren_h: usb-otg0-pwren-h { rockchip,pins =3D <0 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>; @@ -751,11 +769,14 @@ &sdmmc { bus-width =3D <4>; cap-mmc-highspeed; cap-sd-highspeed; + cd-gpios =3D <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>; disable-wp; no-mmc; no-sdio; + pinctrl-names =3D "default"; + pinctrl-0 =3D <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_det &sdmmc0_bus4>; sd-uhs-sdr104; - vmmc-supply =3D <&vcc_3v3_s3>; + vmmc-supply =3D <&vcc3v3_sd>; vqmmc-supply =3D <&vccio_sd_s0>; status =3D "okay"; }; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7E11B3F9AD2; Sat, 28 Feb 2026 17:42:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300578; cv=none; b=gftcsCWVDTisU2ZY9wPvTpCtkRauKeOs3gip6VhzoQfKKAI7R6zSf9/no0RKlsn+gC+nepiX8sJZFG1GCas0N72foAur0CoEdqiaqqrjoku9mYK91sY0kHKAeQYxBrHYwtbGTI4YZ5TNCB3pFX3XlO6DCw40Jwi0JuCPl2+Xcms= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300578; c=relaxed/simple; bh=hA+DYSRYKtLUOo1IIuD02yY0aD61JcSOLCGFa/5OB4Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bIdTdT5Uzn64RIkzyYPgkVHBfcWDwBtgHE3isxXWhlgykYh2YhN2nOTLvM3Lqza+xepSFoEt19U3OWF2o7FGKcDyXNZIz5YixtTPiHmYUP9bLqVAKMAZHz9qekOHo3H7ZgagdAtd0wf9LqpR25aogbTTayL9qXpqjSq8GO5ivLc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uvIY/0eE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uvIY/0eE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4986C19423; Sat, 28 Feb 2026 17:42:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300578; bh=hA+DYSRYKtLUOo1IIuD02yY0aD61JcSOLCGFa/5OB4Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uvIY/0eE9RkbVRPPCDrUuQYWjph7GBTAl8q98TAPNSgnwHBpQiCuhqjxk+zmJ/o4Q mF1q6AN/gVtP+wXFDT/7I+DBid4L/g5Pe6zp8ZPHTvXGJg30Mr87D+7xxR7ZOzkwfU PtB4VtG7+FnXKmzO3kGVS4n/0+FI9ueMLbEIHOgXh473xMiw7F2fYlghBaFcefD2vO Opw3gRD8JsFQlZYwMgNi3wfGACbYvYAwgL4hkXB4h6boIEfpasze6UT+TyimfPe6K4 4gagxc6Cc0BZEtuwgQcTnmieGpBkwtYJEI0rfWIFsFTfFYTJcu7+lxmxBKSXAM+34g QBa2rhg9FbBEQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Oleg Nesterov , Paulo Andrade , "Peter Zijlstra (Intel)" , Sasha Levin Subject: [PATCH 6.19 619/844] x86/uprobes: Fix XOL allocation failure for 32-bit tasks Date: Sat, 28 Feb 2026 12:28:52 -0500 Message-ID: <20260228173244.1509663-620-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Oleg Nesterov [ Upstream commit d55c571e4333fac71826e8db3b9753fadfbead6a ] This script #!/usr/bin/bash echo 0 > /proc/sys/kernel/randomize_va_space echo 'void main(void) {}' > TEST.c # -fcf-protection to ensure that the 1st endbr32 insn can't be emulated gcc -m32 -fcf-protection=3Dbranch TEST.c -o test bpftrace -e 'uprobe:./test:main {}' -c ./test "hangs", the probed ./test task enters an endless loop. The problem is that with randomize_va_space =3D=3D 0 get_unmapped_area(TASK_SIZE - PAGE_SIZE) called by xol_add_vma() can not just return the "addr =3D=3D TASK_SIZE - PAGE_SIZE" hint, this addr is used by the stack vma. arch_get_unmapped_area_topdown() doesn't take TIF_ADDR32 into account and in_32bit_syscall() is false, this leads to info.high_limit > TASK_SIZE. vm_unmapped_area() happily returns the high address > TASK_SIZE and then get_unmapped_area() returns -ENOMEM after the "if (addr > TASK_SIZE - len)" check. handle_swbp() doesn't report this failure (probably it should) and silently restarts the probed insn. Endless loop. I think that the right fix should change the x86 get_unmapped_area() paths to rely on TIF_ADDR32 rather than in_32bit_syscall(). Note also that if CONFIG_X86_X32_ABI=3Dy, in_x32_syscall() falsely returns true in this case because ->orig_ax =3D -1. But we need a simple fix for -stable, so this patch just sets TS_COMPAT if the probed task is 32-bit to make in_ia32_syscall() true. Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap(= )") Reported-by: Paulo Andrade Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/aV5uldEvV7pb4RA8@redhat.com/ Cc: stable@vger.kernel.org Link: https://patch.msgid.link/aWO7Fdxn39piQnxu@redhat.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/kernel/uprobes.c | 24 ++++++++++++++++++++++++ include/linux/uprobes.h | 1 + kernel/events/uprobes.c | 10 +++++++--- 3 files changed, 32 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c index 7be8e361ca55b..619dddf54424e 100644 --- a/arch/x86/kernel/uprobes.c +++ b/arch/x86/kernel/uprobes.c @@ -1823,3 +1823,27 @@ bool is_uprobe_at_func_entry(struct pt_regs *regs) =20 return false; } + +#ifdef CONFIG_IA32_EMULATION +unsigned long arch_uprobe_get_xol_area(void) +{ + struct thread_info *ti =3D current_thread_info(); + unsigned long vaddr; + + /* + * HACK: we are not in a syscall, but x86 get_unmapped_area() paths + * ignore TIF_ADDR32 and rely on in_32bit_syscall() to calculate + * vm_unmapped_area_info.high_limit. + * + * The #ifdef above doesn't cover the CONFIG_X86_X32_ABI=3Dy case, + * but in this case in_32bit_syscall() -> in_x32_syscall() always + * (falsely) returns true because ->orig_ax =3D=3D -1. + */ + if (test_thread_flag(TIF_ADDR32)) + ti->status |=3D TS_COMPAT; + vaddr =3D get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE, 0, 0); + ti->status &=3D ~TS_COMPAT; + + return vaddr; +} +#endif diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h index ee3d36eda45dd..f548fea2adec8 100644 --- a/include/linux/uprobes.h +++ b/include/linux/uprobes.h @@ -242,6 +242,7 @@ extern void arch_uprobe_clear_state(struct mm_struct *m= m); extern void arch_uprobe_init_state(struct mm_struct *mm); extern void handle_syscall_uprobe(struct pt_regs *regs, unsigned long bp_v= addr); extern void arch_uprobe_optimize(struct arch_uprobe *auprobe, unsigned lon= g vaddr); +extern unsigned long arch_uprobe_get_xol_area(void); #else /* !CONFIG_UPROBES */ struct uprobes_state { }; diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index d546d32390a81..1ab7a7e4efb63 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -1694,6 +1694,12 @@ static const struct vm_special_mapping xol_mapping = =3D { .mremap =3D xol_mremap, }; =20 +unsigned long __weak arch_uprobe_get_xol_area(void) +{ + /* Try to map as high as possible, this is only a hint. */ + return get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE, 0, 0); +} + /* Slot allocation for XOL */ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area) { @@ -1709,9 +1715,7 @@ static int xol_add_vma(struct mm_struct *mm, struct x= ol_area *area) } =20 if (!area->vaddr) { - /* Try to map as high as possible, this is only a hint. */ - area->vaddr =3D get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, - PAGE_SIZE, 0, 0); + area->vaddr =3D arch_uprobe_get_xol_area(); if (IS_ERR_VALUE(area->vaddr)) { ret =3D area->vaddr; goto fail; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EA5648C416; Sat, 28 Feb 2026 17:42:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300579; cv=none; b=ZUPPOswdvGMFT2fR65mAiCDUrbm8+K59/z8WdEPBjh9wZD0Uow55QU/Ia5ze5bPq5u41PlKdfleiA/gPF/7mAs147+j3G0rxgzofQa/lra2myoK6SMAdyKvG+XN0RW+Fh2t2857SWY1jo6Llmj5sNijMjsVYSeZRjgnazC5ZeVs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300579; c=relaxed/simple; bh=4wwd9lAtfAx/5nuKfXxd7IZ69+OJygCwQdi19XSC14k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cgnuZQhxp2Pqj4N6yp0069HItjCDDAsYjfF4+PlfH+kPVLjZohrNQ8SYR084UXsgmRd0BpQBM7aTVGGtKZhprGm8f/mDMqqYf9BYoBQz5unhuLtJ1ekfjMLBn4YibRejrWudnyV2tAuftJI4g1P/OeL++G4raw0SbH87pJju2Aw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R+1HYv+T; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R+1HYv+T" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A507FC19425; Sat, 28 Feb 2026 17:42:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300579; bh=4wwd9lAtfAx/5nuKfXxd7IZ69+OJygCwQdi19XSC14k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R+1HYv+TGVdocEzy/FB11dKU2C5ec5sa6vgUY2NNFc7551uftwliArRJNIQE5ljD6 rkz2IoYcYy2e5u0M2xqWIUyzvLVOCTxuiEdm+nua+7/uxbBy5TmoLLmIBaizkCd6RC IPgZtioUPuGCPRplk0TfkO/lhc6tcrx0dZM/aYiwloCkYkRwj9ExHbe53crA0Yr/l1 +MvDcGBAY+lS+nx26cD/XQUZmlNa2KicbBFxhkYE1LHNU56WN3RE/1PPFXmjguePOc L1oRjobSPzdtPGokNjYt0SdtgvUEXEh3qMMGY+7XuoT7FibLsuxOjMHaB4XXFzUC6s itsOiiAtRWZIQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Brian Masney , Thierry Reding , Sasha Levin Subject: [PATCH 6.19 620/844] clk: tegra: tegra124-emc: Fix potential memory leak in tegra124_clk_register_emc() Date: Sat, 28 Feb 2026 12:28:53 -0500 Message-ID: <20260228173244.1509663-621-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit fce0d0bd9c20fefd180ea9e8362d619182f97a1d ] If clk_register() fails, call kfree to release "tegra". Fixes: 2db04f16b589 ("clk: tegra: Add EMC clock driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Brian Masney Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clk/tegra/clk-tegra124-emc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clk/tegra/clk-tegra124-emc.c b/drivers/clk/tegra/clk-t= egra124-emc.c index 2a6db04342815..0f6fb776b2298 100644 --- a/drivers/clk/tegra/clk-tegra124-emc.c +++ b/drivers/clk/tegra/clk-tegra124-emc.c @@ -538,8 +538,10 @@ struct clk *tegra124_clk_register_emc(void __iomem *ba= se, struct device_node *np tegra->hw.init =3D &init; =20 clk =3D clk_register(NULL, &tegra->hw); - if (IS_ERR(clk)) + if (IS_ERR(clk)) { + kfree(tegra); return clk; + } =20 tegra->prev_parent =3D clk_hw_get_parent_by_index( &tegra->hw, emc_get_parent(&tegra->hw))->clk; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7791531715B; Sat, 28 Feb 2026 17:43:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300580; cv=none; b=g1eCNwuVCOM3tHr01wh3M6P8wQFtc3vaKyl+4H8ZalGnZ7r5DB1ehB9uV64cT8CF3b8YsSdraWS4esxO8EgebHYCvJ9mZllJv0TZRZV+RKPDQjU1HzBKLaiaaUCXnUDx9KkevASYMBcbhRcA1LW1DCFIhOEbvZcam81JenVfSy8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300580; c=relaxed/simple; bh=UpEB/ASggR2f9TqfQpGKFDO7+IOK8UAr5GCaJxEYp/A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IWh/2vq7g/g4qpueS5x6BPPEn+FteG9Jp/ac0VdT+vXDF3FczRZ5ygxuXgex3UofUqS1U0z7vAVfQa8nO9a7TWeX6DAy5rUzk8Oblx5P6sZ0NLW1C2ZVGpsh6OAFIptviu6XLLruGr72CGhIr6MTQKMA4oEl5yVE/M+OX5I/ptw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mM/iver5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mM/iver5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9480DC19423; Sat, 28 Feb 2026 17:42:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300580; bh=UpEB/ASggR2f9TqfQpGKFDO7+IOK8UAr5GCaJxEYp/A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mM/iver5b/jUUf+Wy+2yvqjzIYUCmFQqd1/in5SUtC8W28BwZ5zE1bxHRq2cPfXck gddVw5kaTSBNWUIwG0REumJckSu5ciPBvl6nwyawBdils5ZDBcTyt4+hkh8yCa9P52 VGz8ZaWRMFMSuJqEUmq3YXrKEsOYFbhxpNCWvMX4r5azgWfCAwoJfuwpfcRxIfwDw7 9AXS56g2olDdTekdFF0RAsy3TmVtzFj9o76oHot5tkiGr+loiGGTbNa3WjyJZvWqlH mgBgyUc2hF5clvfKgG3JaoAZ7RicC6obPbKNdIu17c1VBngqwmcisgy+zHCvv5M2Gg IR81iqRlsdJ5Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Schnelle , Benjamin Block , Farhan Ali , Heiko Carstens , Sasha Levin Subject: [PATCH 6.19 621/844] s390/pci: Handle futile config accesses of disabled devices directly Date: Sat, 28 Feb 2026 12:28:54 -0500 Message-ID: <20260228173244.1509663-622-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Schnelle [ Upstream commit 84d875e69818bed600edccb09be4a64b84a34a54 ] On s390 PCI busses and slots with multiple functions may have holes because PCI functions are passed-through by the hypervisor on a per function basis and some functions may be in standby or reserved. This fact is indicated by returning true from the hypervisor_isolated_pci_functions() helper and triggers common code to scan all possible devfn values. Via pci_scan_single_device() this in turn causes config reads for the device and vendor IDs, even for PCI functions which are in standby and thereofore disabled. So far these futile config reads, as well as potentially writes, which can never succeed were handled by the PCI load/store instructions themselves. This works as the platform just returns an error for a disabled and thus not usable function handle. It does cause spamming of error logs and additional overhead though. Instead check if the used function handle is enabled in zpci_cfg_load() and zpci_cfg_write() and if not enable directly return -ENODEV. Also refactor zpci_cfg_load() and zpci_cfg_store() slightly to accommodate the new logic while meeting modern kernel style guidelines. Cc: stable@vger.kernel.org Fixes: a50297cf8235 ("s390/pci: separate zbus creation from scanning") Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Reviewed-by: Farhan Ali Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/s390/pci/pci.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 57f3980b98a92..7f44b0644a20e 100644 --- a/arch/s390/pci/pci.c +++ b/arch/s390/pci/pci.c @@ -231,24 +231,33 @@ int zpci_fmb_disable_device(struct zpci_dev *zdev) static int zpci_cfg_load(struct zpci_dev *zdev, int offset, u32 *val, u8 l= en) { u64 req =3D ZPCI_CREATE_REQ(zdev->fh, ZPCI_PCIAS_CFGSPC, len); + int rc =3D -ENODEV; u64 data; - int rc; + + if (!zdev_enabled(zdev)) + goto out_err; =20 rc =3D __zpci_load(&data, req, offset); - if (!rc) { - data =3D le64_to_cpu((__force __le64) data); - data >>=3D (8 - len) * 8; - *val =3D (u32) data; - } else - *val =3D 0xffffffff; + if (rc) + goto out_err; + data =3D le64_to_cpu((__force __le64)data); + data >>=3D (8 - len) * 8; + *val =3D (u32)data; + return 0; + +out_err: + PCI_SET_ERROR_RESPONSE(val); return rc; } =20 static int zpci_cfg_store(struct zpci_dev *zdev, int offset, u32 val, u8 l= en) { u64 req =3D ZPCI_CREATE_REQ(zdev->fh, ZPCI_PCIAS_CFGSPC, len); + int rc =3D -ENODEV; u64 data =3D val; - int rc; + + if (!zdev_enabled(zdev)) + return rc; =20 data <<=3D (8 - len) * 8; data =3D (__force u64) cpu_to_le64(data); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A36F831717D; Sat, 28 Feb 2026 17:43:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300581; cv=none; b=BycLEW7m2HBrkR9kOwYJeXi4N2cW2eM0nDMO7Ol667lcEb7y20tRcHcwwS/Q0EDBKH80CKE+Qa6BxrnWOzrpevL4NQnj3DrK2J4VzppqeqzOz8sci5cS2WgngIjwT93gXzqL/6H8H4wlbhjfgvMB2X3ASQPCyQrM3St4VR85/qM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300581; c=relaxed/simple; bh=BmJESorZCNmwmXWKrpPOWGyF/Oq8LKKDxOzvYAgVGpQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oFWq9qHIu+1TCS/nKbZ/j70EbbBGWu+r5m5Rr9NHNy0TDS4XSJ4svXxMalt0dyaSDGzvHQ7srTb6D2aJ3adTHtfZZy16r4NLp5W2RO7kEvHKBDZYoZDonnasdJbLZ1alpyLN+u5CzIag4Rpzu1f6zBYzoK46nuAv1akrDSFVQpc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OE96oZuf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OE96oZuf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E230C116D0; Sat, 28 Feb 2026 17:43:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300581; bh=BmJESorZCNmwmXWKrpPOWGyF/Oq8LKKDxOzvYAgVGpQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OE96oZufj7DRIYbDjuiDVR4Rz7bF+MMgGuMFRMLWbfvoy3Rvhmlr1CtJJs6auVK7j OWhzwmbQk3Q4vk9+zertY/EQh0Ry2CbXtcEKfC3az+MqW8J/dTjGZoHn707A9Vmevy YyCuQG8a87FUDXU5knQrbYEYOKy5MSjuL4hEd+4ptA2RFGKZIsu4I4yCX8nkS6wEWK 1spPa/GRdv04OCfTzQrFgcxdMnWNRg/jZy6Ji71mCvUFbd1P9RMlw++tjzTjqYwU4q PSCBZRlHUK94mQ+7FfTlI6al0R93X6BmwgxA6PZiLEpRQW0obsDfIcWko7aMSCxmLd spRLRY43FGScw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Joonwon Kang , Jassi Brar , Sasha Levin Subject: [PATCH 6.19 622/844] mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate() Date: Sat, 28 Feb 2026 12:28:55 -0500 Message-ID: <20260228173244.1509663-623-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Joonwon Kang [ Upstream commit fcd7f96c783626c07ee3ed75fa3739a8a2052310 ] Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells =3D <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function. Cc: stable@vger.kernel.org Signed-off-by: Joonwon Kang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mailbox/mailbox.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index 2acc6ec229a45..617ba505691d3 100644 --- a/drivers/mailbox/mailbox.c +++ b/drivers/mailbox/mailbox.c @@ -489,12 +489,10 @@ EXPORT_SYMBOL_GPL(mbox_free_channel); static struct mbox_chan *fw_mbox_index_xlate(struct mbox_controller *mbox, const struct fwnode_reference_args *sp) { - int ind =3D sp->args[0]; - - if (ind >=3D mbox->num_chans) + if (sp->nargs < 1 || sp->args[0] >=3D mbox->num_chans) return ERR_PTR(-EINVAL); =20 - return &mbox->chans[ind]; + return &mbox->chans[sp->args[0]]; } =20 /** --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DD063FA8CA; Sat, 28 Feb 2026 17:43:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300582; cv=none; b=uz8TrdxVBQlS/ItOLknV3uzGDS5Y8jaW0cGc64EWdAnzgJjfbY3zKzSRSjrqGhwT8Ntn3ZuDJi2h+tA495X3Clme/PP9X2bEPHEv7gDgf4e3Ppd9PLpRFqURLA/dFYKsZr7xTBFnQ6ejhVY09TXjWFl7GnnTSZvTaUvxP+oNNls= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300582; c=relaxed/simple; bh=+nBPVjEJJjhhvGDt5ZqNBhqYkKUDrUeoahy2JfsQbok=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZipI0LZzyAtxjKnOuqPGSUG2fwhRPSAXPNno/yhPnUYwsFdRuV8rtx+7jDLeiNyTFaXsW9y1sbRXeeeiRurgI5fYnHOX491mSafIYHWjuk9psah9S4U3GIJTJpL0p+nrTfi/Jy44Ytqk1ibWoO+vWIfj92bfHiPRQ9ZuuWUuqME= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gdhh0wmY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gdhh0wmY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78A97C19424; Sat, 28 Feb 2026 17:43:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300582; bh=+nBPVjEJJjhhvGDt5ZqNBhqYkKUDrUeoahy2JfsQbok=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gdhh0wmYqA24hK/ElqrDtowZ/cDpfpb2Khwtourdw78RH0umpjAl0gj47+jRZ1SSN 5BIOMrB4esFcZRC0SP/D5Y3bhSj1DQNeXPOQL2oSTLcz9odVMMePv6yW9s+Upqik0i GVw0IXEhiGUHga4i4TnpLEEKzIUQlq+LOzQqpwLIgdwN6cW95UeP9XPRUz0530FePD S/xGsWHlXfqUZQYcBZ7KGNkg2NmWuYw+L4TojC72SK1xOgi2Lb7/mgU/++NLj4+X9J TNm5KdrIuapO6Ef68RKbDO27EaZ8yrtMZkxaKhgeQJMkj0Tv7X8ts8eFBoDsxvNd1t F04cRK/qcFGyQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Jouni=20H=C3=B6gander?= , Mika Kahola , Jani Nikula , Rodrigo Vivi , Joonas Lahtinen , Sasha Levin Subject: [PATCH 6.19 623/844] drm/i915/psr: Don't enable Panel Replay on sink if globally disabled Date: Sat, 28 Feb 2026 12:28:56 -0500 Message-ID: <20260228173244.1509663-624-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Jouni H=C3=B6gander [ Upstream commit 69f83f167463bad26104af7fbc114ce1f80366b0 ] With some panels informing support for Panel Replay we are observing problems if having Panel Replay enable bit set on sink when forced to use PSR instead of Panel Replay. Avoid these problems by not setting Panel Replay enable bit in sink when Panel Replay is globally disabled during link training. I.e. disabled by module parameter. The enable bit is still set when disabling Panel Replay via debugfs interface. Added note comment about this. Fixes: 68f3a505b367 ("drm/i915/psr: Enable Panel Replay on sink always when= it's supported") Cc: Mika Kahola Cc: Jani Nikula Cc: Rodrigo Vivi Cc: # v6.15+ Signed-off-by: Jouni H=C3=B6gander Reviewed-by: Mika Kahola Link: https://patch.msgid.link/20260115070039.368965-1-jouni.hogander@intel= .com (cherry picked from commit c5a52cd04e24f0ae53fda26f74ab027b8c548e0e) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/i915/display/intel_psr.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i91= 5/display/intel_psr.c index 08bca45739749..44063b578354e 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -857,7 +857,12 @@ static void intel_psr_enable_sink(struct intel_dp *int= el_dp, =20 void intel_psr_panel_replay_enable_sink(struct intel_dp *intel_dp) { - if (CAN_PANEL_REPLAY(intel_dp)) + /* + * NOTE: We might want to trigger mode set when + * disabling/enabling Panel Replay via debugfs interface to + * ensure this bit is cleared/set accordingly. + */ + if (CAN_PANEL_REPLAY(intel_dp) && panel_replay_global_enabled(intel_dp)) drm_dp_dpcd_writeb(&intel_dp->aux, PANEL_REPLAY_CONFIG, DP_PANEL_REPLAY_ENABLE); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D10F3FA8E8; Sat, 28 Feb 2026 17:43:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300583; cv=none; b=FtPtUdsT8C6i4PJUXy+y5Gtmyi3oAXwaMjLgMqvbIyDSTW2HmX2FW/jbltBFljDO5CstU2bMn5HhDZh8/WFki5kFR1NNTXEAYRL32/83Mwq6UN+xInABIkMGaCEWUHC7oBHd4z3E1GuC3poMB9zIVEFdGC/SU2kv2aU+dbLyYrI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300583; c=relaxed/simple; bh=eMPU9koIKEZixE4sZuG8N2+QdGfAisHOg9zLI83Mqto=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pvTDso2iWemzOllIQKutmyoJD6zLRp6Ilt0CzA2Ul5C89Amzw/NXhrnbQJ9u74Yl6oXrK4CrdGqPJbQY4rW+mqf2cQzMHFaq/6h066Bx3uZAUCcdgE5JyvvHS4hHvLjC/WKmW6fJ4q3dCdpRiAlP/Oat6Vb7VLDTpJnK/MT+I4M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EBpdKgbq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EBpdKgbq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 937BBC19423; Sat, 28 Feb 2026 17:43:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300583; bh=eMPU9koIKEZixE4sZuG8N2+QdGfAisHOg9zLI83Mqto=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EBpdKgbqrd9bhiPPseYt00alemR92mWHeZZWlM6uFrTCRdRYTZl3JLgscjQKcmLuG nL2K4TVw5Y2P5RPyU+hVdd43ca9G35zHytkIb4XH2QTB+SSDjeLrZ5G9tlkgRScskK AV4bJPUd3hZODJ97/whLhe9a77UW0FigN3WbuLvQnOhAyfzDxyS4oNs6IgwWuqeby0 LSE7AG7Aa42pXwrQT30sfZjkhifAMio0MlFh0wLv0FAlskpZRNSz+zURpzppvNXNYs B/FbJMMo6fjpmj3TwzYGDEm0yhDW6MRZhYI9FcCJVSzL6Ei7qo2KvzbzD/P9Uj0Oxq 61DgJSAgW7bwQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bartosz Golaszewski , Krzysztof Kozlowski , Philipp Zabel , Sasha Levin Subject: [PATCH 6.19 624/844] reset: gpio: suppress bind attributes in sysfs Date: Sat, 28 Feb 2026 12:28:57 -0500 Message-ID: <20260228173244.1509663-625-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bartosz Golaszewski [ Upstream commit 16de4c6a8fe9ff497ca1aba33ef0dbee09f11952 ] This is a special device that's created dynamically and is supposed to stay in memory forever. We also currently don't have a devlink between it and the actual reset consumer. Suppress sysfs bind attributes so that user-space can't unbind the device because - as of now - it will cause a use-after-free splat from any user that puts the reset control handle. Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/reset/reset-gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/reset/reset-gpio.c b/drivers/reset/reset-gpio.c index e5512b3b596b5..626c4c639c155 100644 --- a/drivers/reset/reset-gpio.c +++ b/drivers/reset/reset-gpio.c @@ -111,6 +111,7 @@ static struct auxiliary_driver reset_gpio_driver =3D { .id_table =3D reset_gpio_ids, .driver =3D { .name =3D "reset-gpio", + .suppress_bind_attrs =3D true, }, }; module_auxiliary_driver(reset_gpio_driver); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3844531716E; Sat, 28 Feb 2026 17:43:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300584; cv=none; b=ZkcwShgxznlBATR7V9qg0u5pW/4FBSM8IyiXg/lYqWo8BUh4Eli+1twDbdXEMVdUj1vXZ+1t0vHgVM/nr7u928y/o2ntWl3cZMewe5GXOvVLwN2j3pedKajq+mcKnSLTgLUFNEtPzmW3a9o6gAcx7ceNMj6WH93tCP/PBNKmRS8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300584; c=relaxed/simple; bh=uyuwHoRo/ZWZHG1r0TNz72203WGOTdwB80ya0qW2DuQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=idh9gFrSy0wccGzAfyDTqQ3sIIV3wlNQDt/6Acyu6AYsf2oH0tmerFk4c4/z/x4ljbRuUOFSYNdGe76a1dcAnw11GPP2wev0LydAiY77E5n2iRuwwRTBe6c45Icz58nQZ85WHwQVXr8VyRwNS95bGBxyy/Coo4XvJdWnIbrnMJY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EAImG10Y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EAImG10Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 831E9C116D0; Sat, 28 Feb 2026 17:43:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300584; bh=uyuwHoRo/ZWZHG1r0TNz72203WGOTdwB80ya0qW2DuQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EAImG10YY+Jrk0M/krqkvUnLYuBoIQOu/fbL/f1Zy09UxhhDYJqYjvw0SjNe6scqe M841fjhmn+3ADmO2DN6ioCis+lIpZwGOQUGRcDTWck90NQS6HFu1UqZYzIL6tZCX2y mUkYlGuvMAkTG8EH8q1EmN4gNoE1mlicZdfUvAsF9N5E2cJWUcnSo/nVwSxX6L7o5j vDqa+BrDEF4gvfl5k1V+VZVwp9h5Dtp0Izd1V9H7vblJW+0r7LBOUbH7g+dRUMlDjT cctkMfXXwXCFY2BpmkdM6zQseFkBrAgGS/nCMsrbLUjPzxfm5GpDO6STHgiWSZkluS zKJyEQhTCpAGA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mikulas Patocka , Ondrej Kozina , Sasha Levin Subject: [PATCH 6.19 625/844] dm-integrity: fix recalculation in bitmap mode Date: Sat, 28 Feb 2026 12:28:58 -0500 Message-ID: <20260228173244.1509663-626-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mikulas Patocka [ Upstream commit 118ba36e446c01e3cd34b3eedabf1d9436525e1d ] There's a logic quirk in the handling of suspend in the bitmap mode: This is the sequence of calls if we are reloading a dm-integrity table: * dm_integrity_ctr reads a superblock with the flag SB_FLAG_DIRTY_BITMAP set. * dm_integrity_postsuspend initializes a journal and clears the flag SB_FLAG_DIRTY_BITMAP. * dm_integrity_resume sees the superblock with SB_FLAG_DIRTY_BITMAP set - thus it interprets the journal as if it were a bitmap. This quirk causes recalculation problem if the user increases the size of the device in the bitmap mode. Fix this by reading a fresh copy on the superblock in dm_integrity_resume. This commit also fixes another logic quirk - the branch that sets bitmap bits if the device was extended should only be executed if the flag SB_FLAG_DIRTY_BITMAP is set. Signed-off-by: Mikulas Patocka Tested-by: Ondrej Kozina Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-integrity.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c index 79d60495454a5..ba52631052503 100644 --- a/drivers/md/dm-integrity.c +++ b/drivers/md/dm-integrity.c @@ -3788,14 +3788,27 @@ static void dm_integrity_resume(struct dm_target *t= i) struct dm_integrity_c *ic =3D ti->private; __u64 old_provided_data_sectors =3D le64_to_cpu(ic->sb->provided_data_sec= tors); int r; + __le32 flags; =20 DEBUG_print("resume\n"); =20 ic->wrote_to_journal =3D false; =20 + flags =3D ic->sb->flags & cpu_to_le32(SB_FLAG_RECALCULATING); + r =3D sync_rw_sb(ic, REQ_OP_READ); + if (r) + dm_integrity_io_error(ic, "reading superblock", r); + if ((ic->sb->flags & flags) !=3D flags) { + ic->sb->flags |=3D flags; + r =3D sync_rw_sb(ic, REQ_OP_WRITE | REQ_FUA); + if (unlikely(r)) + dm_integrity_io_error(ic, "writing superblock", r); + } + if (ic->provided_data_sectors !=3D old_provided_data_sectors) { if (ic->provided_data_sectors > old_provided_data_sectors && ic->mode =3D=3D 'B' && + ic->sb->flags & cpu_to_le32(SB_FLAG_DIRTY_BITMAP) && ic->sb->log2_blocks_per_bitmap_bit =3D=3D ic->log2_blocks_per_bitmap= _bit) { rw_journal_sectors(ic, REQ_OP_READ, 0, ic->n_bitmap_blocks * (BITMAP_BLOCK_SIZE >> SECTOR_SHIFT), NULL); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57BA03FB059; Sat, 28 Feb 2026 17:43:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300585; cv=none; b=kx1O9LRVm5N22DA4fpu791xlfHVMG3VCvMyM1t5G72xjPg+NYf4z1Mu/f3Ep0IAulsUasXrfp2puMIsBt9XF94c82wPPFA/cD4BUJu9Ujqoha99Np0zd9sFw4ixOMeoeFO51G3ctlIsyCf5pjsonCGUpoten3hzFg5jrkPjKi1Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300585; c=relaxed/simple; bh=SsTQtT95nhRfD4rfSWy0JtnaIw6wyjoP8Ex2NMbIeYY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kJXeJHZmJavRY2v4ANY7NUJkNh7qlcppbrI5RboJHagz70J7GnqePap6OaTHT368f0qk1bn/HhV3OMI7u7UbuziavsH0SNlzQR8Eh1YLTnQbg4CUyTJLDJj1FO7kr7dhOEbtVvFnsnslfMl9EK4vsGLLkfBAznsKvziJ+w9hE28= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X07/2TYl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X07/2TYl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E3C3C2BCAF; Sat, 28 Feb 2026 17:43:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300585; bh=SsTQtT95nhRfD4rfSWy0JtnaIw6wyjoP8Ex2NMbIeYY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X07/2TYlVSFayZC6+tAX2ufXMrvSlBRYlQsLBLX0s+/hXKEJ0udXU4oDNQP9JY91a y1qjHp6M6Pfk5hdkx3MQ7Yblr0VyI1boBAj6qUViCG6y654CzkS31nUz3bqwqH0E5x oR90yD6YgZ9dR01m/YnaA5mTh/DXfNweOMYmGepJFaQ36ildliWN/VaATC4naoUagh JJPEd/J6WrfeobUYsjkKcxPJy0lEqcTGAyZPL+UG4P6l1L3xoZ8mFyt6LCvtE92X8t gGigvFFzntCetus22ma8+dOOK1EyQaPCyt75fkFu8ChFAcMjVsnYiE3TEEM5fkXWhb ZLEtxFiJ+bwUA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Matt Whitlock , Mikulas Patocka , Sasha Levin Subject: [PATCH 6.19 626/844] dm-unstripe: fix mapping bug when there are multiple targets in a table Date: Sat, 28 Feb 2026 12:28:59 -0500 Message-ID: <20260228173244.1509663-627-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Matt Whitlock [ Upstream commit 83c10e8dd43628d0bf86486616556cd749a3c310 ] The "unstriped" device-mapper target incorrectly calculates the sector offset on the mapped device when the target's origin is not zero. Take for example this hypothetical concatenation of the members of a two-disk RAID0: linearized: 0 2097152 unstriped 2 128 0 /dev/md/raid0 0 linearized: 2097152 2097152 unstriped 2 128 1 /dev/md/raid0 0 The intent in this example is to create a single device named /dev/mapper/linearized that comprises all of the chunks of the first disk of the RAID0 set, followed by all of the chunks of the second disk of the RAID0 set. This fails because dm-unstripe.c's map_to_core function does its computations based on the sector number within the mapper device rather than the sector number within the target. The bug turns invisible when the target's origin is at sector zero of the mapper device, as is the common case. In the example above, however, what happens is that the first half of the mapper device gets mapped correctly to the first disk of the RAID0, but the second half of the mapper device gets mapped past the end of the RAID0 device, and accesses to any of those sectors return errors. Signed-off-by: Matt Whitlock Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Fixes: 18a5bf270532 ("dm: add unstriped target") Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-unstripe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-unstripe.c b/drivers/md/dm-unstripe.c index e8a9432057dce..17be483595642 100644 --- a/drivers/md/dm-unstripe.c +++ b/drivers/md/dm-unstripe.c @@ -117,7 +117,7 @@ static void unstripe_dtr(struct dm_target *ti) static sector_t map_to_core(struct dm_target *ti, struct bio *bio) { struct unstripe_c *uc =3D ti->private; - sector_t sector =3D bio->bi_iter.bi_sector; + sector_t sector =3D dm_target_offset(ti, bio->bi_iter.bi_sector); sector_t tmp_sector =3D sector; =20 /* Shift us up to the right "row" on the stripe */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9C2C3FB06C; Sat, 28 Feb 2026 17:43:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300586; cv=none; b=bsOHiBAdDeu8YfoTC9ZXAM+kRaNJcHI5QC9hVROyGJhzvBf/zooAQTM3eMsR09aLL4dwC3HDf5rw5AkE9yo1yoEjnFhZbWJlpoJ9MK+YW67pU5mHbgW7rHHFgM5VbYU1OXxt2T6dMx2b2sDM3ACI8tMPNenbwgtkqCgbGjRSb5s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300586; c=relaxed/simple; bh=0Mqm9g8b0uJL2WhV7ayN85PIyCavrW4mYuHt/F+FbWA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aahV52EvZBtU1VRNVS5WenKqPSPusxD0BeY/NEZBwiA++VRamGLHv5So7hRpaNPvqVXHBxoeDFuUU+W1KxK+Q9nH51xY7/iCUcT4Co78S7gWMCsDIP7VPzxMm00vKPlk1fMSL40nWxHq+4xcb2bTimREYyrzT+udthYdJtMrgss= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ak9iRzvS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ak9iRzvS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4042DC19423; Sat, 28 Feb 2026 17:43:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300585; bh=0Mqm9g8b0uJL2WhV7ayN85PIyCavrW4mYuHt/F+FbWA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ak9iRzvSvOUX6+liXxyjehOk0YEKouyguIiab4R6upEuPbjJht+bHT2qxWx2dxmHk e82NsHEkSiXFkWdExm2c3UNGX+Ns9ozlUneCZlwzeLevAQy0/zvaWGLto9nGnbCoTw ozhFsxmVBF+5h78csB95s9GjVxivtBzgPCjjaMJOXwG65DYc18Q99QQEwOQQVeDwE1 d9oqMgzitDkrTqJHWZo82b0AFk1b2ij2j4vGR3GbLQ5+ZFO1rNN06RdbfxW6ch5qpa lAEruF1ItUsdJLX4tkRdtmFHRrg/gide7WdegzPgXjCvWhfDOPcXthJB0+MmcZiZHA DxO8es6aQ8l9g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Keeping , Alexandre Belloni , Sasha Levin Subject: [PATCH 6.19 627/844] rtc: pcf8563: use correct of_node for output clock Date: Sat, 28 Feb 2026 12:29:00 -0500 Message-ID: <20260228173244.1509663-628-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Keeping [ Upstream commit a380a02ea3ddc69c1c1ccca3882748dee33ec3d3 ] When switching to regmap, the i2c_client pointer was removed from struct pcf8563 so this function switched to using the RTC device instead. But the RTC device is a child of the original I2C device and does not have an associated of_node. Reference the correct device's of_node to ensure that the output clock can be found when referenced by other devices and so that the override clock name is read correctly. Cc: stable@vger.kernel.org Fixes: 00f1bb9b8486b ("rtc: pcf8563: Switch to regmap") Signed-off-by: John Keeping Link: https://patch.msgid.link/20260108184749.3413348-1-jkeeping@inmusicbra= nds.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/rtc/rtc-pcf8563.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c index 4e61011fb7a96..b281e9489df1d 100644 --- a/drivers/rtc/rtc-pcf8563.c +++ b/drivers/rtc/rtc-pcf8563.c @@ -424,7 +424,7 @@ static const struct clk_ops pcf8563_clkout_ops =3D { =20 static struct clk *pcf8563_clkout_register_clk(struct pcf8563 *pcf8563) { - struct device_node *node =3D pcf8563->rtc->dev.of_node; + struct device_node *node =3D pcf8563->rtc->dev.parent->of_node; struct clk_init_data init; struct clk *clk; int ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0FB148C8A5; Sat, 28 Feb 2026 17:43:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300586; cv=none; b=NKYGWObLTohWPWo9XdYESBJ75mW5HSDSpeRu8Fh46zuGrDzDIivkLIERnMmv222xTD8e84UrbkCG8/8ZjNJTOSaTwviCGu7FOWZzsZ1JGWM3ZoPJn0cUgmZvh8h75gae5IaUkcEZAK9AMia/UjvL5xhzcoREIE2ACOOKspVYjgI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300586; c=relaxed/simple; bh=FFPWF6NdzOOfi06Yglh6lxiKLJrLZ7+L/ZBg1OojEiE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ThVP4Bix8dbx2ZW9Yc/JC17K9Gb9O+B1kkaGQ5LEj9J+FcDWSTh95wezVJDyBa0OjPdnkCjfKlk2lw8QXrRYIzyfUZ3Syng2FqqW1GlsrLaIr0UDQnq6JHx8onmfMFOPOpJ/b3NBD6NbLSLU6qyi+AKZXoBPAd2l0VNveJywn4c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=k5qFPGiX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="k5qFPGiX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E043C19423; Sat, 28 Feb 2026 17:43:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300586; bh=FFPWF6NdzOOfi06Yglh6lxiKLJrLZ7+L/ZBg1OojEiE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=k5qFPGiX5pkZU5Ht3QI/j0VWHfC6uCvZjABR1mqdnCrpulyU7p6nXwO2T8xNi1QJr j2gZUgZcNCl1KHTQBMrGC3qlgXpCIOGdH/uT17GP+FoyS5bAdfxVcUC6TfNrxZPAP9 Elk/OcmW5QVv2g+u6K1/9MvbrzsfT7oczhK8RAWstQy8F8Y44RIkRHuH/OS80GvwQX N+o1zHeCwdLSfm5VVvsZdKPzU+dHLJwFON5OY7fF0HgFbeGLeI01Go3SC68Cv4SMtW 0eIykGjHiiC8lOmjKiOowiRsHnBQFqhyQIb37lmEDNmp9HPU2bs/4FpRAATCiItqpn vY7znTevIVy8A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dirk Behme , Alice Ryhl , Sasha Levin Subject: [PATCH 6.19 628/844] drm/tyr: fix register name in error print Date: Sat, 28 Feb 2026 12:29:01 -0500 Message-ID: <20260228173244.1509663-629-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dirk Behme [ Upstream commit 793e8f7d52814e096f63373eca643d2672366a5a ] The `..IRQ..` register is printed here. Not the `..INT..` one. Correct this. Cc: stable@vger.kernel.org Fixes: cf4fd52e3236 ("rust: drm: Introduce the Tyr driver for Arm Mali GPUs= ") Link: https://lore.kernel.org/rust-for-linux/A04F0357-896E-4ACC-BC0E-DEE860= 8CE518@collabora.com/ Signed-off-by: Dirk Behme Link: https://patch.msgid.link/20260119070838.3219739-1-dirk.behme@de.bosch= .com [aliceryhl: update commit message prefix] [aliceryhl: add cc stable as per Miguel's suggestion] Signed-off-by: Alice Ryhl Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/tyr/driver.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs index 0389c558c0367..3047fd12fd849 100644 --- a/drivers/gpu/drm/tyr/driver.rs +++ b/drivers/gpu/drm/tyr/driver.rs @@ -76,7 +76,7 @@ fn issue_soft_reset(dev: &Device, iomem: &Devres) -> Result { dev_err!(dev, "GPU reset failed with errno\n"); dev_err!( dev, - "GPU_INT_RAWSTAT is {}\n", + "GPU_IRQ_RAWSTAT is {}\n", regs::GPU_IRQ_RAWSTAT.read(dev, iomem)? ); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 128353FB882; Sat, 28 Feb 2026 17:43:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300588; cv=none; b=vFZIepjlH0RVDhBR68bdtjYL5kTlM8Jvw48scy8gMCEClphbzu22UxMUNjoX3/Nsbv3jTR7P1NO/JB30zTFL0X20ULz2adKpBmIGLcCbZKUXbmSplRDt3nil0q7l6NiIsA+1akRoFmcbbQjizMklf+0c1ClD9vSTN2whxcO8Xic= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300588; c=relaxed/simple; bh=2/8CjZ2M6wqfVJPQsRKl2gNxsxkT7FkZ7s/j0wZ1C2Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hCMCMHf7Chf6dqG/Ib8f1o68UJSu0kaDWcFLRnRn8fiJT3esKqRNgN9dezbEoF7BUOJkfR0ia/XHpsHC4CCey8evolFKaNPbpl5VwZKO7FZrd8I2driKYkJaGJtuhciBnP+G8dlyK1r4ZijzsRupwlMUeqIYYO4RaVxL1hLGjOA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R9WxMNdz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R9WxMNdz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F01B8C19423; Sat, 28 Feb 2026 17:43:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300587; bh=2/8CjZ2M6wqfVJPQsRKl2gNxsxkT7FkZ7s/j0wZ1C2Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R9WxMNdzp1qkQIKjmiKIsF0piJE9+LQGsTbkommlsP8leF+SoWs3mKCV1UoiYtmez CmkFePWjCWykcDpFrVQzJUMWUd1nF4nmDHKizo0R35qrNEAa8be4BTeZASwqqek2v6 /X3uJz4cQMFQq5XkpJ3N1KMt8R0XvIDpYlTvKD2gY/n9WpVYoKkkyQkp1U/DASdmU2 A4YpCm1yn/z2PSLjMcVx8/vzdLpuEgzE69i0HRZsVv9H4allHWjJszG+Q6bzEuW+Vc IFe0fLJq2GFM8ISeZLfiG8uO3sv8aDQXHs3x55XmQstWeY0DLW0hG81OCo0NaPPgwM IOIy00ABigDow== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jun Yan , Peter Robinson , Dragan Simic , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.19 629/844] arm64: dts: rockchip: Do not enable hdmi_sound node on Pinebook Pro Date: Sat, 28 Feb 2026 12:29:02 -0500 Message-ID: <20260228173244.1509663-630-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jun Yan [ Upstream commit b18247f9dab735c9c2d63823d28edc9011e7a1ad ] Remove the redundant enabling of the hdmi_sound node in the Pinebook Pro board dts file, because the HDMI output is unused on this device. [1][2] This change also eliminates the following kernel log warning, which is caused by the unenabled dependent node of hdmi_sound that ultimately results in the node's probe failure: platform hdmi-sound: deferred probe pending: asoc-simple-card: parse error [1] https://files.pine64.org/doc/PinebookPro/pinebookpro_v2.1_mainboard_sch= ematic.pdf [2] https://files.pine64.org/doc/PinebookPro/pinebookpro_schematic_v21a_202= 20419.pdf Cc: stable@vger.kernel.org Fixes: 5a65505a69884 ("arm64: dts: rockchip: Add initial support for Pinebo= ok Pro") Signed-off-by: Jun Yan Reviewed-by: Peter Robinson Reviewed-by: Dragan Simic Link: https://patch.msgid.link/20260116151253.9223-1-jerrysteve1101@gmail.c= om Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/ar= m64/boot/dts/rockchip/rk3399-pinebook-pro.dts index 810ab6ff4e670..753d513449540 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts @@ -421,10 +421,6 @@ &gpu { status =3D "okay"; }; =20 -&hdmi_sound { - status =3D "okay"; -}; - &i2c0 { clock-frequency =3D <400000>; i2c-scl-falling-time-ns =3D <4>; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E69813FB89A; Sat, 28 Feb 2026 17:43:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300589; cv=none; b=nnAMlWUuZQ1mxwxmtWgXyIxO8MTPLrCc80y+wHNuG6dK4c8olvlncKCFSug098oa88h0zEwfCDSza6YoYIgvghnThkiJepG6uhB8TQweTOyvy8BQ0HYWiizsgtw9z8HXUCnRs3v7oEYJFei6SQcHT6LvisiQnK+wYPNEBAifX5o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300589; c=relaxed/simple; bh=9LQK53S+1C7Ho18RH8m/6mkNYbAiFBoP0Vq87CYjD9k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aoI6Zv9SCzb0iRQXoUhr5RuIC2uANujnCGqWFYcbV8o8THbGqUxHocNrBxZMsKrX3kI8Js0+QOw1Vn39g5aheC7ZNxGItchmQ8nvZIO0rNP6IH/uyjLhxlC5g9GaCgsXjuf+0gBk4WEs+khQkScVOWsEffEizYbQKjcx+B13rxg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VSHOAQpx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VSHOAQpx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2632C19424; Sat, 28 Feb 2026 17:43:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300588; bh=9LQK53S+1C7Ho18RH8m/6mkNYbAiFBoP0Vq87CYjD9k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VSHOAQpxxHUaT4fTOfV4KUIenLga3tqIA+hl31o6OIW0S8o0P+twa5CkV7chE1wIJ l4uLCEt/nGK1A1opDo22wzyjDfM8aih5MbrsSmBv7b5C3gdkbGcIdjYp4aF0dSboi2 Lv4zewwt/blXKwKQhFCFyopfX9olNdO8VeKeApBtE7pHKBC/YKXEAmXz9GwHiVUduO 12vLYD10y9PmVoyNm5zq6GVxdjB3y8Y0LjtAUUM9wSo1KUTsxTqFRZP94EM2KBNDeO b5oszirahVTwS7OoWSOt6+3T3nd1NuasllLYY5Qod13OgGCmQCPm7C82npjrQIHwop 0uWpim+GCAj2g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Renjiang Han , Vikash Garodia , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 630/844] media: venus: vdec: fix error state assignment for zero bytesused Date: Sat, 28 Feb 2026 12:29:03 -0500 Message-ID: <20260228173244.1509663-631-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Renjiang Han [ Upstream commit 93ecd6ee95c38cb533fa25f48d3c1c8cb69f410f ] When hfi_session_flush is issued, all queued buffers are returned to the V4L2 driver. Some of these buffers are not processed and have bytesused =3D 0. Currently, the driver marks such buffers as error even during drain operations, which can incorrectly flag EOS buffers. Only capture buffers with zero payload (and not EOS) should be marked with VB2_BUF_STATE_ERROR. The check is performed inside the non-EOS branch to ensure correct handling. Fixes: 51df3c81ba10b ("media: venus: vdec: Mark flushed buffers with error = state") Signed-off-by: Renjiang Han Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/venus/vdec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platf= orm/qcom/venus/vdec.c index 4a6641fdffcf7..d0bd2d86a31f9 100644 --- a/drivers/media/platform/qcom/venus/vdec.c +++ b/drivers/media/platform/qcom/venus/vdec.c @@ -1440,10 +1440,10 @@ static void vdec_buf_done(struct venus_inst *inst, = unsigned int buf_type, inst->drain_active =3D false; inst->codec_state =3D VENUS_DEC_STATE_STOPPED; } + } else { + if (!bytesused) + state =3D VB2_BUF_STATE_ERROR; } - - if (!bytesused) - state =3D VB2_BUF_STATE_ERROR; } else { vbuf->sequence =3D inst->sequence_out++; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA8CF3FC0CB; Sat, 28 Feb 2026 17:43:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300590; cv=none; b=lo6Rveeh8UEIJqoZnJU0ofkWMKqmp0BfjuAj/kS+kx0fn0r79DX9XKzDi2YSSlPQ093h889aMmsP3shDYZXSRgqp2GKq4GOL2R2SaPuLndK2zhiNUNDubpurGsPhJiNVHfc0vtWqexwZKqCAbWGp9QsV1ejE6reLYg9dRMOy604= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300590; c=relaxed/simple; bh=TqMJ7BuT6pFshyQelZBd8BwjI1j+3aLsEL1tmzIGPgs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VRIO8Ae1qmzMNhOURiZV/d3p2vywqNu/VmyHKwlvJWkRXeug0R0YK6C+w1KyNFPKrNm7tFaxtzYBWl+gHDw52XL4a0b6jMi/Xf4bgZ9PSI9wiQmLbjcF42p0anYRM2XvcZLu3ECJ2uaqKBqOuosmIbUMMO60WKwhYm6JQIoK8Xo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HErH5Utz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HErH5Utz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0428DC116D0; Sat, 28 Feb 2026 17:43:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300589; bh=TqMJ7BuT6pFshyQelZBd8BwjI1j+3aLsEL1tmzIGPgs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HErH5UtzhiJ/TtJ7e+c2q49sQmf7FR8htKByF43/Upy/IWAL+b/6zN1YWUFIH2MBm r2hZVn1wSS6KMk3B9aqY6Vq9/2hzmY7PAKsrGG9uWZnvvV4LII7McXno2KsOBNrKvD z4zR06F8XML+4ZAQG+6SLqwcdpy/xhozSebqRlJqR/5SG8eDWffpQ6H0c17Sv2HnwD VCoK1TPLjwFoJtKQWEI4TAKqkJcC2kWBpCJ6o8J2Zr/blPAUpgW0IS+wTW1eWn8prr ki0juo8RXAP4UaaLZZ5xNpU+KeZhkKyIBjV5XC8uxFrzQV98m1hil3Mj/g/7H/i2ql KSeYEcJ40d70w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dikshita Agarwal , Mecid , Renjiang Han , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 631/844] media: venus: vdec: restrict EOS addr quirk to IRIS2 only Date: Sat, 28 Feb 2026 12:29:04 -0500 Message-ID: <20260228173244.1509663-632-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dikshita Agarwal [ Upstream commit 63c072e2937e6c9995df1b6a28523ed2ae68d364 ] On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could not handle a dummy device address for EOS buffers, so a NULL device address is sent instead. The existing check used IS_V6() alongside a firmware version gate: if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87)) fdata.device_addr =3D 0; else fdata.device_addr =3D 0xdeadb000; However, SC7280 which is also V6, uses a firmware string of the form "1.0.", which the version parser translates to 1.0.0. This unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)` condition on SC7280. Combined with IS_V6() matching there as well, the quirk is incorrectly applied to SC7280, causing VP9 decode failures. Constrain the check to IRIS2 (SM8250) only, which is the only platform that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This restores correct behavior on SC7280 (no forced NULL EOS buffer address). Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop comman= d") Cc: stable@vger.kernel.org Reported-by: Mecid Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222 Co-developed-by: Renjiang Han Signed-off-by: Renjiang Han Signed-off-by: Dikshita Agarwal Tested-by: Renjiang Han Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/venus/vdec.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platf= orm/qcom/venus/vdec.c index d0bd2d86a31f9..4cd69440e8753 100644 --- a/drivers/media/platform/qcom/venus/vdec.c +++ b/drivers/media/platform/qcom/venus/vdec.c @@ -565,7 +565,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v= 4l2_decoder_cmd *cmd) =20 fdata.buffer_type =3D HFI_BUFFER_INPUT; fdata.flags |=3D HFI_BUFFERFLAG_EOS; - if (IS_V6(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87)) + + /* Send NULL EOS addr for only IRIS2 (SM8250),for firmware <=3D 1.0.87. + * SC7280 also reports "1.0." parsed as 1.0.0; restricting to IRIS2 + * avoids misapplying this quirk and breaking VP9 decode on SC7280. + */ + + if (IS_IRIS2(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87)) fdata.device_addr =3D 0; else fdata.device_addr =3D 0xdeadb000; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 046A13FC0E9; Sat, 28 Feb 2026 17:43:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300591; cv=none; b=HHA26aO/Wyhfw9SVGaS2Cs0NI7JhGLY0H+RUjxCCDPTuu9LXrIQ6RcFdzCwNwx9kIbHeyHwRDch+WMyTldAzcspGJiqTxrphZ2f+5G6/lr78qMEb3e7NqyuHMw/vtK2ISm4rFK1HyTXq2GhwJyTu+r6D37mcHRPyT2eOwT2+pbg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300591; c=relaxed/simple; bh=GVG2CccgbtedmWaGhiaA33rg9BGO31x0WCbImzpyZac=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=blpKMltnK6YNpFzy1EriiM+UqyEzn+wXgmbohcY5cEQmnNnyEr6MapqRkcncC2yiSKjmvRT+59qG24UOQOmIo1NfUD3MMCw+Cbopg2v92LwooV0teK2td8XUye7me0h4j69hXy7wY3T0OgbfMmMhz2ZMvNXbXXj91Qray9M7jTY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wli8Tw/x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Wli8Tw/x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C5B7C19425; Sat, 28 Feb 2026 17:43:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300590; bh=GVG2CccgbtedmWaGhiaA33rg9BGO31x0WCbImzpyZac=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Wli8Tw/x/4Pwp1O3iUkkBVI7pCP2Ss/s55O55BVe+i7QST7DiefrxNwn5V43EiAtY qwd3bFFlz4AJmabyXMLuWm5a37QPyu3AhixxoYwC4pPTDofr17BpwVvVQ00ljcfKj2 CXARmANmIvMexMC1Zt9oLl3lSQobeXZcfEof1vMQxruJWo2OmBrvYTesrWLf5Zdi9x F0pI0tl7yNwDiwc9WmkTtpYCHd/RTgH0heQEfHjgaOMfsFkLc/kmwxOo5PzFiVFqbd yuA3DFjxJOQslXKjtLjAbqfUCf3NKlgPew4c3ozlQzlql+RUe9tvH4U+7c+yKwN8X0 kFX8Hs7OtK62w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dikshita Agarwal , Vikash Garodia , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 632/844] Revert "media: iris: Add sanity check for stop streaming" Date: Sat, 28 Feb 2026 12:29:05 -0500 Message-ID: <20260228173244.1509663-633-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dikshita Agarwal [ Upstream commit 370e19042fb8ac68109f8bdb0fdd8118baf39318 ] This reverts commit ad699fa78b59241c9d71a8cafb51525f3dab04d4. Revert the check that skipped stop_streaming when the instance was in IRIS_INST_ERROR, as it caused multiple regressions: 1. Buffers were not returned to vb2 when the instance was already in error state, triggering warnings in the vb2 core because buffer completion was skipped. 2. If a session failed early (e.g. unsupported configuration), the instance transitioned to IRIS_INST_ERROR. When userspace attempted to stop streaming for cleanup, stop_streaming was skipped due to the added check, preventing proper teardown and leaving the firmware in an inconsistent state. Fixes: ad699fa78b59 ("media: iris: Add sanity check for stop streaming") Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_vb2.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/media/platform/qcom/iris/iris_vb2.c b/drivers/media/pl= atform/qcom/iris/iris_vb2.c index db8768d8a8f61..139b821f7952f 100644 --- a/drivers/media/platform/qcom/iris/iris_vb2.c +++ b/drivers/media/platform/qcom/iris/iris_vb2.c @@ -231,8 +231,6 @@ void iris_vb2_stop_streaming(struct vb2_queue *q) return; =20 mutex_lock(&inst->lock); - if (inst->state =3D=3D IRIS_INST_ERROR) - goto exit; =20 if (!V4L2_TYPE_IS_OUTPUT(q->type) && !V4L2_TYPE_IS_CAPTURE(q->type)) @@ -243,10 +241,10 @@ void iris_vb2_stop_streaming(struct vb2_queue *q) goto exit; =20 exit: - if (ret) { - iris_helper_buffers_done(inst, q->type, VB2_BUF_STATE_ERROR); + iris_helper_buffers_done(inst, q->type, VB2_BUF_STATE_ERROR); + if (ret) iris_inst_change_state(inst, IRIS_INST_ERROR); - } + mutex_unlock(&inst->lock); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 31A8748C8B0; Sat, 28 Feb 2026 17:43:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300592; cv=none; b=iKJ7SgO0ECZAjUNBXho5aXSCSkKL9W9swsf/sHAzmBRqxTCcRLJj0b2DLEMZgIP9njFwBa5iVkEdZ78c032Z9Xv386IwhWFp3RSrwlSWzWRG20qjXq2D18qgjMXWBg51HNRuHb0+sTOPXTfku/KQ+433EOhz9xg9afPM1n75hDU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300592; c=relaxed/simple; bh=JeycNq1VemZIYqY51x/gy/WypAJZyGeGTg/g26vA578=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ar4T+ZTy5ekO5SVNuHkPMXKKVSL0X0tFXkQMZlOHQ4Jv4jDP1+OPe8KlyuoQqKoe+flVfZIwgLtA5LZ0O1TFF7n4DgGTEzkIbPfcHv5XBWVpmyhFgr/shlSvhUMk12JbtXxRBaP3cJH0ihcw7iVuy2Fdx4ViumNsXHqNvLZeFMM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A6YNI7N2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="A6YNI7N2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25750C19423; Sat, 28 Feb 2026 17:43:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300592; bh=JeycNq1VemZIYqY51x/gy/WypAJZyGeGTg/g26vA578=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A6YNI7N2R6n4TCZ8J65PRjXL0Ykun64f4WGUbmEnbeITBBZAh3mjwTs2HbMKmDm2Z UMzs2OzXwbxVYGUJ8TcI7LSLl4U2Rw+C9XyRWDdIQawp8W7qIG7fZTlRa3uuMsXdbJ KlBx9mbVLbh8H/hiOymTavmWsHAomJNBWDj1BU2dAF02kSiKAxVu+exxoxnieh+yOw QiaXryoE9/MZA/4RwS8Lh/3CZ4j3BTACuosA9wgzWmeiKYsTk8EGc5ejSudlLx/I9a KBciWxJgBOITHp1JDePw6KnaEiDQRIQiZBld+DwPYG01J25w8Ap9yzNLHD8WkwhXDl JpnSMBxwhacAw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vishnu Reddy , Dikshita Agarwal , Bryan O'Donoghue , Vikash Garodia , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 633/844] media: iris: Fix ffmpeg corrupted frame error Date: Sat, 28 Feb 2026 12:29:06 -0500 Message-ID: <20260228173244.1509663-634-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vishnu Reddy [ Upstream commit 89f7cf35901138d9828d981ce64c131a3da6e867 ] When the ffmpeg decoder is running, the driver receives the V4L2_BUF_FLAG_KEYFRAME flag in the input buffer. The driver then forwards this flag information to the firmware. The firmware, in turn, copies the input buffer flags directly into the output buffer flags. Upon receiving the output buffer from the firmware, the driver observes that the buffer contains the HFI_BUFFERFLAG_DATACORRUPT flag. The root cause is that both V4L2_BUF_FLAG_KEYFRAME and HFI_BUFFERFLAG_DATACORRUPT are the same value. As a result, the driver incorrectly interprets the output frame as corrupted, even though the frame is actually valid. This misinterpretation causes the driver to report an error and skip good frames, leading to missing frames in the final video output and triggering ffmpeg's "corrupt decoded frame" error. To resolve this issue, the input buffer flags should not be sent to the firmware during decoding, since the firmware does not require this information. Fixes: 17f2a485ca67 ("media: iris: implement vb2 ops for buf_queue and firm= ware response") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy Reviewed-by: Dikshita Agarwal Reviewed-by: Bryan O'Donoghue Reviewed-by: Vikash Garodia Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c b/dri= vers/media/platform/qcom/iris/iris_hfi_gen1_command.c index 52da7ef7bab08..b6261d186d215 100644 --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c @@ -282,7 +282,7 @@ static int iris_hfi_gen1_queue_input_buffer(struct iris= _inst *inst, struct iris_ com_ip_pkt.shdr.session_id =3D inst->session_id; com_ip_pkt.time_stamp_hi =3D upper_32_bits(buf->timestamp); com_ip_pkt.time_stamp_lo =3D lower_32_bits(buf->timestamp); - com_ip_pkt.flags =3D buf->flags; + com_ip_pkt.flags =3D 0; com_ip_pkt.mark_target =3D 0; com_ip_pkt.mark_data =3D 0; com_ip_pkt.offset =3D buf->data_offset; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 38DFE3FC8B8; Sat, 28 Feb 2026 17:43:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300593; cv=none; b=aYyeRsB98f9tLbmpX1PttVNhO6UlNlpVSHqJfkmJPz+Dz+kj5b3hTfJ5hZEuRvN71YsACpRT094XPvEK6jZHqRFMb6xoC0Y462gyB3erc/HkB1V5io1wr977Jy5vCvYxatQ1ciN2UP4B/tFDl4H4uF6fPLyVx0gNq84/dzTpaJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300593; c=relaxed/simple; bh=EFZIfroVRKxAPaQYojJzhoqbjti53m4439xZKaFIDzs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ydv4snKUI9X0MSRlXayLrRF6P87iOLHouhz5dhJzMrW1liwIVoflykqgz9NlPdIyXpR9X06PDmCzgMxi3/O5u7ENCGvVXXaa+AxlCaW/xE8YW6iYwvaorkhHzQFzOG3uGcBmyFS8BXgSWTro643r8sco1IUDdVXNlMdYdbqyZhM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CCfwKR9a; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CCfwKR9a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 560D5C116D0; Sat, 28 Feb 2026 17:43:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300593; bh=EFZIfroVRKxAPaQYojJzhoqbjti53m4439xZKaFIDzs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CCfwKR9aNEsvL3oYBsh8JkPFpdAV1Gz1LBNxuJxMP/gJFdH8j/h1RE/irVxMLOQeH cfBiYMsVk26RJdTThT9GsdbTkBTmJBfCLrzqwip4ByYZvBbAVK6k0obl0/oVA9795c 0qt5pZVerdAdPY0hqhB/ynCDhANu1GBXZxnVwzENvj2Xajy48ZmLXotptstiQt5Cu8 qq7kIm79zAg0MGbHGNYQEcPrh1mwSgQtMha2jdeCRzXxbQlgS+mAZmgnQhTQCUdDNM 95QvpNIKe657WEE1fMpvzwOEtPk92QK973Qc5wh9+PKY/bchRuk8ajBRi+3bNMbuak y5+zjP7x9aG9Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ricardo Ribalda , Dikshita Agarwal , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 634/844] media: iris: Fix fps calculation Date: Sat, 28 Feb 2026 12:29:07 -0500 Message-ID: <20260228173244.1509663-635-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ricardo Ribalda [ Upstream commit 71fe80364a6584f404556ac9a6a4aca4ab80fb5b ] iris_venc_s_param() uses do_div to divide two 64 bits operators, this is wrong. Luckily for us, both of the operators fit in 32 bits, so we can use a normal division. Now that we are at it, mark the fps smaller than 1 as invalid, the code does not seem to handle them properly. The following cocci warning is fixed with this patch: ./platform/qcom/iris/iris_venc.c:378:1-7: WARNING: do_div() does a 64-by-32= division, please consider using div64_u64 instead Fixes: 4ff586ff28e3 ("media: iris: Add support for G/S_PARM for encoder vid= eo device") Reviewed-by: Dikshita Agarwal Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_venc.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/media/platform/qcom/iris/iris_venc.c b/drivers/media/p= latform/qcom/iris/iris_venc.c index 5830eba93c68b..0ed5018f9fe33 100644 --- a/drivers/media/platform/qcom/iris/iris_venc.c +++ b/drivers/media/platform/qcom/iris/iris_venc.c @@ -382,8 +382,7 @@ int iris_venc_s_param(struct iris_inst *inst, struct v4= l2_streamparm *s_parm) struct v4l2_fract *timeperframe =3D NULL; u32 default_rate =3D DEFAULT_FPS; bool is_frame_rate =3D false; - u64 us_per_frame, fps; - u32 max_rate; + u32 fps, max_rate; =20 int ret =3D 0; =20 @@ -405,23 +404,19 @@ int iris_venc_s_param(struct iris_inst *inst, struct = v4l2_streamparm *s_parm) timeperframe->denominator =3D default_rate; } =20 - us_per_frame =3D timeperframe->numerator * (u64)USEC_PER_SEC; - do_div(us_per_frame, timeperframe->denominator); - - if (!us_per_frame) + fps =3D timeperframe->denominator / timeperframe->numerator; + if (!fps) return -EINVAL; =20 - fps =3D (u64)USEC_PER_SEC; - do_div(fps, us_per_frame); if (fps > max_rate) { ret =3D -ENOMEM; goto reset_rate; } =20 if (is_frame_rate) - inst->frame_rate =3D (u32)fps; + inst->frame_rate =3D fps; else - inst->operating_rate =3D (u32)fps; + inst->operating_rate =3D fps; =20 if ((s_parm->type =3D=3D V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && vb2_is_stre= aming(src_q)) || (s_parm->type =3D=3D V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE && vb2_is_str= eaming(dst_q))) { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A1D03FC8D8; Sat, 28 Feb 2026 17:43:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300594; cv=none; b=SOPJQpu7VL09XZ+P3K/yVuZixizvN+3ZDT6AoulGEmeryAPVGx2EbxWjyL6VrmnlRECm0PBEGDu5J4lThr5x408Iuvot9wrMQSU0MAUw+ziBBb9rWp1HNT9Y2JrXEg5B+caEZEHTN9eiRamkvgo83y033NHYvDL+gCh2lG+oxAk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300594; c=relaxed/simple; bh=pJq8t6Ws/PvBHxR7cZl+uRcxF+RXoBmnA2nHyPPEK2g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JZ+p/klDI5rWsclrJ75lcKzuUzqKPqdkii/xm+0gzqRskFkPv4rsYBcRWqExxgK/4icb2z3IuKnOvdNtjAIVabokHAmAEKHZ4d7Ho/IIF88noapvmN1WImce2E7HzBPeyPCKmMHzKtb1YySwUHkqq+kn9XP9BozCkGCFnh68P/k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HVsPykAi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HVsPykAi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D4B2C19423; Sat, 28 Feb 2026 17:43:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300594; bh=pJq8t6Ws/PvBHxR7cZl+uRcxF+RXoBmnA2nHyPPEK2g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HVsPykAihacylnuduqv0BWIpD6Yw3a06rT3BgREeuSkxYovoiQCkZbtnHVK5eBCoR cbQTR/7t8ULdpgcSEPREwHbWoELVpy7dOvDg3n6G05gLd0sOIOUNDXy83ADO/RpC4b ZNi5GF9Sbpj6fBb2crmRf+Q5rVpEFIKWBz2jyTerf74dZQhRrKLdvhCo5mywnqKEQF NFBYjS/IlMd4g4toiYaneyFNyyH2mOAaBEeOooXC15LttOEr+0HSr55jZnKFiNl/N9 tcBtAmyyrQqgs1Q4PpmHd7P7QEnEEl8QaUkPRQcQTvEhkyg6avhiONWfHBswY1sq9I BrU7dYRRXCy+g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Val Packett , Dikshita Agarwal , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 635/844] media: iris: use fallback size when S_FMT is called without width/height Date: Sat, 28 Feb 2026 12:29:08 -0500 Message-ID: <20260228173244.1509663-636-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Val Packett [ Upstream commit 4980721cb97d6c47700ab61a048ac8819cfeec87 ] According to 4.5.1.5 of the M2M stateful decoder UAPI documentation, providing the width and the height to S_FMT is "required only if it cannot be parsed from the stream", otherwise they can be left as 0 and the S_FMT implementation is expected to return a valid placeholder resolution that would let REQBUFS succeed. iris was missing the fallback, so clients like rpi-ffmpeg wouldn't work. Fix by adding an explicit fallback to defaults. Fixes: b530b95de22c ("media: iris: implement s_fmt, g_fmt and try_fmt ioctl= s") Link: https://github.com/jc-kynesim/rpi-ffmpeg/issues/103 Reviewed-by: Dikshita Agarwal Signed-off-by: Val Packett Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_vdec.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/media/platform/qcom/iris/iris_vdec.c b/drivers/media/p= latform/qcom/iris/iris_vdec.c index 69ffe52590d3a..227e4e5a326fd 100644 --- a/drivers/media/platform/qcom/iris/iris_vdec.c +++ b/drivers/media/platform/qcom/iris/iris_vdec.c @@ -231,6 +231,14 @@ int iris_vdec_s_fmt(struct iris_inst *inst, struct v4l= 2_format *f) if (vb2_is_busy(q)) return -EBUSY; =20 + /* Width and height are optional, so fall back to a valid placeholder + * resolution until the real one is decoded from the bitstream. + */ + if (f->fmt.pix_mp.width =3D=3D 0 && f->fmt.pix_mp.height =3D=3D 0) { + f->fmt.pix_mp.width =3D DEFAULT_WIDTH; + f->fmt.pix_mp.height =3D DEFAULT_HEIGHT; + } + iris_vdec_try_fmt(inst, f); =20 switch (f->type) { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67FD83FD120; Sat, 28 Feb 2026 17:43:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300595; cv=none; b=eRDtSU7LxArAI2DPWBSusyE7H1KycWU/a7tbUpOLFtUZB5mD/zEYZwkGh+RZ9JFX+TyQKbKCzlsoMPVWQ8CqCbMxHqt0HqfuWSfltodYl160C0L3Deoh0IfOmE+j5uGI5CVz9+uRtLEcNTpI6MMuJs5vMLHsNZJMgeEKjs5zWMI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300595; c=relaxed/simple; bh=9SdAbGTyxiHRr9z7FUYyDx8TqImnTtSL8+GW7cSOGk0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nsJTT2izgCuawJhjGfB5lMQb0TxGLkkfxSxeqjHxrjsFmqzF7pvToTlhNvq6dqkfX/K5kC2rfC8nkRwzCxS6d2cbNonMD40kXBjz5zuWZ9PQWusyFoTcsaUZePMBJDn8sJVX9H0KPQNAAF3Q02bCzd7hMFUzPPpnqTu4P/9YbEc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p2aXJbiE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p2aXJbiE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6563BC19424; Sat, 28 Feb 2026 17:43:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300595; bh=9SdAbGTyxiHRr9z7FUYyDx8TqImnTtSL8+GW7cSOGk0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p2aXJbiEg/5vx5PHUpjEL3EqdF1WZlrRL7nSxK+Gb66FIXDKa5GrRWYbs2BgUtVF1 MX0uhq+qz5ogqvaS+Aeq8I42QXalEX1vqi1K3iCcwgTy5I7b10YyyjIqsTwMrN6rd2 gGQ8nW9869fLN/U3aNPGt3j4ih87iSftSf5BBRR37gCB1S9c1lEStZVEgroWQl/HWJ ZIT0eKyDvLuSCBZLtJLp33nsoGdDx/7AyHH73imSLNxTeCAfrsX6EEBlhPjpks54hG UjOxPc8qxAPzzxl4zhqkUgrleMTTAK2bwx1xbNE/kzoUD9sK7iX/EiqTent+QrpZMq vDxx9/lgUbMUg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dikshita Agarwal , Vikash Garodia , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 636/844] media: iris: remove v4l2_m2m_ioctl_{de,en}coder_cmd API usage during STOP handling Date: Sat, 28 Feb 2026 12:29:09 -0500 Message-ID: <20260228173244.1509663-637-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dikshita Agarwal [ Upstream commit 8fc707d13df517222db12b465af4aa9df05c99e1 ] Currently v4l2_m2m_ioctl_{de,enc}coder_cmd is being invoked during STOP command handling. However, this is not required as the iris driver has its own drain and stop handling mechanism in place. Using the m2m command API in this context leads to incorrect behavior, where the LAST flag is prematurely attached to a capture buffer, when there are no buffers in m2m source queue. But, in this scenario even though the source buffers are returned to client, hardware might still need to process the pending capture buffers. Attaching LAST flag prematurely can result in the capture buffer being removed from the destination queue before the hardware has finished processing it, causing issues when the buffer is eventually returned by the hardware. To prevent this, remove the m2m API usage in stop handling. Fixes: d09100763bed ("media: iris: add support for drain sequence") Fixes: 75db90ae067d ("media: iris: Add support for drain sequence in encode= r video device") Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_vidc.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/qcom/iris/iris_vidc.c b/drivers/media/p= latform/qcom/iris/iris_vidc.c index c9b881923ef18..0c9c23ef2d180 100644 --- a/drivers/media/platform/qcom/iris/iris_vidc.c +++ b/drivers/media/platform/qcom/iris/iris_vidc.c @@ -572,9 +572,10 @@ static int iris_dec_cmd(struct file *filp, void *fh, =20 mutex_lock(&inst->lock); =20 - ret =3D v4l2_m2m_ioctl_decoder_cmd(filp, fh, dec); - if (ret) + if (dec->cmd !=3D V4L2_DEC_CMD_STOP && dec->cmd !=3D V4L2_DEC_CMD_START) { + ret =3D -EINVAL; goto unlock; + } =20 if (inst->state =3D=3D IRIS_INST_DEINIT) goto unlock; @@ -605,9 +606,10 @@ static int iris_enc_cmd(struct file *filp, void *fh, =20 mutex_lock(&inst->lock); =20 - ret =3D v4l2_m2m_ioctl_encoder_cmd(filp, fh, enc); - if (ret) + if (enc->cmd !=3D V4L2_ENC_CMD_STOP && enc->cmd !=3D V4L2_ENC_CMD_START) { + ret =3D -EINVAL; goto unlock; + } =20 if (inst->state =3D=3D IRIS_INST_DEINIT) goto unlock; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BD8C3FD141; Sat, 28 Feb 2026 17:43:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300596; cv=none; b=aeB7KA7dsQBqzh0PHuV4S5wC3LC819sV1HzHoq2hQRRrTrISkrULdGBfzrvn009sOpkhRn+9AS/MoSsesz2hiLKeCUzMePycJyimMsjhgK1gJ/+4elDJn8TRPt3KEZt4C7P0w/rbRoBmrodbAFCXOHuN4tSM36gSL54QGsO9MII= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300596; c=relaxed/simple; bh=V/V23XxPPBDthWFzxgqXCSPcOAVXBDcSfJsMbZck7pU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XJMWFjpIEPRVgSp5xwGssCQhI+RyY7ULrtG4UNYrhDvC7rQPTnspEErtL0qxZMdDVlyvf7G80oSwPW8PHgbwKg0BpMXJSg9avLhbyjZ5UzkgDERDUJVh5Nqmh7muhjmXnbfC69c4gPpBbmLgd8zJviwG69orjuDMlZX/Msfn3fY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Hynd6rnH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Hynd6rnH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 712ACC19423; Sat, 28 Feb 2026 17:43:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300596; bh=V/V23XxPPBDthWFzxgqXCSPcOAVXBDcSfJsMbZck7pU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hynd6rnHHY1kjHulV63a273PtJl8C4aEPHAnuSyPrT8ePDAAxUteNX5L4gFIXxNAk RIBJcjKZXhnabcvQoFdMolx7sU5l9jG5Nc2oZExdx0RXMGLKaD0xTb88Y8vkmMvHSY SRU0E64NUvA2K7UdrQYK9eKUIspXzl6MTUKvLh5IuoewAukkMMG2qPAmp8jVTqHcU8 i+K6Rzj2yeHKblbZNs+NAn++VyAO66yFytSxx4a3O3RRy+DcB0atykIY46KPD10APO nTufg3/BSu9vp2spWMd/kDUZOVYTEv0XrBs4ETl3GSXqcAgF34H7pBf95TFFRODuzv TQFl6G5f7dsPQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dikshita Agarwal , Vikash Garodia , Konrad Dybcio , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 637/844] media: iris: Add missing platform data entries for SM8750 Date: Sat, 28 Feb 2026 12:29:10 -0500 Message-ID: <20260228173244.1509663-638-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dikshita Agarwal [ Upstream commit bbef55f414100853d5bcea56a41f8b171bac8fcb ] Two platform-data fields for SM8750 were missed: - get_vpu_buffer_size =3D iris_vpu33_buf_size Without this, the driver fails to allocate the required internal buffers, leading to basic decode/encode failures during session bring-up. - max_core_mbps =3D ((7680 * 4320) / 256) * 60 Without this capability exposed, capability checks are incomplete and v4l2-compliance for encoder fails. Fixes: a5925a2ce077 ("media: iris: add VPU33 specific encoding buffer calcu= lation") Fixes: a6882431a138 ("media: iris: Add support for ENUM_FRAMESIZES/FRAMEINT= ERVALS for encoder") Cc: stable@vger.kernel.org Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Reviewed-by: Konrad Dybcio Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_platform_gen2.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen2.c b/driver= s/media/platform/qcom/iris/iris_platform_gen2.c index c1989240c2486..00d1d55463179 100644 --- a/drivers/media/platform/qcom/iris/iris_platform_gen2.c +++ b/drivers/media/platform/qcom/iris/iris_platform_gen2.c @@ -915,6 +915,7 @@ const struct iris_platform_data sm8750_data =3D { .get_instance =3D iris_hfi_gen2_get_instance, .init_hfi_command_ops =3D iris_hfi_gen2_command_ops_init, .init_hfi_response_ops =3D iris_hfi_gen2_response_ops_init, + .get_vpu_buffer_size =3D iris_vpu33_buf_size, .vpu_ops =3D &iris_vpu35_ops, .set_preset_registers =3D iris_set_sm8550_preset_registers, .icc_tbl =3D sm8550_icc_table, @@ -945,6 +946,7 @@ const struct iris_platform_data sm8750_data =3D { .num_vpp_pipe =3D 4, .max_session_count =3D 16, .max_core_mbpf =3D NUM_MBS_8K * 2, + .max_core_mbps =3D ((7680 * 4320) / 256) * 60, .dec_input_config_params_default =3D sm8550_vdec_input_config_params_default, .dec_input_config_params_default_size =3D --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7000F3FD15A; Sat, 28 Feb 2026 17:43:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300597; cv=none; b=DbvhhwIrQ3Sm2hCP31Tna8ucySrR5gJDosqYPk8foVUGMBQn/OAVDk7nOUNH1EGodLuZOsAIqkQflULe70LVsUdpMiiHzX7yillrNbcAC2yiJcjcrRka9h0xKWogofKA4WwXii2qHAlx15/y8IkZexsxhiOdQgQtLMSdulOR5Ig= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300597; c=relaxed/simple; bh=/K1y+ZFChZi8Am+ZS0Tvw7xs44reTOVZ/28KbEPHIH0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l9TsGoEFmyyvt664n193XZ6ND85qAl1o47AFothn9Fni4wk+LGvgiwRwFEiF9KfPKr1CA1+IOZogXEEw/+p9SikpGVPpmQAuZHVtQnD+JpzgnM8d9yQE4FXFhMuCtlDLV+tJ9mcXFEowpjPvC0ZczmfOts99bu3h8zJf5EyCFfQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NqFh97B8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NqFh97B8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90BCBC2BC9E; Sat, 28 Feb 2026 17:43:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300597; bh=/K1y+ZFChZi8Am+ZS0Tvw7xs44reTOVZ/28KbEPHIH0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NqFh97B8DU8Dk17w1qmivDs8stsoHGvPeyVcWJ/evivHTx0UX2R9d0giG/N1WQx8r wz0e5PRaeVF4F4gBUDrg2Axs1XKQ/WqjFGtqVI4+umPhT9CVWyMj7sBB2H7XHrra29 pXZbfS6Ilk+ZLX03mNtlW3Nkw4Cnf8JJ3YauwnAFdXCm36+5/5tIuXzKtPSmd9x9Ys R49G6vXgFibYyvJYICWFCBrdUZwgZ9XT7LIJzGCVrfC5RcjD0hnzFKzOlNum7u53p/ +gw4dwBnF128GYPBTVdMlr4a1VTOJscQ4Z4lKl3tzsbbOOeJ5nOWHwLuZYpgVr//vc 8Miwjei6lbZgw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dikshita Agarwal , Bryan O'Donoghue , Vikash Garodia , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 638/844] media: iris: Add buffer to list only after successful allocation Date: Sat, 28 Feb 2026 12:29:11 -0500 Message-ID: <20260228173244.1509663-639-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dikshita Agarwal [ Upstream commit 2d0bbd982dfdd67da488a772f7a8a1bdca7642bf ] Move `list_add_tail()` to after `dma_alloc_attrs()` succeeds when creating internal buffers. Previously, the buffer was enqueued in `buffers->list` before the DMA allocation. If the allocation failed, the function returned `-ENOMEM` while leaving a partially initialized buffer in the list, which could lead to inconsistent state and potential leaks. By adding the buffer to the list only after `dma_alloc_attrs()` succeeds, we ensure the list contains only valid, fully initialized buffers. Fixes: 73702f45db81 ("media: iris: allocate, initialize and queue internal = buffers") Reviewed-by: Bryan O'Donoghue Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_buffer.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media= /platform/qcom/iris/iris_buffer.c index b89b1ee06cce1..f1f003a787bf2 100644 --- a/drivers/media/platform/qcom/iris/iris_buffer.c +++ b/drivers/media/platform/qcom/iris/iris_buffer.c @@ -351,12 +351,15 @@ static int iris_create_internal_buffer(struct iris_in= st *inst, buffer->index =3D index; buffer->buffer_size =3D buffers->size; buffer->dma_attrs =3D DMA_ATTR_WRITE_COMBINE | DMA_ATTR_NO_KERNEL_MAPPING; - list_add_tail(&buffer->list, &buffers->list); =20 buffer->kvaddr =3D dma_alloc_attrs(core->dev, buffer->buffer_size, &buffer->device_addr, GFP_KERNEL, buffer->dma_attrs); - if (!buffer->kvaddr) + if (!buffer->kvaddr) { + kfree(buffer); return -ENOMEM; + } + + list_add_tail(&buffer->list, &buffers->list); =20 return 0; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 783493FD8C7; Sat, 28 Feb 2026 17:43:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300598; cv=none; b=TDOabG9G0d8kc3IN+acvmQvzHsCQY2EAIHHgh9uxW5WuC9WWnEr5IetT5cQ0zxvTI/+/NgrYO/Ql8AUwgB/t/uOr5R9hDOxcy8FDDz83oc2bGPX+h4hw2E8EPe+vJtPDjq9WDQ2YHVSJnGiGwVWM3p7AL1yTLnMc1+xkPdOI2DA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300598; c=relaxed/simple; bh=n0PXaKyAqNUZPAHd67/QmjvwzkMs1oyIMBBXVPbsPcA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ixF3HyncCzvxSHFh4+FdE+9aYZ6s1KiHbRS7UShItg6XSDiMd0pCUjP745pL+ert/zz1ujVmKPdrP9PTxNRnUY0DGhAfF8LeAE0Yzg6GG2FmryVRhfkAqEK+Mdx19VvZCJ3OMzXgWDESHllXwksHq7j6NaTCUOSd9bjjVL96qUs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GJrlSx02; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GJrlSx02" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96EB3C19424; Sat, 28 Feb 2026 17:43:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300598; bh=n0PXaKyAqNUZPAHd67/QmjvwzkMs1oyIMBBXVPbsPcA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GJrlSx02tXOapJ43fFgpB5jfcl0VlgX108aMvHXtrqQGJxUMf7ezaM5M8YiDQVAWf 0xwKlskZ0FsfHfLzVYvuc0QOWN80BcLqWfovqZ+Oq6WFZT5oQ6CFKW1t7pYd4sgeoo v0ZXYni+8xKGi4o+LuWTy8R9qG95ytbMpUEnBiZ9PM/uUf7DSS+I+lFLOkx8HRa2a+ GB5+yUAYGkCysSSO/dO7VC/3eDsd8gBlfsLnf3hayy8ot5eKBZa7PowczFR7TJgiHA ZPevrAK1f0U2PaVbg7zsitWRTgFmW+I7K1ZyLWOT/q1Dm9hj4BjRoINZ7vgXUShvRS BYe/UCbvxstHA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dikshita Agarwal , Bryan O'Donoghue , Vikash Garodia , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 639/844] media: iris: Skip resolution set on first IPSC Date: Sat, 28 Feb 2026 12:29:12 -0500 Message-ID: <20260228173244.1509663-640-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dikshita Agarwal [ Upstream commit 811dbc546f47559dc9d2098c612acfd47e32479e ] The resolution property is not supposed to be set during reconfig. Existing iris_drc_pending(inst) check is insufficient, as it doesn't cover the first port setting change. Extend the conditional check to also skip resolution setting when the instance is in IRIS_INST_SUB_FIRST_IPSC. Fixes: caf205548769 ("media: iris: Avoid updating frame size to firmware du= ring reconfig") Reviewed-by: Bryan O'Donoghue Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c b/dri= vers/media/platform/qcom/iris/iris_hfi_gen1_command.c index b6261d186d215..1c107daca9e89 100644 --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c @@ -733,7 +733,7 @@ static int iris_hfi_gen1_set_resolution(struct iris_ins= t *inst, u32 plane) struct hfi_framesize fs; int ret; =20 - if (!iris_drc_pending(inst)) { + if (!iris_drc_pending(inst) && !(inst->sub_state & IRIS_INST_SUB_FIRST_IP= SC)) { fs.buffer_type =3D HFI_BUFFER_INPUT; fs.width =3D inst->fmt_src->fmt.pix_mp.width; fs.height =3D inst->fmt_src->fmt.pix_mp.height; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9307D3FD8E7; Sat, 28 Feb 2026 17:43:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300599; cv=none; b=rZU9j0V8a6AL6YTXMxZWt69NFCtdX80z+ewDw0Y5Rnx7Wp7IY8ZXS8dydW4AaSJKlz/qYTW4T+adWMjgnuLMa6HliAg+l6O9ENjHJzlnPyspaI7ISQrVbxWc+aV9YuWeYsCuuE7eW22+40PLkQ/S/2C8wX2Dv7PrPLkbQH6x90Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300599; c=relaxed/simple; bh=GKzwqxHBGQfxQn1X+IxwJTAomcaHxn/exreFipPVGf0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GLZaFGKnLR6S1cXWaSQUoWus+MriTBzFawpfOO1lGdrOEUsXIcv25Nb+oBvSWth/ynpfApmpjnLWCQcVMhvGeJ55GTVba5zAWWyXbq2FYkY1aUePV/YCq0AZJNygoxQnAqmUjT3l3SGVrZpsHrvXj/f8UnaqGr1T87wd8cCoFQ8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qzXJ8CHC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qzXJ8CHC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F2CAC2BC87; Sat, 28 Feb 2026 17:43:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300599; bh=GKzwqxHBGQfxQn1X+IxwJTAomcaHxn/exreFipPVGf0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qzXJ8CHCL75EQgvm6Oe5HJjTYSuOLWn7T07xJpulktGbKD64ALk/xbnxmn8l7f3+L +DBNQTNBrxL/+U4xKV8trKYYTwaBPjI0GwUeGq7Bz5h9ozM4u6id9bC8wKEY+Kg05G 6HiuLy/U3R40RKxC7oBXx5gyf02KIon+je5VIrbhQxK8Abu159aiklEFJ2P6+lDocz uHE/DcB0GXdFolxq5sw0X/8bzMb4oRR/S5wJVIIjUIkJlL+XA35DICS+YbBEfBnXup u1n50fzM83XNdLitnKQnsnMO9/e8m2YEmgbMbQzCwioSQ7Ek4w3Uk9A8veOGUtNI1O PvmH8qVBMaZ5Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dikshita Agarwal , Bryan O'Donoghue , Vikash Garodia , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 640/844] media: iris: gen1: Destroy internal buffers after FW releases Date: Sat, 28 Feb 2026 12:29:13 -0500 Message-ID: <20260228173244.1509663-641-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dikshita Agarwal [ Upstream commit 1dabf00ee206eceb0f08a1fe5d1ce635f9064338 ] After the firmware releases internal buffers, the driver was not destroying them. This left stale allocations that were no longer used, especially across resolution changes where new buffers are allocated per the updated requirements. As a result, memory was wasted until session close. Destroy internal buffers once the release response is received from the firmware. Fixes: 73702f45db81 ("media: iris: allocate, initialize and queue internal = buffers") Reviewed-by: Bryan O'Donoghue Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c b/dri= vers/media/platform/qcom/iris/iris_hfi_gen1_command.c index 1c107daca9e89..11815f6f5bacd 100644 --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c @@ -441,6 +441,8 @@ static int iris_hfi_gen1_session_unset_buffers(struct i= ris_inst *inst, struct ir goto exit; =20 ret =3D iris_wait_for_session_response(inst, false); + if (!ret) + ret =3D iris_destroy_internal_buffer(inst, buf); =20 exit: kfree(pkt); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A2EB83FD141; Sat, 28 Feb 2026 17:43:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300600; cv=none; b=J5j2678zfAeU7/VG+3Isy37+Gvw5mstjI78X5lCoj8cmqiF2uL5J41wvN36Dl0SkUPaeDiQ9Vb927c7562L3EQWhRlln9W3MFaU0VOU7EG36waGqUeWsGMRtOBFJ/Qmv96dfBld/G4lrIX9EYBm+hzdkr5GFpGQmeSafG0w6qM4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300600; c=relaxed/simple; bh=AZImeR0YUVahPau8OXj+N1rcm15viZGdfIpYWF1HP0o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VvYn+mQhZmWTcqkYtjgPvr2zCizI1wevVRt4c49ZfD9zTjO+7w7sA9McK57Hhvx1eCZavoelnfpiEUvFl7eRP6tuM38zqDcrfhay3uC68JniQAJ//1x2vUQ4o9MpOIoMjJap+VP3KpwXcxZ67rpLaB3+n1PQQjwglXSOsUxg8SM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=h6eRFul/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="h6eRFul/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BADFDC19423; Sat, 28 Feb 2026 17:43:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300600; bh=AZImeR0YUVahPau8OXj+N1rcm15viZGdfIpYWF1HP0o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=h6eRFul/+28XipuVb2iqRZ3xDvGr4ULcP8R13Esu2/4b6tG+FNzqXRfHfi9XslhkM 2GRnu/9oWXIk5uYlQf5Pc06JE467c1G2hTRWLVv4MM7WUbys55RmENnRgJSKyfj4Y0 XdY5eKXiW2ki7KNdEeJuq5/ntgUXaGLFxV0WxvcyZfI3NaeyUoyLhoyHBADnm/7fZd tFXuM+dd6IkArV5CV6o75wvZonR33zzqtTzmXzKbAFMn5ruNoevS6ACxY6pk4OnXm/ FG20pvZTjti68QIqcynIJ6Fw3WcyAOJMC4iSA4UhJLlWsvPcn6f/NBfwRKJUxoTRkx 7MaDuU+2rgn3g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dikshita Agarwal , Vikash Garodia , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 641/844] media: iris: gen2: Add sanity check for session stop Date: Sat, 28 Feb 2026 12:29:14 -0500 Message-ID: <20260228173244.1509663-642-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dikshita Agarwal [ Upstream commit 9aa8d63d09cfc44d879427cc5ba308012ca4ab8e ] In iris_kill_session, inst->state is set to IRIS_INST_ERROR and session_close is executed, which will kfree(inst_hfi_gen2->packet). If stop_streaming is called afterward, it will cause a crash. Add a NULL check for inst_hfi_gen2->packet before sendling STOP packet to firmware to fix that. Fixes: 11712ce70f8e ("media: iris: implement vb2 streaming ops") Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c b/dri= vers/media/platform/qcom/iris/iris_hfi_gen2_command.c index f912955320992..31e8fc7f8295d 100644 --- a/drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c @@ -963,6 +963,9 @@ static int iris_hfi_gen2_session_stop(struct iris_inst = *inst, u32 plane) struct iris_inst_hfi_gen2 *inst_hfi_gen2 =3D to_iris_inst_hfi_gen2(inst); int ret =3D 0; =20 + if (!inst_hfi_gen2->packet) + return -EINVAL; + reinit_completion(&inst->completion); =20 iris_hfi_gen2_packet_session_command(inst, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 089423FE05C; Sat, 28 Feb 2026 17:43:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300602; cv=none; b=aVWsRowQsRBkM87aVtpDMdflL0C4d3WRvTeNEh3dY3aRYRhqlbEffPwGQaBRqmOAGx+K3oMk7ULdeI/OQZK9i71BVLcAKAMuQVFBhf3eMWpKNbi7Ba4MtIHisAo71IyosQWXHgeFwPQQGX4z7zrgw7sbjuMttLNhT8uW+SHLgdU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300602; c=relaxed/simple; bh=lUk5O7eESbsqaWrLs1QVzAae7+Xwt4nGb9/uTpw8K34=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qJ4zFeRABGb0KI2eBimhard73igQ/Hxg5wK0fCIw6xYIoac90m5rxVdJmm6sw1Ovn1LhQqeWr0vUm+aKZ/aFQUW0Mk49vt9rWeGtY3mJHNB78Wu7pOF7eNOwS/NY8WEpiyCaImRR6a5mZAVSVko3rnYjnDZt2jpMIAjqC+UxtGo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AcqBfxSf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AcqBfxSf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4D4BC19424; Sat, 28 Feb 2026 17:43:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300601; bh=lUk5O7eESbsqaWrLs1QVzAae7+Xwt4nGb9/uTpw8K34=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AcqBfxSf27rj7WlMzXk+rUQBc1o7O+BIOVZlVdON9VfbKzCqCmQFZ2tOWde+U1doM ra0FvN9B6Qc5dRz2oTsEzI2dKjr2QmaLTl6GZmXMcGcks55yiThE7+DFUi22zdYo8n HeM/uVaVuxGvAwtRZM3GlgYtiHLb/ykulQkBKZYRVeRcFBWmKk6rexTjCW/rRBDnBu k6epspqiijwdEXKSHcWLKBe/YgSIaYYVhdeZNvpbg9nBClico6Eyyk/LifR/SA5w5w DEEMf0tTOZ4ZnRfELtTcF9jif5Qzs6Dl3Q2txZgJrjY0gQB9Dk8C6FdZEPFTP+tr+n Lu5qAS3dV4tkw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vishnu Reddy , Dikshita Agarwal , Vikash Garodia , Bryan O'Donoghue , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 642/844] media: iris: Prevent output buffer queuing before stream-on completes Date: Sat, 28 Feb 2026 12:29:15 -0500 Message-ID: <20260228173244.1509663-643-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vishnu Reddy [ Upstream commit 2c73cfd0cfc44ffe331ccb81f6ac45fc399d9ddb ] During normal playback, stream-on for input is followed by output, and only after input stream-on does actual streaming begin. However, when gst-play performs a seek, both input and output streams are stopped, and on restart, output stream-on occurs first. At this point, firmware has not yet started streaming. Queuing output buffers before the firmware begins streaming causes it to process buffers in an invalid state, leading to an error response. These buffers are returned to the driver as errors, forcing the driver into an error state and stopping playback. Fix this by deferring output buffer queuing until stream-on completes. Input buffers can still be queued before stream-on as required. Fixes: 92e007ca5ab6 ("media: iris: Add V4L2 streaming support for encoder v= ideo device") Signed-off-by: Vishnu Reddy Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/platform/qcom/iris/iris_vb2.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/qcom/iris/iris_vb2.c b/drivers/media/pl= atform/qcom/iris/iris_vb2.c index 139b821f7952f..bf0b8400996ec 100644 --- a/drivers/media/platform/qcom/iris/iris_vb2.c +++ b/drivers/media/platform/qcom/iris/iris_vb2.c @@ -193,10 +193,14 @@ int iris_vb2_start_streaming(struct vb2_queue *q, uns= igned int count) buf_type =3D iris_v4l2_type_to_driver(q->type); =20 if (inst->domain =3D=3D DECODER) { - if (inst->state =3D=3D IRIS_INST_STREAMING) + if (buf_type =3D=3D BUF_INPUT) + ret =3D iris_queue_deferred_buffers(inst, BUF_INPUT); + + if (!ret && inst->state =3D=3D IRIS_INST_STREAMING) { ret =3D iris_queue_internal_deferred_buffers(inst, BUF_DPB); - if (!ret) - ret =3D iris_queue_deferred_buffers(inst, buf_type); + if (!ret) + ret =3D iris_queue_deferred_buffers(inst, BUF_OUTPUT); + } } else { if (inst->state =3D=3D IRIS_INST_STREAMING) { ret =3D iris_queue_deferred_buffers(inst, BUF_INPUT); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B40F3FE071; Sat, 28 Feb 2026 17:43:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300602; cv=none; b=buH15UOV4PyKA0XbqbZpAPgHk2p6VLuARLl37vZ73vKZB/8T+y8hw3c8n+s2Irmxh56Y6U6FyexDaYcMXFkuRAb7JJktsdijUrl9TTjKsi2NXGPK93mMpf08NWBZVIqMaTJaq+vII59CKrolTA4jUvzb7YUfT/MQl7V8TGdJ/pU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300602; c=relaxed/simple; bh=F4MJejqL9xPFVLoPwmRms9z9fysULGQptS0CePkzVu0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fYsjRJh2DPgQkHS3q5aGyf3FpHerwVIv6WmviBC3z7mFeEo1+7lgad/JxLrRPoqWpD0ruhn30jtZycjD9Sw+vMZTKptl/LBCr8Wyv1UK4JjOqiEgMNlUooprHdc+MgURdOYIBK8GUxWF8TcULjcQZR3Esh2Yx5a/ObEe9I9C+5o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NnVd0gcM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NnVd0gcM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E54D0C19425; Sat, 28 Feb 2026 17:43:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300602; bh=F4MJejqL9xPFVLoPwmRms9z9fysULGQptS0CePkzVu0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NnVd0gcM19+3FWDLKzlexsFOMKqmfmdGu+BZuhHyPKeqinG1s1Kxu2vxXSuwIEHOB Txm+m3xPjuDT+snKfZ1xPSt+SiPfGPmktNJrS6vdVgGT/O87DTGS4+ccTao2CktxTY 5IYQtYt24ZB8o/fN9A4cUlAd3QEBTU1mcVu8x3vpdp9v2Rhnuf5cysnmt/9zlHGuVW TV1ZJlI3wPJLOQmQ/qmBsmLneCrrYhis2eOQhaZclEnF0f+VrXD4Zs3/u9MIeZA286 q2IzbckvQazHm9ZGSiTmDBzNMjqKOUEkalzCxRCkf3/bJ+s6OnTAklQNIGzu9VDgzW tLWD8r7DmDR1Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luca Ceresoli , Maxime Ripard , Sasha Levin Subject: [PATCH 6.19 643/844] drm: of: drm_of_panel_bridge_remove(): fix device_node leak Date: Sat, 28 Feb 2026 12:29:16 -0500 Message-ID: <20260228173244.1509663-644-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luca Ceresoli [ Upstream commit a4b4385d0523e39a7c058cb5a6c8269e513126ca ] drm_of_panel_bridge_remove() uses of_graph_get_remote_node() to get a device_node but does not put the node reference. Fixes: c70087e8f16f ("drm/drm_of: add drm_of_panel_bridge_remove function") Cc: stable@vger.kernel.org # v4.15 Acked-by: Maxime Ripard Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find= _bridge-2-v2-1-8bad3ef90b9f@bootlin.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/drm/drm_of.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h index 7f0256dae3f13..f3e55ea2174c0 100644 --- a/include/drm/drm_of.h +++ b/include/drm/drm_of.h @@ -5,6 +5,7 @@ #include #include #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_DRM_PANEL_BRIDGE) +#include #include #endif =20 @@ -173,6 +174,8 @@ static inline int drm_of_panel_bridge_remove(const stru= ct device_node *np, bridge =3D of_drm_find_bridge(remote); drm_panel_bridge_remove(bridge); =20 + of_node_put(remote); + return 0; #else return -EINVAL; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4BBE48C8C5; Sat, 28 Feb 2026 17:43:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300603; cv=none; b=smB8/zs85BldpnjnK+K2c0p2HqppQfhvcybUOnt71YIwfs8fjPOtjRkvuisnh/lAZI9bUzMRnWwUKNmrDn6sw5sZKpxCAfOdLy7KZTdBdo/FfR267v+bFmhFpe08+MKJR+inlzJPgoN8+z/d0AJ8poy5MrcVgSxiqXHO4/QxAYM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300603; c=relaxed/simple; bh=G1puFTGsWufhrjjuUp5eqPyNrw1x4Jop1jFVDzYqptI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NzdiharzyTTD4xfMSzMh3LiSBkDZr6PTiOcCEixsGivVbShook3Etr4cxGQsm0Zk5JOYA9qgCMwY9QwX50WLhLZRNpG5VoKBCTOZk/8vZoAOLIkuW0fWmcuWLb7ZLhPNGoxCWM2i1VVwa10MoNzSrbREw0jNveRaI05t16ULgOM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iRLSy5Lh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iRLSy5Lh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C29D5C116D0; Sat, 28 Feb 2026 17:43:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300603; bh=G1puFTGsWufhrjjuUp5eqPyNrw1x4Jop1jFVDzYqptI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iRLSy5Lh/iyjFQUA2vZul7BdJ9DKN6GjismS+vKLmG9SAi/yGcDi2rw5O4bWsc6Wq mIuF7ShHg8xRzax7TUoBxDhA3PiXI0V8l1ZW6W9Eczw8SgqC9m4WVRDSssq3Pxs9QJ UJtrVzT0GPxhPKijF+I0Y7BvK25F1kqh/8wB3BtFmvegNr2knUGlYB1aA3jGOTiTpP vsjqegruNHz0tYiKM0NjAgayibY4aW+Ly3+30eHTn6yyatsYMNQvDWlm19QVfaGyht fYKjQWGDuk2Jx+Os6fWjYuTe+HBLJQBgqowtci5uX6+g183RKQtsIRB9artqccRgnd aWP2yJ9LZP0AA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mauro Carvalho Chehab , Andy Shevchenko , Jonathan Corbet , Sasha Levin Subject: [PATCH 6.19 644/844] docs: kdoc: fix logic to handle unissued warnings Date: Sat, 28 Feb 2026 12:29:17 -0500 Message-ID: <20260228173244.1509663-645-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mauro Carvalho Chehab [ Upstream commit 292eca3163218f2185a8eabe59f4a576bb9e05f8 ] Changeset 469c1c9eb6c9 ("kernel-doc: Issue warnings that were silently disc= arded") didn't properly addressed the missing messages behavior, as it was calling directly python logger low-level function, instead of using the expected method to emit warnings. Basically, there are two methods to log messages: - self.config.log.warning() - This is the raw level to emit a warning. It just writes the a message at stderr, via python logging, as it is initialized as: self.config.log =3D logging.getLogger("kernel-doc") - self.config.warning() - This is where we actually consider a message as a warning, properly incrementing error count. Due to that, several parsing error messages are internally considered as success, causing -Werror to not work on such messages. While here, ensure that the last ignored entry will also be handled by adding an extra check at the end of the parse handler. Fixes: 469c1c9eb6c9 ("kernel-doc: Issue warnings that were silently discard= ed") Closes: https://lore.kernel.org/linux-doc/20260112091053.00cee29a@foz.lan/ Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Acked-by: Andy Shevchenko Signed-off-by: Jonathan Corbet Message-ID: <95109a6585171da4d6900049deaa2634b41ee743.1768823489.git.mcheha= b+huawei@kernel.org> Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/lib/python/kdoc/kdoc_parser.py | 35 ++++++++++++++++++++++------ 1 file changed, 28 insertions(+), 7 deletions(-) diff --git a/tools/lib/python/kdoc/kdoc_parser.py b/tools/lib/python/kdoc/k= doc_parser.py index 500aafc500322..2168d623f7867 100644 --- a/tools/lib/python/kdoc/kdoc_parser.py +++ b/tools/lib/python/kdoc/kdoc_parser.py @@ -295,7 +295,7 @@ class KernelEntry: =20 # TODO: rename to emit_message after removal of kernel-doc.pl def emit_msg(self, ln, msg, *, warning=3DTrue): - """Emit a message""" + """Emit a message.""" =20 log_msg =3D f"{self.fname}:{ln} {msg}" =20 @@ -448,18 +448,37 @@ class KernelDoc: =20 self.config.log.debug("Output: %s:%s =3D %s", dtype, name, pformat= (args)) =20 + def emit_unused_warnings(self): + """ + When the parser fails to produce a valid entry, it places some + warnings under `entry.warnings` that will be discarded when resett= ing + the state. + + Ensure that those warnings are not lost. + + .. note:: + + Because we are calling `config.warning()` here, those + warnings are not filtered by the `-W` parameters: they will = all + be produced even when `-Wreturn`, `-Wshort-desc`, and/or + `-Wcontents-before-sections` are used. + + Allowing those warnings to be filtered is complex, because it + would require storing them in a buffer and then filtering th= em + during the output step of the code, depending on the + selected symbols. + """ + if self.entry and self.entry not in self.entries: + for log_msg in self.entry.warnings: + self.config.warning(log_msg) + def reset_state(self, ln): """ Ancillary routine to create a new entry. It initializes all variables used by the state machine. """ =20 - # - # Flush the warnings out before we proceed further - # - if self.entry and self.entry not in self.entries: - for log_msg in self.entry.warnings: - self.config.log.warning(log_msg) + self.emit_unused_warnings() =20 self.entry =3D KernelEntry(self.config, self.fname, ln) =20 @@ -1664,6 +1683,8 @@ class KernelDoc: # Hand this line to the appropriate state handler self.state_actions[self.state](self, ln, line) =20 + self.emit_unused_warnings() + except OSError: self.config.log.error(f"Error: Cannot open file {self.fname}") =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 883753FE852; Sat, 28 Feb 2026 17:43:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300604; cv=none; b=czbxtZTYZoHeVNlpn2yaWeSTCHUrFcFY0JRCPFl29hAYYHIZ+Xdtc10CqzzeHjqwYF4cBw0trEeXlu3GLFO6R4kZc314RWAY+84ilYF/vCnLhrQnKA3qdvWb8h6CwPkiUltVJxZZQbfXIB9KW4+kB/47Cc4SB0+gQy/42AKQ4dg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300604; c=relaxed/simple; bh=CIq1sMcaAIbQlDLPPLl+hO1rP2rtKXpxE8bLIcDJV2E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K0INEaqTdaD7IDjNDHr2XEcpTNC9EppBvPO5sJS4uZGX0dDDombV4V6TeTeRudPnTJPhQWevGmw7ujg1c6cSEEnDB9E7WJdfIeX54ItsRbOw3t8DvCp4Ecgc7H0VEMSm4b3Grr6vxU44Q0C+0szIeJhXWoUyiJQYG8SS3a5lN8Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K6Xr+YRW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K6Xr+YRW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B157AC19423; Sat, 28 Feb 2026 17:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300604; bh=CIq1sMcaAIbQlDLPPLl+hO1rP2rtKXpxE8bLIcDJV2E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K6Xr+YRWc1K7UMA7dcL7axVqxSgtFTu+b50NBx7RnQODKwP3NKnz6t+r67ai10lRu IHVxuvfp/3IXIXiRyP7xb6M0ua2VWpN79e00Hf7uuMgYS9qeMuW2TVZtr0OB5SJqhr iz16v1VEOTLoZ1nGAi/CKvKzNd7mlKDzur243Zxe8BIaKbaRHPVnMPkdFxaGN27Sxj UN+R4X+hKDpVVe9EnxRGE3SbxGlbwmb9mN2BxbXsa3G5eOklP3OSt+WcCZjisUrREe WPt9dv6H8vwb8MxpPVLFVa2qmSDQSxC6n8CMiLBoXLveVnjD0lRmYsBh7/yyn7n7iY aZzsdfu3UUhLw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mauro Carvalho Chehab , Jonathan Corbet , Sasha Levin Subject: [PATCH 6.19 645/844] docs: kdoc: avoid error_count overflows Date: Sat, 28 Feb 2026 12:29:18 -0500 Message-ID: <20260228173244.1509663-646-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mauro Carvalho Chehab [ Upstream commit 802774d8539fa73487190ec45438777a3c38d424 ] The glibc library limits the return code to 8 bits. We need to stick to this limit when using sys.exit(error_count). Signed-off-by: Mauro Carvalho Chehab Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Message-ID: <233d1674db99ed8feb405a2f781de350f0fba0ac.1768823489.git.mcheha= b+huawei@kernel.org> Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- scripts/kernel-doc.py | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/scripts/kernel-doc.py b/scripts/kernel-doc.py index 7a1eaf986bcd4..1ebb16b9bb087 100755 --- a/scripts/kernel-doc.py +++ b/scripts/kernel-doc.py @@ -116,6 +116,8 @@ SRC_DIR =3D os.path.dirname(os.path.realpath(__file__)) =20 sys.path.insert(0, os.path.join(SRC_DIR, LIB_DIR)) =20 +WERROR_RETURN_CODE =3D 3 + DESC =3D """ Read C language source or header FILEs, extract embedded documentation com= ments, and print formatted documentation to standard output. @@ -176,7 +178,21 @@ class MsgFormatter(logging.Formatter): return logging.Formatter.format(self, record) =20 def main(): - """Main program""" + """ + Main program. + + By default, the return value is: + + - 0: success or Python version is not compatible with + kernel-doc. If -Werror is not used, it will also + return 0 if there are issues at kernel-doc markups; + + - 1: an abnormal condition happened; + + - 2: argparse issued an error; + + - 3: -Werror is used, and one or more unfiltered parse warnings happen= ed. + """ =20 parser =3D argparse.ArgumentParser(formatter_class=3Dargparse.RawTextH= elpFormatter, description=3DDESC) @@ -323,16 +339,12 @@ def main(): =20 if args.werror: print("%s warnings as errors" % error_count) # pylint: disable= =3DC0209 - sys.exit(error_count) + sys.exit(WERROR_RETURN_CODE) =20 if args.verbose: print("%s errors" % error_count) # pylint: disable= =3DC0209 =20 - if args.none: - sys.exit(0) - - sys.exit(error_count) - + sys.exit(0) =20 # Call main method if __name__ =3D=3D "__main__": --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FF1A3FE87D; Sat, 28 Feb 2026 17:43:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300606; cv=none; b=B/DNi7Y31d+T9v2Cd+m/6B7C9Ifal08gYMdvY7S5NXEgr9Ces+JqTiPuMsOkEtx7eJ94nJaGXaWpJaH6pn8AoIvpP5wQBGK7GqG0v5tBdDwPRKESHFDWSZejeUc5COTWv02skjPuTRcjB/JCfyNXQLoKKriJg8gVPhD63DrYj4c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300606; c=relaxed/simple; bh=q/WVrkUAs9UtZs+I2Ue05ZFeeAw+Iz5yXKqjHVYTCCk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mN1z6bFmEeJEQbZs61IkqikkwoZtZOdgoOioNNJaS6q++Loxy+02nDiHMkq1DeSY65yPnc+Oee7SN62theCu9fAYI/xozbfYkO3IkaF2+AvCv/jmSI+sb++E/O4+XC0OQcbd6DEM/lsMaEwjRmJX1xEwSiYdb1zul4/ttBR4u/w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cM4f0TZY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cM4f0TZY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FADDC116D0; Sat, 28 Feb 2026 17:43:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300606; bh=q/WVrkUAs9UtZs+I2Ue05ZFeeAw+Iz5yXKqjHVYTCCk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cM4f0TZYR3/3N8VYy+UfQt12oLdDp2cLZtIoRWz5LDK8409iLGmI9Qv8lhBj6I1PF tkWbv3/u+0qfEIVhdvKMJpvzA69aAZ4omsjoboXp8YoMh8pHgedLnf/QdGjbacQ//g VUDO4Ovt2hZ3bV42YZBy2uSy9ZoaCE2dWORwjRsLC/RF4zDXKR7IAm6EKapdup35qf A4FZfssEQaPBUo41O/IOCqDFEfIqanb7ZURcFbVctBzoFp56gYosOknXcXO2BSc5XT ll1fIwHfMpAdTMV9eqAKe2wlbgizf17PVYiNoMbAuZ70whKW+2ifo9Tpus05486NFa jt8ptZiHAkWCQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vlastimil Babka , Michal Hocko , Johannes Weiner , Pedro Falcato , Zi Yan , Brendan Jackman , "David Hildenbrand (Red Hat)" , David Rientjes , Joshua Hahn , Liam Howlett , Lorenzo Stoakes , Mike Rapoport , Suren Baghdasaryan , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 646/844] mm, page_alloc, thp: prevent reclaim for __GFP_THISNODE THP allocations Date: Sat, 28 Feb 2026 12:29:19 -0500 Message-ID: <20260228173244.1509663-647-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vlastimil Babka [ Upstream commit 9c9828d3ead69416d731b1238802af31760c823e ] Since commit cc638f329ef6 ("mm, thp: tweak reclaim/compaction effort of local-only and all-node allocations"), THP page fault allocations have settled on the following scheme (from the commit log): 1. local node only THP allocation with no reclaim, just compaction. 2. for madvised VMA's or when synchronous compaction is enabled always - THP allocation from any node with effort determined by global defrag setting and VMA madvise 3. fallback to base pages on any node Recent customer reports however revealed we have a gap in step 1 above. What we have seen is excessive reclaim due to THP page faults on a NUMA node that's close to its high watermark, while other nodes have plenty of free memory. The problem with step 1 is that it promises no reclaim after the compaction attempt, however reclaim is only avoided for certain compaction outcomes (deferred, or skipped due to insufficient free base pages), and not e.g. when compaction is actually performed but fails (we did see compact_fail vmstat counter increasing). THP page faults can therefore exhibit a zone_reclaim_mode-like behavior, which is not the intention. Thus add a check for __GFP_THISNODE that corresponds to this exact situation and prevents continuing with reclaim/compaction once the initial compaction attempt isn't successful in allocating the page. Note that commit cc638f329ef6 has not introduced this over-reclaim possibility; it appears to exist in some form since commit 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations"). Followup commits b39d0ee2632d ("mm, page_alloc: avoid expensive reclaim when compaction may not succeed") and cc638f329ef6 have moved in the right direction, but left the abovementioned gap. Link: https://lkml.kernel.org/r/20251219-costly-noretry-thisnode-fix-v1-1-e= 1085a4a0c34@suse.cz Fixes: 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations") Signed-off-by: Vlastimil Babka Acked-by: Michal Hocko Acked-by: Johannes Weiner Acked-by: Pedro Falcato Acked-by: Zi Yan Cc: Brendan Jackman Cc: "David Hildenbrand (Red Hat)" Cc: David Rientjes Cc: Joshua Hahn Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/page_alloc.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index cbf758e27aa2c..1af52f568f22d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4818,6 +4818,20 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int = order, compact_result =3D=3D COMPACT_DEFERRED) goto nopage; =20 + /* + * THP page faults may attempt local node only first, + * but are then allowed to only compact, not reclaim, + * see alloc_pages_mpol(). + * + * Compaction can fail for other reasons than those + * checked above and we don't want such THP allocations + * to put reclaim pressure on a single node in a + * situation where other nodes might have plenty of + * available memory. + */ + if (gfp_mask & __GFP_THISNODE) + goto nopage; + /* * Looks like reclaim/compaction is worth trying, but * sync compaction could be very expensive, so keep --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 873723FF1AB; Sat, 28 Feb 2026 17:43:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300607; cv=none; b=scrv8Vx7tKNpjIIJk+PRGIrjIQ29alFNIJbXKBSHFACL34koxLr7huAREtD2HENzM/5RiGb7cNw3fF+Zj35p/vRNO4zEQdNMqQSj7ZcWvTP29OKOJU/Aa8b3Lrv3kXIfkpzZFJzuXOVfwk++hWZo3m7vDnQhXR+797cFv2qdRJo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300607; c=relaxed/simple; bh=acpezPzvl69WK9Iiw/Yx2kb/8Q2BHP9ENnwHM2ALXNE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Fim4w+SlyLh5RiVG+WOEcp5dinzgj65oKuwjs+UE3QIdD76FxQ8CMuPFfEFk6RqouyxfFkgP027XWYt2blj7fCf3S7qjYNq/dfLLRVHM987BOLHwr5h3BWOAKnLFKMnxd/DGA3j2LFktaSUMW50b9n3wPXCM/1/tuLGD1Q5RAfg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gbLZuSqh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gbLZuSqh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78E52C19425; Sat, 28 Feb 2026 17:43:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300607; bh=acpezPzvl69WK9Iiw/Yx2kb/8Q2BHP9ENnwHM2ALXNE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gbLZuSqh3bzWJTRgRbH52ab1fjBQRByJdhbzgcb28GG84+rJswxNAcWEuWjQOYI86 zojjFxa+JoWl9vjsAJaVluXOumBbPuMTDl7u6bQu2KQeNSR43kbo3H0DMaZjLlNxG7 ljjakV7R1mP4dPp6Hf8VhPYQC3ek0nW01ya3JHDQa5m/m/QziS/CLjjattFkA2FmOt je4aLEih5n9s7+Nz0BQCyyjhQJK2LlBGwWfZJMcNBz8Y+PCpohwvuJXoLUBfQRfJQY +Z/16eWe48ccQNtN0/I2K0LUbQHYyPQfIyFguLLItSm8zScxHun2/IkMpfFM196MYo htLsPbEcI8XlA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Li Wang , "David Hildenbrand (Red Hat)" , Waiman Long , Mark Brown , Shuah Khan , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 647/844] selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs Date: Sat, 28 Feb 2026 12:29:20 -0500 Message-ID: <20260228173244.1509663-648-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li Wang [ Upstream commit 1aa1dd9cc595917882fb6db67725442956f79607 ] charge_reserved_hugetlb.sh mounts a hugetlbfs instance at /mnt/huge with a fixed size of 256M. On systems with large base hugepages (e.g. 512MB), this is smaller than a single hugepage, so the hugetlbfs mount ends up with zero capacity (often visible as size=3D0 in mount output). As a result, write_to_hugetlbfs fails with ENOMEM and the test can hang waiting for progress. =3D=3D=3D Error log =3D=3D=3D # uname -r 6.12.0-xxx.el10.aarch64+64k #./charge_reserved_hugetlb.sh -cgroup-v2 # ----------------------------------------- ... # nr hugepages =3D 10 # writing cgroup limit: 5368709120 # writing reseravation limit: 5368709120 ... # write_to_hugetlbfs: Error mapping the file: Cannot allocate memory # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 ... # mount |grep /mnt/huge none on /mnt/huge type hugetlbfs (rw,relatime,seclabel,pagesize=3D512M,si= ze=3D0) # grep -i huge /proc/meminfo ... HugePages_Total: 10 HugePages_Free: 10 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 524288 kB Hugetlb: 5242880 kB Drop the mount args with 'size=3D256M', so the filesystem capacity is suffi= cient regardless of HugeTLB page size. Link: https://lkml.kernel.org/r/20251221122639.3168038-3-liwang@redhat.com Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Signed-off-by: Li Wang Acked-by: David Hildenbrand (Red Hat) Acked-by: Waiman Long Cc: Mark Brown Cc: Shuah Khan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/testing/selftests/mm/charge_reserved_hugetlb.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh b/tools/= testing/selftests/mm/charge_reserved_hugetlb.sh index e1fe16bcbbe88..fa6713892d82d 100755 --- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh +++ b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh @@ -290,7 +290,7 @@ function run_test() { setup_cgroup "hugetlb_cgroup_test" "$cgroup_limit" "$reservation_limit" =20 mkdir -p /mnt/huge - mount -t hugetlbfs -o pagesize=3D${MB}M,size=3D256M none /mnt/huge + mount -t hugetlbfs -o pagesize=3D${MB}M none /mnt/huge =20 write_hugetlbfs_and_get_usage "hugetlb_cgroup_test" "$size" "$populate" \ "$write" "/mnt/huge/test" "$method" "$private" "$expect_failure" \ @@ -344,7 +344,7 @@ function run_multiple_cgroup_test() { setup_cgroup "hugetlb_cgroup_test2" "$cgroup_limit2" "$reservation_limit= 2" =20 mkdir -p /mnt/huge - mount -t hugetlbfs -o pagesize=3D${MB}M,size=3D256M none /mnt/huge + mount -t hugetlbfs -o pagesize=3D${MB}M none /mnt/huge =20 write_hugetlbfs_and_get_usage "hugetlb_cgroup_test1" "$size1" \ "$populate1" "$write1" "/mnt/huge/test1" "$method" "$private" \ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C39D43FF1C4; Sat, 28 Feb 2026 17:43:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300608; cv=none; b=H7nYV78X0ftg/VcwZh8IhhKsgZbkDt4GBkTVfxBQGT5fG4sPhuoASIApJ52kdFD8wqvwflbMtzQN7l38IjZYxq5NV1c/OejCV1WE021R2KuPZoHYz5Di5Ard9ANuS1su8pCFHSY+WlW7ym/7xY5OHPC0Iv5ISlksgQzvkScDmMc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300608; c=relaxed/simple; bh=rPZ0E3UF0nIX9XVviXncYcH4hqlHR+MaMB1bcTB+E+M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HfyLHvKn8D2RFR1XQwgqAzjC/Wo/K/AHPmoAKmvAjmJa7ngjx6DdTttwzRlJcTXwJg4WP+2G2hlQbb5sLAkHmLElcteU+cK+XwApLRWgjos5JkdFSEnKzppWnlqkAClh81/Y/LRiYCBxSJKF4NJh3bB0ob/MUN70GaNTRGRJMs0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AvcFglo9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AvcFglo9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB98AC19424; Sat, 28 Feb 2026 17:43:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300608; bh=rPZ0E3UF0nIX9XVviXncYcH4hqlHR+MaMB1bcTB+E+M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AvcFglo9n7914P5N+GkZ42frC5/yk0aU/0PAJU8zoc2a0bpvj6Tv9Nm1LDw0msf+Q 2FYnLiqP2iMQbNww63whEdhps3rgqtaHbDnC7fV28W8KsM2cngx0OiLYXsFOTyjwlI I9DwjuFnWt45s4kVAbsZMwg6gB2DpjWAWpjcsZZripiG7Z/pCrzqCY4h8Gdz0WNHa2 iHwjQssdK79P37sqMe8rBiw/Bg8iSszBopSxYEueREGEgjmI1PpOF1YvIwnBdD8TmW fLtf+sJ32WSoX1dIuxrHU4c4lIx5RVkBCegHPl7qOjF3WqE00HKCz3BBaxKr8zjdCK EMqbM/h+U0V5Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sanjay Yadav , =?UTF-8?q?Christian=20K=C3=B6nig?= , Arunpravin Paneer Selvam , Matthew Auld , Sasha Levin Subject: [PATCH 6.19 648/844] drm/buddy: Prevent BUG_ON by validating rounded allocation Date: Sat, 28 Feb 2026 12:29:21 -0500 Message-ID: <20260228173244.1509663-649-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Sanjay Yadav [ Upstream commit 5488a29596cdba93a60a79398dc9b69d5bdadf92 ] When DRM_BUDDY_CONTIGUOUS_ALLOCATION is set, the requested size is rounded up to the next power-of-two via roundup_pow_of_two(). Similarly, for non-contiguous allocations with large min_block_size, the size is aligned up via round_up(). Both operations can produce a rounded size that exceeds mm->size, which later triggers BUG_ON(order > mm->max_order). Example scenarios: - 9G CONTIGUOUS allocation on 10G VRAM memory: roundup_pow_of_two(9G) =3D 16G > 10G - 9G allocation with 8G min_block_size on 10G VRAM memory: round_up(9G, 8G) =3D 16G > 10G Fix this by checking the rounded size against mm->size. For non-contiguous or range allocations where size > mm->size is invalid, return -EINVAL immediately. For contiguous allocations without range restrictions, allow the request to fall through to the existing __alloc_contig_try_harder() fallback. This ensures invalid user input returns an error or uses the fallback path instead of hitting BUG_ON. v2: (Matt A) - Add Fixes, Cc stable, and Closes tags for context Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6712 Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Cc: # v6.7+ Cc: Christian K=C3=B6nig Cc: Arunpravin Paneer Selvam Suggested-by: Matthew Auld Signed-off-by: Sanjay Yadav Reviewed-by: Matthew Auld Reviewed-by: Arunpravin Paneer Selvam Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260108113227.2101872-5-sanjay.kumar.yadav@= intel.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/drm_buddy.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c index 8308116058cc1..fd34d3755f7c5 100644 --- a/drivers/gpu/drm/drm_buddy.c +++ b/drivers/gpu/drm/drm_buddy.c @@ -1156,6 +1156,15 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm, order =3D fls(pages) - 1; min_order =3D ilog2(min_block_size) - ilog2(mm->chunk_size); =20 + if (order > mm->max_order || size > mm->size) { + if ((flags & DRM_BUDDY_CONTIGUOUS_ALLOCATION) && + !(flags & DRM_BUDDY_RANGE_ALLOCATION)) + return __alloc_contig_try_harder(mm, original_size, + original_min_size, blocks); + + return -EINVAL; + } + do { order =3D min(order, (unsigned int)fls(pages) - 1); BUG_ON(order > mm->max_order); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A125C3FF1D8; Sat, 28 Feb 2026 17:43:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300609; cv=none; b=Cgf/86q67bM1cLQvK1+Mw+plreDaafFhOVyHcdgUt3GTFhTBWbj1hcHD8nqbGn1teH2/+M1nsjptk2dFiSEvAjGirj7u3FKqnKc8YuS5+GIxVJckN87HGe1k092LBN7CrLvZcVxdgQ0LWQdy822T6MFHLFVYUk07Vf/XooLF6qg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300609; c=relaxed/simple; bh=nZpfEUnxRBoAUgmH/6AuFk06MuwRjlxeNi9sgiulmN0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jGl4QFA7wrn4kiC95mU90Q+892BO7H9nnLcGG8BqicaoaGebQ0+B1v3QPMCB1/RF7FZ3F5erTQx3+plZkefGcuis0oUb1jZE6cZ729hO5Wab19spzE5/8Sok80yaWs87gSENZ4k5OxsLZhXMfnPOpxNumhPMi3uts3NrdTer37s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PE7pk5ET; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PE7pk5ET" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0BBDC19423; Sat, 28 Feb 2026 17:43:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300609; bh=nZpfEUnxRBoAUgmH/6AuFk06MuwRjlxeNi9sgiulmN0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PE7pk5ETbXMe2eVQ3zer8mLQRg+Sh1nlua1q2hETH1SeNCYJF/Nlxz+6YAvMISAB1 sVvYw5jXdt4KC8VVNmWmjKOLbT5iaheHHu9s0VQUICQhBaTtauR8K6eFgx5OSAmr9x MbVKjZSOeYSAR2aFwztJycgJjiTme3/zMVhHGNmOF0P4zD4Jmr4WP0uGY/3QXBGGhF 5CgLlDMiXyVwM8+9cDnEmgbvMsA1/0dSiZu47bL7fQvymnwFcyAb2eQaiLiulCNxMZ Vzgqe2PEEKGFrZNJMsjvBGgegdrvVl5LtnpSOEbm0uHKnKwm3rxtrGhBi1jqoe/7sn 7gnTtP/0NiAMA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Loic Poulain , stable@kernel.org, Dmitry Baryshkov , Sasha Levin Subject: [PATCH 6.19 649/844] drm/bridge: anx7625: Fix invalid EDID size Date: Sat, 28 Feb 2026 12:29:22 -0500 Message-ID: <20260228173244.1509663-650-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Loic Poulain [ Upstream commit 1d5362145de96b5d00d590605cc94cdfa572b405 ] DRM checks EDID block count against allocated size in drm_edid_valid function. We have to allocate the right EDID size instead of the max size to prevent the EDID to be reported as invalid. Cc: stable@kernel.org Fixes: 7c585f9a71aa ("drm/bridge: anx7625: use struct drm_edid more") Reviewed-by: Dmitry Baryshkov Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20251218151307.95491-1-loic.poulain@oss.qual= comm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/bridge/analogix/anx7625.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/br= idge/analogix/anx7625.c index 6f3fdcb6afdb9..4e49e4f28d552 100644 --- a/drivers/gpu/drm/bridge/analogix/anx7625.c +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c @@ -1801,7 +1801,7 @@ static const struct drm_edid *anx7625_edid_read(struc= t anx7625_data *ctx) return NULL; } =20 - ctx->cached_drm_edid =3D drm_edid_alloc(edid_buf, FOUR_BLOCK_SIZE); + ctx->cached_drm_edid =3D drm_edid_alloc(edid_buf, edid_num * ONE_BLOCK_SI= ZE); kfree(edid_buf); =20 out: --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E80F3FFAA1; Sat, 28 Feb 2026 17:43:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300610; cv=none; b=DxNijYkf7YSqaMu6b63TGLKwTGsUiTCTUrC3pctxLTOJG1EclyXhrY2P4m2lCVCrTrGkvVH1D+YBoMuSGpUbAEiSR39ICq1qJP8BS56GE2HdjC2/0Ss93gkI1/HSIJXJN/ESTBNeFAlmN5nQ/hkkVUXlglzUWPsVATbMFQX5xN4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300610; c=relaxed/simple; bh=SYAvbUPBTIIJtIjD/wMStO6QYPKYZW9xNsUaYMKwkMY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WJl8bFKVFTrnUc+FKQe3v03pCS4w4TijBitQ11dhi/CqSPDJDqb3t7Vh0jI9ZkHD3LpvZEetkAscoJDHMPiCxWBiG0EmsAPq1jH5aHGykiSoosFTd4LL7yOV14YwhJG+UajDRFytGxFkZ2EphCN/UDSL6GDPoRXU+7N5/OZepQE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Mo0AK2th; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Mo0AK2th" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2C21C4AF09; Sat, 28 Feb 2026 17:43:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300610; bh=SYAvbUPBTIIJtIjD/wMStO6QYPKYZW9xNsUaYMKwkMY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Mo0AK2thyK6u84Nh66D8uonpH1SadLnf11BQzqQyeOcoUg+7Ju//vFuEIGWvcOvAP cnqRBwzL8dB6cughXJM7DwuLQavC/xXXU7O1ctb4hNakniPsx8WVEtUhtvJx4Pkkic bzdr/P4QHBvU/vL8OYmNgaXS8W1spEWqiVsH99D+H2PE/u3U2mYCnPrUuycN5ij6VJ qUvalyVmYMNLM6AS/uUqXU5ekQDbhSpVDuT+rxQ5yiFoPW6Cqbee7W4UoLY3mlbmDC 338RQ5PYkuebjzQPe10CzHhILVN5UtGKx7oWZnuYHLdTIqKpYneXW/jeQwBifcur4F 3FedKmM5cKtbQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xu Yang , Frank Li , Vinod Koul , Sasha Levin Subject: [PATCH 6.19 650/844] phy: fsl-imx8mq-usb: set platform driver data Date: Sat, 28 Feb 2026 12:29:23 -0500 Message-ID: <20260228173244.1509663-651-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xu Yang [ Upstream commit debf8326a435ac746f48173e4742a574810f1ff4 ] Add missing platform_set_drvdata() as the data will be used in remove(). Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx9= 5") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260120111646.3159766-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/frees= cale/phy-fsl-imx8mq-usb.c index b30d01f345d20..9c340c889c80c 100644 --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c @@ -676,6 +676,8 @@ static int imx8mq_usb_phy_probe(struct platform_device = *pdev) if (!imx_phy) return -ENOMEM; =20 + platform_set_drvdata(pdev, imx_phy); + imx_phy->clk =3D devm_clk_get(dev, "phy"); if (IS_ERR(imx_phy->clk)) { dev_err(dev, "failed to get imx8mq usb phy clock\n"); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AFD43FFAC3; Sat, 28 Feb 2026 17:43:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300611; cv=none; b=r/3KGYJfwmSj5lnq99MNddGxUuntCUYjy/KA17TemgF3xjNPT6BawBxoXBblP5GKK1Fw0VolY5AdEUBtyUbF/dOTTAFA5VnGNNDdaimzRvpOadlVqqYduMvS2n7UPHOkWgZS085xf0+d1Kb3eNBawrEvYBBQyF0+5rLaHVuL6nQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300611; c=relaxed/simple; bh=arC2Z881uVFzGKibrZWaTBPjUaTvs4NVoNdK8HcPU3A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JLrkJCENcPsafdFS8YvjigbXFyBiWr0Tex5ATPg9QlYg3uxUHYhkJ7tiB6dOK8hH9awqK/3UtmZTYfmgg0IF9+oz1eUEx7Y38b/2nHdW7dhEObHx4gPJ/Alu9cZf5RQza/hVl9Z9zRy46RWH9RH5vMvPoCf6lqZGnVEKywtSaII= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dRpZZKnW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dRpZZKnW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97065C2BC87; Sat, 28 Feb 2026 17:43:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300611; bh=arC2Z881uVFzGKibrZWaTBPjUaTvs4NVoNdK8HcPU3A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dRpZZKnWxhRwVMg3zIPf2v2lbZxF+jN0uNEv1pwl0bKJjJccIgTrETdLQ/hmD8wJ9 yfpZNtn3/lVMNMCBocwsbrRx2J6+JxSdWQWFD6Twy9pjjfU7v5qs7RH2dJHq/IW+Ym kjCEHAB5GLSNIp17RHmS9hEG9EbeaSapE7r9YyBgLXM4YRJlfpD17vbxobqBhGm1Uv Hk7A2WL2tqd6JhcXSds00D+gtC4BzssPVHmEr2/yBa5LagrSgnPUe2QeTfswkm8Vmq Eyz8frS92uYDptvXFxkui3NIkN5gi+84gZb4wXTfrT/GdLDKeVozAYR9+TzbuulB9S Mbmhz76BBkGLQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Richard Zhu , Manivannan Sadhasivam , Frank Li , Sasha Levin Subject: [PATCH 6.19 651/844] PCI: dwc: Skip waiting for L2/L3 Ready if dw_pcie_rp::skip_l23_wait is true Date: Sat, 28 Feb 2026 12:29:24 -0500 Message-ID: <20260228173244.1509663-652-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Richard Zhu [ Upstream commit 58a17b2647ba5aac47e3ffafd0a9b92bf4a9bcbe ] In NXP i.MX6QP and i.MX7D SoCs, LTSSM registers are not accessible once PME_Turn_Off message is broadcasted to the link. So there is no way to verify whether the link has entered L2/L3 Ready state or not. Hence, add a new flag 'dw_pcie_rp::skip_l23_ready' and set it to 'true' for the above mentioned SoCs. This flag when set, will allow the DWC core to skip polling for L2/L3 Ready state and just wait for 10ms as recommended in the PCIe spec r6.0, sec 5.3.3.2.1. Fixes: a528d1a72597 ("PCI: imx6: Use DWC common suspend resume method") Signed-off-by: Richard Zhu [mani: renamed flag to skip_l23_ready and reworded description] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260114083300.3689672-2-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pci-imx6.c | 5 +++++ drivers/pci/controller/dwc/pcie-designware-host.c | 10 ++++++++++ drivers/pci/controller/dwc/pcie-designware.h | 1 + 3 files changed, 16 insertions(+) diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller= /dwc/pci-imx6.c index dd69af0f195ff..c6dfbd57880ea 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -116,6 +116,7 @@ enum imx_pcie_variants { #define IMX_PCIE_FLAG_BROKEN_SUSPEND BIT(9) #define IMX_PCIE_FLAG_HAS_LUT BIT(10) #define IMX_PCIE_FLAG_8GT_ECN_ERR051586 BIT(11) +#define IMX_PCIE_FLAG_SKIP_L23_READY BIT(12) =20 #define imx_check_flag(pci, val) (pci->drvdata->flags & val) =20 @@ -1798,6 +1799,8 @@ static int imx_pcie_probe(struct platform_device *pde= v) */ imx_pcie_add_lut_by_rid(imx_pcie, 0); } else { + if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_SKIP_L23_READY)) + pci->pp.skip_l23_ready =3D true; pci->pp.use_atu_msg =3D true; ret =3D dw_pcie_host_init(&pci->pp); if (ret < 0) @@ -1859,6 +1862,7 @@ static const struct imx_pcie_drvdata drvdata[] =3D { .variant =3D IMX6QP, .flags =3D IMX_PCIE_FLAG_IMX_PHY | IMX_PCIE_FLAG_SPEED_CHANGE_WORKAROUND | + IMX_PCIE_FLAG_SKIP_L23_READY | IMX_PCIE_FLAG_SUPPORTS_SUSPEND, .dbi_length =3D 0x200, .gpr =3D "fsl,imx6q-iomuxc-gpr", @@ -1875,6 +1879,7 @@ static const struct imx_pcie_drvdata drvdata[] =3D { .variant =3D IMX7D, .flags =3D IMX_PCIE_FLAG_SUPPORTS_SUSPEND | IMX_PCIE_FLAG_HAS_APP_RESET | + IMX_PCIE_FLAG_SKIP_L23_READY | IMX_PCIE_FLAG_HAS_PHY_RESET, .gpr =3D "fsl,imx7d-iomuxc-gpr", .mode_off[0] =3D IOMUXC_GPR12, diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pc= i/controller/dwc/pcie-designware-host.c index f1c7d50eba746..af2eeed55f9e5 100644 --- a/drivers/pci/controller/dwc/pcie-designware-host.c +++ b/drivers/pci/controller/dwc/pcie-designware-host.c @@ -1173,6 +1173,16 @@ int dw_pcie_suspend_noirq(struct dw_pcie *pci) return ret; } =20 + /* + * Some SoCs do not support reading the LTSSM register after + * PME_Turn_Off broadcast. For those SoCs, skip waiting for L2/L3 Ready + * state and wait 10ms as recommended in PCIe spec r6.0, sec 5.3.3.2.1. + */ + if (pci->pp.skip_l23_ready) { + mdelay(PCIE_PME_TO_L2_TIMEOUT_US/1000); + goto stop_link; + } + ret =3D read_poll_timeout(dw_pcie_get_ltssm, val, val =3D=3D DW_PCIE_LTSSM_L2_IDLE || val <=3D DW_PCIE_LTSSM_DETECT_WAIT, diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/con= troller/dwc/pcie-designware.h index 6f0dfdde1d577..ca3ff1fefab5d 100644 --- a/drivers/pci/controller/dwc/pcie-designware.h +++ b/drivers/pci/controller/dwc/pcie-designware.h @@ -446,6 +446,7 @@ struct dw_pcie_rp { struct pci_config_window *cfg; bool ecam_enabled; bool native_ecam; + bool skip_l23_ready; }; =20 struct dw_pcie_ep_ops { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F1AB3FFADA; Sat, 28 Feb 2026 17:43:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300612; cv=none; b=G/zdTh/Lw+ZS7P0Ak2jUz/uxo6OLY6Z6cqhphtzENLFHCO+k2V5yz/aSzGzdor/LBtCFPAhBu0DlGxrzTa33MAxfkV2jzzurExIS86t6zBARBvolSmi7XiiPj6ddR0XFr9la5TfiJbfjOAW4UEumYopncLoel9FzV3XDvmSOXIw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300612; c=relaxed/simple; bh=hbXZtEnI7h+qFxH3cDPv4Wg6WkTxhKe9oHLMa70Ar48=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CYRCoELrkJ2r0n3HXjJ/G+lfPUcqd6MtoeT8N6hjVfgtObG7LqQQd2qYNErcGcvZMbvoVwUr02Ylx2+pGcVK7xTx0VR7TnNQSuxqPrI9YDIykCunIeWzOSA/nRevYoabE2AdjCNDyPPA5ilqdVImQCmksQG1h2dhW4mcinOU0mo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MIy/ztAc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MIy/ztAc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BB43C116D0; Sat, 28 Feb 2026 17:43:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300612; bh=hbXZtEnI7h+qFxH3cDPv4Wg6WkTxhKe9oHLMa70Ar48=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MIy/ztAcxi/ZsxxADr1Nh9dNseXP/7rfqjQHoqm8pdJFaKiWhiJ9H0TP2O8u9GPwL NjhRj9bd44at4G8cKIuER0ntLF0/S8wfVlQv0Ga/JfU/J8KLPuQj5eqADU14bgVnir C8fgTjYpGepyMEflYs0mxPnza6mDcDqreU+VZ+M0k2foIbh2HqvFjLEQoWnJQhGqhc x4gdXGB8uUHMDSXHNdzJrPJflLzl7okcklJOSvB8W6LfVJ2lA5puuPI1kF+FdnqtHJ MGw25YIvdIeUSAykTAlx+E3cmPlsXvzMnFyh5wHbYEAdplN9aajrsxJ/rT1cRMAN/O Ar3d49oUqIxzA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , Christoph Hellwig , Carlos Maiolino , Sasha Levin Subject: [PATCH 6.19 652/844] xfs: mark data structures corrupt on EIO and ENODATA Date: Sat, 28 Feb 2026 12:29:25 -0500 Message-ID: <20260228173244.1509663-653-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" [ Upstream commit f39854a3fb2f06dc69b81ada002b641ba5b4696b ] I learned a few things this year: first, blk_status_to_errno can return ENODATA for critical media errors; and second, the scrub code doesn't mark data structures as corrupt on ENODATA or EIO. Currently, scrub failing to capture these errors isn't all that impactful -- the checking code will exit to userspace with EIO/ENODATA, and xfs_scrub will log a complaint and exit with nonzero status. Most people treat fsck tools failing as a sign that the fs is corrupt, but online fsck should mark the metadata bad and keep moving. Cc: stable@vger.kernel.org # v4.15 Fixes: 4700d22980d459 ("xfs: create helpers to record and deal with scrub p= roblems") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/scrub/btree.c | 2 ++ fs/xfs/scrub/common.c | 4 ++++ fs/xfs/scrub/dabtree.c | 2 ++ 3 files changed, 8 insertions(+) diff --git a/fs/xfs/scrub/btree.c b/fs/xfs/scrub/btree.c index acade92c5fce1..b497f6a474c77 100644 --- a/fs/xfs/scrub/btree.c +++ b/fs/xfs/scrub/btree.c @@ -42,6 +42,8 @@ __xchk_btree_process_error( break; case -EFSBADCRC: case -EFSCORRUPTED: + case -EIO: + case -ENODATA: /* Note the badness but don't abort. */ sc->sm->sm_flags |=3D errflag; *error =3D 0; diff --git a/fs/xfs/scrub/common.c b/fs/xfs/scrub/common.c index 7bfa37c99480f..5f9be4151d722 100644 --- a/fs/xfs/scrub/common.c +++ b/fs/xfs/scrub/common.c @@ -103,6 +103,8 @@ __xchk_process_error( break; case -EFSBADCRC: case -EFSCORRUPTED: + case -EIO: + case -ENODATA: /* Note the badness but don't abort. */ sc->sm->sm_flags |=3D errflag; *error =3D 0; @@ -177,6 +179,8 @@ __xchk_fblock_process_error( break; case -EFSBADCRC: case -EFSCORRUPTED: + case -EIO: + case -ENODATA: /* Note the badness but don't abort. */ sc->sm->sm_flags |=3D errflag; *error =3D 0; diff --git a/fs/xfs/scrub/dabtree.c b/fs/xfs/scrub/dabtree.c index 056de4819f866..a6a5d3a75d994 100644 --- a/fs/xfs/scrub/dabtree.c +++ b/fs/xfs/scrub/dabtree.c @@ -45,6 +45,8 @@ xchk_da_process_error( break; case -EFSBADCRC: case -EFSCORRUPTED: + case -EIO: + case -ENODATA: /* Note the badness but don't abort. */ sc->sm->sm_flags |=3D XFS_SCRUB_OFLAG_CORRUPT; *error =3D 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DACD4002EE; Sat, 28 Feb 2026 17:43:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300613; cv=none; b=H4Nl7DD3q/nyli//fx45sf41+HLoDqGh6FYXmCxI0MM00YmbIBYD5ltQWqxDo7Il6IeToNvGJZGKXVTwbYSkLVfxsvNccZ/LYL3mNjL7KJK3BP5YAlCfd4KxapXDlAO56IW6PRymSQeLS/baAD/IwGOilRHWe5GIct4NQAw0EJM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300613; c=relaxed/simple; bh=Y+xjYeWA4FcH7Xu2Dp4PwFESVLxxugv0cygy/exHtes=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ABPS77lPdHh//NrQtoS3gTtbR6vg5kbLLmqyHizFcygsuNfGtq3caNrz3hDCJKZOMq9yRjh7gd4EydRsnfarSFnUyqaq2RWmd5KQxKlHOkj+8Hpyf4R2aw+kuFK+VdwfD9RuBGIXOI5yTkdHIXMkgddXvCsfZolF9RFMc2ruY5o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hVa4rHAa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hVa4rHAa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DEC1C2BC9E; Sat, 28 Feb 2026 17:43:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300613; bh=Y+xjYeWA4FcH7Xu2Dp4PwFESVLxxugv0cygy/exHtes=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hVa4rHAaUnBRIX6DNPMOPmrRL8d/wHcqAYwiNadCOaVvZvT2uoJ4lC7H0vRcdLz/n N+Gak+0Y3cCc8tBK7kohMvzWkMcAy58mS0T/MtghXECc7nQeZwBIfZyI3om98tpqkk R8HXn3pKDcOqFio1NhM1z6uI/sgbsL8dB9evljmp2qspedyQfTGw8/oaY7/iNUPoqM bUGbHYa9EMlWrUhbLgA1pLjZXg7jMNnZLrFwKlAhFehyjjS7Wn0+p7ZxqhG/iLSUCA hT+gEcf1fbSxxiyE1d4CX6+SQiX3RzvzbSXtyTTipoPE5wuxQKpGv9MRGpJuxaVJ7h /9hVl8SgN83Nw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christoph Hellwig , Mark Tinguely , "Darrick J. Wong" , Carlos Maiolino , Sasha Levin Subject: [PATCH 6.19 653/844] xfs: remove xfs_attr_leaf_hasname Date: Sat, 28 Feb 2026 12:29:26 -0500 Message-ID: <20260228173244.1509663-654-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christoph Hellwig [ Upstream commit 3a65ea768b8094e4699e72f9ab420eb9e0f3f568 ] The calling convention of xfs_attr_leaf_hasname() is problematic, because it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfs_attr3_leaf_lookup_int fails with other error values. Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so that the buffer release code is done by each caller of xfs_attr3_leaf_read. Cc: stable@vger.kernel.org # v5.19+ Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Reported-by: Mark Tinguely Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/libxfs/xfs_attr.c | 75 +++++++++++++--------------------------- 1 file changed, 24 insertions(+), 51 deletions(-) diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c index 8c04acd30d489..b88e65c7e45de 100644 --- a/fs/xfs/libxfs/xfs_attr.c +++ b/fs/xfs/libxfs/xfs_attr.c @@ -50,7 +50,6 @@ STATIC int xfs_attr_shortform_addname(xfs_da_args_t *args= ); */ STATIC int xfs_attr_leaf_get(xfs_da_args_t *args); STATIC int xfs_attr_leaf_removename(xfs_da_args_t *args); -STATIC int xfs_attr_leaf_hasname(struct xfs_da_args *args, struct xfs_buf = **bp); =20 /* * Internal routines when attribute list is more than one block. @@ -979,11 +978,12 @@ xfs_attr_lookup( return error; =20 if (xfs_attr_is_leaf(dp)) { - error =3D xfs_attr_leaf_hasname(args, &bp); - - if (bp) - xfs_trans_brelse(args->trans, bp); - + error =3D xfs_attr3_leaf_read(args->trans, args->dp, args->owner, + 0, &bp); + if (error) + return error; + error =3D xfs_attr3_leaf_lookup_int(bp, args); + xfs_trans_brelse(args->trans, bp); return error; } =20 @@ -1222,27 +1222,6 @@ xfs_attr_shortform_addname( * External routines when attribute list is one block *=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/ =20 -/* - * Return EEXIST if attr is found, or ENOATTR if not - */ -STATIC int -xfs_attr_leaf_hasname( - struct xfs_da_args *args, - struct xfs_buf **bp) -{ - int error =3D 0; - - error =3D xfs_attr3_leaf_read(args->trans, args->dp, args->owner, 0, bp); - if (error) - return error; - - error =3D xfs_attr3_leaf_lookup_int(*bp, args); - if (error !=3D -ENOATTR && error !=3D -EEXIST) - xfs_trans_brelse(args->trans, *bp); - - return error; -} - /* * Remove a name from the leaf attribute list structure * @@ -1253,25 +1232,22 @@ STATIC int xfs_attr_leaf_removename( struct xfs_da_args *args) { - struct xfs_inode *dp; - struct xfs_buf *bp; + struct xfs_inode *dp =3D args->dp; int error, forkoff; + struct xfs_buf *bp; =20 trace_xfs_attr_leaf_removename(args); =20 - /* - * Remove the attribute. - */ - dp =3D args->dp; - - error =3D xfs_attr_leaf_hasname(args, &bp); - if (error =3D=3D -ENOATTR) { + error =3D xfs_attr3_leaf_read(args->trans, args->dp, args->owner, 0, &bp); + if (error) + return error; + error =3D xfs_attr3_leaf_lookup_int(bp, args); + if (error !=3D -EEXIST) { xfs_trans_brelse(args->trans, bp); - if (args->op_flags & XFS_DA_OP_RECOVERY) + if (error =3D=3D -ENOATTR && (args->op_flags & XFS_DA_OP_RECOVERY)) return 0; return error; - } else if (error !=3D -EEXIST) - return error; + } =20 xfs_attr3_leaf_remove(bp, args); =20 @@ -1295,23 +1271,20 @@ xfs_attr_leaf_removename( * Returns 0 on successful retrieval, otherwise an error. */ STATIC int -xfs_attr_leaf_get(xfs_da_args_t *args) +xfs_attr_leaf_get( + struct xfs_da_args *args) { - struct xfs_buf *bp; - int error; + struct xfs_buf *bp; + int error; =20 trace_xfs_attr_leaf_get(args); =20 - error =3D xfs_attr_leaf_hasname(args, &bp); - - if (error =3D=3D -ENOATTR) { - xfs_trans_brelse(args->trans, bp); - return error; - } else if (error !=3D -EEXIST) + error =3D xfs_attr3_leaf_read(args->trans, args->dp, args->owner, 0, &bp); + if (error) return error; - - - error =3D xfs_attr3_leaf_getvalue(bp, args); + error =3D xfs_attr3_leaf_lookup_int(bp, args); + if (error =3D=3D -EEXIST) + error =3D xfs_attr3_leaf_getvalue(bp, args); xfs_trans_brelse(args->trans, bp); return error; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DFC540030C; Sat, 28 Feb 2026 17:43:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300614; cv=none; b=bGzCZSz4ncCy7Qah+nG0rZb+9b47lyNT99dVn/0Zt6SjCZtQGTw/lFBdYRqqsgC3vzhK7cykWg1EUNAd6pOq/q3t+2n5VcvWvDfIYH8GbFmqcrPIrlq3xs51IVTxfnJOC1zFDSCzkTJ1IulYQz6aEFVfDNZlcpi7ZJysVo+DC6w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300614; c=relaxed/simple; bh=ERqG7+7TcdUzvV8LO+YQRDPeUQH7NLyuGGHIqXUpaP4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=g9SiJQdmXzyUlsBj0z9yEzo9QJKcfea2JVgr7jsDSuCQgK5JGLb+7VLMSCXD9UwJvOnGZz9pTmkxXUxDZoxQDKV7VSiEHfDWMa7jZ+uS4OS1PwCzcrDx6RCFg9o8kwzDHxqSaEKUAU3nSE8PtxuH1HJYG4CFAtKTpCyD59EMjfY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T1d+vdI7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T1d+vdI7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83AC8C19424; Sat, 28 Feb 2026 17:43:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300614; bh=ERqG7+7TcdUzvV8LO+YQRDPeUQH7NLyuGGHIqXUpaP4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T1d+vdI7hXlzAkmUVnaV3dghliWSFBIyrhh6CCRebaFDCmx6pMRfDzsRI2kulfRj3 fm71Lb7RjN/X43VhO9AJYXhscrvmOczB5xWAXkH5TBOKni1kiZCrZqnRqfy0R9c25f JAEdOX+nXptVGILu0Z/WXOyT1wSxLzBINCu2/x4WKET1bTlKq0ZAhz+kL8q9bJJWvV VVYYtDy5sb2xIJLZkYqRqNscEtANBoJqJslAy/xTbsNJJEUJp9FDkEoph2TWtZsrmN fwRNQ+QWpnNkbw2JVCxIoNGTAt8FgR440o0YMcXwePOGNfFNsXsJFnHHqfpQWhuspG SLPQ2xJG50sCw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Gaignard , Nicolas Dufresne , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 654/844] media: verisilicon: AV1: Fix tile info buffer size Date: Sat, 28 Feb 2026 12:29:27 -0500 Message-ID: <20260228173244.1509663-655-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Gaignard [ Upstream commit a505ca2db89ad92a8d8d27fa68ebafb12e04a679 ] Each tile info is composed of: row_sb, col_sb, start_pos and end_pos (4 bytes each). So the total required memory is AV1_MAX_TILES * 16 bytes. Use the correct #define to allocate the buffer and avoid writing tile info in non-allocated memory. Signed-off-by: Benjamin Gaignard Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.= c b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c index 500e94bcb0293..e4e21ad373233 100644 --- a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c +++ b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c @@ -381,12 +381,12 @@ int rockchip_vpu981_av1_dec_init(struct hantro_ctx *c= tx) return -ENOMEM; av1_dec->global_model.size =3D GLOBAL_MODEL_SIZE; =20 - av1_dec->tile_info.cpu =3D dma_alloc_coherent(vpu->dev, AV1_MAX_TILES, + av1_dec->tile_info.cpu =3D dma_alloc_coherent(vpu->dev, AV1_TILE_INFO_SIZ= E, &av1_dec->tile_info.dma, GFP_KERNEL); if (!av1_dec->tile_info.cpu) return -ENOMEM; - av1_dec->tile_info.size =3D AV1_MAX_TILES; + av1_dec->tile_info.size =3D AV1_TILE_INFO_SIZE; =20 av1_dec->film_grain.cpu =3D dma_alloc_coherent(vpu->dev, ALIGN(sizeof(struct rockchip_av1_film_grain), 2048), --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5670C492181; Sat, 28 Feb 2026 17:43:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300615; cv=none; b=Oeh29U9o+iHBeATZeaa5rT+bf9ZI7KwxqYbPXNXrKNrqQOb2li375Kz2EhQOXljcym5tXhMRNtPTENP0J6ZU2Jt4YYXByKFeXOJZViMUrjch9jWg0xYTPcjVK3XEKxabBE/yT5bwLRHpcISlAlhtZaemoEtIVxBnYV/VjlGQQX4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300615; c=relaxed/simple; bh=SZPQi8By45shZVXLcPDJbaFQuKe0/9kstN6rwHLOtMo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FNk++EjygzA/XU6FC5RNe41uvI6S7BaMewAVvaA89k5vG87xH6Uq6PevGUhtJUkhjVR19JeYtu5YWv5g3cMkHmG3iLP0XJ3+/4/xPOn1i1hiNwqnjjPz+lJ7MsFTFnxx/7sX/jnREPn/2k3DJ9q8YZDTgsoNqKMLBSHei0M5V+M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D87Z6KeU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="D87Z6KeU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75966C19423; Sat, 28 Feb 2026 17:43:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300615; bh=SZPQi8By45shZVXLcPDJbaFQuKe0/9kstN6rwHLOtMo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D87Z6KeUuvTE+yBPRTEgbtXfNMF0mWzQuiuV+xAwx/I5OQzGIQp0nQ+2QTH7PfoNE Qh6++PGj7j5+sjVT7mSI4Q156AY2JYtmdGDUDWDfV3chWPN2K6dCTtlf2TrXsYyAkF hKsTTM4e+UpLc2w+3VwFhrCMKHw6fywAmOgq/Igw3FMLCk3JurZWA4+X4yOhk445sV NhEcNMFYmxGO7q2q0+hyt3FCMcvHVqqu8gOhhTeo9dZgnybHDrltW0cJEwjRs1ANbE bgLc8b4r63KFlL8wqovAvj9zTM56yultHuyzyUH59F7kV62LYSf1QmsOLznttB9JP7 Pc0IrNGGeLLlQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Biggers , Mikulas Patocka , Sasha Levin Subject: [PATCH 6.19 655/844] dm: fix excessive blk-crypto operations for invalid keys Date: Sat, 28 Feb 2026 12:29:28 -0500 Message-ID: <20260228173244.1509663-656-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Biggers [ Upstream commit d6d0e6b9d54532264761405a1ba8ea5bd293acb1 ] dm_exec_wrappedkey_op() passes through the derive_sw_secret, import_key, generate_key, and prepare_key blk-crypto operations to an underlying device. Currently, it calls the operation on every underlying device until one returns success. This logic is flawed when the operation is expected to fail, such as an invalid key being passed to derive_sw_secret. That can happen if userspace passes an invalid key to the FS_IOC_ADD_ENCRYPTION_KEY ioctl. When that happens on a device-mapper device that consists of many dm-linear targets, a lot of unnecessary key unwrapping requests get sent to the underlying key wrapping hardware. Fix this by considering the first device only. As already documented in the comment, it was already checked that all underlying devices support wrapped keys, so this should be fine. Fixes: e93912786e50 ("dm: pass through operations on wrapped inline crypto = keys") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-table.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c index 0522cd700e0e2..4b70872725d04 100644 --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -1237,9 +1237,6 @@ static int dm_wrappedkey_op_callback(struct dm_target= *ti, struct dm_dev *dev, bdev_get_queue(bdev)->crypto_profile; int err =3D -EOPNOTSUPP; =20 - if (!args->err) - return 0; - switch (args->op) { case DERIVE_SW_SECRET: err =3D blk_crypto_derive_sw_secret( @@ -1266,9 +1263,7 @@ static int dm_wrappedkey_op_callback(struct dm_target= *ti, struct dm_dev *dev, break; } args->err =3D err; - - /* Try another device in case this fails. */ - return 0; + return 1; /* No need to continue the iteration. */ } =20 static int dm_exec_wrappedkey_op(struct blk_crypto_profile *profile, @@ -1294,14 +1289,13 @@ static int dm_exec_wrappedkey_op(struct blk_crypto_= profile *profile, * declared on all underlying devices. Thus, all the underlying devices * should support all wrapped key operations and they should behave * identically, i.e. work with the same keys. So, just executing the - * operation on the first device on which it works suffices for now. + * operation on the first device suffices for now. */ for (i =3D 0; i < t->num_targets; i++) { ti =3D dm_table_get_target(t, i); if (!ti->type->iterate_devices) continue; - ti->type->iterate_devices(ti, dm_wrappedkey_op_callback, args); - if (!args->err) + if (ti->type->iterate_devices(ti, dm_wrappedkey_op_callback, args) !=3D = 0) break; } out: --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A00C400C13; Sat, 28 Feb 2026 17:43:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300616; cv=none; b=DRoPryxz/lY4/QK/0mb4sIt3Lvclk6WbntHNx+/xEOmM5LKnfs84mYWFkR69ViGNk/Ad80HjtSaeOHitfOdO1p9YxQV4E7X+lcwFayJu69wTdw28W7VGKmuqs0uoRPFH00NBhwfhCjxYxn3O5/PCLtkr+4DrULrUCqf1oW2JPo4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300616; c=relaxed/simple; bh=wy+9C6HkEMy+Plt9bFUgURSkZS2Cy297b2bowbpBP6E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mxjaeUZ5G/ifFXUjqDGLgtBcmw37qUwXqlMBog87e7Yt0Zp4r5AWfjV3Zg1PFiPWdv9MA1Fg+OKTVkGNHI2MQ6pR8UVjZCl8Omx9Yd2airgzSG1VjXN999W0b0O+B4QLexrDoVW/mbjOIJl5zK7cYdBZeKsVtWrkyskqXLbkpvI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pYADVdgq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pYADVdgq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AFBDC19425; Sat, 28 Feb 2026 17:43:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300616; bh=wy+9C6HkEMy+Plt9bFUgURSkZS2Cy297b2bowbpBP6E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pYADVdgqIj+JZ3TQWLV/f3bcgmYDoq9V29Wpj88S5Cz7goWB7gKD/funYvxdSab6e cXayRcrZ1pky/89BFuJXAyN6gFt00aPZith8MCaOb9OuwyOmXJWJQmb9sH7J7xdbGn Pb/3GqotdqUT0YYv//aczwjd3xGAK2DjhNA/cFJ3Fv7hYLY1Bpw7uUmnhwasW8bdOz caSBPMcdk34kYjQ++QZgOA4LqTfK4yktR1lTvzAw68irVcdD/XWedmk9PwHnoZEfLQ qWJkVh9N8sbFrfI8gQuSXQSHK/2ayC0M7pGhnMtcNoGmPGUd/XAvurNTHAhSREquQC 7gsBE9HuDGIiQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Michal Pecio , Ricardo Ribalda , Laurent Pinchart , Hans Verkuil , Sasha Levin Subject: [PATCH 6.19 656/844] media: uvcvideo: Return queued buffers on start_streaming() failure Date: Sat, 28 Feb 2026 12:29:29 -0500 Message-ID: <20260228173244.1509663-657-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Michal Pecio [ Upstream commit 4cf3b6fd54ebb1ebc977bdc47fb6cfcf9a471a22 ] Return buffers if streaming fails to start due to uvc_pm_get() error. This bug may be responsible for a warning I got running while :; do yavta -c3 /dev/video0; done on an xHCI controller which failed under this workload. I had no luck reproducing this warning again to confirm. xhci_hcd 0000:09:00.0: HC died; cleaning up usb 13-2: USB disconnect, device number 2 WARNING: CPU: 2 PID: 29386 at drivers/media/common/videobuf2/videobuf2-core= .c:1803 vb2_start_streaming+0xac/0x120 Fixes: 7dd56c47784a ("media: uvcvideo: Remove stream->is_streaming field") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20251015133642.3dede646.michal.pecio@gmail.c= om Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/media/usb/uvc/uvc_queue.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_queue.c b/drivers/media/usb/uvc/uvc_= queue.c index 790184c9843d2..e838c6c1893a6 100644 --- a/drivers/media/usb/uvc/uvc_queue.c +++ b/drivers/media/usb/uvc/uvc_queue.c @@ -177,18 +177,20 @@ static int uvc_start_streaming_video(struct vb2_queue= *vq, unsigned int count) =20 ret =3D uvc_pm_get(stream->dev); if (ret) - return ret; + goto err_buffers; =20 queue->buf_used =3D 0; =20 ret =3D uvc_video_start_streaming(stream); - if (ret =3D=3D 0) - return 0; + if (ret) + goto err_pm; =20 - uvc_pm_put(stream->dev); + return 0; =20 +err_pm: + uvc_pm_put(stream->dev); +err_buffers: uvc_queue_return_buffers(queue, UVC_BUF_STATE_QUEUED); - return ret; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 195B7400C30; Sat, 28 Feb 2026 17:43:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300617; cv=none; b=Mkgn5IRsmtxaunSrmoKgGNWHqypxohk+Rez53zQe9FXi4DmqRvaqcuknYIC5aCUptn6bHiGRF6/OADFq69OKuff759Em2Tk1zBV6E0ASztmvG1kRBwxK3Eb0/l63LMsfp3ZGiYQGSBmoJkdBKD0+u1JNeVo4Qhw5FqMJ9lfDVkQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300617; c=relaxed/simple; bh=Q8bbJ0bmizrGoq+XzgQ/UGUa7WgHJYfXizYp9mRQDEw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pTcUbou2vIJHa17dUxIawd7KPf66Zg3xDzZ3ynhFqOGaecY33YlPYvpdN1qSItB9+J9IIaemWlYapkKZTfcV0xsEZRTK6m9FODoFYV2+ctrunqs6qARDjtE7Tz5bQnu3knGoaaR7qDuiIE1oJw8jhkNO8JY1fH31Gw6MPVd3apg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V7/w2ngu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V7/w2ngu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50ED0C116D0; Sat, 28 Feb 2026 17:43:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300617; bh=Q8bbJ0bmizrGoq+XzgQ/UGUa7WgHJYfXizYp9mRQDEw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V7/w2ngu6DHXQnt3q5gKO9UdyGNYy1sA0OvX8KJ+SyNQ8pJ+ft1tHBJYJnD09ymXs jcQ8OjZsboHX3BZ6n2T8m/FuNu7PrwNUxjNTCqB5KptH2EPyH8RiYKNXtxIWGwP5Ym 7E3Hp7eYEx3LF+O7Noi8Q3jwFT1XRshIvrIxq/C0+Ktkk9wtPoMsF8pLZYZTaq9Uak n4rN1QwlbBIQOseMebisZJTskySFlpu2sD6++XpNOOOZRTWWqyxy/ljnFyUTSNEGce U5mqqEnGPFWdJ0QVH96Gb8GYfyXcqONcfodo56tqeFyTpUGDaoh9SzkfI9biXVp3eN qz/Q8mC5UzZng== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jinhui Guo , Lu Baolu , Joerg Roedel , Sasha Levin Subject: [PATCH 6.19 657/844] iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without scalable mode Date: Sat, 28 Feb 2026 12:29:30 -0500 Message-ID: <20260228173244.1509663-658-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Jinhui Guo [ Upstream commit 42662d19839f34735b718129ea200e3734b07e50 ] PCIe endpoints with ATS enabled and passed through to userspace (e.g., QEMU, DPDK) can hard-lock the host when their link drops, either by surprise removal or by a link fault. Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") adds pci_dev_is_disconnected() to devtlb_invalidation_with_pasid() so ATS invalidation is skipped only when the device is being safely removed, but it applies only when Intel IOMMU scalable mode is enabled. With scalable mode disabled or unsupported, a system hard-lock occurs when a PCIe endpoint's link drops because the Intel IOMMU waits indefinitely for an ATS invalidation that cannot complete. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Commit 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release") adds intel_pasid_teardown_sm_context() to intel_iommu_release_device(), which calls qi_flush_dev_iotlb() and can also hard-lock the system when a PCIe endpoint's link drops. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 intel_context_flush_no_pasid device_pasid_table_teardown pci_pasid_table_teardown pci_for_each_dma_alias intel_pasid_teardown_sm_context intel_iommu_release_device iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Sometimes the endpoint loses connection without a link-down event (e.g., due to a link fault); killing the process (virsh destroy) then hard-locks the host. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput pci_dev_is_disconnected() only covers safe-removal paths; pci_device_is_present() tests accessibility by reading vendor/device IDs and internally calls pci_dev_is_disconnected(). On a ConnectX-5 (8 GT/s, x2) this costs ~70 =C2=B5s. Since __context_flush_dev_iotlb() is only called on {attach,release}_dev paths (not hot), add pci_device_is_present() there to skip inaccessible devices and avoid the hard-lock. Fixes: 37764b952e1b ("iommu/vt-d: Global devTLB flush when present context = entry changed") Fixes: 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release") Cc: stable@vger.kernel.org Signed-off-by: Jinhui Guo Link: https://lore.kernel.org/r/20251211035946.2071-2-guojinhui.liam@byteda= nce.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iommu/intel/pasid.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c index 34b209b88be2a..d3841a88e5948 100644 --- a/drivers/iommu/intel/pasid.c +++ b/drivers/iommu/intel/pasid.c @@ -926,6 +926,14 @@ static void __context_flush_dev_iotlb(struct device_do= main_info *info) if (!info->ats_enabled) return; =20 + /* + * Skip dev-IOTLB flush for inaccessible PCIe devices to prevent the + * Intel IOMMU from waiting indefinitely for an ATS invalidation that + * cannot complete. + */ + if (!pci_device_is_present(to_pci_dev(info->dev))) + return; + qi_flush_dev_iotlb(info->iommu, PCI_DEVID(info->bus, info->devfn), info->pfsid, info->ats_qdep, 0, MAX_AGAW_PFN_WIDTH); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0BB5A401487; Sat, 28 Feb 2026 17:43:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300618; cv=none; b=mantXNX6UZyTYodEagKbSUnc1bT+4eeRQAwMChNP1zMI6KWh7ksLtvFywj/9QJ25i9pjveXpQO1gU5BX53YjcxKYRZGDEb3q47fkmcckKdPgFA3udVmwqF14Zn+JiIRjXfNGHL+T//pXLe4wSZynP3Peh5y0+kD43imM//yWnCA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300618; c=relaxed/simple; bh=pZrv2YZrYsK87xb10fIhnLIW90OJBm3wCI/Krk++uIU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=E60SH4zJ0mQva5QddOjZ78yMdnfOgvggD1jBarIwolChgS+haqbpTJfIVLhlRFTSTFuYnIET/AY6AKUmKDlizhpjYRjsKig8sOsLK5aSpsCqDdwYdB/M7k0J6WHsSY4kmZM/O8jX4xBjFeKkJibPJg5EHYGz4fIKcwEjHBzoJPw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FWeUIXhS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FWeUIXhS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 410A5C19425; Sat, 28 Feb 2026 17:43:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300617; bh=pZrv2YZrYsK87xb10fIhnLIW90OJBm3wCI/Krk++uIU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FWeUIXhSWwzrPlRaJhn1GoH2Xdnau8TCTINf/Ti7PQpsO5Ga4a9u4iDi13wNFtRsD oX+xF1pMJ8gD5VePRye+6Yfj4bDHdhWVESLx01Nfn9RLkZF5/mdtzXfHSx+CEVFiLk atvV+NWDdYgH1UkOr19YpnWovLRO7ne+eXctuKQokJAYyZ8CMAJIW14oeIg8auzpFU t/Z2mAn7THFaJaqY5FywYFAVTg3OZKqPqUzAm2Fn+0EHiDpfBf9UdP9A+P36ftrnVw /jSKmmORtkNCA8psHrHhHpUyQnsLohXm8ny6cfTT8xP1XaSRXVxINV4FhWyolpllLH 0ygDEtx4ZkJoA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jinhui Guo , Lu Baolu , Joerg Roedel , Sasha Levin Subject: [PATCH 6.19 658/844] iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Date: Sat, 28 Feb 2026 12:29:31 -0500 Message-ID: <20260228173244.1509663-659-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Jinhui Guo [ Upstream commit 10e60d87813989e20eac1f3eda30b3bae461e7f9 ] Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 =C2=B5s on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions. Fixes: 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when= device is disconnected") Cc: stable@vger.kernel.org Signed-off-by: Jinhui Guo Link: https://lore.kernel.org/r/20251211035946.2071-3-guojinhui.liam@byteda= nce.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iommu/intel/pasid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c index d3841a88e5948..b63a71904cfb8 100644 --- a/drivers/iommu/intel/pasid.c +++ b/drivers/iommu/intel/pasid.c @@ -219,7 +219,7 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iomm= u, if (!info || !info->ats_enabled) return; =20 - if (pci_dev_is_disconnected(to_pci_dev(dev))) + if (!pci_device_is_present(to_pci_dev(dev))) return; =20 sid =3D PCI_DEVID(info->bus, info->devfn); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 182094014A7; Sat, 28 Feb 2026 17:43:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300619; cv=none; b=syU4DXWa42k4IwPrAWSDSTxRG/n/+SePC0AXHi0vTTgVtxriXNruFQjb33x5PKlPV9n4YMHiviWzlk+nuhsEAO8JLfziwFHTCIb1xl+p9GGZ1boYSytF1xFSVHtANTqvLcAaOuH6zsD8uTuJpZufqQkx338uOa/z5+zHVbs78vA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300619; c=relaxed/simple; bh=WuxCK1wydY82CCy7fyUfGoYlroN8zPTI2IvEl3U21/U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RdI9SRtJDRLGd4Fed4lvF+gnOPB/GUj2YgBCsjV7NZmiJODAKqM1jc44ktNWAox8ZOIVN9XCgUBIGCz+iK9nZK0UCug+9hnNtbr6ep5jzaUXXLjAsk8g+ObeD/fJ++jkqxuH11z6eb/G0mQkXlR6guIYaA0ysm3RHPt8Xmhhr/4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XdP4ND62; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XdP4ND62" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32C23C19423; Sat, 28 Feb 2026 17:43:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300619; bh=WuxCK1wydY82CCy7fyUfGoYlroN8zPTI2IvEl3U21/U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XdP4ND62rV0uC+//Gt2sJE8EhVXDZ1/uAJy8r6MVqy+HydGy8XId+x9RJ3fzck9ZH WJIaikWLHBOowKSeHeG4jVvujNabaEv3soBvIcmKWEOVECzHOgkI1JCx5GIfTLadbC P23HwIZMQ9TWwiGqh6cPeXSeEwX3lKMRNgpAG/eg2hTrOceUAh3skBIGZclR78Fot8 MFhd5CKHh0hoFDMZhQlRxJ3+CGSNPgh6cZDTdYuSO+KPJ4C/JwvGH7rOVdvXQaq8i2 Mdj2bJA2+um9G33Hr4ZkgD20kLJZTu0b3UNJXI+8q0NaKCa6qgDuDIaKu2SrSxASpd 3dyWRLtqFwDdA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yi Liu , Kevin Tian , Lu Baolu , Joerg Roedel , Sasha Levin Subject: [PATCH 6.19 659/844] iommu/vt-d: Flush piotlb for SVM and Nested domain Date: Sat, 28 Feb 2026 12:29:32 -0500 Message-ID: <20260228173244.1509663-660-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yi Liu [ Upstream commit 04b1b069f151e793767755f58b51670bff00cbc1 ] Besides the paging domains that use FS, SVM and Nested domains need to use piotlb invalidation descriptor as well. Fixes: b33125296b50 ("iommu/vt-d: Create unique domain ops for each stage") Cc: stable@vger.kernel.org Signed-off-by: Yi Liu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20251223065824.6164-1-yi.l.liu@intel.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iommu/intel/cache.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/cache.c b/drivers/iommu/intel/cache.c index 265e7290256b5..385ae5cfb30d4 100644 --- a/drivers/iommu/intel/cache.c +++ b/drivers/iommu/intel/cache.c @@ -363,6 +363,13 @@ static void qi_batch_add_pasid_dev_iotlb(struct intel_= iommu *iommu, u16 sid, u16 qi_batch_increment_index(iommu, batch); } =20 +static bool intel_domain_use_piotlb(struct dmar_domain *domain) +{ + return domain->domain.type =3D=3D IOMMU_DOMAIN_SVA || + domain->domain.type =3D=3D IOMMU_DOMAIN_NESTED || + intel_domain_is_fs_paging(domain); +} + static void cache_tag_flush_iotlb(struct dmar_domain *domain, struct cache= _tag *tag, unsigned long addr, unsigned long pages, unsigned long mask, int ih) @@ -370,7 +377,7 @@ static void cache_tag_flush_iotlb(struct dmar_domain *d= omain, struct cache_tag * struct intel_iommu *iommu =3D tag->iommu; u64 type =3D DMA_TLB_PSI_FLUSH; =20 - if (intel_domain_is_fs_paging(domain)) { + if (intel_domain_use_piotlb(domain)) { qi_batch_add_piotlb(iommu, tag->domain_id, tag->pasid, addr, pages, ih, domain->qi_batch); return; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC99633E35A; Sat, 28 Feb 2026 17:43:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300620; cv=none; b=LPwRTJpjXc/gTEIgcxVr0eCQujF0CLDHqj6A8BENrOz5in456B/P81I+NmBRUwErnWDg7XrzWcmbk2ayhFRJYfzNBZCduuMfwiDyIJ3wJzYff2ZdZaVJgrX9/KSNxc0yEZ3phxufnfAr0VphTzK1RHOy7yro5dKf8184QKEe1sk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300620; c=relaxed/simple; bh=QR45+H+PlYDCm+HpbNLhOxLuXNzrpI9pZ2tdfedIGM8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dQ094bKfmKMO1xrYn9aBOJ8ZuKmgraFpUCs+uILahljPXmNKrOjPUM2pUb3IOY4nXx9curFE9dYaSklPN/YzrANEu9n+gzOZ8PNJRhRVsqflRqn3iY6eatN0fBPsRN3IqrKElQ0A8G+zgzxOPghmRujCEVkRSr1GTKPdpwZFMmY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HHeoM1Bs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HHeoM1Bs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D9CEC19424; Sat, 28 Feb 2026 17:43:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300619; bh=QR45+H+PlYDCm+HpbNLhOxLuXNzrpI9pZ2tdfedIGM8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HHeoM1BsHyykMRER+RvPA4XRwLBeWQab1NkvhxrVGVhZ34iqFJAGJ9H2WjNl+qms7 O3ix+OJ7sBEGG6/d11wEf5ZJioEeQSjAXryReqXLJ1inyjTnwclpjT2bPvrlToSMVQ DQIOKiL3q0jLPP3BfvAph4f1yVVa5Tcff9eFTst+hAl5UZ8APe8ut6gnyoiD566ZzN MwFWhCzQD6lIcU7QzpkAH6FjV90rniWDaqQoVri8D4bBdAe9owm0TlTkuLj6aqy4iS 47zy3re0NQgKpcDvi+PL8N2O2pRxQEH84q9LXRDwj0iuj2218hj3fhZliib3qmIS3U X5y4N5MAxGRYw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Zenghui Yu (Huawei)" , Marc Zyngier , Sasha Levin Subject: [PATCH 6.19 660/844] KVM: arm64: nv: Return correct RES0 bits for FGT registers Date: Sat, 28 Feb 2026 12:29:33 -0500 Message-ID: <20260228173244.1509663-661-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Zenghui Yu (Huawei)" [ Upstream commit 2eb80a2eee18762a33aa770d742d64fe47852c7e ] We had extended the sysreg masking infrastructure to more general registers, instead of restricting it to VNCR-backed registers, since commit a0162020095e ("KVM: arm64: Extend masking facility to arbitrary registers"). Fix kvm_get_sysreg_res0() to reflect this fact. Note that we're sure that we only deal with FGT registers in kvm_get_sysreg_res0(), the if (sr < __VNCR_START__) is actually a never false, which should probably be removed later. Fixes: 69c19e047dfe ("KVM: arm64: Add TCR2_EL2 to the sysreg arrays") Signed-off-by: Zenghui Yu (Huawei) Link: https://patch.msgid.link/20260121101631.41037-1-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/kvm/emulate-nested.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-neste= d.c index 834f13fb1fb7d..2d04fb56746ea 100644 --- a/arch/arm64/kvm/emulate-nested.c +++ b/arch/arm64/kvm/emulate-nested.c @@ -2428,7 +2428,7 @@ static u64 kvm_get_sysreg_res0(struct kvm *kvm, enum = vcpu_sysreg sr) =20 masks =3D kvm->arch.sysreg_masks; =20 - return masks->mask[sr - __VNCR_START__].res0; + return masks->mask[sr - __SANITISED_REG_START__].res0; } =20 static bool check_fgt_bit(struct kvm_vcpu *vcpu, enum vcpu_sysreg sr, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C0277401D2B; Sat, 28 Feb 2026 17:43:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300620; cv=none; b=HvPPCu7HzfIcxFyCSeovks7yiG4YEtQEl1qSnPFy1TUQn39h9gtDNhqG6X77F0/3GByoTAT0Mtkm+1K8giCCPVa3qxNETiEvaFE3lmy9rA9dAxyJGbuYfXDTjmHBPKcHNoj6hO62s4nvTeD9sMjjazJ1zQMbah6e5bbniUYY+X4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300620; c=relaxed/simple; bh=D69dLqnG4kE0GPvxaIQ4APaQPnLIBI7aapXZ5ZXWLI0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZZPvKMJeO3DXz751XQLGePgHg8iajqLPP759xlmLeHxe6RlZLimFbsB1HL0k6UJjwgzcKiwA71/QEAJNo9TDDriT5Q6jg2FAPbEqlqbhgkt4GVk/yn3pMgpsIhIVVPWx64TDa/1aM7FDQGf2FiHf1q/4DaNHMPJC7kOHsfLog28= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QeI3rUr/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QeI3rUr/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17C50C116D0; Sat, 28 Feb 2026 17:43:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300620; bh=D69dLqnG4kE0GPvxaIQ4APaQPnLIBI7aapXZ5ZXWLI0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QeI3rUr/A6I0buPeai/H/ikMWhiGnV55gPMoDQfIP9NciKDVb0dttI2+MwLVFFz16 DQFWqo1i5eHDm8jh9lkU6m71u65PzYc76w081tKlZIN81/QgjcRnAOEnLMsXT9faTR s0u9eNYhQ8tup82AAZWxyvmUJBhoZhduOzE5xz4n6sDGRTSAkyHcpacR9VC7ocrYhj qJPIrztz/MSSvZH9SgF+ePUue6StwtVz14AswRwPq7hLTdSdmd4WDqZ1T0pDpuEiiF AqJDKIctuf5ztIaIDho0TgldLpTL7J/zF9MdFpmGxPVf3KPRkXC14MHBOIxmG8ecNs CdYAwK7KfzSXw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Douglas Anderson , Lee Jones , Sasha Levin Subject: [PATCH 6.19 661/844] mfd: core: Add locking around 'mfd_of_node_list' Date: Sat, 28 Feb 2026 12:29:34 -0500 Message-ID: <20260228173244.1509663-662-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Douglas Anderson [ Upstream commit 20117c92bcf9c11afd64d7481d8f94fdf410726e ] Manipulating a list in the kernel isn't safe without some sort of mutual exclusion. Add a mutex any time we access / modify 'mfd_of_node_list' to prevent possible crashes. Cc: stable@vger.kernel.org Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match device= s with the correct of_nodes") Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251210113002.1.I6ceaca2cfb7eb25737012b1666= 71f516696be4fd@changeid Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mfd/mfd-core.c | 36 ++++++++++++++++++++++-------------- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c index 7d14a1e7631ee..c55223ce4327a 100644 --- a/drivers/mfd/mfd-core.c +++ b/drivers/mfd/mfd-core.c @@ -22,6 +22,7 @@ #include =20 static LIST_HEAD(mfd_of_node_list); +static DEFINE_MUTEX(mfd_of_node_mutex); =20 struct mfd_of_node_entry { struct list_head list; @@ -105,9 +106,11 @@ static int mfd_match_of_node_to_dev(struct platform_de= vice *pdev, u64 of_node_addr; =20 /* Skip if OF node has previously been allocated to a device */ - list_for_each_entry(of_entry, &mfd_of_node_list, list) - if (of_entry->np =3D=3D np) - return -EAGAIN; + scoped_guard(mutex, &mfd_of_node_mutex) { + list_for_each_entry(of_entry, &mfd_of_node_list, list) + if (of_entry->np =3D=3D np) + return -EAGAIN; + } =20 if (!cell->use_of_reg) /* No of_reg defined - allocate first free compatible match */ @@ -129,7 +132,8 @@ static int mfd_match_of_node_to_dev(struct platform_dev= ice *pdev, =20 of_entry->dev =3D &pdev->dev; of_entry->np =3D np; - list_add_tail(&of_entry->list, &mfd_of_node_list); + scoped_guard(mutex, &mfd_of_node_mutex) + list_add_tail(&of_entry->list, &mfd_of_node_list); =20 of_node_get(np); device_set_node(&pdev->dev, of_fwnode_handle(np)); @@ -286,11 +290,13 @@ static int mfd_add_device(struct device *parent, int = id, if (cell->swnode) device_remove_software_node(&pdev->dev); fail_of_entry: - list_for_each_entry_safe(of_entry, tmp, &mfd_of_node_list, list) - if (of_entry->dev =3D=3D &pdev->dev) { - list_del(&of_entry->list); - kfree(of_entry); - } + scoped_guard(mutex, &mfd_of_node_mutex) { + list_for_each_entry_safe(of_entry, tmp, &mfd_of_node_list, list) + if (of_entry->dev =3D=3D &pdev->dev) { + list_del(&of_entry->list); + kfree(of_entry); + } + } fail_alias: regulator_bulk_unregister_supply_alias(&pdev->dev, cell->parent_supplies, @@ -360,11 +366,13 @@ static int mfd_remove_devices_fn(struct device *dev, = void *data) if (cell->swnode) device_remove_software_node(&pdev->dev); =20 - list_for_each_entry_safe(of_entry, tmp, &mfd_of_node_list, list) - if (of_entry->dev =3D=3D &pdev->dev) { - list_del(&of_entry->list); - kfree(of_entry); - } + scoped_guard(mutex, &mfd_of_node_mutex) { + list_for_each_entry_safe(of_entry, tmp, &mfd_of_node_list, list) + if (of_entry->dev =3D=3D &pdev->dev) { + list_del(&of_entry->list); + kfree(of_entry); + } + } =20 regulator_bulk_unregister_supply_alias(dev, cell->parent_supplies, cell->num_parent_supplies); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B398A401D4A; Sat, 28 Feb 2026 17:43:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300621; cv=none; b=oDfiB+i3WNC8fCXSdU9MwXuH+aM4lnsNbtfWyDSFhxVzTqn/fgSGdGhPpctGPetjQcmzQl+4Hq9onyUYxZtXeGxffM/ipcGfy0/Gi5Iupqj0FWIZyTq5ORaWABaotHjsVT1gTtLyETvF/V7O8g7pW6XsbINdmofXxTTi3bawz9c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300621; c=relaxed/simple; bh=VYxZee+WZHv8VmJp6p+SGQWMaZCd5KJAiLp5Is6OUJg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YzAH1N73hHdDPdiRWHApz5j0+0Z8nSvcIlIciHr85JOBzeCeAISb8pr+qnagje8pNRTZts7zPBhvjQph9jZFzu3Lhi/RUfclDscd8L346Q9XYKfZ++2BPwYjuo7Qfu1gaL1sfZqi/ZcWQBO20I4jlB/FpudVXM0J0t2vfZpsW00= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KTTZGol4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KTTZGol4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E82B4C19424; Sat, 28 Feb 2026 17:43:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300621; bh=VYxZee+WZHv8VmJp6p+SGQWMaZCd5KJAiLp5Is6OUJg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KTTZGol40J3lgEgVxM+L/U/iguYgke3B6zdL0Id70wrRMZn2LGU+Ea8SyRw6nbH2N REQ+59+Rt+z0XwkTjGcwKe1b+MBoykEiUhBm84PhS+Fr0gblAwrg0JU1buV+Zg3Z5n 9mEshIZi8qhLhYoxhQw/JiVy4/76JIkkR+JtgwkRr+tXhArb3zjnotWS0PzJ8x5uCR h03QwJPr2VkFiw2fQZOV0G78mMrCR+iFV2DI6r+eOL4qDpS5h3UdPK2xfeJVkhtXrx InzhktB2pJzDurTWGHEJJRbOLF2m39gFDR5LCvoP2d52oZb6bYyrSEYxNJalX8rJ/w QSknwFftRYgmg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Kory Maincent (TI.com)" , Andrew Davis , Lee Jones , Sasha Levin Subject: [PATCH 6.19 662/844] mfd: tps65219: Implement LOCK register handling for TPS65214 Date: Sat, 28 Feb 2026 12:29:35 -0500 Message-ID: <20260228173244.1509663-663-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Kory Maincent (TI.com)" [ Upstream commit d3fcf276b501a82d4504fd5b1ed40249546530d1 ] The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to nearly all registers when locked. Unlock the registers at probe time and leave them unlocked permanently. This approach is justified because: - Register locking is very uncommon in typical system operation - No code path is expected to lock the registers during runtime - Adding a custom regmap write function would add overhead to every register write, including voltage changes triggered by CPU OPP transitions from the cpufreq governor which could happen quite frequently Cc: stable@vger.kernel.org Fixes: 7947219ab1a2d ("mfd: tps65219: Add support for TI TPS65214 PMIC") Reviewed-by: Andrew Davis Signed-off-by: Kory Maincent (TI.com) Link: https://patch.msgid.link/20251218-fix_tps65219-v5-1-8bb511417f3a@boot= lin.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mfd/tps65219.c | 9 +++++++++ include/linux/mfd/tps65219.h | 2 ++ 2 files changed, 11 insertions(+) diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c index 65a952555218d..7275dcdb7c44f 100644 --- a/drivers/mfd/tps65219.c +++ b/drivers/mfd/tps65219.c @@ -498,6 +498,15 @@ static int tps65219_probe(struct i2c_client *client) return ret; } =20 + if (chip_id =3D=3D TPS65214) { + ret =3D i2c_smbus_write_byte_data(client, TPS65214_REG_LOCK, + TPS65214_LOCK_ACCESS_CMD); + if (ret) { + dev_err(tps->dev, "Failed to unlock registers %d\n", ret); + return ret; + } + } + ret =3D devm_regmap_add_irq_chip(tps->dev, tps->regmap, client->irq, IRQF_ONESHOT, 0, pmic->irq_chip, &tps->irq_data); diff --git a/include/linux/mfd/tps65219.h b/include/linux/mfd/tps65219.h index 55234e771ba73..3abf937191d0c 100644 --- a/include/linux/mfd/tps65219.h +++ b/include/linux/mfd/tps65219.h @@ -149,6 +149,8 @@ enum pmic_id { #define TPS65215_ENABLE_LDO2_EN_MASK BIT(5) #define TPS65214_ENABLE_LDO1_EN_MASK BIT(5) #define TPS65219_ENABLE_LDO4_EN_MASK BIT(6) +/* Register Unlock */ +#define TPS65214_LOCK_ACCESS_CMD 0x5a /* power ON-OFF sequence slot */ #define TPS65219_BUCKS_LDOS_SEQUENCE_OFF_SLOT_MASK GENMASK(3, 0) #define TPS65219_BUCKS_LDOS_SEQUENCE_ON_SLOT_MASK GENMASK(7, 4) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE631492195; Sat, 28 Feb 2026 17:43:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300622; cv=none; b=jor7D2ylwh27SKLzSDFNDZGxZe6zsbLiM6mOSC1CzMEL9t+wHYKKiWhLge71ZnInrcTTwqIbY2fu1RlOhi2d7dfkNwlbj124VKQaegGX52b6rdtmXnjuq/LP7iQ6iZF0m8mRQYb1/DFqA2mvtHpAJRd68d8ZoblhC8PYc+V6tqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300622; c=relaxed/simple; bh=Gyu1YR+zMuhecVW92199mZE4m5Eie57u1ZQCuNNabPQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HUrBYb/8xTG08vn/3cgh2N7Z9js4NjCX2JUEL/iV9NlRdPvZs8U0KFmS6hVOYlU8QNelIyRKfIYqWY6qJ1LONvk79OJzXkFBWYd+Y9eEu3aauXBnoyLGs9gEPU4z5uxccSTEnVjBOFdEEmQnEvOGywbLEi9/wfHo8Tt/MXizU2k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CKnq4Q+P; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CKnq4Q+P" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCEA3C2BC87; Sat, 28 Feb 2026 17:43:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300622; bh=Gyu1YR+zMuhecVW92199mZE4m5Eie57u1ZQCuNNabPQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CKnq4Q+PWaIKAx02K8DiFn52SLmQtCB5B7QpZ+vJTOAn4iHoZY8xD0HI22Bjou+EW +/JP0hoLUY/YsXYZgrAhr+PscL0kKTaw0PrcBA/iGtndTLFPHMoblgSfOt60wOgqa1 FiJIbKzzJstZQpgU+sihIheDo4OvbvWCsCzKOkGWFTGg88NBMNbGjZYVpMAdTwfXab chAXQHQsut42C7HKtRJ0IN3IIHZHMb9aMMrmcX1ZGIDt5hhN8MBxghlxIBE+AVqTAF cceP1rPFonNHHvRZ27yUHWIZ4XosrZtYvT/XhwLhbSavRz+8f+QPxsfXVLzEc6Vv5O brVd/9ei+shyg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Janne Grunau , Sven Peter , Neal Gompa , Lee Jones , Sasha Levin Subject: [PATCH 6.19 663/844] mfd: macsmc: Initialize mutex Date: Sat, 28 Feb 2026 12:29:36 -0500 Message-ID: <20260228173244.1509663-664-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Janne Grunau [ Upstream commit 414f65d6736342c77d4ec5e7373039f4a09250dd ] Initialize struct apple_smc's mutex in apple_smc_probe(). Using the mutex uninitialized surprisingly resulted only in occasional NULL pointer dereferences in apple_smc_read() calls from the probe() functions of sub devices. Cc: stable@vger.kernel.org Fixes: e038d985c9823 ("mfd: Add Apple Silicon System Management Controller") Signed-off-by: Janne Grunau Reviewed-by: Sven Peter Reviewed-by: Neal Gompa Link: https://patch.msgid.link/20251231-macsmc-mutex_init-v2-1-5818c9dc9b29= @jannau.net Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mfd/macsmc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/macsmc.c b/drivers/mfd/macsmc.c index e3893e255ce5e..3015e8d36d6e5 100644 --- a/drivers/mfd/macsmc.c +++ b/drivers/mfd/macsmc.c @@ -413,6 +413,7 @@ static int apple_smc_probe(struct platform_device *pdev) if (!smc) return -ENOMEM; =20 + mutex_init(&smc->mutex); smc->dev =3D &pdev->dev; smc->sram_base =3D devm_platform_get_and_ioremap_resource(pdev, 1, &smc->= sram); if (IS_ERR(smc->sram_base)) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6A0F4025B9; Sat, 28 Feb 2026 17:43:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300623; cv=none; b=JJaP6DYt5HLfhtkDWeo8ZKxFqlhi58ICUvma3rDwLjUoDgL0WF7+leKm3r/fH62EHybHTEpWPrwYyeidp7RznTF3KIr49u6W+aqxmgjBw7fr9Zp+S5zOZ/ICXMAmUY4lBgWi+mIWTj9RaqMAlYXrjdo/kT9wjPpWtMq9mW0z/vU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300623; c=relaxed/simple; bh=YwH7ocqVR6BTEcFleyAorSaH1+d3lxPTj54krC2x6Lo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B9dxBwmOk2fag3ue2+IFlCGuQjenqht4qAukzK7nkzvZ0/om84VeQ6mDI4M3MiPnc5/sQTn5L3uUf8Lv6FHQynt1oCxJ5jMeiwE+qt+29+Znla+3xI+IDVaDn8tlBVTXr8u0bf1qrfAHnhAr0uPTnIadiFW55tw62fykn1gSENM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HsvOd+vj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HsvOd+vj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E507DC19424; Sat, 28 Feb 2026 17:43:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300623; bh=YwH7ocqVR6BTEcFleyAorSaH1+d3lxPTj54krC2x6Lo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HsvOd+vjt7it8W4yzZyNoXnifjUrr/XWWoTCIB4VDNQMBamRoMjCeaWSBmHY8BPTB RPlnKE5MKh1qSx/F+rvKf0FhUoXmmCyCUu+9SsY+1/aTxVZgl4/1scBnDP8scis1rW NX0/GwIdKjgzt+OvaQPLl3UTW5YPZ/Dw7P+4r4pSPBAYX9Z9sPjhUKJ2kFbkz6uRQP 3dGux9SV8QL/Jgn4xDzicvHHzbx54sEWBqrI8eQFd6Z++dK91All9AqMaOV8T+3wmb s9NUsp/tI/lI4GzB2jkJOjPIZemSJH1bvoQd9ngOcdf5dM/o/02W5oaiJC6b+D0zAo ktgfrVqVbPKhQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Dmitry Baryshkov , Konrad Dybcio , Lee Jones , Sasha Levin Subject: [PATCH 6.19 664/844] mfd: qcom-pm8xxx: Fix OF populate on driver rebind Date: Sat, 28 Feb 2026 12:29:37 -0500 Message-ID: <20260228173244.1509663-665-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit 27a8acea47a93fea6ad0e2df4c20a9b51490e4d9 ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20251219110947.24101-1-johan@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mfd/qcom-pm8xxx.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c index 1149f7102a365..0cf374c015ce7 100644 --- a/drivers/mfd/qcom-pm8xxx.c +++ b/drivers/mfd/qcom-pm8xxx.c @@ -577,17 +577,11 @@ static int pm8xxx_probe(struct platform_device *pdev) return rc; } =20 -static int pm8xxx_remove_child(struct device *dev, void *unused) -{ - platform_device_unregister(to_platform_device(dev)); - return 0; -} - static void pm8xxx_remove(struct platform_device *pdev) { struct pm_irq_chip *chip =3D platform_get_drvdata(pdev); =20 - device_for_each_child(&pdev->dev, NULL, pm8xxx_remove_child); + of_platform_depopulate(&pdev->dev); irq_domain_remove(chip->irqdomain); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B8D3D4025D3; Sat, 28 Feb 2026 17:43:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300624; cv=none; b=fnXSr8PgUJPCjOB1T2YeO2BuG5aQJODKX8+qKt/yj1v5yIm/lEcukotC8jyrZdw0sRjiL3yqChPtdB7iOzJUbMBoH2ig6E0TneVcDoThpV3+wDM4cAFwjTVRq5Tx2IsZy8PrXJ75IfmNx8QCrjz3poU0mXS/pJ4tGKx8WHswFOg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300624; c=relaxed/simple; bh=DfTHN1u93uLIZw+bEt+LefiO8/Gp2UrF+x2t8RkN7SY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YaKleQgcfQwU8TwFL68Rmut45/UkRrdcihSAQo7GL4CgXkbUt9QHPF5t0wqunwucNZ0WpQzBERvj/3UBnnng0n61OYPWtrMg1slCjZ52xM0WPj7Zz87FR4jDZU2abZZAIMbHZhomGCViat2qrnS95xCf3t/SzuCxRWc24IBqt7U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N7i+OJZK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N7i+OJZK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC8E4C19423; Sat, 28 Feb 2026 17:43:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300624; bh=DfTHN1u93uLIZw+bEt+LefiO8/Gp2UrF+x2t8RkN7SY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N7i+OJZKjZGN5LNIADEy2MH9DX9jstfRFUAqEenvg+Rq9j9NJ3W5WQfogM+3u01b8 43PwPVWXCAGq+g5XyCiVSjYpyKutGf+12ZmzQ3y2YahsRZ72Yhjf702wOT5WgcDf7C Sdx2h4zeGaDkuHuQRB8GCJILcHhnC7OG0JYtPTCCYZHuUNNHKTjSN6wzrMAz6/39XR h0sa4GBM6UgZASneK92/EtzZmnxT8jW7RivpmapKXnoOkWQ7D1DaLaQYvQBqQryYT3 PTgKCr7inD8uSpXGlJRe6c9EZ/FXXOMVBpEXyw6IHIi7RzWI+s1U1e7WZw7IJl1hcx YdMRLeMkkTkNA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Andreas Kemnade , Lee Jones , Sasha Levin Subject: [PATCH 6.19 665/844] mfd: omap-usb-host: Fix OF populate on driver rebind Date: Sat, 28 Feb 2026 12:29:38 -0500 Message-ID: <20260228173244.1509663-666-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit 24804ba508a3e240501c521685a1c4eb9f574f8e ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20251219110714.23919-1-johan@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mfd/omap-usb-host.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c index a77b6fc790f2e..4d29a6e2ed87a 100644 --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -819,8 +819,10 @@ static void usbhs_omap_remove(struct platform_device *= pdev) { pm_runtime_disable(&pdev->dev); =20 - /* remove children */ - device_for_each_child(&pdev->dev, NULL, usbhs_omap_remove_child); + if (pdev->dev.of_node) + of_platform_depopulate(&pdev->dev); + else + device_for_each_child(&pdev->dev, NULL, usbhs_omap_remove_child); } =20 static const struct dev_pm_ops usbhsomap_dev_pm_ops =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C07ED402D67; Sat, 28 Feb 2026 17:43:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300625; cv=none; b=IYw+wBNBoxCYZvP7Ta5li9u6P1R1qMdwb2Oc8i18Q/GYo7j7naBmWu6TMvbpstuNcDra8JRwfl8HUN1ZJIYKTBAV+4FaRPxsiM9CRkOVWI03fqpZKrYQmXOfwN3dvCUlGCs5Ji60ZgBBLleIBm+kqqnrpaHUoN9I5y96fX+3YRc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300625; c=relaxed/simple; bh=fp1s/Q7tHaLyjsrulurs6UUQlDGA8a88fPiCQOYui7g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hBHi08EUN6/TPSqV2RCbX7Y3p8LfOs6sMsLjJzkA8swZym3w+t7ZKfOxCc2p2GHbM6oOBWLqxUG/azhfVOg5COIlKOWZmCgTyy75+gBDI0eYb1L99281gfAlnkSLbOhTRhvLxwikgMtIyZtAFkj5fEsQq8jos6alIfP6H0HyGig= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GoBw3XAL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GoBw3XAL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E132CC19423; Sat, 28 Feb 2026 17:43:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300625; bh=fp1s/Q7tHaLyjsrulurs6UUQlDGA8a88fPiCQOYui7g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GoBw3XALJEm64K8dv7x3gOnonuBrfgK3GeBcuHn54CDpaLABPm6OHEvhSCEwUl6Ys S6RfvUGsXBIRmPXEWHMpDPuxgtWA0yMmpOM9LRYpjNPpbM5RtuyQCPfoAQ+3wM1+p+ swuQ7/Fn5LHucaBScYWceos1T5godkGrjHibAASbsF5AsJX7ZvL1iQKK/ubWAjfkSJ 2SXAv1AmBBpxIZUqZIDUYnz5bX8njaqC1WFpV6ro6Dv85qSvlNG0ESVovuuP6z0Hzh 4gQ0GIN+zVfsIv/mj/Hkd/S6jmz16jyM7cRhDH2e2p3+grfMpb4mMcdzgS43nTpoSD 4u71CgCxUH7zw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gao Xiang , stable@kernel.org, Hongbo Li , Chao Yu , Sasha Levin Subject: [PATCH 6.19 666/844] erofs: fix incorrect early exits for invalid metabox-enabled images Date: Sat, 28 Feb 2026 12:29:39 -0500 Message-ID: <20260228173244.1509663-667-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gao Xiang [ Upstream commit 643575d5a4f24b23b0c54aa20aa74a4abed8ff5e ] Crafted EROFS images with metadata compression enabled can trigger incorrect early returns, leading to folio reference leaks. However, this does not cause system crashes or other severe issues. Fixes: 414091322c63 ("erofs: implement metadata compression") Cc: stable@kernel.org Reviewed-by: Hongbo Li Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/erofs/super.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/erofs/super.c b/fs/erofs/super.c index 5136cda5972a9..b54083128e0f4 100644 --- a/fs/erofs/super.c +++ b/fs/erofs/super.c @@ -330,12 +330,13 @@ static int erofs_read_superblock(struct super_block *= sb) } sbi->packed_nid =3D le64_to_cpu(dsb->packed_nid); if (erofs_sb_has_metabox(sbi)) { + ret =3D -EFSCORRUPTED; if (sbi->sb_size <=3D offsetof(struct erofs_super_block, metabox_nid)) - return -EFSCORRUPTED; + goto out; sbi->metabox_nid =3D le64_to_cpu(dsb->metabox_nid); if (sbi->metabox_nid & BIT_ULL(EROFS_DIRENT_NID_METABOX_BIT)) - return -EFSCORRUPTED; /* self-loop detection */ + goto out; /* self-loop detection */ } sbi->inos =3D le64_to_cpu(dsb->inos); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C655C402D85; Sat, 28 Feb 2026 17:43:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300626; cv=none; b=nlyhE5X8rUrnR7cFqzWUFlzWmj33stnqbsKN89MZe9+zwHzRHdZ0edPd8XD9a+p3B3IklzuZM3CnGLQUlKnFXgsJJUJXBaE1wwAZnEcVJZZnLZXSTNmJOPjjGWQDGe3WlPM2RFyZ9aKgi939Qdx8GY4b7SGWHvGXHMGQwTGemYg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300626; c=relaxed/simple; bh=pC5QG1l/bE6I4C1vnl30URd/Rzo8ssJRGcMFuJ7TZNw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f/zrs62ExA4gxZQQr0c+0YY8Bt4Xb1ZRnnIx41kaPQgYFEHKJ8705ruhJNnDyNdAuHvkbCtZOpdTGDWjlz3yRyo/kZzfa/gggUMA0kF0VSkQZretxZh7oQDIxthfWeZ0OBhmVfOlpBvwimfEU1EO5BxctQJhgXrf0BWWnzz2zgY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UyK8mvpY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UyK8mvpY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7683C116D0; Sat, 28 Feb 2026 17:43:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300626; bh=pC5QG1l/bE6I4C1vnl30URd/Rzo8ssJRGcMFuJ7TZNw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UyK8mvpYRpx1HBRy5haWQuvJo6u3T44ERkIzBKIgwehFAWe5u8ik1ZiFqmwpfFjSB vd2+XeDUgMhz/6tqazuSsOJ3xzUzZ8p5DaHKh4QlZWskqc4ZAbJS2Ag4wtiWzZU/kn Y1QGh8gn2RNmPRUEpW/GZoxJwmOOBC+20AXiCXmsfumbyezX3RO211TCfNb4K+gQtE zGNAIEsWSNDMsjTOqk1JIWNw2ididcvyxiZyUnUxyAjGKy2zI1KTEN1U6YyoDgqt2Y ej/mbDytEW0qp055WQiiBN6yJlxYPBRK7GMazExrOsRnfeFCr7/L9L57WTnY+jDjyL YVmkwtgeerhjw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gao Xiang , stable@kernel.org, Hongbo Li , Chao Yu , Sasha Levin Subject: [PATCH 6.19 667/844] erofs: fix incorrect early exits in volume label handling Date: Sat, 28 Feb 2026 12:29:40 -0500 Message-ID: <20260228173244.1509663-668-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gao Xiang [ Upstream commit 3afa4da38802a4cba1c23848a32284e7e57b831b ] Crafted EROFS images containing valid volume labels can trigger incorrect early returns, leading to folio reference leaks. However, this does not cause system crashes or other severe issues. Fixes: 1cf12c717741 ("erofs: Add support for FS_IOC_GETFSLABEL") Cc: stable@kernel.org Reviewed-by: Hongbo Li Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/erofs/super.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/erofs/super.c b/fs/erofs/super.c index b54083128e0f4..ee37628ec99fb 100644 --- a/fs/erofs/super.c +++ b/fs/erofs/super.c @@ -347,8 +347,10 @@ static int erofs_read_superblock(struct super_block *s= b) if (dsb->volume_name[0]) { sbi->volume_name =3D kstrndup(dsb->volume_name, sizeof(dsb->volume_name), GFP_KERNEL); - if (!sbi->volume_name) - return -ENOMEM; + if (!sbi->volume_name) { + ret =3D -ENOMEM; + goto out; + } } =20 /* parse on-disk compression configurations */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08047401D2B; Sat, 28 Feb 2026 17:43:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300628; cv=none; b=n6ur+Wg3evtyDEKI/ZWtkcdUMgOiOUAatA54qInxqo30i8of1K0wqvnwHK3zRQukgLBcRWA2Iu2rQE+IY4C6zmVz/StcYI72kJjYiW1lvAcwfLv3T8qvUpfY6RxqHUHG2sI/6DPTaI6tH4uNwG93euObXCe3m5u2QibiYXFbApI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300628; c=relaxed/simple; bh=ztlT3saRJbDT5bqLP6NFt7aq6pAsT7FeK9qce3Gfwuk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y9w9lzpnsWXI7Yihl8sKsAzrBrCQNdz29k/w0tsOj+hdoaci1Tcw/rCkgiqkiJSQaHuvtCVP7KDW61lHORL3Ky1Du11gQOBLz7s8KE4k3zoIxBLCqUIoFBacIQYj/urrIa4ArNExIHVRSc8N0I3bQG7TAUWOn91fiKrLY00a6cc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KoptyfAW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KoptyfAW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EFC8AC116D0; Sat, 28 Feb 2026 17:43:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300627; bh=ztlT3saRJbDT5bqLP6NFt7aq6pAsT7FeK9qce3Gfwuk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KoptyfAWfUuylq6kNLWJte0xaLdhVi1V+6q/ZPsXoEL58N2U48nNy5luYGFhXV0YP Fy4+Dbm8uSoAl4bP0wcXXDI3qg21sVlSAee8asYXlqsHAsJvTjvyslkjVRNB4mgG8h K7nKpk14eKXw1wkUf1kk3BXK6HvW46IB3iFVSfI5nJz1DO9wiHy6sZLI2uzMMHBvdq kmn1eLkrMr+zVVs9fjd+2xmWBB7ELGcOzh2EeGjThkP8IiBfWuar7JjSTH+GIneXL2 5OKl/eSWIVBODVheo0LePXCDJ5FqObhDmXejpIg+Ik7eFY7XPqcA3Hu/M4HaEX/2za 6tceS9HlkWZwg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alexey Charkov , Quentin Schulz , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.19 668/844] arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576 Date: Sat, 28 Feb 2026 12:29:41 -0500 Message-ID: <20260228173244.1509663-669-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexey Charkov [ Upstream commit 79a3286e61829fc43abdd6e3beb31b24930c7af6 ] Rockchip RK3576 UFS controller uses a dedicated pin to reset the connected UFS device, which can operate either in a hardware controlled mode or as a GPIO pin. Power-on default is GPIO mode, but the boot ROM reconfigures it to a hardware controlled mode if it uses UFS to load the next boot stage. Given that existing bindings (and rk3576.dtsi) expect a GPIO-controlled device reset, request the required pin config explicitly. The pin is requested with pull-down enabled, which is in line with the SoC power-on default and helps ensure that the attached UFS chip stays in reset until the driver takes over the control of the respective GPIO line. This doesn't appear to affect Linux, but it does affect U-boot: Before: =3D> md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ... > =3D> ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=3D[3, 3], lane[2, 2], pwr[FA= STAUTO_MODE, FASTAUTO_MODE], rate =3D 2 =3D> md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ After: =3D> md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ...> =3D> ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=3D[3, 3], lane[2, 2], pwr[FA= STAUTO_MODE, FASTAUTO_MODE], rate =3D 2 =3D> md.l 0x2604b398 2604b398: 00000010 00000000 00000000 00000000 ................ (0x2604b398 is the respective pin mux register, with its BIT0 driving the mode of UFS_RST: unset =3D GPIO, set =3D hardware controlled UFS_RST) This helps ensure that GPIO-driven device reset actually fires when the system requests it, not when whatever black box magic inside the UFSHC decides to reset the flash chip. Cc: stable@vger.kernel.org Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK357= 6 SoC") Reported-by: Quentin Schulz Reviewed-by: Quentin Schulz Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260121-ufs-rst-v3-1-35839bcb4ca7@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi | 7 +++++++ arch/arm64/boot/dts/rockchip/rk3576.dtsi | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi b/arch/arm64/= boot/dts/rockchip/rk3576-pinctrl.dtsi index 0b0851a7e4ea9..98c9f8013158c 100644 --- a/arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi @@ -5228,6 +5228,13 @@ ufs_rst: ufs-rst { /* ufs_rstn */ <4 RK_PD0 1 &pcfg_pull_none>; }; + + /omit-if-no-ref/ + ufs_rstgpio: ufs-rstgpio { + rockchip,pins =3D + /* ufs_rstn */ + <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_down>; + }; }; =20 ufs_testdata0 { diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts= /rockchip/rk3576.dtsi index c72343e7a0456..70e67d4dccb8a 100644 --- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi @@ -1826,7 +1826,7 @@ ufshc: ufshc@2a2d0000 { assigned-clock-parents =3D <&cru CLK_REF_MPHY_26M>; interrupts =3D ; power-domains =3D <&power RK3576_PD_USB>; - pinctrl-0 =3D <&ufs_refclk>; + pinctrl-0 =3D <&ufs_refclk &ufs_rstgpio>; pinctrl-names =3D "default"; resets =3D <&cru SRST_A_UFS_BIU>, <&cru SRST_A_UFS_SYS>, <&cru SRST_A_UFS>, <&cru SRST_P_UFS_GRF>; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A912B35F5EC; Sat, 28 Feb 2026 17:43:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300628; cv=none; b=igxHc1S04AnoL2RXvsuNuM//ChppmoeVi/CXD4fWEWZI0ViZgdJ5sZP8h/F6isYffqIanFfsNyFG6eSRCeKjJFH+eclny3VK6sgMCHHY7pbsjRdvmrYpLpzaqPA+Q1zPuVS+HocCJsiVodJk+j+d07PMoOkfAAz7neKnjlKAqs0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300628; c=relaxed/simple; bh=DxwOjVHa6ljGNxDzcQvadqF7PJ2KfWO294/LSSF1MBE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lQQJz9SZ02gDd4uRQiPsEs2E5bPyo/Akd4q6CRiVif/Tsnk4xVfgbZRUPBYrkf3tRQa9L1dGQ2MmJesYxAL64O+4rVQYlc7DJpHZHd1vt4fUUg9oA2ITk8PXSM2VnNK/m5dxBhNIEHogPBVrFcLQkeI6MXhcaXOmFT5GwUBKEro= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iIyI+nQc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iIyI+nQc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E225CC19424; Sat, 28 Feb 2026 17:43:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300628; bh=DxwOjVHa6ljGNxDzcQvadqF7PJ2KfWO294/LSSF1MBE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iIyI+nQcbd3NE0dikim5V0+RTwDeLxP8K/9bCPTNVTJL5KBWuB6kgV5W+EEJvdZJW Y5IfKINafJJMfHWOJss8kPu9O3rbiP3WKAXJe35/ecHGmlMJrwJeWQEV6AgJqBkZ96 RRrg7NkWKCbsG7k7QkAOwoLR3vEK04XKuTIfI6VMEIBzeWsHsqGJa8HiBto8R+6qgy WXpj8h5FeDBAOinI2YLTC/s15VTZk6CX0pcdHpDmX14G7SEVN44nh1Y8AOkYl5wpAe +5JfCavdIaDryCudMySQcn3hHkFe9RjZ/KDONnJq95lbEZxNMn2e8Mw5JKFSbeiXLL k0l20Rbn32zFw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shawn Lin , Andrew Powers-Holmes , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.19 669/844] arm64: dts: rockchip: Fix rk356x PCIe range mappings Date: Sat, 28 Feb 2026 12:29:42 -0500 Message-ID: <20260228173244.1509663-670-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shawn Lin [ Upstream commit f63ea193a404481f080ca2958f73e9f364682db9 ] The pcie bus address should be mapped 1:1 to the cpu side MMIO address, so that there is no same address allocated from normal system memory. Otherwise it's broken if the same address assigned to the EP for DMA purpose.Fix it to sync with the vendor BSP. Fixes: 568a67e742df ("arm64: dts: rockchip: Fix rk356x PCIe register and ra= nge mappings") Fixes: 66b51ea7d70f ("arm64: dts: rockchip: Add rk3568 PCIe2x1 controller") Cc: stable@vger.kernel.org Cc: Andrew Powers-Holmes Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1767600929-195341-1-git-send-email-shawn.lin= @rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 ++-- arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts= /rockchip/rk3568.dtsi index e719a3df126c5..658097ed69714 100644 --- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi @@ -185,7 +185,7 @@ pcie3x1: pcie@fe270000 { <0x0 0xf2000000 0x0 0x00100000>; ranges =3D <0x01000000 0x0 0xf2100000 0x0 0xf2100000 0x0 0x00100000>, <0x02000000 0x0 0xf2200000 0x0 0xf2200000 0x0 0x01e00000>, - <0x03000000 0x0 0x40000000 0x3 0x40000000 0x0 0x40000000>; + <0x03000000 0x3 0x40000000 0x3 0x40000000 0x0 0x40000000>; reg-names =3D "dbi", "apb", "config"; resets =3D <&cru SRST_PCIE30X1_POWERUP>; reset-names =3D "pipe"; @@ -238,7 +238,7 @@ pcie3x2: pcie@fe280000 { <0x0 0xf0000000 0x0 0x00100000>; ranges =3D <0x01000000 0x0 0xf0100000 0x0 0xf0100000 0x0 0x00100000>, <0x02000000 0x0 0xf0200000 0x0 0xf0200000 0x0 0x01e00000>, - <0x03000000 0x0 0x40000000 0x3 0x80000000 0x0 0x40000000>; + <0x03000000 0x3 0x80000000 0x3 0x80000000 0x0 0x40000000>; reg-names =3D "dbi", "apb", "config"; resets =3D <&cru SRST_PCIE30X2_POWERUP>; reset-names =3D "pipe"; diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boo= t/dts/rockchip/rk356x-base.dtsi index 8893b7b6cc9ff..a2c4957a58992 100644 --- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi @@ -1022,7 +1022,7 @@ pcie2x1: pcie@fe260000 { power-domains =3D <&power RK3568_PD_PIPE>; ranges =3D <0x01000000 0x0 0xf4100000 0x0 0xf4100000 0x0 0x00100000>, <0x02000000 0x0 0xf4200000 0x0 0xf4200000 0x0 0x01e00000>, - <0x03000000 0x0 0x40000000 0x3 0x00000000 0x0 0x40000000>; + <0x03000000 0x3 0x00000000 0x3 0x00000000 0x0 0x40000000>; resets =3D <&cru SRST_PCIE20_POWERUP>; reset-names =3D "pipe"; #address-cells =3D <3>; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E461F35F60E; Sat, 28 Feb 2026 17:43:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300630; cv=none; b=t5SdB9htDS5F/1IFVKVEhZWtbLLuUPgBNdiZQerISOEf9gHGRAYjjkKhNY/URpxx1wck0gmiYAmnEBF2xevNclFSbJiKsOfBbuMTVlSdmDvwOjmrEsuCBzmJuwOfk1hoObdnj1Jw1sCMuqoLU2EOQOH2degAwp+OlMocue1wv0o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300630; c=relaxed/simple; bh=Xz8j6pxbQ/FSfDETEPnOFVY7lRTXjT+0U3o495G38Oo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jn+TqBGqg69BfrKItmNFnV+PSoieZ+awC2vu+t2NDdZ0NqrdG0nDMjRrbl/Loni7qm32NJT6QJ5UMclP1eL2yOorpDVg20H4JsqpDMjx+XnMSyWcY1jC0g9pB2sboU5ldFTfYHFQ4g397J7RXI9qILMbwGId4vdFgZqWtZgV1rE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SkyUvV1Q; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SkyUvV1Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1F53C19425; Sat, 28 Feb 2026 17:43:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300629; bh=Xz8j6pxbQ/FSfDETEPnOFVY7lRTXjT+0U3o495G38Oo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SkyUvV1QHs4QI0SE4VxCJ6rd3vjLLxjDpvP+qnvWXi/qPQWKSDaqOOWgBLjt48Fe3 aNWA1l0Ec9WwIRS3cmMsB9G5LGmarpsGcHg3gLxzEgo9oaPuIpQwh60Oc66GgvEgPj aoP4f19nyYHRcYMkj/LXpg2jufHfrtOXaS64KnRJXTw0vT0wTdahHjYtUlSVHA2D/Z F8Pb0UutDH2hRIJxHjDtAt7oEtKpoIjOQ9Jlz1MkJBwPszcMhXPN9kfqQYoZAO8Mp+ eFkEHsa6SzMITWWzsPqRx6flK3ZFKo8Db+jl8QdVKqpp/6OlCnvAhGsZgTht2vfJlT qdFkyrt6BXIqw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shawn Lin , Sebastian Reichel , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.19 670/844] arm64: dts: rockchip: Fix rk3588 PCIe range mappings Date: Sat, 28 Feb 2026 12:29:43 -0500 Message-ID: <20260228173244.1509663-671-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shawn Lin [ Upstream commit 46c56b737161060dfa468f25ae699749047902a2 ] The pcie bus address should be mapped 1:1 to the cpu side MMIO address, so that there is no same address allocated from normal system memory. Otherwise it's broken if the same address assigned to the EP for DMA purpose.Fix it to sync with the vendor BSP. Fixes: 0acf4fa7f187 ("arm64: dts: rockchip: add PCIe3 support for rk3588") Fixes: 8d81b77f4c49 ("arm64: dts: rockchip: add rk3588 PCIe2 support") Cc: stable@vger.kernel.org Cc: Sebastian Reichel Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1767600929-195341-2-git-send-email-shawn.lin= @rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 ++-- arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boo= t/dts/rockchip/rk3588-base.dtsi index 7ab12d1054a73..fdb017258b7bc 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi @@ -1955,7 +1955,7 @@ pcie2x1l1: pcie@fe180000 { power-domains =3D <&power RK3588_PD_PCIE>; ranges =3D <0x01000000 0x0 0xf3100000 0x0 0xf3100000 0x0 0x00100000>, <0x02000000 0x0 0xf3200000 0x0 0xf3200000 0x0 0x00e00000>, - <0x03000000 0x0 0x40000000 0x9 0xc0000000 0x0 0x40000000>; + <0x03000000 0x9 0xc0000000 0x9 0xc0000000 0x0 0x40000000>; reg =3D <0xa 0x40c00000 0x0 0x00400000>, <0x0 0xfe180000 0x0 0x00010000>, <0x0 0xf3000000 0x0 0x00100000>; @@ -2007,7 +2007,7 @@ pcie2x1l2: pcie@fe190000 { power-domains =3D <&power RK3588_PD_PCIE>; ranges =3D <0x01000000 0x0 0xf4100000 0x0 0xf4100000 0x0 0x00100000>, <0x02000000 0x0 0xf4200000 0x0 0xf4200000 0x0 0x00e00000>, - <0x03000000 0x0 0x40000000 0xa 0x00000000 0x0 0x40000000>; + <0x03000000 0xa 0x00000000 0xa 0x00000000 0x0 0x40000000>; reg =3D <0xa 0x41000000 0x0 0x00400000>, <0x0 0xfe190000 0x0 0x00010000>, <0x0 0xf4000000 0x0 0x00100000>; diff --git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/bo= ot/dts/rockchip/rk3588-extra.dtsi index 6e5a58428bbab..a2640014ee042 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi @@ -375,7 +375,7 @@ pcie3x4: pcie@fe150000 { power-domains =3D <&power RK3588_PD_PCIE>; ranges =3D <0x01000000 0x0 0xf0100000 0x0 0xf0100000 0x0 0x00100000>, <0x02000000 0x0 0xf0200000 0x0 0xf0200000 0x0 0x00e00000>, - <0x03000000 0x0 0x40000000 0x9 0x00000000 0x0 0x40000000>; + <0x03000000 0x9 0x00000000 0x9 0x00000000 0x0 0x40000000>; reg =3D <0xa 0x40000000 0x0 0x00400000>, <0x0 0xfe150000 0x0 0x00010000>, <0x0 0xf0000000 0x0 0x00100000>; @@ -462,7 +462,7 @@ pcie3x2: pcie@fe160000 { power-domains =3D <&power RK3588_PD_PCIE>; ranges =3D <0x01000000 0x0 0xf1100000 0x0 0xf1100000 0x0 0x00100000>, <0x02000000 0x0 0xf1200000 0x0 0xf1200000 0x0 0x00e00000>, - <0x03000000 0x0 0x40000000 0x9 0x40000000 0x0 0x40000000>; + <0x03000000 0x9 0x40000000 0x9 0x40000000 0x0 0x40000000>; reg =3D <0xa 0x40400000 0x0 0x00400000>, <0x0 0xfe160000 0x0 0x00010000>, <0x0 0xf1000000 0x0 0x00100000>; @@ -512,7 +512,7 @@ pcie2x1l0: pcie@fe170000 { power-domains =3D <&power RK3588_PD_PCIE>; ranges =3D <0x01000000 0x0 0xf2100000 0x0 0xf2100000 0x0 0x00100000>, <0x02000000 0x0 0xf2200000 0x0 0xf2200000 0x0 0x00e00000>, - <0x03000000 0x0 0x40000000 0x9 0x80000000 0x0 0x40000000>; + <0x03000000 0x9 0x80000000 0x9 0x80000000 0x0 0x40000000>; reg =3D <0xa 0x40800000 0x0 0x00400000>, <0x0 0xfe170000 0x0 0x00010000>, <0x0 0xf2000000 0x0 0x00100000>; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DD724921AA; Sat, 28 Feb 2026 17:43:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300630; cv=none; b=XYXUiSE9yiLS/mgkZDyAXp55+MZQGyIyloahEoqCXwX4CRmZG/8XzVsuyliJ0ZRlQHUO4EGqwePC8s17mcMhMwe1VnfhYvd3eREM0Ui1Hn+XFNRack2outEK69YPLmeLRGyfyTLL6qE8rH2M3F77Xl8uVlfK+xExq3rraBmbvjw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300630; c=relaxed/simple; bh=6cfPf4UrLZqeLG2ynVj+rtBkw4gw8pRAYGT4JMrGWWg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kl26mdNjm6H9QzAkUVWIjvqNTzgpwtYP0uuLoKw7wO0HQaujlc0utsiK1oDF5DwgsMyXlHBaeWFjfPYV3Z59l8r9F7bo/tV/t/l7ONDtrk9L40S0TlbRmNUwzSW7GG1PLKCP1/i8dKEGz/yGBD8lzOclmHxLLIIE5o8iL/FwsPA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=klf3YEPa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="klf3YEPa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9D3BC116D0; Sat, 28 Feb 2026 17:43:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300630; bh=6cfPf4UrLZqeLG2ynVj+rtBkw4gw8pRAYGT4JMrGWWg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=klf3YEPaZDHBlAdwif+Ih/nWSAwnzOHiOy5/J95EylJcj0skfC7Pnyee4pvvna27M Rgs3aSAqbrvg6uu7n6xJtqdx7MYYJ/os0k0lAt8uDT7Gi1K2KxJIeMuoUh2/daqrDh OPmq7YE5nZt+gRfp+cb9orQfcZBHpvTm4rYvlLEcDSbOscMpt5+OHslXHVoeeCNXrZ ojxpL6tEgP1F3w55odJQbBADiSsOZQqFnt/S7MPI5rqAtyMoFvKmp6fywekQ2xmOf6 h77C8masdAYmwtO+voKZ3oshDqzKylIDLIZ8nowH3DxaurveUzoi0QZNq5heypA2xj ElUfbKZ9YUlnQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Brian Norris , Bjorn Helgaas , Marek Szyprowski , Sasha Levin Subject: [PATCH 6.19 671/844] PCI/PM: Prevent runtime suspend until devices are fully initialized Date: Sat, 28 Feb 2026 12:29:44 -0500 Message-ID: <20260228173244.1509663-672-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Brian Norris [ Upstream commit 51c0996dadaea20d73eb0495aeda9cb0422243e8 ] Previously, it was possible for a PCI device to be runtime-suspended before it was fully initialized. When that happened, the suspend process could save invalid device state, for example, before BAR assignment. Restoring the invalid state during resume may leave the device non-functional. Prevent runtime suspend for PCI devices until they are fully initialized by deferring pm_runtime_enable(). More details on how exactly this may occur: 1. PCI device is created by pci_scan_slot() or similar 2. As part of pci_scan_slot(), pci_pm_init() puts the device in D0 and prevents runtime suspend prevented via pm_runtime_forbid() 3. pci_device_add() adds the underlying 'struct device' via device_add(), which means user space can allow runtime suspend, e.g., echo auto > /sys/bus/pci/devices/.../power/control 4. PCI device receives BAR configuration (pci_assign_unassigned_bus_resources(), etc.) 5. pci_bus_add_device() applies final fixups, saves device state, and tries to attach a driver The device may potentially be suspended between #3 and #5, so this is racy with user space (udev or similar). Many PCI devices are enumerated at subsys_initcall time and so will not race with user space, but devices created later by hotplug or modular pwrctrl or host controller drivers are susceptible to this race. More runtime PM details at the first Link: below. Link: https://lore.kernel.org/all/0e35a4e1-894a-47c1-9528-fc5ffbafd9e2@sams= ung.com/ Signed-off-by: Brian Norris [bhelgaas: update comments per https://lore.kernel.org/r/CAJZ5v0iBNOmMtqfqE= brYyuK2u+2J2+zZ-iQd1FvyCPjdvU2TJg@mail.gmail.com] Signed-off-by: Bjorn Helgaas Tested-by: Marek Szyprowski Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260122094815.v5.1.I60a53c170a8596661883bd2= b4ef475155c7aa72b@changeid Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/bus.c | 8 ++++++++ drivers/pci/pci.c | 8 +++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c index 4383a36fd6ca0..41e5c45e38b5e 100644 --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include =20 @@ -379,6 +380,13 @@ void pci_bus_add_device(struct pci_dev *dev) put_device(&pdev->dev); } =20 + /* + * Enable runtime PM, which potentially allows the device to + * suspend immediately, only after the PCI state has been + * configured completely. + */ + pm_runtime_enable(&dev->dev); + if (!dn || of_device_is_available(dn)) pci_dev_allow_binding(dev); =20 diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index f21f6933c9b63..a4eb3bc2127ae 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3199,8 +3199,14 @@ void pci_pm_init(struct pci_dev *dev) poweron: pci_pm_power_up_and_verify_state(dev); pm_runtime_forbid(&dev->dev); + + /* + * Runtime PM will be enabled for the device when it has been fully + * configured, but since its parent and suppliers may suspend in + * the meantime, prevent them from doing so by changing the + * device's runtime PM status to "active". + */ pm_runtime_set_active(&dev->dev); - pm_runtime_enable(&dev->dev); } =20 static unsigned long pci_ea_flags(struct pci_dev *dev, u8 prop) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 89F5A403DB0; Sat, 28 Feb 2026 17:43:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300631; cv=none; b=A401a3TwFHz8OIxbgrCA2JFX/adJP6YfsHHJ0y5OMbKHzlcLVVX8PpG11D7aJwbXLJEnfxAvXkWWCQaFxF2ad6CecdhxP56Ie3eJCpY+RmmP1l3U7C+XyZZnAByktvYMNr19Nbzwd3ded30O5JZwHLghnraUyIPa46fg7/4BLYI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300631; c=relaxed/simple; bh=aGufSnDeM09fNoVcAA8rqkEr8huu5NfEvQm0sdGaDhU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LdBX+ZNndR8KcCDlmIbt1CbTM6Y/VHbk7VNdLsNlAT8p+ujCkfi+kINvHEqFR5vYNzooL9buEALmnI7PDH6y7Yxc33bUSgHrvCk9jgN+85maY3kMtLlMGg1dGTl7wsiEyIQIVGKL1FOwM4Rhuj24e8dlhhRftq7S8z3kRPN/4Uc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S53LyoAY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S53LyoAY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD806C19423; Sat, 28 Feb 2026 17:43:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300631; bh=aGufSnDeM09fNoVcAA8rqkEr8huu5NfEvQm0sdGaDhU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S53LyoAYm60WnaT5EkDFZtmPBJgaT6Ow0d688FYz4rwSMmhZysFFelBBdAby50NL3 uVjzzL96em074AibcYqaWGswrJsObWCfj1ulDaIJUq3MqTNdXF9HV/pRjzI4BpHLxc 8zp+/jeokUl5x/gaVL5CqWGPLggD3u/9agKhampqrlKldK5lWHRMg9x+X6WYpNe2dy ezBv6dF+wyQEtZG2cqMlj2gGb2340UzArCssggCha2NxaeAmXU9WacaCtyPbBfttRt n22+LRQmgBYFlLDJCgA5xwd5EyJ5UwHx/Hl75ERmU1sEG5oSNoSrNhvgUC6wByu/vu UaISIZBsQ6dcw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Francesco Lavra , Stable@vger.kernel.org, Jonathan Cameron , Sasha Levin Subject: [PATCH 6.19 672/844] iio: accel: adxl380: Avoid reading more entries than present in FIFO Date: Sat, 28 Feb 2026 12:29:45 -0500 Message-ID: <20260228173244.1509663-673-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Francesco Lavra [ Upstream commit c1b14015224cfcccd5356333763f2f4f401bd810 ] The interrupt handler reads FIFO entries in batches of N samples, where N is the number of scan elements that have been enabled. However, the sensor fills the FIFO one sample at a time, even when more than one channel is enabled. Therefore,the number of entries reported by the FIFO status registers may not be a multiple of N; if this number is not a multiple, the number of entries read from the FIFO may exceed the number of entries actually present. To fix the above issue, round down the number of FIFO entries read from the status registers so that it is always a multiple of N. Fixes: df36de13677a ("iio: accel: add ADXL380 driver") Signed-off-by: Francesco Lavra Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iio/accel/adxl380.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c index aef5109c1ddd9..9f6c0e02575a6 100644 --- a/drivers/iio/accel/adxl380.c +++ b/drivers/iio/accel/adxl380.c @@ -949,6 +949,7 @@ static irqreturn_t adxl380_irq_handler(int irq, void *= p) if (ret) return IRQ_HANDLED; =20 + fifo_entries =3D rounddown(fifo_entries, st->fifo_set_size); for (i =3D 0; i < fifo_entries; i +=3D st->fifo_set_size) { ret =3D regmap_noinc_read(st->regmap, ADXL380_FIFO_DATA, &st->fifo_buf[i], --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9C3E403DD6; Sat, 28 Feb 2026 17:43:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300632; cv=none; b=qsi9lJfvWJ8Lu22yddEVIKk0Y196JfBsh/7C9so5y+W0MMvxMA0z7/lQaADcuykrAXEalCRb7HFN0D+uvuXxo7UX+SJQwhdTnjJTPrvNcCBh2NaSti5DB+Oy0hvhIF1drmAd0xaNMk1toWDQIvTF6dQX4zkG0pe3avjdbd+JAE4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300632; c=relaxed/simple; bh=0MEsXN5AH0lIkGP598z4YSPXisf20/DS+OzSmpQsEhc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qAS6ol4GL9nGeFQ79ZAYZ6Irx9mw70XBzRafB+IsKyZvTQmcR0WaUR7rRdH59abCjZpgPhfZtckuvBfMzgIQvjVm/NVdkqqCSMx58Gpl0uxgiSbCPjMgN2bqr0zmagDAHDGPt1EnLuz8thU58hr/gkcbRI5Sze8/58wcqMa2Fg0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iAksRyvw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iAksRyvw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AEA04C19423; Sat, 28 Feb 2026 17:43:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300632; bh=0MEsXN5AH0lIkGP598z4YSPXisf20/DS+OzSmpQsEhc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iAksRyvwMwKttINUd7CfTZXGcZLNoOm8IhJJRWtFfo3x9uQglDyGpcR/DUCR4+One DuEsx7MEel9CivDAdh7KHHwfW4ZW6RyZeJVbhHvXTmRjMUB505BOtO71ogPvbnItim Wrg0Kood+fB1hV14quYryoDSqqdtoFNPMpcaZIZZGh+ag8gAfy+tfJWycy6cM1KMlj 2REzXapawqd0nJBpKQzoutntboGWxhIIdI+m/6Fr9A0sisxk7d/NuaIIO5thb/2Md4 7/+cEKuyHKZNcqa84wey9P/lCpyR1PRpAy4Eu0g4H5MUl594nMgMpIHfiGB3wvrQBa FvTcPZRTP0VDw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Mikko Perttunen , Miaoqian Lin , Stephen Boyd , Sasha Levin Subject: [PATCH 6.19 673/844] clk: tegra: tegra124-emc: fix device leak on set_rate() Date: Sat, 28 Feb 2026 12:29:46 -0500 Message-ID: <20260228173244.1509663-674-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit da61439c63d34ae6503d080a847f144d587e3a48 ] Make sure to drop the reference taken when looking up the EMC device and its driver data on first set_rate(). Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: 2db04f16b589 ("clk: tegra: Add EMC clock driver") Fixes: 6d6ef58c2470 ("clk: tegra: tegra124-emc: Fix missing put_device() ca= ll in emc_ensure_emc_driver") Cc: stable@vger.kernel.org # 4.2: 6d6ef58c2470 Cc: Mikko Perttunen Cc: Miaoqian Lin Signed-off-by: Johan Hovold Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clk/tegra/clk-tegra124-emc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/tegra/clk-tegra124-emc.c b/drivers/clk/tegra/clk-t= egra124-emc.c index 0f6fb776b2298..5f1af6dfe7154 100644 --- a/drivers/clk/tegra/clk-tegra124-emc.c +++ b/drivers/clk/tegra/clk-tegra124-emc.c @@ -197,8 +197,8 @@ static struct tegra_emc *emc_ensure_emc_driver(struct t= egra_clk_emc *tegra) tegra->emc_node =3D NULL; =20 tegra->emc =3D platform_get_drvdata(pdev); + put_device(&pdev->dev); if (!tegra->emc) { - put_device(&pdev->dev); pr_err("%s: cannot find EMC driver\n", __func__); return NULL; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 010B14046EB; Sat, 28 Feb 2026 17:43:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300634; cv=none; b=FtFQUYD/w1TOegzKB3itgca3u76vdfGrFULE+N1sIUHqlLS+pbCVnIO/wezGW4LCozQDkrewyH5PDd9P0nKwoI8K8T+dsQuQV41SFWNLIr0p7e2nJ6jwFwdSMgFNE/e0QeoZlu1I7NU8psKRfqB9RxH2goxlAuylcUNvpKBIJ1Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300634; c=relaxed/simple; bh=xrUDajPkY4vdJvRuRoyNz2rXbWijUgSR+43IvsPfa40=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mI7AEsjYUqzRHykVwJ1IzPU93Nnd1hNXQTjU1r8GLDUkfcy8k2JTiwbzaWCqCJR6tmQOjZZr5L76m60sRrWFJwAIdJgEkmYyQSM8bRoRCURURo/ZqdgX/MigW57gVxjum5nU1yynidfHkq7IikSkU1twwCSnAttyMYQKwFVNhpA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iU9UWtKq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iU9UWtKq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAAA9C116D0; Sat, 28 Feb 2026 17:43:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300633; bh=xrUDajPkY4vdJvRuRoyNz2rXbWijUgSR+43IvsPfa40=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iU9UWtKqaUY+sX3h+pigWQKMbPhpPqy3YL+MTs7Yl/cTN1cD23ibf7rOzTIkmU/P3 wRKvVJJLX50ULNcIAI/CYgaxsSG5yz6Z3AixqtDtoEXnnvwmkagdkP9pgknCkkuVGH XC/hjg6NqcSillulYgVpCWJRWjmiT9hkrx7nCl4mhwPgpDapUt1v/XBTULzM7hKUew 3djFcfsVhEL4VSW2xtLdNgP9J8HJ10WN4s6bk4NCtTF74m17O4Eq3o4pbgWcGbi8Z5 zeJEuoZ7Hse7RN2557j+bKUOxa6FWzzwcGXqvWeFFOugzsVNEzXYW3G71WODb89h25 uYMxJQaZqfqNQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jason Gunthorpe , Shuai Xue , Mostafa Saleh , Pranjal Shrivastava , Nicolin Chen , Will Deacon , Sasha Levin Subject: [PATCH 6.19 674/844] iommu/arm-smmu-v3: Add update_safe bits to fix STE update sequence Date: Sat, 28 Feb 2026 12:29:47 -0500 Message-ID: <20260228173244.1509663-675-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jason Gunthorpe [ Upstream commit 2781f2a930abb5d27f80b8afbabfa19684833b65 ] C_BAD_STE was observed when updating nested STE from an S1-bypass mode to an S1DSS-bypass mode. As both modes enabled S2, the used bit is slightly different than the normal S1-bypass and S1DSS-bypass modes. As a result, fields like MEV and EATS in S2's used list marked the word1 as a critical word that requested a STE.V=3D0. This breaks a hitless update. However, both MEV and EATS aren't critical in terms of STE update. One controls the merge of the events and the other controls the ATS that is managed by the driver at the same time via pci_enable_ats(). Add an arm_smmu_get_ste_update_safe() to allow STE update algorithm to relax those fields, avoiding the STE update breakages. After this change, entry_set has no caller checking its return value, so change it to void. Note that this change is required by both MEV and EATS fields, which were introduced in different kernel versions. So add get_update_safe() first. MEV and EATS will be added to arm_smmu_get_ste_update_safe() separately. Fixes: 1e8be08d1c91 ("iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED") Cc: stable@vger.kernel.org Signed-off-by: Jason Gunthorpe Reviewed-by: Shuai Xue Reviewed-by: Mostafa Saleh Reviewed-by: Pranjal Shrivastava Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c | 31 +++++++++++++++++-- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 28 ++++++++++++----- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 4 +++ 3 files changed, 53 insertions(+), 10 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c b/drivers/iom= mu/arm/arm-smmu-v3/arm-smmu-v3-test.c index d2671bfd37981..b254a94b2003d 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c @@ -38,13 +38,16 @@ enum arm_smmu_test_master_feat { static bool arm_smmu_entry_differs_in_used_bits(const __le64 *entry, const __le64 *used_bits, const __le64 *target, + const __le64 *safe, unsigned int length) { bool differs =3D false; unsigned int i; =20 for (i =3D 0; i < length; i++) { - if ((entry[i] & used_bits[i]) !=3D target[i]) + __le64 used =3D used_bits[i] & ~safe[i]; + + if ((entry[i] & used) !=3D (target[i] & used)) differs =3D true; } return differs; @@ -56,12 +59,24 @@ arm_smmu_test_writer_record_syncs(struct arm_smmu_entry= _writer *writer) struct arm_smmu_test_writer *test_writer =3D container_of(writer, struct arm_smmu_test_writer, writer); __le64 *entry_used_bits; + __le64 *safe_target; + __le64 *safe_init; =20 entry_used_bits =3D kunit_kzalloc( test_writer->test, sizeof(*entry_used_bits) * NUM_ENTRY_QWORDS, GFP_KERNEL); KUNIT_ASSERT_NOT_NULL(test_writer->test, entry_used_bits); =20 + safe_target =3D kunit_kzalloc(test_writer->test, + sizeof(*safe_target) * NUM_ENTRY_QWORDS, + GFP_KERNEL); + KUNIT_ASSERT_NOT_NULL(test_writer->test, safe_target); + + safe_init =3D kunit_kzalloc(test_writer->test, + sizeof(*safe_init) * NUM_ENTRY_QWORDS, + GFP_KERNEL); + KUNIT_ASSERT_NOT_NULL(test_writer->test, safe_init); + pr_debug("STE value is now set to: "); print_hex_dump_debug(" ", DUMP_PREFIX_NONE, 16, 8, test_writer->entry, @@ -79,14 +94,23 @@ arm_smmu_test_writer_record_syncs(struct arm_smmu_entry= _writer *writer) * configuration. */ writer->ops->get_used(test_writer->entry, entry_used_bits); + if (writer->ops->get_update_safe) + writer->ops->get_update_safe(test_writer->entry, + test_writer->init_entry, + safe_init); + if (writer->ops->get_update_safe) + writer->ops->get_update_safe(test_writer->entry, + test_writer->target_entry, + safe_target); KUNIT_EXPECT_FALSE( test_writer->test, arm_smmu_entry_differs_in_used_bits( test_writer->entry, entry_used_bits, - test_writer->init_entry, NUM_ENTRY_QWORDS) && + test_writer->init_entry, safe_init, + NUM_ENTRY_QWORDS) && arm_smmu_entry_differs_in_used_bits( test_writer->entry, entry_used_bits, - test_writer->target_entry, + test_writer->target_entry, safe_target, NUM_ENTRY_QWORDS)); } } @@ -106,6 +130,7 @@ arm_smmu_v3_test_debug_print_used_bits(struct arm_smmu_= entry_writer *writer, static const struct arm_smmu_entry_writer_ops test_ste_ops =3D { .sync =3D arm_smmu_test_writer_record_syncs, .get_used =3D arm_smmu_get_ste_used, + .get_update_safe =3D arm_smmu_get_ste_update_safe, }; =20 static const struct arm_smmu_entry_writer_ops test_cd_ops =3D { diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/ar= m/arm-smmu-v3/arm-smmu-v3.c index 7a6aea3b61c11..56420104e154e 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -1093,6 +1093,13 @@ void arm_smmu_get_ste_used(const __le64 *ent, __le64= *used_bits) } EXPORT_SYMBOL_IF_KUNIT(arm_smmu_get_ste_used); =20 +VISIBLE_IF_KUNIT +void arm_smmu_get_ste_update_safe(const __le64 *cur, const __le64 *target, + __le64 *safe_bits) +{ +} +EXPORT_SYMBOL_IF_KUNIT(arm_smmu_get_ste_update_safe); + /* * Figure out if we can do a hitless update of entry to become target. Ret= urns a * bit mask where 1 indicates that qword needs to be set disruptively. @@ -1105,13 +1112,22 @@ static u8 arm_smmu_entry_qword_diff(struct arm_smmu= _entry_writer *writer, { __le64 target_used[NUM_ENTRY_QWORDS] =3D {}; __le64 cur_used[NUM_ENTRY_QWORDS] =3D {}; + __le64 safe[NUM_ENTRY_QWORDS] =3D {}; u8 used_qword_diff =3D 0; unsigned int i; =20 writer->ops->get_used(entry, cur_used); writer->ops->get_used(target, target_used); + if (writer->ops->get_update_safe) + writer->ops->get_update_safe(entry, target, safe); =20 for (i =3D 0; i !=3D NUM_ENTRY_QWORDS; i++) { + /* + * Safe is only used for bits that are used by both entries, + * otherwise it is sequenced according to the unused entry. + */ + safe[i] &=3D target_used[i] & cur_used[i]; + /* * Check that masks are up to date, the make functions are not * allowed to set a bit to 1 if the used function doesn't say it @@ -1120,6 +1136,7 @@ static u8 arm_smmu_entry_qword_diff(struct arm_smmu_e= ntry_writer *writer, WARN_ON_ONCE(target[i] & ~target_used[i]); =20 /* Bits can change because they are not currently being used */ + cur_used[i] &=3D ~safe[i]; unused_update[i] =3D (entry[i] & cur_used[i]) | (target[i] & ~cur_used[i]); /* @@ -1132,7 +1149,7 @@ static u8 arm_smmu_entry_qword_diff(struct arm_smmu_e= ntry_writer *writer, return used_qword_diff; } =20 -static bool entry_set(struct arm_smmu_entry_writer *writer, __le64 *entry, +static void entry_set(struct arm_smmu_entry_writer *writer, __le64 *entry, const __le64 *target, unsigned int start, unsigned int len) { @@ -1148,7 +1165,6 @@ static bool entry_set(struct arm_smmu_entry_writer *w= riter, __le64 *entry, =20 if (changed) writer->ops->sync(writer); - return changed; } =20 /* @@ -1218,12 +1234,9 @@ void arm_smmu_write_entry(struct arm_smmu_entry_writ= er *writer, __le64 *entry, entry_set(writer, entry, target, 0, 1); } else { /* - * No inuse bit changed. Sanity check that all unused bits are 0 - * in the entry. The target was already sanity checked by - * compute_qword_diff(). + * No inuse bit changed, though safe bits may have changed. */ - WARN_ON_ONCE( - entry_set(writer, entry, target, 0, NUM_ENTRY_QWORDS)); + entry_set(writer, entry, target, 0, NUM_ENTRY_QWORDS); } } EXPORT_SYMBOL_IF_KUNIT(arm_smmu_write_entry); @@ -1554,6 +1567,7 @@ static void arm_smmu_ste_writer_sync_entry(struct arm= _smmu_entry_writer *writer) static const struct arm_smmu_entry_writer_ops arm_smmu_ste_writer_ops =3D { .sync =3D arm_smmu_ste_writer_sync_entry, .get_used =3D arm_smmu_get_ste_used, + .get_update_safe =3D arm_smmu_get_ste_update_safe, }; =20 static void arm_smmu_write_ste(struct arm_smmu_master *master, u32 sid, diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/ar= m/arm-smmu-v3/arm-smmu-v3.h index ae23aacc38402..287e223c054d1 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -900,6 +900,8 @@ struct arm_smmu_entry_writer { =20 struct arm_smmu_entry_writer_ops { void (*get_used)(const __le64 *entry, __le64 *used); + void (*get_update_safe)(const __le64 *cur, const __le64 *target, + __le64 *safe_bits); void (*sync)(struct arm_smmu_entry_writer *writer); }; =20 @@ -911,6 +913,8 @@ void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *t= arget, =20 #if IS_ENABLED(CONFIG_KUNIT) void arm_smmu_get_ste_used(const __le64 *ent, __le64 *used_bits); +void arm_smmu_get_ste_update_safe(const __le64 *cur, const __le64 *target, + __le64 *safe_bits); void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer, __le64 *cu= r, const __le64 *target); void arm_smmu_get_cd_used(const __le64 *ent, __le64 *used_bits); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07220404701; Sat, 28 Feb 2026 17:43:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300635; cv=none; b=gQHXCNUe5BLhjelsKFMzgMQL5cU0UFg7NX1VrVT4juyQgC2+pt8fIys73Povmp0nfNSMOT/rXxNrx3v5/vnKriyMHdT58kZgvNEUiHpgYd0rTXkFXoCnawQrIbVmtZ85lG+KwXlSrvlcjk2DNLL1wjZutEnieUnVBeM11CvTYZw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300635; c=relaxed/simple; bh=i0hec5elO3Uy2H1s2O7ojzDBcoo/YFdHOGcSU5X+kjo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YB6bgHmgagASVuSHT0rAr/ZiUFJ2pUbKo1ukdPaVgT4jUMd5cScIar21PxiGjjGOCFkRLzg1ikaEk1Ty48IHN+LmW2peZGCw3gkrj5YZwismEMABPOUt/vnCceOyiv5rEaBTulNQ/5Qkl8E2ik3LkmLnnn2Pd41z7kSKrxw0UWI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=toFpVqd7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="toFpVqd7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9921C2BC87; Sat, 28 Feb 2026 17:43:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300634; bh=i0hec5elO3Uy2H1s2O7ojzDBcoo/YFdHOGcSU5X+kjo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=toFpVqd7B+T3Li5JVAQRsk4gYhWIUrWw+/giuxEscmBhQ9Pf0otrVhV8HORLyBczR /I3QS4lRAKtVJOEWxV9cP2Gm3fB3x6suQuBkOoOcsS6iYsjwLc8Shd30U90OPuNom5 aUPH4NFQm9QrQTlrwsOYLKJ2E/YpeJ5HVEmCBrjI7Htt7TcPpVuU1esBRJze+WIIGX 7BCKADoqrxCdx+GT9vuVwnL2GIMHN3X3/i4JNAV3UngERMbbUyf/MvDIFg32gdZWFD AdgDQVHDT/HLq5pcsXLTT4PvE+dtVP0M+Jd0Fgvc10vPL0ZlNWpA0kaLMHuFwijzQ5 S0hCipnuQmuaQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jason Gunthorpe , Shuai Xue , Mostafa Saleh , Pranjal Shrivastava , Nicolin Chen , Will Deacon , Sasha Levin Subject: [PATCH 6.19 675/844] iommu/arm-smmu-v3: Mark STE MEV safe when computing the update sequence Date: Sat, 28 Feb 2026 12:29:48 -0500 Message-ID: <20260228173244.1509663-676-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jason Gunthorpe [ Upstream commit f3c1d372dbb8e5a86923f20db66deabef42bfc9d ] Nested CD tables set the MEV bit to try to reduce multi-fault spamming on the hypervisor. Since MEV is in STE word 1 this causes a breaking update sequence that is not required and impacts real workloads. For the purposes of STE updates the value of MEV doesn't matter, if it is set/cleared early or late it just results in a change to the fault reports that must be supported by the kernel anyhow. The spec says: Note: Software must expect, and be able to deal with, coalesced fault records even when MEV =3D=3D 0. So mark STE MEV safe when computing the update sequence, to avoid creating a breaking update. Fixes: da0c56520e88 ("iommu/arm-smmu-v3: Set MEV bit in nested STE for DoS = mitigations") Cc: stable@vger.kernel.org Signed-off-by: Jason Gunthorpe Reviewed-by: Shuai Xue Reviewed-by: Mostafa Saleh Reviewed-by: Pranjal Shrivastava Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/ar= m/arm-smmu-v3/arm-smmu-v3.c index 56420104e154e..65c0119f45eae 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -1097,6 +1097,16 @@ VISIBLE_IF_KUNIT void arm_smmu_get_ste_update_safe(const __le64 *cur, const __le64 *target, __le64 *safe_bits) { + /* + * MEV does not meaningfully impact the operation of the HW, it only + * changes how many fault events are generated, thus we can relax it + * when computing the ordering. The spec notes the device can act like + * MEV=3D1 anyhow: + * + * Note: Software must expect, and be able to deal with, coalesced + * fault records even when MEV =3D=3D 0. + */ + safe_bits[1] |=3D cpu_to_le64(STRTAB_STE_1_MEV); } EXPORT_SYMBOL_IF_KUNIT(arm_smmu_get_ste_update_safe); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C4AF404718; Sat, 28 Feb 2026 17:43:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300636; cv=none; b=GMBI8f6au4gZ4EkNgW6+EmPpWb7diLux1NDKe6PR41J7gH7rNgdOC91b2PtYUJRNxMc1RfTzDDQLIFP3D3Kyd/49NkezueXP2Aab4WFa1iqxF6tVFJ4TEBecOAs9jjn85VoocP0HLYukLVJbqTNsPvbrWOWv+xieJPW1uPGtOn4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300636; c=relaxed/simple; bh=m656M2eFCFwUxJZh0qPMW5TWZ7MJ1/UrBFM30tb22pA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qNQ84qnj6cHTqiP5h9FzJL5kVS1va247S6b69lMYpifO68dkgeJzlCwT9l5OWHwYlHjS01XseyMLJrW1KzbwBaqKoQ/tWB3UbxeJ7v1d3kf96bE25xyj+6BKPvR1EPHjl0obVWYkTTCR2fIIVb9hLcvV5URI1mWxm0zxlbVgxyE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TMX5PLGH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TMX5PLGH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24B45C19423; Sat, 28 Feb 2026 17:43:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300635; bh=m656M2eFCFwUxJZh0qPMW5TWZ7MJ1/UrBFM30tb22pA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TMX5PLGHEl4pBi25LvK+H/9EstifGya51r0fC9ekmRFFwAxKcbJUImsJEM1OB8xek s89mDqtFQGP2jP+15e8P0BWo2cd7CM/Ls/ebaG9El4Fwf1fz2aK8I3t1krptlqQO7P lHVxKjgCUOw+KbC2aQcdn7XQ5RcGI/mnK85kLUO/gmEkE69KhHUf0Dfeq+nH5lIqyS P0ff+LA+D0aUxJDrqGb5yASyYOljoUwhAbRqLsnYNdFXUX6KVVKqpFKivCeGTAORN4 51BHuUzsD/Hbvv57O1yw3bOdxvaeTttQLiA9Goqd/5NeriklXRYN6rhbe7+irEJncf E3FuD4wet2+Pw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jason Gunthorpe , Shuai Xue , Nicolin Chen , Will Deacon , Sasha Levin Subject: [PATCH 6.19 676/844] iommu/arm-smmu-v3: Mark EATS_TRANS safe when computing the update sequence Date: Sat, 28 Feb 2026 12:29:49 -0500 Message-ID: <20260228173244.1509663-677-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jason Gunthorpe [ Upstream commit 7cad800485956a263318930613f8f4a084af8c70 ] If VM wants to toggle EATS_TRANS off at the same time as changing the CFG, hypervisor will see EATS change to 0 and insert a V=3D0 breaking update into the STE even though the VM did not ask for that. In bare metal, EATS_TRANS is ignored by CFG=3DABORT/BYPASS, which is why th= is does not cause a problem until we have the nested case where CFG is always a variation of S2 trans that does use EATS_TRANS. Relax the rules for EATS_TRANS sequencing, we don't need it to be exact as the enclosing code will always disable ATS at the PCI device when changing EATS_TRANS. This ensures there are no ATS transactions that can race with an EATS_TRANS change so we don't need to carefully sequence these bits. Fixes: 1e8be08d1c91 ("iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED") Cc: stable@vger.kernel.org Signed-off-by: Jason Gunthorpe Reviewed-by: Shuai Xue Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 26 +++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/ar= m/arm-smmu-v3/arm-smmu-v3.c index 65c0119f45eae..d55b8e39b8e3c 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -1097,6 +1097,32 @@ VISIBLE_IF_KUNIT void arm_smmu_get_ste_update_safe(const __le64 *cur, const __le64 *target, __le64 *safe_bits) { + const __le64 eats_s1chk =3D + FIELD_PREP(STRTAB_STE_1_EATS, STRTAB_STE_1_EATS_S1CHK); + const __le64 eats_trans =3D + FIELD_PREP(STRTAB_STE_1_EATS, STRTAB_STE_1_EATS_TRANS); + + /* + * When an STE changes EATS_TRANS, the sequencing code in the attach + * logic already will have the PCI cap for ATS disabled. Thus at this + * moment we can expect that the device will not generate ATS queries + * and so we don't care about the sequencing of EATS. The purpose of + * EATS_TRANS is to protect the system from hostile untrusted devices + * that issue ATS when the PCI config space is disabled. However, if + * EATS_TRANS is being changed, then we must have already trusted the + * device as the EATS_TRANS security block is being disabled. + * + * Note: now the EATS_TRANS update is moved to the first entry_set(). + * Changing S2S and EATS might transiently result in S2S=3D1 and EATS=3D1 + * which is a bad STE (see "5.2 Stream Table Entry"). In such a case, + * we can't do a hitless update. Also, it should not be added to the + * safe bits with STRTAB_STE_1_EATS_S1CHK, because EATS=3D0b11 would be + * effectively an errant 0b00 configuration. + */ + if (!((cur[1] | target[1]) & cpu_to_le64(eats_s1chk)) && + !((cur[2] | target[2]) & cpu_to_le64(STRTAB_STE_2_S2S))) + safe_bits[1] |=3D cpu_to_le64(eats_trans); + /* * MEV does not meaningfully impact the operation of the HW, it only * changes how many fault events are generated, thus we can relax it --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0BB79405085; Sat, 28 Feb 2026 17:43:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300637; cv=none; b=HwEbV0GTWK9ebL6jcx1uyIUQRod3eBtsY2uYBJIxopYPdmg9U3sx39rPPsaE21cvlCrAWY6mbA2zEiSXesUJjwdi+O50ps9ruuJhA5GgiVt1giFUMU079/M4giyZcjI09iUP3z1W4kbVlQj3kQCwUDB27x0SG9qEZptA7KzRfLA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300637; c=relaxed/simple; bh=oQC+znb4ZNigAItQE36WMOtjblJ8pgVxq3Mmq24po3Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cSVUi6naWMXoSDYGh8D2G422x3kv4vM3eZfhYIPujTsRnvgg/9dIEwvGUlrktuKa+UYKuq9u6IggkC4vKcm4wHg4lhWAzagxFzKw+Z4/3M9VYVOQQ4SpYsX5K99awjuAF7uX5zwnGeUMRc89h4SLNzqrRdJLmJWvAGbcKZyEWtw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ooi325s9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ooi325s9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C3DBC116D0; Sat, 28 Feb 2026 17:43:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300636; bh=oQC+znb4ZNigAItQE36WMOtjblJ8pgVxq3Mmq24po3Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ooi325s9oPtq+w452kkhJoImf2DJoIZ6xNhAlmKieaTBF8vBW28oql14MMHxF90RX +zMBDAVwC+nxmj+Xp8cSsp+oRcyFYF1qJQMjjblg3zQpaW8u0wDDuzC+0qwLWSyMSK iVHiJXJ/6e94X0lTzDFjjlQV3Cv1x3or+Ll/jMzSG6KGjM+02s7Ajfp9IHrQ0sxtUt wGFnUxyFRV2AirhK8w8FsRHokGF8LjGS80Yw7/5UVsM53rwdgvxq5uXc8eqlumjb30 FSOtRhoPiqZn7LCjUTuLtao2Bso5JDkJCg3slwuM4fhE/0oMVWLQ0XDxkrSDnUwXQ3 orwHj6rJcUw+w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nicolin Chen , Jason Gunthorpe , Pranjal Shrivastava , Will Deacon , Sasha Levin Subject: [PATCH 6.19 677/844] iommu/arm-smmu-v3: Do not set disable_ats unless vSTE is Translate Date: Sat, 28 Feb 2026 12:29:50 -0500 Message-ID: <20260228173244.1509663-678-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicolin Chen [ Upstream commit a45dd34663025c75652b27e384e91c9c05ba1d80 ] A vSTE may have three configuration types: Abort, Bypass, and Translate. An Abort vSTE wouldn't enable ATS, but the other two might. It makes sense for a Transalte vSTE to rely on the guest vSTE.EATS field. For a Bypass vSTE, it would end up with an S2-only physical STE, similar to an attachment to a regular S2 domain. However, the nested case always disables ATS following the Bypass vSTE, while the regular S2 case always enables ATS so long as arm_smmu_ats_supported(master) =3D=3D true. Note that ATS is needed for certain VM centric workloads and historically non-vSMMU cases have relied on this automatic enablement. So, having the nested case behave differently causes problems. To fix that, add a condition to disable_ats, so that it might enable ATS for a Bypass vSTE, aligning with the regular S2 case. Fixes: f27298a82ba0 ("iommu/arm-smmu-v3: Allow ATS for IOMMU_DOMAIN_NESTED") Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe Signed-off-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c b/drivers/= iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c index 93fdadd07431a..823461a26659f 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c @@ -177,7 +177,9 @@ static int arm_smmu_attach_dev_nested(struct iommu_doma= in *domain, * config bit here base this off the EATS value in the STE. If the EATS * is set then the VM must generate ATC flushes. */ - state.disable_ats =3D !nested_domain->enable_ats; + if (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(nested_domain->ste[0])) =3D= =3D + STRTAB_STE_0_CFG_S1_TRANS) + state.disable_ats =3D !nested_domain->enable_ats; ret =3D arm_smmu_attach_prepare(&state, domain); if (ret) { mutex_unlock(&arm_smmu_asid_lock); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF4184050A6; Sat, 28 Feb 2026 17:43:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300638; cv=none; b=WU1/tOyCnjbr//h/kUe2sihmhiM3Yz7HWuskQ+z3F+n03CfOehyYy9fmTlWBfL/+Ixn1Vl+8w+sgJ0LEKyAU9KFWCouyrnw6Q+5tM3sLj/U3kzzcLHJLFO0Q6z6lMRRmWrUqjy0PVw92RVjI9kVQKAEAea0Wt+Eu3fvG3pyH5sk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300638; c=relaxed/simple; bh=HeF6ox1C67sqO9OwG7DXMP51pHye57oW7ISY2fNb60I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hj5rwM1mZM5BQb6tLHVBFi1n9uW4hwrjlmtXPIbNTPpx570deeAZ3YgQZ0KTD2cr0vhyODdDD2JNZxGgvpxc67bwqq6Et2/oO6T/dI6/Nr+1m5v5KEm3iSt0zirnjWhDKXTpPI3tOinWHfFZ1/31MyDYnqyzXlPH9jHnYjlvAdg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M87pk2b9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M87pk2b9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 327ABC19423; Sat, 28 Feb 2026 17:43:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300637; bh=HeF6ox1C67sqO9OwG7DXMP51pHye57oW7ISY2fNb60I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M87pk2b9SobKaPYWIGliH1f5xTqhr8meeQ0L/hvqevZ1JsBvcW0/tMrKhU6dC5e3/ jYLjLKYqwST8ftjc3hx+bq7C7T57pDoPrT9KNVXbYWf+T/QyUOuVF3P4ZSpBFd3xHe dl4d4deOvUX5GTodZ8y6p+Y7bhAetyjaS/0cRHAI1BK4Gmd9PV6doE5OMRa3USY6go YQE5+nrbYwarZAMHXcVIxs7MhOTtNdsN06wlEj1zE8mAXXRIULZiL+YGJKNz/6tMnT RlFNPcNQ/N+kZeir41aHH0KIJVBLfMIK0sbHT1CMWFVVdKoMwXnw5LTwhYvfp0GUgI 9BC4ZySZPE3WA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Wayne Chang , Wei-Cheng Chen , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 678/844] usb: host: tegra: Remove manual wake IRQ disposal Date: Sat, 28 Feb 2026 12:29:51 -0500 Message-ID: <20260228173244.1509663-679-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wayne Chang [ Upstream commit ef548189fd3f44786fb813af0018cc8b3bbed2b9 ] We found that calling irq_dispose_mapping() caused a kernel warning when removing the driver. The IRQs are obtained using platform_get_irq(), which returns a Linux virtual IRQ number directly managed by the device core, not by the OF subsystem. Therefore, the driver should not call irq_dispose_mapping() for these IRQs. Fixes: 5df186e2ef11 ("usb: xhci: tegra: Support USB wakeup function for Teg= ra234") Cc: stable@vger.kernel.org Signed-off-by: Wayne Chang Signed-off-by: Wei-Cheng Chen Link: https://patch.msgid.link/20260115103621.587366-1-weichengc@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/usb/host/xhci-tegra.c | 21 ++------------------- 1 file changed, 2 insertions(+), 19 deletions(-) diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c index 8b492871d21d6..3f6aa2440b05b 100644 --- a/drivers/usb/host/xhci-tegra.c +++ b/drivers/usb/host/xhci-tegra.c @@ -1570,7 +1570,6 @@ static int tegra_xusb_setup_wakeup(struct platform_de= vice *pdev, struct tegra_xu data =3D irq_get_irq_data(tegra->wake_irqs[i]); if (!data) { dev_warn(tegra->dev, "get wake event %d irq data fail\n", i); - irq_dispose_mapping(tegra->wake_irqs[i]); break; } =20 @@ -1583,16 +1582,6 @@ static int tegra_xusb_setup_wakeup(struct platform_d= evice *pdev, struct tegra_xu return 0; } =20 -static void tegra_xusb_dispose_wake(struct tegra_xusb *tegra) -{ - unsigned int i; - - for (i =3D 0; i < tegra->num_wakes; i++) - irq_dispose_mapping(tegra->wake_irqs[i]); - - tegra->num_wakes =3D 0; -} - static int tegra_xusb_probe(struct platform_device *pdev) { struct tegra_xusb *tegra; @@ -1648,10 +1637,8 @@ static int tegra_xusb_probe(struct platform_device *= pdev) return err; =20 tegra->padctl =3D tegra_xusb_padctl_get(&pdev->dev); - if (IS_ERR(tegra->padctl)) { - err =3D PTR_ERR(tegra->padctl); - goto dispose_wake; - } + if (IS_ERR(tegra->padctl)) + return PTR_ERR(tegra->padctl); =20 np =3D of_parse_phandle(pdev->dev.of_node, "nvidia,xusb-padctl", 0); if (!np) { @@ -1975,8 +1962,6 @@ static int tegra_xusb_probe(struct platform_device *p= dev) put_padctl: of_node_put(np); tegra_xusb_padctl_put(tegra->padctl); -dispose_wake: - tegra_xusb_dispose_wake(tegra); return err; } =20 @@ -2009,8 +1994,6 @@ static void tegra_xusb_remove(struct platform_device = *pdev) if (tegra->padctl_irq) pm_runtime_disable(&pdev->dev); =20 - tegra_xusb_dispose_wake(tegra); - pm_runtime_put(&pdev->dev); =20 tegra_xusb_disable(tegra); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0DA53404713; Sat, 28 Feb 2026 17:43:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300639; cv=none; b=kIfQ6Yj//s9LZ6PZPplD0yuDYySZlX42wuTu+zNAXCHZo2Yd8uoVUKg8b5gy/61b8qjOTJ1eIoX3EOJJj+XD5aUOey2DgL0szl0liD7mUHkCyRirVNDYOa5GCVHnSPlqsKyCflM5Z3yDlsEx4VRkttK2H1s9XIjYPX3rUSsFnzI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300639; c=relaxed/simple; bh=YHuZmIjUa2BPlEXI0I2i4kyZQxQRN6TdlgoXeGuLW00=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mSqwmQCAlmzURUw+o8bJ0IEcIJjwYDofdHIPOcwhCS1x2mBOWl5cxvi82M+iU8dU34Pjhx7GMp63ONRtu4FgXbK7KPCo9tywQWuboecL0gNt3PmRFtIxU+xP0aYL7u5hL3XH3B3ni9z86n+wP2Z5DtRilbX4wCFKEPAXCQ79Zm4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kUjZVDot; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kUjZVDot" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22FC7C19425; Sat, 28 Feb 2026 17:43:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300638; bh=YHuZmIjUa2BPlEXI0I2i4kyZQxQRN6TdlgoXeGuLW00=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kUjZVDotMnJh0fiXPHH4p+0G7aU6cj5uNBwBdNEWtWohdtg0fu72rDPrXsZERDUZy M+Y+yQvDldhbKZ4tqNavjf3rXsa0fSK2kW7n9yKTzRRnO02DeDd+aVTeC8AhwgGzli FyCo6YhFfnlOhpmlait3lc6za0r23qzly+8QqwUM2Oe7C5BRXy6hApHPFE900rMESh /kPtoYvLMMfA6KG8wRpNBA1XZmQhMxeErEYa/JKT4fZfAxbrjkKz8MIdjBEBGVApDt vIPHk7AHixsLiuC1ct+mG7Ro4vCWBca1io68VYp/L+LUsMfmH5uxpo/EdkXpGGNvk9 vZg3nKdUKrYHg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , Christoph Hellwig , Sasha Levin Subject: [PATCH 6.19 679/844] xfs: delete attr leaf freemap entries when empty Date: Sat, 28 Feb 2026 12:29:52 -0500 Message-ID: <20260228173244.1509663-680-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" [ Upstream commit 6f13c1d2a6271c2e73226864a0e83de2770b6f34 ] Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time. Cc: # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/libxfs/xfs_attr_leaf.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index 91c1b30ebaab3..33c6c468ad8d5 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -1580,6 +1580,19 @@ xfs_attr3_leaf_add_work( min_t(uint16_t, ichdr->freemap[i].size, sizeof(xfs_attr_leaf_entry_t)); } + + /* + * Don't leave zero-length freemaps with nonzero base lying + * around, because we don't want the code in _remove that + * matches on base address to get confused and create + * overlapping freemaps. If we end up with no freemap entries + * then the next _add will compact the leaf block and + * regenerate the freemaps. + */ + if (ichdr->freemap[i].size =3D=3D 0 && ichdr->freemap[i].base > 0) { + ichdr->freemap[i].base =3D 0; + ichdr->holes =3D 1; + } } ichdr->usedbytes +=3D xfs_attr_leaf_entsize(leaf, args->index); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABB9B40598D; Sat, 28 Feb 2026 17:43:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300639; cv=none; b=oyf1BhlZJFPKjwynAu9BIYOylvuHpFf9ksVMHh90YY0kNI+B+Ra62DeH9oOr7C1YAJVK9W+YFom7d45fU8jVvfzvmOKp84jJSlI/cJzY0q38MRXDxlpanm43vTZCtNs01/Wj9Y0TjVjkDMtceNtefw6FTgdjIHw+X+gRxvQEBMw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300639; c=relaxed/simple; bh=1SCvZYGLN1+S53XWG957Hu6A7osok9Yn5DZDvXwHEXc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hN5xZwysGT1W5mGuVIUlRCVP6uRMQ+6kS74LecUm3LlhlFNXfL0R02HOgGArV/zpDdrEAoCPtEvn/UhPars4uYn0Iec2/HoLPqOCLfKc0VqFxHqIC4chhMnmOi5QDMRvvWQWsZo21uhTz3m1GTFYLgm1BqyqLxUkZYdK5h6PNhQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XEARsXub; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XEARsXub" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1908C116D0; Sat, 28 Feb 2026 17:43:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300639; bh=1SCvZYGLN1+S53XWG957Hu6A7osok9Yn5DZDvXwHEXc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XEARsXubCN8y+O5meWRNc2R6OwbSWgSAp4QSyJz9/QMnTYkqKLRyIwrWN/YVGW38m zAgXTsXpADnVSqgQPM4fswRKGaosTqLkseFdxVyvJDLWQPgmDE4gPwvJRcbR0vsqaV Cgjrs56/459pzNTxIsEN/DM/zAVGLmFJydccjUcLFiSSRmgUrM4oKZ5qO+1750aW4p o3XVo+xVm++6DcA5GGNMyTfXsAwBVz0pOBl8Ynm2KMONO6wuK4xYwaOh8/jXJdwEPh mGHI2U/VrOQ95bwgcqk3q4LkXqr+xxBgwPPI5FjtMohWNmTHsuXXtAnOMp5OiV5a5E 3oLmkN+IjmO4w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , Christoph Hellwig , Sasha Levin Subject: [PATCH 6.19 680/844] xfs: fix freemap adjustments when adding xattrs to leaf blocks Date: Sat, 28 Feb 2026 12:29:53 -0500 Message-ID: <20260228173244.1509663-681-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" [ Upstream commit 3eefc0c2b78444b64feeb3783c017d6adc3cd3ce ] xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >=3D ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3D3 and valuelen=3D71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused =3D 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused =3D 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base =3D 376, size =3D 8] * freemap[1] has [base =3D 388, size =3D 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base =3D 384, size =3D 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base =3D 392, size =3D 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base =3D 0. Cc: # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/libxfs/xfs_attr_leaf.c | 36 +++++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index 33c6c468ad8d5..b858e3c2ad50a 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -1476,6 +1476,7 @@ xfs_attr3_leaf_add_work( struct xfs_attr_leaf_name_local *name_loc; struct xfs_attr_leaf_name_remote *name_rmt; struct xfs_mount *mp; + int old_end, new_end; int tmp; int i; =20 @@ -1568,17 +1569,36 @@ xfs_attr3_leaf_add_work( if (be16_to_cpu(entry->nameidx) < ichdr->firstused) ichdr->firstused =3D be16_to_cpu(entry->nameidx); =20 - ASSERT(ichdr->firstused >=3D ichdr->count * sizeof(xfs_attr_leaf_entry_t) - + xfs_attr3_leaf_hdr_size(leaf)); - tmp =3D (ichdr->count - 1) * sizeof(xfs_attr_leaf_entry_t) - + xfs_attr3_leaf_hdr_size(leaf); + new_end =3D ichdr->count * sizeof(struct xfs_attr_leaf_entry) + + xfs_attr3_leaf_hdr_size(leaf); + old_end =3D new_end - sizeof(struct xfs_attr_leaf_entry); + + ASSERT(ichdr->firstused >=3D new_end); =20 for (i =3D 0; i < XFS_ATTR_LEAF_MAPSIZE; i++) { - if (ichdr->freemap[i].base =3D=3D tmp) { - ichdr->freemap[i].base +=3D sizeof(xfs_attr_leaf_entry_t); + int diff =3D 0; + + if (ichdr->freemap[i].base =3D=3D old_end) { + /* + * This freemap entry starts at the old end of the + * leaf entry array, so we need to adjust its base + * upward to accomodate the larger array. + */ + diff =3D sizeof(struct xfs_attr_leaf_entry); + } else if (ichdr->freemap[i].size > 0 && + ichdr->freemap[i].base < new_end) { + /* + * This freemap entry starts in the space claimed by + * the new leaf entry. Adjust its base upward to + * reflect that. + */ + diff =3D new_end - ichdr->freemap[i].base; + } + + if (diff) { + ichdr->freemap[i].base +=3D diff; ichdr->freemap[i].size -=3D - min_t(uint16_t, ichdr->freemap[i].size, - sizeof(xfs_attr_leaf_entry_t)); + min_t(uint16_t, ichdr->freemap[i].size, diff); } =20 /* --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4B924059AF; Sat, 28 Feb 2026 17:44:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300640; cv=none; b=JQ4oiHIHdFJDOTGmJc24Um9J8WL+/ypSnZxe+qUEZhMCB7zb+iijMsz8ebMrOGfHVBrrmeUWXpsk3DSEtG/gJ23HdYR12WwnkWdcFJxWQ2V5Iemn0Pj1Z9wM/ig6xdGIvYoY7aQbblTW9cedDbcrrSa8idKvHOmVqhB+j19Am3s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300640; c=relaxed/simple; bh=GgcFNP1QtzleZLiLxh/PC3kbpgrW2huzx1/XQE76kMQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ovGjiqRAnZzbJ1JGbk9rjOe2V1V2mq9ni8R8dq4s+mIxrkZngTj65hpZQ14GcQlIl2MgEyKj2/FFkX07w09ir9h3ehC8iiaq+zMsog+MBPl5lu2CTuxzjiXrXZ0C1inbmC9GLADZ61c+aM4pa5x7fc5EaQRPhpTW7YmV8UZh2js= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hW1FC3dU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hW1FC3dU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9DA2C19423; Sat, 28 Feb 2026 17:43:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300640; bh=GgcFNP1QtzleZLiLxh/PC3kbpgrW2huzx1/XQE76kMQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hW1FC3dU8ZZFaPB4LQQEeF5Acwjr5BUONKL3IFoEFL/s63XFw2LiGg80J7T2J9AzE Ul/c/UGxXIWsIe9FMIgzrwrXrxRY/4918FtIrRddJ9fN/9q6YDLEuogoHuLWiFh7ut Aj/mRPtmRxIh3m8nCEpwRi1+Y9O3Rl/QV2xzIbKiI2T71EFrSQGJiS06gzsgnOM21E 9Nk24jVMwD0ngB2hH9BTPxnzAJFsaXWXe0PuLAs5SKKagdCJQdrm9ZIahXeMO1NVqC rA9y83cM5ecXN57JmtTcM+o2aRwmsMhYN+WocOA5GHI7WvDRIyVJcLUXaFKn2BKtWy kKXxpZAqHP9Jg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , Christoph Hellwig , Sasha Levin Subject: [PATCH 6.19 681/844] xfs: fix the xattr scrub to detect freemap/entries array collisions Date: Sat, 28 Feb 2026 12:29:54 -0500 Message-ID: <20260228173244.1509663-682-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" [ Upstream commit 6fed8270448c246e706921c177e9633013dd3fcf ] In the previous patches, we observed that it's possible for there to be freemap entries with zero size but a nonzero base. This isn't an inconsistency per se, but older kernels can get confused by this and corrupt the block, leading to corruption. If we see this, flag the xattr structure for optimization so that it gets rebuilt. Cc: # v4.15 Fixes: 13791d3b833428 ("xfs: scrub extended attribute leaf space") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/scrub/attr.c | 54 ++++++++++++++++++++++----------------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/fs/xfs/scrub/attr.c b/fs/xfs/scrub/attr.c index 708334f9b2bd1..ef299be01de5e 100644 --- a/fs/xfs/scrub/attr.c +++ b/fs/xfs/scrub/attr.c @@ -287,32 +287,6 @@ xchk_xattr_set_map( return ret; } =20 -/* - * Check the leaf freemap from the usage bitmap. Returns false if the - * attr freemap has problems or points to used space. - */ -STATIC bool -xchk_xattr_check_freemap( - struct xfs_scrub *sc, - struct xfs_attr3_icleaf_hdr *leafhdr) -{ - struct xchk_xattr_buf *ab =3D sc->buf; - unsigned int mapsize =3D sc->mp->m_attr_geo->blksize; - int i; - - /* Construct bitmap of freemap contents. */ - bitmap_zero(ab->freemap, mapsize); - for (i =3D 0; i < XFS_ATTR_LEAF_MAPSIZE; i++) { - if (!xchk_xattr_set_map(sc, ab->freemap, - leafhdr->freemap[i].base, - leafhdr->freemap[i].size)) - return false; - } - - /* Look for bits that are set in freemap and are marked in use. */ - return !bitmap_intersects(ab->freemap, ab->usedmap, mapsize); -} - /* * Check this leaf entry's relations to everything else. * Returns the number of bytes used for the name/value data. @@ -403,6 +377,7 @@ xchk_xattr_block( =20 *last_checked =3D blk->blkno; bitmap_zero(ab->usedmap, mp->m_attr_geo->blksize); + bitmap_zero(ab->freemap, mp->m_attr_geo->blksize); =20 /* Check all the padding. */ if (xfs_has_crc(ds->sc->mp)) { @@ -449,6 +424,9 @@ xchk_xattr_block( if ((char *)&entries[leafhdr.count] > (char *)leaf + leafhdr.firstused) xchk_da_set_corrupt(ds, level); =20 + if (ds->sc->sm->sm_flags & XFS_SCRUB_OFLAG_CORRUPT) + goto out; + buf_end =3D (char *)bp->b_addr + mp->m_attr_geo->blksize; for (i =3D 0, ent =3D entries; i < leafhdr.count; ent++, i++) { /* Mark the leaf entry itself. */ @@ -467,7 +445,29 @@ xchk_xattr_block( goto out; } =20 - if (!xchk_xattr_check_freemap(ds->sc, &leafhdr)) + /* Construct bitmap of freemap contents. */ + for (i =3D 0; i < XFS_ATTR_LEAF_MAPSIZE; i++) { + if (!xchk_xattr_set_map(ds->sc, ab->freemap, + leafhdr.freemap[i].base, + leafhdr.freemap[i].size)) + xchk_da_set_corrupt(ds, level); + + /* + * freemap entries with zero length and nonzero base can cause + * problems with older kernels, so we mark these for preening + * even though there's no inconsistency. + */ + if (leafhdr.freemap[i].size =3D=3D 0 && + leafhdr.freemap[i].base > 0) + xchk_da_set_preen(ds, level); + + if (ds->sc->sm->sm_flags & XFS_SCRUB_OFLAG_CORRUPT) + goto out; + } + + /* Look for bits that are set in freemap and are marked in use. */ + if (bitmap_intersects(ab->freemap, ab->usedmap, + mp->m_attr_geo->blksize)) xchk_da_set_corrupt(ds, level); =20 if (leafhdr.usedbytes !=3D usedbytes) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 85F3A405994; Sat, 28 Feb 2026 17:44:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300641; cv=none; b=VT7bwNPRNrGKK2PdO1zDp9qBuraWME5IzMgI8N0K3dV+2HvGegVepp9DQgHytgeshsbhP3UcGKitLXCAjRisCVKWviTKMcOjxfVVZCBJR+HF1Z5V4kdUC/eX7t1U38ojqLJCAiwCiI86o0aBOMYpxxFDMxA/lRwe8EYZcd0NY3E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300641; c=relaxed/simple; bh=lMjFxD+80hL9B3iCB39/KHPwCwDV9RytnNQRPLnUyDo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ODKrAmyHwNSEXXTJYv8J6uS6DJoqdYTln8lakWtMIsJhh2SyZ7vSKFPDx7gmEx88pi+9uiCS968yhwT1mHwRc2nBSFT0shcW4vmjVs8MHxsjM6/JwoNhmlUQVD+bMZalc1VY5IEbwbYFVa/morswnvnmWcbeWNTybw++YVlt87M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=buFKmVpK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="buFKmVpK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B67C6C116D0; Sat, 28 Feb 2026 17:44:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300641; bh=lMjFxD+80hL9B3iCB39/KHPwCwDV9RytnNQRPLnUyDo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=buFKmVpKlTEyDMScUNBjjRVdx9eYtVBp2ujfSZ/n4dKuCInrCJcLt3qIn4oXze92b 8XJ0SJGoOlkLUVtYxkVTGv1QGJ2gh+HlQvOyAFM1Ww9unE37jTkstMOJeVsxYNjuLI THCysuly/g7UT2hKtEsBkZq/GsSLWth5PjNCuifvtQbIy6TsEMpnyPcrxyiHnskh8r iCehAXnBVo7e+Fg1R7UrMRW+IqLOhcuao4pJvg6NrrV5xedLhennigbaLkH2WwbJf0 bLqVu9jCFRt9o0Z7U80uTJmijfcwBdOHEbeF3twnW2jf9EVGdq3H+fwJF6SsBGLPKH LvxgF51HzBa9A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , Christoph Hellwig , Sasha Levin Subject: [PATCH 6.19 682/844] xfs: fix remote xattr valuelblk check Date: Sat, 28 Feb 2026 12:29:55 -0500 Message-ID: <20260228173244.1509663-683-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" [ Upstream commit bd3138e8912c9db182eac5fed1337645a98b7a4f ] In debugging other problems with generic/753, it turns out that it's possible for the system go to down in the middle of a remote xattr set operation such that the leaf block entry is marked incomplete and valueblk is set to zero. Make this no longer a failure. Cc: # v4.15 Fixes: 13791d3b833428 ("xfs: scrub extended attribute leaf space") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/scrub/attr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/xfs/scrub/attr.c b/fs/xfs/scrub/attr.c index ef299be01de5e..a0878fdbcf386 100644 --- a/fs/xfs/scrub/attr.c +++ b/fs/xfs/scrub/attr.c @@ -338,7 +338,10 @@ xchk_xattr_entry( rentry =3D xfs_attr3_leaf_name_remote(leaf, idx); namesize =3D xfs_attr_leaf_entsize_remote(rentry->namelen); name_end =3D (char *)rentry + namesize; - if (rentry->namelen =3D=3D 0 || rentry->valueblk =3D=3D 0) + if (rentry->namelen =3D=3D 0) + xchk_da_set_corrupt(ds, level); + if (rentry->valueblk =3D=3D 0 && + !(ent->flags & XFS_ATTR_INCOMPLETE)) xchk_da_set_corrupt(ds, level); } if (name_end > buf_end) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D681406236; Sat, 28 Feb 2026 17:44:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300642; cv=none; b=nOKhJXFxNjxdUKFdrX9ChQIv44i4Kpc7gzIlFtk0HA9QxeZ1rUOF5Ck8sC7Wj+DYWqrPlTvaEDmScV4BzR2FVVdhR+ZYUPNwF0JxWXWcyqn/8ErF63rFKxHb57CakY+UnOPuA5TGRoBFd1D6Spr+eWcmQxlYJiullXx33hV0TbM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300642; c=relaxed/simple; bh=rG777D05VbMN+iLIKLq9Ir7FOuhPQ38fxLYEAXif68Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aJwMDM7gyvShLiXhnfFcVYaJQ7lKfoFfYX5/yvttr4EgHLNJYZh8HoS6biv7MFpcM8MjWw/5Cfdt728FKf6MS44JHlxu7tY0wVnVJO7V8atWCTbAV2DtdiFqmAbbxcE8Pz3/WFwKPUlzc2Ge+nyEpFqzfduQNSd3xPOJ1utv738= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GkNl8Zrx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GkNl8Zrx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93F5FC19425; Sat, 28 Feb 2026 17:44:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300642; bh=rG777D05VbMN+iLIKLq9Ir7FOuhPQ38fxLYEAXif68Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GkNl8ZrxynmMg9EqiFJ1twe29hHNukjGI791l/B6J5+0FgQnUdTgsWdz8IaYOp80t yTDqqLyvRDFpg9/NMFQ8irFmukAOMxH/bjXf8VVyDyghQXaj2haWIKiWtnuRtzA3rv xRZ4Zln+AiEJZduGgqE+0NXo5sehPa6nmHc9tnDBC+16XUJD8tU/enHYIp+8Z5KfYr /tWlIGCWt1zcv2XZIV/PYz5LfrXsbeLzB+xqHpPaKWaWN66uKuXYyEZP/Jx8jfo4HJ wzvygS0tgeneg7E7twWK/FgzobroD5dRu4CsgAMfMy8CcM/zqJXf9ut/LkVSSk+PYp 6cLVQwDBEbZVg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , r772577952@gmail.com, Christoph Hellwig , Sasha Levin Subject: [PATCH 6.19 683/844] xfs: get rid of the xchk_xfile_*_descr calls Date: Sat, 28 Feb 2026 12:29:56 -0500 Message-ID: <20260228173244.1509663-684-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" [ Upstream commit 60382993a2e18041f88c7969f567f168cd3b4de3 ] The xchk_xfile_*_descr macros call kasprintf, which can fail to allocate memory if the formatted string is larger than 16 bytes (or whatever the nofail guarantees are nowadays). Some of them could easily exceed that, and Jiaming Zhang found a few places where that can happen with syzbot. The descriptions are debugging aids and aren't required to be unique, so let's just pass in static strings and eliminate this path to failure. Note this patch touches a number of commits, most of which were merged between 6.6 and 6.14. Cc: r772577952@gmail.com Cc: # v6.12 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/scrub/agheader_repair.c | 13 ++++--------- fs/xfs/scrub/alloc_repair.c | 5 +---- fs/xfs/scrub/attr_repair.c | 20 +++++--------------- fs/xfs/scrub/bmap_repair.c | 6 +----- fs/xfs/scrub/common.h | 25 ------------------------- fs/xfs/scrub/dir.c | 13 ++++--------- fs/xfs/scrub/dir_repair.c | 11 +++-------- fs/xfs/scrub/dirtree.c | 11 +++-------- fs/xfs/scrub/ialloc_repair.c | 5 +---- fs/xfs/scrub/nlinks.c | 6 ++---- fs/xfs/scrub/parent.c | 11 +++-------- fs/xfs/scrub/parent_repair.c | 23 ++++++----------------- fs/xfs/scrub/quotacheck.c | 13 +++---------- fs/xfs/scrub/refcount_repair.c | 13 ++----------- fs/xfs/scrub/rmap_repair.c | 5 +---- fs/xfs/scrub/rtbitmap_repair.c | 6 ++---- fs/xfs/scrub/rtrefcount_repair.c | 15 +++------------ fs/xfs/scrub/rtrmap_repair.c | 5 +---- fs/xfs/scrub/rtsummary.c | 7 ++----- 19 files changed, 47 insertions(+), 166 deletions(-) diff --git a/fs/xfs/scrub/agheader_repair.c b/fs/xfs/scrub/agheader_repair.c index cd6f0223879f4..a2f6a7f71d839 100644 --- a/fs/xfs/scrub/agheader_repair.c +++ b/fs/xfs/scrub/agheader_repair.c @@ -1708,7 +1708,6 @@ xrep_agi( { struct xrep_agi *ragi; struct xfs_mount *mp =3D sc->mp; - char *descr; unsigned int i; int error; =20 @@ -1742,17 +1741,13 @@ xrep_agi( xagino_bitmap_init(&ragi->iunlink_bmp); sc->buf_cleanup =3D xrep_agi_buf_cleanup; =20 - descr =3D xchk_xfile_ag_descr(sc, "iunlinked next pointers"); - error =3D xfarray_create(descr, 0, sizeof(xfs_agino_t), - &ragi->iunlink_next); - kfree(descr); + error =3D xfarray_create("iunlinked next pointers", 0, + sizeof(xfs_agino_t), &ragi->iunlink_next); if (error) return error; =20 - descr =3D xchk_xfile_ag_descr(sc, "iunlinked prev pointers"); - error =3D xfarray_create(descr, 0, sizeof(xfs_agino_t), - &ragi->iunlink_prev); - kfree(descr); + error =3D xfarray_create("iunlinked prev pointers", 0, + sizeof(xfs_agino_t), &ragi->iunlink_prev); if (error) return error; =20 diff --git a/fs/xfs/scrub/alloc_repair.c b/fs/xfs/scrub/alloc_repair.c index bed6a09aa7911..b6fe1f23819eb 100644 --- a/fs/xfs/scrub/alloc_repair.c +++ b/fs/xfs/scrub/alloc_repair.c @@ -850,7 +850,6 @@ xrep_allocbt( struct xrep_abt *ra; struct xfs_mount *mp =3D sc->mp; unsigned int busy_gen; - char *descr; int error; =20 /* We require the rmapbt to rebuild anything. */ @@ -876,11 +875,9 @@ xrep_allocbt( } =20 /* Set up enough storage to handle maximally fragmented free space. */ - descr =3D xchk_xfile_ag_descr(sc, "free space records"); - error =3D xfarray_create(descr, mp->m_sb.sb_agblocks / 2, + error =3D xfarray_create("free space records", mp->m_sb.sb_agblocks / 2, sizeof(struct xfs_alloc_rec_incore), &ra->free_records); - kfree(descr); if (error) goto out_ra; =20 diff --git a/fs/xfs/scrub/attr_repair.c b/fs/xfs/scrub/attr_repair.c index 09d63aa10314b..eded354dec11e 100644 --- a/fs/xfs/scrub/attr_repair.c +++ b/fs/xfs/scrub/attr_repair.c @@ -1529,7 +1529,6 @@ xrep_xattr_setup_scan( struct xrep_xattr **rxp) { struct xrep_xattr *rx; - char *descr; int max_len; int error; =20 @@ -1555,35 +1554,26 @@ xrep_xattr_setup_scan( goto out_rx; =20 /* Set up some staging for salvaged attribute keys and values */ - descr =3D xchk_xfile_ino_descr(sc, "xattr keys"); - error =3D xfarray_create(descr, 0, sizeof(struct xrep_xattr_key), + error =3D xfarray_create("xattr keys", 0, sizeof(struct xrep_xattr_key), &rx->xattr_records); - kfree(descr); if (error) goto out_rx; =20 - descr =3D xchk_xfile_ino_descr(sc, "xattr names"); - error =3D xfblob_create(descr, &rx->xattr_blobs); - kfree(descr); + error =3D xfblob_create("xattr names", &rx->xattr_blobs); if (error) goto out_keys; =20 if (xfs_has_parent(sc->mp)) { ASSERT(sc->flags & XCHK_FSGATES_DIRENTS); =20 - descr =3D xchk_xfile_ino_descr(sc, - "xattr retained parent pointer entries"); - error =3D xfarray_create(descr, 0, + error =3D xfarray_create("xattr parent pointer entries", 0, sizeof(struct xrep_xattr_pptr), &rx->pptr_recs); - kfree(descr); if (error) goto out_values; =20 - descr =3D xchk_xfile_ino_descr(sc, - "xattr retained parent pointer names"); - error =3D xfblob_create(descr, &rx->pptr_names); - kfree(descr); + error =3D xfblob_create("xattr parent pointer names", + &rx->pptr_names); if (error) goto out_pprecs; =20 diff --git a/fs/xfs/scrub/bmap_repair.c b/fs/xfs/scrub/bmap_repair.c index 1084213b8e9b8..747cd9389b491 100644 --- a/fs/xfs/scrub/bmap_repair.c +++ b/fs/xfs/scrub/bmap_repair.c @@ -923,7 +923,6 @@ xrep_bmap( bool allow_unwritten) { struct xrep_bmap *rb; - char *descr; xfs_extnum_t max_bmbt_recs; bool large_extcount; int error =3D 0; @@ -945,11 +944,8 @@ xrep_bmap( /* Set up enough storage to handle the max records for this fork. */ large_extcount =3D xfs_has_large_extent_counts(sc->mp); max_bmbt_recs =3D xfs_iext_max_nextents(large_extcount, whichfork); - descr =3D xchk_xfile_ino_descr(sc, "%s fork mapping records", - whichfork =3D=3D XFS_DATA_FORK ? "data" : "attr"); - error =3D xfarray_create(descr, max_bmbt_recs, + error =3D xfarray_create("fork mapping records", max_bmbt_recs, sizeof(struct xfs_bmbt_rec), &rb->bmap_records); - kfree(descr); if (error) goto out_rb; =20 diff --git a/fs/xfs/scrub/common.h b/fs/xfs/scrub/common.h index ddbc065c798cd..f2ecc68538f0c 100644 --- a/fs/xfs/scrub/common.h +++ b/fs/xfs/scrub/common.h @@ -246,31 +246,6 @@ static inline bool xchk_could_repair(const struct xfs_= scrub *sc) =20 int xchk_metadata_inode_forks(struct xfs_scrub *sc); =20 -/* - * Helper macros to allocate and format xfile description strings. - * Callers must kfree the pointer returned. - */ -#define xchk_xfile_descr(sc, fmt, ...) \ - kasprintf(XCHK_GFP_FLAGS, "XFS (%s): " fmt, \ - (sc)->mp->m_super->s_id, ##__VA_ARGS__) -#define xchk_xfile_ag_descr(sc, fmt, ...) \ - kasprintf(XCHK_GFP_FLAGS, "XFS (%s): AG 0x%x " fmt, \ - (sc)->mp->m_super->s_id, \ - (sc)->sa.pag ? \ - pag_agno((sc)->sa.pag) : (sc)->sm->sm_agno, \ - ##__VA_ARGS__) -#define xchk_xfile_ino_descr(sc, fmt, ...) \ - kasprintf(XCHK_GFP_FLAGS, "XFS (%s): inode 0x%llx " fmt, \ - (sc)->mp->m_super->s_id, \ - (sc)->ip ? (sc)->ip->i_ino : (sc)->sm->sm_ino, \ - ##__VA_ARGS__) -#define xchk_xfile_rtgroup_descr(sc, fmt, ...) \ - kasprintf(XCHK_GFP_FLAGS, "XFS (%s): rtgroup 0x%x " fmt, \ - (sc)->mp->m_super->s_id, \ - (sc)->sa.pag ? \ - rtg_rgno((sc)->sr.rtg) : (sc)->sm->sm_agno, \ - ##__VA_ARGS__) - /* * Setting up a hook to wait for intents to drain is costly -- we have to = take * the CPU hotplug lock and force an i-cache flush on all CPUs once to set= it diff --git a/fs/xfs/scrub/dir.c b/fs/xfs/scrub/dir.c index c877bde71e628..4f849d98cbdd2 100644 --- a/fs/xfs/scrub/dir.c +++ b/fs/xfs/scrub/dir.c @@ -1102,22 +1102,17 @@ xchk_directory( sd->xname.name =3D sd->namebuf; =20 if (xfs_has_parent(sc->mp)) { - char *descr; - /* * Set up some staging memory for dirents that we can't check * due to locking contention. */ - descr =3D xchk_xfile_ino_descr(sc, "slow directory entries"); - error =3D xfarray_create(descr, 0, sizeof(struct xchk_dirent), - &sd->dir_entries); - kfree(descr); + error =3D xfarray_create("slow directory entries", 0, + sizeof(struct xchk_dirent), &sd->dir_entries); if (error) goto out_sd; =20 - descr =3D xchk_xfile_ino_descr(sc, "slow directory entry names"); - error =3D xfblob_create(descr, &sd->dir_names); - kfree(descr); + error =3D xfblob_create("slow directory entry names", + &sd->dir_names); if (error) goto out_entries; } diff --git a/fs/xfs/scrub/dir_repair.c b/fs/xfs/scrub/dir_repair.c index 8d3b550990b58..7a21b688a4715 100644 --- a/fs/xfs/scrub/dir_repair.c +++ b/fs/xfs/scrub/dir_repair.c @@ -1784,20 +1784,15 @@ xrep_dir_setup_scan( struct xrep_dir *rd) { struct xfs_scrub *sc =3D rd->sc; - char *descr; int error; =20 /* Set up some staging memory for salvaging dirents. */ - descr =3D xchk_xfile_ino_descr(sc, "directory entries"); - error =3D xfarray_create(descr, 0, sizeof(struct xrep_dirent), - &rd->dir_entries); - kfree(descr); + error =3D xfarray_create("directory entries", 0, + sizeof(struct xrep_dirent), &rd->dir_entries); if (error) return error; =20 - descr =3D xchk_xfile_ino_descr(sc, "directory entry names"); - error =3D xfblob_create(descr, &rd->dir_names); - kfree(descr); + error =3D xfblob_create("directory entry names", &rd->dir_names); if (error) goto out_xfarray; =20 diff --git a/fs/xfs/scrub/dirtree.c b/fs/xfs/scrub/dirtree.c index 3a9cdf8738b6d..f9c85b8b194fa 100644 --- a/fs/xfs/scrub/dirtree.c +++ b/fs/xfs/scrub/dirtree.c @@ -92,7 +92,6 @@ xchk_setup_dirtree( struct xfs_scrub *sc) { struct xchk_dirtree *dl; - char *descr; int error; =20 xchk_fsgates_enable(sc, XCHK_FSGATES_DIRENTS); @@ -116,16 +115,12 @@ xchk_setup_dirtree( =20 mutex_init(&dl->lock); =20 - descr =3D xchk_xfile_ino_descr(sc, "dirtree path steps"); - error =3D xfarray_create(descr, 0, sizeof(struct xchk_dirpath_step), - &dl->path_steps); - kfree(descr); + error =3D xfarray_create("dirtree path steps", 0, + sizeof(struct xchk_dirpath_step), &dl->path_steps); if (error) goto out_dl; =20 - descr =3D xchk_xfile_ino_descr(sc, "dirtree path names"); - error =3D xfblob_create(descr, &dl->path_names); - kfree(descr); + error =3D xfblob_create("dirtree path names", &dl->path_names); if (error) goto out_steps; =20 diff --git a/fs/xfs/scrub/ialloc_repair.c b/fs/xfs/scrub/ialloc_repair.c index 14e48d3f1912b..b1d00167d263f 100644 --- a/fs/xfs/scrub/ialloc_repair.c +++ b/fs/xfs/scrub/ialloc_repair.c @@ -797,7 +797,6 @@ xrep_iallocbt( { struct xrep_ibt *ri; struct xfs_mount *mp =3D sc->mp; - char *descr; xfs_agino_t first_agino, last_agino; int error =3D 0; =20 @@ -816,11 +815,9 @@ xrep_iallocbt( /* Set up enough storage to handle an AG with nothing but inodes. */ xfs_agino_range(mp, pag_agno(sc->sa.pag), &first_agino, &last_agino); last_agino /=3D XFS_INODES_PER_CHUNK; - descr =3D xchk_xfile_ag_descr(sc, "inode index records"); - error =3D xfarray_create(descr, last_agino, + error =3D xfarray_create("inode index records", last_agino, sizeof(struct xfs_inobt_rec_incore), &ri->inode_records); - kfree(descr); if (error) goto out_ri; =20 diff --git a/fs/xfs/scrub/nlinks.c b/fs/xfs/scrub/nlinks.c index 091c79e432e59..2ba686e4de8bc 100644 --- a/fs/xfs/scrub/nlinks.c +++ b/fs/xfs/scrub/nlinks.c @@ -990,7 +990,6 @@ xchk_nlinks_setup_scan( struct xchk_nlink_ctrs *xnc) { struct xfs_mount *mp =3D sc->mp; - char *descr; unsigned long long max_inos; xfs_agnumber_t last_agno =3D mp->m_sb.sb_agcount - 1; xfs_agino_t first_agino, last_agino; @@ -1007,10 +1006,9 @@ xchk_nlinks_setup_scan( */ xfs_agino_range(mp, last_agno, &first_agino, &last_agino); max_inos =3D XFS_AGINO_TO_INO(mp, last_agno, last_agino) + 1; - descr =3D xchk_xfile_descr(sc, "file link counts"); - error =3D xfarray_create(descr, min(XFS_MAXINUMBER + 1, max_inos), + error =3D xfarray_create("file link counts", + min(XFS_MAXINUMBER + 1, max_inos), sizeof(struct xchk_nlink), &xnc->nlinks); - kfree(descr); if (error) goto out_teardown; =20 diff --git a/fs/xfs/scrub/parent.c b/fs/xfs/scrub/parent.c index 11d5de10fd567..23c195d14494e 100644 --- a/fs/xfs/scrub/parent.c +++ b/fs/xfs/scrub/parent.c @@ -755,7 +755,6 @@ xchk_parent_pptr( struct xfs_scrub *sc) { struct xchk_pptrs *pp; - char *descr; int error; =20 pp =3D kvzalloc(sizeof(struct xchk_pptrs), XCHK_GFP_FLAGS); @@ -768,16 +767,12 @@ xchk_parent_pptr( * Set up some staging memory for parent pointers that we can't check * due to locking contention. */ - descr =3D xchk_xfile_ino_descr(sc, "slow parent pointer entries"); - error =3D xfarray_create(descr, 0, sizeof(struct xchk_pptr), - &pp->pptr_entries); - kfree(descr); + error =3D xfarray_create("slow parent pointer entries", 0, + sizeof(struct xchk_pptr), &pp->pptr_entries); if (error) goto out_pp; =20 - descr =3D xchk_xfile_ino_descr(sc, "slow parent pointer names"); - error =3D xfblob_create(descr, &pp->pptr_names); - kfree(descr); + error =3D xfblob_create("slow parent pointer names", &pp->pptr_names); if (error) goto out_entries; =20 diff --git a/fs/xfs/scrub/parent_repair.c b/fs/xfs/scrub/parent_repair.c index 2949feda62717..897902c54178d 100644 --- a/fs/xfs/scrub/parent_repair.c +++ b/fs/xfs/scrub/parent_repair.c @@ -1497,7 +1497,6 @@ xrep_parent_setup_scan( struct xrep_parent *rp) { struct xfs_scrub *sc =3D rp->sc; - char *descr; struct xfs_da_geometry *geo =3D sc->mp->m_attr_geo; int max_len; int error; @@ -1525,32 +1524,22 @@ xrep_parent_setup_scan( goto out_xattr_name; =20 /* Set up some staging memory for logging parent pointer updates. */ - descr =3D xchk_xfile_ino_descr(sc, "parent pointer entries"); - error =3D xfarray_create(descr, 0, sizeof(struct xrep_pptr), - &rp->pptr_recs); - kfree(descr); + error =3D xfarray_create("parent pointer entries", 0, + sizeof(struct xrep_pptr), &rp->pptr_recs); if (error) goto out_xattr_value; =20 - descr =3D xchk_xfile_ino_descr(sc, "parent pointer names"); - error =3D xfblob_create(descr, &rp->pptr_names); - kfree(descr); + error =3D xfblob_create("parent pointer names", &rp->pptr_names); if (error) goto out_recs; =20 /* Set up some storage for copying attrs before the mapping exchange */ - descr =3D xchk_xfile_ino_descr(sc, - "parent pointer retained xattr entries"); - error =3D xfarray_create(descr, 0, sizeof(struct xrep_parent_xattr), - &rp->xattr_records); - kfree(descr); + error =3D xfarray_create("parent pointer xattr entries", 0, + sizeof(struct xrep_parent_xattr), &rp->xattr_records); if (error) goto out_names; =20 - descr =3D xchk_xfile_ino_descr(sc, - "parent pointer retained xattr values"); - error =3D xfblob_create(descr, &rp->xattr_blobs); - kfree(descr); + error =3D xfblob_create("parent pointer xattr values", &rp->xattr_blobs); if (error) goto out_attr_keys; =20 diff --git a/fs/xfs/scrub/quotacheck.c b/fs/xfs/scrub/quotacheck.c index d412a8359784e..3b2f4ccde2ec0 100644 --- a/fs/xfs/scrub/quotacheck.c +++ b/fs/xfs/scrub/quotacheck.c @@ -741,7 +741,6 @@ xqcheck_setup_scan( struct xfs_scrub *sc, struct xqcheck *xqc) { - char *descr; struct xfs_quotainfo *qi =3D sc->mp->m_quotainfo; unsigned long long max_dquots =3D XFS_DQ_ID_MAX + 1ULL; int error; @@ -756,28 +755,22 @@ xqcheck_setup_scan( =20 error =3D -ENOMEM; if (xfs_this_quota_on(sc->mp, XFS_DQTYPE_USER)) { - descr =3D xchk_xfile_descr(sc, "user dquot records"); - error =3D xfarray_create(descr, max_dquots, + error =3D xfarray_create("user dquot records", max_dquots, sizeof(struct xqcheck_dquot), &xqc->ucounts); - kfree(descr); if (error) goto out_teardown; } =20 if (xfs_this_quota_on(sc->mp, XFS_DQTYPE_GROUP)) { - descr =3D xchk_xfile_descr(sc, "group dquot records"); - error =3D xfarray_create(descr, max_dquots, + error =3D xfarray_create("group dquot records", max_dquots, sizeof(struct xqcheck_dquot), &xqc->gcounts); - kfree(descr); if (error) goto out_teardown; } =20 if (xfs_this_quota_on(sc->mp, XFS_DQTYPE_PROJ)) { - descr =3D xchk_xfile_descr(sc, "project dquot records"); - error =3D xfarray_create(descr, max_dquots, + error =3D xfarray_create("project dquot records", max_dquots, sizeof(struct xqcheck_dquot), &xqc->pcounts); - kfree(descr); if (error) goto out_teardown; } diff --git a/fs/xfs/scrub/refcount_repair.c b/fs/xfs/scrub/refcount_repair.c index 9c8cb5332da04..360fd7354880a 100644 --- a/fs/xfs/scrub/refcount_repair.c +++ b/fs/xfs/scrub/refcount_repair.c @@ -123,13 +123,7 @@ int xrep_setup_ag_refcountbt( struct xfs_scrub *sc) { - char *descr; - int error; - - descr =3D xchk_xfile_ag_descr(sc, "rmap record bag"); - error =3D xrep_setup_xfbtree(sc, descr); - kfree(descr); - return error; + return xrep_setup_xfbtree(sc, "rmap record bag"); } =20 /* Check for any obvious conflicts with this shared/CoW staging extent. */ @@ -704,7 +698,6 @@ xrep_refcountbt( { struct xrep_refc *rr; struct xfs_mount *mp =3D sc->mp; - char *descr; int error; =20 /* We require the rmapbt to rebuild anything. */ @@ -717,11 +710,9 @@ xrep_refcountbt( rr->sc =3D sc; =20 /* Set up enough storage to handle one refcount record per block. */ - descr =3D xchk_xfile_ag_descr(sc, "reference count records"); - error =3D xfarray_create(descr, mp->m_sb.sb_agblocks, + error =3D xfarray_create("reference count records", mp->m_sb.sb_agblocks, sizeof(struct xfs_refcount_irec), &rr->refcount_records); - kfree(descr); if (error) goto out_rr; =20 diff --git a/fs/xfs/scrub/rmap_repair.c b/fs/xfs/scrub/rmap_repair.c index 17d4a38d735cb..cfd1cf403b37e 100644 --- a/fs/xfs/scrub/rmap_repair.c +++ b/fs/xfs/scrub/rmap_repair.c @@ -164,14 +164,11 @@ xrep_setup_ag_rmapbt( struct xfs_scrub *sc) { struct xrep_rmap *rr; - char *descr; int error; =20 xchk_fsgates_enable(sc, XCHK_FSGATES_RMAP); =20 - descr =3D xchk_xfile_ag_descr(sc, "reverse mapping records"); - error =3D xrep_setup_xfbtree(sc, descr); - kfree(descr); + error =3D xrep_setup_xfbtree(sc, "reverse mapping records"); if (error) return error; =20 diff --git a/fs/xfs/scrub/rtbitmap_repair.c b/fs/xfs/scrub/rtbitmap_repair.c index 203a1a97c5026..41d6736a529d0 100644 --- a/fs/xfs/scrub/rtbitmap_repair.c +++ b/fs/xfs/scrub/rtbitmap_repair.c @@ -43,7 +43,6 @@ xrep_setup_rtbitmap( struct xchk_rtbitmap *rtb) { struct xfs_mount *mp =3D sc->mp; - char *descr; unsigned long long blocks =3D mp->m_sb.sb_rbmblocks; int error; =20 @@ -52,9 +51,8 @@ xrep_setup_rtbitmap( return error; =20 /* Create an xfile to hold our reconstructed bitmap. */ - descr =3D xchk_xfile_rtgroup_descr(sc, "bitmap file"); - error =3D xfile_create(descr, blocks * mp->m_sb.sb_blocksize, &sc->xfile); - kfree(descr); + error =3D xfile_create("realtime bitmap file", + blocks * mp->m_sb.sb_blocksize, &sc->xfile); if (error) return error; =20 diff --git a/fs/xfs/scrub/rtrefcount_repair.c b/fs/xfs/scrub/rtrefcount_rep= air.c index 983362447826d..b35e39cce7ad5 100644 --- a/fs/xfs/scrub/rtrefcount_repair.c +++ b/fs/xfs/scrub/rtrefcount_repair.c @@ -128,13 +128,7 @@ int xrep_setup_rtrefcountbt( struct xfs_scrub *sc) { - char *descr; - int error; - - descr =3D xchk_xfile_ag_descr(sc, "rmap record bag"); - error =3D xrep_setup_xfbtree(sc, descr); - kfree(descr); - return error; + return xrep_setup_xfbtree(sc, "realtime rmap record bag"); } =20 /* Check for any obvious conflicts with this shared/CoW staging extent. */ @@ -704,7 +698,6 @@ xrep_rtrefcountbt( { struct xrep_rtrefc *rr; struct xfs_mount *mp =3D sc->mp; - char *descr; int error; =20 /* We require the rmapbt to rebuild anything. */ @@ -722,11 +715,9 @@ xrep_rtrefcountbt( rr->sc =3D sc; =20 /* Set up enough storage to handle one refcount record per rt extent. */ - descr =3D xchk_xfile_ag_descr(sc, "reference count records"); - error =3D xfarray_create(descr, mp->m_sb.sb_rextents, - sizeof(struct xfs_refcount_irec), + error =3D xfarray_create("realtime reference count records", + mp->m_sb.sb_rextents, sizeof(struct xfs_refcount_irec), &rr->refcount_records); - kfree(descr); if (error) goto out_rr; =20 diff --git a/fs/xfs/scrub/rtrmap_repair.c b/fs/xfs/scrub/rtrmap_repair.c index 7561941a337a1..749977a66e40f 100644 --- a/fs/xfs/scrub/rtrmap_repair.c +++ b/fs/xfs/scrub/rtrmap_repair.c @@ -103,14 +103,11 @@ xrep_setup_rtrmapbt( struct xfs_scrub *sc) { struct xrep_rtrmap *rr; - char *descr; int error; =20 xchk_fsgates_enable(sc, XCHK_FSGATES_RMAP); =20 - descr =3D xchk_xfile_rtgroup_descr(sc, "reverse mapping records"); - error =3D xrep_setup_xfbtree(sc, descr); - kfree(descr); + error =3D xrep_setup_xfbtree(sc, "realtime reverse mapping records"); if (error) return error; =20 diff --git a/fs/xfs/scrub/rtsummary.c b/fs/xfs/scrub/rtsummary.c index 4ac679c1bd29c..fb78cff2ac3a1 100644 --- a/fs/xfs/scrub/rtsummary.c +++ b/fs/xfs/scrub/rtsummary.c @@ -43,7 +43,6 @@ xchk_setup_rtsummary( struct xfs_scrub *sc) { struct xfs_mount *mp =3D sc->mp; - char *descr; struct xchk_rtsummary *rts; int error; =20 @@ -70,10 +69,8 @@ xchk_setup_rtsummary( * Create an xfile to construct a new rtsummary file. The xfile allows * us to avoid pinning kernel memory for this purpose. */ - descr =3D xchk_xfile_descr(sc, "realtime summary file"); - error =3D xfile_create(descr, XFS_FSB_TO_B(mp, mp->m_rsumblocks), - &sc->xfile); - kfree(descr); + error =3D xfile_create("realtime summary file", + XFS_FSB_TO_B(mp, mp->m_rsumblocks), &sc->xfile); if (error) return error; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A6D2C406255; Sat, 28 Feb 2026 17:44:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300643; cv=none; b=PLL+SLgCJwGA9duFb7QyfFGdNeHUlbc2c5IpeKGtpwapPTFV6IaHp+hxqE0aEd5VxdCBEDQGWBhb2exxg49/SUy7Rxm8fuf2gzI09QMkpPfQ0UDJXQ2m9tfp5RNsePSOYh/TBXutCowjHd3JdtCSMoOFtKDCq8zVAV8jatc7CNs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300643; c=relaxed/simple; bh=CVsQXwErh+3UDMxzd+f1OyBwyYab9vaX/eDRrIKzo50=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UnYxKETcxYKRgl1PsBjmVrFn65MIBLug0X97jy1lDejnfNjiH4aVkHp2gisk/kmvc7jGkV7EJaCZ1tpVzCxHxrJUTlcvjABClxov2Q4BDFwabGp8DGtpXZrxtYxI6xFvm1ie1JopZZAe6kYJ9ocm3ungr5iUC7FQ1/CnpoMfgUQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=es8l/TAz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="es8l/TAz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 854F6C19423; Sat, 28 Feb 2026 17:44:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300643; bh=CVsQXwErh+3UDMxzd+f1OyBwyYab9vaX/eDRrIKzo50=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=es8l/TAzStZ1vYjObZUfbydS9B8ObfxPPhnD3N0fYTxMUVBSw3hYfSnQF4i46koTW COVYxp9QiLDwQgv4c3cuW6Tbt7Rvbz+cUI2x4MqB4/WlpKFi/3WJ4rRAtNy55ww52V nZ6t2gklbNQfOAcWYJeh2Bgv963sxe/7ZXYdA5wg2IuZ5Y/IvdNFAczzGREOS5aIkw JJggywGgDmo+Q5ZfBPL30qDUXSF32RhRfAQxH5zseBZgCp41JmknT72M6hY5/Uwm5V RnPL9qi3avqQs8j9f4Q64qT41qf79gjal4WNB+I/DqgIGE1OHD7ApKBU8PLOq4cTuB GKD9ZuyRjaa4Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Janne Grunau , Neal Gompa , Stephen Boyd , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 684/844] spmi: apple: Add "apple,t8103-spmi" compatible Date: Sat, 28 Feb 2026 12:29:57 -0500 Message-ID: <20260228173244.1509663-685-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Janne Grunau [ Upstream commit 6c54b0a801dd8227237ba0bf0728bb42681cf027 ] After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,spmi" anymore [1]. Use "apple,t8103-spmi" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@ker= nel.org/ Fixes: 77ca75e80c71 ("spmi: add a spmi driver for Apple SoC") Cc: stable@vger.kernel.org Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau Signed-off-by: Stephen Boyd Link: https://patch.msgid.link/20260123182039.224314-7-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/spmi/spmi-apple-controller.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spmi/spmi-apple-controller.c b/drivers/spmi/spmi-apple= -controller.c index 697b3e8bb0235..87e3ee9d4f2aa 100644 --- a/drivers/spmi/spmi-apple-controller.c +++ b/drivers/spmi/spmi-apple-controller.c @@ -149,6 +149,7 @@ static int apple_spmi_probe(struct platform_device *pde= v) } =20 static const struct of_device_id apple_spmi_match_table[] =3D { + { .compatible =3D "apple,t8103-spmi", }, { .compatible =3D "apple,spmi", }, {} }; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 400444059A0; Sat, 28 Feb 2026 17:44:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300644; cv=none; b=N+WivQ09FcjhSRU40fCOeNComd6HiH0PeRJ7pR7Ub6Smo2fh3TaxFGIHTwg7y+ap5NKa2/c8LDr3mLPUclDAGCmdUZ96S/yh4JyMSAkfZtFYCoOO2oUT72LgNEU5cSnwbYBlTwf9Fz8E1fscqVwVAJAeT3Jgo4TnWNfVcoWA+Kk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300644; c=relaxed/simple; bh=AedUg56Kv4+hZRWO362YEp7CZLERRZDvK76EqmWpuKA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W2YuHQwFrp2/CYvPhB1xFScgORHXMEFUEfcsM0pTsPmUfZGeugvGQLewZFNYR1fpAb1XdNm2SZU35zSz6jM5PnBUl4RkazRR8QThf7y9mOoT94vvqf3jtHSRDq0IDlGjvZD+vhkcfCYodW9Ifcio9mElCudBXzwmQwqPaE1VMDk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WjrLBFE0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WjrLBFE0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E284C116D0; Sat, 28 Feb 2026 17:44:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300644; bh=AedUg56Kv4+hZRWO362YEp7CZLERRZDvK76EqmWpuKA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WjrLBFE057s/AlBze4ChGNQJ6qEJ2sSQUF/oKtnM41wKHBNDmKInf6AgpNcySMmjq Tun2IkcfL+AOHEloPpea+9p0flLiXEcUHe2WWCs25KQgtml4x+qGZjJpcs6Y3SWMMi YXa9reyHxCcerLxBJC8y+gOx1f//UixxIj642vgStBcXVqRksKeREHVQYo9Liba8rj q4nxHplZ4MIec4O6wUaeDNVeKIKOzvZ/qAxDYVVpb83dAkiph8eluGOZ5auGrmtuIt yl7RUHyOXjuCtHPj7qQUgzDhk0MU5k/Iqxbu+gyndEy7DwQFPtutYXGkU9TnE2USHo UTBgPOVeaXC/g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lyude Paul , Danilo Krummrich , Sasha Levin Subject: [PATCH 6.19 685/844] rust/drm: Fix Registration::{new,new_foreign_owned}() docs Date: Sat, 28 Feb 2026 12:29:58 -0500 Message-ID: <20260228173244.1509663-686-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lyude Paul [ Upstream commit 638eeda8abaa3e6afe6bd5758ef8045a7f33b9a0 ] Looks like we've actually had a malformed rustdoc reference in the rustdocs for Registration::new_foreign_owned() for a while that, when fixed, still couldn't resolve properly because it refers to a private item. This is probably leftover from when Registration::new() was public, so drop the documentation from that function and fixup the documentation for Registration::new_foreign_owned(). Signed-off-by: Lyude Paul Acked-by: Danilo Krummrich Fixes: 0600032c54b7 ("rust: drm: add DRM driver registration") Cc: # v6.16+ Link: https://patch.msgid.link/20260122221037.3462081-1-lyude@redhat.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- rust/kernel/drm/driver.rs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs index f30ee4c6245cd..e09f977b5b519 100644 --- a/rust/kernel/drm/driver.rs +++ b/rust/kernel/drm/driver.rs @@ -121,7 +121,6 @@ pub trait Driver { pub struct Registration(ARef>); =20 impl Registration { - /// Creates a new [`Registration`] and registers it. fn new(drm: &drm::Device, flags: usize) -> Result { // SAFETY: `drm.as_raw()` is valid by the invariants of `drm::Devi= ce`. to_result(unsafe { bindings::drm_dev_register(drm.as_raw(), flags)= })?; @@ -129,8 +128,9 @@ fn new(drm: &drm::Device, flags: usize) -> Result { Ok(Self(drm.into())) } =20 - /// Same as [`Registration::new`}, but transfers ownership of the [`Re= gistration`] to - /// [`devres::register`]. + /// Registers a new [`Device`](drm::Device) with userspace. + /// + /// Ownership of the [`Registration`] object is passed to [`devres::re= gister`]. pub fn new_foreign_owned( drm: &drm::Device, dev: &device::Device, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 214DB406D30; Sat, 28 Feb 2026 17:44:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300645; cv=none; b=co7/taRn3BNSQg0Rt6AwxcfGjNls+PW4HSCUhqd03DTkBx9thzzzKcT66rDe6anUKFwhRuJKmP/ZitEYL4DZJUwbjAb4q+m2N0VTyAqmtvSrmRVkudGsuNbXkn8Al+elfWnHA5b7OIeuUBoVfdAoOJNlA7Q8NCyAPGolvai68Do= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300645; c=relaxed/simple; bh=MbuABjn9H9HKfHNv7nGjfbWLKR6u++7irBa3GmCmfZ4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rsTiUXyMHFYcHe9eq9T87Wz1ELELphVW44aq824WPGZ367bnLyANNiRLPAn4dY/H6EpevRbkLRfqXoojSJPU9IL+vjcgVAWfaZaFL8mf1spNTdB58WIp9MeaCV8SXD51uVjIadgltNIcpw9erKdqTOfnznBPpvZXBNLkGQdO43s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ms1NaqP2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ms1NaqP2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68911C19424; Sat, 28 Feb 2026 17:44:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300645; bh=MbuABjn9H9HKfHNv7nGjfbWLKR6u++7irBa3GmCmfZ4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ms1NaqP2fhY07hwI5kmwqa7QjCwWC1enFCUDtTv7Q02G3EtBRYYo5LjoxwTRo5kLY Vws8utbGTT0LVQz/8i3r3hLpDHx9AkVcFsN3fXRZ1pyg9jRSQzT5BkzKKqg4VZoBJt gGIuDS661pjgSKZouAbaM+hHGPOa0/8zO1nrKVsqiCWXTyTXvrlvvSRWRAGQaNsEp2 r4qXdua1LIW6seWzDiGscSo5fhVk8o9kzRU54bx3KbBQN6+lhq3c/+ayFbV8x3R7FU OTr2uf7Ej9UE2Oo/9q2yR9heMtSUMDoQy9PMn5SynRa6TlfvA8bLG6Q/O0qcgYxa8C Iz6KoY19fBvOg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vasiliy Kovalev , Sean Christopherson , Sasha Levin Subject: [PATCH 6.19 686/844] KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2() Date: Sat, 28 Feb 2026 12:29:59 -0500 Message-ID: <20260228173244.1509663-687-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vasiliy Kovalev [ Upstream commit 95d848dc7e639988dbb385a8cba9b484607cf98c ] Add SRCU read-side protection when reading PDPTR registers in __get_sregs2(). Reading PDPTRs may trigger access to guest memory: kvm_pdptr_read() -> svm_cache_reg() -> load_pdptrs() -> kvm_vcpu_read_guest_page() -> kvm_vcpu_gfn_to_memslot() kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(), which uses srcu_dereference_check() and requires either kvm->srcu or kvm->slots_lock to be held. Currently only vcpu->mutex is held, triggering lockdep warning: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot 6.12.59+ #3 Not tainted include/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active =3D 2, debug_locks =3D 1 1 lock held by syz.5.1717/15100: #0: ff1100002f4b00b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/= 0x1590 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824 __kvm_memslots include/linux/kvm_host.h:1062 [inline] __kvm_memslots include/linux/kvm_host.h:1059 [inline] kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline] kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617 kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302 load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065 svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688 kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline] __get_sregs2 arch/x86/kvm/x86.c:11784 [inline] kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279 kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Suggested-by: Sean Christopherson Cc: stable@vger.kernel.org Fixes: 6dba94035203 ("KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2") Signed-off-by: Vasiliy Kovalev Link: https://patch.msgid.link/20260123222801.646123-1-kovalev@altlinux.org Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/kvm/x86.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index d65ebaed18986..8b12bf0774c77 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -12157,9 +12157,11 @@ static void __get_sregs2(struct kvm_vcpu *vcpu, st= ruct kvm_sregs2 *sregs2) return; =20 if (is_pae_paging(vcpu)) { + kvm_vcpu_srcu_read_lock(vcpu); for (i =3D 0 ; i < 4 ; i++) sregs2->pdptrs[i] =3D kvm_pdptr_read(vcpu, i); sregs2->flags |=3D KVM_SREGS2_FLAGS_PDPTRS_VALID; + kvm_vcpu_srcu_read_unlock(vcpu); } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4328D406D57; Sat, 28 Feb 2026 17:44:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300646; cv=none; b=t6tCBKuvEFzQ2GFjRWezNwKuF2Lsma1mtIc8v6iSKBmAhy4rwqn3O3jVqFNs7mK7sP6gp8fBIDjO/SjUmsls1SFnLSHUEERVVsdaQdHTCvcZ/Cj/9afosazPMU5NnAvjT6gUQq5DyeltpM0sG7zgjl5XN07eRRMdpanyNp0GVrM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300646; c=relaxed/simple; bh=uywr7CSIBVJdzBj0/d7eb/WIoGhpGFKanqhG09sqgeE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=t0444jgVJMwQLkg6o54D1x6+Cp2duXXfxb5uUtgysZ6ERVr7NO2s+0eHYUldXM1nyVNGjKZC2fmF7e6dU5c4Kt9hfWmUJM76eebMmFn0TyCfWlKR5mmf+3Y1hacWEmItyPvx1+ooh746IEI5zDP5i3uObkP8Hx8xACfMmtdm46k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F2Xp63cX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F2Xp63cX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48E5AC19423; Sat, 28 Feb 2026 17:44:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300646; bh=uywr7CSIBVJdzBj0/d7eb/WIoGhpGFKanqhG09sqgeE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F2Xp63cX/kgJLz/L2EMBRbb4sBY6rO+HWw+e3r4306O2LAwcKH2zOUEu1DqCzfW7s PdZZ6BsrGCr/x5UJav5AgbVVdFoHEJcQm4nh0lVwoYsRVOtV0F2KKjnmfEpmtQ76HS dPeNne4sDH2uliG1tDoeStszT5lZSzMn5+ltnOi2MFax5eajNqATL5ALYANCXmzUaq 93kbA96SsOuG7buWA2I5qo5i2kGIw0gZPp3nT9hSIsrV6zcpBOjULddhex+a5LdZs3 JZVIjahXPO7R1BDr/HnuHaQ9ZEogdB8Zp77qko4Uf30o57nVgZBtfWOHNJvxaYfzV1 qYX9bUXKOTGaw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Manikanta Maddireddy , Manivannan Sadhasivam , Bjorn Helgaas , Niklas Cassel , Frank Li , Sasha Levin Subject: [PATCH 6.19 687/844] PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions Date: Sat, 28 Feb 2026 12:30:00 -0500 Message-ID: <20260228173244.1509663-688-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Manikanta Maddireddy [ Upstream commit 8754dd7639ab0fd68c3ab9d91c7bdecc3e5740a8 ] struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 Fixes: e85a2d783762 ("PCI: endpoint: Add support in configfs to associate t= wo EPCs with EPF") Signed-off-by: Manikanta Maddireddy [mani: cced stable, changed commit message as per https://lore.kernel.org/l= inux-pci/aV9joi3jF1R6ca02@ryzen] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260108062747.1870669-1-mmaddireddy@nvidia.= com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/endpoint/pci-ep-cfs.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/pci/endpoint/pci-ep-cfs.c b/drivers/pci/endpoint/pci-e= p-cfs.c index 43feb6139fa36..8b392a8363bb1 100644 --- a/drivers/pci/endpoint/pci-ep-cfs.c +++ b/drivers/pci/endpoint/pci-ep-cfs.c @@ -68,8 +68,8 @@ static int pci_secondary_epc_epf_link(struct config_item = *epf_item, return 0; } =20 -static void pci_secondary_epc_epf_unlink(struct config_item *epc_item, - struct config_item *epf_item) +static void pci_secondary_epc_epf_unlink(struct config_item *epf_item, + struct config_item *epc_item) { struct pci_epf_group *epf_group =3D to_pci_epf_group(epf_item->ci_parent); struct pci_epc_group *epc_group =3D to_pci_epc_group(epc_item); @@ -132,8 +132,8 @@ static int pci_primary_epc_epf_link(struct config_item = *epf_item, return 0; } =20 -static void pci_primary_epc_epf_unlink(struct config_item *epc_item, - struct config_item *epf_item) +static void pci_primary_epc_epf_unlink(struct config_item *epf_item, + struct config_item *epc_item) { struct pci_epf_group *epf_group =3D to_pci_epf_group(epf_item->ci_parent); struct pci_epc_group *epc_group =3D to_pci_epc_group(epc_item); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 44A1C407A72; Sat, 28 Feb 2026 17:44:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300647; cv=none; b=K+6QrQgfz2KE2lBf7RZNQq8ZQRdPkyrBzmzo77nNsQ2BUc6wyvO6RLZr1yyGrcUTqCCeVF3z2Jjgu/sSMekzlcM/10Ga8OvrpdJBA3KE3treA9cKH5NpdC3tFBaZpkkPWfdhB+qmrzyphtI5uncbHR1Yun6w5sp5+qBJgFlxxCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300647; c=relaxed/simple; bh=0gyeaJeEvy8mAjJ9Rf2x728MJKlHIwZPHrIr5G9Oqfw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sbL0UVE7k4B3P5C1A69e8dJiDWizOtXebA04Ux2jWC94GIXPlvfub0ZS6T3NJhBs1L0R6E4jPV4GeQ902kRjtyemVITIXXB/4SBd7ZjZJXkLDK8GTdu+lG8fALNZtMuCAZEvMyuxDIdgHCuwegLfqRqkqsP479KgPdkBIKoWSF8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sKGIJLYv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sKGIJLYv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64FB2C19423; Sat, 28 Feb 2026 17:44:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300647; bh=0gyeaJeEvy8mAjJ9Rf2x728MJKlHIwZPHrIr5G9Oqfw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sKGIJLYv6oSClxudwHX4vRYBDsmRtJZCY6eGiHzRE2faxWHB6PdBGl8j2O9FGRzwP ZRvFijbJX+uFP4ow8GKEfFcn1W+KkbZLvllz5o8+V3riTYWi7IeVfhewZKPhFdLbGM IQQYqgJpcj9OSFH+JJVrT+kopJPai6ULH0vhqLStQKEIX0YRGVynkGnduncEFPV05O StZSF8cM402cBleH3mQT40ALKEyPzXji1tdgRiVTDVIJ83VvPnlgVLhtYDcC8/3lTd TZ4Nhv7QmkadNpPkmyP7YGY5JNud6IoDCTTIzrJ1s2xLbd9hsAV1DM702Z37ySK53C Yeto3+XJbOaQw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Raag Jadav , Guido Trentalancia , Mika Westerberg , Andy Shevchenko , Sasha Levin Subject: [PATCH 6.19 688/844] pinctrl: intel: Add code name documentation Date: Sat, 28 Feb 2026 12:30:01 -0500 Message-ID: <20260228173244.1509663-689-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Raag Jadav [ Upstream commit fc32c5725fbe1164d353400389d3e29d19960a3a ] Intel pinctrl drivers support large set of platforms and the IPs are often reused by their different variants, but it's currently not possible to figure out the exact driver that supports specific variant. Add user friendly documentation for them. Cc: stable@vger.kernel.org Reported-by: Guido Trentalancia Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D220056 Signed-off-by: Raag Jadav Acked-by: Mika Westerberg Acked-by: Guido Trentalancia [andy: added Oxford comma] Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pinctrl/intel/Kconfig | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/pinctrl/intel/Kconfig b/drivers/pinctrl/intel/Kconfig index 248c2e558ff32..3ebf072371457 100644 --- a/drivers/pinctrl/intel/Kconfig +++ b/drivers/pinctrl/intel/Kconfig @@ -52,7 +52,10 @@ config PINCTRL_ALDERLAKE select PINCTRL_INTEL help This pinctrl driver provides an interface that allows configuring - of Intel Alder Lake PCH pins and using them as GPIOs. + PCH pins of the following platforms and using them as GPIOs: + - Alder Lake HX, N, and S + - Raptor Lake HX, E, and S + - Twin Lake =20 config PINCTRL_BROXTON tristate "Intel Broxton pinctrl and GPIO driver" @@ -136,15 +139,17 @@ config PINCTRL_METEORLAKE select PINCTRL_INTEL help This pinctrl driver provides an interface that allows configuring - of Intel Meteor Lake pins and using them as GPIOs. + SoC pins of the following platforms and using them as GPIOs: + - Arrow Lake (all variants) + - Meteor Lake (all variants) =20 config PINCTRL_METEORPOINT tristate "Intel Meteor Point pinctrl and GPIO driver" select PINCTRL_INTEL help - Meteor Point is the PCH of Intel Meteor Lake. This pinctrl driver - provides an interface that allows configuring of PCH pins and - using them as GPIOs. + This pinctrl driver provides an interface that allows configuring + PCH pins of the following platforms and using them as GPIOs: + - Arrow Lake HX and S =20 config PINCTRL_SUNRISEPOINT tristate "Intel Sunrisepoint pinctrl and GPIO driver" @@ -159,7 +164,11 @@ config PINCTRL_TIGERLAKE select PINCTRL_INTEL help This pinctrl driver provides an interface that allows configuring - of Intel Tiger Lake PCH pins and using them as GPIOs. + PCH pins of the following platforms and using them as GPIOs: + - Alder Lake H, P, PS, and U + - Raptor Lake H, P, PS, PX, and U + - Rocket Lake S + - Tiger Lake (all variants) =20 source "drivers/pinctrl/intel/Kconfig.tng" endmenu --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3388E407A8B; Sat, 28 Feb 2026 17:44:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300648; cv=none; b=EPnPE+sE3KEwgk1o2AxwDYHIhP3qqjdYixyBDb3Eqgng2opmIGj668NgaV7UfwoRN5W25IXiUX5Rkgywm64hWl9J/+eqNnFCi4oOxmK7e/iX9kgDMu42q2keSTisP3UvMPMvxW/fyS8BUBodJzoEvXPrqPPcgusrmUKI3vg3ZLs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300648; c=relaxed/simple; bh=cuz0HrJojVSCVZxXgiwczN+3ALnzoM2hqpMUZbMXo5E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PJjHKMgGu4MzYald26gXhlKXA4Wz7mzxT/0PFwCAy50O17J+jvGTtkAqfHf2nhFNaZjsXab33OSTfVZoyOvwABf0VMOxbKLHu5+9dS6gi/pPDG8HNs6AGW2WQM1zgGuxMEQyBm13BQ6KDXS3H9xn4LynVO9fDNAgh29wexxHlPo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Yrq4Cda0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yrq4Cda0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CF0EC116D0; Sat, 28 Feb 2026 17:44:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300648; bh=cuz0HrJojVSCVZxXgiwczN+3ALnzoM2hqpMUZbMXo5E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Yrq4Cda0mZ3KXjjrylc2Erckj3fwAViEdQX8sORo/gzz8X1ynyJvP2vpj0CvvcCaX 4Kk/D6thtQvaRBfMLVJ1PhqmpzBQU8ekftEy0hr7Uc5TIXJWATF1Nyixi8le36+m01 gOOuk8m7Pf8f0IjMxrIkEJnGOib4k7buNe0CGlK1eXHFbo9ac6KJyxp8E5NETwllMY 9qe3reh8jHlj/iRMDPjWGd4tusQ5Gr+8TsTj3pKouVI5hgQbOswRRlXAvduTbH9brw 8fQ4BZXyx8llh8xUN0bnJY0DsnR42ApB1RfV2WHAjnvKrxKOEpgYTxLy6EmgZqEZRF O7dLbV1pE+6pw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , r772577952@gmail.com, Christoph Hellwig , Sasha Levin Subject: [PATCH 6.19 689/844] xfs: only call xf{array,blob}_destroy if we have a valid pointer Date: Sat, 28 Feb 2026 12:30:02 -0500 Message-ID: <20260228173244.1509663-690-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" [ Upstream commit ba408d299a3bb3c5309f40c5326e4fb83ead4247 ] Only call the xfarray and xfblob destructor if we have a valid pointer, and be sure to null out that pointer afterwards. Note that this patch fixes a large number of commits, most of which were merged between 6.9 and 6.10. Cc: r772577952@gmail.com Cc: # v6.12 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/scrub/agheader_repair.c | 8 ++++++-- fs/xfs/scrub/attr_repair.c | 6 ++++-- fs/xfs/scrub/dir_repair.c | 8 ++++++-- fs/xfs/scrub/dirtree.c | 8 ++++++-- fs/xfs/scrub/nlinks.c | 3 ++- 5 files changed, 24 insertions(+), 9 deletions(-) diff --git a/fs/xfs/scrub/agheader_repair.c b/fs/xfs/scrub/agheader_repair.c index a2f6a7f71d839..6e3fef36d6614 100644 --- a/fs/xfs/scrub/agheader_repair.c +++ b/fs/xfs/scrub/agheader_repair.c @@ -837,8 +837,12 @@ xrep_agi_buf_cleanup( { struct xrep_agi *ragi =3D buf; =20 - xfarray_destroy(ragi->iunlink_prev); - xfarray_destroy(ragi->iunlink_next); + if (ragi->iunlink_prev) + xfarray_destroy(ragi->iunlink_prev); + ragi->iunlink_prev =3D NULL; + if (ragi->iunlink_next) + xfarray_destroy(ragi->iunlink_next); + ragi->iunlink_next =3D NULL; xagino_bitmap_destroy(&ragi->iunlink_bmp); } =20 diff --git a/fs/xfs/scrub/attr_repair.c b/fs/xfs/scrub/attr_repair.c index eded354dec11e..dd24044c44efd 100644 --- a/fs/xfs/scrub/attr_repair.c +++ b/fs/xfs/scrub/attr_repair.c @@ -1516,8 +1516,10 @@ xrep_xattr_teardown( xfblob_destroy(rx->pptr_names); if (rx->pptr_recs) xfarray_destroy(rx->pptr_recs); - xfblob_destroy(rx->xattr_blobs); - xfarray_destroy(rx->xattr_records); + if (rx->xattr_blobs) + xfblob_destroy(rx->xattr_blobs); + if (rx->xattr_records) + xfarray_destroy(rx->xattr_records); mutex_destroy(&rx->lock); kfree(rx); } diff --git a/fs/xfs/scrub/dir_repair.c b/fs/xfs/scrub/dir_repair.c index 7a21b688a4715..d5a55eabf6801 100644 --- a/fs/xfs/scrub/dir_repair.c +++ b/fs/xfs/scrub/dir_repair.c @@ -172,8 +172,12 @@ xrep_dir_teardown( struct xrep_dir *rd =3D sc->buf; =20 xrep_findparent_scan_teardown(&rd->pscan); - xfblob_destroy(rd->dir_names); - xfarray_destroy(rd->dir_entries); + if (rd->dir_names) + xfblob_destroy(rd->dir_names); + rd->dir_names =3D NULL; + if (rd->dir_entries) + xfarray_destroy(rd->dir_entries); + rd->dir_names =3D NULL; } =20 /* Set up for a directory repair. */ diff --git a/fs/xfs/scrub/dirtree.c b/fs/xfs/scrub/dirtree.c index f9c85b8b194fa..3e0bbe75c44cf 100644 --- a/fs/xfs/scrub/dirtree.c +++ b/fs/xfs/scrub/dirtree.c @@ -81,8 +81,12 @@ xchk_dirtree_buf_cleanup( kfree(path); } =20 - xfblob_destroy(dl->path_names); - xfarray_destroy(dl->path_steps); + if (dl->path_names) + xfblob_destroy(dl->path_names); + dl->path_names =3D NULL; + if (dl->path_steps) + xfarray_destroy(dl->path_steps); + dl->path_steps =3D NULL; mutex_destroy(&dl->lock); } =20 diff --git a/fs/xfs/scrub/nlinks.c b/fs/xfs/scrub/nlinks.c index 2ba686e4de8bc..dec3b9b47453e 100644 --- a/fs/xfs/scrub/nlinks.c +++ b/fs/xfs/scrub/nlinks.c @@ -971,7 +971,8 @@ xchk_nlinks_teardown_scan( =20 xfs_dir_hook_del(xnc->sc->mp, &xnc->dhook); =20 - xfarray_destroy(xnc->nlinks); + if (xnc->nlinks) + xfarray_destroy(xnc->nlinks); xnc->nlinks =3D NULL; =20 xchk_iscan_teardown(&xnc->collect_iscan); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 28376492510; Sat, 28 Feb 2026 17:44:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300649; cv=none; b=mWE6pHZIwHNdQ6TRlnZTsJxm7E7NIOwHttT4DDejA6va5daPjKFLDfcrRX7yCmH2fz79iZFi8N9bb9vtK8IBA3ShrkuM3LePF8Pz4VzYNdUb1dHjb5y7zo0bXvD+h7SUBZ5EUzRcgRmYpkYdSDjV94ej+NVhq3NUOlWMBzZcR2g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300649; c=relaxed/simple; bh=/kb3/CN4l+J4R7vK+W4oMij34Pk/nldAKDkkXdUCpEg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RhmfnqSwaAvAglBXCJkMsZjA5YLa+d9kQ+FL2rnQM3ATO97RaaLlC4Nwjq3vW9i8oqLCSH+oXdKTzNq5N0OiM+zl34/vznsOvUa6dtnZy9aCyvhO2u4vqph+w1Dd2IOlqEbMeiGpKb/eGv1yiU+j9ts8tGqjKM6nrpt+0A4f4VM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aizzmWZt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aizzmWZt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AA1BC19424; Sat, 28 Feb 2026 17:44:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300649; bh=/kb3/CN4l+J4R7vK+W4oMij34Pk/nldAKDkkXdUCpEg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aizzmWZtUK3P5d8IhxD85pPXmYXTeVURrs0TroovgE4cFqIdykdvL/V9WwnGLlWvI E/aY55vfAX+ogZm1/RIVyeuEXw1DDYMwqAAKXQ84OdwrFlGNrDRmfpolZYc7JfWYtS cgcQ27+3KuO0OofDrWC77GelrmirePRRaxiAn/p4d6s3flHczXLl8r8z8cSyyCSx27 Czqq9FKeu6EjeznSTlsLgYrFtXNiRXGqjem47tQZVkO6KoJnTixUwKGhIiXCVK2ytO 1ANx7SlSx3CVGwcJKNYm4GXq6WgGhIi8aZwLcIPjIMjg8zlAVvlYBBNTF8e1LU323K DvDPtIHvnFwZw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , r772577952@gmail.com, Christoph Hellwig , Sasha Levin Subject: [PATCH 6.19 690/844] xfs: check return value of xchk_scrub_create_subord Date: Sat, 28 Feb 2026 12:30:03 -0500 Message-ID: <20260228173244.1509663-691-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" [ Upstream commit ca27313fb3f23e4ac18532ede4ec1c7cc5814c4a ] Fix this function to return NULL instead of a mangled ENOMEM, then fix the callers to actually check for a null pointer and return ENOMEM. Most of the corrections here are for code merged between 6.2 and 6.10. Cc: r772577952@gmail.com Cc: # v6.12 Fixes: 1a5f6e08d4e379 ("xfs: create subordinate scrub contexts for xchk_met= adata_inode_subtype") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/scrub/common.c | 3 +++ fs/xfs/scrub/repair.c | 3 +++ fs/xfs/scrub/scrub.c | 2 +- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/xfs/scrub/common.c b/fs/xfs/scrub/common.c index 5f9be4151d722..ebabf3b620a2c 100644 --- a/fs/xfs/scrub/common.c +++ b/fs/xfs/scrub/common.c @@ -1399,6 +1399,9 @@ xchk_metadata_inode_subtype( int error; =20 sub =3D xchk_scrub_create_subord(sc, scrub_type); + if (!sub) + return -ENOMEM; + error =3D sub->sc.ops->scrub(&sub->sc); xchk_scrub_free_subord(sub); return error; diff --git a/fs/xfs/scrub/repair.c b/fs/xfs/scrub/repair.c index efd5a7ccdf624..4d45d39e67f11 100644 --- a/fs/xfs/scrub/repair.c +++ b/fs/xfs/scrub/repair.c @@ -1136,6 +1136,9 @@ xrep_metadata_inode_subtype( * setup/teardown routines. */ sub =3D xchk_scrub_create_subord(sc, scrub_type); + if (!sub) + return -ENOMEM; + error =3D sub->sc.ops->scrub(&sub->sc); if (error) goto out; diff --git a/fs/xfs/scrub/scrub.c b/fs/xfs/scrub/scrub.c index 3c3b0d25006ff..c312f0a672e65 100644 --- a/fs/xfs/scrub/scrub.c +++ b/fs/xfs/scrub/scrub.c @@ -634,7 +634,7 @@ xchk_scrub_create_subord( =20 sub =3D kzalloc(sizeof(*sub), XCHK_GFP_FLAGS); if (!sub) - return ERR_PTR(-ENOMEM); + return NULL; =20 sub->old_smtype =3D sc->sm->sm_type; sub->old_smflags =3D sc->sm->sm_flags; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15CD4408538; Sat, 28 Feb 2026 17:44:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300650; cv=none; b=r5nWcogva+i27X2ve1sKgDv7kVzwW5vZlOH986bEaKTVmPwZ2E7H2CruqUiQQe5cfxCSKlghuU2SEwiROokYJQlccNtfKh5fIOptnXQdfBPb8qbw0bPu9/73nMcqI9eJfSp/lQneY3fKo+adJigmSZ2Ez+apWDilk+vWh3+9U/A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300650; c=relaxed/simple; bh=mdmC0ism8/cu3mnEHsqV2RhrhtLVd5ter06KAnbIgCY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BqyG9UzFSJTwn9rtTB3kEi0MwV5KDwR7Hyr8WXpcQjSSGdQTLtJuTUFvbBC+WgNEXiVseESttGD7cCN/u3OsKQlv2prX4vMEevcFpna8XYly8LLr6tUUsgFb+OcecoVg84dQyz2PcGlBbss4SU1RW2skgaQAuWFl+CgsrZEYrZ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hKbF6ZFg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hKbF6ZFg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CD0EC19423; Sat, 28 Feb 2026 17:44:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300650; bh=mdmC0ism8/cu3mnEHsqV2RhrhtLVd5ter06KAnbIgCY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hKbF6ZFgtS34rUsT+TIDk3KQhsMKa+dcoVSzrkQnKtNb3Qbl9B4X/2Vx4Sww6jM3a vRLosUUdP3JDI7v9UFSvtr3X4Qlxn6j2pz4Xt0atQpScoCdmyn1YIl7DjZFmQxrD7K /vMKtp+ZndaR0FdYQYPPGmgCxPpCUf0Bmh6RI7mQxbNKx5dMSj1vGIGzZqWwMcSLYp jSM9eKFLzXMm/4AC8madT3thcBkOGsTot89AJbuEjkp1OzaazbyKufIa50x4bIBq/W ztyiM/zVcO6cEn7RRzH8PwIEydOVza+saSc0R3aGgU5oxNAUbSUO23idEbcouwkOno qPx55075ybY0Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , r772577952@gmail.com, Christoph Hellwig , Sasha Levin Subject: [PATCH 6.19 691/844] xfs: check for deleted cursors when revalidating two btrees Date: Sat, 28 Feb 2026 12:30:04 -0500 Message-ID: <20260228173244.1509663-692-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" [ Upstream commit 55e03b8cbe2783ec9acfb88e8adb946ed504e117 ] The free space and inode btree repair functions will rebuild both btrees at the same time, after which it needs to evaluate both btrees to confirm that the corruptions are gone. However, Jiaming Zhang ran syzbot and produced a crash in the second xchk_allocbt call. His root-cause analysis is as follows (with minor corrections): In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first for BNOBT, second for CNTBT). The cause of this issue is that the first call nullified the cursor required by the second call. Let's first enter xrep_revalidate_allocbt() via following call chain: xfs_file_ioctl() -> xfs_ioc_scrubv_metadata() -> xfs_scrub_metadata() -> `sc->ops->repair_eval(sc)` -> xrep_revalidate_allocbt() xchk_allocbt() is called twice in this function. In the first call: /* Note that sc->sm->sm_type is XFS_SCRUB_TYPE_BNOPT now */ xchk_allocbt() -> xchk_btree() -> `bs->scrub_rec(bs, recp)` -> xchk_allocbt_rec() -> xchk_allocbt_xref() -> xchk_allocbt_xref_other() since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to &sc->sa.cnt_cur. Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call chain: xfs_alloc_get_rec() -> xfs_btree_get_rec() -> xfs_btree_check_block() -> (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter is true, return -EFSCORRUPTED. This should be caused by ioctl$XFS_IOC_ERROR_INJECTION I guess. Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this function, *curpp (points to sc->sa.cnt_cur) is nullified. Back to xrep_revalidate_allocbt(), since sc->sa.cnt_cur has been nullified, it then triggered null-ptr-deref via xchk_allocbt() (second call) -> xchk_btree(). So. The bnobt revalidation failed on a cross-reference attempt, so we deleted the cntbt cursor, and then crashed when we tried to revalidate the cntbt. Therefore, check for a null cntbt cursor before that revalidation, and mark the repair incomplete. Also we can ignore the second tree entirely if the first tree was rebuilt but is already corrupt. Apply the same fix to xrep_revalidate_iallocbt because it has the same problem. Cc: r772577952@gmail.com Link: https://lore.kernel.org/linux-xfs/CANypQFYU5rRPkTy=3DiG5m1Lp4RWasSgrH= XAh3p8YJojxV0X15dQ@mail.gmail.com/T/#m520c7835fad637eccf843c7936c200589427c= c7e Cc: # v6.8 Fixes: dbfbf3bdf639a2 ("xfs: repair inode btrees") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/xfs/scrub/alloc_repair.c | 15 +++++++++++++++ fs/xfs/scrub/ialloc_repair.c | 20 +++++++++++++++++--- 2 files changed, 32 insertions(+), 3 deletions(-) diff --git a/fs/xfs/scrub/alloc_repair.c b/fs/xfs/scrub/alloc_repair.c index b6fe1f23819eb..35035d02a2316 100644 --- a/fs/xfs/scrub/alloc_repair.c +++ b/fs/xfs/scrub/alloc_repair.c @@ -923,7 +923,22 @@ xrep_revalidate_allocbt( if (error) goto out; =20 + /* + * If the bnobt is still corrupt, we've failed to repair the filesystem + * and should just bail out. + * + * If the bnobt fails cross-examination with the cntbt, the scan will + * free the cntbt cursor, so we need to mark the repair incomplete + * and avoid walking off the end of the NULL cntbt cursor. + */ + if (sc->sm->sm_flags & XFS_SCRUB_OFLAG_CORRUPT) + goto out; + sc->sm->sm_type =3D XFS_SCRUB_TYPE_CNTBT; + if (!sc->sa.cnt_cur) { + xchk_set_incomplete(sc); + goto out; + } error =3D xchk_allocbt(sc); out: sc->sm->sm_type =3D old_type; diff --git a/fs/xfs/scrub/ialloc_repair.c b/fs/xfs/scrub/ialloc_repair.c index b1d00167d263f..f28459f58832f 100644 --- a/fs/xfs/scrub/ialloc_repair.c +++ b/fs/xfs/scrub/ialloc_repair.c @@ -863,10 +863,24 @@ xrep_revalidate_iallocbt( if (error) goto out; =20 - if (xfs_has_finobt(sc->mp)) { - sc->sm->sm_type =3D XFS_SCRUB_TYPE_FINOBT; - error =3D xchk_iallocbt(sc); + /* + * If the inobt is still corrupt, we've failed to repair the filesystem + * and should just bail out. + * + * If the inobt fails cross-examination with the finobt, the scan will + * free the finobt cursor, so we need to mark the repair incomplete + * and avoid walking off the end of the NULL finobt cursor. + */ + if (!xfs_has_finobt(sc->mp) || + (sc->sm->sm_flags & XFS_SCRUB_OFLAG_CORRUPT)) + goto out; + + sc->sm->sm_type =3D XFS_SCRUB_TYPE_FINOBT; + if (!sc->sa.fino_cur) { + xchk_set_incomplete(sc); + goto out; } + error =3D xchk_iallocbt(sc); =20 out: sc->sm->sm_type =3D old_type; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED8B4408551; Sat, 28 Feb 2026 17:44:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300651; cv=none; b=CmqpgTbW46RspyOAtiqKUVFtcvPQ4o0/eRzAzklhso4kLctEn56bb4SrPf66CG4sfasYfyPavgWdKr4fN/buBDxHRqMeNSj+MvVKFBpyKINM/U6vMD43Ni1Ck+ho/L40z1SxOTo7S76OIKEP90s3F2kAmeUQaoebA7MDtHKUPLI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300651; c=relaxed/simple; bh=Aqc0C09FHgHvnnRPqXKzOg3T8s79hVLPi8LPOoDVkRM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fYcybQYtbEhxmhC+iaEcrHbFDwLc8zbqDKuW3FrObzlg1c8aEOFFgx5ZQY+Lvux8m3qovSa7oTjNiJCF9Ln/eG+J+5RuI4GtaD5X7noTooN8uW5RSZiq/lUzJ3ha5bV/OuvN9LNbc32xZg259AAf0PGN/hmbm87ubcTwStJQbKw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ALHcG4Oe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ALHcG4Oe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E6E8C19423; Sat, 28 Feb 2026 17:44:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300650; bh=Aqc0C09FHgHvnnRPqXKzOg3T8s79hVLPi8LPOoDVkRM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ALHcG4Oe1NPSkVnKtOaodWgqKH0wdbvQWX0q0mgTUGPJVTbTXDJWNyo0+55dyta/w 3FdE+p1TmdtAcP4M6wxvhC3AXByaExrD01qUudr0XlmSSpWMWnh7gbUdut3EKrrmCW M6xz34JswIcYdb+uOy+tfjXVBCj1VXlWF+yHQwzS3W9rJcAgv8Avkzu4fEdguezNJc NOChhZ3QOdJ5MlGLTdDsiQQRTHsBN3okrwf0ALo9oRuBsCQr436jQWR2kei1UwOFhP Lt15623C43lvBUOODPbi0c72WD8bzSqYfUtnVcyALTeicHEvKMWp8bAAuWfKoIJbiX oMlRLXwpxIHFA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jack Wang , Yu Kuai , Sasha Levin Subject: [PATCH 6.19 692/844] md/bitmap: fix GPF in write_page caused by resize race Date: Sat, 28 Feb 2026 12:30:05 -0500 Message-ID: <20260228173244.1509663-693-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jack Wang [ Upstream commit 46ef85f854dfa9d5226b3c1c46493d79556c9589 ] A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update. Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@= ionos.com Closes: https://lore.kernel.org/linux-raid/CAMGffE=3DMbfp=3D7xD_hYxXk1PAaCZ= NSEAVeQGKGy7YF9f2S4=3DNEA@mail.gmail.com/T/#u Cc: stable@vger.kernel.org Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap= resizing.") Signed-off-by: Jack Wang Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/md-bitmap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c index 84b7e2af6dbaa..7bb56d0491a2f 100644 --- a/drivers/md/md-bitmap.c +++ b/drivers/md/md-bitmap.c @@ -2453,6 +2453,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sec= tor_t blocks, memcpy(page_address(store.sb_page), page_address(bitmap->storage.sb_page), sizeof(bitmap_super_t)); + mutex_lock(&bitmap->mddev->bitmap_info.mutex); spin_lock_irq(&bitmap->counts.lock); md_bitmap_file_unmap(&bitmap->storage); bitmap->storage =3D store; @@ -2560,7 +2561,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sec= tor_t blocks, set_page_attr(bitmap, i, BITMAP_PAGE_DIRTY); } spin_unlock_irq(&bitmap->counts.lock); - + mutex_unlock(&bitmap->mddev->bitmap_info.mutex); if (!init) { __bitmap_unplug(bitmap); bitmap->mddev->pers->quiesce(bitmap->mddev, 0); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D581B408E41; Sat, 28 Feb 2026 17:44:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300651; cv=none; b=cO0fsos/W8pXIzOywcpoNjrVjrimYw6QV1xF+GMX/6KhKvbcT8EnJofAIW+OAx0ltdYH/Eo99aM/mora+fwNvAn0h+ITfUUVGMkMD7TRhyuaS3vU5PsKyIWdydPT5vP1l9/+Qpx+SpMDGrDS8z4ikRuN+gc+TkC14lgqQ+xuctQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300651; c=relaxed/simple; bh=TU8tjJbpGgqdlyzIOimmAedpFUlDG+LzupMVudAj6h0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SgV68BqnjYq15L/D4MchWgsLu2mFP6+s2GvAedZOIumTW4+ZL4ukCEIRCPvxGA+atewK4G7XhZ/QB7kg74yxmDRe5IcvkYVnG/ns2n628N874MEVxoxKfmYfSgEqfXFWC73dZ9+Q87i7B99SlZrtRf+twOVP/akbe7nHmPlsfxs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CNCp+/kG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CNCp+/kG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1974AC19423; Sat, 28 Feb 2026 17:44:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300651; bh=TU8tjJbpGgqdlyzIOimmAedpFUlDG+LzupMVudAj6h0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CNCp+/kGw77R9RWPgVh8qvvUdHbp/Sja2SNt4CvnfP6TFTu9vnnwarZrqe7+eRvvu +K7JstDbzK7uelfQeTAheTDZ+6qFR4IGqRm0h2PXiC/meuPHY/dp5TGXEoFDM1Fb3B pmIVJFYw4N/8cEwQiaFhSzHBC+3BRakXW2+63gpOrGRHkBKfQpuumlg+GmrTRSlx9W DIcW3GkL5juz7+vXwYiUPZbKtYBu4DqzKFEl8eyYUVO7u3m5DJuL0RLHfP4Dg8ZOuP DN3yBLfWdq+js4xAcEExD7Z1V7uzo/BycL+lRRlhQhRW28bAO+ZswGf/CBv9fSEuzi rop5JyPO72WQw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jeff Layton , Chris Mason , Chuck Lever , Sasha Levin Subject: [PATCH 6.19 693/844] nfsd: fix nfs4_file refcount leak in nfsd_get_dir_deleg() Date: Sat, 28 Feb 2026 12:30:06 -0500 Message-ID: <20260228173244.1509663-694-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jeff Layton [ Upstream commit 789477b849394afdb60507924d65f7ef18f078ce ] Claude pointed out that there is a nfs4_file refcount leak in nfsd_get_dir_deleg(). Ensure that the reference to "fp" is released before returning. Fixes: 8b99f6a8c116 ("nfsd: wire up GET_DIR_DELEGATION handling") Cc: stable@vger.kernel.org Cc: Chris Mason Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/nfsd/nfs4state.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index d5e0f3a52d4f0..45d486466cdc3 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -9520,8 +9520,10 @@ nfsd_get_dir_deleg(struct nfsd4_compound_state *csta= te, spin_unlock(&clp->cl_lock); spin_unlock(&state_lock); =20 - if (!status) + if (!status) { + put_nfs4_file(fp); return dp; + } =20 /* Something failed. Drop the lease and clean up the stid */ kernel_setlease(fp->fi_deleg_file->nf_file, F_UNLCK, NULL, (void **)&dp); @@ -9529,5 +9531,6 @@ nfsd_get_dir_deleg(struct nfsd4_compound_state *cstat= e, nfs4_put_stid(&dp->dl_stid); out_delegees: put_deleg_file(fp); + put_nfs4_file(fp); return ERR_PTR(status); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 18074408E67; Sat, 28 Feb 2026 17:44:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300653; cv=none; b=a0Pc15fvcPlKUDoOyIK8ToLRvoMhy8J385rOH3GHMiDicrD7dh42+3Yij+08ovu7EhXDaTxbjTNl1u7P0ysg0ESb+UyBnRyZl9G2CXdKtA1OWVQ9AVy7+nqo+pMcfKn7buDnbyfORKGQpjtiMT95pb5JIX+URUfm+tlTzSj4qzA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300653; c=relaxed/simple; bh=Xcb95x740lu1XJg4kTK4/crhGdElR3gbj+YKv0KsAIM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=e+xrXr4ytWapZXirZywD97+nBUaJJgXuxGEtkFXXAm76Ssa4YCadpxfuVS24eDznrV5n7/B9rn6BgnshcbOFgCLhpg5ht0+S7xApACkUrc1HEyVSeQwvVBex1l0/A2tAWjij1Uqfye3zjN76IC4pZFHeqHGFhL7rS+jBPf+na3A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FfZWjRGO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FfZWjRGO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07BB1C2BC87; Sat, 28 Feb 2026 17:44:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300652; bh=Xcb95x740lu1XJg4kTK4/crhGdElR3gbj+YKv0KsAIM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FfZWjRGOYkduHXBVNJjxPmR9jbBLJjGMMu4olAAoo7R7KGQYx7YIcd5a8iXuVCRdj Lq/yXqo3772m2CMfsXxyS4nArCZ44zD0Pb1EdQZ9r7+uGHDeWzEqK/5HCxgvmX6jcP NVryc1MM6WKTJ2fd5sB9lyJnTtZ4xwgr08wKYRMksDdXAU7ot1LkmFDVmnPkr8XMBR EQ2vXc1xbvlmUaoX8kyDl0CqJRJDpL+OCR8OegnFGswDUUWprZ9QEX5l6b+DMcnkYY vHFDR7zijqcXi6BWenz6rb/YMTMiYXJDZyHrPhxj9G3K0pfVxodP0WZU0kndH3mJ8s mOClCsJYZC2ig== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Olga Kornievskaia , Jeff Layton , Chuck Lever , Sasha Levin Subject: [PATCH 6.19 694/844] NFSD: fix setting FMODE_NOCMTIME in nfs4_open_delegation Date: Sat, 28 Feb 2026 12:30:07 -0500 Message-ID: <20260228173244.1509663-695-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Olga Kornievskaia [ Upstream commit 41b0a87bc60d5ccfa8575481ddb4d4d8758507fa ] fstests generic/215 and generic/407 were failing because the server wasn't updating mtime properly. When deleg attribute support is not compiled in and thus no attribute delegation was given, the server was skipping updating mtime and ctime because FMODE_NOCMTIME was uncoditionally set for the write delegation. Fixes: e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_A= TTRS delegation") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/nfsd/nfs4state.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 45d486466cdc3..c298ec2621ec9 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -6353,7 +6353,8 @@ nfs4_open_delegation(struct svc_rqst *rqstp, struct n= fsd4_open *open, dp->dl_ctime =3D stat.ctime; dp->dl_mtime =3D stat.mtime; spin_lock(&f->f_lock); - f->f_mode |=3D FMODE_NOCMTIME; + if (deleg_ts) + f->f_mode |=3D FMODE_NOCMTIME; spin_unlock(&f->f_lock); trace_nfsd_deleg_write(&dp->dl_stid.sc_stateid); } else { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB503408E7C; Sat, 28 Feb 2026 17:44:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300653; cv=none; b=cKVbYZA+qrwpzkFP0+nZLgba044osloBIpv2s4hvY0cb6WcHq0ar/Oza14Ejn21bJJZYtc77OSztcs4dL8zg7ddQBx+eymMrNz9Dmzt5QJ5NjYFRdjDo1CdXLtQN21QBOL2hGDyggrPRYEMercC0CCh3lUX1XHV5Umb54pV3mrM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300653; c=relaxed/simple; bh=lwidor7yhbMXoDAf9SjUqka3+hhG/IispQy3ahKV/iU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TEk5IjZeE0snPI0rZQWShy7k7PTeEJ/3ROOH/JLKtrX3v/B0XB5LBwxg5AnN7dgu6zItLqn0l5J8qBFvq1srxjClVnuv2Ft67sn/HtJke8GahVnvx61/Lx/Yu5hLlcNYxMSwDRjVNsnypSC8gNeAZyDJ/Gn81m9F+vT1RsSCAXo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SxKwrOMR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SxKwrOMR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F116CC116D0; Sat, 28 Feb 2026 17:44:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300653; bh=lwidor7yhbMXoDAf9SjUqka3+hhG/IispQy3ahKV/iU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SxKwrOMRyLKGe0Xin6Ju76tVScG0+xuu2KPE0TjaFu7bBtCM+HDJAPQmLAyw0/8K0 Ghy8lgxrSX/bXALx6jPSUQE+prGJnpHd0uSgIxKiezPT/24m0iGgXpBjexsuRJ494x hrgdKC6yPO9biCsAaK84rkXgEeZht5SCztiT1Hq71ScWDLY5n4/I6OlG8HtPQl13/l PSLvXn6bMdgAXOlXdJlH7r/3f2VvKe87s2rrTayw7vFbEpgMwN0QpDxkjbIdL77FWP 9CpIGqHrt0C/iDhH/+dBeEyYoqBcwQrPnaEqtBBkBBZASxK0MQGRpraqzi7IG1qshJ 4KbbgtDhJMsUQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Anthony Iliopoulos , NeilBrown , Chuck Lever , Sasha Levin Subject: [PATCH 6.19 695/844] nfsd: fix return error code for nfsd_map_name_to_[ug]id Date: Sat, 28 Feb 2026 12:30:08 -0500 Message-ID: <20260228173244.1509663-696-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Anthony Iliopoulos [ Upstream commit 404d779466646bf1461f2090ff137e99acaecf42 ] idmap lookups can time out while the cache is waiting for a userspace upcall reply. In that case cache_check() returns -ETIMEDOUT to callers. The nfsd_map_name_to_[ug]id functions currently proceed with attempting to map the id to a kuid despite a potentially temporary failure to perform the idmap lookup. This results in the code returning the error NFSERR_BADOWNER which can cause client operations to return to userspace with failure. Fix this by returning the failure status before attempting kuid mapping. This will return NFSERR_JUKEBOX on idmap lookup timeout so that clients can retry the operation instead of aborting it. Fixes: 65e10f6d0ab0 ("nfsd: Convert idmap to use kuids and kgids") Cc: stable@vger.kernel.org Signed-off-by: Anthony Iliopoulos Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/nfsd/nfs4idmap.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/nfsd/nfs4idmap.c b/fs/nfsd/nfs4idmap.c index b5b3d45979c9b..c319c31b0f647 100644 --- a/fs/nfsd/nfs4idmap.c +++ b/fs/nfsd/nfs4idmap.c @@ -672,6 +672,8 @@ __be32 nfsd_map_name_to_uid(struct svc_rqst *rqstp, con= st char *name, return nfserr_inval; =20 status =3D do_name_to_id(rqstp, IDMAP_TYPE_USER, name, namelen, &id); + if (status) + return status; *uid =3D make_kuid(nfsd_user_namespace(rqstp), id); if (!uid_valid(*uid)) status =3D nfserr_badowner; @@ -707,6 +709,8 @@ __be32 nfsd_map_name_to_gid(struct svc_rqst *rqstp, con= st char *name, return nfserr_inval; =20 status =3D do_name_to_id(rqstp, IDMAP_TYPE_GROUP, name, namelen, &id); + if (status) + return status; *gid =3D make_kgid(nfsd_user_namespace(rqstp), id); if (!gid_valid(*gid)) status =3D nfserr_badowner; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B35BD40968B; Sat, 28 Feb 2026 17:44:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300654; cv=none; b=U+R3Gc7JnbvrStdzjo2h41rFf2Tw9EoXe6+goMhAntuCl29TKv5jSgD+lbEmY4wx+PPwxJZf1PTaOwY4BjM1dUTDBDld7DE3i94iCmFKl4vGNNjhzvynN1/wpaO74mdLBnYofuYRZnUUC2SzUMuSfj0LZDjtzSN0+bO5SuY2hmw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300654; c=relaxed/simple; bh=yxA5KaE4uvfBQpQprwMxjBhIEAzroIjNlZjVW68MtJQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kht961biiP+Xn8l97aapm9naGsDCT1VrZCJEIueFFB0EDZAjNGbcp9K3cgm4x5Bu5jlwhP0m0WeV21dgLQ7IzgBRaHLyapp5gGdDxzCf3sT+HX8PbTfvBRmB5NhvF+a+/pHcDG+Ua+wlggThBM5D+0+a64OJn3wpFURRAmGv0Yo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=n419y3Cz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="n419y3Cz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4481C19424; Sat, 28 Feb 2026 17:44:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300654; bh=yxA5KaE4uvfBQpQprwMxjBhIEAzroIjNlZjVW68MtJQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=n419y3Czown4UugM7far54u6lkWAob2g8bYcMLH7DKqi9NTrkenROFAFzZG32mwp4 nM7vwdoH8uv8XrPhQtiEhdbomYFpqd+TUl4RwzJOGaNfZLFJa6HYXkakC3jGctX5jv wIVRdcwEVjwCS1srawKF3RpFBSQ3dJ5he2wCSxlGAUenbaQYVzLzB6cZEnSo3PIu/7 74eZKOC0T3h6V78Y37jvMvkZdib6cDaCb9G/m+kW1ogsQSvpsl57pYFJ+51DV0i9A5 m6c3+a6JK9fvsb6OXk8Zu84AAapP1mb/Mqorh2Dtr+ofmGNe7Cmw07NBN6GZHvahwm na4r9JRoGT4LQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Krzysztof Kozlowski , Srinivas Kandagatla , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 696/844] nvmem: Drop OF node reference on nvmem_add_one_cell() failure Date: Sat, 28 Feb 2026 12:30:09 -0500 Message-ID: <20260228173244.1509663-697-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Krzysztof Kozlowski [ Upstream commit f397bc0781553d01b4cdba506c09334a31cb0ec5 ] If nvmem_add_one_cell() failed, the ownership of "child" (or "info.np"), thus its OF reference, is not passed further and function should clean up by putting the reference it got via earlier of_node_get(). Note that this is independent of references obtained via for_each_child_of_node() loop. Fixes: 50014d659617 ("nvmem: core: use nvmem_add_one_cell() in nvmem_add_ce= lls_from_of()") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260116170846.733558-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/nvmem/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 387c88c552595..ff68fd5ad3d6f 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -831,6 +831,7 @@ static int nvmem_add_cells_from_dt(struct nvmem_device = *nvmem, struct device_nod kfree(info.name); if (ret) { of_node_put(child); + of_node_put(info.np); return ret; } } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C2424096A8; Sat, 28 Feb 2026 17:44:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300655; cv=none; b=rXnREUaiWOdKqX5PcYLDXZvZWdDYHfVUL0zJN2WNsBL4XhGW3tfsJ8K9+1JrzHL9nu5QA6yKm3PdvZGm0gndj4SJOdasWXR5hVKw/dldKPkJQh/Tf5THSdLPi3c2douNkrMQlgWcV2aHCMSeY0Mel5TvlugCX2KGySYSVjJ7ivA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300655; c=relaxed/simple; bh=pZG3GCvDBKtzXTJvwnW1s7I9cHrCKIe4y4nCdtVb+X0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pP4VSMR1HwDv30oL6nCP2bolvYM6HVAcqwe+P23Kg7JpIAmislNtryhrB9sXYnoJJw2hngZnSseA5rKYPKIkgrMyfIDBGJ7s15DiOPLi7vIEI3HF4LCwhkyLLZclURmsXfqb0wy60YX+oUZrMGgg3ijgxuFELD0hKeb7nUyl750= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N44M+dUZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N44M+dUZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4D40C19425; Sat, 28 Feb 2026 17:44:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300655; bh=pZG3GCvDBKtzXTJvwnW1s7I9cHrCKIe4y4nCdtVb+X0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N44M+dUZvXLxfymTkWJN1xaLN/1Kdevadto2u5epUqe8YVecciSMCmCm15biK9fIM giqnSN50B2kT+GA2Sh/DEjLJquVwtCvVJHcqpTFTCkv7GMUyb3zdH00OhbivXV1Azb nuzZiYEB+bo5WBy7zd0kz29DRaMg/srliw2jN9KA7+5HOC6Z3MWudKe5yCU9N8z4P6 6S0j9xTU/TUhlyDf2Dgmp6I/lTJL7enYKht14ymxcKBRbbEf2XvwY701Ynh/HRHLLE xH8rG3MU/kSVmHvhgY8okrQ+Xz5kduayT/OeKSnuWMHASDeBEb/LmUdhQFXc7R5zJU EvhdXzFga40vQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , =?UTF-8?q?Malte=20Schr=C3=B6der?= , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.19 697/844] PCI: Fix bridge window alignment with optional resources Date: Sat, 28 Feb 2026 12:30:10 -0500 Message-ID: <20260228173244.1509663-698-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ilpo J=C3=A4rvinen [ Upstream commit 7e90360e6d4599795b6f4e094e20d0bdf3b2615f ] pbus_size_mem() has two alignments, one for required resources in min_align and another in add_align that takes account optional resources. The add_align is applied to the bridge window through the realloc_head list. It can happen, however, that add_align is larger than min_align but calculated size1 and size0 are equal due to extra tailroom (e.g., hotplug reservation, tail alignment), and therefore no entry is created to the realloc_head list. Without the bridge appearing in the realloc head, add_align is lost when pbus_size_mem() returns. The problem is visible in this log for 0000:05:00.0 which lacks add_size ... add_align ... line that would indicate it was added into the realloc_head list: pci 0000:05:00.0: PCI bridge to [bus 06-16] ... pci 0000:06:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 07] r= equires relaxed alignment rules pci 0000:06:06.0: bridge window [mem 0x00100000-0x001fffff] to [bus 0a] r= equires relaxed alignment rules pci 0000:06:07.0: bridge window [mem 0x00100000-0x003fffff] to [bus 0b] r= equires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x00800000-0x00ffffff 64bit pref] to= [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14= ] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14= ] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14= ] add_size 100000 add_align 1000000 pci 0000:06:0c.0: bridge window [mem 0x00100000-0x001fffff] to [bus 15] r= equires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] r= equires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] r= equires relaxed alignment rules pci 0000:05:00.0: bridge window [mem 0xd4800000-0xd97fffff]: assigned pci 0000:05:00.0: bridge window [mem 0x1060000000-0x10607fffff 64bit pref= ]: assigned pci 0000:06:08.0: bridge window [mem size 0x04900000]: can't assign; no s= pace pci 0000:06:08.0: bridge window [mem size 0x04900000]: failed to assign While this bug itself seems old, it has likely become more visible after the relaxed tail alignment that does not grossly overestimate the size needed for the bridge window. Make sure add_align > min_align too results in adding an entry into the realloc head list. In addition, add handling to the cases where add_size is zero while only alignment differs. Fixes: d74b9027a4da ("PCI: Consider additional PF's IOV BAR alignment in si= zing and assigning") Reported-by: Malte Schr=C3=B6der Signed-off-by: Ilpo J=C3=A4rvinen Signed-off-by: Bjorn Helgaas Tested-by: Malte Schr=C3=B6der Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251219174036.16738-2-ilpo.jarvinen@linux.i= ntel.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/setup-bus.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 09a28cfcd5b88..ee8fe6e0de5fd 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -14,6 +14,7 @@ * tighter packing. Prefetchable range support. */ =20 +#include #include #include #include @@ -463,7 +464,7 @@ static void reassign_resources_sorted(struct list_head = *realloc_head, "%s %pR: ignoring failure in optional allocation\n", res_name, res); } - } else if (add_size > 0) { + } else if (add_size > 0 || !IS_ALIGNED(res->start, align)) { res->flags |=3D add_res->flags & (IORESOURCE_STARTALIGN|IORESOURCE_SIZEALIGN); if (pci_reassign_resource(dev, idx, add_size, align)) @@ -1392,12 +1393,13 @@ static void pbus_size_mem(struct pci_bus *bus, unsi= gned long type, =20 resource_set_range(b_res, min_align, size0); b_res->flags |=3D IORESOURCE_STARTALIGN; - if (bus->self && size1 > size0 && realloc_head) { + if (bus->self && realloc_head && (size1 > size0 || add_align > min_align)= ) { b_res->flags &=3D ~IORESOURCE_DISABLED; - add_to_list(realloc_head, bus->self, b_res, size1-size0, add_align); + add_size =3D size1 > size0 ? size1 - size0 : 0; + add_to_list(realloc_head, bus->self, b_res, add_size, add_align); pci_info(bus->self, "bridge window %pR to %pR add_size %llx add_align %l= lx\n", b_res, &bus->busn_res, - (unsigned long long) (size1 - size0), + (unsigned long long) add_size, (unsigned long long) add_align); } } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 19421409EEE; Sat, 28 Feb 2026 17:44:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300658; cv=none; b=px4QbyqNWvsfQllQj6TvaJZ8qRQjLy18rqkUCXe3wMyLLuY+f6v44vqOW8G7mHgjgHHE6aadfcNnAZRr0xN2JZzpFFXcKC1VppDRFGXl9faG3us09j2wsFeYi+TLyvwnBZBvuvKFA3/7NCvuy1t0XJZC4Y0O/GvOdutJvUhlRfA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300658; c=relaxed/simple; bh=NG6KsHGhCYCyBAMOLAxtK7Ymu497bdXMUaieBzxkmTo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YzonH9mgtvuirZ47spfGSHms+iL2rpzTnwGMbrcW67tZhdsKFdajzBheEhfcxNYuAd8hW4VzeVzJBkx0aP/A8nR1EP78h+exXuMJiiN/mqgAww3Z4NWCxI2J+uLevLhB/WTVYQrWPCc2m3UhHgBQPksGhQnLEywyi+9ldBefV/M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iqicOfpq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iqicOfpq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8AACC116D0; Sat, 28 Feb 2026 17:44:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300658; bh=NG6KsHGhCYCyBAMOLAxtK7Ymu497bdXMUaieBzxkmTo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iqicOfpq0RpC3NC8EhxPRqunMDybiIdJ2zGbrnDf2zzsTmyNjAKvx5OrtFQq+TOdU M2J7B29bEwk4xiv7CsZ7tV9L9+nc4rIF5LWWTv1/ISslpLR3J33CVSemrkWFJhsu9m w63clPtkAtWOYNH+dVK7kPVGYxT66MpezR7tcpBB6nQ2jjoFx/sfVyH5IXpnZte6f0 YG9PtXw1exS35yQn0i4KVi1E5KhlOl24psAI+68dFgbCl0zbB5GtFKydfq3ZZNidpz cuTr4id2ekihfXy4qA8P7tqSkMEHLB/k0bMwmmEdmLTa+WWklJ3OruubxnyPCMyORA THu0IHNF47JMw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harshit Mogalapalli , Mimi Zohar , Alexander Graf , Ard Biesheuvel , Borislav Betkov , guoweikang , Henry Willard , "H. Peter Anvin" , Ingo Molnar , Jiri Bohac , Joel Granados , Jonathan McDowell , Mike Rapoport , Paul Webb , Sohil Mehta , Sourabh Jain , Thomas Gleinxer , Yifei Liu , Baoquan He , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 698/844] ima: verify the previous kernel's IMA buffer lies in addressable RAM Date: Sat, 28 Feb 2026 12:30:11 -0500 Message-ID: <20260228173244.1509663-699-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harshit Mogalapalli [ Upstream commit 10d1c75ed4382a8e79874379caa2ead8952734f9 ] Patch series "Address page fault in ima_restore_measurement_list()", v3. When the second-stage kernel is booted via kexec with a limiting command line such as "mem=3D" we observe a pafe fault that happens. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) not-present page This happens on x86_64 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") This patch (of 3): When the second-stage kernel is booted with a limiting command line (e.g. "mem=3D"), the IMA measurement buffer handed over from the previous kernel may fall outside the addressable RAM of the new kernel. Accessing such a buffer can fault during early restore. Introduce a small generic helper, ima_validate_range(), which verifies that a physical [start, end] range for the previous-kernel IMA buffer lies within addressable memory: - On x86, use pfn_range_is_mapped(). - On OF based architectures, use page_is_ram(). Link: https://lkml.kernel.org/r/20251231061609.907170-1-harshit.m.mogalapal= li@oracle.com Link: https://lkml.kernel.org/r/20251231061609.907170-2-harshit.m.mogalapal= li@oracle.com Signed-off-by: Harshit Mogalapalli Reviewed-by: Mimi Zohar Cc: Alexander Graf Cc: Ard Biesheuvel Cc: Borislav Betkov Cc: guoweikang Cc: Henry Willard Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Bohac Cc: Joel Granados Cc: Jonathan McDowell Cc: Mike Rapoport Cc: Paul Webb Cc: Sohil Mehta Cc: Sourabh Jain Cc: Thomas Gleinxer Cc: Yifei Liu Cc: Baoquan He Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/ima.h | 1 + security/integrity/ima/ima_kexec.c | 35 ++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) diff --git a/include/linux/ima.h b/include/linux/ima.h index 8e29cb4e6a01d..abf8923f8fc51 100644 --- a/include/linux/ima.h +++ b/include/linux/ima.h @@ -69,6 +69,7 @@ static inline int ima_measure_critical_data(const char *e= vent_label, #ifdef CONFIG_HAVE_IMA_KEXEC int __init ima_free_kexec_buffer(void); int __init ima_get_kexec_buffer(void **addr, size_t *size); +int ima_validate_range(phys_addr_t phys, size_t size); #endif =20 #ifdef CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/im= a_kexec.c index 5beb69edd12fd..36a34c54de58b 100644 --- a/security/integrity/ima/ima_kexec.c +++ b/security/integrity/ima/ima_kexec.c @@ -12,6 +12,8 @@ #include #include #include +#include +#include #include #include #include "ima.h" @@ -294,3 +296,36 @@ void __init ima_load_kexec_buffer(void) pr_debug("Error restoring the measurement list: %d\n", rc); } } + +/* + * ima_validate_range - verify a physical buffer lies in addressable RAM + * @phys: physical start address of the buffer from previous kernel + * @size: size of the buffer + * + * On success return 0. On failure returns -EINVAL so callers can skip + * restoring. + */ +int ima_validate_range(phys_addr_t phys, size_t size) +{ + unsigned long start_pfn, end_pfn; + phys_addr_t end_phys; + + if (check_add_overflow(phys, (phys_addr_t)size - 1, &end_phys)) + return -EINVAL; + + start_pfn =3D PHYS_PFN(phys); + end_pfn =3D PHYS_PFN(end_phys); + +#ifdef CONFIG_X86 + if (!pfn_range_is_mapped(start_pfn, end_pfn)) +#else + if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) +#endif + { + pr_warn("IMA: previous kernel measurement buffer %pa (size 0x%zx) lies o= utside available memory\n", + &phys, size); + return -EINVAL; + } + + return 0; +} --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9990B409F0B; Sat, 28 Feb 2026 17:44:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300660; cv=none; b=kwnMMKacIZdUppw/22rwxLZCURYTMUNj3dD1Hag/sRt1oMmYuh+KXx6SbJqPiIPKmGKfrcVjnwnl6XI7jRqg55O/zJ+MB9EA//F+fHkbNQ0i8GYcihfGFFHj1FQSmSoikDbPF/K4sof8gNHkmzkh6QguHqvZJDtAd8EYPA+Iins= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300660; c=relaxed/simple; bh=hynepgpAQS62ggttobeYcs2o4UAKAYMz2B4KjnrM9KM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=R7G5O+nAi2UFYlr8O0gQ7Z+jwssJU511GMi5LWzVwtIM93juXZgmDIwiPWI1fg3fen4nJ2d/I6UWNKvPligpd+vyCkB8l0fdm2cUNG+rZwUe8lrITZeYXnPwFmfegGRgdJ7veRGSKrTChuKhp3USs4ppVLkvbDFzqZ3Hs9Sy55o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hlZkXaf7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hlZkXaf7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 435E1C116D0; Sat, 28 Feb 2026 17:44:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300660; bh=hynepgpAQS62ggttobeYcs2o4UAKAYMz2B4KjnrM9KM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hlZkXaf7mKTJL6Zn/WVr+4AcSLnCKi/tHcUHxlcgt1ykv8I4gUBn/qVntJg2yLlAv tVA+XiYGr8y74NM1Ph9GM9cf/seLh8/Mw/YzYEZo6JokHYO2eOnfuCduG3tYVrdmI0 Sft7tmHW6ZcMIfM8iwowFOhhvvkX30ows3n5hSShrGADlJTEEq5PN0bxEyir+23vns fcSSVAnhQhtA/LgwUDTSSw/4INf0OD4z0mkAulQS0jhw9dMCiBAsRl57KBMBEl1ujj 2+X4kPyzU/r9uC/0/acr+hT52B3CynKilx+SQc6KLmj2UjkFtdaM4DYizU1Bcn4j4i yTolKFdimR+Ag== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harshit Mogalapalli , Mimi Zohar , Alexander Graf , Ard Biesheuvel , Baoquan He , Borislav Betkov , guoweikang , Henry Willard , "H. Peter Anvin" , Ingo Molnar , Jiri Bohac , Joel Granados , Jonathan McDowell , Mike Rapoport , Paul Webb , Sohil Mehta , Sourabh Jain , Thomas Gleinxer , Yifei Liu , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 699/844] of/kexec: refactor ima_get_kexec_buffer() to use ima_validate_range() Date: Sat, 28 Feb 2026 12:30:12 -0500 Message-ID: <20260228173244.1509663-700-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harshit Mogalapalli [ Upstream commit 4d02233235ed0450de9c10fcdcf3484e3c9401ce ] Refactor the OF/DT ima_get_kexec_buffer() to use a generic helper to validate the address range. No functional change intended. Link: https://lkml.kernel.org/r/20251231061609.907170-3-harshit.m.mogalapal= li@oracle.com Signed-off-by: Harshit Mogalapalli Reviewed-by: Mimi Zohar Cc: Alexander Graf Cc: Ard Biesheuvel Cc: Baoquan He Cc: Borislav Betkov Cc: guoweikang Cc: Henry Willard Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Bohac Cc: Joel Granados Cc: Jonathan McDowell Cc: Mike Rapoport Cc: Paul Webb Cc: Sohil Mehta Cc: Sourabh Jain Cc: Thomas Gleinxer Cc: Yifei Liu Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/of/kexec.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c index 1ee2d31816aeb..c4cf3552c0183 100644 --- a/drivers/of/kexec.c +++ b/drivers/of/kexec.c @@ -128,7 +128,6 @@ int __init ima_get_kexec_buffer(void **addr, size_t *si= ze) { int ret, len; unsigned long tmp_addr; - unsigned long start_pfn, end_pfn; size_t tmp_size; const void *prop; =20 @@ -144,17 +143,9 @@ int __init ima_get_kexec_buffer(void **addr, size_t *s= ize) if (!tmp_size) return -ENOENT; =20 - /* - * Calculate the PFNs for the buffer and ensure - * they are with in addressable memory. - */ - start_pfn =3D PHYS_PFN(tmp_addr); - end_pfn =3D PHYS_PFN(tmp_addr + tmp_size - 1); - if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) { - pr_warn("IMA buffer at 0x%lx, size =3D 0x%zx beyond memory\n", - tmp_addr, tmp_size); - return -EINVAL; - } + ret =3D ima_validate_range(tmp_addr, tmp_size); + if (ret) + return ret; =20 *addr =3D __va(tmp_addr); *size =3D tmp_size; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13545409F1C; Sat, 28 Feb 2026 17:44:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300663; cv=none; b=SMUuhsJ3x/VWJtlg/qU0K2tAmEwZtcTiwKbBx50l5DjbRnldO7ukX6PASZlt1CF4nsOHDP7swXNhJgvh5p2owb5ryJn9lW+/HPrZK9DDV0ZHg0I+LhT+FDMjDOOZOVSm642bAHeXj7rbD4Bhqft1SjPo78pEHc+sm4IacgHcUUk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300663; c=relaxed/simple; bh=eka7zON3gX8jz16OwPRfwdNq2KwQ6lxsdlOJPMoc0bU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aBp1CbHIDx830Lb/6lV4FmeoEjD/QmuYPPR+O11KiWnPgS7dtPnaWJYR1wouG/w7maoCIzLluT8z/EEI/kMWW0Sxyw0w0ZrjDNfbjfjmebdAojKionFpAEqg0SaJbZImXlafhHh0llRjRp4DNv+V/o7nJ21sWwdShmW7kko0Ths= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eRALPQTB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eRALPQTB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAA47C2BC87; Sat, 28 Feb 2026 17:44:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300663; bh=eka7zON3gX8jz16OwPRfwdNq2KwQ6lxsdlOJPMoc0bU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eRALPQTBEaAXANEo8jzKD7Xll2lxtGbqumutFdi9edD3nyOVq8oIyCZkUd+372DxJ ILh+b6CXBw2QEzBz4o+BjbrQ65ERidKJ33Usm1hcJ8hNXrMiA/vx93cluTMrZpSTip 1/SFWfQ6adfM7+VzHvcF5zTu3mNlBM2ODRqirVPMSCpIFxTZi7weMaCgrWMOpcnKbO cDPlenT61pUrYVOuzMLnEn9FLZOA610k/FwySpHMY6viPellxWpMWDa8ZcIiw5y+NZ MSVmHm8rbjPkjDlkICWNTYD7EDJ0K0FG5YQbBabbe8MM59lLhAJB8mF141tNFv6c09 jYsVLGMGBVgTg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harshit Mogalapalli , Paul Webb , Mimi Zohar , Alexander Graf , Ard Biesheuvel , Baoquan He , Borislav Betkov , guoweikang , Henry Willard , "H. Peter Anvin" , Ingo Molnar , Jiri Bohac , Joel Granados , Jonathan McDowell , Mike Rapoport , Sohil Mehta , Sourabh Jain , Thomas Gleinxer , Yifei Liu , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 700/844] x86/kexec: add a sanity check on previous kernel's ima kexec buffer Date: Sat, 28 Feb 2026 12:30:13 -0500 Message-ID: <20260228173244.1509663-701-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Harshit Mogalapalli [ Upstream commit c5489d04337b47e93c0623e8145fcba3f5739efd ] When the second-stage kernel is booted via kexec with a limiting command line such as "mem=3D", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) =E2=80=93 not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail. Link: https://lkml.kernel.org/r/20251231061609.907170-4-harshit.m.mogalapal= li@oracle.com Signed-off-by: Harshit Mogalapalli Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec= ") Reported-by: Paul Webb Reviewed-by: Mimi Zohar Cc: Alexander Graf Cc: Ard Biesheuvel Cc: Baoquan He Cc: Borislav Betkov Cc: guoweikang Cc: Henry Willard Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Bohac Cc: Joel Granados Cc: Jonathan McDowell Cc: Mike Rapoport Cc: Sohil Mehta Cc: Sourabh Jain Cc: Thomas Gleinxer Cc: Yifei Liu Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/kernel/setup.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 1b2edd07a3e17..383d4a4784f5b 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -439,9 +439,15 @@ int __init ima_free_kexec_buffer(void) =20 int __init ima_get_kexec_buffer(void **addr, size_t *size) { + int ret; + if (!ima_kexec_buffer_size) return -ENOENT; =20 + ret =3D ima_validate_range(ima_kexec_buffer_phys, ima_kexec_buffer_size); + if (ret) + return ret; + *addr =3D __va(ima_kexec_buffer_phys); *size =3D ima_kexec_buffer_size; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2EDAD492537; Sat, 28 Feb 2026 17:44:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300664; cv=none; b=JsUBNLBpZ68wBdtHzO1EglwiBRLs/NvyAZCUsTMULuPbDFaBIbgZL5XaJj4n0Q/ZCMizTcHdIDzON1E4iOQ+2WIz39i5vl44OgNiboSLRNaAxt1f0696Fj4RruhrFx/14ABOS25eaQiAbhqadjvIWOy+8+1o+6lY/++GA8ypBuk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300664; c=relaxed/simple; bh=l6graGhs00TKyzQLpbf68cfiC+x52l/KmoX1tNaXKPE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Z+Gg+oATAqeFwEAI5p2MI8ljrLZzQT0X/+00ogLziC52sQ9zbKK8yEAS12NPo4V62QLYtcMHPlVJBzSqNvsHqEOEGbBEo2UntMPNXNYUcP9Cn2Ex+KbEFmLYMW+3tUBYxr53Z4XptEeFQT6E1nDod0JVY/an+UnMHNSinILXhe0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kCKXmY32; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kCKXmY32" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AAE9C116D0; Sat, 28 Feb 2026 17:44:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300664; bh=l6graGhs00TKyzQLpbf68cfiC+x52l/KmoX1tNaXKPE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kCKXmY32G/PoOXBn4L62OS3iVA+azj7WYaiVal6b3xvmV8NMa190WNTyQfjZ9xjaw YZ/mjfkpFLwZUnseSK874Kl6H4SbkRktYJ+vS1jz+Q9YBSbu1kr/xnBqHCq8eR6RG+ KYIXHqzryhZGyYKwCAye0JWdTcB4SthN0PQpfzETVt7sfu3NrhLMk3Xqw+Zn7gJtRs Yvyf62rdt9qpkTFfqN57uWAK5Z+lXBwJGVEzOSQpvFlXT/h/M5aXg7QlR5lr1mUOMc JmdiPa4o4YcRQNccv/ohgvngHseLyxMuCN1GedDO97ta6eSf8AAKK4d2x9nY8lDJW1 PrBRCPNLTzzsA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Deepanshu Kartikey , syzbot+d8d4c31d40f868eaea30@syzkaller.appspotmail.com, Uladzislau Rezki , Hillf Danton , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 701/844] mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node Date: Sat, 28 Feb 2026 12:30:14 -0500 Message-ID: <20260228173244.1509663-702-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Deepanshu Kartikey [ Upstream commit 5747435e0fd474c24530ef1a6822f47e7d264b27 ] When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks. Processing a large purge_list without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions. The issue manifests in purge_vmap_node() -> kasan_release_vmalloc_node() where iterating through hundreds or thousands of vmap_area entries and freeing their associated shadow pages causes: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l ... task:kworker/0:17 state:R running task stack:28840 pid:6229 ... kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299 purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299 Each call to kasan_release_vmalloc() can free many pages, and with page_owner tracking, each free triggers save_stack() which performs stack unwinding under RCU read lock. Without yielding, this creates an unbounded RCU critical section. Add periodic cond_resched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed The fix uses need_resched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load. Link: https://lkml.kernel.org/r/20260112103612.627247-1-kartikey406@gmail.c= om Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+d8d4c31d40f868eaea30@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Dd8d4c31d40f868eaea30 Link: https://lore.kernel.org/all/20260112084723.622910-1-kartikey406@gmail= .com/T/ [v1] Suggested-by: Uladzislau Rezki Reviewed-by: Uladzislau Rezki (Sony) Cc: Hillf Danton Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/vmalloc.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index e286c2d2068cb..ea24ee957605e 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2268,11 +2268,14 @@ decay_va_pool_node(struct vmap_node *vn, bool full_= decay) reclaim_list_global(&decay_list); } =20 +#define KASAN_RELEASE_BATCH_SIZE 32 + static void kasan_release_vmalloc_node(struct vmap_node *vn) { struct vmap_area *va; unsigned long start, end; + unsigned int batch_count =3D 0; =20 start =3D list_first_entry(&vn->purge_list, struct vmap_area, list)->va_s= tart; end =3D list_last_entry(&vn->purge_list, struct vmap_area, list)->va_end; @@ -2282,6 +2285,11 @@ kasan_release_vmalloc_node(struct vmap_node *vn) kasan_release_vmalloc(va->va_start, va->va_end, va->va_start, va->va_end, KASAN_VMALLOC_PAGE_RANGE); + + if (need_resched() || (++batch_count >=3D KASAN_RELEASE_BATCH_SIZE)) { + cond_resched(); + batch_count =3D 0; + } } =20 kasan_release_vmalloc(start, end, start, end, KASAN_VMALLOC_TLB_FLUSH); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7396140A8FC; Sat, 28 Feb 2026 17:44:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300665; cv=none; b=A5QcILoDcuMKaXygHTm3FUS8OYrTg/WG5/Tqi96Wnf9h2MBt7l4gbx7QvVZWpDVcxA3C43ZVDWaS3qOCgeSbkuSbjEX/FX+fWUe6WpEN4yRI13ZeXKslA53y1rA9kAq8gV6TZTKe+0mSlIl+5EKlaKPBjiUhmbY1c3z7r/0QzXk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300665; c=relaxed/simple; bh=JSxcDFknxS5iM5aU8le0mweKjNJSX/1pheTt1QFMtgk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d65/z9HUar2m6WUbXAMcwbxVq03x95K4RPYshQbt39M/hICenqZNH8Nfg016u3OH7KuDj/uGtur+PL0O1kh7rVAS60eNp/bVHvUFPVfQY31jhmXHpEPFmFd1K9QXhDLU1q0JybqwE/1be6RZVuL1pJArHZY/UBaIp88EpSuLB/Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DUnAx/va; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DUnAx/va" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 565B0C116D0; Sat, 28 Feb 2026 17:44:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300665; bh=JSxcDFknxS5iM5aU8le0mweKjNJSX/1pheTt1QFMtgk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DUnAx/vaprACkiCRMNwZtWNg/5cqdC0jvCDGL7Br4LdCRsW5XX/u1nszPRA2v2qKL CZewt/KjgXMRLFU8651g9Ppj6r38E43nJJmvHaoKKkLiYirW45CvfcjyQlohzFnvTJ TPIU8c0rjuDJsTyVvsEFMp+SCfof3nUxR8bt14hUl6GuW/2m1VuiIbcqlZMVHwLgBl pdmbWZTDbhQdfurLbS3ziEiMJAUA8hog/C/huXsQRkCkXZDoXZPwg9SFIahz0khC/a E9WsLOk2HnSpEoZJ8AXVNRznuVpRupwKhICWRgZUJFHPveSM+2gw6FK7/Mvgo2eiBS ju8RF9TZAx0+A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haotien Hsu , stable , Wayne Chang , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 702/844] usb: gadget: tegra-xudc: Add handling for BLCG_COREPLL_PWRDN Date: Sat, 28 Feb 2026 12:30:15 -0500 Message-ID: <20260228173244.1509663-703-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haotien Hsu [ Upstream commit 1132e90840abf3e7db11f1d28199e9fbc0b0e69e ] The COREPLL_PWRDN bit in the BLCG register must be set when the XUSB device controller is powergated and cleared when it is unpowergated. If this bit is not explicitly controlled, the core PLL may remain in an incorrect power state across suspend/resume or ELPG transitions. Therefore, update the driver to explicitly control this bit during powergate transitions. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mod= e controller") Cc: stable Signed-off-by: Haotien Hsu Signed-off-by: Wayne Chang Link: https://patch.msgid.link/20260123173121.4093902-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/usb/gadget/udc/tegra-xudc.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/udc/tegra-xudc.c b/drivers/usb/gadget/udc/t= egra-xudc.c index 9d2007f448c04..7f7251c10e952 100644 --- a/drivers/usb/gadget/udc/tegra-xudc.c +++ b/drivers/usb/gadget/udc/tegra-xudc.c @@ -3392,17 +3392,18 @@ static void tegra_xudc_device_params_init(struct te= gra_xudc *xudc) { u32 val, imod; =20 + val =3D xudc_readl(xudc, BLCG); if (xudc->soc->has_ipfs) { - val =3D xudc_readl(xudc, BLCG); val |=3D BLCG_ALL; val &=3D ~(BLCG_DFPCI | BLCG_UFPCI | BLCG_FE | BLCG_COREPLL_PWRDN); val |=3D BLCG_IOPLL_0_PWRDN; val |=3D BLCG_IOPLL_1_PWRDN; val |=3D BLCG_IOPLL_2_PWRDN; - - xudc_writel(xudc, val, BLCG); + } else { + val &=3D ~BLCG_COREPLL_PWRDN; } + xudc_writel(xudc, val, BLCG); =20 if (xudc->soc->port_speed_quirk) tegra_xudc_limit_port_speed(xudc); @@ -3953,6 +3954,7 @@ static void tegra_xudc_remove(struct platform_device = *pdev) static int __maybe_unused tegra_xudc_powergate(struct tegra_xudc *xudc) { unsigned long flags; + u32 val; =20 dev_dbg(xudc->dev, "entering ELPG\n"); =20 @@ -3965,6 +3967,10 @@ static int __maybe_unused tegra_xudc_powergate(struc= t tegra_xudc *xudc) =20 spin_unlock_irqrestore(&xudc->lock, flags); =20 + val =3D xudc_readl(xudc, BLCG); + val |=3D BLCG_COREPLL_PWRDN; + xudc_writel(xudc, val, BLCG); + clk_bulk_disable_unprepare(xudc->soc->num_clks, xudc->clks); =20 regulator_bulk_disable(xudc->soc->num_supplies, xudc->supplies); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 79E7240A915; Sat, 28 Feb 2026 17:44:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300666; cv=none; b=gHVN5qscXkt8vdyaK0UaUpxQs+1n6rJsaJa2UQiaDuCF5+uIDx8p8tB7qpkn5zE5FLwEJRIgwOxd5SipWc7JYYO3f5hu8MpWtGZjXoFHtWpOmYL7BvTG+cW7Fn1nQD2SHnLa90ZQfsgwuC+iJ+oYJbJXXSlL+DqsIZRN6tTNYD4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300666; c=relaxed/simple; bh=kpHZapoyxabCm6cAD/gUJE9UyGbJ8uuPHKnXTWN8fPg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=StylydX5bMXTUxC+/3K83rbPc5O2sYwqI0ZfalI10IM8fzsZnUjNhYgVMSa+8Md12quq9ZYTqC4un0XhitsDkUR4U7NtjxUzAhkqAidVHRawv2yI0+3YOxKy3WlztO6bmjWMno1bAjmIb6tOj5GxuZuK3/uxZ930J2MHaJgrCOE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qcEH5xr2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qcEH5xr2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DD4CC19425; Sat, 28 Feb 2026 17:44:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300666; bh=kpHZapoyxabCm6cAD/gUJE9UyGbJ8uuPHKnXTWN8fPg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qcEH5xr2DbbCWbbKYievTbbKZt86/GnntqcxmyqsYUeX0eZZcRf0SG8ZVEzQ4t0u+ eAhfLSWSdw5Q/KlNsoHhci4D1rUH+2/H576OKC7OXx+eTxTUnHU8hLs/Sf4kkCb0CP 0WFBRj2ClVubNYPiU9ci8cCFpxLTjgDMOczA2vgCFTc+6/ToRKOzW99P6lbAiBOXc5 X2ZxPwM771CX1lpcZT3KE/rKqwbfipk8947lARQK6E9PdK8thF0oJBA80YfqGN2FCH AKpdtSHLB+hpLR02bflQvG6yfNATGrCziPYf5CEl6hzVc3GUR1gQFZTh9w8ridosW1 6vRc1RGC6IVXg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vlastimil Babka , kernel test robot , Harry Yoo , Suren Baghdasaryan , "Liam R. Howlett" , Sasha Levin Subject: [PATCH 6.19 703/844] mm/slab: add rcu_barrier() to kvfree_rcu_barrier_on_cache() Date: Sat, 28 Feb 2026 12:30:16 -0500 Message-ID: <20260228173244.1509663-704-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vlastimil Babka [ Upstream commit b55b423e8518361124ff0a9e15df431b3682ee4f ] After we submit the rcu_free sheaves to call_rcu() we need to make sure the rcu callbacks complete. kvfree_rcu_barrier() does that via flush_all_rcu_sheaves() but kvfree_rcu_barrier_on_cache() doesn't. Fix that. This currently causes no issues because the caches with sheaves we have are never destroyed. The problem flagged by kernel test robot was reported for a patch that enables sheaves for (almost) all caches, and occurred only with CONFIG_KASAN. Harry Yoo found the root cause [1]: It turns out the object freed by sheaf_flush_unused() was in KASAN percpu quarantine list (confirmed by dumping the list) by the time __kmem_cache_shutdown() returns an error. Quarantined objects are supposed to be flushed by kasan_cache_shutdown(), but things go wrong if the rcu callback (rcu_free_sheaf_nobarn()) is processed after kasan_cache_shutdown() finishes. That's why rcu_barrier() in __kmem_cache_shutdown() didn't help, because it's called after kasan_cache_shutdown(). Calling rcu_barrier() in kvfree_rcu_barrier_on_cache() guarantees that it'll be added to the quarantine list before kasan_cache_shutdown() is called. So it's a valid fix! [1] https://lore.kernel.org/all/aWd6f3jERlrB5yeF@hyeyoo/ Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202601121442.c530bed3-lkp@intel.com Fixes: 0f35040de593 ("mm/slab: introduce kvfree_rcu_barrier_on_cache() for = cache destruction") Cc: stable@vger.kernel.org Reviewed-by: Harry Yoo Tested-by: Harry Yoo Reviewed-by: Suren Baghdasaryan Reviewed-by: Liam R. Howlett Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/slab_common.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index eed7ea556cb1a..ee994ec7f251e 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -2133,8 +2133,11 @@ EXPORT_SYMBOL_GPL(kvfree_rcu_barrier); */ void kvfree_rcu_barrier_on_cache(struct kmem_cache *s) { - if (s->cpu_sheaves) + if (s->cpu_sheaves) { flush_rcu_sheaves_on_cache(s); + rcu_barrier(); + } + /* * TODO: Introduce a version of __kvfree_rcu_barrier() that works * on a specific slab cache. --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1911649253A; Sat, 28 Feb 2026 17:44:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300667; cv=none; b=h8ZhSMQ84mN2oZaqAhso7IWamRghDYOQYurWoR9+9gcZD2cMgKTdKKCQYaF6kB45dNP9ok34zUi8KXM0pW3aWb6/geJs1cwLSjAZRjKgUgjlzjkD3/csqfotSF4GzcA7Kr95AXttFIzBAEqfwtrU1ShC2/mYtr89wIc05bi8dpU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300667; c=relaxed/simple; bh=w5jgtz5DSWUWiVF2tlEtWyl1qNtrBDZobr0H7JY9hkM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ixxy/Jt4BuTYA+QiHMm6wOISr568pSsNLklEwdwxQeXbH94r6/DIcRb98Pt5C7Np67AzthrkhLh8B6ut/ofr+lyVs03VAP3jDtLcca1ckDQ7CMycp/osZrSHFPg/BO+Ybl6zM9DBBa5QgLXNPr78713R0PopPfGen1eAvq93khc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WAJOqkwU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WAJOqkwU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BDFBC116D0; Sat, 28 Feb 2026 17:44:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300667; bh=w5jgtz5DSWUWiVF2tlEtWyl1qNtrBDZobr0H7JY9hkM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WAJOqkwU6xkg0qgytiA6LOk1xIHt9sG5SfKbLQvNv27LKDHJTe0SV4WSix3Vpo4wU n8/61hxheYRO2uwn1bsnfeeNDC0qa098drqkw8CJ+qmRIESnyF75l2qzaogJUi+UdV 01SCOcbFB2XLGjTz8w6twdAZdb6aVJ/+JjAwGyUI3OZFuiX9sX8OkzXVH618U1w01l 6yIWvj4YZb48DjVbwqxEa3ukDhwOwN1lZNU6rG2NIiuzBBF4S8v0bTevsx2/KBf6/C Tuld0/F+sIwUe9HXKpqcSSO5k9jNthXUAXBpCoC1kVVDP5GIuSxLw4HeFahH29tEqs YhLn7tqQDYq/Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jens Axboe , Sasha Levin Subject: [PATCH 6.19 704/844] io_uring/net: don't continue send bundle if poll was required for retry Date: Sat, 28 Feb 2026 12:30:17 -0500 Message-ID: <20260228173244.1509663-705-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jens Axboe [ Upstream commit 806ae939c41e5da1d94a1e2b31f5702e96b6c3e3 ] If a send bundle has picked a bunch of buffers, then it needs to send all of those to be complete. This may require poll arming, if the send buffer ends up being full. Once a send bundle has been poll armed, no further bundles should be attempted. This allows a current bundle to complete even though it needs to go through polling to do so, but it will not allow another bundle to be started once that has happened. Ideally we would abort a bundle if it was only partially sent, but as some parts of it already went out on the wire, this obviously isn't feasible. Not continuing more bundle attempts post encountering a full socket buffer is the second best thing. Cc: stable@vger.kernel.org Fixes: a05d1f625c7a ("io_uring/net: support bundles for send") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/net.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/io_uring/net.c b/io_uring/net.c index 519ea055b7619..d9a4b83804a25 100644 --- a/io_uring/net.c +++ b/io_uring/net.c @@ -515,7 +515,11 @@ static inline bool io_send_finish(struct io_kiocb *req, =20 cflags =3D io_put_kbufs(req, sel->val, sel->buf_list, io_bundle_nbufs(kms= g, sel->val)); =20 - if (bundle_finished || req->flags & REQ_F_BL_EMPTY) + /* + * Don't start new bundles if the buffer list is empty, or if the + * current operation needed to go through polling to complete. + */ + if (bundle_finished || req->flags & (REQ_F_BL_EMPTY | REQ_F_POLLED)) goto finish; =20 /* --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 404B136309F; Sat, 28 Feb 2026 17:44:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300668; cv=none; b=JIob8LDdJWGiRtvp8lObklDNz1PbXPjf+5pK2UssV5NebsiDLHY955yQrJM4NOVfDUmzQyjSEHhNldhL6IQnSi5qmyOmDjohBUdmyxRowmC3B8JOsXhhKfpG+075k8Ejrg+dpYHMKg+X+eABRUjNXfIefoG5x4+2cUhvTTSl2zw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300668; c=relaxed/simple; bh=u2kxPBOwOLkphVOpPpRhqeDwmrywy8m72tKElHpBxYI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gbT8h/q+0BYXD7z6OR6Tnjs3B2LqugUlt2iD0JHwiRDhWCSfzcNS65CmkdeKJkz1uIeDaDBqmPsk59c9H4fwW8Zq9Z0mQxNGhx9kaiDgTNAQtSwuIANJvkaQsNAIdHBbNVeWIiWsLgEQ1wg4gtI4AT99bpQW23V+kRwNb7bb2RE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Am6GDfwG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Am6GDfwG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40AA4C19423; Sat, 28 Feb 2026 17:44:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300668; bh=u2kxPBOwOLkphVOpPpRhqeDwmrywy8m72tKElHpBxYI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Am6GDfwGOSFMtxWCx4iAnNPewW4BLx/DF0voA0hv4d5lQYwyUze1YBLn9RiJOrqTy 4aIydoRxXTFlg4046gCtXMXaridYZThgpdS6Ik5+svajHlbC/e+gHNs9GS4qZsPIpX iNDiSblcl2nGPytSFlSa4sAEWm5OEgAhGnCcfF0vmSg4vgDMQ0a6IHJEoaEiMWKjDk trkdlv51yo7vxGFCmQ8l2ilZsdnG8Q1v0qL9YMaIEA0ckTX9zzO+YBl+9hUvt5vCf5 2PMQ2OpSX4AyqawjcmQkbLqkBsaEfPKbsOkywjZq9VbcDLj1VAPwcxCjcN1u86H+o4 4oh1e5bemzSFg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Dan Carpenter , Su Hui , "Christophe Leroy (CS GROUP)" , Ioana Ciornei , Sasha Levin Subject: [PATCH 6.19 705/844] bus: fsl-mc: fix an error handling in fsl_mc_device_add() Date: Sat, 28 Feb 2026 12:30:18 -0500 Message-ID: <20260228173244.1509663-706-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit 52f527d0916bcdd7621a0c9e7e599b133294d495 ] In fsl_mc_device_add(), device_initialize() is called first. put_device() should be called to drop the reference if error occurs. And other resources would be released via put_device -> fsl_mc_device_release. So remove redundant kfree() in error handling path. Fixes: bbf9d17d9875 ("staging: fsl-mc: Freescale Management Complex (fsl-mc= ) bus driver") Cc: stable@vger.kernel.org Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/b767348e-d89c-416e-acea-1ebbff3bea20@st= anley.mountain/ Signed-off-by: Su Hui Suggested-by: Christophe Leroy (CS GROUP) Signed-off-by: Haoxiang Li Reviewed-by: Ioana Ciornei Link: https://lore.kernel.org/r/20260124102054.1613093-1-lihaoxiang@isrc.is= cas.ac.cn Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/bus/fsl-mc/fsl-mc-bus.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bu= s.c index a97baf2cbcdd5..eb7b6c0ba9e7c 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -909,11 +909,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, return 0; =20 error_cleanup_dev: - kfree(mc_dev->regions); - if (mc_bus) - kfree(mc_bus); - else - kfree(mc_dev); + put_device(&mc_dev->dev); =20 return error; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 152463630BB; Sat, 28 Feb 2026 17:44:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300669; cv=none; b=SjgIunLjwha9rpId+H/f1soY8n4IK5K42+rpgu18SHlhAF3Q1/QPuqh5bqK3s0N/2C5FQSM8iDCJHNI7y9+VErKIgJKiqsfklOX+IeJ+LGhji7TZA623qCWvjaZmKWQT3YVnJLm2WgwI7DlBR7bwF1oiYN4lqM3zNzXSRg8AB28= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300669; c=relaxed/simple; bh=5DCS3A7t+tTiclp/u9V8WFYtNQXqWmziwsQZxT7F0Kw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cgW+ENLUVR6mNZofit7dVYkW/Yi1S39EP63MgkSmMtIxipK4Ykk97xcG9QneRLYhy+1Lp7XNWY26En4nG7WEkBwuHWu6OGXu+nL7fzcw5fkzQN9UAmrlpdVHS1Hf4MeJD0DCgI3LnFY3cgQpVzmCnV+YWbJcWYDfSkGC/L0hdk4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HdMCoolS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HdMCoolS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F711C116D0; Sat, 28 Feb 2026 17:44:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300669; bh=5DCS3A7t+tTiclp/u9V8WFYtNQXqWmziwsQZxT7F0Kw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HdMCoolS5Mn6G7fCnTX3fxSKg1IAZk5TotoiybMOhA6mNtRmkLep0t9or+b66ctIB 4oOoQCuaQkedpyVwJ0ekwCSHs9R2zBY6XNFbVvEKQrz8ZBe5YK5esXsndsBB/RiHFW HYSgNZ3OVgBl8Wv2JYArqo+/AYS98w34uSzCWkDwIQbZDX+ohPfgXDZC6zpBKVCRp+ GCA3aX1kzQyQBQjiFyqfOHvYR5ACFzFnlTl8IgBVdcGR/e6Eoa/S8vxlkVrbp5cpT8 JBotM2alN0iPy4BWMjLEeUnQSd4w2042KG6MtatIJAr0J9KPfOJaiVNg5CeharNgLH vnOQHfgoZP3qA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Marzinski , Mikulas Patocka , Sasha Levin Subject: [PATCH 6.19 706/844] dm mpath: Add missing dm_put_device when failing to get scsi dh name Date: Sat, 28 Feb 2026 12:30:19 -0500 Message-ID: <20260228173244.1509663-707-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Marzinski [ Upstream commit 787bd63ee661b0148ce8e1fde92b7afddd85c446 ] When commit fd81bc5cca8f ("scsi: device_handler: Return error pointer in scsi_dh_attached_handler_name()") added code to fail parsing the path if scsi_dh_attached_handler_name() failed with -ENOMEM, it didn't clean up the reference to the path device that had just been taken. Fix this, and steamline the error paths of parse_path() a little. Fixes: fd81bc5cca8f ("scsi: device_handler: Return error pointer in scsi_dh= _attached_handler_name()") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-mpath.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c index d5d6ef7ba8381..b739894f01807 100644 --- a/drivers/md/dm-mpath.c +++ b/drivers/md/dm-mpath.c @@ -960,27 +960,27 @@ static struct pgpath *parse_path(struct dm_arg_set *a= s, struct path_selector *ps attached_handler_name =3D NULL; } else { r =3D PTR_ERR(attached_handler_name); - goto bad; + ti->error =3D "error allocating handler name"; + goto bad_put_device; } } if (attached_handler_name || m->hw_handler_name) { INIT_DELAYED_WORK(&p->activate_path, activate_path_work); r =3D setup_scsi_dh(p->path.dev->bdev, m, &attached_handler_name, &ti->e= rror); kfree(attached_handler_name); - if (r) { - dm_put_device(ti, p->path.dev); - goto bad; - } + if (r) + goto bad_put_device; } =20 r =3D ps->type->add_path(ps, &p->path, as->argc, as->argv, &ti->error); - if (r) { - dm_put_device(ti, p->path.dev); - goto bad; - } + if (r) + goto bad_put_device; =20 return p; - bad: + +bad_put_device: + dm_put_device(ti, p->path.dev); +bad: free_pgpath(p); return ERR_PTR(r); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1AEC440BDAA; Sat, 28 Feb 2026 17:44:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300670; cv=none; b=YTHDOIOTq+DdZwkRUbDaFdP9vLHcS4zk7MPKRe9GgC8OQWnnRkThb19uOt6tC7dr8kFaIwqIAN/UNv0zKQtFvoA/owk8xaUpY0ST6THfzVuVFnOuD9ohS+9LG4djFr1jCMf/RAifPhDCbNa/Pouu17EeWAn9SThxZSbp2cj6tf0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300670; c=relaxed/simple; bh=wkeDulKa8F111M35HYlkOg2bAaaqRdcXiuwCNUn7jwg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SRB+FnMR+zmEmK0hKRxCoMTkyqOJxz62EfqKith6Ajx23Cf0nXGj4CgmFNeGIwu0/sLkh+jpYhgFH0ucW/b51ztyazQh03gd1W86lVEstR0v1X4XDXW/gqiaWFj0UYCOEYKRpnImxnIZQ7Hf0/DTD9cmG69Ih2r9fYeVQ6tzOgs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K1heH1P3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K1heH1P3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B414C116D0; Sat, 28 Feb 2026 17:44:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300669; bh=wkeDulKa8F111M35HYlkOg2bAaaqRdcXiuwCNUn7jwg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K1heH1P3KJykwgxdhQ5aFca1Vx7BV2ITypLeUymu2Mkx5qkpha6bWs5drDrOjhd19 0KKljnKethFWSfPW4yaUKuuv0co/7tXtiWppY4VAdUfq3iurT3FLlv62euYngFPVon am7ytTfRo07rXDy+itJiFDLPMK9x21QzI1uw8TJPQMNyLJ1n+tty/77dwV+qVan6cY bboXEutCMr9aLbYisT4WqsCwdN65YTnglrEbMVsn80z+NGtsQ8PowpzNU2XPwMc8Ci 2XGhEfqBizJnpiDjH0JcyjWG/jRnwP1/NwRsmjibR1wwUaX79DrKYfXUxZO1RE4Kph D0fG+L/A60P8g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Marzinski , Sasha Levin Subject: [PATCH 6.19 707/844] dm mpath: make pg_init_delay_msecs settable Date: Sat, 28 Feb 2026 12:30:20 -0500 Message-ID: <20260228173244.1509663-708-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Marzinski [ Upstream commit 218b16992a37ea97b9e09b7659a25a864fb9976f ] "pg_init_delay_msecs X" can be passed as a feature in the multipath table and is used to set m->pg_init_delay_msecs in parse_features(). However, alloc_multipath_stage2(), which is called after parse_features(), resets m->pg_init_delay_msecs to its default value. Instead, set m->pg_init_delay_msecs in alloc_multipath(), which is called before parse_features(), to avoid overwriting a value passed in by the table. Signed-off-by: Benjamin Marzinski Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/md/dm-mpath.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c index b739894f01807..aa9a88a9aa768 100644 --- a/drivers/md/dm-mpath.c +++ b/drivers/md/dm-mpath.c @@ -225,6 +225,7 @@ static struct multipath *alloc_multipath(struct dm_targ= et *ti) mutex_init(&m->work_mutex); =20 m->queue_mode =3D DM_TYPE_NONE; + m->pg_init_delay_msecs =3D DM_PG_INIT_DELAY_DEFAULT; =20 m->ti =3D ti; ti->private =3D m; @@ -251,7 +252,6 @@ static int alloc_multipath_stage2(struct dm_target *ti,= struct multipath *m) set_bit(MPATHF_QUEUE_IO, &m->flags); atomic_set(&m->pg_init_in_progress, 0); atomic_set(&m->pg_init_count, 0); - m->pg_init_delay_msecs =3D DM_PG_INIT_DELAY_DEFAULT; init_waitqueue_head(&m->pg_init_wait); init_waitqueue_head(&m->probe_wait); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EAF9640BDC5; Sat, 28 Feb 2026 17:44:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300671; cv=none; b=kaX+B+1N1zzRPhFQMivRCRTK8II/OWI5b6vhHWErNLpGzOThqYxlqtsaOz1WmrW7qFtH+icnyzz5s7vvRrWCwOF1iVBlkB9NlDPLsVPEK4COhYrKTSzMJFw4Axu0gWtSOwVaCLuP0JIsSaBkel9mSK3J6SN2vB0N4ErMEFmoqTY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300671; c=relaxed/simple; bh=R4y3wwuLIU2aPt/uQFe46IIl65jyVzKx2e0SZu1jYeg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ofYN07GPfTj0ND4jFUWXGj2TobQ+B8Om7e3QGTLfxnDnFKOrtI4DaZEET160S3ZOfPReof2jPibjgH1z+oF85vsHUhLiY05hWnPud43vd/FpfOVzuMHJ1uCKHksw5DlxBWVXxzbUQFCDG1NLbLSHTgpccS3PdFOHOlS6SYv5HEE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=udNrmW6h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="udNrmW6h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 016FEC19425; Sat, 28 Feb 2026 17:44:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300670; bh=R4y3wwuLIU2aPt/uQFe46IIl65jyVzKx2e0SZu1jYeg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=udNrmW6h98iTcRlb+8L/jx0nS/94NO2KMkkNqAn2Ov+JqqCRnIi9Xoe4V8b8pm/3N Dcs+TP0P3r127Ts19HMi51cn2wCV7nLaUZur3Y2kHkDJHMN52pcSqty8L2T0QBXKzF gUl3ZsFOlKSasNz2sVUFyPhnvzhWVPOkiysmcD0d7nhKqn3Y6nrmclpxR2Cj8eOQNp ENZKUUSexdlR5FhK9jCIK1yZar5oTzEFyisrqlANpZPe6sjJ3BMoxgXu0gj8mUnaQ3 x0KGTxz/hg1nmP2ePJJjdTtiqzJ9XzsqG+lEzcXIXE/ayFo3W+EGDXZzuz9c7gxUb4 83xKkLhxs0LMQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Joey Gouly , David Spickett , Kevin Brodsky , Mark Rutland , Will Deacon , Sasha Levin Subject: [PATCH 6.19 708/844] arm64: poe: fix stale POR_EL0 values for ptrace Date: Sat, 28 Feb 2026 12:30:21 -0500 Message-ID: <20260228173244.1509663-709-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Joey Gouly [ Upstream commit 1f3b950492db411e6c30ee0076b61ef2694c100a ] If a process wrote to POR_EL0 and then crashed before a context switch happened, the coredump would contain an incorrect value for POR_EL0. The value read in poe_get() would be a stale value left in thread.por_el0. = Fix this by reading the value from the system register, if the target thread is= the current thread. This matches what gcs/fpsimd do. Fixes: 175198199262 ("arm64/ptrace: add support for FEAT_POE") Reported-by: David Spickett Cc: stable@vger.kernel.org Signed-off-by: Joey Gouly Cc: Kevin Brodsky Cc: Mark Rutland Reviewed-by: Kevin Brodsky Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/kernel/ptrace.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index 6c5ff6807d4cc..64ff87f023113 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -1484,6 +1484,9 @@ static int poe_get(struct task_struct *target, if (!system_supports_poe()) return -EINVAL; =20 + if (target =3D=3D current) + current->thread.por_el0 =3D read_sysreg_s(SYS_POR_EL0); + return membuf_write(&to, &target->thread.por_el0, sizeof(target->thread.por_el0)); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D4204949E5; Sat, 28 Feb 2026 17:44:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300672; cv=none; b=Qa+q+AyvJ4dSncgcYCX9oIrTzZ9TMb5qe5rV59lNl9e7TTQoRIJobj537f89+md/UkXI+A+WfXR0O0W2iXopLgKmb16j1D0DuVfWiOC+PaEb0Mr4VbYIH+w6gkMqWRzw+351Kin6Yvh/ZzQ9WCIxGtivd7zZ1D+NmXS55SgkUJA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300672; c=relaxed/simple; bh=W6W7FBTM2KboxMZEwq13+hDQwWbf3XoBnHsc68k/l1k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aM2zw+053FzVuFm6RJk9TbzkEuoyuZCPJijBU9gR5gW/VBUdVx9V5/GVm0HyTbKxATL7axjV7ufUr6rxXU6/O8CPzh9dBdham7p21APKgWFffxKspQh54RBw/6EA3tN9oGHFVU6Pvbu9zAWb5k+dkyQqytUgl+U0X8/JbMvs6eY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Jt6xUg4K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Jt6xUg4K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D648C116D0; Sat, 28 Feb 2026 17:44:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300672; bh=W6W7FBTM2KboxMZEwq13+hDQwWbf3XoBnHsc68k/l1k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Jt6xUg4Kdg+IxrJK7QROuVyjKFUA5EA2dXl3B7IjZ90YqjhYduttK9Bu0Rf/WU/zo rkhIf4zrYNNnwODVeRC+lSzN1E+5+7mWBszV3bgIlwZe3AzUsA0AAStl8BmqSr0MW8 a0SVwLCGSojNw2YBLM9mZ4AeXLaeP7zbAsVbybxi1Vev51nsoaGvKQbeF1kzFyzZKf oS2uRrd0eMk6/sC1mIRXQgrDtkb6F6cv/tHqM4l8uGGEzp1vLUZtLnNscIZCFZkBQg 81B3jAg4xaq8Kh4TDh8uNJlP/xPL43UNVvvtSNagTbekPzLgsCNW8ciYX1kBz0o/Cu kVKjo8Kng0Xvw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Leo Yan , Hamza Mahfooz , Thomas Voegtle , Greg Kroah-Hartman , Ian Rogers , James Clark , Namhyung Kim , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 6.19 709/844] tools: Fix bitfield dependency failure Date: Sat, 28 Feb 2026 12:30:22 -0500 Message-ID: <20260228173244.1509663-710-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Leo Yan [ Upstream commit a537c0da168a08b0b6a7f7bd9e75f4cc8d45ff57 ] A perf build failure was reported by Thomas Voegtle on stable kernel v6.6.120: CC tests/sample-parsing.o CC util/intel-pt-decoder/intel-pt-pkt-decoder.o CC util/perf-regs-arch/perf_regs_csky.o CC util/arm-spe-decoder/arm-spe-pkt-decoder.o CC util/perf-regs-arch/perf_regs_loongarch.o In file included from util/arm-spe-decoder/arm-spe-pkt-decoder.h:10, from util/arm-spe-decoder/arm-spe-pkt-decoder.c:14: /local/git/linux-stable-rc/tools/include/linux/bitfield.h: In function = =E2=80=98le16_encode_bits=E2=80=99: /local/git/linux-stable-rc/tools/include/linux/bitfield.h:166:31: error: = implicit declaration of function =E2=80=98cpu_to_le16=E2=80=99; did you mean =E2=80=98htole16=E2= =80=99? [-Werror=3Dimplicit-function-declaration] ____MAKE_OP(le##size,u##size,cpu_to_le##size,le##size##_to_cpu) \ ^~~~~~~~~ /local/git/linux-stable-rc/tools/include/linux/bitfield.h:149:9: note: in= definition of macro =E2=80=98____MAKE_OP=E2=80=99 return to((v & field_mask(field)) * field_multiplier(field)); \ ^~ /local/git/linux-stable-rc/tools/include/linux/bitfield.h:170:1: note: in= expansion of macro =E2=80=98__MAKE_OP=E2=80=99 __MAKE_OP(16) Fix this by including linux/kernel.h, which provides the required definitions. The issue was not found on the mainline due to the relevant C files have included kernel.h. It'd be good to merge this change on mainline as well for robustness. Closes: https://lore.kernel.org/stable/3a44500b-d7c8-179f-61f6-e51cb50d3512= @lio96.de/ Fixes: 64d86c03e1441742 ("perf arm-spe: Extend branch operations") Reported-by: Hamza Mahfooz Reported-by: Thomas Voegtle Signed-off-by: Leo Yan Cc: Greg Kroah-Hartman Cc: Ian Rogers Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim To: Sasha Levin Cc: stable@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- tools/include/linux/bitfield.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/include/linux/bitfield.h b/tools/include/linux/bitfield.h index 6093fa6db2600..ddf81f24956ba 100644 --- a/tools/include/linux/bitfield.h +++ b/tools/include/linux/bitfield.h @@ -8,6 +8,7 @@ #define _LINUX_BITFIELD_H =20 #include +#include #include =20 /* --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4644440C791; Sat, 28 Feb 2026 17:44:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300673; cv=none; b=AiGFmuJ7HXSUCjWiy226oRTA1SDfD1bXtjttP54iSk6mbgIz+9xbtYxuIdz/lgnr7948PJI/zjLn++R7WYZkvEjL+Qelp+nYullGFk7gGssilofmYuYxYaK08ev1h/wCthwQB+VN0RPjIOs9iOBru1ajvPxPCbFD2/FnxnUbxpU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300673; c=relaxed/simple; bh=tMR0jwUSTCfCgTboqHcqsTP5vZR4Ew9O/wiWKDWqn88=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=P+H9NLrMQG9ZAthxO6AzQOf+RrBmjE5rRi3z9oVaidsLnmb33ckvUKYm6/ADc2GH05I9UepakLBqIcL3iecg+T60Jfb1QfNtfdqxjPVhXgwyrzbgV9+A8bMYOnbcvIlzgwKEt2Kg0L7pTBdJo4mTAYDAFCuhxzMVoV49nvjXGcE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZsFa1kJG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZsFa1kJG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D91CC19423; Sat, 28 Feb 2026 17:44:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300673; bh=tMR0jwUSTCfCgTboqHcqsTP5vZR4Ew9O/wiWKDWqn88=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZsFa1kJGMuMrlmMvKwEdkU4rERnxOZWi6PtLDEhSxYbwAiDAXsPeCNdaK3VNLNYw6 HphmD+Ulu7m7/Og55dhHZDcGpotKLCDURq4Q1ZBdwP+S+/lQLwcrmklBgUcGix1G5U 6E8onHYhHjCqTrba+BMxW+k/Gdp9Jdzm6qlJoXXuMc+AH7GQeOF7R9X+DoyZFjRNMN ZcrE+QwXfQ7wOFpzS+6IvRn7OMtT28dlPsKy7hsLEtbxUVLDxAqJ47M21n2icC5GpP 8jOfl8RmaE6xi3VkaOqXMro4GfzU+Y9N4ND+FBmAutuRkfe5mQ1Cbiu56j9Wd1IrEK NDejWa7+l3fXA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Jason Wang , "Michael S. Tsirkin" , Sasha Levin Subject: [PATCH 6.19 710/844] vhost: move vdpa group bound check to vhost_vdpa Date: Sat, 28 Feb 2026 12:30:23 -0500 Message-ID: <20260228173244.1509663-711-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Eugenio P=C3=A9rez [ Upstream commit cd025c1e876b4e262e71398236a1550486a73ede ] Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them. While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write. Cc: stable@vger.kernel.org Fixes: bda324fd037a ("vdpasim: control virtqueue support") Acked-by: Jason Wang Signed-off-by: Eugenio P=C3=A9rez Signed-off-by: Michael S. Tsirkin Message-Id: <20260119143306.1818855-2-eperezma@redhat.com> Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/vdpa/mlx5/net/mlx5_vnet.c | 3 --- drivers/vdpa/vdpa_sim/vdpa_sim.c | 6 ------ drivers/vhost/vdpa.c | 2 +- 3 files changed, 1 insertion(+), 10 deletions(-) diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5= _vnet.c index ddaa1366704bb..44062e9d68f00 100644 --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c @@ -3640,9 +3640,6 @@ static int mlx5_set_group_asid(struct vdpa_device *vd= ev, u32 group, struct mlx5_vdpa_dev *mvdev =3D to_mvdev(vdev); int err =3D 0; =20 - if (group >=3D MLX5_VDPA_NUMVQ_GROUPS) - return -EINVAL; - mvdev->mres.group2asid[group] =3D asid; =20 mutex_lock(&mvdev->mres.lock); diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_= sim.c index c1c6431950e1b..df9c7ddc5d782 100644 --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c @@ -606,12 +606,6 @@ static int vdpasim_set_group_asid(struct vdpa_device *= vdpa, unsigned int group, struct vhost_iotlb *iommu; int i; =20 - if (group > vdpasim->dev_attr.ngroups) - return -EINVAL; - - if (asid >=3D vdpasim->dev_attr.nas) - return -EINVAL; - iommu =3D &vdpasim->iommu[asid]; =20 mutex_lock(&vdpasim->mutex); diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index b0179e8567aba..7e51eec842b8c 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -680,7 +680,7 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v= , unsigned int cmd, case VHOST_VDPA_SET_GROUP_ASID: if (copy_from_user(&s, argp, sizeof(s))) return -EFAULT; - if (s.num >=3D vdpa->nas) + if (idx >=3D vdpa->ngroups || s.num >=3D vdpa->nas) return -EINVAL; if (!ops->set_group_asid) return -EOPNOTSUPP; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6464D40C7AD; Sat, 28 Feb 2026 17:44:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300674; cv=none; b=s/mvLrckvAKAsuU8RiPnWixC4xDiaKsYh7b7EAUtZ2sIGXyXE962EMct0jqbxXRyQORWOfK+kJuY1u4bH6bgXgylf085TV2hmACTTXDA19YdDtv2QInBw8jDmoTonognG94t44Rn58Y5NL5WhRgFXcAYOd1W8JZ7iuUuova9fYo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300674; c=relaxed/simple; bh=jvUAgPlhKfZajov5c17TsQrh8cTqBVWq5FQ3TlPoW/8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nPK6i2MAVM8maoiUNTi5oM3Fceu63uBjyRq2wnYhSUPlbxk6bRCVeMGyaEseDxn35T+Ks3SKI6+974TJMZQE/r0/kPb+Xyi3jIoSFU+4V4mevZMFBHDt+jFlmfNgSaQPkWFjlRNpd/1yuIuhd7Dxenp4RkFggiV5D8HIxdB+haQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SZFtSF7a; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SZFtSF7a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 704E9C19425; Sat, 28 Feb 2026 17:44:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300674; bh=jvUAgPlhKfZajov5c17TsQrh8cTqBVWq5FQ3TlPoW/8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SZFtSF7a3A2E3J2OzLxqprzWPwMdlFFnEoRP+zZ2b9j0E5HH5Cas/BIV6GxO38m5S M3lPgk7ERDyTtplniitr6SD68zBUi5aIvRJJJb6jJH+hdiwuXvZ3vUC3Zl7Z0x/Qa4 /73bxq1Ihduj5E958tnIBD50uhEA02ew7LwZoccw0ARS82xpQXA93aTt1T8hjkD5f5 jrxtEJkyXy0jd4QERrlvVuxMFVrB/p0H3tevR/78NKP5MlrAod8tJaXzkgpKgiDZy+ FiRDcK1u70q7uV2WDrvPUbh5PcJgDbAgoxD0gq7eIwQilp5D1c+3bNNpbZ9G5YLJTf cN05tizIpJI5A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Fabio M. De Francesco" , Dave Jiang , Hanjun Guo , Jonathan Cameron , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 711/844] ACPI: APEI: GHES: Add helper for CPER CXL protocol errors checks Date: Sat, 28 Feb 2026 12:30:24 -0500 Message-ID: <20260228173244.1509663-712-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Fabio M. De Francesco" [ Upstream commit 70205869686212eb8e4cddf02bf87fd5fd597bc2 ] Move the CPER CXL protocol errors validity check out of cxl_cper_post_prot_err() to new cxl_cper_sec_prot_err_valid() and limit the serial number check only to CXL agents that are CXL devices (UEFI v2.10, Appendix N.2.13). Export the new symbol for reuse by ELOG. Reviewed-by: Dave Jiang Reviewed-by: Hanjun Guo Reviewed-by: Jonathan Cameron Signed-off-by: Fabio M. De Francesco [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260114101543.85926-4-fabio.m.de.francesco@= linux.intel.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: b584bfbd7ec4 ("ACPI: APEI: GHES: Disable KASAN instrumentati= on when compile testing with clang < 18") Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/apei/Makefile | 1 + drivers/acpi/apei/ghes.c | 18 +---------------- drivers/acpi/apei/ghes_helpers.c | 33 ++++++++++++++++++++++++++++++++ include/cxl/event.h | 10 ++++++++++ 4 files changed, 45 insertions(+), 17 deletions(-) create mode 100644 drivers/acpi/apei/ghes_helpers.c diff --git a/drivers/acpi/apei/Makefile b/drivers/acpi/apei/Makefile index 2c474e6477e12..5db61dfb46915 100644 --- a/drivers/acpi/apei/Makefile +++ b/drivers/acpi/apei/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_ACPI_APEI) +=3D apei.o obj-$(CONFIG_ACPI_APEI_GHES) +=3D ghes.o +obj-$(CONFIG_ACPI_APEI_PCIEAER) +=3D ghes_helpers.o obj-$(CONFIG_ACPI_APEI_EINJ) +=3D einj.o einj-y :=3D einj-core.o einj-$(CONFIG_ACPI_APEI_EINJ_CXL) +=3D einj-cxl.o diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 77ea7a5b761f1..9919c31e42c07 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -741,24 +741,8 @@ static void cxl_cper_post_prot_err(struct cxl_cper_sec= _prot_err *prot_err, struct cxl_cper_prot_err_work_data wd; u8 *dvsec_start, *cap_start; =20 - if (!(prot_err->valid_bits & PROT_ERR_VALID_AGENT_ADDRESS)) { - pr_err_ratelimited("CXL CPER invalid agent type\n"); + if (cxl_cper_sec_prot_err_valid(prot_err)) return; - } - - if (!(prot_err->valid_bits & PROT_ERR_VALID_ERROR_LOG)) { - pr_err_ratelimited("CXL CPER invalid protocol error log\n"); - return; - } - - if (prot_err->err_len !=3D sizeof(struct cxl_ras_capability_regs)) { - pr_err_ratelimited("CXL CPER invalid RAS Cap size (%u)\n", - prot_err->err_len); - return; - } - - if (!(prot_err->valid_bits & PROT_ERR_VALID_SERIAL_NUMBER)) - pr_warn(FW_WARN "CXL CPER no device serial number\n"); =20 guard(spinlock_irqsave)(&cxl_cper_prot_err_work_lock); =20 diff --git a/drivers/acpi/apei/ghes_helpers.c b/drivers/acpi/apei/ghes_help= ers.c new file mode 100644 index 0000000000000..f3d162139a974 --- /dev/null +++ b/drivers/acpi/apei/ghes_helpers.c @@ -0,0 +1,33 @@ +// SPDX-License-Identifier: GPL-2.0-only +// Copyright(c) 2025 Intel Corporation. All rights reserved + +#include +#include + +int cxl_cper_sec_prot_err_valid(struct cxl_cper_sec_prot_err *prot_err) +{ + if (!(prot_err->valid_bits & PROT_ERR_VALID_AGENT_ADDRESS)) { + pr_err_ratelimited("CXL CPER invalid agent type\n"); + return -EINVAL; + } + + if (!(prot_err->valid_bits & PROT_ERR_VALID_ERROR_LOG)) { + pr_err_ratelimited("CXL CPER invalid protocol error log\n"); + return -EINVAL; + } + + if (prot_err->err_len !=3D sizeof(struct cxl_ras_capability_regs)) { + pr_err_ratelimited("CXL CPER invalid RAS Cap size (%u)\n", + prot_err->err_len); + return -EINVAL; + } + + if ((prot_err->agent_type =3D=3D RCD || prot_err->agent_type =3D=3D DEVIC= E || + prot_err->agent_type =3D=3D LD || prot_err->agent_type =3D=3D FMLD) = && + !(prot_err->valid_bits & PROT_ERR_VALID_SERIAL_NUMBER)) + pr_warn_ratelimited(FW_WARN + "CXL CPER no device serial number\n"); + + return 0; +} +EXPORT_SYMBOL_GPL(cxl_cper_sec_prot_err_valid); diff --git a/include/cxl/event.h b/include/cxl/event.h index 6fd90f9cc2034..4d7d1036ea9cb 100644 --- a/include/cxl/event.h +++ b/include/cxl/event.h @@ -320,4 +320,14 @@ static inline int cxl_cper_prot_err_kfifo_get(struct c= xl_cper_prot_err_work_data } #endif =20 +#ifdef CONFIG_ACPI_APEI_PCIEAER +int cxl_cper_sec_prot_err_valid(struct cxl_cper_sec_prot_err *prot_err); +#else +static inline int +cxl_cper_sec_prot_err_valid(struct cxl_cper_sec_prot_err *prot_err) +{ + return -EOPNOTSUPP; +} +#endif + #endif /* _LINUX_CXL_EVENT_H */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 747514949EB; Sat, 28 Feb 2026 17:44:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300675; cv=none; b=sMXdNTKbGJp0Sg9JSzYb/PaO0G+UhJ+fu5bn9b3yNUSWZaHjIB7hj6XNOjmzf2ZtvqF+KzoNicnJufSut9Ouy/DUrdE1yH6XINXhpdNEjgeUaX5mwIAK7svTDNVBJx3M6qev3zGY80LPsSBHqJFI/TJ31CGq/XW8oiYgJrbwxUk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300675; c=relaxed/simple; bh=DFcVptJHE90BO3dqT9p9dM65RX0wG6rDmsWvG1CjIWo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oF2pPEHgXDbyI4okn9FAyyYSa0+GVt9eoEhU1cmYUNF7RTwBns1CeYJTxS0mRHmRIs+kWpr5rnv4+Ld0kZt/xkIT9s03Gfz45uVEPlQYFVK5N4c5gz+1s/piynAcNKkWfHPDXiheeKAZFJeeqveCYH5w4FccOqMluYBCOYXbm6Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p7Lc7Rbm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p7Lc7Rbm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C2B4C19423; Sat, 28 Feb 2026 17:44:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300675; bh=DFcVptJHE90BO3dqT9p9dM65RX0wG6rDmsWvG1CjIWo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p7Lc7RbmtkoCJme034xx3TL9BkW43nToPwFDxndptg1dU21925H2NeIist1zI18Am DFlaXiYC+14dvTAFCrUCxyGdPcTd3iMxg5ICVy1j/PxXpBSYdKi9qUfKvG7ZRYEZdB RhKDVbqOPSODulZDl64YwmwYAC5WfzlqPQpEl3GRrU69yFXwA1d9+KvNryX5dCf2CI TvnIPgBUGsPON+mD+BYhsbR1rMqKvTUou7uCM/bSqihWBAKlb7alA2/ts3GOw9GT70 NfNGL/+X+2tk/FXnWXKZm8ROrRKA4Ia3/IOsCa7OkqBo45WI34vwhLso/inYP42u29 tps4G6NVmML0A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nathan Chancellor , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 712/844] ACPI: APEI: GHES: Disable KASAN instrumentation when compile testing with clang < 18 Date: Sat, 28 Feb 2026 12:30:25 -0500 Message-ID: <20260228173244.1509663-713-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nathan Chancellor [ Upstream commit b584bfbd7ec417f257f651cc00a90c66e31dfbf1 ] After a recent innocuous change to drivers/acpi/apei/ghes.c, building ARCH=3Darm64 allmodconfig with clang-17 or older (which has both CONFIG_KASAN=3Dy and CONFIG_WERROR=3Dy) fails with: drivers/acpi/apei/ghes.c:902:13: error: stack frame size (2768) exceeds l= imit (2048) in 'ghes_do_proc' [-Werror,-Wframe-larger-than] 902 | static void ghes_do_proc(struct ghes *ghes, | ^ A KASAN pass that removes unneeded stack instrumentation, enabled by default in clang-18 [1], drastically improves stack usage in this case. To avoid the warning in the common allmodconfig case when it can break the build, disable KASAN for ghes.o when compile testing with clang-17 and older. Disabling KASAN outright may hide legitimate runtime issues, so live with the warning in that case; the user can either increase the frame warning limit or disable -Werror, which they should probably do when debugging with KASAN anyways. Closes: https://github.com/ClangBuiltLinux/linux/issues/2148 Link: https://github.com/llvm/llvm-project/commit/51fbab134560ece663517bf1e= 8c2a30300d08f1a [1] Signed-off-by: Nathan Chancellor Cc: All applicable Link: https://patch.msgid.link/20260114-ghes-avoid-wflt-clang-older-than-18= -v1-1-9c8248bfe4f4@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/apei/Makefile | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/acpi/apei/Makefile b/drivers/acpi/apei/Makefile index 5db61dfb46915..1a0b85923cd42 100644 --- a/drivers/acpi/apei/Makefile +++ b/drivers/acpi/apei/Makefile @@ -1,6 +1,10 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_ACPI_APEI) +=3D apei.o obj-$(CONFIG_ACPI_APEI_GHES) +=3D ghes.o +# clang versions prior to 18 may blow out the stack with KASAN +ifeq ($(CONFIG_COMPILE_TEST)_$(CONFIG_CC_IS_CLANG)_$(call clang-min-versio= n, 180000),y_y_) +KASAN_SANITIZE_ghes.o :=3D n +endif obj-$(CONFIG_ACPI_APEI_PCIEAER) +=3D ghes_helpers.o obj-$(CONFIG_ACPI_APEI_EINJ) +=3D einj.o einj-y :=3D einj-core.o --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 32A0740D074; Sat, 28 Feb 2026 17:44:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300676; cv=none; b=Z78uaH1R5sQIht7H5+kvX2IsidrB8US3HWahISOcCAq+dm7bNMtkPSxQxRzT2Uydy+vefuZm6R+/ckWxgpYPV50B5Y6Gg+jnQtHaVb5ehR2Np8KHkpJh1Su7m1lBypFeeuUwZhUB+HuoCf8ZvmihET51x37xtGh3aBKMt2V9pwo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300676; c=relaxed/simple; bh=ZKIhve9+0RYe83pGZaG+13LcI7JpEpR6FeZefY3R9vU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d1dgq3oyj7OoOhO8Lm1NzuCq653qslEo8QQpaklUAdAdGo7UN20+9bbFpydDtXWxLGGA7yJoi/KFLwkx+7JxiBOJ9NuGfWvnpGNaKi77W7eXy7Yv1B6PDj1JJm1YZa1rZQDq3FK9ffc/n7Vzl59tn+huhSBXKkcUnChAKJFspf8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CXiumi9N; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CXiumi9N" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 676AAC2BC87; Sat, 28 Feb 2026 17:44:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300676; bh=ZKIhve9+0RYe83pGZaG+13LcI7JpEpR6FeZefY3R9vU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CXiumi9NkXJ6xy9D5nuAnULT+4LVLbubg3Me92ji8b1NXHVSQuUu1OefFLZxdfjz6 Z6BJOWhJeVe3JwOD716k4DpCaJ0GZD6xzDxH4CckfYAVtUOTeLVU7V/mFdLgJLP9xZ agA6KxbemA4Mqmbpg0G2F9pNAFh1CG629rb41zZulf8R3/ZUkuIKXwkNMgA/zPGY4e OQPwH1kf1EnldvnmUdwbUjedWPuCTLWLa/glqcemMmYLLtzDYNylr3xZZ7kwCLtZYR p7kyuoTI4ZwqL/FVqCmwCb6SI6sOIIrVl+a2NSyv/Op0YQoHrle435Pdi4xqeNqAmo CRwQag+bGziXw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Guangshuo Li , Christophe Leroy , Madhavan Srinivasan , Sasha Levin Subject: [PATCH 6.19 713/844] powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() Date: Sat, 28 Feb 2026 12:30:26 -0500 Message-ID: <20260228173244.1509663-714-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Guangshuo Li [ Upstream commit 33c1c6d8a28a2761ac74b0380b2563cf546c2a3a ] As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array(). Fixes: 790a1662d3a26 ("powerpc/smp: Parse ibm,thread-groups with multiple p= roperties") Cc: stable@vger.kernel.org Reviewed-by: Christophe Leroy Signed-off-by: Guangshuo Li Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250923133235.1862108-1-lgs201920130244@gma= il.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/powerpc/kernel/smp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c index 292fee8809bc8..cad3358fa4c35 100644 --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@ -822,6 +822,8 @@ static int parse_thread_groups(struct device_node *dn, =20 count =3D of_property_count_u32_elems(dn, "ibm,thread-groups"); thread_group_array =3D kcalloc(count, sizeof(u32), GFP_KERNEL); + if (!thread_group_array) + return -ENOMEM; ret =3D of_property_read_u32_array(dn, "ibm,thread-groups", thread_group_array, count); if (ret) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 667D140D099; Sat, 28 Feb 2026 17:44:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300677; cv=none; b=lZ/GVvJxC9mLhwqMIkXRh/KUlq+DVupoGzXKQZCTAh6dUJJU2fJLup2Ynzy4sqmOVxWht7g21dMRNKdCekhuKx4UsKUHR0tFEGfnRLFZ1MDWiveMhQplPBv19E4v1Npp6oOw8M/ybiZ6qJrRueD4ZYHYIVwHEv/ai6OQ1mS+l34= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300677; c=relaxed/simple; bh=NxGOfkvRJjHXt727XexuhxLaF0DzYjTi8pPM5h4Zgzk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SkOQYvUrCC0ZvUqcwFszyd8yadWgoNmNcJDXsVz6QcM1uW5TX5YALaP7L8TzkUsZWtlVV/n/PqZhIW0ztcoUvDPvlOnaOlwZHmPvpn5EIWrjIALCgotUCDtN91y6xBcH/EatPZa4Pzm/2M/hlcITNq8qzATLCO6N9kchIq1ro3Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TPGtURPG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TPGtURPG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A46EC116D0; Sat, 28 Feb 2026 17:44:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300677; bh=NxGOfkvRJjHXt727XexuhxLaF0DzYjTi8pPM5h4Zgzk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TPGtURPGXmZE1P3JHY3E6Sr3n/2Sff2k+sWVduAPwT6njkS/8343PzcYQAMU8gCZj vhm+yVpfO29cnNHNvYVATLI+Jg1hb6qxr5lMI9+96T5g4wiCqDza7w/eP+sntDtHHI hJrefV53DqCP/Wii90nh6K7uUYmT94782bDtxzmGbtI4EAjRwD723RyJd9GtJmPtnZ IHIIoRkiba+gj+1h2DAcxYfb1j2eN5YvQtqE9r1H4Yp1dSBsfA2qmu0Yk3PohBPI8I Dmw+OIaa2bitMzyO0MuXflnDaSxN+LdGhCBE1jzNSWGa87uu2lV07AG7j6HYjgL51q rRK38cT0xDmRw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Antoniu Miclaus , Andy Shevchenko , Stable@vger.kernel.org, Jonathan Cameron , Sasha Levin Subject: [PATCH 6.19 714/844] iio: gyro: itg3200: Fix unchecked return value in read_raw Date: Sat, 28 Feb 2026 12:30:27 -0500 Message-ID: <20260228173244.1509663-715-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Antoniu Miclaus [ Upstream commit b79b24f578cdb2d657db23e5fafe82c7e6a36b72 ] The return value from itg3200_read_reg_s16() is stored in ret but never checked. The function unconditionally returns IIO_VAL_INT, ignoring potential I2C read failures. This causes garbage data to be returned to userspace when the read fails, with no error reported. Add proper error checking to propagate the failure to callers. Fixes: 9dbf091da080 ("iio: gyro: Add itg3200") Signed-off-by: Antoniu Miclaus Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iio/gyro/itg3200_core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/gyro/itg3200_core.c b/drivers/iio/gyro/itg3200_cor= e.c index cd8a2dae56cd9..bfe95ec1abda9 100644 --- a/drivers/iio/gyro/itg3200_core.c +++ b/drivers/iio/gyro/itg3200_core.c @@ -93,6 +93,8 @@ static int itg3200_read_raw(struct iio_dev *indio_dev, case IIO_CHAN_INFO_RAW: reg =3D (u8)chan->address; ret =3D itg3200_read_reg_s16(indio_dev, reg, val); + if (ret) + return ret; return IIO_VAL_INT; case IIO_CHAN_INFO_SCALE: *val =3D 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F6CB40D88A; Sat, 28 Feb 2026 17:44:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300678; cv=none; b=JWp7dS32IhIgjSGLlqhKUIo6Y+QBMw3SJjsMnSFJziO+gvoh3r4Rm9kKt6vJvV5GbWcmnZmqjExIBuBiw3cgvU9nJDYL+FlEZT7+dkODyarNDvvymn3Kxeg+c5UW9S8wAJWWCRrbrqzxx7I57Jwic8yzXZ3j4YJXc58a4cLpJj8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300678; c=relaxed/simple; bh=72MtH4etEwxT1k1sD3KO4Y5iZT6lDvDEQvn42kEpSV0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Yfh7CKEXwBWbSIRjDbah3W4G+6V05TgZb7LMSEdsOhOxELLRsIkMD82wzQLgYbef5frk0NMAIhPxcN8HfI0I2FwUcZtDkXn66Zz72hvtlF9g/vMAUExHnhc/0+6HdfiGBP++/wYEeFXu7YLtHaABjhzyAnhALTf4XXug+lLatug= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BH00+zye; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BH00+zye" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6132AC19424; Sat, 28 Feb 2026 17:44:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300678; bh=72MtH4etEwxT1k1sD3KO4Y5iZT6lDvDEQvn42kEpSV0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BH00+zyesruLx11SHVsP3cLjk19fDK6Tg+x/MaHIaqxyD6Q2726H3O3b+GOgNBNOC 1mJHANcc4u3SqTKPgDXAinIWGJkvpHM0RxZRWKQR2XHZGHvOxOaOKipiHzNwjkbWgs Fxdb5FpYCEzrAWcZxmDM2FzNvmPw80RrPTF8vUeWBFhl3se1QxdMc8NXI+IbzzbWoh zsyT0r2yOoeuqgnCCpuy23kkvIZ4XHJon1I8af44I5CGh98HJWZlRHOHAic1Luz/oV lWO4U3GiWaICABXaJ69YfinAYGvSxu5ww8bKMItGCU2ezrrOVC26s6B3PbBf1kYA0m JC1AcUHh38kKA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David LaPorte , Gunnar Kudrjavets , Mikhail Kshevetskiy , Miquel Raynal , Sasha Levin Subject: [PATCH 6.19 715/844] mtd: spinand: Disable continuous read during probe Date: Sat, 28 Feb 2026 12:30:28 -0500 Message-ID: <20260228173244.1509663-716-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David LaPorte [ Upstream commit b4af7d194dc879353829f3c56988a68fbba1fbdd ] Macronix serial NAND devices with continuous read support do not clear the configuration register on soft reset and lack a hardware reset pin. When continuous read is interrupted (e.g., during reboot), the feature remains enabled at the device level. With continuous read enabled, the OOB area becomes inaccessible and all reads are instead directed to the main area. As a result, during partition allocation as part of MTD device registration, the first two bytes of the main area for the master block are read and indicate that the block is bad. This process repeats for every subsequent block for the partition. All reads and writes that reference the BBT find no good blocks and fail. The only paths for recovery from this state are triggering the continuous read feature by way of raw MTD reads or through a NAND device power drain. Disable continuous read explicitly during spinand probe to ensure quiescent feature state. Fixes: 631cfdd0520d ("mtd: spi-nand: Add continuous read support") Cc: stable@vger.kernel.org Signed-off-by: David LaPorte Reviewed-by: Gunnar Kudrjavets Reviewed-by: Mikhail Kshevetskiy Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mtd/nand/spi/core.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c index d207286572d87..9540fd04156c7 100644 --- a/drivers/mtd/nand/spi/core.c +++ b/drivers/mtd/nand/spi/core.c @@ -859,6 +859,14 @@ static void spinand_cont_read_init(struct spinand_devi= ce *spinand) (engine_type =3D=3D NAND_ECC_ENGINE_TYPE_ON_DIE || engine_type =3D=3D NAND_ECC_ENGINE_TYPE_NONE)) { spinand->cont_read_possible =3D true; + + /* + * Ensure continuous read is disabled on probe. + * Some devices retain this state across soft reset, + * which leaves the OOB area inaccessible and results + * in false positive returns from spinand_isbad(). + */ + spinand_cont_read_enable(spinand, false); } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 345B140D8A5; Sat, 28 Feb 2026 17:44:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300679; cv=none; b=ZIscek69J7Ipg4ghnncetJ1goEDruTmmI5iOVTf1WXwTO95CtRl/UObZ+G8pNKDKt5EJcE2nvXVwlO1Mh7m1kgYqF7sP1SO0DHZhQH9Eicbg9YbRgRNZSbJgnDUnHPK4Vk82kn5H+3MqCpnIPxmR7At9v8pKTLML4vmGPp0AxKo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300679; c=relaxed/simple; bh=95F7p9FHL/AywEQFx6+zZMDVlipdmfIm7nhBfH5jJKE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GbopKHGNIQOdYxUZ+E0iVWdOSfEa1FB1ZOYlrElpO9ZAJJkNh9oQAHDR6R/oeb9PSD69bswj/HRlLw6neon8qLcqFwYwNSTt+AUTdikzwJ+Hz6IJqSrWEgC6DL2mIDkn7x7wjpd9RR7yx0Kyc2Kg5GhuAPE3d9i6K1ZG5MQTJnQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Xv4TQSut; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Xv4TQSut" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65902C19424; Sat, 28 Feb 2026 17:44:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300679; bh=95F7p9FHL/AywEQFx6+zZMDVlipdmfIm7nhBfH5jJKE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Xv4TQSutb5Clm+FzEETMkIdJCXne+su35qorghq1Xz/xHSy0a64jALRHUkBn5VepY AsiL5Xu/R4zWCLSz1fjD14EzXrAP+r6dLByO/RsFaj6wbfKuahYkjuBB7XPCvz3vhE WgQiOO+H2azCN9Xlrt0VJM6uNvdZ7vE3YDCdS2km2akpesJEjh21lXlgfOOWAMVMLR 5mR57Zxi7c2/LoK3Kq/cKUbPiVEo6Ru1my8KSRM/Df3S5gmR7thgdarbUJKNx/pDl5 1Ll6FCBwV0s8wXMJ3Ol/PjCzXdwysjijvnAx1kUDLxkvQC3dpElv4NF186aMkxnZdI mBRYUpXdd+2nA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Emanuele Ghidoli , Francesco Dolcini , Sebastian Reichel , Sasha Levin Subject: [PATCH 6.19 716/844] power: reset: tdx-ec-poweroff: fix restart Date: Sat, 28 Feb 2026 12:30:29 -0500 Message-ID: <20260228173244.1509663-717-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Emanuele Ghidoli [ Upstream commit 562357a6310f79e45844c3e980d410a1e8e02ce6 ] During testing, restart occasionally failed on Toradex modules. The issue was traced to an interaction between the EC-based reset/poweroff handler and the PSCI restart handler. While the embedded controller is resetting or powering off the module, the PSCI code may still be invoked, triggering an I2C transaction to the PMIC. This can leave the PMIC I2C in a frozen state. Add a delay after issuing the EC reset or power-off command to give the controller time to complete the operation and avoid falling back to another restart/poweroff provider. Also print an error message if sending the command to the embedded controll= er fails. Fixes: 18672fe12367 ("power: reset: add Toradex Embedded Controller") Cc: stable@vger.kernel.org Signed-off-by: Emanuele Ghidoli Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260130071208.1184239-1-ghidoliemanuele@gma= il.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/power/reset/tdx-ec-poweroff.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/power/reset/tdx-ec-poweroff.c b/drivers/power/reset/td= x-ec-poweroff.c index 3302a127fce52..8040aa03d74d4 100644 --- a/drivers/power/reset/tdx-ec-poweroff.c +++ b/drivers/power/reset/tdx-ec-poweroff.c @@ -8,7 +8,10 @@ */ =20 #include +#include +#include #include +#include #include #include #include @@ -31,6 +34,8 @@ =20 #define EC_REG_MAX 0xD0 =20 +#define EC_CMD_TIMEOUT_MS 1000 + static const struct regmap_range volatile_ranges[] =3D { regmap_reg_range(EC_CMD_REG, EC_CMD_REG), }; @@ -75,6 +80,13 @@ static int tdx_ec_power_off(struct sys_off_data *data) =20 err =3D tdx_ec_cmd(regmap, EC_CMD_POWEROFF); =20 + if (err) { + dev_err(data->dev, "Failed to send power off command\n"); + } else { + mdelay(EC_CMD_TIMEOUT_MS); + WARN_ONCE(1, "Unable to power off system\n"); + } + return err ? NOTIFY_BAD : NOTIFY_DONE; } =20 @@ -85,6 +97,13 @@ static int tdx_ec_restart(struct sys_off_data *data) =20 err =3D tdx_ec_cmd(regmap, EC_CMD_RESET); =20 + if (err) { + dev_err(data->dev, "Failed to send restart command\n"); + } else { + mdelay(EC_CMD_TIMEOUT_MS); + WARN_ONCE(1, "Unable to restart system\n"); + } + return err ? NOTIFY_BAD : NOTIFY_DONE; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C45B40D08B; Sat, 28 Feb 2026 17:44:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300680; cv=none; b=ZWNLZBt3FBj4blluJIaC8qOXK3a6kdF5vTzBvlBiIsoziWW9gjil0kJyNmInd0yT9mW0MxTz9bVDmHROJgT0DMS6zHh35b5BU5GADGcxCzZdZ90c0KeWk3OojAm3aERUxpMuyJOt5IqcuOzuiazaNULAido/QqNV7g7suxb7wAU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300680; c=relaxed/simple; bh=Y5A+qy/cBeezTIQpW8P+otUa1RJTrk/4afSR4NCp82U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iAc06YJfaes/sPgtYgNCPlDkxBLdcJh3Vvu+Din36fY4uHOz0e0pXMcdUjfg2ZXmNHpFs48sOni8vqTATUr5ZGLKqn8uLI77/Rj8Z0YuvdyLf7rDnGGae99g5BRyNRj80pRT3IsOMcwZHIYS6CuWtFj5gpiNsCjb1JphhcosEHQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GdAuBSsY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GdAuBSsY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DBA7C19425; Sat, 28 Feb 2026 17:44:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300680; bh=Y5A+qy/cBeezTIQpW8P+otUa1RJTrk/4afSR4NCp82U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GdAuBSsYz7CzM0/VJR/paBCCAs6ytg+twN2aIq1h0kcHerYbh48IkySYBPmWHm8cq luqNOd8G4skgwoOPquyKOmmVelsjSGgLvQqm40TzbhkgScRu2IEuECujgM0f+uJwjN kkVLWIVarOGgPYjyaonetroDRwagz8EdVqj4xPo21zmNvln2knYUXY+oxi5f468EeX SFRtwhjTxbk5yPES1Eubib4CoN890Q+m3pvkWgDkKfy5qvG4YAOHx0pSAvsIUU/6Qb m4oLlBR44vTvbab5fbqCwmsEIdKccucf6tznsAh99JAIQ///93B1mStoG7DxZBTXfc rb+hBYRK8X+LQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: William Tambe , Max Filippov , Chris Zankel , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 717/844] mm/highmem: fix __kmap_to_page() build error Date: Sat, 28 Feb 2026 12:30:30 -0500 Message-ID: <20260228173244.1509663-718-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: William Tambe [ Upstream commit 94350fe6cad77b46c3dcb8c96543bef7647efbc0 ] This changes fixes following build error which is a miss from ef6e06b2ef87 ("highmem: fix kmap_to_page() for kmap_local_page() addresses"). mm/highmem.c:184:66: error: 'pteval' undeclared (first use in this function); did you mean 'pte_val'? 184 | idx =3D arch_kmap_local_map_idx(i, pte_pfn(pteval)); In __kmap_to_page(), pteval is used but does not exist in the function. (akpm: affects xtensa only) Link: https://lkml.kernel.org/r/SJ0PR07MB86317E00EC0C59DA60935FDCD18DA@SJ0P= R07MB8631.namprd07.prod.outlook.com Fixes: ef6e06b2ef87 ("highmem: fix kmap_to_page() for kmap_local_page() add= resses") Signed-off-by: William Tambe Reviewed-by: Max Filippov Cc: Chris Zankel Cc: Max Filippov Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/highmem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/highmem.c b/mm/highmem.c index b5c8e4c2d5d49..a33e411839517 100644 --- a/mm/highmem.c +++ b/mm/highmem.c @@ -180,12 +180,13 @@ struct page *__kmap_to_page(void *vaddr) for (i =3D 0; i < kctrl->idx; i++) { unsigned long base_addr; int idx; + pte_t pteval =3D kctrl->pteval[i]; =20 idx =3D arch_kmap_local_map_idx(i, pte_pfn(pteval)); base_addr =3D __fix_to_virt(FIX_KMAP_BEGIN + idx); =20 if (base_addr =3D=3D base) - return pte_page(kctrl->pteval[i]); + return pte_page(pteval); } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 62DB340E12F; Sat, 28 Feb 2026 17:44:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300681; cv=none; b=QqK3SbVT0Guc1SnMpmuaCbq3N9oOK8F37qEFSJbNlyVUUg2sJ7uw7ufWQNEVPXL/F5xLVOlJvuiknl8pt31XEqQUmmoQiRGD8ZZLGIG4KzYEjHLhGFF50n9gYSbhdPZDUn7MoMrHhW5yJBntt2epBz47mqkGXtaituj0uGssbIw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300681; c=relaxed/simple; bh=5KGWVuGG68irXfHboGwSA+TrY5NyBPFImHEJnw5iMWA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=V92OssgG7GbpMhfx4m1IIBlbHGLP+zDxGXuCs8QaRVNNIwKJlfFVHuWTBP4mVFsOsrilbPS/AyZnB/kzGeam62+oT24uMPttfyy/4OnJkaJFRByEqaGUD2ucq5DXAtSSBw7b59+0IEC/WrWCJplQrHGyQ/8pRZSKoXUOYSfyuhM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m74UPxk0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m74UPxk0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 618C8C19423; Sat, 28 Feb 2026 17:44:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300681; bh=5KGWVuGG68irXfHboGwSA+TrY5NyBPFImHEJnw5iMWA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m74UPxk0xjuLqtd5gdNtnJBqQ1XDvEyXry0Mj+S2RQ8JmakVqMlNjay9h4RCSBuBL LGho2fz1fNBT6JR6ZHIW/4vR3ugw4tnzL9X5B7Ow+DZY+B26+RAort/eRf6qPoHNCL /hO/zsayv1K+L8GPA/mPOXKIX6Un2ba8iUhbBoWBGMqk0Z+pjujk4glDrr0tbEzDi+ P3ZgzQq1/vcoyJAG/5OqVVGar7xQzVRdMwygu0ukEjJ7MnrWNyvO7Xv3dqGOKFY5Lq LgWS46E/hszbH3eLVu/+TyEdYccQIBf0naAcUFNkCRG4+r6e60aFafcGpsbMnQ+vyQ iblaSkAgbT5/w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nathan Chancellor , Bill Wendling , Justin Stitt , Uros Bizjak , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 718/844] compiler-clang.h: require LLVM 19.1.0 or higher for __typeof_unqual__ Date: Sat, 28 Feb 2026 12:30:31 -0500 Message-ID: <20260228173244.1509663-719-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nathan Chancellor [ Upstream commit e8d899d301346a5591c9d1af06c3c9b3501cf84b ] When building the kernel using a version of LLVM between llvmorg-19-init (the first commit of the LLVM 19 development cycle) and the change in LLVM that actually added __typeof_unqual__ for all C modes [1], which might happen during a bisect of LLVM, there is a build failure: In file included from arch/x86/kernel/asm-offsets.c:9: In file included from include/linux/crypto.h:15: In file included from include/linux/completion.h:12: In file included from include/linux/swait.h:7: In file included from include/linux/spinlock.h:56: In file included from include/linux/preempt.h:79: arch/x86/include/asm/preempt.h:61:2: error: call to undeclared function '= __typeof_unqual__'; ISO C99 and later do not support implicit function decl= arations [-Wimplicit-function-declaration] 61 | raw_cpu_and_4(__preempt_count, ~PREEMPT_NEED_RESCHED); | ^ arch/x86/include/asm/percpu.h:478:36: note: expanded from macro 'raw_cpu_= and_4' 478 | #define raw_cpu_and_4(pcp, val) percpu_bi= nary_op(4, , "and", (pcp), val) | ^ arch/x86/include/asm/percpu.h:210:3: note: expanded from macro 'percpu_bi= nary_op' 210 | TYPEOF_UNQUAL(_var) pto_tmp__; = \ | ^ include/linux/compiler.h:248:29: note: expanded from macro 'TYPEOF_UNQUAL' 248 | # define TYPEOF_UNQUAL(exp) __typeof_unqual__(exp) | ^ The current logic of CC_HAS_TYPEOF_UNQUAL just checks for a major version of 19 but half of the 19 development cycle did not have support for __typeof_unqual__. Harden the logic of CC_HAS_TYPEOF_UNQUAL to avoid this error by only using __typeof_unqual__ with a released version of LLVM 19, which is greater than or equal to 19.1.0 with LLVM's versioning scheme that matches GCC's [2]. Link: https://github.com/llvm/llvm-project/commit/cc308f60d41744b5920ec2e2e= 5b25e1273c8704b [1] Link: https://github.com/llvm/llvm-project/commit/4532617ae420056bf32f6403d= de07fb99d276a49 [2] Link: https://lkml.kernel.org/r/20260116-require-llvm-19-1-for-typeof_unqua= l-v1-1-3b9a4a4b212b@kernel.org Fixes: ac053946f5c4 ("compiler.h: introduce TYPEOF_UNQUAL() macro") Signed-off-by: Nathan Chancellor Cc: Bill Wendling Cc: Justin Stitt Cc: Uros Bizjak Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/compiler-clang.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h index 7edf1a07b5350..e1123dd284862 100644 --- a/include/linux/compiler-clang.h +++ b/include/linux/compiler-clang.h @@ -153,4 +153,4 @@ * Bindgen uses LLVM even if our C compiler is GCC, so we cannot * rely on the auto-detected CONFIG_CC_HAS_TYPEOF_UNQUAL. */ -#define CC_HAS_TYPEOF_UNQUAL (__clang_major__ >=3D 19) +#define CC_HAS_TYPEOF_UNQUAL (__clang_major__ > 19 || (__clang_major__ =3D= =3D 19 && __clang_minor__ > 0)) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6135940E149; Sat, 28 Feb 2026 17:44:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300682; cv=none; b=JCqIqqF9ivlETJvcMIEtairbXKKU4XsQrf+n8bQdM6eSUndnaTeD7rBEHPXI8VhJdqSMDfb5V5wt3CIDxLAjb9UMTyqq/q/U+bFzWiMDHdn1oChEB7XS899sfm8jD2Y+4LhDp4FyEEkabER+aTVrZdgNshP5uFYA0HauXm47s7I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300682; c=relaxed/simple; bh=kKnit95le2+dEaHuxkHCZ4Z5TC3ZZdIrDO+rIBCKDpc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=E9+l7e4k3yJLFC4HTfkzzoSMxDujAGBr93/Bqc9hxaWP8YsJRr32UcA/a9pcsy4ilkNvGE+MRlxPSzVaMJL27wI0mjMpKILcFxR7gfIrLtltWkL4HSufbaWlsdAks8Y5kG7rzuTFG3bKts1vBVVjXTYPzKaWLADXOXdwCVA5yv4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DrYmkDo9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DrYmkDo9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E665C2BC87; Sat, 28 Feb 2026 17:44:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300682; bh=kKnit95le2+dEaHuxkHCZ4Z5TC3ZZdIrDO+rIBCKDpc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DrYmkDo924i0iuYEPGkomd2NX1oUyqVNeD3JlBan1jD/CJQO3kw2dctCLksHSybAY TV2PvOpMR+gCqAHgHnqlRByiFORnKLwlDMBCGARhEUdLWxoQp/YXAmoAT8h/+MM7eh JdkNJcg15pjxt33XmQi9ln/1dF6F4YT8ru0IAxsr83/Yydidr/3h0PLGEQeejWOkDo vTlGLnmgdQVYoKlBawgOzQOjuMYWjj8pA5nX6l7xME1k/OYvUOBo7mxsFYEtHFAGgQ oQNrpZAn4F5ErOmIpF5UUlH0kcGhGNonblZUxOQ5QH6eC34xuJs/aBp4z0Dk3bm74R dCc5EweWj/z+Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Andrew Morton , Alexandre Bounine , Matt Porter , Sasha Levin Subject: [PATCH 6.19 719/844] rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() Date: Sat, 28 Feb 2026 12:30:32 -0500 Message-ID: <20260228173244.1509663-720-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit 666183dcdd9ad3b8156a1df7f204f728f720380f ] When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer. Link: https://lkml.kernel.org/r/20260121013508.195836-1-lihaoxiang@isrc.isc= as.ac.cn Fixes: e6b585ca6e81 ("rapidio: move net allocation into core code") Signed-off-by: Haoxiang Li Reviewed-by: Andrew Morton Cc: Alexandre Bounine Cc: Matt Porter Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/rapidio/rio-scan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c index c12941f71e2cb..dcd6619a4b027 100644 --- a/drivers/rapidio/rio-scan.c +++ b/drivers/rapidio/rio-scan.c @@ -854,7 +854,8 @@ static struct rio_net *rio_scan_alloc_net(struct rio_mp= ort *mport, =20 if (idtab =3D=3D NULL) { pr_err("RIO: failed to allocate destID table\n"); - rio_free_net(net); + kfree(net); + mport->net =3D NULL; net =3D NULL; } else { net->enum_data =3D idtab; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07ACE40E946; Sat, 28 Feb 2026 17:44:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300684; cv=none; b=IhYkjcbylD5L9uZRCDB0gj1Jl57FE4byspENAtr/ZTuraqeZZzw82dKaJwtT+TUlhNcCOsvCwR91YM2ermj3IADsR2NZYZaze91cxa5gaXchBNRHFpm5yDvHEk4O3EbiHWWLrJPqygTFfY1Pwtu25QdBkc2rT00Q9ILg2tfSGiQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300684; c=relaxed/simple; bh=829/Owi9SM/5ByjQlN4zVXMTkXwocNKaHkz6VOhfvpc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EH8ynnL7HtHb/3ynH0jk8dFuIqpQBCuKG9P59fSwS2sTAJLp1HZU04iYET9jKL8xstF2C8BRwLH0J09Rfd3ad7wKYnbxuXwM0XhKQjgX10WgvIe4qrtpYj1u+cygihqJgAShghNRLWE8TIRoC8mj7+VK+xvCmqVdFdfTrMCIsDA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FXG2digM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FXG2digM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A5ADC19423; Sat, 28 Feb 2026 17:44:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300683; bh=829/Owi9SM/5ByjQlN4zVXMTkXwocNKaHkz6VOhfvpc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FXG2digM8/+R178tdEn9L8/cxk932JfsZ92Du83znOahYHBrr3bhSksOHmtf1cl7X UhabIOlvyAYNsEVjIVH2xITlhKOTVyUfXlLuckvrEZIQLduBXg6tfy9xxIRo3A+pJr YblctWQPb0Kgsa4kn5pjz0yR/dqNzmO0Vl/c3dD2noAGYx6snFdx6s7Umtwz5mFM4h /i6Qu2v1O0siETOUwkD5QKM7yBK2WiELv3F1zg5YtEWNM9VKEj+hTXfdqw+HYLf3QU U1ygOO+03Z16/TQ7OWMR/VzJxARhVfyrkQSNPv/2IZXmK1OGx9vk2vMKcc9pxftRne 2tvq8Qpqzfp2A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Heming Zhao , Mark Fasheh , Joel Becker , Junxiao Bi , Joseph Qi , Changwei Ge , Jun Piao , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 720/844] ocfs2: fix reflink preserve cleanup issue Date: Sat, 28 Feb 2026 12:30:33 -0500 Message-ID: <20260228173244.1509663-721-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Heming Zhao [ Upstream commit 5138c936c2c82c9be8883921854bc6f7e1177d8c ] commit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3. Link: https://lkml.kernel.org/r/20251210015725.8409-2-heming.zhao@suse.com Fixes: 0fe9b66c65f3 ("ocfs2: Add preserve to reflink.") Signed-off-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ocfs2/xattr.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c index 1b21fbc16d73a..1bff4f2d1345e 100644 --- a/fs/ocfs2/xattr.c +++ b/fs/ocfs2/xattr.c @@ -6394,6 +6394,10 @@ static int ocfs2_reflink_xattr_header(handle_t *hand= le, (void *)last - (void *)xe); memset(last, 0, sizeof(struct ocfs2_xattr_entry)); + last =3D &new_xh->xh_entries[le16_to_cpu(new_xh->xh_count)] - 1; + } else { + memset(xe, 0, sizeof(struct ocfs2_xattr_entry)); + last =3D NULL; } =20 /* --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 50CC840E95D; Sat, 28 Feb 2026 17:44:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300685; cv=none; b=s9T25cIhFUi7vI2xUr8LQ3cXmOtUtWht/0OSVAXAzqpjtTdhCkih/zmWQm41szlMQSbH/gaVsQ16sNirlqq6QFjaVgF0e8edcvEeAYh6YfQqP3ObIJbTsO5K5oSgiv8B8ZnQc5PqLroET5WkM08BSpWoZXSC3s3mePL3Ih6m+ZM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300685; c=relaxed/simple; bh=A1f1QShUP6lQqJ7k1RJjkakWAtceu7yz6XBz1K+AskQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Nd/ScoacuXUWWxu++1HEkhNqFKCubxYhy6+OEav6lAyDF16Mdyenqz2bvmSzhJeDgSfMfZ2LKCcvgGQ5eZx8uCOZCxa29BNcb95LjxAAPBAOBU+OwkMZ7eJQ/XuWGCuoAwLJVN7qJdjAdyVP+Btd6r/usc3hYzOLdImeUeHQBJE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NNICFunZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NNICFunZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E74A1C116D0; Sat, 28 Feb 2026 17:44:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300685; bh=A1f1QShUP6lQqJ7k1RJjkakWAtceu7yz6XBz1K+AskQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NNICFunZ5YyXUq932myBf5Ug0B/tX54xW60OvbzO8hQPb9iHERKxXBCVtZadWvcPz 8V8dYHlSX3a34rC6oEqsDwMkeESdJ17xXIU23/1eszB00MZn+0v7/bxmg40sxOB/Qp VT2/E/xn9qgbTh3zCIPlcuqCGR1zBxbH6oLzwEJhWJgvCgrEXR46KGgI46uWll/fe+ qbWIcgz3q2TDTO6/kkhRAG3hdNX1bEat6KsRlak+Q4YctD5jmH++bNfXSnUER0cEWf FqeLrVsQxBn06Uja71lw835YEjypxTxyMbUNz+i1LNqS5OwPqLeCcWt/K5VdQ67NKV hhUo6NCcol4Hw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Li Chen , Baoquan He , Alexander Graf , Eric Biggers , Philipp Rudo , Ricardo Ribalda Delgado , Ross Zwisler , Sourabh Jain , Steven Rostedt , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 721/844] kexec: derive purgatory entry from symbol Date: Sat, 28 Feb 2026 12:30:34 -0500 Message-ID: <20260228173244.1509663-722-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li Chen [ Upstream commit 480e1d5c64bb14441f79f2eb9421d5e26f91ea3d ] kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#= 10: kexec/1784 Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty: move helper to avoid forward declaration, per Baoquan] Link: https://lkml.kernel.org/r/20260128043511.316860-1-me@linux.beauty Link: https://lkml.kernel.org/r/20260120124005.148381-1-me@linux.beauty Fixes: 8652d44f466a ("kexec: support purgatories with .text.hot sections") Signed-off-by: Li Chen Acked-by: Baoquan He Cc: Alexander Graf Cc: Eric Biggers Cc: Li Chen Cc: Philipp Rudo Cc: Ricardo Ribalda Delgado Cc: Ross Zwisler Cc: Sourabh Jain Cc: Steven Rostedt Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/kexec_file.c | 131 +++++++++++++++++++++++++------------------- 1 file changed, 74 insertions(+), 57 deletions(-) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index eb62a97942428..2bfbb2d144e69 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -882,6 +882,60 @@ static int kexec_calculate_store_digests(struct kimage= *image) } =20 #ifdef CONFIG_ARCH_SUPPORTS_KEXEC_PURGATORY +/* + * kexec_purgatory_find_symbol - find a symbol in the purgatory + * @pi: Purgatory to search in. + * @name: Name of the symbol. + * + * Return: pointer to symbol in read-only symtab on success, NULL on error. + */ +static const Elf_Sym *kexec_purgatory_find_symbol(struct purgatory_info *p= i, + const char *name) +{ + const Elf_Shdr *sechdrs; + const Elf_Ehdr *ehdr; + const Elf_Sym *syms; + const char *strtab; + int i, k; + + if (!pi->ehdr) + return NULL; + + ehdr =3D pi->ehdr; + sechdrs =3D (void *)ehdr + ehdr->e_shoff; + + for (i =3D 0; i < ehdr->e_shnum; i++) { + if (sechdrs[i].sh_type !=3D SHT_SYMTAB) + continue; + + if (sechdrs[i].sh_link >=3D ehdr->e_shnum) + /* Invalid strtab section number */ + continue; + strtab =3D (void *)ehdr + sechdrs[sechdrs[i].sh_link].sh_offset; + syms =3D (void *)ehdr + sechdrs[i].sh_offset; + + /* Go through symbols for a match */ + for (k =3D 0; k < sechdrs[i].sh_size/sizeof(Elf_Sym); k++) { + if (ELF_ST_BIND(syms[k].st_info) !=3D STB_GLOBAL) + continue; + + if (strcmp(strtab + syms[k].st_name, name) !=3D 0) + continue; + + if (syms[k].st_shndx =3D=3D SHN_UNDEF || + syms[k].st_shndx >=3D ehdr->e_shnum) { + pr_debug("Symbol: %s has bad section index %d.\n", + name, syms[k].st_shndx); + return NULL; + } + + /* Found the symbol we are looking for */ + return &syms[k]; + } + } + + return NULL; +} /* * kexec_purgatory_setup_kbuf - prepare buffer to load purgatory. * @pi: Purgatory to be loaded. @@ -960,6 +1014,10 @@ static int kexec_purgatory_setup_sechdrs(struct purga= tory_info *pi, unsigned long offset; size_t sechdrs_size; Elf_Shdr *sechdrs; + const Elf_Sym *entry_sym; + u16 entry_shndx =3D 0; + unsigned long entry_off =3D 0; + bool start_fixed =3D false; int i; =20 /* @@ -977,6 +1035,12 @@ static int kexec_purgatory_setup_sechdrs(struct purga= tory_info *pi, bss_addr =3D kbuf->mem + kbuf->bufsz; kbuf->image->start =3D pi->ehdr->e_entry; =20 + entry_sym =3D kexec_purgatory_find_symbol(pi, "purgatory_start"); + if (entry_sym) { + entry_shndx =3D entry_sym->st_shndx; + entry_off =3D entry_sym->st_value; + } + for (i =3D 0; i < pi->ehdr->e_shnum; i++) { unsigned long align; void *src, *dst; @@ -994,6 +1058,13 @@ static int kexec_purgatory_setup_sechdrs(struct purga= tory_info *pi, =20 offset =3D ALIGN(offset, align); =20 + if (!start_fixed && entry_sym && i =3D=3D entry_shndx && + (sechdrs[i].sh_flags & SHF_EXECINSTR) && + entry_off < sechdrs[i].sh_size) { + kbuf->image->start =3D kbuf->mem + offset + entry_off; + start_fixed =3D true; + } + /* * Check if the segment contains the entry point, if so, * calculate the value of image->start based on it. @@ -1004,13 +1075,14 @@ static int kexec_purgatory_setup_sechdrs(struct pur= gatory_info *pi, * is not set to the initial value, and warn the user so they * have a chance to fix their purgatory's linker script. */ - if (sechdrs[i].sh_flags & SHF_EXECINSTR && + if (!start_fixed && sechdrs[i].sh_flags & SHF_EXECINSTR && pi->ehdr->e_entry >=3D sechdrs[i].sh_addr && pi->ehdr->e_entry < (sechdrs[i].sh_addr + sechdrs[i].sh_size) && - !WARN_ON(kbuf->image->start !=3D pi->ehdr->e_entry)) { + kbuf->image->start =3D=3D pi->ehdr->e_entry) { kbuf->image->start -=3D sechdrs[i].sh_addr; kbuf->image->start +=3D kbuf->mem + offset; + start_fixed =3D true; } =20 src =3D (void *)pi->ehdr + sechdrs[i].sh_offset; @@ -1128,61 +1200,6 @@ int kexec_load_purgatory(struct kimage *image, struc= t kexec_buf *kbuf) return ret; } =20 -/* - * kexec_purgatory_find_symbol - find a symbol in the purgatory - * @pi: Purgatory to search in. - * @name: Name of the symbol. - * - * Return: pointer to symbol in read-only symtab on success, NULL on error. - */ -static const Elf_Sym *kexec_purgatory_find_symbol(struct purgatory_info *p= i, - const char *name) -{ - const Elf_Shdr *sechdrs; - const Elf_Ehdr *ehdr; - const Elf_Sym *syms; - const char *strtab; - int i, k; - - if (!pi->ehdr) - return NULL; - - ehdr =3D pi->ehdr; - sechdrs =3D (void *)ehdr + ehdr->e_shoff; - - for (i =3D 0; i < ehdr->e_shnum; i++) { - if (sechdrs[i].sh_type !=3D SHT_SYMTAB) - continue; - - if (sechdrs[i].sh_link >=3D ehdr->e_shnum) - /* Invalid strtab section number */ - continue; - strtab =3D (void *)ehdr + sechdrs[sechdrs[i].sh_link].sh_offset; - syms =3D (void *)ehdr + sechdrs[i].sh_offset; - - /* Go through symbols for a match */ - for (k =3D 0; k < sechdrs[i].sh_size/sizeof(Elf_Sym); k++) { - if (ELF_ST_BIND(syms[k].st_info) !=3D STB_GLOBAL) - continue; - - if (strcmp(strtab + syms[k].st_name, name) !=3D 0) - continue; - - if (syms[k].st_shndx =3D=3D SHN_UNDEF || - syms[k].st_shndx >=3D ehdr->e_shnum) { - pr_debug("Symbol: %s has bad section index %d.\n", - name, syms[k].st_shndx); - return NULL; - } - - /* Found the symbol we are looking for */ - return &syms[k]; - } - } - - return NULL; -} - void *kexec_purgatory_get_symbol_addr(struct kimage *image, const char *na= me) { struct purgatory_info *pi =3D &image->purgatory_info; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F27240E977; Sat, 28 Feb 2026 17:44:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300686; cv=none; b=Juny5XgRd7ve0TKm9RvDJxGtfwFNnOKIZR/svBgnV+9MIJ5dL94VRcsuZQjuuEeyHZ/893g+ZVYCTnCJfx8+LePVg/eg0WqDZcKArcirVtqpWv7jirAM2mEW7w+7DPdqpi8P/O2CGi7DUPMcHAacyjK9OxuuY/sZwReLvm/lccw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300686; c=relaxed/simple; bh=rjXJLCBeCGvltKD9acB4is1H3g18LgE0Z3h2wPRvfwI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PGOLA0h8Z/LKAYIqjXmuBTjaB4zYBt6VHEpwt+f3OVUap/35o6PGTrTDUj0yFTerJH0lMYubSUtLNU168UeGCaPv5ueKnMrE1xpuJ9qHq/IYIPKKVwTS3Vu3B6WmxKYaMYCqVQMVaeGKUCl2oBaJ9A+7CZYIz+b5lkV4I2ZLgWA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Rq0pWXuG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Rq0pWXuG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77DD3C116D0; Sat, 28 Feb 2026 17:44:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300686; bh=rjXJLCBeCGvltKD9acB4is1H3g18LgE0Z3h2wPRvfwI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Rq0pWXuGA2yZvc/GivoDBc13ocgCQv8HONqYXrc+8EXHXQHnG0NNVwa3/CWaow/Vq 6AA8bHpbf+JBQIJihpp70hylSCfZqS90RhksfwCx3iyBAHF2X9iFCtpGHvTCN610/0 5Lf7kIc8mgW1UEGila3T9358ED0Gvg6IXbZDzSLHGXtI+wkcPwhLHuLThDF+d0Hs54 1IKG9/qzsMr4wHtXWfALyfoA3L2+5GLht76lGBcnAmA/5gFbwWWd0ehqdnp6MqZsA7 mDMWkWfkrFetAkfXnPFJYabVwwcoHNv6lQhNg/lR3vLRu5+3fU8NdSOhsGCxooxGWs VNiN+dkTlbQRg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vasily Gorbik , Baoquan He , Coiby Xu , Dave Young , Vivek Goyal , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 722/844] crash_dump: fix dm_crypt keys locking and ref leak Date: Sat, 28 Feb 2026 12:30:35 -0500 Message-ID: <20260228173244.1509663-723-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vasily Gorbik [ Upstream commit 96a54b8ffc8c4567c32fe0b6996669f1132b026d ] crash_load_dm_crypt_keys() reads dm-crypt volume keys from the user keyring. It uses user_key_payload_locked() without holding key->sem, which makes lockdep complain when kexec_file_load() assembles the crash image: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D WARNING: suspicious RCU usage ----------------------------- ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usag= e! other info that might help us debug this: rcu_scheduler_active =3D 2, debug_locks =3D 1 no locks held by kexec/4875. stack backtrace: Call Trace: dump_stack_lvl+0x5d/0x80 lockdep_rcu_suspicious.cold+0x4e/0x96 crash_load_dm_crypt_keys+0x314/0x390 bzImage64_load+0x116/0x9a0 ? __lock_acquire+0x464/0x1ba0 __do_sys_kexec_file_load+0x26a/0x4f0 do_syscall_64+0xbd/0x430 entry_SYSCALL_64_after_hwframe+0x77/0x7f In addition, the key returned by request_key() is never key_put()'d, leaking a key reference on each load attempt. Take key->sem while copying the payload and drop the key reference afterwards. Link: https://lkml.kernel.org/r/patch.git-2d4d76083a5c.your-ad-here.call-01= 769426386-ext-2560@work.hours Fixes: 479e58549b0f ("crash_dump: store dm crypt keys in kdump reserved mem= ory") Signed-off-by: Vasily Gorbik Cc: Baoquan He Cc: Coiby Xu Cc: Dave Young Cc: Vivek Goyal Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/crash_dump_dm_crypt.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c index 401423ba477da..abb307a23de33 100644 --- a/kernel/crash_dump_dm_crypt.c +++ b/kernel/crash_dump_dm_crypt.c @@ -143,6 +143,7 @@ static int read_key_from_user_keying(struct dm_crypt_ke= y *dm_key) { const struct user_key_payload *ukp; struct key *key; + int ret =3D 0; =20 kexec_dprintk("Requesting logon key %s", dm_key->key_desc); key =3D request_key(&key_type_logon, dm_key->key_desc, NULL); @@ -152,20 +153,28 @@ static int read_key_from_user_keying(struct dm_crypt_= key *dm_key) return PTR_ERR(key); } =20 + down_read(&key->sem); ukp =3D user_key_payload_locked(key); - if (!ukp) - return -EKEYREVOKED; + if (!ukp) { + ret =3D -EKEYREVOKED; + goto out; + } =20 if (ukp->datalen > KEY_SIZE_MAX) { pr_err("Key size %u exceeds maximum (%u)\n", ukp->datalen, KEY_SIZE_MAX); - return -EINVAL; + ret =3D -EINVAL; + goto out; } =20 memcpy(dm_key->data, ukp->data, ukp->datalen); dm_key->key_size =3D ukp->datalen; kexec_dprintk("Get dm crypt key (size=3D%u) %s: %8ph\n", dm_key->key_size, dm_key->key_desc, dm_key->data); - return 0; + +out: + up_read(&key->sem); + key_put(key); + return ret; } =20 struct config_key { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF888494A04; Sat, 28 Feb 2026 17:44:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300687; cv=none; b=OrnO7Cb68XsC6NsNy1JPuMHSo7bop3JtAtSJDd/TNxooox0eVeM37GZt9eZDlXyKJIwUJtOeUii7nIzvZhpkBXGnAuxtE5bP+pH1ydPYZdwnuU0RYMT/r2VTlFySNrHjBtk0LvaQoUqZ/XcMcstyOQGP6tZHcgbyO9VI+xvMZtE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300687; c=relaxed/simple; bh=1cbUP4+f5t1+aDgDls9jn2QhrK4hzb6Zn4PR9dAMTyc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BoJK+rD+7paBD0Y72DwM7kOGXvG0D9MM/onAabQZLo427rpZYdDDNwVyPeqpkzaqNozPmA8FjKLY+MkcTHlmbtba8aw/UHFl1EQVf2f8A8+MAztrfDjc0NQcrDQNCxzsIgEl6n3LZtDQibM7/hAUWl7v7bL9gQnvoZRQswJq6V8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UNu9vZHw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UNu9vZHw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6C8DC116D0; Sat, 28 Feb 2026 17:44:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300687; bh=1cbUP4+f5t1+aDgDls9jn2QhrK4hzb6Zn4PR9dAMTyc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UNu9vZHwQcXLK3wfARChmOip4+0ElJBfT8Kenn3TOAcCLo8cIVpFZmFiOsAVg35OM uUi9U/qi8n6A8rWsP/4SokFXRwZlJLy0RcOGEACEwfiM0PxAPXgFMEsN21QqI0m/0h pIL2U0s78Ym9vKut7Z8j8I43ygfTH3DGW7YZPicS2ISITp7IdcZbfVy4H7n8djW8r8 uewtwSr3Iyn3EJe/970bgGEI/ZR7gv4TgtGpjZk1uCJlmz8yq/jPT7CtJkKsKjfm2L tu+qwpKkzxbmJEr+Mrh8aIEp6urOGLprRQsgwihgMXqu1e13i8bacHxw4w9IULyGh9 iMM3traghJ22w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Evangelos Petrongonas , Pratyush Yadav , "Mike Rapoport (Microsoft)" , Pasha Tatashin , Alexander Graf , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 723/844] kho: skip memoryless NUMA nodes when reserving scratch areas Date: Sat, 28 Feb 2026 12:30:36 -0500 Message-ID: <20260228173244.1509663-724-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Evangelos Petrongonas [ Upstream commit 427b2535f51342de3156babc6bdc3f3b7dd2c707 ] kho_reserve_scratch() iterates over all online NUMA nodes to allocate per-node scratch memory. On systems with memoryless NUMA nodes (nodes that have CPUs but no memory), memblock_alloc_range_nid() fails because there is no memory available on that node. This causes KHO initialization to fail and kho_enable to be set to false. Some ARM64 systems have NUMA topologies where certain nodes contain only CPUs without any associated memory. These configurations are valid and should not prevent KHO from functioning. Fix this by only counting nodes that have memory (N_MEMORY state) and skip memoryless nodes in the per-node scratch allocation loop. Link: https://lkml.kernel.org/r/20260120175913.34368-1-epetron@amazon.de Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers"). Signed-off-by: Evangelos Petrongonas Reviewed-by: Pratyush Yadav Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Pasha Tatashin Cc: Alexander Graf Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/liveupdate/kexec_handover.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_h= andover.c index 90d411a59f76d..fcbbfcd3365f6 100644 --- a/kernel/liveupdate/kexec_handover.c +++ b/kernel/liveupdate/kexec_handover.c @@ -645,7 +645,7 @@ static void __init kho_reserve_scratch(void) scratch_size_update(); =20 /* FIXME: deal with node hot-plug/remove */ - kho_scratch_cnt =3D num_online_nodes() + 2; + kho_scratch_cnt =3D nodes_weight(node_states[N_MEMORY]) + 2; size =3D kho_scratch_cnt * sizeof(*kho_scratch); kho_scratch =3D memblock_alloc(size, PAGE_SIZE); if (!kho_scratch) @@ -675,7 +675,11 @@ static void __init kho_reserve_scratch(void) kho_scratch[i].size =3D size; i++; =20 - for_each_online_node(nid) { + /* + * Loop over nodes that have both memory and are online. Skip + * memoryless nodes, as we can not allocate scratch areas there. + */ + for_each_node_state(nid, N_MEMORY) { size =3D scratch_size_node(nid); addr =3D memblock_alloc_range_nid(size, CMA_MIN_ALIGNMENT_BYTES, 0, MEMBLOCK_ALLOC_ACCESSIBLE, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4E3740F37A; Sat, 28 Feb 2026 17:44:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300688; cv=none; b=T3gVOGK1EtoyVMFXoSkkyOtPbap5k4b3oIpRr9jZa5l7A5VhVmL6jBJDvZoUehgcF+13GtpsKSRLEzRyiIhYGWd05jP7w2iaeBQEi+HvefpAT4cIpUFbhuxuw7OG6aGXBXbdtbKNoPajs6lQKGrm75Wm59SfCwS90tr/K89zUsc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300688; c=relaxed/simple; bh=ujKkFQFpaopOnq3N33y07y7T0GQ1Edd0brGyWkvGKrk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lb/WkGVu5CdYMb4ZVBjenwsbjTZvRXgFjHswVZjvufpqg9kIxHm1kuE7uHuGazjkPPCho61BVr7Izgf3EkrRGCn2xcfJJxiyNSFgpc8jh0DwzgqSP4t8KgNpfFnkV2Mej2RwwEf5vWcK5zYY9fvujK164wTUOEBEfwrViu6jZ5o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sHAYEnJe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sHAYEnJe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D62AEC116D0; Sat, 28 Feb 2026 17:44:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300688; bh=ujKkFQFpaopOnq3N33y07y7T0GQ1Edd0brGyWkvGKrk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sHAYEnJeWYyWTpA3qcMsrDJU0yU6RnmkW7E+h/YwXO8XR6fCqQVuYJfBli0pJwCMR kRaTUjy1GpUQWUiwA64Sd+64ExgScYk1tvLt9n0sjipbY/djPIeJw25aaDMOHvrloB 3UNtX4gMZg/4uAJyW1hVDnVIWAtI4xnBki3+hYOb08Pit9yfbkFs+HAm+nkcFu8L4L 7IdY/hYzOhv71iQvKkAncMsKCbqeeyyosYfuUlrzKT8Ccptdt9OgTjgeXK1b5ndpbs dyONSsYtOplrbe4u6laKoqP1XXXKQ3+yFKCg/txwjRW1N07WIimepk8gmTdVaIZpF2 PyuQV6oqYvEFQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Schnelle , Benjamin Block , Bjorn Helgaas , Gerd Bayer , Sasha Levin Subject: [PATCH 6.19 724/844] Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV" Date: Sat, 28 Feb 2026 12:30:37 -0500 Message-ID: <20260228173244.1509663-725-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Schnelle [ Upstream commit 2fa119c0e5e528453ebae9e70740e8d2d8c0ed5a ] This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+= 0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_r= emove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on. Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/= disabling SR-IOV") Reported-by: Benjamin Block Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Benjamin Block Acked-by: Gerd Bayer Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-1-dac4925a7621= @linux.ibm.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/iov.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index 00784a60ba80b..7de5b18647beb 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -629,18 +629,15 @@ static int sriov_add_vfs(struct pci_dev *dev, u16 num= _vfs) if (dev->no_vf_scan) return 0; =20 - pci_lock_rescan_remove(); for (i =3D 0; i < num_vfs; i++) { rc =3D pci_iov_add_virtfn(dev, i); if (rc) goto failed; } - pci_unlock_rescan_remove(); return 0; failed: while (i--) pci_iov_remove_virtfn(dev, i); - pci_unlock_rescan_remove(); =20 return rc; } @@ -765,10 +762,8 @@ static void sriov_del_vfs(struct pci_dev *dev) struct pci_sriov *iov =3D dev->sriov; int i; =20 - pci_lock_rescan_remove(); for (i =3D 0; i < iov->num_VFs; i++) pci_iov_remove_virtfn(dev, i); - pci_unlock_rescan_remove(); } =20 static void sriov_disable(struct pci_dev *dev) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5B0540F397; Sat, 28 Feb 2026 17:44:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300689; cv=none; b=O9x3N4aF7C+Ev+R0vyy6BNQV3n4h5Ql+zi+1DGUSKswgZOi0p9R5FoUKJwp76H4gKS+NXbCK5l/BuLVYVH0G6jC3f0T2IfZxd1SlVZrW9NIWXmqexXbp+T641eEZB8eHcgnYdoinBUN0BxX9ynYOPivmN5t4l/qSnk26U8AoPV4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300689; c=relaxed/simple; bh=WZFSXAUJDe6g1AzSqwFAPL0xXDLsa7xxrDe5oto/pqI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jmOz1C0qGhE9wrg3U+xv2kDj+LEwEawM/o7dUi8MMT6RwuhEUqJBRXGtE+BWacw8ZvkFLW7fYqsDJo7lqT8pNAnsWr5tXteLsn5zp/uhsQnvNpuibuXufOHm15lI/9XIG/e3ZYjtxZX0WZq2EDdFpqQrg3oiiXK3t/35QpUZ/bs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GYkWXTcv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GYkWXTcv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE23CC19424; Sat, 28 Feb 2026 17:44:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300689; bh=WZFSXAUJDe6g1AzSqwFAPL0xXDLsa7xxrDe5oto/pqI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GYkWXTcvcL7vNeRpn01rw/bi59L2w+F57MQTm5r5lGCeNAOHwSo2S83qvkSDqD65M SEXLbu3MsBxVxuGd424V4PPoM2GkSS4sSVmLfsK9musnDGKAn2hHzsGZme01G2MfGS 2rcSGzs0SaUORnXPBBgJDmAqAj2u6UZjpCzb+6G08zpLv77X7dSMTJ8qmFva+lj0e0 qoRnZFZaAg4FrXvU1qz2PTXqkcfvNgESjTf6hA15PUMhU5t1ldijTuv1WPfCQd4vZc GvJt+1/SPplLfN0CTyO6zebHkdExDZ05C0RnLD1FSd1mrtKULDYhO2eEqLEEnaltzK 933h9JPvE4W/Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Schnelle , Benjamin Block , Bjorn Helgaas , Gerd Bayer , Sasha Levin Subject: [PATCH 6.19 725/844] PCI/IOV: Fix race between SR-IOV enable/disable and hotplug Date: Sat, 28 Feb 2026 12:30:38 -0500 Message-ID: <20260228173244.1509663-726-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Schnelle [ Upstream commit a5338e365c4559d7b4d7356116b0eb95b12e08d5 ] Commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") tried to fix a race between the VF removal inside sriov_del_vfs() and concurrent hot unplug by taking the PCI rescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lock was also taken in sriov_add_vfs() to protect addition of VFs. This approach however causes deadlock on trying to remove PFs with SR-IOV enabled because PFs disable SR-IOV during removal and this removal happens under the PCI rescan/remove lock. So the original fix had to be reverted. Instead of taking the PCI rescan/remove lock in sriov_add_vfs() and sriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vs hotplug higher up in the callchain by taking the lock in sriov_numvfs_store() before calling into the driver's sriov_configure() callback. Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/= disabling SR-IOV") Reported-by: Benjamin Block Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Benjamin Block Reviewed-by: Gerd Bayer Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-2-dac4925a7621= @linux.ibm.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/iov.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index 7de5b18647beb..4a659c34935e1 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -495,7 +495,9 @@ static ssize_t sriov_numvfs_store(struct device *dev, =20 if (num_vfs =3D=3D 0) { /* disable VFs */ + pci_lock_rescan_remove(); ret =3D pdev->driver->sriov_configure(pdev, 0); + pci_unlock_rescan_remove(); goto exit; } =20 @@ -507,7 +509,9 @@ static ssize_t sriov_numvfs_store(struct device *dev, goto exit; } =20 + pci_lock_rescan_remove(); ret =3D pdev->driver->sriov_configure(pdev, num_vfs); + pci_unlock_rescan_remove(); if (ret < 0) goto exit; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C38C4410786; Sat, 28 Feb 2026 17:44:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300690; cv=none; b=lLuU5W58mu9/Tq06rs0g6/8f9Jl2TaCnzLYf8sJKzYjFOUCm0C9VTLG1UDvlnZzbnH0dxeSkj4lWceyOgIO+e1N7lMxiK21qMHZslUXVy0T+vtzm8wd6yjgLFxg0NS1dzXrsJ6GmraIgTocENLNouD2J3fwyBH4QdXG5HMObkBk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300690; c=relaxed/simple; bh=GJIHd4BqxosNssM6wtIsh7cuiuhdr2Ql99CV3MDksGc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ffMLoeSgGgXmr1uggfvhcDt34fTgBmRrT2jIp/3aC01ZVeMWu7TF0hENcn+MsbGZ1QKMqSQwx8eXWchszFw5A+fyR6Vp+8Dbi/lCVIpFTaHHxwYbOS37RLleB7/PsuP4ExDhokseFTLRDIwPtFS/F8h8YE0j/SqRRtaYKVGGSMQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Mgx4akoK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Mgx4akoK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4B29C19423; Sat, 28 Feb 2026 17:44:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300690; bh=GJIHd4BqxosNssM6wtIsh7cuiuhdr2Ql99CV3MDksGc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Mgx4akoKyo7KHn7PHbOVTvg1nd0Ybyb9129sySv/zeLbjeAnFWpQqSdE9C33AWGY0 7zAsv0Wh1UroxjERacvjb5KO9asg6zMc2CM4/mpP0kyftojVuIQ1yFbVxnSFodWTuy MX94zjjs4rVZFIIBu1jlUcAYMRGvhNmfuj+e+ujycNGl4+uHz+abOH8lfoCGX7wA7u jvweyMZny/nZGg1TCA5vymNgzZF86LcTIF5SBlqigNB4la8RusghjBQlMFATlDqUQW 0rlduwQTE8T2oI8OuNxyaOV4fFPlUSQAoRhLP0HfbgiBvoU6jN/2xu0kNEy2k07IlA ZUTdXj8+GPZbQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Marco Elver , Boqun Feng , David Laight , Will Deacon , Sasha Levin Subject: [PATCH 6.19 726/844] arm64: Fix non-atomic __READ_ONCE() with CONFIG_LTO=y Date: Sat, 28 Feb 2026 12:30:39 -0500 Message-ID: <20260228173244.1509663-727-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marco Elver [ Upstream commit bb0c99e08ab9aa6d04b40cb63c72db9950d51749 ] The implementation of __READ_ONCE() under CONFIG_LTO=3Dy incorrectly qualified the fallback "once" access for types larger than 8 bytes, which are not atomic but should still happen "once" and suppress common compiler optimizations. The cast `volatile typeof(__x)` applied the volatile qualifier to the pointer type itself rather than the pointee. This created a volatile pointer to a non-volatile type, which violated __READ_ONCE() semantics. Fix this by casting to `volatile typeof(*__x) *`. With a defconfig + LTO + debug options build, we see the following functions to be affected: xen_manage_runstate_time (884 -> 944 bytes) xen_steal_clock (248 -> 340 bytes) ^-- use __READ_ONCE() to load vcpu_runstate_info structs Fixes: e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when CO= NFIG_LTO=3Dy") Cc: stable@vger.kernel.org Reviewed-by: Boqun Feng Signed-off-by: Marco Elver Tested-by: David Laight Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/include/asm/rwonce.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonc= e.h index 78beceec10cda..fc0fb42b0b641 100644 --- a/arch/arm64/include/asm/rwonce.h +++ b/arch/arm64/include/asm/rwonce.h @@ -58,7 +58,7 @@ default: \ atomic =3D 0; \ } \ - atomic ? (typeof(*__x))__u.__val : (*(volatile typeof(__x))__x);\ + atomic ? (typeof(*__x))__u.__val : (*(volatile typeof(*__x) *)__x);\ }) =20 #endif /* !BUILD_VDSO */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E70D24107A6; Sat, 28 Feb 2026 17:44:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300692; cv=none; b=r4M+uPXp083VUX74REz3GqHPh8xo2wpybXZ9Bcchaoe96o/IpdskoWEe9tV8A64AuSd/kZvoNjktoP+S6Fg/f77bsCviKWx8Kdcm7QjkjYjjlDe+aCyC58YoiwHeHMANMzM4A8yIfiUmXura1TUH/EyPR9rmOtnWLU/3r2jRpbY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300692; c=relaxed/simple; bh=j60Mn7wCdsu2R+2+Hr/C3VqzHRBv4QO0Kx9Yg/Y9tPU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KCptSH5pHhCk7UqcqIWWzqiLunJMP7fV6cKcdQ6V+aO39xgcof57a87ed0UlXgMnLlHByilU+TP0rvEsj5tGYUM9g/Iez6HRbGHOP3i1tHFH3idZ43O1HdlDp1ymIY3FlQMIyJdDxC5FMjyDLqA9Q7b14KRvw/UrigS3TDicouE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KLT7KcM5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KLT7KcM5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC909C19423; Sat, 28 Feb 2026 17:44:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300691; bh=j60Mn7wCdsu2R+2+Hr/C3VqzHRBv4QO0Kx9Yg/Y9tPU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KLT7KcM5xHcumv/+42fSe5dY40I50rggW6TJ5RSp3cu2JXU6e1wvRe6t3SuB3hji7 ov4oc/cnWHt4a/WYrUEsw+0Sb7zwDypmi5TpQCa7Dvpb9j4ydfS6e26JGSvHV4oIRZ QSCUs/OoAnBWRGXTWj9zwFzsDgeq2/PPKlv3uOTkgntBZqcaKKh+pjCg9wyuzZfLKT V5NELDDlmgcPO46kSiwv0Ik8Yr02jDLbf4ZYPP6HPsY+jHF4OUghJE/v8toa7wEQ6Q i8wxkUkmUS28xm20ORNbGQd6+TfqdvBmttwHzAhDKbdy2J1lTnF+rD8Ymn0wcTBWs5 SJHi4puJkF3dw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Breno Leitao , "Peter Zijlstra (Intel)" , Oleg Nesterov , Andrii Nakryiko , "Masami Hiramatsu (Google)" , Sasha Levin Subject: [PATCH 6.19 727/844] uprobes: Fix incorrect lockdep condition in filter_chain() Date: Sat, 28 Feb 2026 12:30:40 -0500 Message-ID: <20260228173244.1509663-728-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Breno Leitao [ Upstream commit a56a38fd9196fc89401e498d70b7aa9c9679fa6e ] The list_for_each_entry_rcu() in filter_chain() uses rcu_read_lock_trace_held() as the lockdep condition, but the function holds consumer_rwsem, not the RCU trace lock. This gives me the following output when running with some locking debug option enabled: kernel/events/uprobes.c:1141 RCU-list traversed in non-reader section!! filter_chain register_for_each_vma uprobe_unregister_nosync __probe_event_disable Remove the incorrect lockdep condition since the rwsem provides sufficient protection for the list traversal. Fixes: cc01bd044e6a ("uprobes: travers uprobe's consumer list locklessly un= der SRCU protection") Signed-off-by: Breno Leitao Signed-off-by: Peter Zijlstra (Intel) Acked-by: Oleg Nesterov Acked-by: Andrii Nakryiko Acked-by: Masami Hiramatsu (Google) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260128-uprobe_rcu-v2-1-994ea6d32730@debian= .org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/events/uprobes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 1ab7a7e4efb63..3ec996ca6de0d 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -1138,7 +1138,7 @@ static bool filter_chain(struct uprobe *uprobe, struc= t mm_struct *mm) bool ret =3D false; =20 down_read(&uprobe->consumer_rwsem); - list_for_each_entry_rcu(uc, &uprobe->consumers, cons_node, rcu_read_lock_= trace_held()) { + list_for_each_entry(uc, &uprobe->consumers, cons_node) { ret =3D consumer_filter(uc, mm); if (ret) break; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C0B7494A0E; Sat, 28 Feb 2026 17:44:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300693; cv=none; b=eE15PdVniMU21aQuECUWrfb86YGJjI4sr7mSsGDwpUFvuJ2oO00IBeb8YoTt0GeDBxd8MOpn5MDCKnnv9RuCEOPCezjUWtB5pGTvz8FUni9DodlUBy6H1YtWlTFLn21pOMgMRx7fRTB0zpCMOqb0jcQJ9OseqrbN4oXR+X5KrRM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300693; c=relaxed/simple; bh=Mu0YetehpSMSEnsfyji6J7/9tlJ/cVtHgFo5QB5cRj4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=izYEfXMAp1Y4/bu2OPlXQsG5ZS4B/e1i+P+bqvM9/M11C83/nMWgkodWIGhMD3Wu2VEMoqkdZ+t/GHXV+5ref2wQHtl0L0M+uFGM8EGEBX9Z8L6YwAQlS9tXv79i3EeA1ZTk3OiMqTqD85d+o7u41kDxpiTqYfYu1G5ZKYLb+ec= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eM73i+I5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eM73i+I5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18A9CC19424; Sat, 28 Feb 2026 17:44:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300692; bh=Mu0YetehpSMSEnsfyji6J7/9tlJ/cVtHgFo5QB5cRj4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eM73i+I5iGFEhJf2UGlNArUWyhZZDmU7okKhp1j9z2Dfp4kmv520HOEFX98Vqyft/ azWMhdxV59BOaqKnQyR0eRjx0KF5RT4y7OsG4MlCHusy4mIs+i4o3tTDBRv1WnnNmT /tYOg8yyR2o1GYsMIjiIJ+BcCdoX+ESY6OUt4rS9Nlb4AT9owPDDr+xgDL/gLFgoUK E71nBhzqFMFVpJbgSLGmJ0F0+UmEIm304pb6MbsUt1UzP+hGli1BEU4DygBvUofgoL gVrjq7+inC1wrzcA05pPRyM/mpVF99DgH838ldjghVxDowTF9tBF6RSQDYUHTkZWnl 17YBmMIQmnsQg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Marek Vasut , Geert Uytterhoeven , Stephen Boyd , Sasha Levin Subject: [PATCH 6.19 728/844] clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841 Date: Sat, 28 Feb 2026 12:30:41 -0500 Message-ID: <20260228173244.1509663-729-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marek Vasut [ Upstream commit 5ec820fc28d0b8a0f3890d476b1976f20e8343cc ] The 9FGV0841 has 8 outputs and registers 8 struct clk_hw, make sure there are 8 slots for those newly registered clk_hw pointers, else there is going to be out of bounds write when pointers 4..7 are set into struct rs9_driver_data .clk_dif[4..7] field. Since there are other structure members past this struct clk_hw pointer array, writing to .clk_dif[4..7] fields corrupts both the struct rs9_driver_data content and data around it, sometimes without crashing the kernel. However, the kernel does surely crash when the driver is unbound or during suspend. Fix this, increase the struct clk_hw pointer array size to the maximum output count of 9FGV0841, which is the biggest chip that is supported by this driver. Cc: stable@vger.kernel.org Fixes: f0e5e1800204 ("clk: rs9: Add support for 9FGV0841") Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/CAMuHMdVyQpOBT+Ho+mXY07fndFN9bKJdaaWGn91WOF= nnYErLyg@mail.gmail.com Signed-off-by: Marek Vasut Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/clk/clk-renesas-pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk-renesas-pcie.c b/drivers/clk/clk-renesas-pcie.c index 4c3a5e4eb77ac..f94a9c4d0b670 100644 --- a/drivers/clk/clk-renesas-pcie.c +++ b/drivers/clk/clk-renesas-pcie.c @@ -64,7 +64,7 @@ struct rs9_driver_data { struct i2c_client *client; struct regmap *regmap; const struct rs9_chip_info *chip_info; - struct clk_hw *clk_dif[4]; + struct clk_hw *clk_dif[8]; u8 pll_amplitude; u8 pll_ssc; u8 clk_dif_sr; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA5C7411612; Sat, 28 Feb 2026 17:44:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300694; cv=none; b=WcteEdL34PgJ3UFMZva4n8osTv7WLT/igcwcaC2eQT1EFGLe4qYqtYPKldZ8lqHJzhYux3mOOtbAxawD/QyB3vsleVtFlQwljfx49WC5p4ZQnzYfZG1S7Ml21iEK3In2R+SE6SuyOPMoiJrMGCgc1NjYfSbrjyG7dL+8GgRLQXE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300694; c=relaxed/simple; bh=bK24Ld8ohx06yJGKtz7JW7F1nt/8Zi1GqouzWeD8rKI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K02j/XTKhEW8l0Wjfc8aJM8XRoCgSBLq3ptMapZGP4ZyhieLANjunDvrTRFbiGbKRLkW31CLO7+yWZ/7Et9bLqG3AoI9UYDQ167XmfeucOlxUI7s0WRI2/X6AMKsSFHQz+/Wu/uZro9IMq9vMlURUmBLmlz4U2XaGaZp7FFqqCg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lmp/104S; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lmp/104S" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A643C2BC87; Sat, 28 Feb 2026 17:44:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300693; bh=bK24Ld8ohx06yJGKtz7JW7F1nt/8Zi1GqouzWeD8rKI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lmp/104S6sCzsIKRZqd5ehctcPyymrrfPrONZL71VvLoYTC005wHpnWKAl96gvsHA ycIJ2DoePFzZ47urZDc34B1bvu8Nd0qLNmbVxWCh0ATAIkzs34/PhEzv2HcdCBwu8k GKkKnvz7UdtQiCN9KkYM1hMpBXv5fWzbet4FrnlkK+S7cojbhC9zN7EORGYCfzJ/O3 0ePSVkdHgWhehn7XbVRWXWzalIFRlPwfsQHTIyWnvD2q90Ff3IOap+WDe60YFvY2Ca 0dWwQ+G7q9iMrccwsDOEEgxYwaocZhujqW1KIFpc7uU3xg4V8gZQzt42BgiP7429k0 on6SwV3Ehuc8A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sun YangKai , Boris Burkov , David Sterba , Sasha Levin Subject: [PATCH 6.19 729/844] btrfs: fix periodic reclaim condition Date: Sat, 28 Feb 2026 12:30:42 -0500 Message-ID: <20260228173244.1509663-730-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sun YangKai [ Upstream commit 19eff93dc738e8afaa59cb374b44bb5a162e6c2d ] Problems with current implementation: 1. reclaimable_bytes is signed while chunk_sz is unsigned, causing negative reclaimable_bytes to trigger reclaim unexpectedly 2. The "space must be freed between scans" assumption breaks the two-scan requirement: first scan marks block groups, second scan reclaims them. Without the second scan, no reclamation occurs. Instead, track actual reclaim progress: pause reclaim when block groups will be reclaimed, and resume only when progress is made. This ensures reclaim continues until no further progress can be made. And resume periodic reclaim when there's enough free space. And we take care if reclaim is making any progress now, so it's unnecessary to set periodic_reclaim_ready to false when failed to reclaim a block group. Fixes: 813d4c6422516 ("btrfs: prevent pathological periodic reclaim loops") CC: stable@vger.kernel.org # 6.12+ Suggested-by: Boris Burkov Reviewed-by: Boris Burkov Signed-off-by: Sun YangKai Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/block-group.c | 6 ++++-- fs/btrfs/space-info.c | 21 ++++++++++++--------- 2 files changed, 16 insertions(+), 11 deletions(-) diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index c7be37bcbc48d..25a0d207f10c9 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -1872,6 +1872,7 @@ void btrfs_reclaim_bgs_work(struct work_struct *work) while (!list_empty(&fs_info->reclaim_bgs)) { u64 used; u64 reserved; + u64 old_total; int ret =3D 0; =20 bg =3D list_first_entry(&fs_info->reclaim_bgs, @@ -1937,6 +1938,7 @@ void btrfs_reclaim_bgs_work(struct work_struct *work) } =20 spin_unlock(&bg->lock); + old_total =3D space_info->total_bytes; spin_unlock(&space_info->lock); =20 /* @@ -1989,14 +1991,14 @@ void btrfs_reclaim_bgs_work(struct work_struct *wor= k) reserved =3D 0; spin_lock(&space_info->lock); space_info->reclaim_errors++; - if (READ_ONCE(space_info->periodic_reclaim)) - space_info->periodic_reclaim_ready =3D false; spin_unlock(&space_info->lock); } spin_lock(&space_info->lock); space_info->reclaim_count++; space_info->reclaim_bytes +=3D used; space_info->reclaim_bytes +=3D reserved; + if (space_info->total_bytes < old_total) + btrfs_set_periodic_reclaim_ready(space_info, true); spin_unlock(&space_info->lock); =20 next: diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c index 3f08e450f7961..30aedf596b548 100644 --- a/fs/btrfs/space-info.c +++ b/fs/btrfs/space-info.c @@ -2099,11 +2099,11 @@ static bool is_reclaim_urgent(struct btrfs_space_in= fo *space_info) return unalloc < data_chunk_size; } =20 -static void do_reclaim_sweep(struct btrfs_space_info *space_info, int raid) +static bool do_reclaim_sweep(struct btrfs_space_info *space_info, int raid) { struct btrfs_block_group *bg; int thresh_pct; - bool try_again =3D true; + bool will_reclaim =3D false; bool urgent; =20 spin_lock(&space_info->lock); @@ -2121,7 +2121,7 @@ static void do_reclaim_sweep(struct btrfs_space_info = *space_info, int raid) spin_lock(&bg->lock); thresh =3D mult_perc(bg->length, thresh_pct); if (bg->used < thresh && bg->reclaim_mark) { - try_again =3D false; + will_reclaim =3D true; reclaim =3D true; } bg->reclaim_mark++; @@ -2138,12 +2138,13 @@ static void do_reclaim_sweep(struct btrfs_space_inf= o *space_info, int raid) * If we have any staler groups, we don't touch the fresher ones, but if = we * really need a block group, do take a fresh one. */ - if (try_again && urgent) { - try_again =3D false; + if (!will_reclaim && urgent) { + urgent =3D false; goto again; } =20 up_read(&space_info->groups_sem); + return will_reclaim; } =20 void btrfs_space_info_update_reclaimable(struct btrfs_space_info *space_in= fo, s64 bytes) @@ -2153,7 +2154,8 @@ void btrfs_space_info_update_reclaimable(struct btrfs= _space_info *space_info, s6 lockdep_assert_held(&space_info->lock); space_info->reclaimable_bytes +=3D bytes; =20 - if (space_info->reclaimable_bytes >=3D chunk_sz) + if (space_info->reclaimable_bytes > 0 && + space_info->reclaimable_bytes >=3D chunk_sz) btrfs_set_periodic_reclaim_ready(space_info, true); } =20 @@ -2180,7 +2182,6 @@ static bool btrfs_should_periodic_reclaim(struct btrf= s_space_info *space_info) =20 spin_lock(&space_info->lock); ret =3D space_info->periodic_reclaim_ready; - btrfs_set_periodic_reclaim_ready(space_info, false); spin_unlock(&space_info->lock); =20 return ret; @@ -2194,8 +2195,10 @@ void btrfs_reclaim_sweep(const struct btrfs_fs_info = *fs_info) list_for_each_entry(space_info, &fs_info->space_info, list) { if (!btrfs_should_periodic_reclaim(space_info)) continue; - for (raid =3D 0; raid < BTRFS_NR_RAID_TYPES; raid++) - do_reclaim_sweep(space_info, raid); + for (raid =3D 0; raid < BTRFS_NR_RAID_TYPES; raid++) { + if (do_reclaim_sweep(space_info, raid)) + btrfs_set_periodic_reclaim_ready(space_info, false); + } } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCF0F41162C; Sat, 28 Feb 2026 17:44:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300694; cv=none; b=F19rvv5EJ5m9f84YAAMNdICs7KKMaG6nLN7nkhn5AeMJAJGTN8ViZuQ0vov2+hLcCP/ioo+HOHCOjf2DPq49+917kXtjRAxl5wIWqYA0smVhi4/5y6mYdpmbZF3nsRZosmY2z3bbWTN0dCsMDwhdrYNn4TeVWP4Um/CK99wQJHY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300694; c=relaxed/simple; bh=uFmPrhAMgpqXea1OZKq/YcQkGw59/awQ2V/rHRDjTy0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H+t7SsT+go659slIjKqgctVvWemGtMU0+2TGU/ceU3q3Z7dLx5PCZ48q+pv6OKmGtTfu4WG9jZ21fVFrVD3J/Vi1sDp7hNUwUHE+XqPuA1+8iqwnPcl2l7MQl29n57jyBMOuvjQ2Ugacmhdpkl377dYSXesvrffiE7Lu0QMO22o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tqdwxDyL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tqdwxDyL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 011A1C116D0; Sat, 28 Feb 2026 17:44:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300694; bh=uFmPrhAMgpqXea1OZKq/YcQkGw59/awQ2V/rHRDjTy0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tqdwxDyLujQUsOcq/6Bn3AMZTXnfHjuM2MdaVkzokTnIXwmfTOromdiXusj9NOOOv zmKSxRF5qbuI/zr1ADAxnxRfw3Xj3+Y0l/zGy4kmmvWvUH+2yGS14SYV1cPabfiKKo +g8e+UmAutswDSAr8UVsiKParAKSnke+q7dLfYDmDqVJ8c0eM+Equo6+WPihf2N3sK /OIXSAwX22Ivg1JUkyMOTmtuckdg72Z1g1hpaVVTgqerIbetseSwYiaiRRG8tKSy6h Aqk1oIQBek0y3cwrwwJ3lI5qx6amrpI4Q4Mn4CqOiJ6L9bnyAjX8i4peMAluXHZNtT hgkBlDz+JV88A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Naohiro Aota , Johannes Thumshirn , David Sterba , Sasha Levin Subject: [PATCH 6.19 730/844] btrfs: zoned: fixup last alloc pointer after extent removal for RAID1 Date: Sat, 28 Feb 2026 12:30:43 -0500 Message-ID: <20260228173244.1509663-731-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Naohiro Aota [ Upstream commit dda3ec9ee6b3e120603bff1b798f25b51e54ac5d ] When a block group is composed of a sequential write zone and a conventional zone, we recover the (pseudo) write pointer of the conventional zone using the end of the last allocated position. However, if the last extent in a block group is removed, the last extent position will be smaller than the other real write pointer position. Then, that will cause an error due to mismatch of the write pointers. We can fixup this case by moving the alloc_offset to the corresponding write pointer position. Fixes: 568220fa9657 ("btrfs: zoned: support RAID0/1/10 on top of raid strip= e tree") CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/zoned.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c index 359a98e6de851..f27ba6e9b47d5 100644 --- a/fs/btrfs/zoned.c +++ b/fs/btrfs/zoned.c @@ -1490,6 +1490,21 @@ static int btrfs_load_block_group_raid1(struct btrfs= _block_group *bg, /* In case a device is missing we have a cap of 0, so don't use it. */ bg->zone_capacity =3D min_not_zero(zone_info[0].capacity, zone_info[1].ca= pacity); =20 + /* + * When the last extent is removed, last_alloc can be smaller than the ot= her write + * pointer. In that case, last_alloc should be moved to the corresponding= write + * pointer position. + */ + for (i =3D 0; i < map->num_stripes; i++) { + if (zone_info[i].alloc_offset =3D=3D WP_MISSING_DEV || + zone_info[i].alloc_offset =3D=3D WP_CONVENTIONAL) + continue; + if (last_alloc <=3D zone_info[i].alloc_offset) { + last_alloc =3D zone_info[i].alloc_offset; + break; + } + } + for (i =3D 0; i < map->num_stripes; i++) { if (zone_info[i].alloc_offset =3D=3D WP_MISSING_DEV) continue; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9E0B494A13; Sat, 28 Feb 2026 17:44:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300695; cv=none; b=eh3OKwB32bPO6gJgd096xY7qadABYdZ1sXv7QaqbxvCXzsKKcklpzc1oBPTUniE+gSSAg/vVSEut2UnE0DlSMPrhkCyBuSD1uza/j3E7YGitlsj1SFQ6ysVr2BVfbH9N8LLSuow4K+9TFfHX6D6y+9VuCi+xn5B9XggSGfCnZHs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300695; c=relaxed/simple; bh=xXjaISQWB5K+hLOvfvyVDRNcW/9pv1KrNdhC60jFPYI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nAVKhBA5Mhvvst/ami+ZIldJXWpqTlXmwuXLHjLniEeGHdOWbCupeqLxc2IMwtmxmqg8JP1gD3xOdhTaA50MSZhQJTcSERl2ysq+86QEkf2z1pfkdBI/NoAlVj3zc6p1sm6bcgPf2BASQgacMGfbXixSdeR9Vc9OZB2eGXQc/eI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IXHErwXH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IXHErwXH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB952C19425; Sat, 28 Feb 2026 17:44:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300695; bh=xXjaISQWB5K+hLOvfvyVDRNcW/9pv1KrNdhC60jFPYI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IXHErwXHgDFLtOvEfWKXcBcR24b3daU6A5Gg9ks1vxJMMZz1Kg3kwCf2Jviyw1M1H lK96WQHedzKGn9tqXpj96zBHXHkJ/uKuk9fFG6kAdcbz09hFOsgR5BnoVSCxz5opDE KjUCVmn4LbuX+md54mRYZyIIhAGrDzHeIP8MtqItUOs5QiaMVXHVXYqc12dogwhgiI JUJaMDtFfUZETiS5cno/ZjchfP5UVoyVbY0dYH4KE4X5drJjqGi1xs6RjxmYWePxGj Hveu5CRl739O2dWdk2jwt149TeUga/IMmRpj34QdzR9O8t5Nu20HoecbQ5wmAuBUYP kMn4YBDK5pk0w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Naohiro Aota , Johannes Thumshirn , David Sterba , Sasha Levin Subject: [PATCH 6.19 731/844] btrfs: zoned: fixup last alloc pointer after extent removal for DUP Date: Sat, 28 Feb 2026 12:30:44 -0500 Message-ID: <20260228173244.1509663-732-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Naohiro Aota [ Upstream commit e2d848649e64de39fc1b9c64002629b4daa1105d ] When a block group is composed of a sequential write zone and a conventional zone, we recover the (pseudo) write pointer of the conventional zone using the end of the last allocated position. However, if the last extent in a block group is removed, the last extent position will be smaller than the other real write pointer position. Then, that will cause an error due to mismatch of the write pointers. We can fixup this case by moving the alloc_offset to the corresponding write pointer position. Fixes: c0d90a79e8e6 ("btrfs: zoned: fix alloc_offset calculation for partly= conventional block groups") CC: stable@vger.kernel.org # 6.16+ Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/zoned.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c index f27ba6e9b47d5..6c06581954181 100644 --- a/fs/btrfs/zoned.c +++ b/fs/btrfs/zoned.c @@ -1449,6 +1449,20 @@ static int btrfs_load_block_group_dup(struct btrfs_b= lock_group *bg, return -EIO; } =20 + /* + * When the last extent is removed, last_alloc can be smaller than the ot= her write + * pointer. In that case, last_alloc should be moved to the corresponding= write + * pointer position. + */ + for (int i =3D 0; i < map->num_stripes; i++) { + if (zone_info[i].alloc_offset =3D=3D WP_CONVENTIONAL) + continue; + if (last_alloc <=3D zone_info[i].alloc_offset) { + last_alloc =3D zone_info[i].alloc_offset; + break; + } + } + if (zone_info[0].alloc_offset =3D=3D WP_CONVENTIONAL) zone_info[0].alloc_offset =3D last_alloc; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB9F0411E20; Sat, 28 Feb 2026 17:44:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300696; cv=none; b=Pn5LeShLPEl6y2wY48JcF+iyRo38p/kN6M6qxFwNlUxOTuo4g2SRx+oRVm+OyWBFdykNRWFCUV6+TwEb4ViNiUs064JMPOuwR8Fy2wPqyhklmUUtNMXP4YGwn49rx0r/B4zLfzwS5F8UZVLhYQTkBT476ZxxfdXFt1sneO7JRnw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300696; c=relaxed/simple; bh=quVWn0vnLdm39flO7X+zwsc7svemaACy8zQ4FtMLFLo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Px54L32S3qrRaYewOXmNuvqsPKtXrBK7VXRLwOb3y+2wm9kH3SfdUq6GwK2SZcIEj8SDUHDGUhTPMtMcdwoEmynuYqmRc1zvvhtx9QXzFBIm+tR5q2Gqn5UKiMOo5PQpLffbnX4cLXFh6FTZ8s6DZj1b1OAKN9BwxWhyNHiDkro= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NTI+sCAZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NTI+sCAZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0BDDC2BC87; Sat, 28 Feb 2026 17:44:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300696; bh=quVWn0vnLdm39flO7X+zwsc7svemaACy8zQ4FtMLFLo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NTI+sCAZ27GR2ZVpakWrw9bwVso7UO4vjh6QiKuqKNWupjM7M6qXFNv93ukLgxg3G 8IPIS9EC6AZzvPKpS3TrYpP+khtTDeJdcKSsQomHx3y/nAItgmA/r/pOwttU8lucV4 NacrpWYfJHZ0Fet0i7i6uYbIBY3saat4198BvWYJrCZgK5LGiqgfZuadbAgrtinNoY U/i3Reqm0k4rx5rvs4WoVmVrTaY7VOAPDdWBhaLstlrtQxgcFUFCqVy1uLHWzBbhQs GgPv9b6DGVXpISHrGsZnBt3aI6/+otd8O513w4FI+QxWpuG6MSTbuBTW/qJWEpo1gR 81Rq+xvV444Nw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Naohiro Aota , Johannes Thumshirn , David Sterba , Sasha Levin Subject: [PATCH 6.19 732/844] btrfs: zoned: fixup last alloc pointer after extent removal for RAID0/10 Date: Sat, 28 Feb 2026 12:30:45 -0500 Message-ID: <20260228173244.1509663-733-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Naohiro Aota [ Upstream commit 52ee9965d09b2c56a027613db30d1fb20d623861 ] When a block group is composed of a sequential write zone and a conventional zone, we recover the (pseudo) write pointer of the conventional zone using the end of the last allocated position. However, if the last extent in a block group is removed, the last extent position will be smaller than the other real write pointer position. Then, that will cause an error due to mismatch of the write pointers. We can fixup this case by moving the alloc_offset to the corresponding write pointer position. Fixes: 568220fa9657 ("btrfs: zoned: support RAID0/1/10 on top of raid strip= e tree") CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/zoned.c | 194 +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 179 insertions(+), 15 deletions(-) diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c index 6c06581954181..392e6ad874cc7 100644 --- a/fs/btrfs/zoned.c +++ b/fs/btrfs/zoned.c @@ -1560,7 +1560,9 @@ static int btrfs_load_block_group_raid0(struct btrfs_= block_group *bg, { struct btrfs_fs_info *fs_info =3D bg->fs_info; u64 stripe_nr =3D 0, stripe_offset =3D 0; + u64 prev_offset =3D 0; u32 stripe_index =3D 0; + bool has_partial =3D false, has_conventional =3D false; =20 if ((map->type & BTRFS_BLOCK_GROUP_DATA) && !fs_info->stripe_root) { btrfs_err(fs_info, "zoned: data %s needs raid-stripe-tree", @@ -1568,6 +1570,35 @@ static int btrfs_load_block_group_raid0(struct btrfs= _block_group *bg, return -EINVAL; } =20 + /* + * When the last extent is removed, last_alloc can be smaller than the ot= her write + * pointer. In that case, last_alloc should be moved to the corresponding= write + * pointer position. + */ + for (int i =3D 0; i < map->num_stripes; i++) { + u64 alloc; + + if (zone_info[i].alloc_offset =3D=3D WP_MISSING_DEV || + zone_info[i].alloc_offset =3D=3D WP_CONVENTIONAL) + continue; + + stripe_nr =3D zone_info[i].alloc_offset >> BTRFS_STRIPE_LEN_SHIFT; + stripe_offset =3D zone_info[i].alloc_offset & BTRFS_STRIPE_LEN_MASK; + if (stripe_offset =3D=3D 0 && stripe_nr > 0) { + stripe_nr--; + stripe_offset =3D BTRFS_STRIPE_LEN; + } + alloc =3D ((stripe_nr * map->num_stripes + i) << BTRFS_STRIPE_LEN_SHIFT)= + + stripe_offset; + last_alloc =3D max(last_alloc, alloc); + + /* Partially written stripe found. It should be last. */ + if (zone_info[i].alloc_offset & BTRFS_STRIPE_LEN_MASK) + break; + } + stripe_nr =3D 0; + stripe_offset =3D 0; + if (last_alloc) { u32 factor =3D map->num_stripes; =20 @@ -1581,7 +1612,7 @@ static int btrfs_load_block_group_raid0(struct btrfs_= block_group *bg, continue; =20 if (zone_info[i].alloc_offset =3D=3D WP_CONVENTIONAL) { - + has_conventional =3D true; zone_info[i].alloc_offset =3D btrfs_stripe_nr_to_offset(stripe_nr); =20 if (stripe_index > i) @@ -1590,6 +1621,28 @@ static int btrfs_load_block_group_raid0(struct btrfs= _block_group *bg, zone_info[i].alloc_offset +=3D stripe_offset; } =20 + /* Verification */ + if (i !=3D 0) { + if (unlikely(prev_offset < zone_info[i].alloc_offset)) { + btrfs_err(fs_info, + "zoned: stripe position disorder found in block group %llu", + bg->start); + return -EIO; + } + + if (unlikely(has_partial && + (zone_info[i].alloc_offset & BTRFS_STRIPE_LEN_MASK))) { + btrfs_err(fs_info, + "zoned: multiple partial written stripe found in block group %llu", + bg->start); + return -EIO; + } + } + prev_offset =3D zone_info[i].alloc_offset; + + if ((zone_info[i].alloc_offset & BTRFS_STRIPE_LEN_MASK) !=3D 0) + has_partial =3D true; + if (test_bit(0, active) !=3D test_bit(i, active)) { if (unlikely(!btrfs_zone_activate(bg))) return -EIO; @@ -1601,6 +1654,19 @@ static int btrfs_load_block_group_raid0(struct btrfs= _block_group *bg, bg->alloc_offset +=3D zone_info[i].alloc_offset; } =20 + /* Check if all devices stay in the same stripe row. */ + if (unlikely(zone_info[0].alloc_offset - + zone_info[map->num_stripes - 1].alloc_offset > BTRFS_STRIPE_LEN)) { + btrfs_err(fs_info, "zoned: stripe gap too large in block group %llu", bg= ->start); + return -EIO; + } + + if (unlikely(has_conventional && bg->alloc_offset < last_alloc)) { + btrfs_err(fs_info, "zoned: allocated extent stays beyond write pointers = %llu %llu", + bg->alloc_offset, last_alloc); + return -EIO; + } + return 0; } =20 @@ -1611,8 +1677,11 @@ static int btrfs_load_block_group_raid10(struct btrf= s_block_group *bg, u64 last_alloc) { struct btrfs_fs_info *fs_info =3D bg->fs_info; + u64 AUTO_KFREE(raid0_allocs); u64 stripe_nr =3D 0, stripe_offset =3D 0; u32 stripe_index =3D 0; + bool has_partial =3D false, has_conventional =3D false; + u64 prev_offset =3D 0; =20 if ((map->type & BTRFS_BLOCK_GROUP_DATA) && !fs_info->stripe_root) { btrfs_err(fs_info, "zoned: data %s needs raid-stripe-tree", @@ -1620,6 +1689,60 @@ static int btrfs_load_block_group_raid10(struct btrf= s_block_group *bg, return -EINVAL; } =20 + raid0_allocs =3D kcalloc(map->num_stripes / map->sub_stripes, sizeof(*rai= d0_allocs), + GFP_NOFS); + if (!raid0_allocs) + return -ENOMEM; + + /* + * When the last extent is removed, last_alloc can be smaller than the ot= her write + * pointer. In that case, last_alloc should be moved to the corresponding= write + * pointer position. + */ + for (int i =3D 0; i < map->num_stripes; i +=3D map->sub_stripes) { + u64 alloc =3D zone_info[i].alloc_offset; + + for (int j =3D 1; j < map->sub_stripes; j++) { + int idx =3D i + j; + + if (zone_info[idx].alloc_offset =3D=3D WP_MISSING_DEV || + zone_info[idx].alloc_offset =3D=3D WP_CONVENTIONAL) + continue; + if (alloc =3D=3D WP_MISSING_DEV || alloc =3D=3D WP_CONVENTIONAL) { + alloc =3D zone_info[idx].alloc_offset; + } else if (unlikely(zone_info[idx].alloc_offset !=3D alloc)) { + btrfs_err(fs_info, + "zoned: write pointer mismatch found in block group %llu", + bg->start); + return -EIO; + } + } + + raid0_allocs[i / map->sub_stripes] =3D alloc; + if (alloc =3D=3D WP_CONVENTIONAL) + continue; + if (unlikely(alloc =3D=3D WP_MISSING_DEV)) { + btrfs_err(fs_info, + "zoned: cannot recover write pointer of block group %llu due to missing= device", + bg->start); + return -EIO; + } + + stripe_nr =3D alloc >> BTRFS_STRIPE_LEN_SHIFT; + stripe_offset =3D alloc & BTRFS_STRIPE_LEN_MASK; + if (stripe_offset =3D=3D 0 && stripe_nr > 0) { + stripe_nr--; + stripe_offset =3D BTRFS_STRIPE_LEN; + } + + alloc =3D ((stripe_nr * (map->num_stripes / map->sub_stripes) + + (i / map->sub_stripes)) << + BTRFS_STRIPE_LEN_SHIFT) + stripe_offset; + last_alloc =3D max(last_alloc, alloc); + } + stripe_nr =3D 0; + stripe_offset =3D 0; + if (last_alloc) { u32 factor =3D map->num_stripes / map->sub_stripes; =20 @@ -1629,24 +1752,51 @@ static int btrfs_load_block_group_raid10(struct btr= fs_block_group *bg, } =20 for (int i =3D 0; i < map->num_stripes; i++) { - if (zone_info[i].alloc_offset =3D=3D WP_MISSING_DEV) - continue; + int idx =3D i / map->sub_stripes; =20 - if (test_bit(0, active) !=3D test_bit(i, active)) { - if (unlikely(!btrfs_zone_activate(bg))) - return -EIO; - } else { - if (test_bit(0, active)) - set_bit(BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE, &bg->runtime_flags); + if (raid0_allocs[idx] =3D=3D WP_CONVENTIONAL) { + has_conventional =3D true; + raid0_allocs[idx] =3D btrfs_stripe_nr_to_offset(stripe_nr); + + if (stripe_index > idx) + raid0_allocs[idx] +=3D BTRFS_STRIPE_LEN; + else if (stripe_index =3D=3D idx) + raid0_allocs[idx] +=3D stripe_offset; } =20 - if (zone_info[i].alloc_offset =3D=3D WP_CONVENTIONAL) { - zone_info[i].alloc_offset =3D btrfs_stripe_nr_to_offset(stripe_nr); + if ((i % map->sub_stripes) =3D=3D 0) { + /* Verification */ + if (i !=3D 0) { + if (unlikely(prev_offset < raid0_allocs[idx])) { + btrfs_err(fs_info, + "zoned: stripe position disorder found in block group %llu", + bg->start); + return -EIO; + } =20 - if (stripe_index > (i / map->sub_stripes)) - zone_info[i].alloc_offset +=3D BTRFS_STRIPE_LEN; - else if (stripe_index =3D=3D (i / map->sub_stripes)) - zone_info[i].alloc_offset +=3D stripe_offset; + if (unlikely(has_partial && + (raid0_allocs[idx] & BTRFS_STRIPE_LEN_MASK))) { + btrfs_err(fs_info, + "zoned: multiple partial written stripe found in block group %llu", + bg->start); + return -EIO; + } + } + prev_offset =3D raid0_allocs[idx]; + + if ((raid0_allocs[idx] & BTRFS_STRIPE_LEN_MASK) !=3D 0) + has_partial =3D true; + } + + if (zone_info[i].alloc_offset =3D=3D WP_MISSING_DEV || + zone_info[i].alloc_offset =3D=3D WP_CONVENTIONAL) + zone_info[i].alloc_offset =3D raid0_allocs[idx]; + + if (test_bit(0, active) !=3D test_bit(i, active)) { + if (unlikely(!btrfs_zone_activate(bg))) + return -EIO; + } else if (test_bit(0, active)) { + set_bit(BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE, &bg->runtime_flags); } =20 if ((i % map->sub_stripes) =3D=3D 0) { @@ -1655,6 +1805,20 @@ static int btrfs_load_block_group_raid10(struct btrf= s_block_group *bg, } } =20 + /* Check if all devices stay in the same stripe row. */ + if (unlikely(zone_info[0].alloc_offset - + zone_info[map->num_stripes - 1].alloc_offset > BTRFS_STRIPE_LEN)) { + btrfs_err(fs_info, "zoned: stripe gap too large in block group %llu", + bg->start); + return -EIO; + } + + if (unlikely(has_conventional && bg->alloc_offset < last_alloc)) { + btrfs_err(fs_info, "zoned: allocated extent stays beyond write pointers = %llu %llu", + bg->alloc_offset, last_alloc); + return -EIO; + } + return 0; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C0FC1411E38; Sat, 28 Feb 2026 17:44:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300697; cv=none; b=hoor61G4dc2Z5qqtwI9AZhADKTunvgqkpDKNSecC+JIviNBmibAtUAZa1wWplOdP55BVLzplCu0alqI5dnJ02iCIFXPU8zPAX/zCgB76V0rgFaOBK/vekfDcVe7jjADHCLDGRUjfW0YcF5HMrkH+RaMgX2shl4XmEx+ry8Tpyc8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300697; c=relaxed/simple; bh=8pP6ycsp0TqupfNl0Q2wbJsvX68uudcx08pR2T86QMA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Z/xiRgkNZmpDBTg90Z4B9V3BNpPLXk45Uoeij+EAtzTXHpaKGosXnJwgUEV+MQFq6IZdGADLyUGR4WOHWiV52r1o/KPuFd0PS7CAwVbP0fpCOheU531IDjTlfl8AmONwiBM/QraTvUEd9xAUmbgYzzxJiY6x3P+JevE6XvA4JRc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N/3vXYGD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N/3vXYGD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA38DC116D0; Sat, 28 Feb 2026 17:44:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300697; bh=8pP6ycsp0TqupfNl0Q2wbJsvX68uudcx08pR2T86QMA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N/3vXYGDZGF3rOwSckQzeafV0ZtRYbS0PWdDfmGqv+8DDjVBx+CBJMvlvTtDPrUem tbPXayqZlBmq4F9VneM6mkZme9t9rzS4Gbigg4ayLjN8FqgWtcKOKULvB+NS1QGYBy v3KOX64natllCJTEmfTUmbh+b4GClLSqETOwDjlDWdOwEIaXD/FkE6dBg8wXi2b3xf 8UFZ9VmBI1cbiqbOIPelqZX5Zvd93P8f/MLk2/vGc/vpSyA7ZJ1UEJtxwx1XHSSgq9 GzGYvZ4nDgvoFLcEdn73Yf85tjndDn2bTrehZhYRPuuFoobVJYOlUcuD/1Bt53miFe C49JytzwrOfAA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: jinbaohong , Qu Wenruo , Robbie Ko , Filipe Manana , David Sterba , Sasha Levin Subject: [PATCH 6.19 733/844] btrfs: continue trimming remaining devices on failure Date: Sat, 28 Feb 2026 12:30:46 -0500 Message-ID: <20260228173244.1509663-734-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: jinbaohong [ Upstream commit 912d1c6680bdb40b72b1b9204706f32b6eb842c3 ] Commit 93bba24d4b5a ("btrfs: Enhance btrfs_trim_fs function to handle error better") intended to make device trimming continue even if one device fails, tracking failures and reporting them at the end. However, it used 'break' instead of 'continue', causing the loop to exit on the first device failure. Fix this by replacing 'break' with 'continue'. Fixes: 93bba24d4b5a ("btrfs: Enhance btrfs_trim_fs function to handle error= better") CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Qu Wenruo Signed-off-by: Robbie Ko Signed-off-by: jinbaohong Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/btrfs/extent-tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 8bdb609f58a7e..bc0db6593f329 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -6588,7 +6588,7 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, stru= ct fstrim_range *range) if (ret) { dev_failed++; dev_ret =3D ret; - break; + continue; } } mutex_unlock(&fs_devices->device_list_mutex); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 02EAC4128A3; Sat, 28 Feb 2026 17:44:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300699; cv=none; b=PMbtX8oCQrgH9cGbqAaXS9cRwuqtYS2UsXIN4xzrm/oht2sXIeyktv4LPvhhYoZ6eXiIZct8nxqj5rnVA9AS2kF1JuJFPrDtw2bsXgJRiZFKq26oLV5O0KSgcuLf/7O4BqnVkQjizf+Jwozv5D7hy2zu6FEWT/jhHgHfXhXFwKQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300699; c=relaxed/simple; bh=zmUkgrODlewI86AyQNZRMWa4ZdLSddABDb6WSKeLnjA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=scD2tbW8ghd1nXscLpV1YuoCQzfUIpchg3HOaHZ29ffrQYS8Z4Y0b+jDhMfIwpRfYMggGX303+tTu89nSj0sjS0+OtGcWaI3pHpfy8z1M58WJqxZcOCJyy+JUf5lKBRZDGkejDU4X0U67rSlVyS5t8hzP5JKPznqFilKAnF6djU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LBqX4Tl8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LBqX4Tl8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8525C19425; Sat, 28 Feb 2026 17:44:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300698; bh=zmUkgrODlewI86AyQNZRMWa4ZdLSddABDb6WSKeLnjA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LBqX4Tl8glZmHrPvOFi3zqTZG9iJMGN/55gRjedHGIuEHXyv9wwALwzRBSDhh0XlX nOMjrdO+iSB0cm2uzXzwr++Hbvs/FD/dPgR4vI8QWcpclvRct8dWI3HdLKGsQTVUn0 WMGNXvqHHLuv1vqc1946FHknxp1vnnXFxOHws0c6H2CyGMSPvDj2Ij7zv9SpzLgF4R gt6iuqwuv2mtRrQu89t3UbMothsAwHQ36IrYF57JH6qDDjLYcROH89SsyVSbCxZJuX Aj821CXQwF921Wgh2qGowgatDZGacayGHmMIE716yD/J21jjjccRDzkxFkWHzO4kPa nreSVwiLkfghw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yu Zhang , Jason Gunthorpe , Joerg Roedel , Sasha Levin Subject: [PATCH 6.19 734/844] iommupt: Always add IOVA range to iotlb_gather in gather_range_pages() Date: Sat, 28 Feb 2026 12:30:47 -0500 Message-ID: <20260228173244.1509663-735-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yu Zhang [ Upstream commit b48ca920613858b477f75946907e72c74570af05 ] Add current (iova, len) to the iotlb gather, regardless of the setting of PT_FEAT_FLUSH_RANGE or PT_FEAT_FLUSH_RANGE_NO_GAPS. In gather_range_pages(), the current IOVA range is only added to iotlb_gather when PT_FEAT_FLUSH_RANGE is set. Yet a virtual IOMMU with NpCache uses only PT_FEAT_FLUSH_RANGE_NO_GAPS. In that case, iotlb_gather will stay empty (start=3DULONG_MAX, end=3D0) after initialization, and the current (iova, len) will not be added to the iotlb_gather, causing subsequent iommu_iotlb_sync() to perform IOTLB invalidation with wrong parameters (e.g., amd_iommu_iotlb_sync() computes size from gather->end - gather->start + 1, leading to an invalid range). The disjoint check and sync for PT_FEAT_FLUSH_RANGE_NO_GAPS remain unchanged: when the new range is disjoint from the existing gather, we still sync first and then add the new range, so semantics for NO_GAPS are preserved. Fixes: 7c53f4238aa8 ("iommupt: Add unmap_pages op") Cc: stable@vger.kernel.org Reviewed-by: Jason Gunthorpe Signed-off-by: Yu Zhang Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/iommu/generic_pt/iommu_pt.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/iommu/generic_pt/iommu_pt.h b/drivers/iommu/generic_pt= /iommu_pt.h index d575f3ba9d341..3e33fe64feab2 100644 --- a/drivers/iommu/generic_pt/iommu_pt.h +++ b/drivers/iommu/generic_pt/iommu_pt.h @@ -58,10 +58,9 @@ static void gather_range_pages(struct iommu_iotlb_gather= *iotlb_gather, * Note that the sync frees the gather's free list, so we must * not have any pages on that list that are covered by iova/len */ - } else if (pt_feature(common, PT_FEAT_FLUSH_RANGE)) { - iommu_iotlb_gather_add_range(iotlb_gather, iova, len); } =20 + iommu_iotlb_gather_add_range(iotlb_gather, iova, len); iommu_pages_list_splice(free_list, &iotlb_gather->freelist); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A62874128B8; Sat, 28 Feb 2026 17:44:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300699; cv=none; b=JSzpVISNcQeqowjqH7z6AgPoz0PP2lATgqNCdHrVrVy2g3AgLxH3kIzyjlepxzyf/0ireG9G1p+tXONhz86SIAFcywY5XoL481vTJN0klY6ht831N/G7zRFXlrlPT4+eDZ/V5vlqSunNzRiOQCfGkCyYJMySJw8so966cU1/suc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300699; c=relaxed/simple; bh=3gm6q3lXq5wpQLGyI1ry515LPwMSLEfQoxZvlknDrTk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WXqq5UaqYU5yOo/QvHfzJ2aBSbDXheORd/TIiee6kdKf4Wm/sPx1lTaatWMcpOvm8+SdTkwHqECdeBJhdIUc2/j104GaW0rD9kfcH1ouUaPZm+2VkRX2kiIV+v8Rij5T8ibb4scwAzDxdTPXFXcVgfHE93ms8IDlvWNoD3rR+oo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GWe36I4n; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GWe36I4n" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC229C2BC87; Sat, 28 Feb 2026 17:44:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300699; bh=3gm6q3lXq5wpQLGyI1ry515LPwMSLEfQoxZvlknDrTk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GWe36I4n06mD1M744CWOSuUUr0bj1fEJfTRaX5aZJP7fc2+rxaq+ZvWi95fZvnoCM MDHm+sfyvM8WXvHPMqmLVgqpZFyyJ3rKVdozQmqWtNzZPnO8Myhk//17aexU7Cv6do M2rN8kai+H6O4yFsZzy1J7B0StKbwd5jIHhpRSr8+rIWxD9kMuortMTiKZfzI5/hRi iEirMF38RUudpuGesa+VWssP+ApS2KShqmTfRGwnrHkXNaseowm85Ajy3h8rWOEZLY 2bOfLjRLilwMOKD8rI3qrHDN4DXvNpM9utAOdc9nanVvRboOF+6THNIh3PjHs9BQ1R +0HK0dbZ0rUbg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peng Fan , Daniel Baluta , Mathieu Poirier , Sasha Levin Subject: [PATCH 6.19 735/844] remoteproc: imx_rproc: Fix invalid loaded resource table detection Date: Sat, 28 Feb 2026 12:30:48 -0500 Message-ID: <20260228173244.1509663-736-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peng Fan [ Upstream commit 26aa5295010ffaebcf8f1991c53fa7cf2ee1b20d ] imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a "rsc-table" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash. Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find= _loaded_rsc_table") Cc: stable@vger.kernel.org Signed-off-by: Peng Fan Acked-by: Daniel Baluta Link: https://lore.kernel.org/r/20260129-imx-rproc-fix-v3-1-fc4e41e6e750@nx= p.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/remoteproc/imx_rproc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c index 33f21ab24c921..d93bf5134d6f0 100644 --- a/drivers/remoteproc/imx_rproc.c +++ b/drivers/remoteproc/imx_rproc.c @@ -609,6 +609,10 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rpro= c, const struct firmware * { struct imx_rproc *priv =3D rproc->priv; =20 + /* No resource table in the firmware */ + if (!rproc->table_ptr) + return NULL; + if (priv->rsc_table) return (struct resource_table *)priv->rsc_table; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B945B352927; Sat, 28 Feb 2026 17:45:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300700; cv=none; b=AdENbF2A16N8M0V84P5fUAtVwCYkr/e6b5/pNXJLNLwbkX0Q5nlnAxgRU820kRBOGegzj5d5kngwhd/cjtis4w6dfT46ORayjkhGT2DZksjth6nTWC8IS85+wCAJU0FErcXUaXg61pkqCYM+YmQMFerYJeqIiluIXsAU4qUnot4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300700; c=relaxed/simple; bh=S7eFNdkVrO8QDXkHBh+Sia2xcyU4ekGamgMGgDtYibg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ImfK8Rgfex5MW0PbPJgqrc3KDvwaeO4Hk24qYjz2jrKhMwt1JPBaMH2/qpyZ+B6vdW2WXwEZgJj+bWeZ/PcCoi1eUCUAsg5E9clDcwJObNculTr1NmENm6V8rE85YFp2Oslj8brsGq4ySAyrevRFRxIWDRkuzOkiD+LkUEjWI08= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HehLMOPm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HehLMOPm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF41EC19425; Sat, 28 Feb 2026 17:44:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300700; bh=S7eFNdkVrO8QDXkHBh+Sia2xcyU4ekGamgMGgDtYibg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HehLMOPmqP9/bsJ+haageM84kMz1sDcz/k2/VvEhnqWrvlBZj9bvqQcJ9NA6ITmuJ +elZ8PQt7aA388CwHwQ/K9UK91VG/JMAwudwdpBfoG/Y3seoICQMXJQDppCCjLRPuT BUjY//zXc9CgHusV7Wnp14JAZ/S0NQuIMugBtpBi9ixQRKCtN+ckhOE3KNRYpY53Fp v32wtHNlF7y/RipQAo6TbrD/4l/dS5vW3fXJY9TPTD35OW1nn0NZwxbxLM9weD0Q6J EWFAQsGMf2fZKKcdXHF+InpWmxYhr8dRHUjQjXOtY1HESd6X0juGALVH/kVYVv1N7G 60119u4JROVqQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Robin Murphy , Ilkka Koskinen , Will Deacon , Sasha Levin Subject: [PATCH 6.19 736/844] perf/arm-cmn: Reject unsupported hardware configurations Date: Sat, 28 Feb 2026 12:30:49 -0500 Message-ID: <20260228173244.1509663-737-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Robin Murphy [ Upstream commit 36c0de02575ce59dfd879eb4ef63d53a68bbf9ce ] So far we've been fairly lax about accepting both unknown CMN models (at least with a warning), and unknown revisions of those which we do know, as although things do frequently change between releases, typically enough remains the same to be somewhat useful for at least some basic bringup checks. However, we also make assumptions of the maximum supported sizes and numbers of things in various places, and there's no guarantee that something new might not be bigger and lead to nasty array overflows. Make sure we only try to run on things that actually match our assumptions and so will not risk memory corruption. We have at least always failed on completely unknown node types, so update that error message for clarity and consistency too. Cc: stable@vger.kernel.org Fixes: 7819e05a0dce ("perf/arm-cmn: Revamp model detection") Reviewed-by: Ilkka Koskinen Signed-off-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/perf/arm-cmn.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c index 651edd73bfcb1..4fbafc4b79843 100644 --- a/drivers/perf/arm-cmn.c +++ b/drivers/perf/arm-cmn.c @@ -2422,6 +2422,15 @@ static int arm_cmn_discover(struct arm_cmn *cmn, uns= igned int rgn_offset) arm_cmn_init_node_info(cmn, reg & CMN_CHILD_NODE_ADDR, dn); dn->portid_bits =3D xp->portid_bits; dn->deviceid_bits =3D xp->deviceid_bits; + /* + * Logical IDs are assigned from 0 per node type, so as + * soon as we see one bigger than expected, we can assume + * there are more than we can cope with. + */ + if (dn->logid > CMN_MAX_NODES_PER_EVENT) { + dev_err(cmn->dev, "Node ID invalid for supported CMN versions: %d\n", = dn->logid); + return -ENODEV; + } =20 switch (dn->type) { case CMN_TYPE_DTC: @@ -2471,7 +2480,7 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsi= gned int rgn_offset) break; /* Something has gone horribly wrong */ default: - dev_err(cmn->dev, "invalid device node type: 0x%x\n", dn->type); + dev_err(cmn->dev, "Device node type invalid for supported CMN versions= : 0x%x\n", dn->type); return -ENODEV; } } @@ -2499,6 +2508,10 @@ static int arm_cmn_discover(struct arm_cmn *cmn, uns= igned int rgn_offset) cmn->mesh_x =3D cmn->num_xps; cmn->mesh_y =3D cmn->num_xps / cmn->mesh_x; =20 + if (max(cmn->mesh_x, cmn->mesh_y) > CMN_MAX_DIMENSION) { + dev_err(cmn->dev, "Mesh size invalid for supported CMN versions: %dx%d\n= ", cmn->mesh_x, cmn->mesh_y); + return -ENODEV; + } /* 1x1 config plays havoc with XP event encodings */ if (cmn->num_xps =3D=3D 1) dev_warn(cmn->dev, "1x1 config not fully supported, translate XP events = manually\n"); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F31E4138C1; Sat, 28 Feb 2026 17:45:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300702; cv=none; b=sXT3Ds+6KTY0z/LBfgszeKAMDsZWOk2KH15E8gU27pxXqphy0YK8tkXLxx0gJfXzZkbCBdz+oVwRzVQ9/A0QyHTkC6IINEGxT1a5A5cca+Kt4cx9Qp1roY1iJbRO79mqd+fEGbnp7d/JvdKMtNyCo+3RLLj861HuUCYJ3ATvp78= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300702; c=relaxed/simple; bh=sM9X61E3kqhs+mki2imRDiNuMlmepupUstAlak9zoM0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EKToz24gqvXRiJThTlZhmcP3G2iG3duXd8sWWB4Dr82qKF8UxurxGjL/hVKHa4NcfifA506Vd4ypJ5c6wb9QUvppKQvEfUur5FlBeqZgWr25gCRJgDNs3aYjQ0CTbEsvfNx0oSuCGwZ3Mdwcfx3XOs/x8fGeonVGEyaZDU7Aw0Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MIrgs1QQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MIrgs1QQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E15ADC19424; Sat, 28 Feb 2026 17:45:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300701; bh=sM9X61E3kqhs+mki2imRDiNuMlmepupUstAlak9zoM0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MIrgs1QQw/ihstaS4y2NC11BmaI9bnXwq5e6k7HIv/JTsPl6/uN1f36poYt3aDUnq sOld9MmnszQYppi6U0qRdlgSSayHYwY+mAcfmIzS36c73rKF1ifRdLeycT/v/uxfTF bVDbHYKXO893RGrmULmqY0f3AH5j4n53jpWmKUQ0r9laDE3mweBXr46x03WhvoCQcv aS+Sc8zMkErO1LzFeqq/dQkOc2PrW7X6z+RPZKdI6lScZOi86mwFeXFVGaOoOGNG38 imEbtJrk8+9LFVEpetBV/+K71BipB2WKi/wJc6qj59fB+lsz1pQJNRloOZsxtm8/el EbdpWaZ8N5JTg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Yen , Peter Wang , Bart Van Assche , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 6.19 737/844] scsi: ufs: core: Flush exception handling work when RPM level is zero Date: Sat, 28 Feb 2026 12:30:50 -0500 Message-ID: <20260228173244.1509663-738-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Yen [ Upstream commit f8ef441811ec413717f188f63d99182f30f0f08e ] Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence. Fixes: 57d104c153d3 ("ufs: add UFS power management support") Signed-off-by: Thomas Yen Cc: Stable Tree Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260129165156.956601-1-thomasyen@google.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/ufs/core/ufshcd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index 604043a7533d3..09f0d77d57f02 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -9994,6 +9994,8 @@ static int __ufshcd_wl_suspend(struct ufs_hba *hba, e= num ufs_pm_op pm_op) =20 if (req_dev_pwr_mode =3D=3D UFS_ACTIVE_PWR_MODE && req_link_state =3D=3D UIC_LINK_ACTIVE_STATE) { + ufshcd_disable_auto_bkops(hba); + flush_work(&hba->eeh_work); goto vops_suspend; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD17E2D23A5; Sat, 28 Feb 2026 17:45:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300702; cv=none; b=nACSPsqjxPHDkEhOthzXaTRaVZj1mIhBVSSHAJdj/r64tkL4VzvKUK/NH3wSfP0/GOQbBOnGw/c/BBgGLIdLxRjOT51wMVrkMBW5QV6UE0KcWIsvFsoy5wOx1rZ3pvCsIyLIbZ2QQE47lg091gTNBafbsPiHtN40G476NbbFOmk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300702; c=relaxed/simple; bh=0qRTXaOIE4LNkwWI98+IZd+MNx2AL1wQd1q54OWNNZY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X0C/EoimvuyBb0j77tdH4y7ISlQzuBlMnU5/Fe/SDuizDy/jAKgaQ4xHDXmLTgKJMJQI4NWIyhjwwHU4o1bJS0T7Xy/Z/abFH9zkAJa0zRs1zoN5FbG7WQZUGDfHLyVy0LVNaqPkFh397Z7eJ2MQvA3CRKa0nHM9ZaiZ9arQo9Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S/PwK+aA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S/PwK+aA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECED0C116D0; Sat, 28 Feb 2026 17:45:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300702; bh=0qRTXaOIE4LNkwWI98+IZd+MNx2AL1wQd1q54OWNNZY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S/PwK+aAH7hmufkQXq4/3oieFFX6x24aeulixvEWSyqKFmWg/teLNtFyjUFZzUs7g Omt7IRyXSYNrCexRQZIblj7fKVr5YnDkkYDa348KGd8KEbkuF4Etr0jXBDYNgl16f4 mxosdPo8B+b4wLiakzTgbnyi1qtZPaR2WQ5p3R9yib1JMIs2Y9U+byax2BLDgGtqms 6JQ57Me0MAgW2ghhApnfSd5U8xWgQm1dUadIlXuR35CAbxP9gvNmq6Bg2k5Sg3Djox RC/liQW00nHqEnbhCnmElNS064yXTWwVn6ugGJ4MgaKsxyh+49TjKAdCzNQbtpSWK+ EXgSB42pshwHg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harry Yoo , kernel test robot , Hao Li , Vlastimil Babka , Sasha Levin Subject: [PATCH 6.19 738/844] mm/slab: avoid allocating slabobj_ext array from its own slab Date: Sat, 28 Feb 2026 12:30:51 -0500 Message-ID: <20260228173244.1509663-739-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harry Yoo [ Upstream commit 280ea9c3154b2af7d841f992c9fc79e9d6534e03 ] When allocating slabobj_ext array in alloc_slab_obj_exts(), the array can be allocated from the same slab we're allocating the array for. This led to obj_exts_in_slab() incorrectly returning true [1], although the array is not allocated from wasted space of the slab. Vlastimil Babka observed that this problem should be fixed even when ignoring its incompatibility with obj_exts_in_slab(), because it creates slabs that are never freed as there is always at least one allocated object. To avoid this, use the next kmalloc size or large kmalloc when the array can be allocated from the same cache we're allocating the array for. In case of random kmalloc caches, there are multiple kmalloc caches for the same size and the cache is selected based on the caller address. Because it is fragile to ensure the same caller address is passed to kmalloc_slab(), kmalloc_noprof(), and kmalloc_node_noprof(), bump the size to (s->object_size + 1) when the sizes are equal, instead of directly comparing the kmem_cache pointers. Note that this doesn't happen when memory allocation profiling is disabled, as when the allocation of the array is triggered by memory cgroup (KMALLOC_CGROUP), the array is allocated from KMALLOC_NORMAL. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202601231457.f7b31e09-lkp@intel.com = [1] Cc: stable@vger.kernel.org Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allocati= on and free paths") Signed-off-by: Harry Yoo Link: https://patch.msgid.link/20260126125714.88008-1-harry.yoo@oracle.com Reviewed-by: Hao Li Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/slub.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 53 insertions(+), 7 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index e1583757331e7..9a7c2fec6208a 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2095,6 +2095,49 @@ static inline void init_slab_obj_exts(struct slab *s= lab) slab->obj_exts =3D 0; } =20 +/* + * Calculate the allocation size for slabobj_ext array. + * + * When memory allocation profiling is enabled, the obj_exts array + * could be allocated from the same slab cache it's being allocated for. + * This would prevent the slab from ever being freed because it would + * always contain at least one allocated object (its own obj_exts array). + * + * To avoid this, increase the allocation size when we detect the array + * may come from the same cache, forcing it to use a different cache. + */ +static inline size_t obj_exts_alloc_size(struct kmem_cache *s, + struct slab *slab, gfp_t gfp) +{ + size_t sz =3D sizeof(struct slabobj_ext) * slab->objects; + struct kmem_cache *obj_exts_cache; + + /* + * slabobj_ext array for KMALLOC_CGROUP allocations + * are served from KMALLOC_NORMAL caches. + */ + if (!mem_alloc_profiling_enabled()) + return sz; + + if (sz > KMALLOC_MAX_CACHE_SIZE) + return sz; + + if (!is_kmalloc_normal(s)) + return sz; + + obj_exts_cache =3D kmalloc_slab(sz, NULL, gfp, 0); + /* + * We can't simply compare s with obj_exts_cache, because random kmalloc + * caches have multiple caches per size, selected by caller address. + * Since caller address may differ between kmalloc_slab() and actual + * allocation, bump size when sizes are equal. + */ + if (s->object_size =3D=3D obj_exts_cache->object_size) + return obj_exts_cache->object_size + 1; + + return sz; +} + int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s, gfp_t gfp, bool new_slab) { @@ -2103,26 +2146,26 @@ int alloc_slab_obj_exts(struct slab *slab, struct k= mem_cache *s, unsigned long new_exts; unsigned long old_exts; struct slabobj_ext *vec; + size_t sz; =20 gfp &=3D ~OBJCGS_CLEAR_MASK; /* Prevent recursive extension vector allocation */ gfp |=3D __GFP_NO_OBJ_EXT; =20 + sz =3D obj_exts_alloc_size(s, slab, gfp); + /* * Note that allow_spin may be false during early boot and its * restricted GFP_BOOT_MASK. Due to kmalloc_nolock() only supporting * architectures with cmpxchg16b, early obj_exts will be missing for * very early allocations on those. */ - if (unlikely(!allow_spin)) { - size_t sz =3D objects * sizeof(struct slabobj_ext); - + if (unlikely(!allow_spin)) vec =3D kmalloc_nolock(sz, __GFP_ZERO | __GFP_NO_OBJ_EXT, slab_nid(slab)); - } else { - vec =3D kcalloc_node(objects, sizeof(struct slabobj_ext), gfp, - slab_nid(slab)); - } + else + vec =3D kmalloc_node(sz, gfp | __GFP_ZERO, slab_nid(slab)); + if (!vec) { /* * Try to mark vectors which failed to allocate. @@ -2136,6 +2179,9 @@ int alloc_slab_obj_exts(struct slab *slab, struct kme= m_cache *s, return -ENOMEM; } =20 + VM_WARN_ON_ONCE(virt_to_slab(vec) !=3D NULL && + virt_to_slab(vec)->slab_cache =3D=3D s); + new_exts =3D (unsigned long)vec; if (unlikely(!allow_spin)) new_exts |=3D OBJEXTS_NOSPIN_ALLOC; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 103C3413F36; Sat, 28 Feb 2026 17:45:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300704; cv=none; b=q6jS78QqtBSeiXY8xkUcOu5DuMWefq02+q4KjjFQDm+qWqGQgM51VfjUGhyhvIO2PX8gYiV/J/iIiiHIE6j367KYRnl2NRcTTMtrBoip8GEFwBZnjEZ85zz98PFe/mZFjJ/gvkIXNKQD2pvndthByRPgeQ8pDuM04Bjkc6Ep7vo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300704; c=relaxed/simple; bh=7XtzJWyng5F+/9CAkuRi23pmTU+hujE5U5871cDjoEc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Lzm7y9gLfgLTz/zwiWARCQNGwJDL+IH04amVX58W86LR8hl5kfwlnftyWWLncg84u+b1yhqmwwNemy+gwe6F+QVwq0Y3PdNghTwzrRXGJrVmQOXu4EhG12YTKzSrIsRhwwyme+UeC52rFgQzJliWtvTOefhdC80lF8ROjLbb0mA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JbTyLAbZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JbTyLAbZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F33A2C116D0; Sat, 28 Feb 2026 17:45:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300703; bh=7XtzJWyng5F+/9CAkuRi23pmTU+hujE5U5871cDjoEc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JbTyLAbZqdQ8vhygTt1IvR3ocQnerMTXcwKdKxRvTLmhq1VnfBi5yGu4gDByP8Cas CBdiwU3rFdod+6tzDKkGqRrucnoL07fQCtUNNCDQfSSq03xHJvejdoWZyPv+wtiG1E QKhbO0ER8hOsMFSqIKKvzUyxmmfyhmdkoaoAhgsqXVe+2SdQb3opcD0S+KqvWO1Th1 KAtYiB44vD4nPjBpdRJZJL806zLDWbfIpAkxBBNlEi2wsDnI3Cbrxuc1OzwQAUJbRS WeF8zQ/XlTPqyYDaJ9Lfr6GjBwILWHuwaXqFpGn3WFv3JuDMFVsVmq5eAt1RHFt07P gzS7QCfRRe8mw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harry Yoo , Andrey Ryabinin , Vlastimil Babka , Sasha Levin Subject: [PATCH 6.19 739/844] mm/slab: use unsigned long for orig_size to ensure proper metadata align Date: Sat, 28 Feb 2026 12:30:52 -0500 Message-ID: <20260228173244.1509663-740-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harry Yoo [ Upstream commit b85f369b81aed457acbea4ad3314218254a72fd2 ] When both KASAN and SLAB_STORE_USER are enabled, accesses to struct kasan_alloc_meta fields can be misaligned on 64-bit architectures. This occurs because orig_size is currently defined as unsigned int, which only guarantees 4-byte alignment. When struct kasan_alloc_meta is placed after orig_size, it may end up at a 4-byte boundary rather than the required 8-byte boundary on 64-bit systems. Note that 64-bit architectures without HAVE_EFFICIENT_UNALIGNED_ACCESS are assumed to require 64-bit accesses to be 64-bit aligned. See HAVE_64BIT_ALIGNED_ACCESS and commit adab66b71abf ("Revert: "ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS"") for more details. Change orig_size from unsigned int to unsigned long to ensure proper alignment for any subsequent metadata. This should not waste additional memory because kmalloc objects are already aligned to at least ARCH_KMALLOC_MINALIGN. Closes: https://lore.kernel.org/all/aPrLF0OUK651M4dk@hyeyoo Suggested-by: Andrey Ryabinin Cc: stable@vger.kernel.org Fixes: 6edf2576a6cc ("mm/slub: enable debugging memory wasting of kmalloc") Signed-off-by: Harry Yoo Closes: https://lore.kernel.org/all/aPrLF0OUK651M4dk@hyeyoo/ Link: https://patch.msgid.link/20260113061845.159790-2-harry.yoo@oracle.com Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/slub.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 9a7c2fec6208a..78946116ecd2f 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -857,7 +857,7 @@ static inline bool slab_update_freelist(struct kmem_cac= he *s, struct slab *slab, * request size in the meta data area, for better debug and sanity check. */ static inline void set_orig_size(struct kmem_cache *s, - void *object, unsigned int orig_size) + void *object, unsigned long orig_size) { void *p =3D kasan_reset_tag(object); =20 @@ -867,10 +867,10 @@ static inline void set_orig_size(struct kmem_cache *s, p +=3D get_info_end(s); p +=3D sizeof(struct track) * 2; =20 - *(unsigned int *)p =3D orig_size; + *(unsigned long *)p =3D orig_size; } =20 -static inline unsigned int get_orig_size(struct kmem_cache *s, void *objec= t) +static inline unsigned long get_orig_size(struct kmem_cache *s, void *obje= ct) { void *p =3D kasan_reset_tag(object); =20 @@ -883,7 +883,7 @@ static inline unsigned int get_orig_size(struct kmem_ca= che *s, void *object) p +=3D get_info_end(s); p +=3D sizeof(struct track) * 2; =20 - return *(unsigned int *)p; + return *(unsigned long *)p; } =20 #ifdef CONFIG_SLUB_DEBUG @@ -1198,7 +1198,7 @@ static void print_trailer(struct kmem_cache *s, struc= t slab *slab, u8 *p) off +=3D 2 * sizeof(struct track); =20 if (slub_debug_orig_size(s)) - off +=3D sizeof(unsigned int); + off +=3D sizeof(unsigned long); =20 off +=3D kasan_metadata_size(s, false); =20 @@ -1394,7 +1394,7 @@ static int check_pad_bytes(struct kmem_cache *s, stru= ct slab *slab, u8 *p) off +=3D 2 * sizeof(struct track); =20 if (s->flags & SLAB_KMALLOC) - off +=3D sizeof(unsigned int); + off +=3D sizeof(unsigned long); } =20 off +=3D kasan_metadata_size(s, false); @@ -8021,7 +8021,7 @@ static int calculate_sizes(struct kmem_cache_args *ar= gs, struct kmem_cache *s) =20 /* Save the original kmalloc request size */ if (flags & SLAB_KMALLOC) - size +=3D sizeof(unsigned int); + size +=3D sizeof(unsigned long); } #endif =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7940413F49; Sat, 28 Feb 2026 17:45:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300704; cv=none; b=hOdjJmqZLdmSK86c14m2YYpzPAMsHGrDBYhm8Kl+P4ylQxnh7myxeNDqfhq+4FE5qHfbvAh96TnUWlMeMRTubCalNWZFChDakNl4ylvsBX69xBMmihkkwMWKaE3sP8xujniZiwX2SEoQDxkMNbg5FgO32dOTY9caFMjr7nu54eA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300704; c=relaxed/simple; bh=ZwyYhaYhrSbFRdn+LnNbNaEEXW4wkcTasMoEGoCtb8Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Pskb7eOCJURS3mN+omN0nUpBg2qJxSIwJVVqR5eb00hHg6Uo2t//GxlM0GEmQwsIz8MRLdm7QOIdPobA3a7Sgb38+S64IntMbvHT8P13oIuBrtHm9F5fT46TDwd8DlvjBoT0AjauvQ62H7fcQ6Ef/6a0JPHpgQxCOaNtcCLPATc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OqvKUXTH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OqvKUXTH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E14C3C19423; Sat, 28 Feb 2026 17:45:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300704; bh=ZwyYhaYhrSbFRdn+LnNbNaEEXW4wkcTasMoEGoCtb8Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OqvKUXTH75XocudkxBLnFyA9Q0bhfauTvHLAOqEfOQWFY04tT+Sj3mWVgD+vTssVJ xxHB2kMapNhqeY0qRa2zbYm52PhP3GRcWfFCZQYManOKiSlBlsABZDXS5SiFcp5oh8 Mw82edQLr0N5nUoZQb6nmxNwIId1e+Zm0LRD7Mj46yNc6jCQxM8S15H77+Yu0f1xE0 hklruGan0l2JTs7QOpK01vE6s18k38Du7hHV9r+mmQu1W/UujyTOYSDu/zvnR0YNjT JPeXRcsoOBJ/mSV++0mAMg/q5FIjXG4+AkQd1kJsVkSaQHBJBE9XUIWu1WxkD0LczJ jrnJQ6TC4xvFQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xuewen Yan , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 6.19 740/844] PM: sleep: core: Avoid bit field races related to work_in_progress Date: Sat, 28 Feb 2026 12:30:53 -0500 Message-ID: <20260228173244.1509663-741-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xuewen Yan [ Upstream commit 0491f3f9f664e7e0131eb4d2a8b19c49562e5c64 ] In all of the system suspend transition phases, the async processing of a device may be carried out in parallel with power.work_in_progress updates for the device's parent or suppliers and if it touches bit fields from the same group (for example, power.must_resume or power.wakeup_path), bit field corruption is possible. To avoid that, turn work_in_progress in struct dev_pm_info into a proper bool field and relocate it to save space. Fixes: aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending chi= ldren") Fixes: 443046d1ad66 ("PM: sleep: Make suspend of devices more asynchronous") Signed-off-by: Xuewen Yan Closes: https://lore.kernel.org/linux-pm/20260203063459.12808-1-xuewen.yan@= unisoc.com/ Cc: All applicable [ rjw: Added subject and changelog ] Link: https://patch.msgid.link/CAB8ipk_VX2VPm706Jwa1=3D8NSA7_btWL2ieXmBgHr2= JcULEP76g@mail.gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/pm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/pm.h b/include/linux/pm.h index 98a899858ecee..afcaaa37a8126 100644 --- a/include/linux/pm.h +++ b/include/linux/pm.h @@ -681,10 +681,10 @@ struct dev_pm_info { struct list_head entry; struct completion completion; struct wakeup_source *wakeup; + bool work_in_progress; /* Owned by the PM core */ bool wakeup_path:1; bool syscore:1; bool no_pm_callbacks:1; /* Owned by the PM core */ - bool work_in_progress:1; /* Owned by the PM core */ bool smart_suspend:1; /* Owned by the PM core */ bool must_resume:1; /* Owned by the PM core */ bool may_skip_resume:1; /* Set by subsystems */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B42F6411E2B; Sat, 28 Feb 2026 17:45:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300705; cv=none; b=HCHaZwFyrmAB0AN4DUMv5Qffck374wsWIzu8twudMMyHj9zNX+O14PU+WggBf/tXWmW/14fOB+9cOcNC/0S4KhLse9UbaK9vXQ6F0G8bdAEzB4b/nfE4w72qN/e+KNMt8wHmPrMTpdzXjgUTanrORLB42JVzRjcBwOf6H9z9m1Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300705; c=relaxed/simple; bh=dQkMmHrbcqCy/oztNkPAM72dHeZZl1pyQ+qFF3r0YC4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MsOisw1kwQvqwdmsSkZ5dZmEyxO3JbMMESa7eC+PvDVOZ7FAfIAABNMgQKQc6nY2SwmNuLLxVcd2x93uZYTU5wu9ro/ZoZmWdUySDAnVk88lN6FpF70rs3SAUzO7BqgYf/W20L56xa1axFtkf7G3oZehpMEirroXMnjj2h2wvVw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KaH1Fu+6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KaH1Fu+6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD117C2BC9E; Sat, 28 Feb 2026 17:45:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300705; bh=dQkMmHrbcqCy/oztNkPAM72dHeZZl1pyQ+qFF3r0YC4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KaH1Fu+61XWb7Axkzw/fh5eZq7nMjzxfnMtDAa6aOQiuU12Lv+1QQc/MdbfX448kC yxZvJ3s22FvcD8SlN7TnKhLqu7xM7bZ8APZsJhdz5NPpiEKAQnbFj7+vLoC/GL0xBD 2Z4+mqCtbtnL2CHvn6r6sLRkbyCKVpzSaVtLDqOGcuL60yEihRnraWsd/8Eu5mb6R/ uvmJK7e6BKkhmFc6nnQjQDNnftfcEJ+fGjjobZKMA4D600mpW55ftUScnwni7xqRRV zLcqZKE2lXtDUX5kyYYZMVgYGRD8vqpEnm2KE0KiQezyyeRaI/0d4F6tuOo6Y4QdNQ m5EEVW/s/5KFA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Rong Zhang , Beiyan Yun , Yao Zi , Jiaxun Yang , Thomas Bogendoerfer , Sasha Levin Subject: [PATCH 6.19 741/844] MIPS: Loongson2ef: Register PCI controller in early stage Date: Sat, 28 Feb 2026 12:30:54 -0500 Message-ID: <20260228173244.1509663-742-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Rong Zhang [ Upstream commit 6a00c043af07492502ba7a2263ddc4cdb01b66a7 ] We are about to set loongson_pci_io_resource.start to 0 and adopt PCIBIOS_MIN_IO. As the first step, PCI controller needs to be registered in early stage to make it the root of other resources (e.g., i8259) and prevent resource conflicts. Register it in plat_mem_setup() instead of arch_initcall(). Fixes: ae81aad5c2e1 ("MIPS: PCI: Use pci_enable_resources()") Cc: stable@vger.kernel.org Tested-by: Beiyan Yun Tested-by: Yao Zi Signed-off-by: Rong Zhang Acked-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/mips/include/asm/mach-loongson2ef/loongson.h | 6 ++++++ arch/mips/loongson2ef/common/pci.c | 7 +------ arch/mips/loongson2ef/common/setup.c | 1 + 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/mips/include/asm/mach-loongson2ef/loongson.h b/arch/mips/= include/asm/mach-loongson2ef/loongson.h index 4a098fb102325..0e586787eb87a 100644 --- a/arch/mips/include/asm/mach-loongson2ef/loongson.h +++ b/arch/mips/include/asm/mach-loongson2ef/loongson.h @@ -324,4 +324,10 @@ extern unsigned long _loongson_addrwincfg_base; =20 #endif /* ! CONFIG_CPU_SUPPORTS_ADDRWINCFG */ =20 +#ifdef CONFIG_PCI +void loongson2ef_pcibios_init(void); +#else +static inline void loongson2ef_pcibios_init(void) { } +#endif + #endif /* __ASM_MACH_LOONGSON2EF_LOONGSON_H */ diff --git a/arch/mips/loongson2ef/common/pci.c b/arch/mips/loongson2ef/com= mon/pci.c index 7d9ea51e8c01e..55524f9a7b96b 100644 --- a/arch/mips/loongson2ef/common/pci.c +++ b/arch/mips/loongson2ef/common/pci.c @@ -73,15 +73,10 @@ static void __init setup_pcimap(void) #endif } =20 -static int __init pcibios_init(void) +void __init loongson2ef_pcibios_init(void) { setup_pcimap(); =20 loongson_pci_controller.io_map_base =3D mips_io_port_base; register_pci_controller(&loongson_pci_controller); - - - return 0; } - -arch_initcall(pcibios_init); diff --git a/arch/mips/loongson2ef/common/setup.c b/arch/mips/loongson2ef/c= ommon/setup.c index 4fd27f4f90edb..a639e35acce59 100644 --- a/arch/mips/loongson2ef/common/setup.c +++ b/arch/mips/loongson2ef/common/setup.c @@ -27,4 +27,5 @@ EXPORT_SYMBOL(__wbflush); =20 void __init plat_mem_setup(void) { + loongson2ef_pcibios_init(); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B8D6414BE3; Sat, 28 Feb 2026 17:45:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300707; cv=none; b=qjxTicEmzIFXrsIXt17dyMPCMQaXDAqmAHsUs2nn2YwXZVRBPA1yPeVYCzv31VVOvXin9CcOhqXtZ/UsdzK3R7tZCjOakavnKJ9T3AKZVbYVMjGBknslEafI0QlxgCE7rucpQEuy4lRoz3dK6IcPaNx1pulgmcMSzpU/223L0dg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300707; c=relaxed/simple; bh=POVVDLSYNt4aqCKww6t4rhfVjfjD+cYHX5CfY2Bk1SE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lDi2CQdQIjrIDJw/euEAC+zB1dnciRjIauBB/6haEtz0YievV0ywLepR4TeQRQ+7Iy5sPLGRQhJYdd1YGJ8SqDO6+MLDY4wxeH9mimo/IR8q4iORBVNpMgkjwjwyLMeka24Horsh45XXZbzCFvV8yytg1Cara2butluUfKxp9tU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=idxqwU+t; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="idxqwU+t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA92FC116D0; Sat, 28 Feb 2026 17:45:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300706; bh=POVVDLSYNt4aqCKww6t4rhfVjfjD+cYHX5CfY2Bk1SE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=idxqwU+tkce8n+F1kQLF3q0NFEO527lqqDmonVC2SLc0eOJp6/Tv85g2D87wCSv2Q Lerg0AFcq9lra1di9KtU64eebge1C0UxRxycsrMYCWVC4pRQWq0nvYtqnyFntwt0s4 BhDzQTUFGYKi0AZLS/jiOxWEAEQpXKYlOMai/U5quy+P2WzHW4GouD/LlQ29kGbVHt Bp1PbF+Zh4IxEBcuo6vIH/XwUPXj73aL+9pwH/A7q3bqm+1wc+vYkkP9mEIOfvwp01 9K08nc1fMTmgf5V1svu3/cjyQJ2ab+zVc9KNhG7LIKsGnmb1LfWISmttKrE38OYv4W 5PCi54QDCAixQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Rong Zhang , Beiyan Yun , Yao Zi , Jiaxun Yang , Thomas Bogendoerfer , Sasha Levin Subject: [PATCH 6.19 742/844] MIPS: Loongson2ef: Use pcibios_align_resource() to block io range Date: Sat, 28 Feb 2026 12:30:55 -0500 Message-ID: <20260228173244.1509663-743-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Rong Zhang [ Upstream commit 32ec465103527ede09b640cd0ab0636dc58827fb ] Loongson2ef reserves io range below 0x4000 (LOONGSON_PCI_IO_START) while ISA-mode only IDE controller on the south bridge still has a hard dependency on ISA IO ports. The reservation was done by lifting loongson_pci_io_resource.start onto 0x4000. Prior to commit ae81aad5c2e1 ("MIPS: PCI: Use pci_enable_resources()"), the arch specific pcibios_enable_resources() did not check if the resources were claimed, which diverges from what PCI core checks, effectively hiding the fact that IDE IO resources were not properly within the resource tree. After starting to use pcibios_enable_resources() from PCI core, enabling IDE controller fails: pata_cs5536 0000:00:0e.2: BAR 0 [io 0x01f0-0x01f7]: not claimed; can't e= nable device pata_cs5536 0000:00:0e.2: probe with driver pata_cs5536 failed with error= -22 MIPS PCI code already has support for enforcing lower bounds using PCIBIOS_MIN_IO in pcibios_align_resource() without altering the IO window start address itself. Make Loongson2ef PCI code use PCIBIOS_MIN_IO too. Fixes: ae81aad5c2e1 ("MIPS: PCI: Use pci_enable_resources()") Cc: stable@vger.kernel.org Tested-by: Beiyan Yun Tested-by: Yao Zi Signed-off-by: Rong Zhang Acked-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/mips/loongson2ef/common/pci.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/mips/loongson2ef/common/pci.c b/arch/mips/loongson2ef/com= mon/pci.c index 55524f9a7b96b..0f11392104bfd 100644 --- a/arch/mips/loongson2ef/common/pci.c +++ b/arch/mips/loongson2ef/common/pci.c @@ -17,7 +17,7 @@ static struct resource loongson_pci_mem_resource =3D { =20 static struct resource loongson_pci_io_resource =3D { .name =3D "pci io space", - .start =3D LOONGSON_PCI_IO_START, + .start =3D 0x00000000UL, /* See loongson2ef_pcibios_init(). */ .end =3D IO_SPACE_LIMIT, .flags =3D IORESOURCE_IO, }; @@ -77,6 +77,15 @@ void __init loongson2ef_pcibios_init(void) { setup_pcimap(); =20 + /* + * ISA-mode only IDE controllers have a hard dependency on ISA IO ports. + * + * Claim them by setting PCI IO space to start at 0x00000000, and set + * PCIBIOS_MIN_IO to prevent non-legacy PCI devices from touching + * reserved regions. + */ + PCIBIOS_MIN_IO =3D LOONGSON_PCI_IO_START; + loongson_pci_controller.io_map_base =3D mips_io_port_base; register_pci_controller(&loongson_pci_controller); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 279DE414BFE; Sat, 28 Feb 2026 17:45:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300708; cv=none; b=Y4WpGkb/oaoz9t9gsMYLMIAf1yH7MF0ntiU9TZpofAly8GeCr2h3k3ntf5/7B4XXBCSYBwFAcA71K8GXRD/nM0m8WTjriQeJVjaRvybJUxHAS3PnPV7jZk6PC/7mfG12iVLe8OCfKdb/DEYWL9qF79NNhTxg87wtLHhmZK2d29M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300708; c=relaxed/simple; bh=0okS24yR1p0q9G0akiBZoBKuecrrZL4S4vPF8LVJtuk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ax0IIQGdkIrpzQDzRl1Pm+R4z5EEWC9a2V5uyxObKrcQFYAboyJNXTSnYvYtAJKb6hyxLGNOjI/ffUctookGkhWxSQWOaTMIrdBjdlWTvr1kO+Y3BNwRJt7PNdJuo+QKiqrWNcVk+Qb8hBSxRkUSbbU5AZzxZO5WVRILbb+nnE0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S/8dahUg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S/8dahUg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0308DC19423; Sat, 28 Feb 2026 17:45:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300708; bh=0okS24yR1p0q9G0akiBZoBKuecrrZL4S4vPF8LVJtuk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S/8dahUgb2Bv3+HqdTNo8x3GjGgoG+d9Q45IB0R/sHkWDT+ONSworfbTprfpm0qPv PjnkY/R7KwzU6jjdEbC6TI6LhIn+30PonjLRdqOTCfJzz4+XKvW/RL3hGLN45oSRrq 1qt5nqleypQ+FyZ5WAL9pkvzDA/kFRqu+oZB75BtQZ7KwdOhLHvdBC8BYAFOH8ACpm fWBTXj9ofzYdrumAV41/R9EgcpJ0ilDFcLzvieo6yIQJzuT7Kqli7NXktkPVh5ByDP fsM0cD2rnRbVdj3yaPyjWfExgxR2ffOx1S7GY2sSDvjn4cz9tLKFNRGy0ntYye51y8 tzVT/AQRuFybg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Niklas Cassel , Manivannan Sadhasivam , "Maciej W. Rozycki" , Damien Le Moal , Hans Zhang , Frank Li , Shawn Lin , Sasha Levin Subject: [PATCH 6.19 743/844] PCI: dwc: Fix msg_atu_index assignment Date: Sat, 28 Feb 2026 12:30:56 -0500 Message-ID: <20260228173244.1509663-744-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Niklas Cassel [ Upstream commit 58fbf08935d9c4396417e5887df89a4e681fa7e3 ] When dw_pcie_iatu_setup() configures outbound address translation for both type PCIE_ATU_TYPE_MEM and PCIE_ATU_TYPE_IO, the iATU index to use is incremented before calling dw_pcie_prog_outbound_atu(). However for msg_atu_index, the index is not incremented before use, causing the iATU index to be the same as the last configured iATU index, which means that it will incorrectly use the same iATU index that is already in use, breaking outbound address translation. In total there are three problems with this code: -It assigns msg_atu_index the same index that was used for the last outbound address translation window, rather than incrementing the index before assignment. -The index should only be incremented (and msg_atu_index assigned) if the use_atu_msg feature is actually requested/in use (pp->use_atu_msg is set). -If the use_atu_msg feature is requested/in use, and there are no outbound iATUs available, the code should return an error, as otherwise when this this feature is used, it will use an iATU index that is out of bounds. Fixes: e1a4ec1a9520 ("PCI: dwc: Add generic MSG TLP support for sending PME= _Turn_Off when system suspend") Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Maciej W. Rozycki Reviewed-by: Damien Le Moal Reviewed-by: Hans Zhang Reviewed-by: Frank Li Reviewed-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260127151038.1484881-6-cassel@kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/controller/dwc/pcie-designware-host.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pc= i/controller/dwc/pcie-designware-host.c index af2eeed55f9e5..53125b97530b6 100644 --- a/drivers/pci/controller/dwc/pcie-designware-host.c +++ b/drivers/pci/controller/dwc/pcie-designware-host.c @@ -946,7 +946,14 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp) dev_warn(pci->dev, "Ranges exceed outbound iATU size (%d)\n", pci->num_ob_windows); =20 - pp->msg_atu_index =3D i; + if (pp->use_atu_msg) { + if (pci->num_ob_windows > ++i) { + pp->msg_atu_index =3D i; + } else { + dev_err(pci->dev, "Cannot add outbound window for MSG TLP\n"); + return -ENOMEM; + } + } =20 i =3D 0; resource_list_for_each_entry(entry, &pp->bridge->dma_ranges) { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1654A416505; Sat, 28 Feb 2026 17:45:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300709; cv=none; b=QncT2NtQYhJGqFFa6SqfHrsVlE+pvUzVrUHIesHizBoYZ8TufkdVSq6EMaZNUaX8RaP+Qb6vuIKnrjiXrDJB9VL6dxVGJHbz+5J0h5ND8Y5E+xgDdh5vVDaT/j7kvgtPa4s3hDvjiaaTmuL0e3gaVZSVRzoQx5vj0z8tV6DxtrE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300709; c=relaxed/simple; bh=+Ste2ttJfZAd6L9l4wmVUyZ5HJ1zQqi8hqqC0X2Ssoo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CStrQZwb5FmqkQjvtqAet2YNufWvBqlTv+2tWuCelvUOoftaULN7jve5so/8RqPYUfXgrSigt9/21/GLCFDC9aPasm2iy6ypE+dEOstxNyPzRNoDexKGgO5YAotzs6SjaxHWWhTAR+L6dVyT2EqbsH+B76YAxqFFOdzE5ga0XYE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S13CKTwj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S13CKTwj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BF4FC19423; Sat, 28 Feb 2026 17:45:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300709; bh=+Ste2ttJfZAd6L9l4wmVUyZ5HJ1zQqi8hqqC0X2Ssoo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S13CKTwjuFfVlA+LG/p4SjQdue+VuljfHRj7/m1LxX1Lxfao5U9yWMbwIVzfsN36S UjOjoy9qo+2u10/B50+++Nlso2jML9aMVM8IIzGi05Y43z0m6weRIGbFoqwTSpFPJj 8CEcCTG3FnIi3pe8dGWGN02U7m+zJpGTz59WwXn5lsdE1ixIhEBLsmHEJXjbYgdycZ jecP6rTPIc6+QQgt7Fjvr6iiQsw8pDnV3P7xM42t/kSztYdR3+WeEtPD2FnGWOA/yT FSu9IXQhYSb/UJ+DvjhnLuU9KKgB+obbCoOYRtb0EtsYOw1FZNlDfvzxESiFa5cMEi gBCnCuOsYFJDA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Andrew Davis , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 744/844] mux: mmio: fix regmap leak on probe failure Date: Sat, 28 Feb 2026 12:30:57 -0500 Message-ID: <20260228173244.1509663-745-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit 3c4ae63073d84abee5d81ce46d86a94e9dae9c89 ] The mmio regmap that may be allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: 61de83fd8256 ("mux: mmio: Do not use syscon helper to build regmap") Cc: stable@vger.kernel.org # 6.16 Cc: Andrew Davis Signed-off-by: Johan Hovold Acked-by: Andrew Davis Link: https://patch.msgid.link/20251127134702.1915-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mux/mmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c index 3409af1ffb80f..0611ef28bb69a 100644 --- a/drivers/mux/mmio.c +++ b/drivers/mux/mmio.c @@ -72,7 +72,7 @@ static int mux_mmio_probe(struct platform_device *pdev) if (IS_ERR(base)) regmap =3D ERR_PTR(-ENODEV); else - regmap =3D regmap_init_mmio(dev, base, &mux_mmio_regmap_cfg); + regmap =3D devm_regmap_init_mmio(dev, base, &mux_mmio_regmap_cfg); /* Fallback to checking the parent node on "real" errors. */ if (IS_ERR(regmap) && regmap !=3D ERR_PTR(-EPROBE_DEFER)) { regmap =3D dev_get_regmap(dev->parent, NULL); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3682941652E; Sat, 28 Feb 2026 17:45:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300710; cv=none; b=Q30AI0ZJDlRmNF58ecS9k//Wj3Zm1Vx2sPOKpg4n+5duBO+uVuyQF7AynEBshOukfDVf0koTxA0xa+1jo/DE3wCEzsZuTgc7eUcudKZDx1shV4H+q2dgYgYJ6W4wuK4xn6muL6SibroiaCSx9jD0RaY1U0fIM9qMxMmwKjIm/OE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300710; c=relaxed/simple; bh=j95vHr5RgMxzqPs5bwjfN8AGGDsRFapqiYkrDSxniwg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iJUUjw7hYLEJnsoNcGckeIw6gseyo/cSUn2kMjMlCrCbKpRbpVzZX0HwebSC2Eg7+hFjgxwJEC+/GzbBJeuRQzAlDuLjJ6CDvptYjbWrE/Mk5NJpacQeGfVpgeyaX2ti/n57K42e0i/x0bkE22av2pqSdQ14ivUTFqOSL3fAbCw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lHClTRF4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lHClTRF4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FB04C19423; Sat, 28 Feb 2026 17:45:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300710; bh=j95vHr5RgMxzqPs5bwjfN8AGGDsRFapqiYkrDSxniwg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lHClTRF42BlpRaCBQg5/Q0RMAiSam3IhgLtn/vWRTCVbYI1OcuHLzww3seAkC1kuI PzSfLQq7i8j673dS/aAzth7a7K09rEk4wF0eCkx0Y+mxw7BsJigVSBfPfqJ5M+PNq6 X1Ul8/JPrEkAAKQFiJZCbjBtvPYzu/v3KNgf0vlnAgh4tL5eFvgjqrKyRBmYP6Qle5 2v7/Kbao85N7jdwbfJS9U05+69Y76HGWsUGF8aXIG6H04GKM9GZZF/jDwVMqR+Ap88 croNz2dZsI+AZOnLPFfFYYUhZfezEPsBbWxJb5c8eQmXdGt2eTT/a1xya7XIg7lu9n qrez0kTMyED3w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Prashanth K , stable , Samuel Wu , Thinh Nguyen , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 745/844] usb: dwc3: gadget: Move vbus draw to workqueue context Date: Sat, 28 Feb 2026 12:30:58 -0500 Message-ID: <20260228173244.1509663-746-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Prashanth K [ Upstream commit 54aaa3b387c2f580a99dc86a9cc2eb6dfaf599a7 ] Currently dwc3_gadget_vbus_draw() can be called from atomic context, which in turn invokes power-supply-core APIs. And some these PMIC APIs have operations that may sleep, leading to kernel panic. Fix this by moving the vbus_draw into a workqueue context. Fixes: 99288de36020 ("usb: dwc3: add an alternate path in vbus_draw callbac= k") Cc: stable Tested-by: Samuel Wu Acked-by: Thinh Nguyen Signed-off-by: Prashanth K Link: https://patch.msgid.link/20260204054155.3063825-1-prashanth.k@oss.qua= lcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/usb/dwc3/core.c | 19 ++++++++++++++++++- drivers/usb/dwc3/core.h | 4 ++++ drivers/usb/dwc3/gadget.c | 8 +++----- 3 files changed, 25 insertions(+), 6 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 93fd5fdf95cb1..59801611dd756 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -2155,6 +2155,20 @@ static int dwc3_get_num_ports(struct dwc3 *dwc) return 0; } =20 +static void dwc3_vbus_draw_work(struct work_struct *work) +{ + struct dwc3 *dwc =3D container_of(work, struct dwc3, vbus_draw_work); + union power_supply_propval val =3D {0}; + int ret; + + val.intval =3D 1000 * (dwc->current_limit); + ret =3D power_supply_set_property(dwc->usb_psy, POWER_SUPPLY_PROP_INPUT_C= URRENT_LIMIT, &val); + + if (ret < 0) + dev_dbg(dwc->dev, "Error (%d) setting vbus draw (%d mA)\n", + ret, dwc->current_limit); +} + static struct power_supply *dwc3_get_usb_power_supply(struct dwc3 *dwc) { struct power_supply *usb_psy; @@ -2169,6 +2183,7 @@ static struct power_supply *dwc3_get_usb_power_supply= (struct dwc3 *dwc) if (!usb_psy) return ERR_PTR(-EPROBE_DEFER); =20 + INIT_WORK(&dwc->vbus_draw_work, dwc3_vbus_draw_work); return usb_psy; } =20 @@ -2395,8 +2410,10 @@ void dwc3_core_remove(struct dwc3 *dwc) =20 dwc3_free_event_buffers(dwc); =20 - if (dwc->usb_psy) + if (dwc->usb_psy) { + cancel_work_sync(&dwc->vbus_draw_work); power_supply_put(dwc->usb_psy); + } } EXPORT_SYMBOL_GPL(dwc3_core_remove); =20 diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 45757169b672f..9cfc36d4bc259 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -1060,6 +1060,8 @@ struct dwc3_glue_ops { * @role_switch_default_mode: default operation mode of controller while * usb role is USB_ROLE_NONE. * @usb_psy: pointer to power supply interface. + * @vbus_draw_work: Work to set the vbus drawing limit + * @current_limit: How much current to draw from vbus, in milliAmperes. * @usb2_phy: pointer to USB2 PHY * @usb3_phy: pointer to USB3 PHY * @usb2_generic_phy: pointer to array of USB2 PHYs @@ -1246,6 +1248,8 @@ struct dwc3 { enum usb_dr_mode role_switch_default_mode; =20 struct power_supply *usb_psy; + struct work_struct vbus_draw_work; + unsigned int current_limit; =20 u32 fladj; u32 ref_clk_per; diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 8a35a6901db7d..5732d414e6a64 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -3123,8 +3123,6 @@ static void dwc3_gadget_set_ssp_rate(struct usb_gadge= t *g, static int dwc3_gadget_vbus_draw(struct usb_gadget *g, unsigned int mA) { struct dwc3 *dwc =3D gadget_to_dwc(g); - union power_supply_propval val =3D {0}; - int ret; =20 if (dwc->usb2_phy) return usb_phy_set_power(dwc->usb2_phy, mA); @@ -3132,10 +3130,10 @@ static int dwc3_gadget_vbus_draw(struct usb_gadget = *g, unsigned int mA) if (!dwc->usb_psy) return -EOPNOTSUPP; =20 - val.intval =3D 1000 * mA; - ret =3D power_supply_set_property(dwc->usb_psy, POWER_SUPPLY_PROP_INPUT_C= URRENT_LIMIT, &val); + dwc->current_limit =3D mA; + schedule_work(&dwc->vbus_draw_work); =20 - return ret; + return 0; } =20 /** --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67AB9416521; Sat, 28 Feb 2026 17:45:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300711; cv=none; b=aD/W6IBtVtu11BJJ0nyaRCK0C8veMEPZQ8GG1W3H8LORgm1Qxjad4npAKVw7QdN//2SP6yBqi6iie9NtJcwrASGs+2OTjOECXO61XHUD9HQe4tKYZV8kJVoAWaLaJMpKHKWiGva93eYjzExFJ36ONYea1yIe87pjXDl/jnFn9Pc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300711; c=relaxed/simple; bh=KKRH8BqmA8D24Dq5Sat9mQBwtLCDGlq0H+A/IIvoLjw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=i7qby9t8m16JifqnmuQLhh0+pGA/EllVW35ldEZDUNHp+KQN0s4FLzpYPTVYZVfNHargWFovYCN//jWoB0eO0Ho8cQkyQVTRdYGBJPJXKTIDONSHXPGRuO2nK1o+JeT1wWfixfyOzCYHGh7mveEYzUyEPvmWjH3IUY4YFOh2CrU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XAyzzzez; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XAyzzzez" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F65AC19424; Sat, 28 Feb 2026 17:45:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300711; bh=KKRH8BqmA8D24Dq5Sat9mQBwtLCDGlq0H+A/IIvoLjw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XAyzzzez6PQ5iyCSrSQoa4YU3xUsEu4VtYJflmIsOc3NcZbVAyFAtgGp10XMt0d0h NdDR6WWf58jM/f+LLgnT3YWbdNOWtNLwFWgQ+BZUvWVr5Ry4fPWtEY+7yTxl7nMMWu oPneFYPBUBXqm5cEynjBc2OI7PCvWGs/3KXpKyHa74nsopW6Nu1d7HKI6fuzlfXT4L iWn0NrJHYeKrOxOQU5anvFTSJdoHl6u9z8rSY1g3v/X0LCepqW7h7fqNDysWlVO4ez rUSEOrvnVX116WXVd8hHXuYlxLpTkixjp0Wp8vkB2rvBRLDRxLeM3O7EKgwtTRV1rI ZfZAyorKvkeiw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jisheng Zhang , stable , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 746/844] usb: dwc2: fix resume failure if dr_mode is host Date: Sat, 28 Feb 2026 12:30:59 -0500 Message-ID: <20260228173244.1509663-747-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jisheng Zhang [ Upstream commit a52e4f2dff413b58c7200e89bb6540bd995e1269 ] commit 13b1f8e25bfd1 ("usb: dwc2: Force mode optimizations") removed the dwc2_force_mode(hsotg, true) in dwc2_force_dr_mode() if dr_mode is host. But this brings a bug: the controller fails to resume back as host, further debugging shows that the controller is resumed as peripheral. The reason is dwc2_force_dr_mode() missed the host mode forcing, and when resuming from s2ram, GINTSTS is 0 by default, dwc2_is_device_mode in dwc2_resume() misreads this as the controller is in peripheral mode. Fix the resume failure by adding back the dwc2_force_mode(hsotg, true). Then an obvious question is: why this bug hasn't been observed and fixed for about six years? There are two resons: most dwc2 platforms set the dr_mode as otg; Some platforms don't have suspend & resume support yet. Fixes: 13b1f8e25bfd1 ("usb: dwc2: Force mode optimizations") Cc: stable Signed-off-by: Jisheng Zhang Link: https://patch.msgid.link/20260129021534.10411-1-jszhang@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/usb/dwc2/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c index c3d24312db0fe..f375c5185bfe2 100644 --- a/drivers/usb/dwc2/core.c +++ b/drivers/usb/dwc2/core.c @@ -578,6 +578,7 @@ void dwc2_force_dr_mode(struct dwc2_hsotg *hsotg) { switch (hsotg->dr_mode) { case USB_DR_MODE_HOST: + dwc2_force_mode(hsotg, true); /* * NOTE: This is required for some rockchip soc based * platforms on their host-only dwc2. --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C023414910; Sat, 28 Feb 2026 17:45:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300712; cv=none; b=TsRlID79VTYoJOgvqhSVSqDwyJB7zOy+Yfj0CPJJ7sg5AjtRP4D7GeGH3YCaLZLO+c3aKbpvYQU1IHhr29o2SmTW517OASFsthlMxrZJg4SKlxmOTfXo/llGIi4nfNOEKCfBKH4Zyzh+38ogiAKPcJfg2sDA46ucROG+Qe6OGT0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300712; c=relaxed/simple; bh=Y8XpSHB5fFtmQz5KqQGt2nNLe7eX8r+4h6XtvAwSy/o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ceGtIuHuaZDtPrSAg+aiVOmnKa6go6MTs2S9wxJh1Jv4AAfKyMXMPhfNkBpV0EXgTo+TSJHfe1EK1RYNmvOEKElzRKHsjdZEqOQoUWp3jZUbauUEhj/YFI2C9zu0zutDK8hqUG6pdQLk1F/LVEJOxaNI5N9CJBaXa1AjwA4FGDY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K6Xkbv5i; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K6Xkbv5i" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FC3DC19423; Sat, 28 Feb 2026 17:45:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300712; bh=Y8XpSHB5fFtmQz5KqQGt2nNLe7eX8r+4h6XtvAwSy/o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K6Xkbv5iqU6Ufss/BFj+tEyPy3J0ryWiixmWqB6R/uDrTUfHyjpLefQUPS/pJrX1J Iq4ID0ZfyawAJYiOHZBoM8K1RCoRu+KZPZZ3gaK0Z+DapdmFkQWphFIEIpzNoCXwJn 2qwZOgNfsvx/6q6QzfJez7Ccc5IvjrdcSMOWKsuT3kO2FI3M4d4ro8AL9HsjIujJZk YfQ7KG0pDpGVyZpKpLvIvwVStjYleXLOC8Ewj5VMRUCUaJZyWroYH9ogCBMc6LgFbh Xvx7oNAh1JwPO1ssWLo0O3BMqjJnqcefwl6oTCdcqSiUBzqsyRxTuNFhDtaBFiZ1EX tB6iKrx2IR+Ng== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrea Scian , stable@kernel.org, Miquel Raynal , Sasha Levin Subject: [PATCH 6.19 747/844] mtd: rawnand: pl353: Fix software ECC support Date: Sat, 28 Feb 2026 12:31:00 -0500 Message-ID: <20260228173244.1509663-748-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrea Scian [ Upstream commit 89b831ebdaca0df4ca3b226f7e7a1d1db1629060 ] We need to set also write_page_raw in ecc structure to allow choosing SW ECC instead of HW one, otherwise write operation fail. Fixes: 08d8c62164a322 ("mtd: rawnand: pl353: Add support for the ARM PL353 = SMC NAND controller") Signed-off-by: Andrea Scian Cc: stable@kernel.org Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/mtd/nand/raw/pl35x-nand-controller.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/raw/pl35x-nand-controller.c b/drivers/mtd/nan= d/raw/pl35x-nand-controller.c index 11bd90e3f18cb..7f012b7c3eaec 100644 --- a/drivers/mtd/nand/raw/pl35x-nand-controller.c +++ b/drivers/mtd/nand/raw/pl35x-nand-controller.c @@ -976,6 +976,7 @@ static int pl35x_nand_attach_chip(struct nand_chip *chi= p) fallthrough; case NAND_ECC_ENGINE_TYPE_NONE: case NAND_ECC_ENGINE_TYPE_SOFT: + chip->ecc.write_page_raw =3D nand_monolithic_write_page_raw; break; case NAND_ECC_ENGINE_TYPE_ON_HOST: ret =3D pl35x_nand_init_hw_ecc_controller(nfc, chip); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13C58414933; Sat, 28 Feb 2026 17:45:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300713; cv=none; b=fTglwRMw0Xhi5/181rLZFTXYa5uXN8TIxPTdToan37xIcjoJ6e/hBe3fRiuDqRAQbxwTesguAOTHx4keTQeB9FNMYV3+5cYRWTWGbFz1p5vuYCxTDBSyQphpqY35j3BRr7ha0RZzf2RZMFliojJWr+O1ZexSq+JhTzW7AyH7R9I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300713; c=relaxed/simple; bh=SUf0qdZ6P+PWNQj5j9osWjREKs8+YSw/TMis7sPESjs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dPy5m01BYowQfv995/We/UceJmx2NrgIASTATuWFtq21E2zsKV/QtMe52Yvq5cCLUQShn4fA493mbYeX0iB9bq86/ncIUvwlJPkMPCN79ghII4y/hJPSu4NCyd38Rq2j4FFfIS7eT8dIVgjEycE+yHimo+tAzzVbcFmtGYCRXJA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FzUNoCTL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FzUNoCTL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42C13C19424; Sat, 28 Feb 2026 17:45:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300712; bh=SUf0qdZ6P+PWNQj5j9osWjREKs8+YSw/TMis7sPESjs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FzUNoCTLLmlQVqPXgq5bgq6qnA1CH9srDaTgU3sZ4IMfcPc6+aHnolocayUR4l2zu CEYYEJquAaSU4zmKzfdl73dGyDmQw+PrYLwVKYk9Bn+FSK0z3OBugLNkcpQLwtJtMZ +unjD6RyLEJW7lTs45R8OyvUceUkepGLUzXw2tBcf/E8o79nMLKJauR4lAK0TDMJcr sTW/HtrowmKkUYNv6rxKNPpMZhsiT7PTE3lxO4urVFPP7Qr8oFM59ZXG8tpI2vMuf2 imR5bjpcmV9Xz7IA/9F7wGZxi9OYLIF2AZO5UEdqKP+JycnVEpcYX1C3m+rG2LoRZB 0p2sfcSl3HvgQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Daniel Hodges , Eric Dumazet , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 748/844] tipc: fix RCU dereference race in tipc_aead_users_dec() Date: Sat, 28 Feb 2026 12:31:01 -0500 Message-ID: <20260228173244.1509663-749-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Daniel Hodges [ Upstream commit 6a65c0cb0ff20b3cbc5f1c87b37dd22cdde14a1c ] tipc_aead_users_dec() calls rcu_dereference(aead) twice: once to store in 'tmp' for the NULL check, and again inside the atomic_add_unless() call. Use the already-dereferenced 'tmp' pointer consistently, matching the correct pattern used in tipc_aead_users_inc() and tipc_aead_users_set(). Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Cc: stable@vger.kernel.org Reviewed-by: Eric Dumazet Signed-off-by: Daniel Hodges Link: https://patch.msgid.link/20260203145621.17399-1-git@danielhodges.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/tipc/crypto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c index 970db62bd029b..a3f9ca28c3d53 100644 --- a/net/tipc/crypto.c +++ b/net/tipc/crypto.c @@ -460,7 +460,7 @@ static void tipc_aead_users_dec(struct tipc_aead __rcu = *aead, int lim) rcu_read_lock(); tmp =3D rcu_dereference(aead); if (tmp) - atomic_add_unless(&rcu_dereference(aead)->users, -1, lim); + atomic_add_unless(&tmp->users, -1, lim); rcu_read_unlock(); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F051041652E; Sat, 28 Feb 2026 17:45:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300714; cv=none; b=Jv2sxUg/AUA8pIaAP5kB/Z00GZnGjvw3aiRTlJcn2FyTYHvs8FkeVtIOEa14PQQuS5RcN6jPJzoz65FFxxrUrT+LKtbkKejR8Ff9vEoLqJ9c+GjBMBLH7lJvj1ODMAMW/8SoJBcWPEhP0n1ysvk6XQAc/ZlM2ej7TozBPSA10r4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300714; c=relaxed/simple; bh=XW2U0HJTBShcycZ6yYEmu1RVekp9uFgol6PeA2a1UK4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=t2/yaBgQ6DlvAC2soxStTbvaHTYyTocsvDARJ2KYtKvBo++DmxMmlzcgsq6AEpVjxYUC2ChYkmgb4iaeW4H4t+rHmI8hMgXViAgTG0sGOmCsGcWrl2D+XGnlbsfVxLY9L7jHLJBZBIclBOWrERNn+IvWpAzBr38pNcfTQr9J/m4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZGbQqEeE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZGbQqEeE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36422C2BC87; Sat, 28 Feb 2026 17:45:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300713; bh=XW2U0HJTBShcycZ6yYEmu1RVekp9uFgol6PeA2a1UK4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZGbQqEeEbS5exsVx8n7hlkwQcozLTniSrGOP+tkMVf2bCgdQd5G+tmVl2R07w8DRm 7ns8mRJq/FdlICctNq9bvFKTCkfOQFhQL2v2X/uX/mkirpt92iDlwwFWSemB/ExJUE EXH/Dcqrrz80mTBXNRQj40oEg55L7ifHDzs6HX5BhZCZpqpaaJ5SBfnq/0rc77CrpO /iKqkdy30fbRqzMJs65GcAqyr7KYgD7cptV9sO0QEBCuFCMckPYDQS/Hcvqw2ZjcVg mnoEPTCM95rL2q2bl2yhLeLcGZlNG2Y/JhBjQs8tY8cIHgJGqvIFWuY8f9kdbmHdz6 nJw7ea6MBZiqA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sunday Clement , Alexander Deucher , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 749/844] drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() Date: Sat, 28 Feb 2026 12:31:02 -0500 Message-ID: <20260228173244.1509663-750-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sunday Clement [ Upstream commit 8a70a26c9f34baea6c3199a9862ddaff4554a96d ] The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation. Signed-off-by: Sunday Clement Reviewed-by: Alexander Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdkfd/kfd_events.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_events.c b/drivers/gpu/drm/amd/= amdkfd/kfd_events.c index 5a190dd6be4e2..844a6a28a6408 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c @@ -331,6 +331,12 @@ static int kfd_event_page_set(struct kfd_process *p, v= oid *kernel_address, if (p->signal_page) return -EBUSY; =20 + if (size < KFD_SIGNAL_EVENT_LIMIT * 8) { + pr_err("Event page size %llu is too small, need at least %lu bytes\n", + size, (unsigned long)(KFD_SIGNAL_EVENT_LIMIT * 8)); + return -EINVAL; + } + page =3D kzalloc(sizeof(*page), GFP_KERNEL); if (!page) return -ENOMEM; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 16721415FEE; Sat, 28 Feb 2026 17:45:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300715; cv=none; b=MFpwFspWDYYOrIV5j1GbsBnddDNzVNtVW3afSDfxygtzZIdOAPVM4Gp1QDT2fEO5yU405bcN9q12QUr/KhyrJ+LpWwtlXyHztyu6MuEcspnAVOml9V6BgC17O56lj5Z8msrseGLG0RmAvfl1npeCT5C8bg16nnGbJ6iP2hiAUPA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300715; c=relaxed/simple; bh=ahXYLm+8OtBX0q7N+dNK1bZZl9qTi4S3mddAQJNgEj8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NWTitKEFEo2Kn7imtHE3mS7FJpR5CYXv7e7R6KybGLpSzGtYpCm0EguVY2Zu2ht+97liqz0ho1uqahv8qhsqmGNMI70mMhypNNEZIi6MSbyzk0YjR+8ANLOL4TmAA5xjdhurXQVkFRbMiRe7rwbHouULd5+NA6iz7O8ZqxzxGYk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uobDt8p2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uobDt8p2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 216ECC19423; Sat, 28 Feb 2026 17:45:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300714; bh=ahXYLm+8OtBX0q7N+dNK1bZZl9qTi4S3mddAQJNgEj8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uobDt8p2Mt2cc6ZIj/dS8eQp2430ciU5Rn3udItyvwgloOdH5fattGjZ4HUoCtD4r OinpixwIyPKwZv4PnLhau5ofe2mM4dRfvvoYLkXlMVe6av6DznO9DaJyHwyALO3RkS nDvKtfaeBskna/iK64u6/6vTCjWH3H0Y/Yzn/JwUhq/9drxtN76lWQ68PDXT6+CneH 1p3kG8APY6Wy9rRSMYIPTUpoY9A8DHiCK63W6Ahhes5clozgdEuzTiZdEKyEjO2nP9 mQf8lDT1x7jCGkU+r+e67cElaNVrA4mayJPCS9vdr2IAbJB/yQjMP1fixajZ6AZ390 6J3Nf1Q8ruxPA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yifan Zhang , Alex Deucher , Lijo Lazar , Sasha Levin Subject: [PATCH 6.19 750/844] drm/amdgpu: Protect GPU register accesses in powergated state in some paths Date: Sat, 28 Feb 2026 12:31:03 -0500 Message-ID: <20260228173244.1509663-751-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yifan Zhang [ Upstream commit 39fc2bc4da0082c226cbee331f0a5d44db3997da ] Ungate GPU CG/PG in device_fini_hw and device_halt to protect GPU register accesses, e.g. GC registers are accessed in amdgpu_irq_disable_all= () and amdgpu_fence_driver_hw_fini(). Signed-off-by: Yifan Zhang Acked-by: Alex Deucher Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/a= md/amdgpu/amdgpu_device.c index ba6fb23b840a0..09f9d82e572da 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3659,9 +3659,6 @@ static int amdgpu_device_ip_fini_early(struct amdgpu_= device *adev) } } =20 - amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE); - amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE); - amdgpu_amdkfd_suspend(adev, true); amdgpu_userq_suspend(adev); =20 @@ -5047,6 +5044,9 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev) amdgpu_virt_fini_data_exchange(adev); } =20 + amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE); + amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE); + /* disable all interrupts */ amdgpu_irq_disable_all(adev); if (adev->mode_info.mode_config_initialized) { @@ -7502,6 +7502,9 @@ void amdgpu_device_halt(struct amdgpu_device *adev) amdgpu_xcp_dev_unplug(adev); drm_dev_unplug(ddev); =20 + amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE); + amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE); + amdgpu_irq_disable_all(adev); =20 amdgpu_fence_driver_hw_fini(adev); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D2C88415FD1; Sat, 28 Feb 2026 17:45:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300715; cv=none; b=m7rC4XjRrpy9qtI++evSgxMgDIfAZjo4ymup5zqsn7XqKZebIIAYvjdm6M6xmSSF1WD53ZKyKB9TwS4UKOhemkkUEXDTb3mDqlXOw8LrhwNNwuuY5lFjCmyeh8Q6zjKI178pn+w5Bm7mzxKk0KPYzyQvssnnme1FXQVbB/qx6jI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300715; c=relaxed/simple; bh=7CwA+MeN8tG/l0tVfl+yVvqZ6EPZcnqVLzgKng0siLQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=thy+nf/3vOnwwBwKHyg3JdMnkOm+qvRBCNGbgKtRy8x4ptNMckbfn9/xxw/vgTW1ei3INvE9Ko6EQROjzWwRKpJ4wylgrXbBn1XAFpgiWUu8ihw/15+0sTERNY3hx6o5C8k6Nz99xrIHFbDs7wiDiT2IZwUNYcV+beTn0Egjzgg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gFCLged8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gFCLged8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13444C116D0; Sat, 28 Feb 2026 17:45:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300715; bh=7CwA+MeN8tG/l0tVfl+yVvqZ6EPZcnqVLzgKng0siLQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gFCLged8al/FVbuzzmvy4polPxNBX3cE3yzoqDqSzmud1NJ1GWn4XeZBl3W4AS6Lu jxABj7Ea5KASpxtBuOMo5AmtbsiJGRHlM1TBsXPvDrojnvCfPeg0d90sgwx631ov4f ItJlbKV4qP+0Xf1CsN7k4VAXBLej+lfJ78cclFqSrllTsYHqcwv4AF3eYUSCgn3zw8 YEenaiJLdCcTbD2ocW091JtRs8AdBLNXU9pMT81CeppT0Z8Bc7weB0l4JM27z2zSSg iERMa3dseI4ZIgLT4Gp1FT3Dv0wfRJk7QU3cBlu/yd84i5cM5PsSNDV2QOJKNKEMib ynmxOOlc0gnfg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Philip Yang , Felix Kuehling , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 751/844] drm/amdgpu: GPU vm support 5-level page table Date: Sat, 28 Feb 2026 12:31:04 -0500 Message-ID: <20260228173244.1509663-752-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Philip Yang [ Upstream commit f6b1c1f5fd7237f77fc3880603ea54dcf0371a20 ] If GPU supports 5-level page table, but CPU disable 5-level page table by using boot option no5lvl or CPU feature not available, the virtual address will be 48bit, not needed to enable 5-level page table on GPU vm. If adev->vm_manager.num_level, number of pde levels, set to 4, then gfxhub and mmhub register VM_CONTEXTx_CNTL/PAGE_TABLE_DEPTH will set to 4 to enable 5-level page table in page table walker. Set vm_manager.root_level to AMDGPU_VM_PDE3, then update GPU mapping will allocate and update PDE3/PDE2/PDE1/PDE0/PTB 5-level page tables. If max_level is not 4, no change for the logic to support features needed by old ASICs. v2: squash in CONFIG fix Signed-off-by: Philip Yang Acked-by: Felix Kuehling Signed-off-by: Alex Deucher Stable-dep-of: 3b948dd0366a ("drm/amdgpu: Use 5-level paging if gmc support= 57-bit VA") Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 ++++++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 1 + 3 files changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/a= mdgpu/amdgpu_vm.c index a67285118c37b..4d329454456bc 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -2360,9 +2360,26 @@ void amdgpu_vm_adjust_size(struct amdgpu_device *ade= v, uint32_t min_vm_size, unsigned max_bits) { unsigned int max_size =3D 1 << (max_bits - 30); + bool sys_5level_pgtable =3D false; unsigned int vm_size; uint64_t tmp; =20 +#ifdef CONFIG_X86_64 + /* + * Refer to function configure_5level_paging() for details. + */ + sys_5level_pgtable =3D (native_read_cr4() & X86_CR4_LA57); +#endif + + /* + * If GPU supports 5-level page table, but system uses 4-level page table, + * then use 4-level page table on GPU + */ + if (max_level =3D=3D 4 && !sys_5level_pgtable) { + min_vm_size =3D 256 * 1024; + max_level =3D 3; + } + /* adjust vm size first */ if (amdgpu_vm_size !=3D -1) { vm_size =3D amdgpu_vm_size; @@ -2405,6 +2422,9 @@ void amdgpu_vm_adjust_size(struct amdgpu_device *adev= , uint32_t min_vm_size, tmp =3D DIV_ROUND_UP(fls64(tmp) - 1, 9) - 1; adev->vm_manager.num_level =3D min_t(unsigned int, max_level, tmp); switch (adev->vm_manager.num_level) { + case 4: + adev->vm_manager.root_level =3D AMDGPU_VM_PDB3; + break; case 3: adev->vm_manager.root_level =3D AMDGPU_VM_PDB2; break; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h b/drivers/gpu/drm/amd/a= mdgpu/amdgpu_vm.h index 15d757c016cbb..de53176a398dc 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h @@ -185,9 +185,10 @@ struct amdgpu_bo_vm; #define AMDGPU_VM_USE_CPU_FOR_COMPUTE (1 << 1) =20 /* VMPT level enumerate, and the hiberachy is: - * PDB2->PDB1->PDB0->PTB + * PDB3->PDB2->PDB1->PDB0->PTB */ enum amdgpu_vm_level { + AMDGPU_VM_PDB3, AMDGPU_VM_PDB2, AMDGPU_VM_PDB1, AMDGPU_VM_PDB0, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c b/drivers/gpu/drm/am= d/amdgpu/amdgpu_vm_pt.c index f794fb1cc06e6..c7a7d51080a87 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c @@ -51,6 +51,7 @@ static unsigned int amdgpu_vm_pt_level_shift(struct amdgp= u_device *adev, unsigned int level) { switch (level) { + case AMDGPU_VM_PDB3: case AMDGPU_VM_PDB2: case AMDGPU_VM_PDB1: case AMDGPU_VM_PDB0: --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CBA2141651E; Sat, 28 Feb 2026 17:45:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300716; cv=none; b=GcRQI82azpF8nbdU2RHSEkIRnLi/blkgWUgAqTa4wP0e7KCyS4S58TrgZ0ciwIZQw4eH1KbzrH5QeiwIgQsdoSYZ2PNjXes0A6kXRmsMDWSZs9gzvjLwhYxhTJsEXwcFjnuAvUwIfzL+Aoum2YiGs5nRo6Ox66frH2wbL9zvGhs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300716; c=relaxed/simple; bh=AhMIT7OoY6+ia1wzwEj6LDd5nymD3tVV7EHUtUD+8VE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NSgUowh36pZMIjgPF5YrBsbmkbmcZvdux8EEffS8GMbY9fm6PzbmyYc0o5n3ZLt+547SAo4tQz7ihLI1qpIYeaLPhfF/g6WqKGxl+JGG6+VZ9k/17goAMSoSeZWgUFYDTikVtGBtb3IFBfrVVloCLqEGmrgCuF4lfrYCCYhOXnE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qSQrtyXY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qSQrtyXY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06284C19423; Sat, 28 Feb 2026 17:45:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300716; bh=AhMIT7OoY6+ia1wzwEj6LDd5nymD3tVV7EHUtUD+8VE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qSQrtyXY/GjQvkY/VZ9nr3IkgirltLG98TEnNwdMbOBMjNYVRWSkw+dv3HYA92J6b KaQTAQ6UwQqEJASY4PmEjXTWjTcdtL6MFLXN3FIBTFKhg3THqxeKSjHxJGx4Hw/XyB 4bUHYTPbisPjhzL6i5fLZczNV4Hnxbu+nMVXpDjNLBp6XL4lk3ic4PSh/D9zwzJDhP KXY/C05uZrl7m1VexzetaIOSASm2MHOC4rUAKaWrg6bNhUaG/0zQa1hw3rWVjLPUr8 lBQ4XdILZWrMwAOHdYIrC4ynjW7cev7aUFK2/THtWBMNgult3Eq7ANhTi3BVf4dXe6 L2SRiB9BaXKPA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Philip Yang , =?UTF-8?q?Christian=20K=C3=B6nig?= , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 752/844] drm/amdgpu: Use 5-level paging if gmc support 57-bit VA Date: Sat, 28 Feb 2026 12:31:05 -0500 Message-ID: <20260228173244.1509663-753-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Philip Yang [ Upstream commit 3b948dd0366a0b64c02e4ed1aefdf7825942e803 ] Regardless if CPU enable 5-level paging, GPU vm use 5-level paging if gmc init with 57-bit address space support, because ARM64 4-level paging support 48-bit VA, x86 and GPU 4-level paging support 47-bit VA, require 5-level paging on GPU to support ARM64. NPA address space 52-bit mapping on NPA GPU VM require 5-level paging. Debugger trap get device snapshot expect LDS and Scratch base, limit above 57-bit, which is set only for 5-level paging. Signed-off-by: Philip Yang Reviewed-by: Christian K=C3=B6nig Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.19.x Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/a= mdgpu/amdgpu_vm.c index 4d329454456bc..bd7f83efed187 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -2360,26 +2360,9 @@ void amdgpu_vm_adjust_size(struct amdgpu_device *ade= v, uint32_t min_vm_size, unsigned max_bits) { unsigned int max_size =3D 1 << (max_bits - 30); - bool sys_5level_pgtable =3D false; unsigned int vm_size; uint64_t tmp; =20 -#ifdef CONFIG_X86_64 - /* - * Refer to function configure_5level_paging() for details. - */ - sys_5level_pgtable =3D (native_read_cr4() & X86_CR4_LA57); -#endif - - /* - * If GPU supports 5-level page table, but system uses 4-level page table, - * then use 4-level page table on GPU - */ - if (max_level =3D=3D 4 && !sys_5level_pgtable) { - min_vm_size =3D 256 * 1024; - max_level =3D 3; - } - /* adjust vm size first */ if (amdgpu_vm_size !=3D -1) { vm_size =3D amdgpu_vm_size; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB585415619; Sat, 28 Feb 2026 17:45:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300718; cv=none; b=sq/7VP03KESB+/P02OqMVxp6oNLMlZqfMLLfxV8z8VKicw3Fnp3DZ1fRX17FpwBfiQYNb0iTVPv6pdWQ4Paawr/FQiLPxwcuav+VEG7ZezSYDSKCyRLPRB4cVtVK3oqT/B0EZTvWqZPI555lPT7a1LdgyKKNG3yWdJFwDNU0rng= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300718; c=relaxed/simple; bh=EtV2LE5whI6918UgcOFQyk+HwlHhhT9iTKC/U1RTuVo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jaeb/fo3H6bnw/mVRqwlCrwccE3QWk0M57JqzjQmi/lG4xkjClC3jep3VU6ktmDgF2i6Pp+dsVklZ6dgKuGRih/d7HsXoo3/Nde4MEL0+7JSnIWl5dw9L4wql7h40i8QrJk2Sm/kL6qnKycfcEuOHjiovbPfhNYeiYYc7/QSZO4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sq51djEH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sq51djEH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E97D9C116D0; Sat, 28 Feb 2026 17:45:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300717; bh=EtV2LE5whI6918UgcOFQyk+HwlHhhT9iTKC/U1RTuVo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sq51djEHMDRXuoHzOui7neaRMJOUzGEy2brsp1tjgA+AMDE3FCGdUeK/v3LlZMjJ5 bYVbMrySU4w0+0bSupWsO5cDVKJfAGJ8Al2w/YoEk3dmLRTpp57da9g9FmOMZWeze1 5MHwmql6c9Kj12O2IC8jTGApnbkkS++P70ZGc8kgIJow+K11XWpbTgkMJ/OuIGQOp3 TNV4zSQvUwUnNl9LYyvV701G8zuwMYJVaeMhWcWO2MOZFnP9f+bOtsCUvBvEpjyxsL 2R2a2xPTgU8gJX2k8u5GnCAPes2K/+vqGEYXoKCTv+zNup01WYBf4IhhjGDyJI4Glk K+usNU0pLSB3w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kevin Hao , Alexander Sverdlin , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 753/844] net: cpsw_new: Fix unnecessary netdev unregistration in cpsw_probe() error path Date: Sat, 28 Feb 2026 12:31:06 -0500 Message-ID: <20260228173244.1509663-754-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kevin Hao [ Upstream commit 62db84b7efa63b78aed9fdbdae90f198771be94c ] The current error handling in cpsw_probe() has two issues: - cpsw_unregister_ports() may be called before cpsw_register_ports() has been executed. - cpsw_unregister_ports() is already invoked within cpsw_register_ports() in case of a register_netdev() failure, but the error path would call it again. Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based dri= ver part 1 - dual-emac") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Reviewed-by: Alexander Sverdlin Link: https://patch.msgid.link/20260205-cpsw-error-path-v1-1-6e58bae6b299@g= mail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/ti/cpsw_new.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw_new.c b/drivers/net/ethernet/ti/c= psw_new.c index 21af0a10626aa..b9fc31eb06134 100644 --- a/drivers/net/ethernet/ti/cpsw_new.c +++ b/drivers/net/ethernet/ti/cpsw_new.c @@ -2003,7 +2003,7 @@ static int cpsw_probe(struct platform_device *pdev) /* setup netdevs */ ret =3D cpsw_create_ports(cpsw); if (ret) - goto clean_unregister_netdev; + goto clean_cpts; =20 /* Grab RX and TX IRQs. Note that we also have RX_THRESHOLD and * MISC IRQs which are always kept disabled with this driver so @@ -2017,14 +2017,14 @@ static int cpsw_probe(struct platform_device *pdev) 0, dev_name(dev), cpsw); if (ret < 0) { dev_err(dev, "error attaching irq (%d)\n", ret); - goto clean_unregister_netdev; + goto clean_cpts; } =20 ret =3D devm_request_irq(dev, cpsw->irqs_table[1], cpsw_tx_interrupt, 0, dev_name(dev), cpsw); if (ret < 0) { dev_err(dev, "error attaching irq (%d)\n", ret); - goto clean_unregister_netdev; + goto clean_cpts; } =20 if (!cpsw->cpts) @@ -2034,7 +2034,7 @@ static int cpsw_probe(struct platform_device *pdev) 0, dev_name(&pdev->dev), cpsw); if (ret < 0) { dev_err(dev, "error attaching misc irq (%d)\n", ret); - goto clean_unregister_netdev; + goto clean_cpts; } =20 /* Enable misc CPTS evnt_pend IRQ */ @@ -2043,7 +2043,7 @@ static int cpsw_probe(struct platform_device *pdev) skip_cpts: ret =3D cpsw_register_notifiers(cpsw); if (ret) - goto clean_unregister_netdev; + goto clean_cpts; =20 ret =3D cpsw_register_devlink(cpsw); if (ret) @@ -2065,8 +2065,6 @@ static int cpsw_probe(struct platform_device *pdev) =20 clean_unregister_notifiers: cpsw_unregister_notifiers(cpsw); -clean_unregister_netdev: - cpsw_unregister_ports(cpsw); clean_cpts: cpts_release(cpsw->cpts); cpdma_ctlr_destroy(cpsw->dma); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9FE81415630; Sat, 28 Feb 2026 17:45:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300718; cv=none; b=AYFSp5uE1pjQkk+7Gez0bpL4G/IJMIcSwBKRk4VKELblknFWCXui3E4E+Y80oeJVbSOg9tzwtbYw2wimepJ3kBPL8Kc5EfncA3hRhKnY48JE4XKzKz+t405r6lcqL3sX9sTOIihnfdNoDEXyjs2ftMjrXwnct5kZ6IIdjxDHsik= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300718; c=relaxed/simple; bh=qpdXrmbJfQtvHDWmIsEsHq8t7y6haRxrCyfoQdXZkXc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HK8aR/0PZU92bjroblin2COLbXzO9bdUvJkb4LWauEurdR3UY48vodUhEnmirQjeaAplSAntbHCajZsDDHyTNzEAz32PvYP802wTmJOoG+SVYRGoD6XD7txnaH6e3uAlNxyTx+fG+l/ZpObRmrefQ1yadFVoOgYMqXeztdU9Cxg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LNlbQTBh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LNlbQTBh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D822CC19423; Sat, 28 Feb 2026 17:45:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300718; bh=qpdXrmbJfQtvHDWmIsEsHq8t7y6haRxrCyfoQdXZkXc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LNlbQTBh+pKCfJAhhHtth7TzRlnxfUGyIEVQYOh9kY2T311+Fj3BvyrU8PHmWGO6N TQ8nixs4sV4Hx4Rsij2PVUzLhibra/b/AEwsyn+qR8EFw1gA/JEmVio72YHwRcg3op d2EDJb0Z05aB2Jle9GvcWPMcKPAMUwFgUqmEzSaf5+8cCZwpk8kSZUeO4wfygmyphe QQoXdVV6l8pvvRb77wZ+nFCZ28wLQFfcU+pJupvrVoTD94otMm5HLXVQAKRbtVlR5O QTmwrooIcR0i7RPdOtFZy54R5sPpw8xfRI+9IyydYnz9enl9GFJD0aUQdAGgDuCLdi sT5UkpPmW+lYw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kevin Hao , Alexander Sverdlin , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 754/844] net: cpsw_new: Fix potential unregister of netdev that has not been registered yet Date: Sat, 28 Feb 2026 12:31:07 -0500 Message-ID: <20260228173244.1509663-755-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kevin Hao [ Upstream commit 9d724b34fbe13b71865ad0906a4be97571f19cf5 ] If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly. Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based dri= ver part 1 - dual-emac") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Reviewed-by: Alexander Sverdlin Link: https://patch.msgid.link/20260205-cpsw-error-path-v1-2-6e58bae6b299@g= mail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/ti/cpsw_new.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw_new.c b/drivers/net/ethernet/ti/c= psw_new.c index b9fc31eb06134..7f42f58a4b031 100644 --- a/drivers/net/ethernet/ti/cpsw_new.c +++ b/drivers/net/ethernet/ti/cpsw_new.c @@ -1472,7 +1472,7 @@ static void cpsw_unregister_ports(struct cpsw_common = *cpsw) =20 for (i =3D 0; i < cpsw->data.slaves; i++) { ndev =3D cpsw->slaves[i].ndev; - if (!ndev) + if (!ndev || ndev->reg_state !=3D NETREG_REGISTERED) continue; =20 priv =3D netdev_priv(ndev); @@ -1494,7 +1494,6 @@ static int cpsw_register_ports(struct cpsw_common *cp= sw) if (ret) { dev_err(cpsw->dev, "cpsw: err registering net device%d\n", i); - cpsw->slaves[i].ndev =3D NULL; break; } } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95C1141651E; Sat, 28 Feb 2026 17:45:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300719; cv=none; b=h3hvx/tIljJWCEa42NKce1L/9FgQnklGO+D+m+G/+ePc1sGK/9xT4tfx0M7kmczRClVFrslzxIazFsTyEOEGcJL6o1K0EJSthhV2+Hlz0EjCoMykj11vIj5U8q/WKvgALZRo689yUqkbPQ11sQY0DdUTmiCsd/wKGpSTycdInS4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300719; c=relaxed/simple; bh=aQv/3XJYR3hAjB/rejfaQpmXH4pIvSVZf7Ui6GlV/XY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jwtpvHIeAA1HEFns96z+IlBvZ+q2E243qK/JO5XwBMLYrNJYVcpVcJ6IA6+0fwXVxefV57Utgud2AvB1b/qHpq1Qv3hBsviFgvgLbMW+L9Vl8v6FFmRT0FupNYRE7ms7WzAUb99eqlvffQTCwc7C62uaMNtCFVqflBxZny+kuiM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UUAX8a4U; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UUAX8a4U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C61E9C4AF09; Sat, 28 Feb 2026 17:45:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300719; bh=aQv/3XJYR3hAjB/rejfaQpmXH4pIvSVZf7Ui6GlV/XY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UUAX8a4UM8vDVSRs4UV8xU4t+x6/K7JUww/9iY18z1ccuSkAzALWQzXvcRdxCq3Fw wlYtoNe1UvlrpUDTbk+iagKN+k71wUccuAkERT+LcgxyUUwKr53HmIEYcudLxTocoB BB+AcNO4V89pE+ow8WLu6qKZDLLWLiQN131Ta54yLHsW4bxIEh3TVFfYXM4/pJqgPa CYiPaYaaTmhvCju+37MFj/zQrAm1n5H+sEP56WRwwhf8B8DdsHfYn3cHCVDQCbRAkk GcyAIoMyNnuPCS7ZHvJMlEKd8ZIZXVj74i08dXsUyFlg1N8hAXvnnQzxLN2jKsaHIO CzmExp0p3YrWg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Sizhe Liu , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.19 755/844] PCI: Don't claim disabled bridge windows Date: Sat, 28 Feb 2026 12:31:08 -0500 Message-ID: <20260228173244.1509663-756-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ilpo J=C3=A4rvinen [ Upstream commit 2ecc1bf14e2fdaff78bd1b8e7ed3dba336a3fad5 ] The commit 8278c6914306 ("PCI: Preserve bridge window resource type flags") changed bridge window resource behavior such that flags are no longer zero if the bridge window is not valid or is disabled (mainly to preserve the type flags for later use). If a bridge window has its limit smaller than base address, pci_read_bridge_*() sets both IORESOURCE_UNSET and IORESOURCE_DISABLED to indicate the bridge window exists but is not valid with the current base and limit configuration. The code in pci_claim_bridge_resources() still depends on the old behavior of checking validity of the bridge window solely based on !r->flags, whereas after 8278c6914306, also IORESOURCE_DISABLED may indicate bridge window addresses are not valid. While pci_claim_resource() does check IORESOURCE_UNSET, pci_claim_bridge_resource() attempts to clip the resource if pci_claim_resource() fails, which is not correct for bridge window resources that are not valid. As pci_bus_clip_resource() performs clipping regardless of flags and then clears IORESOURCE_UNSET, it should not be called unless the resource is valid. The problem is visible in this log: pci 0000:20:00.0: PCI bridge to [bus 21] pci 0000:20:00.0: bridge window [io size 0x0000 disabled]: can't claim; = no address assigned pci 0000:20:00.0: [io 0x0000-0xffffffffffffffff disabled] clipped to [io= 0x0000-0xffff disabled] Add IORESOURCE_DISABLED check in pci_claim_bridge_resources() to only claim bridge windows that appear to have a valid configuration. Fixes: 8278c6914306 ("PCI: Preserve bridge window resource type flags") Reported-by: Sizhe Liu Link: https://lore.kernel.org/all/20260203023545.2753811-1-liusizhe5@huawei= .com Signed-off-by: Ilpo J=C3=A4rvinen Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/4d9228d6-a230-6ddf-e300-fbf42d523863@linux.i= ntel.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/setup-bus.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index ee8fe6e0de5fd..8311b06fadcc6 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1685,6 +1685,8 @@ static void pci_claim_bridge_resources(struct pci_dev= *dev) =20 if (!r->flags || r->parent) continue; + if (r->flags & IORESOURCE_DISABLED) + continue; =20 pci_claim_bridge_resource(dev, i); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7EE394170BE; Sat, 28 Feb 2026 17:45:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300720; cv=none; b=NdukO/PlpV9YPnDNuP3Lka+AjL+LPdSnbg/rUeE4a3P2ijQ+Li1PnsKPZQFrKUdfIN1Tdcm0zi5Yea5XWcZ0AoGKhd55z5Fs82JvK7iXI4hMs9awoEsSV+RHnjTw79Bq8SYaS5LRhlXSe/7jo43WriMGZrz/vc6NfQqDW/zF3XI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300720; c=relaxed/simple; bh=VGRqTs+iJEq+2KfvW+RRrTfqytroJsAWwlaHGjT8bjA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BVszQXcbgCKHjQ6fvOm630lGwDk1dZN58MDdOwqa0J7mmnle+ju4lqaVWiKw4gZ2QbwgQnmgkNOGpEdJVKvzkPPGhFunqqJh+xFdiesuVG4GMPpg56/aOsPoaNzDjShrzXSQvag6MjzoVt/JBsU0iGMeU9eS22LaWckWjmA0tXM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MvLsS99m; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MvLsS99m" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8A4DC19425; Sat, 28 Feb 2026 17:45:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300720; bh=VGRqTs+iJEq+2KfvW+RRrTfqytroJsAWwlaHGjT8bjA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MvLsS99mlhN/KwGbeczkEhcD6Slk3awo9st0k5rGyCtTFFN8iRDKAUw95j8NCRVZL TmtsAeAsuHlyyJ305FUzqOkFcAouN4hbMe3n6fN/wmj9RLbfm+SHjQKHuZH8XkWumh +mxb6vzHTPJ6z+P007p1cvTCkIP/tJpuhwAgVu1hB3LhI2zSzwSLnWcYf4ZUsHsGWp OafnyyB1QbPDLiIHXli76AQqq1q42nl74L2RcLur1TawsZ5pplCGv6qC3Qj3OQUfEy MMhEAJQ1pxV8bum6opov1HalkKh9nWQtdPk1HrveGYQRwYMSFHVni/xj9ijjOXiSa3 LcageaYIPCM+A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jinhui Guo , Bjorn Helgaas , Dan Williams , Sasha Levin Subject: [PATCH 6.19 756/844] PCI: Fix pci_slot_trylock() error handling Date: Sat, 28 Feb 2026 12:31:09 -0500 Message-ID: <20260228173244.1509663-757-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jinhui Guo [ Upstream commit 9368d1ee62829b08aa31836b3ca003803caf0b72 ] Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com] Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Jinhui Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Dan Williams Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251212145528.2555-1-guojinhui.liam@bytedan= ce.com Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/pci/pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index a4eb3bc2127ae..8500b862f4f2e 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -5355,10 +5355,8 @@ static int pci_slot_trylock(struct pci_slot *slot) if (!dev->slot || dev->slot !=3D slot) continue; if (dev->subordinate) { - if (!pci_bus_trylock(dev->subordinate)) { - pci_dev_unlock(dev); + if (!pci_bus_trylock(dev->subordinate)) goto unlock; - } } else if (!pci_dev_trylock(dev)) goto unlock; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BA334170D9; Sat, 28 Feb 2026 17:45:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300721; cv=none; b=oplmDerof80ZJfuSl8JJ8WhY7sNv4XT2FSorI7IWnVu/bb23RcGTIpfv1cND3etsNeaVfZKtSAjm74uigdtGDNHLBbDw4QS3/M/uzIvdHtCHjOLSbm1W929EbGNAlV+z5JRjTMxm4c82H/fG232wkteGFUQYE6WhwRI9M1bsadg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300721; c=relaxed/simple; bh=P43d+N4IGQbeLEG01p/BGme6501S6Qrro9wO6gciA7w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QywR3fcu0SP6fUaMJb7x6d5seKBOPGu/jVz8tn/2LpZ1BMQx0Gl/mkLpNHlW+DkQgoPOnurrsQ2E6fvhcBMk56Ws0QXhkD8zohhpQz1ObCt2e4XVNKBFGI2t/hT9l98HnL6NUhp296CWDZXWUd9d+Evab3coe0AqtPYROYFF44M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jtX0AZHA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jtX0AZHA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7185C116D0; Sat, 28 Feb 2026 17:45:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300721; bh=P43d+N4IGQbeLEG01p/BGme6501S6Qrro9wO6gciA7w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jtX0AZHAMCmVhihTiOCnQzvh/0rZF4YiTQ62HaFP1viWcjObiarOBlc3M5QBSmpM4 yPxlv6Iq0CsalOizq/9YmOMa/7haHjcyJZ+C/gVmaLij8ZK1RnzWiZTiq1mGjzWNt1 Fptuvy/lqE9dawo7//fZLrZh176+hIMZIj45cy3zkiSjbD8A6WiB4D7sgYQxJQ5svG 0rIleCjF7wfwNZRw1LVUkJBUt+EhSNxZ2zZYXe//FJMW80xjFyq+c8+yk6+TAhn63l nnoFFuVEBy7h5mzfjxrPyfAOhx159oUwxBkLq8AYFzS1bPwGmDMWGK+LnUS7ivqvgl I3HNe13OmNjmw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Haoxiang Li , Helge Deller , Sasha Levin Subject: [PATCH 6.19 757/844] parisc: kernel: replace kfree() with put_device() in create_tree_node() Date: Sat, 28 Feb 2026 12:31:10 -0500 Message-ID: <20260228173244.1509663-758-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Haoxiang Li [ Upstream commit dcf69599c47f29ce0a99117eb3f9ddcd2c4e78b6 ] If device_register() fails, put_device() is the correct way to drop the device reference. Found by code review. Fixes: 1070c9655b90 ("[PA-RISC] Fix must_check warnings in drivers.c") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/parisc/kernel/drivers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/parisc/kernel/drivers.c b/arch/parisc/kernel/drivers.c index 8d23fe42b0cee..809e3c171ad54 100644 --- a/arch/parisc/kernel/drivers.c +++ b/arch/parisc/kernel/drivers.c @@ -435,7 +435,7 @@ static struct parisc_device * __init create_tree_node(c= har id, dev->dev.dma_mask =3D &dev->dma_mask; dev->dev.coherent_dma_mask =3D dev->dma_mask; if (device_register(&dev->dev)) { - kfree(dev); + put_device(&dev->dev); return NULL; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 652B54178E9; Sat, 28 Feb 2026 17:45:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300722; cv=none; b=C8TzK8AM/rqTQjEgalU2Q4lPpRlyzrU02yzZzl5jOeiUx08GOS5COar5LdFwgoBnwysQGDqJmljqmBUoQYZsvaVckXQHCJehfhocohc5s0tRcuIaemtSUeEWzbGXgT7EktmrvhAR9O2o8R4vVPBTu2UcKAfejIw9jLeVLSGsLac= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300722; c=relaxed/simple; bh=J83u0kGEsCtBTesOS2pEmIsGusm+DKOl27U+XU8rUfA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ahhobkk5oM9sgjOi4qdNm1+bv+Dd2zd5ifK/93JObedannA93Jj7MXl+iWdk8ycyWCJems5krp00REkXNPfxpU9KMvG/e1A549ffHQwSbHJhpDeX6tCQtBZ//uXOwPARSbSoRsxiwadBZylxooU63hk5eDn4Rc2f+7/B5P3H/Eg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EOko73Ji; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EOko73Ji" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81430C2BC9E; Sat, 28 Feb 2026 17:45:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300722; bh=J83u0kGEsCtBTesOS2pEmIsGusm+DKOl27U+XU8rUfA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EOko73JiHfJoOXGXEJplkWZbuv2YjtMQAeZDU6gGrFp6Vml28Zpbe/br+cHPv1Fjw 91nYoxIS/vauapviQ9HuJ4sbnKPHppn/y6AlLi3wlnOWJ/Kd4vX9AYiGTPGRTVHFN5 U8FBr+hgYru1jU3X/c6/wdlSDKl9bIU80AsVygULRFUjZdKFYlPk/D7Do3rlNxbOsY xTUd4eSDWBWdwe6iUwFmuwiREjEbmzEeOaVnnWwgPZfi9TRzWtW6M0+GDxI/91mHLx gcCxvuecB40Tubh704co0GRxuhuj2vONsn7VfMTiDBzOvKeBwDkuyts1XXHXI4pScM JjEaDEfPeOtEA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Matthieu Baerts (NGI0)" , syzbot+f56f7d56e2c6e11a01b6@syzkaller.appspotmail.com, Mat Martineau , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 758/844] mptcp: pm: in-kernel: always set ID as avail when rm endp Date: Sat, 28 Feb 2026 12:31:11 -0500 Message-ID: <20260228173244.1509663-759-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Matthieu Baerts (NGI0)" [ Upstream commit d191101dee25567c2af3b28565f45346c33d65f5 ] Syzkaller managed to find a combination of actions that was generating this warning: WARNING: net/mptcp/pm_kernel.c:1074 at __mark_subflow_endp_available net/= mptcp/pm_kernel.c:1074 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_fullmesh net/mptcp/pm_= kernel.c:1446 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags_all net/mptc= p/pm_kernel.c:1474 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags+0x5de/0x640 = net/mptcp/pm_kernel.c:1538, CPU#1: syz.7.48/2535 Modules linked in: CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e67= 6cf5 #17 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-de= bian-1.17.0-1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inlin= e] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline] RIP: 0010:mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538 Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 8= 9 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 <0f> 0b 90 e9 3d= ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89 RSP: 0018:ffffc9001535b820 EFLAGS: 00010287 netdevsim0: tun_chr_ioctl cmd 1074025677 RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7 netdevsim0: linktype set to 823 RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800 FS: 00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000= 000 netlink: 'syz.3.50': attribute type 5 has an invalid length. CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 netlink: 1232 bytes leftover after parsing attributes in process `syz.3.5= 0'. CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0 Call Trace: mptcp_pm_set_flags net/mptcp/pm_netlink.c:277 [inline] mptcp_pm_nl_set_flags_doit+0x1d7/0x210 net/mptcp/pm_netlink.c:282 genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4ab/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:733 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2608 ___sys_sendmsg+0x2de/0x320 net/socket.c:2662 __sys_sendmsg net/socket.c:2694 [inline] __do_sys_sendmsg net/socket.c:2699 [inline] __se_sys_sendmsg net/socket.c:2697 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2697 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xed/0x360 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc6adb66f6d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f= 7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff= ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 netlink: 'syz.5.51': attribute type 2 has an invalid length. R13: 00007fff25e91fe0 R14: 00007fc6ac5a7ce4 R15: 00007fff25e920d7 The actions that caused that seem to be: - Create an MPTCP endpoint for address A without any flags - Create a new MPTCP connection from address A - Remove the MPTCP endpoint: the corresponding subflows will be removed - Recreate the endpoint with the same ID, but with the subflow flag - Change the same endpoint to add the fullmesh flag In this case, msk->pm.local_addr_used has been kept to 0 as expected, but the corresponding bit in msk->pm.id_avail_bitmap was still unset after having removed the endpoint, causing the splat later on. When removing an endpoint, the corresponding endpoint ID was only marked as available for "signal" types with an announced address, plus all "subflow" types, but not the other types like an endpoint corresponding to the initial subflow. In these cases, re-creating an endpoint with the same ID didn't signal/create anything. Here, adding the fullmesh flag was creating the splat when calling __mark_subflow_endp_available() from mptcp_pm_nl_fullmesh(), because msk->pm.local_addr_used was set to 0 while the ID was marked as used. To fix this issue, the corresponding bit in msk->pm.id_avail_bitmap can always be set as available when removing an MPTCP in-kernel endpoint. In other words, moving the call to __set_bit() to do it in all cases, except for "subflow" types where this bit is handled in a dedicated helper. Note: instead of adding a new spin_(un)lock_bh that would be taken in all cases, do all the actions requiring the spin lock under the same block. This modification potentially fixes another issue reported by syzbot, see [1]. But without a reproducer or more details about what exactly happened before, it is hard to confirm. Fixes: e255683c06df ("mptcp: pm: re-using ID of unused removed ADD_ADDR") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/606 Reported-by: syzbot+f56f7d56e2c6e11a01b6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/68fcfc4a.050a0220.346f24.02fb.GAE@google.co= m [1] Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260205-net-mptcp-misc-fixes-6-19-rc8-v2-1-= c2720ce75c34@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/mptcp/pm_kernel.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index b26675054b0dc..4972c19fc73e2 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -1056,10 +1056,8 @@ static bool mptcp_pm_remove_anno_addr(struct mptcp_s= ock *msk, ret =3D mptcp_remove_anno_list_by_saddr(msk, addr); if (ret || force) { spin_lock_bh(&msk->pm.lock); - if (ret) { - __set_bit(addr->id, msk->pm.id_avail_bitmap); + if (ret) msk->pm.add_addr_signaled--; - } mptcp_pm_remove_addr(msk, &list); spin_unlock_bh(&msk->pm.lock); } @@ -1097,17 +1095,15 @@ static int mptcp_nl_remove_subflow_and_signal_addr(= struct net *net, !(entry->flags & MPTCP_PM_ADDR_FLAG_IMPLICIT)); =20 list.ids[0] =3D mptcp_endp_get_local_id(msk, addr); - if (remove_subflow) { - spin_lock_bh(&msk->pm.lock); - mptcp_pm_rm_subflow(msk, &list); - spin_unlock_bh(&msk->pm.lock); - } =20 - if (entry->flags & MPTCP_PM_ADDR_FLAG_SUBFLOW) { - spin_lock_bh(&msk->pm.lock); + spin_lock_bh(&msk->pm.lock); + if (remove_subflow) + mptcp_pm_rm_subflow(msk, &list); + if (entry->flags & MPTCP_PM_ADDR_FLAG_SUBFLOW) __mark_subflow_endp_available(msk, list.ids[0]); - spin_unlock_bh(&msk->pm.lock); - } + else /* mark endp ID as available, e.g. Signal or MPC endp */ + __set_bit(addr->id, msk->pm.id_avail_bitmap); + spin_unlock_bh(&msk->pm.lock); =20 if (msk->mpc_endpoint_id =3D=3D entry->addr.id) msk->mpc_endpoint_id =3D 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4797D417903; Sat, 28 Feb 2026 17:45:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300723; cv=none; b=O6IRnN96xHdk/ux510AbmYAsQvftmdFgvgWYIOw7s/niAToGV1ro+eZWDIzxgbPGE5UdT/3Pj6ZlKbVivdll8L50rf++SENBhHrX+zba2YMx5U/tvnHHIlW+6fcSHpOhKAtb8xxZADhCtjwVjX+HMM/PiW1LiBQKJQnnPahE6Gw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300723; c=relaxed/simple; bh=ZXbbGPOEiAauBu9+joyNRBMAEU5p3ym0ZRLsyoPd6Os=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MflP81Q5rQETznknNqlo+83V1JA9FULk3IzAksCVO809dWFCfg7WaCUdOYvU6qqxTUU/5i0PieeANv1K9v+dRo642mWzNbeUXfK4iSGCYVW2laO2AVJB2LSvr5WA0f6GB03pzJ3aGeLnDrSJQvcf4rw0CUY7mZ9NhAXKvH+vntw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hHGOAM3r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hHGOAM3r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A3EAC19424; Sat, 28 Feb 2026 17:45:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300723; bh=ZXbbGPOEiAauBu9+joyNRBMAEU5p3ym0ZRLsyoPd6Os=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hHGOAM3rDNCURtFnINuuNkW0MEeB4aXFVOX9vL73YQmNe6guCTXPlhT/DRTDkwfpd 6vEhWjrwRiC9rC/1dQ922ZcelD17BWaR/VoblTrtPdgrrXgRoStyt9ut6jdcQvLItS 7BLAV0G80Ms8qyAwi2yYdjaHvQNZzQmLyOgd9R1q3EPt8DZyFF5t6oSHttlqxdy5kJ +GfdL2jr34mbYmDuEwI95MtdoOHh48abJLULrBYt+eT84Yqxu6X8aWzMy9YrmaIUPR O7MEbxftseDghvtkaZfkI11mMjNsHgq3JzqmNB1+PdP/RrmY9cDk2oXn97qZvroOzq Xm0yVdTmurlrg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Tidmore , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH 6.19 759/844] staging: rtl8723bs: fix null dereference in find_network Date: Sat, 28 Feb 2026 12:31:12 -0500 Message-ID: <20260228173244.1509663-760-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Tidmore [ Upstream commit 41460a19654c32d39fd0e3a3671cd8d4b7b8479f ] The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260202205429.20181-1-ethantidmore06@gmail.= com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/staging/rtl8723bs/core/rtw_mlme.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c b/drivers/staging/rt= l8723bs/core/rtw_mlme.c index 98704179ad35a..936c850e5aab8 100644 --- a/drivers/staging/rtl8723bs/core/rtw_mlme.c +++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c @@ -835,8 +835,10 @@ static void find_network(struct adapter *adapter) struct wlan_network *tgt_network =3D &pmlmepriv->cur_network; =20 pwlan =3D rtw_find_network(&pmlmepriv->scanned_queue, tgt_network->networ= k.mac_address); - if (pwlan) - pwlan->fixed =3D false; + if (!pwlan) + return; + + pwlan->fixed =3D false; =20 if (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) && (adapter->stapriv.asoc_sta_count =3D=3D 1)) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 51BCC41791F; Sat, 28 Feb 2026 17:45:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300724; cv=none; b=CgP9hgAThVpFQlgHqbWRg/L0QFPhrlulKYZPfIwxmICwX1EJPieyXgoyfPO2Ifxp+LyDlxmafcN2ZcRdPqHYvd/L/XSUgm7PgkybJuV4ReYYNiDPQlE3YG6+Bw2It6tPo3VpfNTYxEwL4FgOaq32UinK3ObsTDzXIYgU63kj1Co= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300724; c=relaxed/simple; bh=qoKGMMA8c2XybmlNisuifTOpQXuhT19rXE7/Qukienc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QqQy9Q9H7UhKFA8XU7aye912qes7hVJ6KybVCho2KFMpRU+626EeThli/CjngkXBn3wmx6UHPfSsRXT7PxpKBE8Lo9HX65wIysZTUCAQvKXNEo+wd74TJlFvR+X/xFrxV8F9/1/1gNBgbbEBlWo6ghUQqUPJNoAYshLyoLdMuJM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e5aD8a2c; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e5aD8a2c" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63D95C116D0; Sat, 28 Feb 2026 17:45:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300724; bh=qoKGMMA8c2XybmlNisuifTOpQXuhT19rXE7/Qukienc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=e5aD8a2c3MfdrB2AdnWXGys4z2b0NG6xOY7BtP6FzsBu7sAJkMDl7+3/wdl1crnOc 2kbLjOALTqsWiFLhkHFHiRTcr33NdQ21o0I7/Hwtb/CKeEMH18esLsfv1LQMLDv5KL /5cI/oW7P940ma8pIEqO0tOKBcv190B9+he/b3Jogeu5G4HX2jUSawzPFwnvTT8cbR Xk/ciM8Imv8EIpmkdYs2/LIo/OC+J1IzF0MlKjeVH+Dc04b4dxFz8Q+l4SsPwzOIer YPCIdQwG4jPK2/YPkR8tQo+w6k0PzlB5sAV52Gq3/b3NMqT3w8syasAy4OfgPnZDqj PFNbW/h3plKEQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gui-Dong Han , Ben Hutchings , Guenter Roeck , Sasha Levin Subject: [PATCH 6.19 760/844] hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization induced race Date: Sat, 28 Feb 2026 12:31:13 -0500 Message-ID: <20260228173244.1509663-761-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gui-Dong Han [ Upstream commit 007be4327e443d79c9dd9e56dc16c36f6395d208 ] Simply copying shared data to a local variable cannot prevent data races. The compiler is allowed to optimize away the local copy and re-read the shared memory, causing a Time-of-Check Time-of-Use (TOCTOU) issue if the data changes between the check and the usage. To enforce the use of the local variable, use READ_ONCE() when reading the shared data and WRITE_ONCE() when updating it. Apply these macros to the three identified locations (curr_sense, adc, and fault) where local variables are used for error validation, ensuring the value remains consistent. Reported-by: Ben Hutchings Closes: https://lore.kernel.org/all/6fe17868327207e8b850cf9f88b7dc58b2021f7= 3.camel@decadent.org.uk/ Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compati= bles") Fixes: b8d5acdcf525 ("hwmon: (max16065) Use local variable to avoid TOCTOU") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Link: https://lore.kernel.org/r/20260203121443.5482-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/hwmon/max16065.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/hwmon/max16065.c b/drivers/hwmon/max16065.c index 4c9e7892a73c1..43fbb9b26b102 100644 --- a/drivers/hwmon/max16065.c +++ b/drivers/hwmon/max16065.c @@ -151,27 +151,27 @@ static struct max16065_data *max16065_update_device(s= truct device *dev) int i; =20 for (i =3D 0; i < data->num_adc; i++) - data->adc[i] - =3D max16065_read_adc(client, MAX16065_ADC(i)); + WRITE_ONCE(data->adc[i], + max16065_read_adc(client, MAX16065_ADC(i))); =20 if (data->have_current) { - data->adc[MAX16065_NUM_ADC] - =3D max16065_read_adc(client, MAX16065_CSP_ADC); - data->curr_sense - =3D i2c_smbus_read_byte_data(client, - MAX16065_CURR_SENSE); + WRITE_ONCE(data->adc[MAX16065_NUM_ADC], + max16065_read_adc(client, MAX16065_CSP_ADC)); + WRITE_ONCE(data->curr_sense, + i2c_smbus_read_byte_data(client, MAX16065_CURR_SENSE)); } =20 for (i =3D 0; i < 2; i++) - data->fault[i] - =3D i2c_smbus_read_byte_data(client, MAX16065_FAULT(i)); + WRITE_ONCE(data->fault[i], + i2c_smbus_read_byte_data(client, MAX16065_FAULT(i))); =20 /* * MAX16067 and MAX16068 have separate undervoltage and * overvoltage alarm bits. Squash them together. */ if (data->chip =3D=3D max16067 || data->chip =3D=3D max16068) - data->fault[0] |=3D data->fault[1]; + WRITE_ONCE(data->fault[0], + data->fault[0] | data->fault[1]); =20 data->last_updated =3D jiffies; data->valid =3D true; @@ -185,7 +185,7 @@ static ssize_t max16065_alarm_show(struct device *dev, { struct sensor_device_attribute_2 *attr2 =3D to_sensor_dev_attr_2(da); struct max16065_data *data =3D max16065_update_device(dev); - int val =3D data->fault[attr2->nr]; + int val =3D READ_ONCE(data->fault[attr2->nr]); =20 if (val < 0) return val; @@ -203,7 +203,7 @@ static ssize_t max16065_input_show(struct device *dev, { struct sensor_device_attribute *attr =3D to_sensor_dev_attr(da); struct max16065_data *data =3D max16065_update_device(dev); - int adc =3D data->adc[attr->index]; + int adc =3D READ_ONCE(data->adc[attr->index]); =20 if (unlikely(adc < 0)) return adc; @@ -216,7 +216,7 @@ static ssize_t max16065_current_show(struct device *dev, struct device_attribute *da, char *buf) { struct max16065_data *data =3D max16065_update_device(dev); - int curr_sense =3D data->curr_sense; + int curr_sense =3D READ_ONCE(data->curr_sense); =20 if (unlikely(curr_sense < 0)) return curr_sense; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3641F4182C9; Sat, 28 Feb 2026 17:45:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300727; cv=none; b=c/A53rixDOMWL63mRzy/3kkoRrOsV569zQWSPNaGO46nAlJ4FYYxxiFg7zvrv0TArZ0vDfWDy60KOw/9u1IaY/T47yn7V60dI1XJN7EDSJPveCxPxj7emYq2uH9aTcEj7Y7iXgdn3VXCKHeJx6HSWtnqPb3fJMKeq+VdWqSMj7Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300727; c=relaxed/simple; bh=YtJ83uoawKQ7DjuY7+NET7ElXZ6UcnKZpJ0Fl0lpTgo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nj84dw/LQmKo84+qHFRmUQv0VU6CFrcaaeuukEQ9zXpJUJ2A0RBHDKomnj5AsxZxm1VC+aciGzOo8bHx1TFp+zpOcRfggvD1V2H5zBs2CaqcwjTIAxinwSVKy3agG9peyEoHoG9QMZ3SVdzGze2nwjTcPmqwRsai7vi7cuLLt98= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pK0qNJUt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pK0qNJUt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5602EC19425; Sat, 28 Feb 2026 17:45:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300727; bh=YtJ83uoawKQ7DjuY7+NET7ElXZ6UcnKZpJ0Fl0lpTgo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pK0qNJUtoLRuqqtCVANEh+WairZI9/UxW6Tzb2i0VJADicOwAm3luX8C7xBrS/EEK TaY2U04WIZdGtUcHIwfUCwmd/AFL1eMssD6U7sLNmqpPlnQqBllZ9tHQ1G7nYO+oF1 7MOijnD9gZIkl8lIgcaTIGvCFMzfRYzPHJMLpk9nOX2j+i1pDP+uvBxF+2wIJW0bUU gq5rMVbBzWb8tg0e2hQk5+MAWu98n/cFpEfcu26LXQFbSmYIYof4YubFFfFIxaMdUj RD1PCGqyWfvVaSqKq/6KkQ+AffPY8MjQ3uZiWWTlbSyw8gJIhEiHiPd5cOuM37nJ9L h/+DKkeUSZOGQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alan Maguire , Nilay Shroff , Marco Elver , Yonghong Song , Alexei Starovoitov , Andrii Nakryiko , Bart van Assche , Daniel Borkman , Eduard Zingerman , Hao Luo , Heiko Carstens , "H. Peter Anvin" , "Jason A. Donenfeld" , Jiri Olsa , John Fastabend , Kees Cook , KP Singh , Martin KaFai Lau , Miguel Ojeda , Naman Jain , Nathan Chancellor , "Paul E . McKenney" , Peter Zijlstra , Stanislav Fomichev , Uros Bizjak , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 761/844] kcsan, compiler_types: avoid duplicate type issues in BPF Type Format Date: Sat, 28 Feb 2026 12:31:14 -0500 Message-ID: <20260228173244.1509663-762-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alan Maguire [ Upstream commit 9dc052234da736f7749f19ab6936342ec7dbe3ac ] Enabling KCSAN is causing a large number of duplicate types in BTF for core kernel structs like task_struct [1]. This is due to the definition in include/linux/compiler_types.h `#ifdef __SANITIZE_THREAD__ ... `#define __data_racy volatile .. `#else ... `#define __data_racy ... `#endif Because some objects in the kernel are compiled without KCSAN flags (KCSAN_SANITIZE) we sometimes get the empty __data_racy annotation for objects; as a result we get multiple conflicting representations of the associated structs in DWARF, and these lead to multiple instances of core kernel types in BTF since they cannot be deduplicated due to the additional modifier in some instances. Moving the __data_racy definition under CONFIG_KCSAN avoids this problem, since the volatile modifier will be present for both KCSAN and KCSAN_SANITIZE objects in a CONFIG_KCSAN=3Dy kernel. Link: https://lkml.kernel.org/r/20260116091730.324322-1-alan.maguire@oracle= .com Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qua= lifier") Signed-off-by: Alan Maguire Reported-by: Nilay Shroff Tested-by: Nilay Shroff Suggested-by: Marco Elver Reviewed-by: Marco Elver Acked-by: Yonghong Song Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Bart van Assche Cc: Daniel Borkman Cc: Eduard Zingerman Cc: Hao Luo Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Jason A. Donenfeld Cc: Jiri Olsa Cc: John Fastabend Cc: Kees Cook Cc: KP Singh Cc: Martin KaFai Lau Cc: Miguel Ojeda Cc: Naman Jain Cc: Nathan Chancellor Cc: "Paul E . McKenney" Cc: Peter Zijlstra Cc: Stanislav Fomichev Cc: Uros Bizjak Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/compiler_types.h | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index d3318a3c25777..86111a189a874 100644 --- a/include/linux/compiler_types.h +++ b/include/linux/compiler_types.h @@ -303,6 +303,22 @@ struct ftrace_likely_data { # define __no_kasan_or_inline __always_inline #endif =20 +#ifdef CONFIG_KCSAN +/* + * Type qualifier to mark variables where all data-racy accesses should be + * ignored by KCSAN. Note, the implementation simply marks these variables= as + * volatile, since KCSAN will treat such accesses as "marked". + * + * Defined here because defining __data_racy as volatile for KCSAN objects= only + * causes problems in BPF Type Format (BTF) generation since struct members + * of core kernel data structs will be volatile in some objects and not in + * others. Instead define it globally for KCSAN kernels. + */ +# define __data_racy volatile +#else +# define __data_racy +#endif + #ifdef __SANITIZE_THREAD__ /* * Clang still emits instrumentation for __tsan_func_{entry,exit}() and bu= iltin @@ -314,16 +330,9 @@ struct ftrace_likely_data { * disable all instrumentation. See Kconfig.kcsan where this is mandatory. */ # define __no_kcsan __no_sanitize_thread __disable_sanitizer_instrumentati= on -/* - * Type qualifier to mark variables where all data-racy accesses should be - * ignored by KCSAN. Note, the implementation simply marks these variables= as - * volatile, since KCSAN will treat such accesses as "marked". - */ -# define __data_racy volatile # define __no_sanitize_or_inline __no_kcsan notrace __maybe_unused #else # define __no_kcsan -# define __data_racy #endif =20 #ifdef __SANITIZE_MEMORY__ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 878954182DB; Sat, 28 Feb 2026 17:45:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300728; cv=none; b=mffpy8hiSBLc+bKwRyTE0wmPNJqJ9+rdzcfKzZH8aC5BM59+yuOPFm1HsR0fkkGWj6f5muXFOLpN/pRjy1HAfUn6RA0u+yuR7eg1pcCmimJGKqVEAQ4u82v2cRT2O8oWZdujNvS6Crp94CCivVnJFIGxIilrQcnslNhBGdr+pEc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300728; c=relaxed/simple; bh=r1CH4diocVV5/6lId/JsDHVBZyZjEV5vcT3Jy3BE2Ws=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OsajJcTYOf/Ir+WJtBJZw6cLVwSYWmCfZhkzdPR0HEEen5PBeQ9aUVSnfHJ6Sio3hGZl3LynlAvcK/SxgKzwKTiGE3Md8XTUP0i8bMmvZmWf0oFXYz6ukkOIXGATG2V20BgCOWVtBmlNDky3616QPuAR7vci+GkEJbW6iO84148= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Nh/jtuh3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Nh/jtuh3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5598FC116D0; Sat, 28 Feb 2026 17:45:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300728; bh=r1CH4diocVV5/6lId/JsDHVBZyZjEV5vcT3Jy3BE2Ws=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Nh/jtuh3S0Fhn15I2BkHviS0Ukirg7MkTuEYlKjjLL9Eznx39qZDGQFYewHfea227 j2mgUe8U8UIzjffXum4ew9i2FDl1nQHaCjYT+53GXGCYpV6f9ZOcpzxoje0ZRhg+fP Q1t7y3vqWgdL2RTVNzU6xq3Vo3wRt2d9TGEnDKYS/vVUqCYvO4b7FR1m2hHw0J23JJ 3VKFrf7U1kif6Ujg4g15be6Qi7dfo/D+3u8nYpxA4WuKaXQhYPIsXyxRhTwa+qITeP pNfi833n3AGh7t6vKzbKu3WZYUOb+sBTUrEoFf07qbOOVPYfR+hGnokEByDhA5mgf3 NMIOnINMDPwkg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shengming Hu , Petr Mladek , Ingo Molnar , Mark Brown , Thomas Gleixner , Zhang Run , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 762/844] watchdog/softlockup: fix sample ring index wrap in need_counting_irqs() Date: Sat, 28 Feb 2026 12:31:15 -0500 Message-ID: <20260228173244.1509663-763-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shengming Hu [ Upstream commit cafe4074a7221dca2fa954dd1ab0cf99b6318e23 ] cpustat_tail indexes cpustat_util[], which is a NUM_SAMPLE_PERIODS-sized ring buffer. need_counting_irqs() currently wraps the index using NUM_HARDIRQ_REPORT, which only happens to match NUM_SAMPLE_PERIODS. Use NUM_SAMPLE_PERIODS for the wrap to keep the ring math correct even if the NUM_HARDIRQ_REPORT or NUM_SAMPLE_PERIODS changes. Link: https://lkml.kernel.org/r/tencent_7068189CB6D6689EB353F3D17BF5A5311A0= 7@qq.com Fixes: e9a9292e2368 ("watchdog/softlockup: Report the most frequent interru= pts") Signed-off-by: Shengming Hu Reviewed-by: Petr Mladek Cc: Ingo Molnar Cc: Mark Brown Cc: Thomas Gleixner Cc: Zhang Run Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/watchdog.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/watchdog.c b/kernel/watchdog.c index 366122f4a0f87..70eaa77242814 100644 --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -550,7 +550,7 @@ static bool need_counting_irqs(void) u8 util; int tail =3D __this_cpu_read(cpustat_tail); =20 - tail =3D (tail + NUM_HARDIRQ_REPORT - 1) % NUM_HARDIRQ_REPORT; + tail =3D (tail + NUM_SAMPLE_PERIODS - 1) % NUM_SAMPLE_PERIODS; util =3D __this_cpu_read(cpustat_util[tail][STATS_HARDIRQ]); return util > HARDIRQ_PERCENT_THRESH; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 924BF495538; Sat, 28 Feb 2026 17:45:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300729; cv=none; b=UheAy3xXnXWksN+hucTJzFQEA+Ojl97/uoLjwnr8TR1J20i/CBBGANvdx4hLoxy/fH443WgpGjekAXrHNKsRdLIp6ZW9UpEuSFQYpEyk8kaYlTdpIoqjKTxhmb40neVPZ2A4z/QzLzOGOAO1vSIsmHcEzru12cAVeG5nUgVmlHo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300729; c=relaxed/simple; bh=doQYmoj5Ue5MGqSM1/caFzg561LPLFI4l4+iCvmp3Es=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lNDQYgqkucMbl04mXh9sTznuxoh9X4+63LFFqUJdcyXS7R7IqMMTZY2lZgQ52QyHCQUbmWj1sJ/OK6HZ1jjHCCWwJUpUguvCqdpZpVeFGHphZTgEOitqYx6YE2Ua54cMsIjwh4lpEwqv1ftPGDYgOCu/0ACRBKy0i2ToTT+7OGM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eA6uQAvF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eA6uQAvF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A61B4C116D0; Sat, 28 Feb 2026 17:45:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300729; bh=doQYmoj5Ue5MGqSM1/caFzg561LPLFI4l4+iCvmp3Es=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eA6uQAvFqckkZ2rYNZ5aosDvT4HnvhKd2iGXmBV+w1onNeauMt17OCfVulMWUFTBD JSJ2LZSE+uXNYv6QwZ4PoHfUIS13zvg7ju5o9h1nuHlpFGgtlu54SoX3NsO4za7BBM Eu1Qj6xA/iYr0LTJe27hsOeyKK0WwoJgY3Q8Ron27rSV/XyIzjYcFHBsb/UDrftfS7 CnBaiioat4nP6Q8uNAc7JuoedP7Q6/NqP87924kUgCGMaOYHF+mLZ+qBWhFpCJhjax ntLxFP175mct880mvh28HJbZofXiEuTPN44GivN2kHvj18tp7pnwIvKJDsgSwhWI0C aJtoLpJvbZsxg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Carlos Song , Frank Li , Andi Shyti , Wolfram Sang , Sasha Levin Subject: [PATCH 6.19 763/844] i2c: imx-lpi2c: fix SMBus block read NACK after byte count Date: Sat, 28 Feb 2026 12:31:16 -0500 Message-ID: <20260228173244.1509663-764-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Carlos Song [ Upstream commit efdc383d1cc28d45cbf5a23b5ffa997010aaacb4 ] The LPI2C controller sends a NACK at the end of a receive command unless another receive command is already queued in MTDR. During SMBus block reads, this causes the controller to NACK immediately after receiving the block length byte, aborting the transfer before the data bytes are read. Fix this by queueing a second receive command as soon as the block length byte is received, keeping MTDR non-empty and ensuring continuous ACKs. The initial receive command reads the block length, and the subsequent command reads the remaining data bytes according to the reported length. Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver") Signed-off-by: Carlos Song Cc: # v4.10+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260123105459.3448822-1-carlos.song@nxp.com Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/i2c/busses/i2c-imx-lpi2c.c | 107 ++++++++++++++++++++++------- 1 file changed, 83 insertions(+), 24 deletions(-) diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-im= x-lpi2c.c index d882126c1778c..519a1ac832a41 100644 --- a/drivers/i2c/busses/i2c-imx-lpi2c.c +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c @@ -5,6 +5,7 @@ * Copyright 2016 Freescale Semiconductor, Inc. */ =20 +#include #include #include #include @@ -90,6 +91,7 @@ #define MRDR_RXEMPTY BIT(14) #define MDER_TDDE BIT(0) #define MDER_RDDE BIT(1) +#define MSR_RDF_ASSERTED(x) FIELD_GET(MSR_RDF, (x)) =20 #define SCR_SEN BIT(0) #define SCR_RST BIT(1) @@ -461,7 +463,7 @@ static bool lpi2c_imx_write_txfifo(struct lpi2c_imx_str= uct *lpi2c_imx, bool atom =20 static bool lpi2c_imx_read_rxfifo(struct lpi2c_imx_struct *lpi2c_imx, bool= atomic) { - unsigned int blocklen, remaining; + unsigned int remaining; unsigned int temp, data; =20 do { @@ -472,15 +474,6 @@ static bool lpi2c_imx_read_rxfifo(struct lpi2c_imx_str= uct *lpi2c_imx, bool atomi lpi2c_imx->rx_buf[lpi2c_imx->delivered++] =3D data & 0xff; } while (1); =20 - /* - * First byte is the length of remaining packet in the SMBus block - * data read. Add it to msgs->len. - */ - if (lpi2c_imx->block_data) { - blocklen =3D lpi2c_imx->rx_buf[0]; - lpi2c_imx->msglen +=3D blocklen; - } - remaining =3D lpi2c_imx->msglen - lpi2c_imx->delivered; =20 if (!remaining) { @@ -493,12 +486,7 @@ static bool lpi2c_imx_read_rxfifo(struct lpi2c_imx_str= uct *lpi2c_imx, bool atomi lpi2c_imx_set_rx_watermark(lpi2c_imx); =20 /* multiple receive commands */ - if (lpi2c_imx->block_data) { - lpi2c_imx->block_data =3D 0; - temp =3D remaining; - temp |=3D (RECV_DATA << 8); - writel(temp, lpi2c_imx->base + LPI2C_MTDR); - } else if (!(lpi2c_imx->delivered & 0xff)) { + if (!(lpi2c_imx->delivered & 0xff)) { temp =3D (remaining > CHUNK_DATA ? CHUNK_DATA : remaining) - 1; temp |=3D (RECV_DATA << 8); writel(temp, lpi2c_imx->base + LPI2C_MTDR); @@ -536,18 +524,77 @@ static int lpi2c_imx_write_atomic(struct lpi2c_imx_st= ruct *lpi2c_imx, return err; } =20 -static void lpi2c_imx_read_init(struct lpi2c_imx_struct *lpi2c_imx, - struct i2c_msg *msgs) +static unsigned int lpi2c_SMBus_block_read_length_byte(struct lpi2c_imx_st= ruct *lpi2c_imx) { - unsigned int temp; + unsigned int data; + + data =3D readl(lpi2c_imx->base + LPI2C_MRDR); + lpi2c_imx->rx_buf[lpi2c_imx->delivered++] =3D data & 0xff; + + return data; +} + +static int lpi2c_imx_read_init(struct lpi2c_imx_struct *lpi2c_imx, + struct i2c_msg *msgs) +{ + unsigned int temp, val, block_len; + int ret; =20 lpi2c_imx->rx_buf =3D msgs->buf; lpi2c_imx->block_data =3D msgs->flags & I2C_M_RECV_LEN; =20 lpi2c_imx_set_rx_watermark(lpi2c_imx); - temp =3D msgs->len > CHUNK_DATA ? CHUNK_DATA - 1 : msgs->len - 1; - temp |=3D (RECV_DATA << 8); - writel(temp, lpi2c_imx->base + LPI2C_MTDR); + + if (!lpi2c_imx->block_data) { + temp =3D msgs->len > CHUNK_DATA ? CHUNK_DATA - 1 : msgs->len - 1; + temp |=3D (RECV_DATA << 8); + writel(temp, lpi2c_imx->base + LPI2C_MTDR); + } else { + /* + * The LPI2C controller automatically sends a NACK after the last byte o= f a + * receive command, unless the next command in MTDR is also a receive co= mmand. + * If MTDR is empty when a receive completes, a NACK is sent by default. + * + * To comply with the SMBus block read spec, we start with a 2-byte read: + * The first byte in RXFIFO is the block length. Once this byte arrives,= the + * controller immediately updates MTDR with the next read command, ensur= ing + * continuous ACK instead of NACK. + * + * The second byte is the first block data byte. Therefore, the subseque= nt + * read command should request (block_len - 1) bytes, since one data byte + * has already been read. + */ + + writel((RECV_DATA << 8) | 0x01, lpi2c_imx->base + LPI2C_MTDR); + + ret =3D readl_poll_timeout(lpi2c_imx->base + LPI2C_MSR, val, + MSR_RDF_ASSERTED(val), 1, 1000); + if (ret) { + dev_err(&lpi2c_imx->adapter.dev, "SMBus read count failed %d\n", ret); + return ret; + } + + /* Read block length byte and confirm this SMBus transfer meets protocol= */ + block_len =3D lpi2c_SMBus_block_read_length_byte(lpi2c_imx); + if (block_len =3D=3D 0 || block_len > I2C_SMBUS_BLOCK_MAX) { + dev_err(&lpi2c_imx->adapter.dev, "Invalid SMBus block read length\n"); + return -EPROTO; + } + + /* + * When block_len shows more bytes need to be read, update second read c= ommand to + * keep MTDR non-empty and ensuring continuous ACKs. Only update command= register + * here. All block bytes will be read out at IRQ handler or lpi2c_imx_re= ad_atomic() + * function. + */ + if (block_len > 1) + writel((RECV_DATA << 8) | (block_len - 2), lpi2c_imx->base + LPI2C_MTDR= ); + + lpi2c_imx->msglen +=3D block_len; + msgs->len +=3D block_len; + } + + return 0; } =20 static bool lpi2c_imx_read_chunk_atomic(struct lpi2c_imx_struct *lpi2c_imx) @@ -592,6 +639,10 @@ static bool is_use_dma(struct lpi2c_imx_struct *lpi2c_= imx, struct i2c_msg *msg) if (!lpi2c_imx->can_use_dma) return false; =20 + /* DMA is not suitable for SMBus block read */ + if (msg->flags & I2C_M_RECV_LEN) + return false; + /* * A system-wide suspend or resume transition is in progress. LPI2C shoul= d use PIO to * transfer data to avoid issue caused by no ready DMA HW resource. @@ -609,10 +660,14 @@ static bool is_use_dma(struct lpi2c_imx_struct *lpi2c= _imx, struct i2c_msg *msg) static int lpi2c_imx_pio_xfer(struct lpi2c_imx_struct *lpi2c_imx, struct i2c_msg *msg) { + int ret; + reinit_completion(&lpi2c_imx->complete); =20 if (msg->flags & I2C_M_RD) { - lpi2c_imx_read_init(lpi2c_imx, msg); + ret =3D lpi2c_imx_read_init(lpi2c_imx, msg); + if (ret) + return ret; lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE | MIER_NDIE); } else { lpi2c_imx_write(lpi2c_imx, msg); @@ -624,8 +679,12 @@ static int lpi2c_imx_pio_xfer(struct lpi2c_imx_struct = *lpi2c_imx, static int lpi2c_imx_pio_xfer_atomic(struct lpi2c_imx_struct *lpi2c_imx, struct i2c_msg *msg) { + int ret; + if (msg->flags & I2C_M_RD) { - lpi2c_imx_read_init(lpi2c_imx, msg); + ret =3D lpi2c_imx_read_init(lpi2c_imx, msg); + if (ret) + return ret; return lpi2c_imx_read_atomic(lpi2c_imx, msg); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A7FB418E0F; Sat, 28 Feb 2026 17:45:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300730; cv=none; b=cxaSv6AaUYgjZRy2vBwkwhC8w3c0ODu3feXUDRiy8ZabZul6Jsw37Dm4EqDJiy9zVl66HR/bFI5YBaq0U9PZsCliD1VOq1nR7KYVXDEddCvPlmUkWoyuMA7wv76ewYmjSHPghWWbZDGaYFXYMpF+Aqp45AbvlkMwPv2MIePbZtw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300730; c=relaxed/simple; bh=s86EvEk4BoaoT1WuJ9i9KlB0ECiih2ij5rPXYWYCir8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=vGtaJRhwzPRJ/k81SkBAcRX8rrfs7hN+MMPPYp3qAMdx1WPgUQf5vlPUtejyjLgF0uLxgWDk7/v64Sw+2Hnsw7QIP/YQKrdv/Nc94Cp/Qw8JlCVI/AFc0dQN7mX4HydPKePXlZckgcDZ8pREpBc6KnRthXjbxs7YVU5tkCDqnv4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tToEiY8w; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tToEiY8w" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFAE5C19425; Sat, 28 Feb 2026 17:45:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300730; bh=s86EvEk4BoaoT1WuJ9i9KlB0ECiih2ij5rPXYWYCir8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tToEiY8wbNxuBsceL3CAoNYaHUN1dAPB1wyC0l2l1qrMReB+JhNLxBMvL+T/BqVH9 kGPmGRb/ROZPf6tVnoOmwZ09hQlT0Q2YdV5MkJoRC4EnzK2ZyuUWBYC+NsbnHhJP7S OLx0QQvN3JdCK22VI6v/U6ONBNUgdA/GvJzwCiLVs5BckylLU+33Vbyvst3ZBnPWcX jLsgPubbTmoAWiZJETPScVr7hSYRNWhvj7/aYhizEF6zhSUhC5ZJBcOpUHqvH/Hppe n3Dbulu/zp0P4ioRZhvZiSQfza86um+TFWFi/VtuVFck0yvrgYVVaqIFSmISkuKQpm Ldrgjw3xTBpmA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shyam Prasad N , Steve French , Sasha Levin Subject: [PATCH 6.19 764/844] cifs: Fix locking usage for tcon fields Date: Sat, 28 Feb 2026 12:31:17 -0500 Message-ID: <20260228173244.1509663-765-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shyam Prasad N [ Upstream commit 96c4af418586ee9a6aab61738644366426e05316 ] We used to use the cifs_tcp_ses_lock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srv_lock, ses_lock and tc_lock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization. There were still a couple of uses of cifs_tcp_ses_lock to provide tcon fields. In this patch, I've replaced them with tc_lock. Cc: stable@vger.kernel.org Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/smb/client/cached_dir.c | 4 ++-- fs/smb/client/smb2misc.c | 6 +++--- fs/smb/client/smb2ops.c | 8 +++----- fs/smb/client/smb2pdu.c | 2 ++ fs/smb/client/trace.h | 1 + 5 files changed, 11 insertions(+), 10 deletions(-) diff --git a/fs/smb/client/cached_dir.c b/fs/smb/client/cached_dir.c index 1db7ab6c2529c..569030b3e68d4 100644 --- a/fs/smb/client/cached_dir.c +++ b/fs/smb/client/cached_dir.c @@ -788,11 +788,11 @@ static void cfids_laundromat_worker(struct work_struc= t *work) cfid->dentry =3D NULL; =20 if (cfid->is_open) { - spin_lock(&cifs_tcp_ses_lock); + spin_lock(&cfid->tcon->tc_lock); ++cfid->tcon->tc_count; trace_smb3_tcon_ref(cfid->tcon->debug_id, cfid->tcon->tc_count, netfs_trace_tcon_ref_get_cached_laundromat); - spin_unlock(&cifs_tcp_ses_lock); + spin_unlock(&cfid->tcon->tc_lock); queue_work(serverclose_wq, &cfid->close_work); } else /* diff --git a/fs/smb/client/smb2misc.c b/fs/smb/client/smb2misc.c index f3cb62d914502..0871b9f1f86a6 100644 --- a/fs/smb/client/smb2misc.c +++ b/fs/smb/client/smb2misc.c @@ -820,14 +820,14 @@ smb2_handle_cancelled_close(struct cifs_tcon *tcon, _= _u64 persistent_fid, int rc; =20 cifs_dbg(FYI, "%s: tc_count=3D%d\n", __func__, tcon->tc_count); - spin_lock(&cifs_tcp_ses_lock); + spin_lock(&tcon->tc_lock); if (tcon->tc_count <=3D 0) { struct TCP_Server_Info *server =3D NULL; =20 trace_smb3_tcon_ref(tcon->debug_id, tcon->tc_count, netfs_trace_tcon_ref_see_cancelled_close); WARN_ONCE(tcon->tc_count < 0, "tcon refcount is negative"); - spin_unlock(&cifs_tcp_ses_lock); + spin_unlock(&tcon->tc_lock); =20 if (tcon->ses) { server =3D tcon->ses->server; @@ -841,7 +841,7 @@ smb2_handle_cancelled_close(struct cifs_tcon *tcon, __u= 64 persistent_fid, tcon->tc_count++; trace_smb3_tcon_ref(tcon->debug_id, tcon->tc_count, netfs_trace_tcon_ref_get_cancelled_close); - spin_unlock(&cifs_tcp_ses_lock); + spin_unlock(&tcon->tc_lock); =20 rc =3D __smb2_handle_cancelled_cmd(tcon, SMB2_CLOSE_HE, 0, persistent_fid, volatile_fid); diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index edfd6a4e87e8b..d76d79e50e8e7 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -3088,7 +3088,9 @@ smb2_get_dfs_refer(const unsigned int xid, struct cif= s_ses *ses, struct cifs_tcon, tcon_list); if (tcon) { + spin_lock(&tcon->tc_lock); tcon->tc_count++; + spin_unlock(&tcon->tc_lock); trace_smb3_tcon_ref(tcon->debug_id, tcon->tc_count, netfs_trace_tcon_ref_get_dfs_refer); } @@ -3157,13 +3159,9 @@ smb2_get_dfs_refer(const unsigned int xid, struct ci= fs_ses *ses, out: if (tcon && !tcon->ipc) { /* ipc tcons are not refcounted */ - spin_lock(&cifs_tcp_ses_lock); - tcon->tc_count--; + cifs_put_tcon(tcon, netfs_trace_tcon_ref_put_dfs_refer); trace_smb3_tcon_ref(tcon->debug_id, tcon->tc_count, netfs_trace_tcon_ref_dec_dfs_refer); - /* tc_count can never go negative */ - WARN_ON(tcon->tc_count < 0); - spin_unlock(&cifs_tcp_ses_lock); } kfree(utf16_path); kfree(dfs_req); diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index 5d57c895ca37a..c7e086dfb1765 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -4239,7 +4239,9 @@ void smb2_reconnect_server(struct work_struct *work) =20 list_for_each_entry(tcon, &ses->tcon_list, tcon_list) { if (tcon->need_reconnect || tcon->need_reopen_files) { + spin_lock(&tcon->tc_lock); tcon->tc_count++; + spin_unlock(&tcon->tc_lock); trace_smb3_tcon_ref(tcon->debug_id, tcon->tc_count, netfs_trace_tcon_ref_get_reconnect_server); list_add_tail(&tcon->rlist, &tmp_list); diff --git a/fs/smb/client/trace.h b/fs/smb/client/trace.h index a584a77431132..191f02344dcdd 100644 --- a/fs/smb/client/trace.h +++ b/fs/smb/client/trace.h @@ -189,6 +189,7 @@ EM(netfs_trace_tcon_ref_put_cancelled_close_fid, "PUT Cn-Fid") \ EM(netfs_trace_tcon_ref_put_cancelled_mid, "PUT Cn-Mid") \ EM(netfs_trace_tcon_ref_put_mnt_ctx, "PUT MntCtx") \ + EM(netfs_trace_tcon_ref_put_dfs_refer, "PUT DfsRfr") \ EM(netfs_trace_tcon_ref_put_reconnect_server, "PUT Reconn") \ EM(netfs_trace_tcon_ref_put_tlink, "PUT Tlink ") \ EM(netfs_trace_tcon_ref_see_cancelled_close, "SEE Cn-Cls") \ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64743418E27; Sat, 28 Feb 2026 17:45:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300731; cv=none; b=D3OAl3+Hpv5DxQLThIDYqoEcM5Fj4BItGePCAY0dOEJXmmIO0P3i5g431Fzky7duRk+tUbTwEqxMmm8JkUaGd22sHsxoW9ANufs5yAZ3mDUCJ9mZATkoGwwk/Ha87d95g4Xf2OrfdpWV2SHvBcywT02Eyqzvd5L3yg2jpvWQM74= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300731; c=relaxed/simple; bh=Ssi4ys2hsnK4l5iOGPWzKxKmZumXDR9aWBZNhATU+mw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GqQFgn9XofWu0HxtxhtNFsNpsbDHwKtItk7ico6wufiR2P0AgWBnIxmnvuuNlXaP4uIQAys+ImqlOjx9w1/rwWe13Lox8+mOLQdoCdC/31biG4E4qpdN5MYtngL5/6gqtl/fCP8NzjBBN6rVNLnf9KNefnDQDXIPtp7I3qt03KU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GAYUs3nI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GAYUs3nI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F147C19423; Sat, 28 Feb 2026 17:45:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300731; bh=Ssi4ys2hsnK4l5iOGPWzKxKmZumXDR9aWBZNhATU+mw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GAYUs3nI1rzQ0Rr2e5CilbbStZqhQaW9IIw4RpMJJgBdmPGnfi2HWvjIWAISj/DH2 uh+lBBxrMM49vHEtYQzVUNaH8BN0myGXOovRBEhRP5LfDKBHp0AW0v2wvpIhTP6k3G 55i3qlOCsG7ywNiIeaLq2RcNon8CbxgYPMkfx4rpNY8OhOZ01LooyuwEkEB9HPgOXj nJ38JtT8FGSViOm0dUsgwQpqFnlxtWDwaa1dY04Q4AHOTVv+TXaBD75BnKHXKE/Xpu MiIQNpbo8QEhxm+CJa+/AZLxKa07Iq+wxpnUeaBGFoJi4luF/ktNHeR41DUfc6e4UL kMyjv8Yoms2Xg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiaxun Yang , Waldemar Brodkorb , Thomas Bogendoerfer , Sasha Levin Subject: [PATCH 6.19 765/844] MIPS: rb532: Fix MMIO UART resource registration Date: Sat, 28 Feb 2026 12:31:18 -0500 Message-ID: <20260228173244.1509663-766-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiaxun Yang [ Upstream commit e93bb4b76cfefb302534246e892c7667491cb8cc ] Since commit 6e690d54cfa8 ("serial: 8250: fix return error code in serial8250_request_std_resource()"), registering an 8250 MMIO port without mapbase no longer works, as the resource range is derived from mapbase/mapsize. Populate mapbase and mapsize accordingly. Also drop ugly membase KSEG1 pointer and set UPF_IOREMAP instead, letting the 8250 core perform the ioremap. Fixes: 6e690d54cfa8 ("serial: 8250: fix return error code in serial8250_req= uest_std_resource()") Cc: stable@vger.kernel.org Reported-by: Waldemar Brodkorb Link: https://lore.kernel.org/linux-mips/aX-d0ShTplHKZT33@waldemar-brodkorb= .de/ Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/mips/rb532/devices.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c index b7f6f782d9a13..ffa4d38ca95df 100644 --- a/arch/mips/rb532/devices.c +++ b/arch/mips/rb532/devices.c @@ -212,11 +212,12 @@ static struct platform_device rb532_wdt =3D { static struct plat_serial8250_port rb532_uart_res[] =3D { { .type =3D PORT_16550A, - .membase =3D (char *)KSEG1ADDR(REGBASE + UART0BASE), + .mapbase =3D REGBASE + UART0BASE, + .mapsize =3D 0x1000, .irq =3D UART0_IRQ, .regshift =3D 2, .iotype =3D UPIO_MEM, - .flags =3D UPF_BOOT_AUTOCONF, + .flags =3D UPF_BOOT_AUTOCONF | UPF_IOREMAP, }, { .flags =3D 0, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8EAD0419960; Sat, 28 Feb 2026 17:45:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300732; cv=none; b=Zv+aNHqjf3mI1Tls/lGE5eue3nsSrENUPF0FEy+3FLFoNiygF7w0yIf5cRgUlV2Lp6Xtyvy6pYPa+wlPTJT/1BaUdOWy7SVT2EJpDfuUDWefWUOgEnlA0hbNR3vJXflwy04QVHBjEwlqwhU477i7ucG/UQZOUxLdjwcOighY9jE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300732; c=relaxed/simple; bh=Hlmh0opQC9HK0eY7nsrWlsivURzKe8R1G54uAobADrI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qtuDBxnK+LL05lkdSHx78BDCINJezSOY9xQXEK2DiuIzh8rXSq5WBvPdD+pvs9h0P1EslZyBc5thNXIV1qu/AHWz2ijqV5k+0pQSz6jNY8L4ibKF+eVeCMSJQ6+lez4DGNcnDPAxTzcUOVb3WHS/U9ZV4yKLDQc3HFwuBIEBG04= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XhsCasab; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XhsCasab" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BD10C116D0; Sat, 28 Feb 2026 17:45:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300732; bh=Hlmh0opQC9HK0eY7nsrWlsivURzKe8R1G54uAobADrI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XhsCasabwh+5YoY15talFuA/xIdPYeq2xlUxTIeeUKVhyrZ1kGBcwp11xgsEE+QzY 2R7FjhQrFQBch+owQ0LKQQTcPtZHMGfSqRZc9DvODCYLq+myYXV2riw/g/46EvI9lC A7DCl2KmTPkeLjNOfq1W3Pe6sB27PltA0n5Flxt77T7GEAxYli1AY6P92Xwi8vISXy LgEfc0K+2im7JH2np1biwZr30nMbcj2sRUsPnpcvadTAw2zbH9j36x9IhJwgEwJkWm BQKvZ60yXa8SKIZynQu8LCPCZwUFwG3AdtHGSbuVia8x/pEgedLJiHf9OXh7AdR1WK GK7K650sT8mPg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: ethanwu , Viacheslav Dubeyko , Ilya Dryomov , Sasha Levin Subject: [PATCH 6.19 766/844] ceph: supply snapshot context in ceph_zero_partial_object() Date: Sat, 28 Feb 2026 12:31:19 -0500 Message-ID: <20260228173244.1509663-767-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: ethanwu [ Upstream commit f16bd3fa74a2084ee7e16a8a2be7e7399b970907 ] The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=3Da' mon 'allow r f= sname=3Da' osd 'allow rw tag cephfs data=3Da' mount -t ceph fs_a@.a=3D/ /mnt/mycephfs/ -o conf=3D./ceph.conf dd if=3D/dev/urandom of=3D/mnt/mycephfs/foo bs=3D64K count=3D1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!! Cc: stable@vger.kernel.org Fixes: ad7a60de882ac ("ceph: punch hole support") Signed-off-by: ethanwu Reviewed-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ceph/file.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/fs/ceph/file.c b/fs/ceph/file.c index 983390069f737..9152b47227101 100644 --- a/fs/ceph/file.c +++ b/fs/ceph/file.c @@ -2568,6 +2568,7 @@ static int ceph_zero_partial_object(struct inode *ino= de, struct ceph_inode_info *ci =3D ceph_inode(inode); struct ceph_fs_client *fsc =3D ceph_inode_to_fs_client(inode); struct ceph_osd_request *req; + struct ceph_snap_context *snapc; int ret =3D 0; loff_t zero =3D 0; int op; @@ -2582,12 +2583,25 @@ static int ceph_zero_partial_object(struct inode *i= node, op =3D CEPH_OSD_OP_ZERO; } =20 + spin_lock(&ci->i_ceph_lock); + if (__ceph_have_pending_cap_snap(ci)) { + struct ceph_cap_snap *capsnap =3D + list_last_entry(&ci->i_cap_snaps, + struct ceph_cap_snap, + ci_item); + snapc =3D ceph_get_snap_context(capsnap->context); + } else { + BUG_ON(!ci->i_head_snapc); + snapc =3D ceph_get_snap_context(ci->i_head_snapc); + } + spin_unlock(&ci->i_ceph_lock); + req =3D ceph_osdc_new_request(&fsc->client->osdc, &ci->i_layout, ceph_vino(inode), offset, length, 0, 1, op, CEPH_OSD_FLAG_WRITE, - NULL, 0, 0, false); + snapc, 0, 0, false); if (IS_ERR(req)) { ret =3D PTR_ERR(req); goto out; @@ -2601,6 +2615,7 @@ static int ceph_zero_partial_object(struct inode *ino= de, ceph_osdc_put_request(req); =20 out: + ceph_put_snap_context(snapc); return ret; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 73B84419969; Sat, 28 Feb 2026 17:45:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300733; cv=none; b=q09rL1P0GjQQcJsjwq6U/spGvwn3m2/ofNLBLIpB18N+CT2eoBnNrD8k4212iDH6lmEHjOzfA5cdXdmZzk4g7AOXGIjd5/CXhmMxSOpHTbUBMS+nMuhMsLiOn6HO1Js0jtjrJqny69rXqANXPVEu9eJDtfrxG+ZKXlvrDGE2i+E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300733; c=relaxed/simple; bh=6nj11AkLtWQxIa78AOEDTUX1bUEgcX2hoEIeXFyozq4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=onNw+6g3e1FqC0GaDF0RlRhedDbhwy79SjSMZ9j5VnoReiOOEEeSxD8IqMrxHAGnuF3V+j2RNDImVOZG0kGFs+LVPb4aAkZoNgoffaqrFTJLiLNhv9OqfmnydSdJbTCKbntN/axeABzz4BPMY3OoX8eQnee1PQdVg8cM5nes3JE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GGQkTTMm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GGQkTTMm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BD2BC19423; Sat, 28 Feb 2026 17:45:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300733; bh=6nj11AkLtWQxIa78AOEDTUX1bUEgcX2hoEIeXFyozq4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GGQkTTMmGYScHBI/Lz3quJ6PPEasY8ULn7dE6SgKMlUv4aMOcHXwm4QbllZWgBQNn VNpQop7whIsHJaLgXldpq/ybTBdoJUHC7btMyIgP4Qac1L6TtTducrNp7nh8t4SnAu TNyyEUk2iQhgX15zhDtrEC3+M6SMviG0G+qEFApR64WpseuzIwpN6EJh/bSXoX3QK+ 8Y8mKZt/tzpXJR2M80170nNas4FV0VPWbotI/TM0V9J/ClPreV4912m3jKxlzgqvLk Lfz7/Gqf0pD9n4ga5ZInh+rw9RWe3PFza+bRaFmx7Uh9x3Rrxh597ogWDBXl5Yjz6q fM+GDQQZ8Zwaw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ankit Nautiyal , Jani Nikula , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Suraj Kandpal , Joonas Lahtinen , Sasha Levin Subject: [PATCH 6.19 767/844] drm/i915/quirks: Fix device id for QUIRK_EDP_LIMIT_RATE_HBR2 entry Date: Sat, 28 Feb 2026 12:31:20 -0500 Message-ID: <20260228173244.1509663-768-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ankit Nautiyal [ Upstream commit 510e7261a7bcd6232e90f0b6b9f93303bdd29f8a ] Update the device ID for Dell XPS 13 7390 2-in-1 in the quirk `QUIRK_EDP_LIMIT_RATE_HBR2` entry. The previous ID (0x8a12) was incorrect; the correct ID is 0x8a52. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Fixes: 21c586d9233a ("drm/i915/dp: Add device specific quirk to limit eDP r= ate to HBR2") Cc: Jani Nikula Cc: Ville Syrj=C3=A4l=C3=A4 Cc: Ankit Nautiyal Cc: # v6.18+ Signed-off-by: Ankit Nautiyal Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20251226043359.2553-1-ankit.k.nautiyal@intel= .com (cherry picked from commit c7c30c4093cc11ff66672471f12599a555708343) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/i915/display/intel_quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/= i915/display/intel_quirks.c index d2e16b79d6be1..1abbdd426e587 100644 --- a/drivers/gpu/drm/i915/display/intel_quirks.c +++ b/drivers/gpu/drm/i915/display/intel_quirks.c @@ -239,7 +239,7 @@ static struct intel_quirk intel_quirks[] =3D { { 0x0f31, 0x103c, 0x220f, quirk_invert_brightness }, =20 /* Dell XPS 13 7390 2-in-1 */ - { 0x8a12, 0x1028, 0x08b0, quirk_edp_limit_rate_hbr2 }, + { 0x8a52, 0x1028, 0x08b0, quirk_edp_limit_rate_hbr2 }, }; =20 static const struct intel_dpcd_quirk intel_dpcd_quirks[] =3D { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD6C341999D; Sat, 28 Feb 2026 17:45:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300734; cv=none; b=oTAryC8EI8zP91Xswgv8fgVcJQSp9NWkXD8q2/zelqp9lo7leImQbfpCdmBclJLW0+ZgMTpvTazqlcwdD2up9nsZRbVPTJQIDbNdBhwv53OJp6bZmScwL3OaAly7X4LPL8oLAbB4H6/1D8TQRu5iqC+t0O01jBEq5ZfTU2ubhqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300734; c=relaxed/simple; bh=bLVy6HQwsr+8u5KfKcxO8vi0mFCKBljaXDJoAFyc1AI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WqR46YExXEu8WVyA92caKzFCLBxX40YUjYfehxdywwnL7T9XoadVoy7Wfwq/H5FGzdmXh6IhzuPwwDWr+3DRAeLBTcaWh3lTKeaEMIZImKdybElYtoIWTlnHjdS4vRjoizigDZc0oyUd3EqEHfzk6+BvTpDMnDdO2OjEVjomZEI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TchFH1Dz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TchFH1Dz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B16CC2BC87; Sat, 28 Feb 2026 17:45:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300734; bh=bLVy6HQwsr+8u5KfKcxO8vi0mFCKBljaXDJoAFyc1AI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TchFH1DzMXabrMAByugtJpVvEgLl2V2nH1CBqo38gStPP8I0Qbjj/H+39gVAUgVCX mb61RfURtguYL5RPa/+Oh0ADTJsabTgIGoV+FciBEq+S+fbmS9jJkIe1wohyDWzt2I E0Mp97//NS4v5ChImb3WivXrkSJPAtxdXM9oSaD5AmTF+1Sg6Oz8r4eawHFIcv3Awp +VFb4FQ6wpJhnnrtvkXS8zxU2gmZENU8lwz0ED9lqkaqR7mxJKt9DrCC5BUxZIHY+Q jVmVvaeGOQcwWA/D1FYkbWaKnyZ3NhQ9c/NOCAB6m4R89a9lxgCQWAlFQJMXh4oCyD Or16ECg24tfhw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miguel Ojeda , David Wood , Wesley Wiser , Gary Guo , Sasha Levin Subject: [PATCH 6.19 768/844] rust: kbuild: pass `-Zunstable-options` for Rust 1.95.0 Date: Sat, 28 Feb 2026 12:31:21 -0500 Message-ID: <20260228173244.1509663-769-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miguel Ojeda [ Upstream commit 0a9be83e57de0d0ca8ca4ec610bc344f17a8e5e7 ] Custom target specifications are unstable, but starting with Rust 1.95.0, `rustc` requires to explicitly pass `-Zunstable-options` to use them [1]: error: error loading target specification: custom targets are unstable = and require `-Zunstable-options` | =3D help: run `rustc --print target-list` for a list of built-in targ= ets David (Rust compiler team lead), writes: "We're destabilising custom targets to allow us to move forward with build-std without accidentally exposing functionality that we'd like to revisit prior to committing to. I'll start a thread on Zulip to discuss with the RfL team how we can come up with an alternative for them." Thus pass it. Cc: David Wood Cc: Wesley Wiser Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in = older LTSs). Link: https://github.com/rust-lang/rust/pull/151534 [1] Reviewed-by: Gary Guo Tested-by: Gary Guo Link: https://patch.msgid.link/20260206204535.39431-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- rust/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/rust/Makefile b/rust/Makefile index 4dcc2eff51cb2..725158740fc6f 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -552,6 +552,8 @@ $(obj)/$(libpin_init_internal_name): private rustc_targ= et_flags =3D --cfg kernel $(obj)/$(libpin_init_internal_name): $(src)/pin-init/internal/src/lib.rs F= ORCE +$(call if_changed_dep,rustc_procmacro) =20 +# `rustc` requires `-Zunstable-options` to use custom target specifications +# since Rust 1.95.0 (https://github.com/rust-lang/rust/pull/151534). quiet_cmd_rustc_library =3D $(if $(skip_clippy),RUSTC,$(RUSTC_OR_CLIPPY_QU= IET)) L $@ cmd_rustc_library =3D \ OBJTREE=3D$(abspath $(objtree)) \ @@ -562,6 +564,7 @@ quiet_cmd_rustc_library =3D $(if $(skip_clippy),RUSTC,$= (RUSTC_OR_CLIPPY_QUIET)) L --crate-type rlib -L$(objtree)/$(obj) \ --crate-name $(patsubst %.o,%,$(notdir $@)) $< \ --sysroot=3D/dev/null \ + -Zunstable-options \ $(if $(rustc_objcopy),;$(OBJCOPY) $(rustc_objcopy) $@) \ $(cmd_objtool) =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B87D41A245; Sat, 28 Feb 2026 17:45:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300735; cv=none; b=OQpktw/ADBMi7jCoztcasir+l9avQOUcxFe5HlHqX6GeD39tLvBP5Kh5w6OJyaBF5zxsoEpMVbHOk2EvhZXS+U0sgRXFilq+C6vRcDVh7q4cbP4k6nk+znZ/vi8HQ6dHC0j82G6udpQjSPkAbcdTYllEN7cZ7F39wR/yIpDwkCg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300735; c=relaxed/simple; bh=RpB3DW51fZCyj15eTUSIKRiq+wX54JMMajurU4ynt5o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=m0ZjgOHYOU9vJrxqhj4RnxDea191aY75jqEQaYqZ9LfRk8W2NZcDRJ4rj94/effGMMjz1ntzTEPBIuSA15d7R6LH7XjATS0bGh2ANehRsZadwbIq0K3NW7AWnatNomeBswyzeD5X27V/wJki3wORmCZJveME40asv05ig5Rjis0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PWreLr7h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PWreLr7h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A23EBC19424; Sat, 28 Feb 2026 17:45:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300735; bh=RpB3DW51fZCyj15eTUSIKRiq+wX54JMMajurU4ynt5o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PWreLr7hwXg2Ufh688fFUAGB5Hai+zqwZ/9hywri+71ORz0vpmo/B8ifBqblpCRR/ 8ALN4EQpUMPYOWbzW3O8wtRrP93Xh/BWiLHlwwyIq+2Rx5RnPn5/VeaVOaztFice0X pfrS/ArexJLXsn8RxI1EYVrCvZK8+PxHZ7hkk0ae2J2gjpJw7LwrUfg9OoiCLA2oyo +1njBxreZF9ihb6zOFh5nHEgBn9rQXmVN86vnfXoi8Ze7lYgILPA/fdxfa5uSXoWUq DyIFNWwuK9KxAbo45AKTuLgO3BKD9AncvIoHE3A5S4tN14lSFcYgEcsmm0AcVGv44H oN5xCchrI4BSg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harry Yoo , Vlastimil Babka , Sasha Levin Subject: [PATCH 6.19 769/844] mm/slab: do not access current->mems_allowed_seq if !allow_spin Date: Sat, 28 Feb 2026 12:31:22 -0500 Message-ID: <20260228173244.1509663-770-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harry Yoo [ Upstream commit 144080a5823b2dbd635acb6decf7ab23182664f3 ] Lockdep complains when get_from_any_partial() is called in an NMI context, because current->mems_allowed_seq is seqcount_spinlock_t and not NMI-safe: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D WARNING: inconsistent lock state 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff889085799820 (&____s->seqcount#3){.-.-}-{0:0}, at: ___slab_alloc+0x58= f/0xc00 {INITIAL USE} state was registered at: lock_acquire+0x185/0x320 kernel_init_freeable+0x391/0x1150 kernel_init+0x1f/0x220 ret_from_fork+0x736/0x8f0 ret_from_fork_asm+0x1a/0x30 irq event stamp: 56 hardirqs last enabled at (55): [] _raw_spin_unlock_irq= +0x27/0x70 hardirqs last disabled at (56): [] __schedule+0x2a8a/0x= 6630 softirqs last enabled at (0): [] copy_process+0x1dc1/0= x6a10 softirqs last disabled at (0): [<0000000000000000>] 0x0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&____s->seqcount#3); lock(&____s->seqcount#3); *** DEADLOCK *** According to Documentation/locking/seqlock.rst, seqcount_t is not NMI-safe and seqcount_latch_t should be used when read path can interrupt the write-side critical section. In this case, do not access current->mems_allowed_seq and avoid retry. Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") Cc: stable@vger.kernel.org Signed-off-by: Harry Yoo Link: https://patch.msgid.link/20260210081900.329447-2-harry.yoo@oracle.com Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/slub.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 78946116ecd2f..6304a2b7b8318 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3610,6 +3610,7 @@ static struct slab *get_any_partial(struct kmem_cache= *s, enum zone_type highest_zoneidx =3D gfp_zone(pc->flags); struct slab *slab; unsigned int cpuset_mems_cookie; + bool allow_spin =3D gfpflags_allow_spinning(pc->flags); =20 /* * The defrag ratio allows a configuration of the tradeoffs between @@ -3634,7 +3635,15 @@ static struct slab *get_any_partial(struct kmem_cach= e *s, return NULL; =20 do { - cpuset_mems_cookie =3D read_mems_allowed_begin(); + /* + * read_mems_allowed_begin() accesses current->mems_allowed_seq, + * a seqcount_spinlock_t that is not NMI-safe. Do not access + * current->mems_allowed_seq and avoid retry when GFP flags + * indicate spinning is not allowed. + */ + if (allow_spin) + cpuset_mems_cookie =3D read_mems_allowed_begin(); + zonelist =3D node_zonelist(mempolicy_slab_node(), pc->flags); for_each_zone_zonelist(zone, z, zonelist, highest_zoneidx) { struct kmem_cache_node *n; @@ -3656,7 +3665,7 @@ static struct slab *get_any_partial(struct kmem_cache= *s, } } } - } while (read_mems_allowed_retry(cpuset_mems_cookie)); + } while (allow_spin && read_mems_allowed_retry(cpuset_mems_cookie)); #endif /* CONFIG_NUMA */ return NULL; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D5F841A264; Sat, 28 Feb 2026 17:45:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300736; cv=none; b=XQW+Q3d5f+f3/4ckn0bS0u3V5aUIhZOCG63rHtn06IqNR5ymtWLOmAC9EFrDQkFlW/Wqk+lB+qTR2NZW73VsLQ7fx5lQRJEabVhbpCMqhQpyjts94/N7OT0EFo8mNNRkQMjjjc9grugv6d/jxke70wP23FAGSfMjqzQBHGvHnIs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300736; c=relaxed/simple; bh=h9Z/KId332mUdy5fm53XOU9xtmdVeVuae9Ii70xwFTQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K8+L9fdIhO14BNfIs0bi0zvQOCmvxXJN8vWZOOFbspG8JpSX3lRi/b27n/w88zmO9S5oN3ykCbz7T4vNwdOsHt+JaYNDzXrMOyATyLxsW2Ym8dM7EopCEVSzIppC2HJPfibyCaNQct2gUp6oHYvok+MVfdZmPL5OObCIlKtW04c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FNnVAvwC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FNnVAvwC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 805CFC19423; Sat, 28 Feb 2026 17:45:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300736; bh=h9Z/KId332mUdy5fm53XOU9xtmdVeVuae9Ii70xwFTQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FNnVAvwCtf6VV0MedJFfUbSrS4k2JoxoqneC/FrSvBbXGlpWTw6dkEzyy3SjhmAOS ZtaFpkqfzHrOZSEw8linucgDz/BRQ5VfB+Fe7Kd3r98IoaIVvo85VEF/iK6D4WvdE2 Ciw9ejmL5ii5llRDCCHKJdCX1RUHiLYxF3IOWOMlOsdTNaaR7UsWa7bxs2zaYRZ4zx e/Z9qdQLwgEZNCtiab7j7NCwGytm4zXaOZp7OaBavq8xc4YDpdgQGxgscTn/703spc sFlrXXkSwogj6ToWz3bQZMMIDjQaNpModphu2m5CQXkjOwFMefPbrojNvS1ESqgT3H NCQCkWctD97dg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harry Yoo , Vlastimil Babka , Sasha Levin Subject: [PATCH 6.19 770/844] mm/slab: use prandom if !allow_spin Date: Sat, 28 Feb 2026 12:31:23 -0500 Message-ID: <20260228173244.1509663-771-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harry Yoo [ Upstream commit a1e244a9f177894969c6cd5ebbc6d72c19fc4a7a ] When CONFIG_SLAB_FREELIST_RANDOM is enabled and get_random_u32() is called in an NMI context, lockdep complains because it acquires a local_lock: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D WARNING: inconsistent lock state 6.19.0-rc5-slab-for-next+ #325 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/8312 [HC2[2]:SC0[0]:HE0:SE1] takes: ffff88a02ec49cc0 (batched_entropy_u32.lock){-.-.}-{3:3}, at: get_random_u= 32+0x7f/0x2e0 {INITIAL USE} state was registered at: lock_acquire+0xd9/0x2f0 get_random_u32+0x93/0x2e0 __get_random_u32_below+0x17/0x70 cache_random_seq_create+0x121/0x1c0 init_cache_random_seq+0x5d/0x110 do_kmem_cache_create+0x1e0/0xa30 __kmem_cache_create_args+0x4ec/0x830 create_kmalloc_caches+0xe6/0x130 kmem_cache_init+0x1b1/0x660 mm_core_init+0x1d8/0x4b0 start_kernel+0x620/0xcd0 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xf3/0x140 common_startup_64+0x13e/0x148 irq event stamp: 76 hardirqs last enabled at (75): [] exc_nmi+0x11a/0x240 hardirqs last disabled at (76): [] sysvec_irq_work+0x11= /0x110 softirqs last enabled at (0): [] copy_process+0xc7a/0x= 2350 softirqs last disabled at (0): [<0000000000000000>] 0x0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(batched_entropy_u32.lock); lock(batched_entropy_u32.lock); *** DEADLOCK *** Fix this by using pseudo-random number generator if !allow_spin. This means kmalloc_nolock() users won't get truly random numbers, but there is not much we can do about it. Note that an NMI handler might interrupt prandom_u32_state() and change the random state, but that's safe. Link: https://lore.kernel.org/all/0c33bdee-6de8-4d9f-92ca-4f72c1b6fb9f@suse= .cz Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") Cc: stable@vger.kernel.org Signed-off-by: Harry Yoo Link: https://patch.msgid.link/20260210081900.329447-3-harry.yoo@oracle.com Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/slub.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 6304a2b7b8318..889c2804bbfeb 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include @@ -3196,8 +3197,11 @@ static void *next_freelist_entry(struct kmem_cache *= s, return (char *)start + idx; } =20 +static DEFINE_PER_CPU(struct rnd_state, slab_rnd_state); + /* Shuffle the single linked freelist based on a random pre-computed seque= nce */ -static bool shuffle_freelist(struct kmem_cache *s, struct slab *slab) +static bool shuffle_freelist(struct kmem_cache *s, struct slab *slab, + bool allow_spin) { void *start; void *cur; @@ -3208,7 +3212,19 @@ static bool shuffle_freelist(struct kmem_cache *s, s= truct slab *slab) return false; =20 freelist_count =3D oo_objects(s->oo); - pos =3D get_random_u32_below(freelist_count); + if (allow_spin) { + pos =3D get_random_u32_below(freelist_count); + } else { + struct rnd_state *state; + + /* + * An interrupt or NMI handler might interrupt and change + * the state in the middle, but that's safe. + */ + state =3D &get_cpu_var(slab_rnd_state); + pos =3D prandom_u32_state(state) % freelist_count; + put_cpu_var(slab_rnd_state); + } =20 page_limit =3D slab->objects * s->size; start =3D fixup_red_left(s, slab_address(slab)); @@ -3235,7 +3251,8 @@ static inline int init_cache_random_seq(struct kmem_c= ache *s) return 0; } static inline void init_freelist_randomization(void) { } -static inline bool shuffle_freelist(struct kmem_cache *s, struct slab *sla= b) +static inline bool shuffle_freelist(struct kmem_cache *s, struct slab *sla= b, + bool allow_spin) { return false; } @@ -3320,7 +3337,7 @@ static struct slab *allocate_slab(struct kmem_cache *= s, gfp_t flags, int node) =20 setup_slab_debug(s, slab, start); =20 - shuffle =3D shuffle_freelist(s, slab); + shuffle =3D shuffle_freelist(s, slab, allow_spin); =20 if (!shuffle) { start =3D fixup_red_left(s, start); @@ -8627,6 +8644,9 @@ void __init kmem_cache_init_late(void) { flushwq =3D alloc_workqueue("slub_flushwq", WQ_MEM_RECLAIM, 0); WARN_ON(!flushwq); +#ifdef CONFIG_SLAB_FREELIST_RANDOM + prandom_init_once(&slab_rnd_state); +#endif } =20 struct kmem_cache * --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DCC741A277; Sat, 28 Feb 2026 17:45:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300737; cv=none; b=YIb9cqVEOhCQtnEqr5XlEyunw1X9SVl79osQY2mopYS2omWWDRFoQ7ZpELyagWEvkHn6ATv7VT1yElmXfy3HtPSNVMpHonSQSas5gC8BYSFSFCUIMqz2/OcKdgSJEtzgolHFss72KBTxA608CMaQtZ7murmRjRaPp0gzrhBfpW8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300737; c=relaxed/simple; bh=emobCQBnMg46p/11boViFk59VezvSiUxF6K3V1JMj8I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Sj+xn7uz1MKXKLJ5kEmoUHbXY9O0BUw7BsBcpX5TG5Zt/wgitvyL+BsSQtyt3IZFe1jiEYP786tJvW4df1c96WKBvGS9KFYI+fDJqTwKI9xIfUVZcJzEE+zVtemBj/kvdblTnF6Y37nbbz2wwGdQGYjkQ+836p6ACXlXuK3WhsI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SITkB9kZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SITkB9kZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D2F7C19425; Sat, 28 Feb 2026 17:45:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300737; bh=emobCQBnMg46p/11boViFk59VezvSiUxF6K3V1JMj8I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SITkB9kZv227NPqAQa/sxm5eiLPIWZq8SxqCHMKoDrcvIVc7HUu8yVYI/46OuvHKJ QqLi5a1Klx6hf0r4X5KVZKK+1ajOSIzuXgvB4gKukYdjrVspK2psEquJMjmEOXu+8A ySSXG8suyYeEMdZkZYP+yxmD+T6AVBhUBWLTrXm193vM74sYyApUYslg9ZlCCklQig SE/b+cgG6dIgFgm4LfE8ffr0pxTb/vM61j3f4zbVUBOJN5phMGU95NleroEruCEySX qyaJkkZk1qBTtSkVzJDv1y7oPw931IKgOfI3GFWOHQxRnO7zpODgtZvlhireXlwdK9 Wj8DnLjvmvfbQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Garry , Huacai Chen , Sasha Levin Subject: [PATCH 6.19 771/844] LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE Date: Sat, 28 Feb 2026 12:31:24 -0500 Message-ID: <20260228173244.1509663-772-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Garry [ Upstream commit 94b0c831eda778ae9e4f2164a8b3de485d8977bb ] The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this. Cc: stable@vger.kernel.org Signed-off-by: John Garry Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/loongarch/include/asm/topology.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/loongarch/include/asm/topology.h b/arch/loongarch/include= /asm/topology.h index f06e7ff25bb7c..6b79d6183085a 100644 --- a/arch/loongarch/include/asm/topology.h +++ b/arch/loongarch/include/asm/topology.h @@ -12,7 +12,7 @@ =20 extern cpumask_t cpus_on_node[]; =20 -#define cpumask_of_node(node) (&cpus_on_node[node]) +#define cpumask_of_node(node) ((node) =3D=3D NUMA_NO_NODE ? cpu_all_mask = : &cpus_on_node[node]) =20 struct pci_bus; extern int pcibus_to_node(struct pci_bus *); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE2A641AB26; Sat, 28 Feb 2026 17:45:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300737; cv=none; b=VcI0AqDpyGuYA0Uau2+pZ4h0bPZWWuFbsR4lAudd7+cfT0J72aZJABtWyFVEyXfFianUuk0CkvzwJcryiaGD0gtleKoGjNJp5D/B1DQP62UTUzvL/dbiE9RvVRt4ius/3brbg1zwmYHuPHKqWtC76I9QOh76QgxE9ZQordcYTWw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300737; c=relaxed/simple; bh=+QmB+On8mef2rFA1QxU+2uPtpps85pIbmRUMtawkgk4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uVCK+PmBWYl/Y3PgYHF945vVAn7eVYuv1kHNdRnyeTeAogbDf1BS9N9jqFU1IPASoLYVYa9X/gOzkKw/xYfn36YVQttrvwihml2BWWQf1TWhT2tUyp2psFa07aZbvk/NnmDrJi/Sql15yEh5mUBK9T9qYtrLZcBunMAT2ZZzvag= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Q9K1gK8h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Q9K1gK8h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A1EFC2BC87; Sat, 28 Feb 2026 17:45:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300737; bh=+QmB+On8mef2rFA1QxU+2uPtpps85pIbmRUMtawkgk4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q9K1gK8h7b0mkB0y26mz3eAQ26w2SayD7CCyHEFa70lnJNAxUgJicJ7szoV64qX+Q p/stI4Mqdtzk8Rl7z9fNj/RftJUz89QcuN+a8JXeGOaCv2nXbD2c8MDkEmbbjHW2A2 yTFEMzSz1EWAiU1QCFYQTq3QwskgH3AxME55bllz3DsqDm7pwfCiJ6SGfQkUqx1h+3 FnyjJq67u81v877gz6PBZSNx2hBRZqhRMZnOFTGDGuClY7y8fejtvE2b+ChirwtUx4 q3qrfbHMKcFp7BRX938CLIhNRvLbU0dJFHgr5h2dVdIy1QlZQYRbqNEUT2DdpxcPDK wf6sbVmvSPF2w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Huacai Chen , Sasha Levin Subject: [PATCH 6.19 772/844] LoongArch: Prefer top-down allocation after arch_mem_init() Date: Sat, 28 Feb 2026 12:31:25 -0500 Message-ID: <20260228173244.1509663-773-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Huacai Chen [ Upstream commit 2172d6ebac9372eb01fe4505a53e18cb061e103b ] Currently we use bottom-up allocation after sparse_init(), the reason is sparse_init() need a lot of memory, and bottom-up allocation may exhaust precious low memory (below 4GB). On the other hand, SWIOTLB and CMA need low memories for DMA32, so swiotlb_init() and dma_contiguous_reserve() need bottom-up allocation. Since swiotlb_init() and dma_contiguous_reserve() are both called in arch_mem_init(), we no longer need bottom-up allocation after that. So we set the allocation policy to top-down at the end of arch_mem_init(), in order to avoid later memory allocations (such as KASAN) exhaust low memory. This solve at least two problems: 1. Some buggy BIOSes use 0xfd000000~0xfe000000 for secondary CPUs, but didn't reserve this range, which causes smpboot failures. 2. Some DMA32 devices, such as Loongson-DRM and OHCI, cannot work with KASAN enabled. Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/loongarch/kernel/setup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c index 20cb6f3064568..2b260d15b2e25 100644 --- a/arch/loongarch/kernel/setup.c +++ b/arch/loongarch/kernel/setup.c @@ -421,6 +421,7 @@ static void __init arch_mem_init(char **cmdline_p) PFN_UP(__pa_symbol(&__nosave_end))); =20 memblock_dump_all(); + memblock_set_bottom_up(false); =20 early_memtest(PFN_PHYS(ARCH_PFN_OFFSET), PFN_PHYS(max_low_pfn)); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B40D441AB44; Sat, 28 Feb 2026 17:45:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300738; cv=none; b=IMfAScZjr5OTDAv1Idlj8r4UvpvxtptQvSt82lXBE1UIVnaZL5DJYQ2Pb9rOKLSgmazxU3KLKGlx9vvJiafbUemx87SfGqN4NR6h0HzW8RBMODvC/7b5Lg+NnHtYxOw46DY0kJZ93jIPqD7jnVvkBe8Ei8ROjY8FliUQj4KEL/4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300738; c=relaxed/simple; bh=8com0PjHSTh+0gD2UpQ0rW8+1kO9JKtyYtGcqgEWsf0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GjrsiTh1PnYqYHp7HsASgXRrmaH8FnL12/lhSMdqx1OpEnh9l/7XLfMLmrxIvwlbrEgZuiESA/f+QjADh+CXyadWMURiHm4k1REcQ0D38Uqh6V+mISd1AnvUiMWUAaTDQlicuFj5yN2YKX/UoWlgPtK2eTVEMZDWHM8jPgpvYXA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=h8pCzqTr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="h8pCzqTr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02235C116D0; Sat, 28 Feb 2026 17:45:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300738; bh=8com0PjHSTh+0gD2UpQ0rW8+1kO9JKtyYtGcqgEWsf0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=h8pCzqTr9D4TwkrBjtBXXZpgWFj9JnAPbPqhqC0CPHwfxuTdnVZ/sphQpfadZFJJ3 qJAs2alXOwzexQjisXpR1uRR4EZXeeH/x9pstLX7dx6+7x8J7ALXgy7Vuta6T4Pqe7 HQXKo86HTRSXfgyVAh5eugvNWh8vZrOmyYrkbmjcFFetTBflChV+IysZy9xTz/BRx4 qKI+18GQiFLTwHKSx8Rpn8sy+JmRXM18C4WnW4NJXxRF4JFHiogBOcvU7dl2BB7Tcz CAg3YUskyCxXdVCE9fJEqwdHJviE6WFbxqQd6F95GjdZvnpq0R02HX2DtOayuyvASH TRyRTd48QJM3g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tiezhu Yang , Huacai Chen , Sasha Levin Subject: [PATCH 6.19 773/844] LoongArch: Use %px to print unmodified unwinding address Date: Sat, 28 Feb 2026 12:31:26 -0500 Message-ID: <20260228173244.1509663-774-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tiezhu Yang [ Upstream commit 77403a06d845db1caf9a6b0867b43e9dd8de8e4a ] Currently, use %p to prevent leaking information about the kernel memory layout when printing the PC address, but the kernel log messages are not useful to debug problem if bt_address() returns 0. Given that the type of "pc" variable is unsigned long, it should use %px to print the unmodified unwinding address. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/loongarch/kernel/unwind_orc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/loongarch/kernel/unwind_orc.c b/arch/loongarch/kernel/unw= ind_orc.c index 8a6e3429a860e..d6b3688a1ce97 100644 --- a/arch/loongarch/kernel/unwind_orc.c +++ b/arch/loongarch/kernel/unwind_orc.c @@ -494,7 +494,7 @@ bool unwind_next_frame(struct unwind_state *state) =20 state->pc =3D bt_address(pc); if (!state->pc) { - pr_err("cannot find unwind pc at %p\n", (void *)pc); + pr_err("cannot find unwind pc at %px\n", (void *)pc); goto err; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 880B34963AA; Sat, 28 Feb 2026 17:45:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300739; cv=none; b=egY1ipvI8lGjCk1IKub0QTEX80wL+tle9TV3R2aSwa5CrjbaK/7OvZfewuzctRDrJifsE43U3X3eWiiVw1d58gzleXhv25jvwQLC2OL68vSjEW0rcCWRI6mtYRdbzKgLTGrQ5ijzEcuNIpCIXA/gEoQugx/Ue7bdWUSyuIpDHxo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300739; c=relaxed/simple; bh=behYP//EBJQWzRhmcJ7IjtX8DC9jh8obcpcJyQBZJUQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pbB79lI5I7kabIhj7C52RMCcnvQ/TymhnNjhDdBRXFro/jZrkrNj55hEiAmrEkg5P0VH2IHkx0RaeMVQVLUxl0IbsGEcWL1NGEvsv1ZsokBEKwm+BYccOM5Dtgfa+Zs/A4eg5Jw/1tw2I+407xAfc2aFKCyix5jHVQRFY1jGk80= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rVTHgLvd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rVTHgLvd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2B76C116D0; Sat, 28 Feb 2026 17:45:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300739; bh=behYP//EBJQWzRhmcJ7IjtX8DC9jh8obcpcJyQBZJUQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rVTHgLvdumq52EqIBjmsOZTZhPMB/k99dQH+ytbtdq0U6j1X/YojftFmkkQPSfATg kzyWgx6NLRIpJuocq9t41TJsJwF7jArjs+tJ8zQg7LlUs44ScrfDyVw1iHwxKc7Cz8 BEOrbchdzVYoeS4RNitokxZa3tJxx3jMtpzs6Gh47vtiWo3ZcJFM2822tqazVo+Vt+ V/VzxP70sh9fjtHkw4tn5VfkDr+jq0CjnROx8Y3O2yNOXifmYKrX9jgioUvIlobVlT BwGKLqDeeIYPqYaDv1hnfBZov5yWk+BdTEU0KmLTdLyyGQFkmvqQx5ceA8BWrUOUY8 KkBNwk3nXr3qQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tiezhu Yang , Huacai Chen , Sasha Levin Subject: [PATCH 6.19 774/844] LoongArch: Handle percpu handler address for ORC unwinder Date: Sat, 28 Feb 2026 12:31:27 -0500 Message-ID: <20260228173244.1509663-775-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tiezhu Yang [ Upstream commit 055c7e75190e0be43037bd663a3f6aced194416e ] After commit 4cd641a79e69 ("LoongArch: Remove unnecessary checks for ORC unwinder"), the system can not boot normally under some configs (such as enable KASAN), there are many error messages "cannot find unwind pc". The kernel boots normally with the defconfig, so no problem found out at the first time. Here is one way to reproduce: cd linux make mrproper defconfig -j"$(nproc)" scripts/config -e KASAN make olddefconfig all -j"$(nproc)" sudo make modules_install sudo make install sudo reboot The address that can not unwind is not a valid kernel address which is between "pcpu_handlers[cpu]" and "pcpu_handlers[cpu] + vec_sz" due to the code of eentry was copied to the new area of pcpu_handlers[cpu] in setup_tlb_handler(), handle this special case to get the valid address to unwind normally. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/loongarch/include/asm/setup.h | 3 +++ arch/loongarch/kernel/unwind_orc.c | 16 ++++++++++++++++ 2 files changed, 19 insertions(+) diff --git a/arch/loongarch/include/asm/setup.h b/arch/loongarch/include/as= m/setup.h index 3c2fb16b11b64..f81375e5e89c0 100644 --- a/arch/loongarch/include/asm/setup.h +++ b/arch/loongarch/include/asm/setup.h @@ -7,6 +7,7 @@ #define _LOONGARCH_SETUP_H =20 #include +#include #include #include =20 @@ -14,6 +15,8 @@ =20 extern unsigned long eentry; extern unsigned long tlbrentry; +extern unsigned long pcpu_handlers[NR_CPUS]; +extern long exception_handlers[VECSIZE * 128 / sizeof(long)]; extern char init_command_line[COMMAND_LINE_SIZE]; extern void tlb_init(int cpu); extern void cpu_cache_init(void); diff --git a/arch/loongarch/kernel/unwind_orc.c b/arch/loongarch/kernel/unw= ind_orc.c index d6b3688a1ce97..11ba3e4ac9eee 100644 --- a/arch/loongarch/kernel/unwind_orc.c +++ b/arch/loongarch/kernel/unwind_orc.c @@ -352,6 +352,22 @@ static inline unsigned long bt_address(unsigned long r= a) { extern unsigned long eentry; =20 +#if defined(CONFIG_NUMA) && !defined(CONFIG_PREEMPT_RT) + int cpu; + int vec_sz =3D sizeof(exception_handlers); + + for_each_possible_cpu(cpu) { + if (!pcpu_handlers[cpu]) + continue; + + if (ra >=3D pcpu_handlers[cpu] && + ra < pcpu_handlers[cpu] + vec_sz) { + ra =3D ra + eentry - pcpu_handlers[cpu]; + break; + } + } +#endif + if (ra >=3D eentry && ra < eentry + EXCCODE_INT_END * VECSIZE) { unsigned long func; unsigned long type =3D (ra - eentry) / VECSIZE; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64EE741B8F6; Sat, 28 Feb 2026 17:45:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300740; cv=none; b=CsS7D2oCSx/zNqTQae591FyR+LrDxFwjrIHHxudZpRqT0TBbew5OgOTKtyr/fqWLDZFCS2UzUzhZCVQWNHm6LYqN50T3i0w8YfFfqtRb3DwMa2TKWONozS6i7vwpQnsOmnCQ2lkrlvR2whKOmRwhE4PTMg5qd+3aWwvd5qdlpHs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300740; c=relaxed/simple; bh=9L1oZcuaQriepnx5tlDnK2zkiVRUhPcE3h+4TexLDM0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h/re/iahGN0Dif18Ju3pgLw4Iy8k3E4AcdznYzC8E+Vt62oCQI0tmvsMnuJc0AvyRmkZf9zOAlG525jzqq5jUeRiuvRVYYM0K2ccVMiF+MQsmTIgRggC6Nwrf9XyMFxE/qkvRLTmu+v+JSXwjeparJ5+68TV/czuANDcMTQcK3o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=thGywmJz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="thGywmJz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF4C4C2BC87; Sat, 28 Feb 2026 17:45:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300740; bh=9L1oZcuaQriepnx5tlDnK2zkiVRUhPcE3h+4TexLDM0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=thGywmJzcYdpFTmGkEMUwX1xhWr2Hk9QKeQCM4qnslngNr/U7M3EKASSmHys/FkS0 0clQEfM6aIY6iulRwODVoU7ft2ro5HFQlWlaZRV0SqoiAc0ZMaUyG9wYkLT7RCOsts jHChNfhDL9KI27jURFogjkZTfLVWnAGrxQTsvfMKlu1WiCJicl1RRPtmZ2ODR2iv7S RMfUOa94UTHfYEEwJ79yCYKs+l2S/2OckkITK0Pu/FoIYe0nirOSZATbvNtsPWp8vv Z/yqjmvQvG6bVeg59RvPxbzbHsR//Hpv4u3PJhgRZbD2R2+UEg03tzjj28tvt7EIt5 /S0N1yFU1Awyg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tiezhu Yang , Huacai Chen , Sasha Levin Subject: [PATCH 6.19 775/844] LoongArch: Guard percpu handler under !CONFIG_PREEMPT_RT Date: Sat, 28 Feb 2026 12:31:28 -0500 Message-ID: <20260228173244.1509663-776-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tiezhu Yang [ Upstream commit 70b0faae3590c628a98a627a10e5d211310169d4 ] After commit 88fd2b70120d ("LoongArch: Fix sleeping in atomic context for PREEMPT_RT"), it should guard percpu handler under !CONFIG_PREEMPT_RT to avoid redundant operations. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/loongarch/kernel/unwind_prologue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/loongarch/kernel/unwind_prologue.c b/arch/loongarch/kerne= l/unwind_prologue.c index 729e775bd40dd..ee1c29686ab05 100644 --- a/arch/loongarch/kernel/unwind_prologue.c +++ b/arch/loongarch/kernel/unwind_prologue.c @@ -65,7 +65,7 @@ static inline bool scan_handlers(unsigned long entry_offs= et) =20 static inline bool fix_exception(unsigned long pc) { -#ifdef CONFIG_NUMA +#if defined(CONFIG_NUMA) && !defined(CONFIG_PREEMPT_RT) int cpu; =20 for_each_possible_cpu(cpu) { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6817241B918; Sat, 28 Feb 2026 17:45:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300741; cv=none; b=bsf5tETdw+yPmOuWX5epiGS4M0vHD/pqZiA4JllUKLF1Dazn4O5soLDobUheqT204eofSkPug3qUmwtF64a7m+geWOr8VQolwE4zvx68R7feBLZ+hsxPydX10dFAjResYUvzK91/luaUqQWa25jGI1I00i5nwLvzjYals9Yt7do= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300741; c=relaxed/simple; bh=/nD649T2xEp+kK4gCXKPYPLpFpSVvdLGdcEntA0McGI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hqWWYk19i8hJhvn9kOAP+JFZzbHDTaIgTY4dleam3LfdLCWUPNoraJBJQbWNMMKRveeO7D/KHUuLZ3Tb+ju0YKFv/4OLZaHvHecX/3QeFAVFEbn1NaCi1c3vReZdVVxXhUbmDbFdsyqubMmLTYbJfnm6QAWX/83bbNADalrk0Pc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FHMgNLSc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FHMgNLSc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BF6CC2BC9E; Sat, 28 Feb 2026 17:45:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300741; bh=/nD649T2xEp+kK4gCXKPYPLpFpSVvdLGdcEntA0McGI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FHMgNLSc+E7FCf2AQf9FJ6Tz+bdJlxRrLU7bdgAn7EnVmMIorxUgKReYSg/r6rWy5 mbClFUpq3v3GvFy05wgq0YDn3iK9qh7+PeWkN8k+kg+adBqoFE0uT7zDIPSX5vfuJv gv2sXTO+hQ0q/MP1pXJ/9jqrsbZSk//pyiqptf7R4KksFvtPplqDH3MTrOv8ODSlLl aeLotYRxmAjUgOiZTiO9brChOOS9Rg2GxTHjrvkETMwkBNXJWERMKLCvC4S5ORqMKZ EK/58PIMeV6+MU1/e6QEiUihOeaUHE2VDcRA+YO3a2ohmvQPEQ3r/cijUwTYPkbs4S tEMBrVjAsOY+Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tiezhu Yang , Huacai Chen , Sasha Levin Subject: [PATCH 6.19 776/844] LoongArch: Remove some extern variables in source files Date: Sat, 28 Feb 2026 12:31:29 -0500 Message-ID: <20260228173244.1509663-777-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tiezhu Yang [ Upstream commit 0e6f596d6ac635e80bb265d587b2287ef8fa1cd6 ] There are declarations of the variable "eentry", "pcpu_handlers[]" and "exception_handlers[]" in asm/setup.h, the source files already include this header file directly or indirectly, so no need to declare them in the source files, just remove the code. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/loongarch/kernel/unwind_orc.c | 2 -- arch/loongarch/kernel/unwind_prologue.c | 4 ---- arch/loongarch/mm/tlb.c | 1 - 3 files changed, 7 deletions(-) diff --git a/arch/loongarch/kernel/unwind_orc.c b/arch/loongarch/kernel/unw= ind_orc.c index 11ba3e4ac9eee..9cfb5bb1991f2 100644 --- a/arch/loongarch/kernel/unwind_orc.c +++ b/arch/loongarch/kernel/unwind_orc.c @@ -350,8 +350,6 @@ EXPORT_SYMBOL_GPL(unwind_start); =20 static inline unsigned long bt_address(unsigned long ra) { - extern unsigned long eentry; - #if defined(CONFIG_NUMA) && !defined(CONFIG_PREEMPT_RT) int cpu; int vec_sz =3D sizeof(exception_handlers); diff --git a/arch/loongarch/kernel/unwind_prologue.c b/arch/loongarch/kerne= l/unwind_prologue.c index ee1c29686ab05..da07acad7973a 100644 --- a/arch/loongarch/kernel/unwind_prologue.c +++ b/arch/loongarch/kernel/unwind_prologue.c @@ -23,10 +23,6 @@ extern const int unwind_hint_lasx; extern const int unwind_hint_lbt; extern const int unwind_hint_ri; extern const int unwind_hint_watch; -extern unsigned long eentry; -#ifdef CONFIG_NUMA -extern unsigned long pcpu_handlers[NR_CPUS]; -#endif =20 static inline bool scan_handlers(unsigned long entry_offset) { diff --git a/arch/loongarch/mm/tlb.c b/arch/loongarch/mm/tlb.c index 6a3c91b9cacdc..4014c44695878 100644 --- a/arch/loongarch/mm/tlb.c +++ b/arch/loongarch/mm/tlb.c @@ -262,7 +262,6 @@ static void output_pgtable_bits_defines(void) #ifdef CONFIG_NUMA unsigned long pcpu_handlers[NR_CPUS]; #endif -extern long exception_handlers[VECSIZE * 128 / sizeof(long)]; =20 static void setup_tlb_handler(int cpu) { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D78441C0A4; Sat, 28 Feb 2026 17:45:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300742; cv=none; b=imb2gVwcju5cgLxpCAkzizvfsgbT7AGoP1tH3bcCyGTZG4wbL7TFdHvWJAvuA4daa8OAtMC+wAZF5mmQh+NnKVt5LJTOlEbRQ/+DpbB6X1JW3Jy3daVg+N0QhPMxNp72Nebnu5f/hdQnheuljQBYqXgIIFUK47VwZjhhstFX94c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300742; c=relaxed/simple; bh=afb7B18bbscKce6/uYHwcOSkVej6oPy+5SftlNgAz68=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=a9c1oOl2hB8wKqJAuifDT6H26hSfod29dfgCh4Y6oPDSZWoHRulM+r+gtdBAY5sRvZi9DD69DHDyrTEQVGQrl2NIJR/h/5QtIxMtj/dEMicUHQpR10VECz1l81yXM1xBW3hAU4rmtL+xHudmOWRt6HaldwKaGYYIyhHluk64rD4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vDSBRxF8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vDSBRxF8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A6DAC19423; Sat, 28 Feb 2026 17:45:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300742; bh=afb7B18bbscKce6/uYHwcOSkVej6oPy+5SftlNgAz68=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vDSBRxF8p0O9spFcbYWP081FTCAdErzyZ22+t/2W21gYWM+ieHHrZx+KR4RTp0X10 14wqfNAQ9RL/7eIM+VcOTvms7epTeI7K2xVU+vIuE3RiZfX0TZIpinwLUY5I04K4Xx VPjUpohqvx5G8frGXdMU8BFaV4cDvxQeE2oX4SCWkUH8s7st1hVn4Za0Z33rFGFp8d lB80kwKCl2VVb8UfynvhnG0Wg2keu2eJsJk19zb/21gkqaQU3PhCPXB2RV2vaoh7at PJsH8F6TqYjntiN1gA86/J1nKPvcY7jwCUHjc9rZPhoMN2kuxGfV0DneMhzWG2yKF0 MJPaztEJCZBnw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tiezhu Yang , Huacai Chen , Sasha Levin Subject: [PATCH 6.19 777/844] LoongArch: Disable instrumentation for setup_ptwalker() Date: Sat, 28 Feb 2026 12:31:30 -0500 Message-ID: <20260228173244.1509663-778-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tiezhu Yang [ Upstream commit 7cb37af61f09c9cfd90c43c9275307c16320cbf2 ] According to Documentation/dev-tools/kasan.rst, software KASAN modes use compiler instrumentation to insert validity checks. Such instrumentation might be incompatible with some parts of the kernel, and therefore needs to be disabled, just use the attribute __no_sanitize_address to disable instrumentation for the low level function setup_ptwalker(). Otherwise bringing up the secondary CPUs failed when CONFIG_KASAN is set (especially when PTW is enabled), here are the call chains: smpboot_entry() start_secondary() cpu_probe() per_cpu_trap_init() tlb_init() setup_tlb_handler() setup_ptwalker() The reason is the PGD registers are configured in setup_ptwalker(), but KASAN instrumentation may cause TLB exceptions before that. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/loongarch/mm/tlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/loongarch/mm/tlb.c b/arch/loongarch/mm/tlb.c index 4014c44695878..aaf7d685cc2aa 100644 --- a/arch/loongarch/mm/tlb.c +++ b/arch/loongarch/mm/tlb.c @@ -202,7 +202,7 @@ void __update_tlb(struct vm_area_struct *vma, unsigned = long address, pte_t *ptep local_irq_restore(flags); } =20 -static void setup_ptwalker(void) +static void __no_sanitize_address setup_ptwalker(void) { unsigned long pwctl0, pwctl1; unsigned long pgd_i =3D 0, pgd_w =3D 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2DC4041C0C7; Sat, 28 Feb 2026 17:45:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300743; cv=none; b=K7OgI4P+g9BejradEObPsfF1gkEFN2Lv0JQ43QKPFHeaSKcnclbLdj1WpEFN5qQB9d+3ZWZoF8LANOFARia8heJ+OZz1YtkyYOWxNAumuxRvDnzrBt5YhTgA6dEc9BoPX81lRHDzOU8oIn84ZdM6eBzmMEOoh+RqBXwShKf4HPw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300743; c=relaxed/simple; bh=n11fJxM1zdO1l3kKSRQWSOUtzlFHtSJ7rvoF1B0cTWg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nvXRzNEOcRGM8ppEvGntqHfCOa/mccXwBy9mf/5rwMmwQeJJxXRS5zMoOdXQEFo6gqzF6YStZDnfcOgvcxTUDo7GYOQhpNoZLD1woI2U08b8G4IoVsI5m+vQH59m4Dwx12IMCPl/KK8+hEJ0SX2Fvy6WHIj+zrAXnG2R7Zga+ic= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EGS12iWP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EGS12iWP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44436C19425; Sat, 28 Feb 2026 17:45:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300742; bh=n11fJxM1zdO1l3kKSRQWSOUtzlFHtSJ7rvoF1B0cTWg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EGS12iWPZBDodMMzxUB+8NvbgQ6tndvghG//NAMI9OgPffyF0v6utyNThqscPwA5h zJL2s2XzYo7gdTb95miBNQ8K4KyTHOa/PPnKbF3wAgcipQaaniN3fU5hdUflvHsneU qRXlrVKfbtaNQhTWVW4AOvehYxO8HSKaY7cIZvsdotvqDQbzkp30EYCiVHi0xE5YvM sh+ixkkB+1l1/2wkOe5gQKnU3mOkCYVEUyuqmQARGPifl0g2zN5I5CDKWIb1ukd0H+ koEP0Wqzc2LBoPnmZVNdBH7g39l7t88zmnMCS0BQ6cRVe+T0BXlWVfSVKTHfoUG8Pc ezyNiOpgM3WTw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Nelson-Moore , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 778/844] net: ethernet: marvell: skge: remove incorrect conflicting PCI ID Date: Sat, 28 Feb 2026 12:31:31 -0500 Message-ID: <20260228173244.1509663-779-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Nelson-Moore [ Upstream commit d01103fdcb871fd83fd06ef5803d576507c6a801 ] The ID 1186:4302 is matched by both r8169 and skge. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. I downloaded the latest drivers for all hardware revisions of the D-Link DGE-530T from D-Link's website, and the only drivers which contain this ID are Realtek drivers. Therefore, remove this device ID from skge. In the kernel bug report which requested addition of this device ID, someone created a patch to add the ID to skge. Then, it was pointed out that this device is an "r8169 in disguise", and a patch was created to add it to r8169. Somehow, both of these patches got merged. See the link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D38862 Fixes: c074304c2bcf ("add pci-id for DGE-530T") Cc: stable@vger.kernel.org Signed-off-by: Ethan Nelson-Moore Link: https://patch.msgid.link/20260206071724.15268-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/marvell/skge.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/mar= vell/skge.c index 05349a0b2db1c..cf4e26d337bb5 100644 --- a/drivers/net/ethernet/marvell/skge.c +++ b/drivers/net/ethernet/marvell/skge.c @@ -78,7 +78,6 @@ static const struct pci_device_id skge_id_table[] =3D { { PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, 0x4320) }, /* SK-98xx V2.0 */ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4b01) }, /* D-Link DGE-530T (rev.B)= */ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4c00) }, /* D-Link DGE-530T */ - { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4302) }, /* D-Link DGE-530T Rev C1 = */ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4320) }, /* Marvell Yukon 88E8001= /8003/8010 */ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x5005) }, /* Belkin */ { PCI_DEVICE(PCI_VENDOR_ID_CNET, 0x434E) }, /* CNet PowerG-2000 */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA3F141B906; Sat, 28 Feb 2026 17:45:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300743; cv=none; b=SiZ1hgJr2JGhTZ2eOfU2r5YrwD5gDQprhIjnYc9twSUbcwl2KC42CkgAjWSgYZs6sXuplVG3iANKEgKVd0y4QMca01DcEF+NYJFxhmV1lWBUiED8MHi/lpF4R15wMeYU3sO/6Zr1GnScB2Zvw5H1X6hN3MN0TheHCJ26GjO6m7I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300743; c=relaxed/simple; bh=sVKXGti/1tHXqLvuJLqu4mRGLNaVilAoFO9v0XPvu+g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rcPD20DjLoIZtuElIttM6VWOtGCjj6oZ0MCNu6KxlYGzUg+65wTlzf1fqHqDHlvG/N7N/8A8mkZwIw5iSDKsuWkWECMN9l27hXn7gJKMN/mnjG9+ULBzQrFMGx4IxEdRYMw+cTjKJTF12HlI66XSdUg64UQkjXyamWtqFctaEDA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MQQFH9ze; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MQQFH9ze" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C4C9C116D0; Sat, 28 Feb 2026 17:45:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300743; bh=sVKXGti/1tHXqLvuJLqu4mRGLNaVilAoFO9v0XPvu+g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MQQFH9zesT6m37rbf7UWrwDzK8xtlyrIHR/EFRD2o/BsDO8gV0W48mddERrY/7uDT nsgNA8TJAzffcUtSrseyEZzXqLpati7cONguNfFqGY0Qvig12AEqyd2QBt0wFEs3mE c6iRPch3hfKKw7xVNUoUsD/tr5276ezSxE+Q/0mnjUt+dPEoMODArAS8Wb37CBdpig auEQnHnOfBJoDTmEoXVJtN1t7dCTJiVkWGQD885r7lxoQH3wkjfdtyX1cuhVDmQ0Nb qj8o2TUSslTVqqU8fLbFTW1JjGzjnKEItk7RsP0fBK8LLBmnhEqD8e1x0f91/PITCv nf5B+kja6krGg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Fourier , "Christophe Leroy (CS GROUP)" , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 779/844] net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() Date: Sat, 28 Feb 2026 12:31:32 -0500 Message-ID: <20260228173244.1509663-780-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Fourier [ Upstream commit 36bd7d5deef936c4e1e3cd341598140e5c14c1d3 ] The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer. Reviewed-by: Christophe Leroy (CS GROUP) Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC") Cc: Signed-off-by: Thomas Fourier Link: https://patch.msgid.link/20260206085334.21195-2-fourier.thomas@gmail.= com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/wan/fsl_ucc_hdlc.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c index f999798a56127..dff84731343cc 100644 --- a/drivers/net/wan/fsl_ucc_hdlc.c +++ b/drivers/net/wan/fsl_ucc_hdlc.c @@ -790,18 +790,14 @@ static void uhdlc_memclean(struct ucc_hdlc_private *p= riv) =20 if (priv->rx_buffer) { dma_free_coherent(priv->dev, - RX_BD_RING_LEN * MAX_RX_BUF_LENGTH, + (RX_BD_RING_LEN + TX_BD_RING_LEN) * MAX_RX_BUF_LENGTH, priv->rx_buffer, priv->dma_rx_addr); priv->rx_buffer =3D NULL; priv->dma_rx_addr =3D 0; - } =20 - if (priv->tx_buffer) { - dma_free_coherent(priv->dev, - TX_BD_RING_LEN * MAX_RX_BUF_LENGTH, - priv->tx_buffer, priv->dma_tx_addr); priv->tx_buffer =3D NULL; priv->dma_tx_addr =3D 0; + } } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E117941CCBD; Sat, 28 Feb 2026 17:45:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300745; cv=none; b=ARdUGsq0xLabx13XkNQl1epakVvDGNRcgY3lH897M2nTZNqkm/TcjDRPNj1A3vt1tfTeIGz/07k+gowQVm1NLlwr/JYnCAM+xEYoyeDq/zqO4A0sv/rHq1RI2qy8KPO1q/5ZmwWZf7mFpsqQQ8IwXENvZ9xV5OujUHHDL5gSeq0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300745; c=relaxed/simple; bh=ydw5SlpCZHeg3BEfdP/Kvqsx3VerIoR5MIjioJQKz+0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=g1VPW1cfXmF9hVJpl+ZN57ysB1mJ0sh21YowAK0gDELaYlU2QhJaXMAU4LvbnTYWRDTBEds63GKTDeT+8kZJhyEsRV6yirsDkk7v0h2elNAQLUgAQE9ikPwBx5sBgWXargEm3u62PpBak4Z58vk6ueUrZlVt/M79f3EgAOiOYMQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=u/KIJp6N; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="u/KIJp6N" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D92FC116D0; Sat, 28 Feb 2026 17:45:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300744; bh=ydw5SlpCZHeg3BEfdP/Kvqsx3VerIoR5MIjioJQKz+0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=u/KIJp6NlwPZUutKJyZN0s7swy4F3Wh/DDQg/TyOjG+Px2aJyb9AC/9OulOMmd8b5 3YRRFAyjSppLGz2dSRja5dt5b9YYyifoNHCJitGRnp+lQC72RrZlouXNPpNBqGpBk9 gNga9mqzqnAyfPzEOXdqtzhUNWHSK5/9PuyqoIAmME0JSmLFzIb80qc5ulLy1nrJmR S8rUPzxr4ompIt/Dj1DgA5KCa2EGHLdTdaP2IKmsFlcystGX79arP8hiKBvfrvBn09 EG2xNm3o6kK3LdQYepuYsArymgdgIFFYV4d0gtyLetF6iAXEU/FYBHkBz/PoPDa10n dVLL29GumH/0w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bo Sun , Vadim Fedorenko , Jijie Shao , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 780/844] octeontx2-af: CGX: fix bitmap leaks Date: Sat, 28 Feb 2026 12:31:33 -0500 Message-ID: <20260228173244.1509663-781-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bo Sun [ Upstream commit 3def995c4ede842adf509c410e92d09a0cedc965 ] The RX/TX flow-control bitmaps (rx_fc_pfvf_bmap and tx_fc_pfvf_bmap) are allocated by cgx_lmac_init() but never freed in cgx_lmac_exit(). Unbinding and rebinding the driver therefore triggers kmemleak: unreferenced object (size 16): backtrace: rvu_alloc_bitmap cgx_probe Free both bitmaps during teardown. Fixes: e740003874ed ("octeontx2-af: Flow control resource management") Cc: stable@vger.kernel.org Signed-off-by: Bo Sun Reviewed-by: Vadim Fedorenko Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20260206130925.1087588-2-bo@mboxify.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/marvell/octeontx2/af/cgx.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c b/drivers/net/= ethernet/marvell/octeontx2/af/cgx.c index 42044cd810b1f..fd4792e432bf0 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c @@ -1823,6 +1823,8 @@ static int cgx_lmac_exit(struct cgx *cgx) cgx->mac_ops->mac_pause_frm_config(cgx, lmac->lmac_id, false); cgx_configure_interrupt(cgx, lmac, lmac->lmac_id, true); kfree(lmac->mac_to_index_bmap.bmap); + rvu_free_bitmap(&lmac->rx_fc_pfvf_bmap); + rvu_free_bitmap(&lmac->tx_fc_pfvf_bmap); kfree(lmac->name); kfree(lmac); } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF10741CCDA; Sat, 28 Feb 2026 17:45:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300745; cv=none; b=vBc8T7MmTxreO5c9TVAGIwERzbXAwyopwtcXUcOA8OTMrn59nH/3TkJDF0vaBy8JB3Q6UqHWGG/IbcOoqdYJCy5GoSmHROyHWqqFOviUbUCL1fc1eWQGsX84VLTcCvBrUjc+WMRpDM6m8/5LsKE6JovDtVhpoYx/8s/dJBOvW9o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300745; c=relaxed/simple; bh=PAoL5jEsBEqiO4796cl0CDVmSwXkHDjdmnPBtrD0VOc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L7FTKzWY4m0duIL3oP/e5bfmwdux3AMLxCyZ1I030p7xsB6Q/ATFvS2SRzSnJzfXLi3XWJ4rVhC5TCgZ6SRVJNaog0+xJhnQ+ugmq2oXuMnP1U/Pp6Ru2JO7V5OF/66NmnXuybnm/UVCuuFgrmp7aIKwNU8yew89gtkD7UfCyGg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hmLLbXh3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hmLLbXh3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13BC6C116D0; Sat, 28 Feb 2026 17:45:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300745; bh=PAoL5jEsBEqiO4796cl0CDVmSwXkHDjdmnPBtrD0VOc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hmLLbXh3Oy/8NA+cGRYoxdmWN/xZHk5fLCAs5nhoWEDjDWc7xwNokJsOtSiGPQQfP JrjHVcRvkx7cfj7w9uI8v/ui0wqUtJCPCWC+8up6txcNcKBtJVMG+lDDihxXOvx61b XNMoFBhRywL08LWyFRzQB95IS3r6YqcKxiYV4vBiR6Vw/NQLKT43zoW8aUBmNeV4Lt qGrH8VhKTVUpKUXbDnUl60+4SAlneYa6sju+PxV3EVIJBD+klouroPy2xTyY6ADfqT Aq7suY3oyUf57ovw7BLKlRdPaqaHn0dzGpgMFGV8IOym59BWHKV9fUab4DHQ7Qlu3M kp/x5NO5hFDPA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kevin Hao , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 781/844] net: ti: icssg-prueth: Add optional dependency on HSR Date: Sat, 28 Feb 2026 12:31:34 -0500 Message-ID: <20260228173244.1509663-782-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kevin Hao [ Upstream commit e3998b6e90f875f19bf758053d79ccfd41880173 ] Commit 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame forward offload") introduced support for offloading HSR frame forwarding, which relies on functions such as is_hsr_master() provided by the HSR module. Although HSR provides stubs for configurations with HSR disabled, this driver still requires an optional dependency on HSR. Otherwise, build failures will occur when icssg-prueth is built-in while HSR is configured as a module. ld.lld: error: undefined symbol: is_hsr_master >>> referenced by icssg_prueth.c:710 (drivers/net/ethernet/ti/icssg/icssg= _prueth.c:710) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_pru= eth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:681 (drivers/net/ethernet/ti/icssg/icssg= _prueth.c:681) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_pru= eth_hsr_add_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:1812 (drivers/net/ethernet/ti/icssg/icss= g_prueth.c:1812) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(prueth_ne= tdevice_event) in archive vmlinux.a ld.lld: error: undefined symbol: hsr_get_port_ndev >>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg= _prueth.c:712) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_pru= eth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg= _prueth.c:712) >>> drivers/net/etherneteth_hsr_del_mcast) in archive vmlin= ux.a >>> referenced by icssg_prueth.c:683 (drivers/net/ethernet/ti/icssg/icssg= _prueth.c:683) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_pru= eth_hsr_add_mcast) in archive vmlinux.a >>> referenced 1 more times Fixes: 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame forw= ard offload") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260207-icssg-dep-v3-1-8c47c1937f81@gmail.c= om Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/ti/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kcon= fig index fe5b2926d8ab0..c60b04921c62c 100644 --- a/drivers/net/ethernet/ti/Kconfig +++ b/drivers/net/ethernet/ti/Kconfig @@ -192,6 +192,7 @@ config TI_ICSSG_PRUETH depends on NET_SWITCHDEV depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER depends on PTP_1588_CLOCK_OPTIONAL + depends on HSR || !HSR help Support dual Gigabit Ethernet ports over the ICSSG PRU Subsystem. This subsystem is available starting with the AM65 platform. --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C8E641D4C8; Sat, 28 Feb 2026 17:45:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300746; cv=none; b=GrE53bQbbV+b9SoWueTh7q75DbiWnw+Ng/WHXPwFm9/eff/c4JnkbpY+Ln8ckMUaiVPBS/tenymYRc/58avslQGWNe3cL9s0WCaAeXNAKvfuBacNmuELvzqMVKi0R1L6f2MLDDgkGgfRa4WrkMSPEWRyR6W+J32XTby3e5pMgfQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300746; c=relaxed/simple; bh=EtLEKl541sDBEHiRI8iutlpHkytahuMT2YOz0dIiePQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kBtrQsvDySRnyupIgY5lkEHeYggQJ619AX/M26L2uLbHlND2bv6qJKj0fkb81i4/UBzJfDUvftcq6Wosa4/7Xcme3aUAi/N7kx1VyMBCa/uq0vOPHH03p9vyuR9xcyFgjZFfWwpyqcZ7NY+zk7y8nABsqR20y5VV+PQivyc3wog= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lHZP1cFG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lHZP1cFG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E696CC19423; Sat, 28 Feb 2026 17:45:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300746; bh=EtLEKl541sDBEHiRI8iutlpHkytahuMT2YOz0dIiePQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lHZP1cFGjiA2auQfLPGjZRAk/NmOkBkXWxC7okkHyWbJ3o/E29BcUK3LmVMt/ow6Q TWoKqSMwSVRN3jKgrPrSEhjr/O/dKVYmMeSJgj6duXTIaV19/28ZnhIYLqJuV6xhX+ sf45sLwROhZWCjtnOwXHHcb1UxBvZmcsZ5irk7gwWlgwo1rZjOMMoQOMhpd+jvveJ5 IGmNNkijXJQ5nJAlYdr6zmW+nSgLEG8+G4WMEv0JB4w4tXr+mXwE9vMjUmfTv1usA0 pPpd6bzpglydT9rZqkNx00KGgcsaEM3noPxKXZEoOeRyzdoY8orxRAUjyL6ohwuf8D iFifVOtrLR+3A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kevin Hao , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 782/844] net: macb: Fix tx/rx malfunction after phy link down and up Date: Sat, 28 Feb 2026 12:31:35 -0500 Message-ID: <20260228173244.1509663-783-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kevin Hao [ Upstream commit bf9cf80cab81e39701861a42877a28295ade266f ] In commit 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()"), the mog_init_rings() callback was moved from macb_mac_link_up() to macb_open() to resolve a deadlock issue. However, this change introduced a tx/rx malfunction following phy link down and up events. The issue arises from a mismatch between the software queue->tx_head, queue->tx_tail, queue->rx_prepared_head, and queue->rx_tail values and the hardware's internal tx/rx queue pointers. According to the Zynq UltraScale TRM [1], when tx/rx is disabled, the internal tx queue pointer resets to the value in the tx queue base address register, while the internal rx queue pointer remains unchanged. The following is quoted from the Zynq UltraScale TRM: When transmit is disabled, with bit [3] of the network control register set low, the transmit-buffer queue pointer resets to point to the address indicated by the transmit-buffer queue base address register. Disabling receive does not have the same effect on the receive-buffer queue pointer. Additionally, there is no need to reset the RBQP and TBQP registers in a phy event callback. Therefore, move macb_init_buffers() to macb_open(). In a phy link up event, the only required action is to reset the tx software head and tail pointers to align with the hardware's behavior. [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm Fixes: 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from ma= cb_mac_link_up() to macb_open()") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260208-macb-init-ring-v1-1-939a32c14635@gm= ail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/cadence/macb_main.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/etherne= t/cadence/macb_main.c index 6511ecd5856bd..4ebb40adfab37 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -705,14 +705,12 @@ static void macb_mac_link_up(struct phylink_config *c= onfig, if (rx_pause) ctrl |=3D MACB_BIT(PAE); =20 - /* Initialize rings & buffers as clearing MACB_BIT(TE) in link down - * cleared the pipeline and control registers. - */ - macb_init_buffers(bp); - - for (q =3D 0, queue =3D bp->queues; q < bp->num_queues; ++q, ++queue) + for (q =3D 0, queue =3D bp->queues; q < bp->num_queues; ++q, ++queue) { + queue->tx_head =3D 0; + queue->tx_tail =3D 0; queue_writel(queue, IER, bp->rx_intr_mask | MACB_TX_INT_FLAGS | MACB_BIT(HRESP)); + } } =20 macb_or_gem_writel(bp, NCFGR, ctrl); @@ -2954,6 +2952,7 @@ static int macb_open(struct net_device *dev) } =20 bp->macbgem_ops.mog_init_rings(bp); + macb_init_buffers(bp); =20 for (q =3D 0, queue =3D bp->queues; q < bp->num_queues; ++q, ++queue) { napi_enable(&queue->napi_rx); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AFD9241D4EA; Sat, 28 Feb 2026 17:45:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300747; cv=none; b=bFGdROXjtJQlnMEg9fOgGO6Pe8KvE3mkl8Sp8KPL7VMPrLqSeVBEyqIA12IFWLyJ1+ED7Nw8NeEUXMuX/tRQvRDZMWVlnX5iXrJwI40hTFDVW+7C92b7a2KzHM0jvFGSMKi7QUXB/HU/js7AVPuYZvuXzOYDQbiI3eLt+ZavtW4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300747; c=relaxed/simple; bh=uy1r3ahCTJ4rnv4BH6RukpYgDyvuCSnL7tli9AcvMuA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Vi9+BJs5q5MgQvONzj9E3gh6i4IROf4deTvZcQEp6SoLHvq1rwljHnJE8CdsSZ5m33Eml0BDHgmWRJV2PSUHaKlL5QHRAEmNtOeq10/H+H6xq4BsG4oMHWDQGZ+JqzBQs6CPm8EThVb+N/TwoeV811yktRBEa/fDHGnfBOHTKH0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rY/OGGxA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rY/OGGxA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3357C116D0; Sat, 28 Feb 2026 17:45:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300747; bh=uy1r3ahCTJ4rnv4BH6RukpYgDyvuCSnL7tli9AcvMuA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rY/OGGxAdzMGeTVsc0ousmVHOSJbTJFNEml7WHS4RHXvo7JLzehNXSz40afgEUUpv EprKTEv9BbPyhQl3oXQsBkQBfnPzGZOb3mggylojzmZBxmRRc3qwmqYh0dslnuxnxn GdRoUkjENOpNh6EJjL0J6IW3Ar372Y4e8Eu6jesud6y3jeMSoJ2iGfwncVChkvmrUp 1eA76l/plbYJlX0tZcz18ewIYzvlY9n/fqzCn1IJCE8oTQjhXyvLchj1XeSZq1RV75 poO1M98u5+1jIj2kfXalTipxXe3jvbQsXrLdNoEZg1gyVT6oDEDaOAWA0AhRoLqZUn i6CtEfmXqIjjQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Masami Hiramatsu (Google)" , Mathieu Desnoyers , "Steven Rostedt (Google)" , Sasha Levin Subject: [PATCH 6.19 783/844] tracing: Fix to set write permission to per-cpu buffer_size_kb Date: Sat, 28 Feb 2026 12:31:36 -0500 Message-ID: <20260228173244.1509663-784-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Masami Hiramatsu (Google)" [ Upstream commit f844282deed7481cf2f813933229261e27306551 ] Since the per-cpu buffer_size_kb file is writable for changing per-cpu ring buffer size, the file should have the write access permission. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Link: https://patch.msgid.link/177071301597.2293046.11683339475076917920.st= git@mhiramat.tok.corp.google.com Fixes: 21ccc9cd7211 ("tracing: Disable "other" permission bits in the trace= fs files") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/trace/trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 8bd4ec08fb361..8e9c1bfe3ebb3 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -9398,7 +9398,7 @@ tracing_init_tracefs_percpu(struct trace_array *tr, l= ong cpu) trace_create_cpu_file("stats", TRACE_MODE_READ, d_cpu, tr, cpu, &tracing_stats_fops); =20 - trace_create_cpu_file("buffer_size_kb", TRACE_MODE_READ, d_cpu, + trace_create_cpu_file("buffer_size_kb", TRACE_MODE_WRITE, d_cpu, tr, cpu, &tracing_entries_fops); =20 if (tr->range_addr_start) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87A8541B918; Sat, 28 Feb 2026 17:45:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300748; cv=none; b=QuZF+qjvCJoIFxW03RrmDZzfn/1MQOacN7Jb+tQiLIGsGAPCUPG9SxNUjhGapYs90UoCtn3cLUn9awE026oiGBd1JkM4zeSUeMWasmsyS6Tzbt6lYHMMNe/umPMsuab/0wp1Vap5vgivAbJUZgdm95lCp9Apmsq42JsMRFrUmio= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300748; c=relaxed/simple; bh=IFBb7akjpT9xHxJvEkyOMo+fidVQgV9jRlm3pQG56bo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ESlBeIPNJ6aKlBCSl1YSv4A0O7FI04BjE2iRQHAfvB8Psi/0d1PhIfLBMTpEvvRB/mB2d3yWofZULaWVGagDmbrMiY3Aj+8rXDY1lgzOpREnZNejTC1d1ixG6HhP4Dhqk91f1z2OF5i5mG0DImy/TZwg/V4fabEzREBtQI7IHXg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CiCZXQvR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CiCZXQvR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2546C2BC87; Sat, 28 Feb 2026 17:45:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300748; bh=IFBb7akjpT9xHxJvEkyOMo+fidVQgV9jRlm3pQG56bo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CiCZXQvRn5ab9b3kOSsOXZPSHRB2YU7Lu5VekCDarOWZYoWUkWTXQxeNN2cfrRX9e aUNrSJh+9/0xFSSFd1pM5qF/TtuaBLEu0Y7RAvhgJz9eEMFCpLJk3/Vd2QSxDORxCG eaMqOStC9dO/Bk6BL0N9f6xqFDXK8p5CjFWK+dyGGNyXNLzlQUbCySSeK0Z48mO+ia ETVlZksihjuBcpbeI4y5SiFQs/AvL19dWDHpvRoUN/Y1G5VmURtWZuaz/jeXVnZQNj AaM217I7ENq253l2EGoS3BNM9qXwZSOgCUFjKRAKAwRrSA+pVcP0EZAElHS9cxPYGx kIW4PsNNOc9PQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Masami Hiramatsu (Google)" , Mathieu Desnoyers , "Steven Rostedt (Google)" , Sasha Levin Subject: [PATCH 6.19 784/844] tracing: Reset last_boot_info if ring buffer is reset Date: Sat, 28 Feb 2026 12:31:37 -0500 Message-ID: <20260228173244.1509663-785-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Masami Hiramatsu (Google)" [ Upstream commit 804c4a2209bcf6ed4c45386f033e4d0f7c5bfda5 ] Commit 32dc0042528d ("tracing: Reset last-boot buffers when reading out all cpu buffers") resets the last_boot_info when user read out all data via trace_pipe* files. But it is not reset when user resets the buffer from other files. (e.g. write `trace` file) Reset it when the corresponding ring buffer is reset too. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Link: https://patch.msgid.link/177071302364.2293046.17895165659153977720.st= git@mhiramat.tok.corp.google.com Fixes: 32dc0042528d ("tracing: Reset last-boot buffers when reading out all= cpu buffers") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/trace/trace.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 8e9c1bfe3ebb3..cc93d0e1f1876 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -4881,6 +4881,8 @@ static int tracing_single_release_tr(struct inode *in= ode, struct file *file) return single_release(inode, file); } =20 +static bool update_last_data_if_empty(struct trace_array *tr); + static int tracing_open(struct inode *inode, struct file *file) { struct trace_array *tr =3D inode->i_private; @@ -4905,6 +4907,8 @@ static int tracing_open(struct inode *inode, struct f= ile *file) tracing_reset_online_cpus(trace_buf); else tracing_reset_cpu(trace_buf, cpu); + + update_last_data_if_empty(tr); } =20 if (file->f_mode & FMODE_READ) { @@ -5971,6 +5975,7 @@ tracing_set_trace_read(struct file *filp, char __user= *ubuf, int tracer_init(struct tracer *t, struct trace_array *tr) { tracing_reset_online_cpus(&tr->array_buffer); + update_last_data_if_empty(tr); return t->init(tr); } =20 @@ -7789,6 +7794,7 @@ int tracing_set_clock(struct trace_array *tr, const c= har *clockstr) ring_buffer_set_clock(tr->max_buffer.buffer, trace_clocks[i].func); tracing_reset_online_cpus(&tr->max_buffer); #endif + update_last_data_if_empty(tr); =20 if (tr->scratch && !(tr->flags & TRACE_ARRAY_FL_LAST_BOOT)) { struct trace_scratch *tscratch =3D tr->scratch; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B60241DDD2; Sat, 28 Feb 2026 17:45:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300749; cv=none; b=pR0bOnBLUFLHxD4Z4EIFSa71O/VdMmg5DiDCIzFnkInaQEVEq/mQVGpUEJvm6eym3yfOZjVlZaEoQ+A9hHwmypDo4RpRAGKAkePz+k5WRV8VxJFzwcELSo4dOUw/S9DIdY6jwPx/8T40s1NVpFjPf2JiweO7g2bmLFSgAqwDwCM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300749; c=relaxed/simple; bh=JgNDxt1J+KIqE4bkKNZgfOq0qnpsrOurMpn2qfVfZXQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Gw1YBGfBe3O+GxdG+s3Z7epOANlPxxYjX2Wbt+eGyofxHXxSVo4wyTeHz1F8rg6o/opJhHj+rmA9z3TKMMKABtKRU8a5zoIRXFO2KrsOgydz4qdo/5x6k3eDzL1q2Xg2fQ0ku5EYwbHu2NYS56ScEDM4/vFs5FHirLNWwd5XJ4g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Bd/ItxcL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Bd/ItxcL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A543AC116D0; Sat, 28 Feb 2026 17:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300749; bh=JgNDxt1J+KIqE4bkKNZgfOq0qnpsrOurMpn2qfVfZXQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Bd/ItxcL013tjaCNMY68RxXItt4of43FPAZ2u9h5useHRk8hvvC1a2N/a+e8KmM2c E5qMY8FDKWgFvzsbEBc1xbTGF2gIMy63TSFeXurxu6gUAHE5t6Js4JCYOzcypPs0PB BOEfqt8UAvXO9ei2qpsvf0adDVTggFiFuO48AdyTgSczNm3Eyi0HfbxrnL5GWHYd4f XpM1x2JpD+5INIZ1ZptKspiZmLohU7Dy2BqJeZ0lz173DlXlEmcKDctKFAKDVPEaPk 0d+FBiagO71PDUKDCZjHym8Zfv5a6hpo2AX6Uo9uKSZeSzwdFVP3/Gn910oaJc+DV/ cS2ejWk3fGTFw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sam Edwards , Sam Edwards , Ilya Dryomov , Sasha Levin Subject: [PATCH 6.19 785/844] ceph: do not propagate page array emplacement errors as batch errors Date: Sat, 28 Feb 2026 12:31:38 -0500 Message-ID: <20260228173244.1509663-786-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sam Edwards [ Upstream commit 707104682e3c163f7c14cdd6b07a3e95fb374759 ] When fscrypt is enabled, move_dirty_folio_in_page_array() may fail because it needs to allocate bounce buffers to store the encrypted versions of each folio. Each folio beyond the first allocates its bounce buffer with GFP_NOWAIT. Failures are common (and expected) under this allocation mode; they should flush (not abort) the batch. However, ceph_process_folio_batch() uses the same `rc` variable for its own return code and for capturing the return codes of its routine calls; failing to reset `rc` back to 0 results in the error being propagated out to the main writeback loop, which cannot actually tolerate any errors here: once `ceph_wbc.pages` is allocated, it must be passed to ceph_submit_write() to be freed. If it survives until the next iteration (e.g. due to the goto being followed), ceph_allocate_page_array()'s BUG_ON() will oops the worker. Note that this failure mode is currently masked due to another bug (addressed next in this series) that prevents multiple encrypted folios from being selected for the same write. For now, just reset `rc` when redirtying the folio to prevent errors in move_dirty_folio_in_page_array() from propagating. Note that move_dirty_folio_in_page_array() is careful never to return errors on the first folio, so there is no need to check for that. After this change, ceph_process_folio_batch() no longer returns errors; its only remaining failure indicator is `locked_pages =3D=3D 0`, which the caller already handles correctly. Cc: stable@vger.kernel.org Fixes: ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") Signed-off-by: Sam Edwards Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ceph/addr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index faecd9025ee9c..3cfe3df6e6a22 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -1369,6 +1369,7 @@ int ceph_process_folio_batch(struct address_space *ma= pping, rc =3D move_dirty_folio_in_page_array(mapping, wbc, ceph_wbc, folio); if (rc) { + rc =3D 0; folio_redirty_for_writepage(wbc, folio); folio_unlock(folio); break; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EA8F41DDE9; Sat, 28 Feb 2026 17:45:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300750; cv=none; b=eI+XMKwXYexZmzyiRilx9/gQlmlQoF1Jodbz3gd8BR8Y8+9tR4DZYBxmt1fQRHHOvp2cvpv5A2OJ+TEPz3CwF3p2K/VXsUdCt2YdyzVF37e02Bdlbc0d2StUu77C5Pk0jYRlneGYmq7lv0Ov8PQMXxtZeRCr6zI08HPRel39I/w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300750; c=relaxed/simple; bh=1HhwZmIlQJ5cO9vDpfo4RUmluN7cuB9Xo3xbXrzw4ho=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BlGqY2VTE9LT/AEDyLX71mlDnH+okF4Nx2xfXOu4PtfpRdoKZ8WWCL8aZdOfau1fYTa+dYe7mRaResUQnzaflpsDUlx/yve1XWDK0qrwvMVbejhb7KEjdyVpTuukUhNzrEX0zOCoMDOdZCeHf+n8V2GFqCBrXZWSQ4b38ssbrSo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LqSOqbJc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LqSOqbJc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 982C4C19423; Sat, 28 Feb 2026 17:45:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300750; bh=1HhwZmIlQJ5cO9vDpfo4RUmluN7cuB9Xo3xbXrzw4ho=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LqSOqbJctE2dgMXGh9pkKHh6L25NFkp+1OxyLo3fYbVlmblbo/OMgyV1sCMhrFJn3 hdkpK3jjn1OfeuBl7r8EKNAHIAMlQZnPkqJfwkgbmGTKDBWAxlkXbOxuXXRJzX3atm QM/FSg20FwUtfleB7HZEZswZDwstqaNz1jzrF9pwtN7dn7eN/zaJ34W/qF0jwJ0TVa wV+C6kRiHpSj/07sMvHU1oJOd7qe7NpKlGicABSSdjDf6CfAn5wAVzS7+sbLWaYL9L K3HyN1BNWKIL7sjU3WxQMAmpAJ4cy55YpkIoltVi2+1cPR4yjOa3FW5DlFZc7vV5fs 014XSL8tJbvkw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sam Edwards , Sam Edwards , Ilya Dryomov , Sasha Levin Subject: [PATCH 6.19 786/844] ceph: fix write storm on fscrypted files Date: Sat, 28 Feb 2026 12:31:39 -0500 Message-ID: <20260228173244.1509663-787-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sam Edwards [ Upstream commit cac190c7674fea71620d754ffcdaaeed7c551dbc ] CephFS stores file data across multiple RADOS objects. An object is the atomic unit of storage, so the writeback code must clean only folios that belong to the same object with each OSD request. CephFS also supports RAID0-style striping of file contents: if enabled, each object stores multiple unbroken "stripe units" covering different portions of the file; if disabled, a "stripe unit" is simply the whole object. The stripe unit is (usually) reported as the inode's block size. Though the writeback logic could, in principle, lock all dirty folios belonging to the same object, its current design is to lock only a single stripe unit at a time. Ever since this code was first written, it has determined this size by checking the inode's block size. However, the relatively-new fscrypt support needed to reduce the block size for encrypted inodes to the crypto block size (see 'fixes' commit), which causes an unnecessarily high number of write operations (~1024x as many, with 4MiB objects) and correspondingly degraded performance. Fix this (and clarify intent) by using i_layout.stripe_unit directly in ceph_define_write_size() so that encrypted inodes are written back with the same number of operations as if they were unencrypted. This patch depends on the preceding commit ("ceph: do not propagate page array emplacement errors as batch errors") for correctness. While it applies cleanly on its own, applying it alone will introduce a regression. This dependency is only relevant for kernels where ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") has been applied; stable kernels without that commit are unaffected. Cc: stable@vger.kernel.org Fixes: 94af0470924c ("ceph: add some fscrypt guardrails") Signed-off-by: Sam Edwards Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/ceph/addr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index 3cfe3df6e6a22..c6c853748942b 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -1000,7 +1000,8 @@ unsigned int ceph_define_write_size(struct address_sp= ace *mapping) { struct inode *inode =3D mapping->host; struct ceph_fs_client *fsc =3D ceph_inode_to_fs_client(inode); - unsigned int wsize =3D i_blocksize(inode); + struct ceph_inode_info *ci =3D ceph_inode(inode); + unsigned int wsize =3D ci->i_layout.stripe_unit; =20 if (fsc->mount_options->wsize < wsize) wsize =3D fsc->mount_options->wsize; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7353D4963C7; Sat, 28 Feb 2026 17:45:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300751; cv=none; b=l4AbKKFzmEFIKFveF0EZUjT60yovCDi2gYvyOwVhIEtTCXUKGjhgl0LFh4dymssPESEs/uN225OWs+jUXDQcWxA8xqoaviCXKF41wszUryaBeoBXdpg9p45UUYaK5XerCYcReCvEzYdj4tGdVaRkRbYr3TAN85Jgw83F+FL7AUo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300751; c=relaxed/simple; bh=LNzFhU9XfZhjf8xxOub6ucNaRuUyk/B2S4O+7kveyFs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p4qFJTJkjP2GvE5njuA72UJU5zY1Tj3j6yOL0DnS1ihSsS4CudFqhaeOVRDNFp8ri2cFbvAWuwAkHoN2wubFzRzm9HaATPh9+LPrmpPIHrIPy0cvG67hTbBoNg/gQt/p7rQ34zsKqj3BbRCJNnG+96/eMhuKQxQFjyalNTNtaeQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Qyv7oFsi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Qyv7oFsi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BAE8C19424; Sat, 28 Feb 2026 17:45:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300751; bh=LNzFhU9XfZhjf8xxOub6ucNaRuUyk/B2S4O+7kveyFs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Qyv7oFsiZaoDhAbEBuEzf1ifhVT6UrptbGQT9O0KwqBD8eQUbJE1Ra4Sut1C7HuJz X3r5CqORQZoT+gghZe3JeET9akDQVKttxUoaxwAczJPIVqZgV0HvXKF7DcKypp1ML/ IMuoJEY38JSxHOdqXIYlct+Z8hGuYhMMj63lwlaL2TSdE0AaTJNypoD7YaxW7xdDeZ dm9Ya4peutWZoRHq+MCWIhwfxwWq9lZbxHcRn8n/wJWcOisEz5r5WdPhWMFd9CcmlQ aYzzKdlsIYj3xsm1nZ3BDATb6Kk4tqfObzhsEn82AUWn0b6JOTZBcx0PT35YIUfSOQ 3VhD0NoJdadAA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jens Axboe , Sasha Levin Subject: [PATCH 6.19 787/844] io_uring/filetable: clamp alloc_hint to the configured alloc range Date: Sat, 28 Feb 2026 12:31:40 -0500 Message-ID: <20260228173244.1509663-788-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jens Axboe [ Upstream commit a6bded921ed35f21b3f6bd8e629bf488499ca442 ] Explicit fixed file install/remove operations on slots outside the configured alloc range can corrupt alloc_hint via io_file_bitmap_set() and io_file_bitmap_clear(), which unconditionally update alloc_hint to the bit position. This causes subsequent auto-allocations to fall outside the configured range. For example, if the alloc range is [10, 20) and a file is removed at slot 2, alloc_hint gets set to 2. The next auto-alloc then starts searching from slot 2, potentially returning a slot below the range. Fix this by clamping alloc_hint to [file_alloc_start, file_alloc_end) at the top of io_file_bitmap_get() before starting the search. Cc: stable@vger.kernel.org Fixes: 6e73dffbb93c ("io_uring: let to set a range for file slot allocation= ") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/filetable.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/io_uring/filetable.c b/io_uring/filetable.c index 794ef95df293c..cb1838c9fc377 100644 --- a/io_uring/filetable.c +++ b/io_uring/filetable.c @@ -22,6 +22,10 @@ static int io_file_bitmap_get(struct io_ring_ctx *ctx) if (!table->bitmap) return -ENFILE; =20 + if (table->alloc_hint < ctx->file_alloc_start || + table->alloc_hint >=3D ctx->file_alloc_end) + table->alloc_hint =3D ctx->file_alloc_start; + do { ret =3D find_next_zero_bit(table->bitmap, nr, table->alloc_hint); if (ret !=3D nr) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E4A741E5BB; Sat, 28 Feb 2026 17:45:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300752; cv=none; b=Dx40WllK6FHbXKaPVDczQqGamN2TKuo0lvU0w/wune5cdAlMEwHiuqXKbUseFcHG4Dun9GvMx2OQi8XkC0CfB9darq6Aq70JbDLfCBD4eFwhKcNY6OGUGqoSwITZLEGIcnLuCsyOvYAU8pi3S8yDA45MNb/3gGRcN3bCE+mA6wE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300752; c=relaxed/simple; bh=b42WEZw7ILAb0uLleni0IDk7v/nd9K5I8bG6AzqTbbE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tfhngrl8KLi5gO/oJZZY3Ra7cF6/5qydhHSNmtPY9gX7AFJ6y+xY5v1FnrsQ17siXGSwlDYBW3r7DOqw4rE2O7YyJrHW3It1PpTOjGAphJn2QhWWEMc2awm9FuI19R7bt79y8leAAaXFrxa5rDDWsA2lATYDUAElwewzFFm/Vf0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=u2NiN0V3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="u2NiN0V3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C2C0C2BC87; Sat, 28 Feb 2026 17:45:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300751; bh=b42WEZw7ILAb0uLleni0IDk7v/nd9K5I8bG6AzqTbbE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=u2NiN0V3eVIrKuyjKEED3DhLyKhe+6uCC7H8UurWUaLh0ERSEDzha1sOYQE+S71Hl +hVR1siX01ImghCRwB3wjXHnWfRAfGbFOWpoLnhAyM2tPlPk/D5Xk6MhqnZwlElobv 9Sc4voXSYev1DJodKwtqccUEsC+JASk6e0eplfJHFhbi5KFbE/c+FJVLsabgNwxO7r DvO2sZo++ie4kvcwU6JasMczI98e7N5ZKbPJNkZ98hbaHXUmXGNr4J+jqRvUHp+fEN j+2wAe1vxdT/WQZIbzWHtDimu1Z/bQgz2HyaUT6iCzRHZ4ZSYYf6/L5rom2knkGH7n qCFFVXEp/IGyA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jens Axboe , Sasha Levin Subject: [PATCH 6.19 788/844] io_uring/openclose: fix io_pipe_fixed() slot tracking for specific slots Date: Sat, 28 Feb 2026 12:31:41 -0500 Message-ID: <20260228173244.1509663-789-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jens Axboe [ Upstream commit f4d0668b38d8784f33a9a36c72ed5d0078247538 ] __io_fixed_fd_install() returns 0 on success for non-alloc mode (specific slot), not the slot index. io_pipe_fixed() used this return value directly as the slot index in fds[], which can cause the reported values returned via copy_to_user() to be incorrect, or the error path operating on the incorrect direct descriptor. Fix by computing the actual 0-based slot index (slot - 1) for specific slot mode, while preserving the existing behavior for auto-alloc mode where __io_fixed_fd_install() already returns the allocated index. Cc: stable@vger.kernel.org Fixes: 53db8a71ecb4 ("io_uring: add support for IORING_OP_PIPE") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/openclose.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/io_uring/openclose.c b/io_uring/openclose.c index 15dde9bd6ff67..606ce0664e6a4 100644 --- a/io_uring/openclose.c +++ b/io_uring/openclose.c @@ -336,31 +336,34 @@ static int io_pipe_fixed(struct io_kiocb *req, struct= file **files, { struct io_pipe *p =3D io_kiocb_to_cmd(req, struct io_pipe); struct io_ring_ctx *ctx =3D req->ctx; + bool alloc_slot; int ret, fds[2] =3D { -1, -1 }; int slot =3D p->file_slot; =20 if (p->flags & O_CLOEXEC) return -EINVAL; =20 + alloc_slot =3D slot =3D=3D IORING_FILE_INDEX_ALLOC; + io_ring_submit_lock(ctx, issue_flags); =20 ret =3D __io_fixed_fd_install(ctx, files[0], slot); if (ret < 0) goto err; - fds[0] =3D ret; + fds[0] =3D alloc_slot ? ret : slot - 1; files[0] =3D NULL; =20 /* * If a specific slot is given, next one will be used for * the write side. */ - if (slot !=3D IORING_FILE_INDEX_ALLOC) + if (!alloc_slot) slot++; =20 ret =3D __io_fixed_fd_install(ctx, files[1], slot); if (ret < 0) goto err; - fds[1] =3D ret; + fds[1] =3D alloc_slot ? ret : slot - 1; files[1] =3D NULL; =20 io_ring_submit_unlock(ctx, issue_flags); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E883241E5D0; Sat, 28 Feb 2026 17:45:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300753; cv=none; b=giohgWwPKwKqd02/EdfWtG1yZyWyRuTOhfe+TAFCO9czhYxnCDv0H5RKdH3mz6m7zo1GVCgvDqdGNyl68gaebGN9ujcotTAKCtht33baaXZDwpbtR79IkBb+kvPAbuRW4IYeEVYz491LWuMORwIciQZib8mXY9oV0bScfdX+NbE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300753; c=relaxed/simple; bh=sJPjn9/el1BMGHGiVhN4lm3RjvPSjPUYYJVsKWZ2OkE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sMZrYIofyWIOIpaAs9MIFi+pn2NaL05zbWlzb5i6NOzSx8QQIzBSvj0n+R1bI1sWOySnWoAXZ4XJxCVaMo5QNHqrXl8PvXyG7AwXMB3IazaCZTHYlfFsWAQXhHOzl1H8acb0YEUisA6wruYeKMaVVCWB344YWcftdqq4SsyOF9E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i6sA5efJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="i6sA5efJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35B37C19424; Sat, 28 Feb 2026 17:45:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300752; bh=sJPjn9/el1BMGHGiVhN4lm3RjvPSjPUYYJVsKWZ2OkE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i6sA5efJ4j5B8XxeywiawjWA5RNrvlIcRYW9UUi5lCP0tvoV6b2qiRecwBWonCylT eZOfAEVII1phcAr74fjNoPRyfibf6Ur1YKm+3WEjmA2vaJiO0LP/ix0axhpeHWRtxz CmliRAAOKSoUYkpqOE3/HjNphP8+5oJnxRPkrLnQnY66Xr0RyUlp4aXjOGqdtmrqoN XrH6UbqJOmC4JNXjPNDWXQZze//EowYVF6BPZ0YznH0Uhhz8wcTIK9KQ9nY1S9zWE+ DSwAsmKNdY2JEq98OjTh85rp87Dez74J2SoUXgeJD4Muz1cwcdGlmRI5nMmLzp4Era aBlHD+9EHd2yA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Imre Deak , Vinod Govindapillai , Sasha Levin Subject: [PATCH 6.19 789/844] drm/i915/dp: Fail state computation for invalid DSC source input BPP values Date: Sat, 28 Feb 2026 12:31:42 -0500 Message-ID: <20260228173244.1509663-790-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Imre Deak [ Upstream commit 338465490cf7bd4a700ecd33e4855fee4622fa5f ] There is no reason to accept an invalid minimum/maximum DSC source input BPP value (i.e a minimum DSC input BPP value above the maximum pipe BPP or a maximum DSC input BPP value below the minimum pipe BPP value), fail the state computation in these cases. Reviewed-by: Vinod Govindapillai Signed-off-by: Imre Deak Link: https://patch.msgid.link/20251215192357.172201-17-imre.deak@intel.com Stable-dep-of: fe26ae6ac8b8 ("drm/i915/dp: Fix pipe BPP clamping due to HDR= ") Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/i915/display/intel_dp.c | 28 ++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915= /display/intel_dp.c index 0ec82fcbcf48e..d0dbc6715717d 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2605,16 +2605,30 @@ intel_dp_compute_config_link_bpp_limits(struct inte= l_dp *intel_dp, return true; } =20 -static void -intel_dp_dsc_compute_pipe_bpp_limits(struct intel_dp *intel_dp, +static bool +intel_dp_dsc_compute_pipe_bpp_limits(struct intel_connector *connector, struct link_config_limits *limits) { - struct intel_display *display =3D to_intel_display(intel_dp); + struct intel_display *display =3D to_intel_display(connector); + const struct link_config_limits orig_limits =3D *limits; int dsc_min_bpc =3D intel_dp_dsc_min_src_input_bpc(); int dsc_max_bpc =3D intel_dp_dsc_max_src_input_bpc(display); =20 - limits->pipe.max_bpp =3D clamp(limits->pipe.max_bpp, dsc_min_bpc * 3, dsc= _max_bpc * 3); - limits->pipe.min_bpp =3D clamp(limits->pipe.min_bpp, dsc_min_bpc * 3, dsc= _max_bpc * 3); + limits->pipe.min_bpp =3D max(limits->pipe.min_bpp, dsc_min_bpc * 3); + limits->pipe.max_bpp =3D min(limits->pipe.max_bpp, dsc_max_bpc * 3); + + if (limits->pipe.min_bpp <=3D 0 || + limits->pipe.min_bpp > limits->pipe.max_bpp) { + drm_dbg_kms(display->drm, + "[CONNECTOR:%d:%s] Invalid DSC src/sink input BPP (src:%d-%d pipe:%= d-%d)\n", + connector->base.base.id, connector->base.name, + dsc_min_bpc * 3, dsc_max_bpc * 3, + orig_limits.pipe.min_bpp, orig_limits.pipe.max_bpp); + + return false; + } + + return true; } =20 bool @@ -2654,8 +2668,8 @@ intel_dp_compute_config_limits(struct intel_dp *intel= _dp, respect_downstream_limits); } =20 - if (dsc) - intel_dp_dsc_compute_pipe_bpp_limits(intel_dp, limits); + if (dsc && !intel_dp_dsc_compute_pipe_bpp_limits(connector, limits)) + return false; =20 if (is_mst || intel_dp->use_max_params) { /* --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CB2041EDEE; Sat, 28 Feb 2026 17:45:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300754; cv=none; b=Gd7e/w4hQoexXihA9se+fF2sdo6A/jgobUst+ltsWtfTEQ3MmigdeLC7Efqts3TpJ227oibuKkTJnaaUcQZv6IuBf43KLj0ZTKFZ35x0Ouq6+wbN6h9wNlpMqRqkY0AbNsCDI7uOlTWAAZDawIUmDix+0JK61EW8rE1TsDVNoDQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300754; c=relaxed/simple; bh=GO/zWVd/A/W2BF9fwRjLNvOo5WKl075fDPmIaoAKY3M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PM9eYc5Tpxqp1strZrIiev4jaVMMRdfUBFXJKZAP8L/cNRy5rWNov/chihdVwZfo2qBXVkpVmLc5LoQmfrjrKI2vyo4hbsqU56+ekwifpbK8Ec+3LDolI+w3MpmkMhxinS8zHPJvKLh2Z5Ap6j4cvuIf8jni+QDtJWd3jh5irKI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eh9zG95B; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eh9zG95B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2289AC19423; Sat, 28 Feb 2026 17:45:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300753; bh=GO/zWVd/A/W2BF9fwRjLNvOo5WKl075fDPmIaoAKY3M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eh9zG95B5Xh0eqBwJPiT1+lJGA41y8dFpZZOYyX1Fx9F86Mbx1ipoX6e8xhOboFEK hvk0ouHD0YINTRcntmIvpW5F/TrONuLgF6O5aLD1zkcnDOz5jKNRPzHBgGyMPX+k0w kMeUSWHa07/gmbS6EcihdzQmHOjowcC84ce3l495izye536q5lZdsyj6U3p0/uy27W FP54R5llYe6AvqoVvxyY/NJC0ldjf2znjFjcSBK6FCG0As75O2FVsk+4H4vKlEOP3X 2EP1ZHM/LHF+YgldLkuhX7B8tahRFVQxFi1TspEj+Z7dnCE2E0tX/yQzMYtqmtomnv L9jjdM4Q58s4A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Imre Deak , Chaitanya Kumar Borah , Ankit Nautiyal , Joonas Lahtinen , Sasha Levin Subject: [PATCH 6.19 790/844] drm/i915/dp: Fix pipe BPP clamping due to HDR Date: Sat, 28 Feb 2026 12:31:43 -0500 Message-ID: <20260228173244.1509663-791-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Imre Deak [ Upstream commit fe26ae6ac8b88fcdac5036b557c129a17fe520d2 ] The pipe BPP value shouldn't be set outside of the source's / sink's valid pipe BPP range, ensure this when increasing the minimum pipe BPP value to 30 due to HDR. While at it debug print if the HDR mode was requested for a connector by setting the corresponding HDR connector property. This indicates if the requested HDR mode could not be enabled, since the selected pipe BPP is below 30, due to a sink capability or link BW limit. v2: - Also handle the case where the sink could support the target 30 BPP only in DSC mode due to a BW limit, but the sink doesn't support DSC or 30 BPP as a DSC input BPP. (Chaitanya) - Debug print the connector's HDR mode in the link config dump, to indicate if a BPP >=3D 30 required by HDR couldn't be reached. (Ankit) - Add Closes: trailer. (Ankit) - Don't print the 30 BPP-outside of valid BPP range debug message if the min BPP is already > 30 (and so a target BPP >=3D 30 required for HDR is ensured). Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15503 Fixes: ba49a4643cf53 ("drm/i915/dp: Set min_bpp limit to 30 in HDR mode") Cc: Chaitanya Kumar Borah Cc: # v6.18+ Reviewed-by: Ankit Nautiyal # v1 Reviewed-by: Chaitanya Kumar Borah Signed-off-by: Imre Deak Link: https://patch.msgid.link/20260209133817.395823-1-imre.deak@intel.com (cherry picked from commit 08b7ef16b6a03e8c966e286ee1ac608a6ffb3d4a) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/i915/display/intel_dp.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915= /display/intel_dp.c index d0dbc6715717d..ee258df439a7d 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2639,6 +2639,7 @@ intel_dp_compute_config_limits(struct intel_dp *intel= _dp, bool dsc, struct link_config_limits *limits) { + struct intel_display *display =3D to_intel_display(intel_dp); bool is_mst =3D intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST); struct intel_connector *connector =3D to_intel_connector(conn_state->connector); @@ -2651,8 +2652,7 @@ intel_dp_compute_config_limits(struct intel_dp *intel= _dp, limits->min_lane_count =3D intel_dp_min_lane_count(intel_dp); limits->max_lane_count =3D intel_dp_max_lane_count(intel_dp); =20 - limits->pipe.min_bpp =3D intel_dp_in_hdr_mode(conn_state) ? 30 : - intel_dp_min_bpp(crtc_state->output_format); + limits->pipe.min_bpp =3D intel_dp_min_bpp(crtc_state->output_format); if (is_mst) { /* * FIXME: If all the streams can't fit into the link with their @@ -2668,6 +2668,19 @@ intel_dp_compute_config_limits(struct intel_dp *inte= l_dp, respect_downstream_limits); } =20 + if (!dsc && intel_dp_in_hdr_mode(conn_state)) { + if (intel_dp_supports_dsc(intel_dp, connector, crtc_state) && + limits->pipe.max_bpp >=3D 30) + limits->pipe.min_bpp =3D max(limits->pipe.min_bpp, 30); + else + drm_dbg_kms(display->drm, + "[CONNECTOR:%d:%s] Can't force 30 bpp for HDR (pipe bpp: %d-%d DSC= -support: %s)\n", + connector->base.base.id, connector->base.name, + limits->pipe.min_bpp, limits->pipe.max_bpp, + str_yes_no(intel_dp_supports_dsc(intel_dp, connector, + crtc_state))); + } + if (dsc && !intel_dp_dsc_compute_pipe_bpp_limits(connector, limits)) return false; =20 @@ -2798,10 +2811,11 @@ intel_dp_compute_link_config(struct intel_encoder *= encoder, } =20 drm_dbg_kms(display->drm, - "DP lane count %d clock %d bpp input %d compressed " FXP_Q4_FMT " li= nk rate required %d available %d\n", + "DP lane count %d clock %d bpp input %d compressed " FXP_Q4_FMT " HD= R %s link rate required %d available %d\n", pipe_config->lane_count, pipe_config->port_clock, pipe_config->pipe_bpp, FXP_Q4_ARGS(pipe_config->dsc.compressed_bpp_x16), + str_yes_no(intel_dp_in_hdr_mode(conn_state)), intel_dp_config_required_rate(pipe_config), intel_dp_max_link_data_rate(intel_dp, pipe_config->port_clock, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 397F041EE14; Sat, 28 Feb 2026 17:45:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300755; cv=none; b=Dj1xjmnTfX5QxV9gqnSoWC/2D/3ABbj8HdLfi5S6KTu8nttXubu6HsNdXUjVFwU1mRNfjdc8B2r8dTGWgU4pTt2AAJBokNWRkrw4usJJ4ep+5yDym53w7pWrFfttgxrMqK3+GrEx3/QlU+m4ihjMO6Y45xFX6BDPTZdkP1iERUo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300755; c=relaxed/simple; bh=0fLR1J4FMSOIvTYpF/twl2H6aYPkBt+W2GMacOSwAUw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L5Wz0VSCLxv0s/ZZJWly3AF3CztZhNpqS9KBzeexeG7PXMvKijOYPu31bOuCi7D3gdtPBixfIPtBGOR9g5Of97epzO7gJz/7fS8RUBP+AMFzbah6Lu+a08R/NcGJH3sVTjzPSuN4TefJf82eqPREeAHpV4B6EdYOwgd7gl71WQk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Bm0gcvDX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Bm0gcvDX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3135AC19425; Sat, 28 Feb 2026 17:45:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300755; bh=0fLR1J4FMSOIvTYpF/twl2H6aYPkBt+W2GMacOSwAUw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Bm0gcvDXiAi9LoOTpa02kg7cHiOf/aTdvqci+A19hHaa79+M/RWQQWOWiDFNZjYUT mnTSMJSByrYahZoLal6nIy6ZM23WHm5YonUf6ipkeblZmjObRwmqVsF60V3UNAv6WZ 1bVnbupSiiSbAT8OSS9R4RbRDjejcFAjVw9HaYZscfqM1YvhRDh3VmxpZJiNNQDX+L JRcLdsCMd/EJgRSzIqwC+fPhFu6BXmVf9bNUw50mL1B9D4qeHtSPMpKg9RvCtdQ+zi LgGbs5oG+k1sPk3mmGAYeNXyqwKgjzJQO1Q1q3KAP1IX8VPyTks5NQpwKB63bMxEi5 m/mbLP2aV5ykw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Leo Li , Nicholas Kazlauskas , Tom Chung , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 791/844] drm/amd/display: Increase DCN35 SR enter/exit latency Date: Sat, 28 Feb 2026 12:31:44 -0500 Message-ID: <20260228173244.1509663-792-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Leo Li [ Upstream commit 318917e1d8ecc89f820f4fabf79935f4fed718cd ] [Why & How] On Framework laptops with DDR5 modules, underflow can be observed. It's unclear why it only occurs on specific desktop contents. However, increasing enter/exit latencies by 3us seems to resolve it. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4463 Reviewed-by: Nicholas Kazlauskas Signed-off-by: Leo Li Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- .../amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 16 ++++++++-------- .../gpu/drm/amd/display/dc/dml/dcn35/dcn35_fpu.c | 4 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c b= /drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c index dfd0c9505af09..0a21910c87e10 100644 --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c @@ -768,32 +768,32 @@ static struct wm_table ddr5_wm_table =3D { .wm_inst =3D WM_A, .wm_type =3D WM_TYPE_PSTATE_CHG, .pstate_latency_us =3D 11.72, - .sr_exit_time_us =3D 28.0, - .sr_enter_plus_exit_time_us =3D 30.0, + .sr_exit_time_us =3D 31.0, + .sr_enter_plus_exit_time_us =3D 33.0, .valid =3D true, }, { .wm_inst =3D WM_B, .wm_type =3D WM_TYPE_PSTATE_CHG, .pstate_latency_us =3D 11.72, - .sr_exit_time_us =3D 28.0, - .sr_enter_plus_exit_time_us =3D 30.0, + .sr_exit_time_us =3D 31.0, + .sr_enter_plus_exit_time_us =3D 33.0, .valid =3D true, }, { .wm_inst =3D WM_C, .wm_type =3D WM_TYPE_PSTATE_CHG, .pstate_latency_us =3D 11.72, - .sr_exit_time_us =3D 28.0, - .sr_enter_plus_exit_time_us =3D 30.0, + .sr_exit_time_us =3D 31.0, + .sr_enter_plus_exit_time_us =3D 33.0, .valid =3D true, }, { .wm_inst =3D WM_D, .wm_type =3D WM_TYPE_PSTATE_CHG, .pstate_latency_us =3D 11.72, - .sr_exit_time_us =3D 28.0, - .sr_enter_plus_exit_time_us =3D 30.0, + .sr_exit_time_us =3D 31.0, + .sr_enter_plus_exit_time_us =3D 33.0, .valid =3D true, }, } diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn35/dcn35_fpu.c b/drivers= /gpu/drm/amd/display/dc/dml/dcn35/dcn35_fpu.c index 817a370e80a77..8a177d5ae213e 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn35/dcn35_fpu.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn35/dcn35_fpu.c @@ -164,8 +164,8 @@ struct _vcs_dpi_soc_bounding_box_st dcn3_5_soc =3D { }, }, .num_states =3D 5, - .sr_exit_time_us =3D 28.0, - .sr_enter_plus_exit_time_us =3D 30.0, + .sr_exit_time_us =3D 31.0, + .sr_enter_plus_exit_time_us =3D 33.0, .sr_exit_z8_time_us =3D 250.0, .sr_enter_plus_exit_z8_time_us =3D 350.0, .fclk_change_latency_us =3D 24.0, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9FC6C4963D6; Sat, 28 Feb 2026 17:45:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300756; cv=none; b=ZieFb6qA04bC6DiZE9n+MHMY7fGMUecnCMFjU3Y/9IBoqieBZcw6R6l+xgzmD6am8BDsIirASYDweTVdGEdmSpnhGnBovru6EVqOAMmsv9qUNWWu8+bZ3iDSMBvK5ZWC5/leTwt3Lcxf9C/D4Y0Hh8FfzhuYqyuFq9WrXWWWN64= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300756; c=relaxed/simple; bh=ForwgQBNYAjm7/Hw3Jcwsg+KSoOreHUE+pN41ssV4SM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ELW+YeGHTj0CorXX8kdl28tG7p1wBEZbps28iqgDTz7D6Tnuql+vN8aUCD3g2Y9G2YpVJwMDw0lKRiwSEpP7llNveB40goJdHhktHil2CORiaVPR5Pwvd4wnv9PmMLiI7sl7BIafy8A4GYhf95T4aJLvXfUormsOrJtpoIGQves= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vLReu6ln; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vLReu6ln" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 567B4C19423; Sat, 28 Feb 2026 17:45:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300756; bh=ForwgQBNYAjm7/Hw3Jcwsg+KSoOreHUE+pN41ssV4SM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vLReu6lnhINNBZgklJzNGvq0KXd+3xwLEN0jyO5edLuRvP4QkvNH9H4JGh1Y1zvqj mbtDxdecjs6whti2i7r83hM+J3UHbEvX+yyPNAShVMHVwW6/rCs5mZeuXeOD/u1kvA dCZhT4vW0/z8eWyx+7K2djUYOFuzLIGezbhYg6wan/sQFJec+kwT6pv1s/QSLLCGM0 K8N+1MyGD5DSPOGiYUawRkEooxKK8on8NM1PK6E3XGmQIXByqBJWWcJqHSYiI8kQmD 0d29a3ZCVPG3s6+rQpdb+wR8SSfVsTvzCgU6hyCo2fII76IauAnJocrEMRrmLKF35I MVQIMJY5pdWig== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Pierre-Eric Pelloux-Prayer , =?UTF-8?q?Christian=20K=C3=B6nig?= , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 792/844] drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify Date: Sat, 28 Feb 2026 12:31:45 -0500 Message-ID: <20260228173244.1509663-793-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Pierre-Eric Pelloux-Prayer [ Upstream commit b18fc0ab837381c1a6ef28386602cd888f2d9edf ] Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table. The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpu_vm_handle_moved behave as if updating the page table immediately was correct but in this case it's not. An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported: glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blit Xorg: copy of linear buffer The sequence of jobs would be: drm_sched_job_run # GPU0, frame rendering drm_sched_job_queue # GPU0, blit drm_sched_job_done # GPU0, frame rendering drm_sched_job_run # GPU0, blit move linear buffer for GPU1 access # amdgpu_dma_buf_move_notify -> update pt # GPU0 It this point the blit job on GPU0 is still running and would likely produce a page fault. Cc: stable@vger.kernel.org Fixes: a448cb003edc ("drm/amdgpu: implement amdgpu_gem_prime_move_notify v2= ") Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian K=C3=B6nig Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/= amd/amdgpu/amdgpu_dma_buf.c index c1461317eb298..83fed04436ad7 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c @@ -496,8 +496,15 @@ amdgpu_dma_buf_move_notify(struct dma_buf_attachment *= attach) r =3D dma_resv_reserve_fences(resv, 2); if (!r) r =3D amdgpu_vm_clear_freed(adev, vm, NULL); + + /* Don't pass 'ticket' to amdgpu_vm_handle_moved: we want the clear=3Dtr= ue + * path to be used otherwise we might update the PT of another process + * while it's using the BO. + * With clear=3Dtrue, amdgpu_vm_bo_update will sync to command submission + * from the same VM. + */ if (!r) - r =3D amdgpu_vm_handle_moved(adev, vm, ticket); + r =3D amdgpu_vm_handle_moved(adev, vm, NULL); =20 if (r && r !=3D -EBUSY) DRM_ERROR("Failed to invalidate VM page tables (%d))\n", --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8692141F54E; Sat, 28 Feb 2026 17:45:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300758; cv=none; b=SJ9qXwoFDZO7OWpvRIGRI5TiqJDxQzOHGYl3/MotSfSI2/16oKxM3vyblemXAf/obvoyYRWWCGwAlt4g9MSdTdGT7K5E6O6W9qsJPBnR3jsOi+Oa8t83Nov3dTd/DgI823eTG0OiuXtiE9oTzRyQa8qsJriSpQr3KMgQjqdZkms= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300758; c=relaxed/simple; bh=SvhekaeBihNp9RCE30D+VMaOdhKwa+8CeDfTQXBXoo0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=s3Wzm3xOlLE9tUP17oSejU5fOHVPe12iJc61yYhM+Zaz4qDTVJz6/1DCl9PiLgAQ/zE8XF0ZsJUSLJMrqsFfYbt/ofSoPo8pN++N2VhpwprNGIpEe4Cgj0BgE9gUm3SqKDSjz60GBLMWyR/+RGtyBsc2u4WYrB21oKAxZzRi66o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pwjdYgg2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pwjdYgg2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57413C116D0; Sat, 28 Feb 2026 17:45:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300758; bh=SvhekaeBihNp9RCE30D+VMaOdhKwa+8CeDfTQXBXoo0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pwjdYgg2+6Mk/XDH+wrD/P+cQGoKOWjE2GN5RwjU+6RBDlx8SPCPxgJ98TBesEVVB Bu5V4zdxk6FJt714iWgEFV5Fft3Oo7FBAJ66s2IVJND8giJQbQNpuLSR7HUFcClbiX KPzA2VQiG0dnoaGoaiVZQyLjHPvnV73Locickq4ZcO/dfEQNTGuMBC+cyNdZLSblRv wbqwZgJ8z7zY15JdEredev8FrX5620ro1WnGO3rhnw9SclJzLVtt4RG2VRQqFCBfWC YZ6ABCrXkxurpKzu1qPTfvQZ09ybTRKlz374Mij5nuy2l1m9y4729T+IL5vZHIDfi7 wPFvaR4IyfV/g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Joshua Hahn , Usama Arif , David Hildenbrand , "Liam R. Howlett" , Lorenzo Stoakes , Ma Wupeng , Michal Hocko , Mike Rapoport , Muchun Song , Oscar Salvador , Shakeel Butt , Suren Baghdasaryan , Vlastimil Babka , Waiman Long , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 793/844] mm/hugetlb: restore failed global reservations to subpool Date: Sat, 28 Feb 2026 12:31:46 -0500 Message-ID: <20260228173244.1509663-794-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Joshua Hahn [ Upstream commit 1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5 ] Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool's reservation. Unfortunately, this fix also introduced the opposite problem, which would leave spool->used_hpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter. Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit. The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=3D4, min=3D2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepage_subpool_get_pages(spool, 3) succeeds. used_hpages +=3D 3 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left used_hpages -=3D 2 5. Subpool now has used_hpages =3D 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4. With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user. Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages. The underflow issue that the original commit fixes still remains fixed as well. Without this fix, used_hpages would keep on leaking if hugetlb_acct_memory() fails. Link: https://lkml.kernel.org/r/20260116204037.2270096-1-joshua.hahnjy@gmai= l.com Fixes: a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") Signed-off-by: Joshua Hahn Acked-by: Usama Arif Cc: David Hildenbrand Cc: "Liam R. Howlett" Cc: Lorenzo Stoakes Cc: Ma Wupeng Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Oscar Salvador Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Waiman Long Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/hugetlb.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index a1832da0f6236..77e45dd50ba21 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6717,6 +6717,15 @@ long hugetlb_reserve_pages(struct inode *inode, */ hugetlb_acct_memory(h, -gbl_resv); } + /* Restore used_hpages for pages that failed global reservation */ + if (gbl_reserve && spool) { + unsigned long flags; + + spin_lock_irqsave(&spool->lock, flags); + if (spool->max_hpages !=3D -1) + spool->used_hpages -=3D gbl_reserve; + unlock_or_release_subpool(spool, flags); + } out_uncharge_cgroup: hugetlb_cgroup_uncharge_cgroup_rsvd(hstate_index(h), chg * pages_per_huge_page(h), h_cg); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82BE641EE06; Sat, 28 Feb 2026 17:46:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300760; cv=none; b=fUSRLxo74xdIzqAewbt+OSiWs2KCtoAZlbjAAVB96UXMKgzVHVOkJc685LKPOs//c0gPtCQ3dsrPKVNzLGYlPklbVFeA8E197plVLXs9s8GjJlweyyYlW09nU34wC9XfggMMw4rMnokqWudsuzhKkF5FmPOufeza96cbsbcf32Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300760; c=relaxed/simple; bh=zp6cO7ZFhELTQw7V6vC4EMFq2kivJRRUtz9gBME0WYE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KtgWdA09wcvGBk4fsHx1TVWXt55xZQnJQfhU7bmfm1Ld/OJ/queb6fSkR/mn7Esb0QZjEsJoN7fCN/HYKzbvPioNEE4oaA2LVpZ2OkZlcvzI0wlll9OZiCT8az+VwGuVmPrltBIxDxSAAX0tmiqz5RFRgdKu8NGpn9PjVvbZ1EQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PjZjTZ4C; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PjZjTZ4C" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87A2AC2BC9E; Sat, 28 Feb 2026 17:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300760; bh=zp6cO7ZFhELTQw7V6vC4EMFq2kivJRRUtz9gBME0WYE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PjZjTZ4Cwy0ZrKdk+EMIxy+qVWLEK/ZsH905v38p/4N2tJIhLysmcP/v8Lyk5k6kR hWmBf7FjaV85hOQncZEBqbUkiggBwqBbul9ox1r+oOv6uKdHJE8THHKATjVAUdxO+l bKgJoMaIbYBqCXPuNA1FUboF6tLnBiqbx/VL2IU3X40sIJEPtYiSs/T9TR+JdZvvpz Yi1nvwXYWxwgS0oV5RhoReeJr9a8B9Zz7nZ8auN9v+heDJx0GBSBv78YQE6jVAaNc4 iSwJT8C+Hz/fE3G5prk0RPqIjPjhcJEJavLQL/ISTdyrJh+JdyUfD9sGf2qGQvASjZ YQ1mnIjS0iv0w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harry Yoo , Vlastimil Babka , Zi Yan , Alexei Starovoitov , Brendan Jackman , Johannes Weiner , Michal Hocko , Sebastian Andrzej Siewior , Shakeel Butt , Suren Baghdasaryan , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 794/844] mm/page_alloc: skip debug_check_no_{obj,locks}_freed with FPI_TRYLOCK Date: Sat, 28 Feb 2026 12:31:47 -0500 Message-ID: <20260228173244.1509663-795-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harry Yoo [ Upstream commit 338ad1e84d15078a9ae46d7dd7466329ae0bfa61 ] When CONFIG_DEBUG_OBJECTS_FREE is enabled, debug_check_no_{obj,locks}_freed() functions are called. Since both of them spin on a lock, they are not safe to be called if the FPI_TRYLOCK flag is specified. This leads to a lockdep splat: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D WARNING: inconsistent lock state 6.19.0-rc5-slab-for-next+ #326 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/9046 [HC2[2]:SC0[0]:HE0:SE1] takes: ffffffff84ed6bf8 (&obj_hash[i].lock){-.-.}-{2:2}, at: __debug_check_no_ob= j_freed+0xe0/0x300 {INITIAL USE} state was registered at: lock_acquire+0xd9/0x2f0 _raw_spin_lock_irqsave+0x4c/0x80 __debug_object_init+0x9d/0x1f0 debug_object_init+0x34/0x50 __init_work+0x28/0x40 init_cgroup_housekeeping+0x151/0x210 init_cgroup_root+0x3d/0x140 cgroup_init_early+0x30/0x240 start_kernel+0x3e/0xcd0 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xf3/0x140 common_startup_64+0x13e/0x148 irq event stamp: 2998 hardirqs last enabled at (2997): [] exc_nmi+0x11a/0x240 hardirqs last disabled at (2998): [] sysvec_irq_work+0x= 11/0x110 softirqs last enabled at (1416): [] __irq_exit_rcu+0x1= 32/0x1c0 softirqs last disabled at (1303): [] __irq_exit_rcu+0x1= 32/0x1c0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&obj_hash[i].lock); lock(&obj_hash[i].lock); *** DEADLOCK *** Rename free_pages_prepare() to __free_pages_prepare(), add an fpi_t parameter, and skip those checks if FPI_TRYLOCK is set. To keep the fpi_t definition in mm/page_alloc.c, add a wrapper function free_pages_prepare() that always passes FPI_NONE and use it in mm/compaction.c. Link: https://lkml.kernel.org/r/20260209062639.16577-1-harry.yoo@oracle.com Fixes: 8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()") Signed-off-by: Harry Yoo Reviewed-by: Vlastimil Babka Acked-by: Zi Yan Cc: Alexei Starovoitov Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Sebastian Andrzej Siewior Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/page_alloc.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 1af52f568f22d..48af3d7b47849 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1340,8 +1340,8 @@ static inline void pgalloc_tag_sub_pages(struct alloc= _tag *tag, unsigned int nr) =20 #endif /* CONFIG_MEM_ALLOC_PROFILING */ =20 -__always_inline bool free_pages_prepare(struct page *page, - unsigned int order) +__always_inline bool __free_pages_prepare(struct page *page, + unsigned int order, fpi_t fpi_flags) { int bad =3D 0; bool skip_kasan_poison =3D should_skip_kasan_poison(page); @@ -1434,7 +1434,7 @@ __always_inline bool free_pages_prepare(struct page *= page, page_table_check_free(page, order); pgalloc_tag_sub(page, 1 << order); =20 - if (!PageHighMem(page)) { + if (!PageHighMem(page) && !(fpi_flags & FPI_TRYLOCK)) { debug_check_no_locks_freed(page_address(page), PAGE_SIZE << order); debug_check_no_obj_freed(page_address(page), @@ -1473,6 +1473,11 @@ __always_inline bool free_pages_prepare(struct page = *page, return true; } =20 +bool free_pages_prepare(struct page *page, unsigned int order) +{ + return __free_pages_prepare(page, order, FPI_NONE); +} + /* * Frees a number of pages from the PCP lists * Assumes all pages on list are in same zone. @@ -1606,7 +1611,7 @@ static void __free_pages_ok(struct page *page, unsign= ed int order, unsigned long pfn =3D page_to_pfn(page); struct zone *zone =3D page_zone(page); =20 - if (free_pages_prepare(page, order)) + if (__free_pages_prepare(page, order, fpi_flags)) free_one_page(zone, page, pfn, order, fpi_flags); } =20 @@ -2970,7 +2975,7 @@ static void __free_frozen_pages(struct page *page, un= signed int order, return; } =20 - if (!free_pages_prepare(page, order)) + if (!__free_pages_prepare(page, order, fpi_flags)) return; =20 /* @@ -3027,7 +3032,7 @@ void free_unref_folios(struct folio_batch *folios) unsigned long pfn =3D folio_pfn(folio); unsigned int order =3D folio_order(folio); =20 - if (!free_pages_prepare(&folio->page, order)) + if (!__free_pages_prepare(&folio->page, order, FPI_NONE)) continue; /* * Free orders not handled on the PCP directly to the --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCEF94963DA; Sat, 28 Feb 2026 17:46:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300761; cv=none; b=O/P1qlLfxMVmJQ9fOARG7eDnhWu3bIjNh5JUCOPcvAqz6G/2IYtKCcvogy7xvSrU4ljPLyj6xCTzWzhbb0ytcOAwNCpvuAfmnX3ioQRGpx/gvNoc2yG9PqmUzJ3lDH8ehFMHtkJQ5bVQ5SSdS3oFjei/BTLoNDhJ9hMZyYTILPY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300761; c=relaxed/simple; bh=Lf6er7hIUYoGNxI8zjtR1nY1T9ukD1O6DpoqieGl/Z8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K98Y+cFil5SzTlJUbVd9Gi1cvMav2WWeWAWyN90z0CBPEgISp6kEv3qfiq94QcmWuYoLLzGujS7AqUOK5q+DybfhecnUKvh4mmyo3veaiA6hfyuuaonWdrytO92T0IS0fpKMDY7GZUkftdWTYUGQxWOLHloeQKINo/QonXpyDeE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TcpK7tLR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TcpK7tLR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4619FC19425; Sat, 28 Feb 2026 17:46:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300761; bh=Lf6er7hIUYoGNxI8zjtR1nY1T9ukD1O6DpoqieGl/Z8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TcpK7tLRzfZwIZNmMMYaRm8qwU73riS3wPP1Lvsbaj46DyEfVwOKUexkD6SoPNmF/ wUcjKZAJ3+nXz3uqgskOTojJxZlQowF9/x2AdjDk6bAqwL7ZxS00FQNrgroGZD3Hih UPXkcQCcTohIkXnJ/DsYJSmc4lS9QVXm7HyhRyGo3MhIwDbVTzn9xKnQJoir+fRuew l8Se+dYsiiw4Ttg0xRNMOiPj/AFfafJW3mgsxw/Bw+tJ4mTCsrhj/YYRTQ4OUROtmN wl+RpjtHW286a9XWgAGBxB0FMipQXFpWjqg0DDjpYUJBrCM0qmQ7oTsoRDpvfGKZmY F+UidbH1ti7ug== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Ruikai Peng , Thomas Gleixner , Shakeel Butt , syzbot+237b5b985b78c1da9600@syzkaller.appspotmail.com, Andrew Morton , Sasha Levin Subject: [PATCH 6.19 795/844] procfs: fix possible double mmput() in do_procmap_query() Date: Sat, 28 Feb 2026 12:31:48 -0500 Message-ID: <20260228173244.1509663-796-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit 61dc9f776705d6db6847c101b98fa4f0e9eb6fa3 ] When user provides incorrectly sized buffer for build ID for PROCMAP_QUERY we return with -ENAMETOOLONG error. After recent changes this condition happens later, after we unlocked mmap_lock/per-VMA lock and did mmput(), so original goto out is now wrong and will double-mmput() mm_struct. Fix by jumping further to clean up only vm_file and name_buf. Link: https://lkml.kernel.org/r/20260210192738.3041609-1-andrii@kernel.org Fixes: b5cbacd7f86f ("procfs: avoid fetching build ID while holding VMA loc= k") Signed-off-by: Andrii Nakryiko Reported-by: Ruikai Peng Reported-by: Thomas Gleixner Tested-by: Thomas Gleixner Reviewed-by: Shakeel Butt Reported-by: syzbot+237b5b985b78c1da9600@syzkaller.appspotmail.com Cc: Ruikai Peng Closes: https://lkml.kernel.org/r/CAFD3drOJANTZPuyiqMdqpiRwOKnHwv5QgMNZghCD= r-WxdiHvMg@mail.gmail.com Closes: https://lore.kernel.org/all/698aaf3c.050a0220.3b3015.0088.GAE@googl= e.com/T/#u Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/proc/task_mmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 26188a4ad1abd..2f55efc368162 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -780,7 +780,7 @@ static int do_procmap_query(struct mm_struct *mm, void = __user *uarg) } else { if (karg.build_id_size < build_id_sz) { err =3D -ENAMETOOLONG; - goto out; + goto out_file; } karg.build_id_size =3D build_id_sz; } @@ -808,6 +808,7 @@ static int do_procmap_query(struct mm_struct *mm, void = __user *uarg) out: query_vma_teardown(&lock_ctx); mmput(mm); +out_file: if (vm_file) fput(vm_file); kfree(name_buf); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C7E641FE0E; Sat, 28 Feb 2026 17:46:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300764; cv=none; b=GV9reb8Eq85jv0cjrn2ajnkIMiA+PbHAz76O+lue1Bqbqenf4O07eiwNM68IwDX/3bzLpeLI49EeVdSzU+SXvcbYIn8bk8eXnXpkXqafUtENcfx43BWlZol4K2f1Db+46A6aUWioOl3GDyhW3jClah8CL94389WA1Pb6kqJJqAI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300764; c=relaxed/simple; bh=OtMj7CmQ6fqSlQoJN2jnRlJ9Z64fiLW/MGW85MuIhYM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VK1jVS06kkLDpxUf+gHppHRRjYyCMsgaXOgGEoSAoy7FrFhPN9Z6nDCdvAWsPhW1TYNVI55yLIVonq8ML31I/8PZ7wkMRYqj3ArVH+WVroU9Xppm6oNBA5C24zzZ5JWK2HQIl/iVh6WSEDKVH+gL0OWBE/lBjSLlzOLDGG5U2Ao= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NANTIr+s; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NANTIr+s" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C13FC116D0; Sat, 28 Feb 2026 17:46:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300764; bh=OtMj7CmQ6fqSlQoJN2jnRlJ9Z64fiLW/MGW85MuIhYM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NANTIr+sHuKeP+8N/QB1EoS7ejWwz14/ICx7qP7zDliNsI0Lc12l5tASUQsoV0Cq6 bPtDbjv2t1Udk0FmzlLvNFX+xRhmwzVRgFZs+GNjSZglqiXMnSymzgrLXbZGbJ1u7L M8/1os7OT7ZzWO1MEm3tDcVK0PlIQtHwiWTa7Q4vK1EVponB3TEwfPcKn3GpR9GLvG ERKkLA6D3QoGkzmZQKSiynOFfzilnw9ahIanJO+XWlhuRp3zrgbDOegPTZUIWp4RBj yQ5nVMbaNH3P954UdeNcsHkCvAt7dv5NlIiCqbiIRoPGlJW+bzJDjugxpdW7MMaWtJ ziXDNEpgXL3pQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bing Jiao , Shakeel Butt , Axel Rasmussen , David Hildenbrand , Gregory Price , Johannes Weiner , Joshua Hahn , Liam Howlett , Lorenzo Stoakes , Michal Hocko , Mike Rapoport , Muchun Song , Qi Zheng , Roman Gushchin , Suren Baghdasaryan , Tejun Heo , Vlastimil Babka , Waiman Long , Wei Xu , Yuanchu Xie , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 796/844] mm/vmscan: fix demotion targets checks in reclaim/demotion Date: Sat, 28 Feb 2026 12:31:49 -0500 Message-ID: <20260228173244.1509663-797-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bing Jiao [ Upstream commit 1aceed565ff172fc0331dd1d5e7e65139b711139 ] Patch series "mm/vmscan: fix demotion targets checks in reclaim/demotion", v9. This patch series addresses two issues in demote_folio_list(), can_demote(), and next_demotion_node() in reclaim/demotion. 1. demote_folio_list() and can_demote() do not correctly check demotion target against cpuset.mems_effective, which will cause (a) pages to be demoted to not-allowed nodes and (b) pages fail demotion even if the system still has allowed demotion nodes. Patch 1 fixes this bug by updating cpuset_node_allowed() and mem_cgroup_node_allowed() to return effective_mems, allowing directly logic-and operation against demotion targets. 2. next_demotion_node() returns a preferred demotion target, but it does not check the node against allowed nodes. Patch 2 ensures that next_demotion_node() filters against the allowed node mask and selects the closest demotion target to the source node. This patch (of 2): Fix two bugs in demote_folio_list() and can_demote() due to incorrect demotion target checks against cpuset.mems_effective in reclaim/demotion. Commit 7d709f49babc ("vmscan,cgroup: apply mems_effective to reclaim") introduces the cpuset.mems_effective check and applies it to can_demote(). However: 1. It does not apply this check in demote_folio_list(), which leads to situations where pages are demoted to nodes that are explicitly excluded from the task's cpuset.mems. 2. It checks only the nodes in the immediate next demotion hierarchy and does not check all allowed demotion targets in can_demote(). This can cause pages to never be demoted if the nodes in the next demotion hierarchy are not set in mems_effective. These bugs break resource isolation provided by cpuset.mems. This is visible from userspace because pages can either fail to be demoted entirely or are demoted to nodes that are not allowed in multi-tier memory systems. To address these bugs, update cpuset_node_allowed() and mem_cgroup_node_allowed() to return effective_mems, allowing directly logic-and operation against demotion targets. Also update can_demote() and demote_folio_list() accordingly. Bug 1 reproduction: Assume a system with 4 nodes, where nodes 0-1 are top-tier and nodes 2-3 are far-tier memory. All nodes have equal capacity. Test script: echo 1 > /sys/kernel/mm/numa/demotion_enabled mkdir /sys/fs/cgroup/test echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control echo "0-2" > /sys/fs/cgroup/test/cpuset.mems echo $$ > /sys/fs/cgroup/test/cgroup.procs swapoff -a # Expectation: Should respect node 0-2 limit. # Observation: Node 3 shows significant allocation (MemFree drops) stress-ng --oomable --vm 1 --vm-bytes 150% --mbind 0,1 Bug 2 reproduction: Assume a system with 6 nodes, where nodes 0-2 are top-tier, node 3 is a far-tier node, and nodes 4-5 are the farthest-tier nodes. All nodes have equal capacity. Test script: echo 1 > /sys/kernel/mm/numa/demotion_enabled mkdir /sys/fs/cgroup/test echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control echo "0-2,4-5" > /sys/fs/cgroup/test/cpuset.mems echo $$ > /sys/fs/cgroup/test/cgroup.procs swapoff -a # Expectation: Pages are demoted to Nodes 4-5 # Observation: No pages are demoted before oom. stress-ng --oomable --vm 1 --vm-bytes 150% --mbind 0,1,2 Link: https://lkml.kernel.org/r/20260114205305.2869796-1-bingjiao@google.com Link: https://lkml.kernel.org/r/20260114205305.2869796-2-bingjiao@google.com Fixes: 7d709f49babc ("vmscan,cgroup: apply mems_effective to reclaim") Signed-off-by: Bing Jiao Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: David Hildenbrand Cc: Gregory Price Cc: Johannes Weiner Cc: Joshua Hahn Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Qi Zheng Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Tejun Heo Cc: Vlastimil Babka Cc: Waiman Long Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/cpuset.h | 6 ++--- include/linux/memcontrol.h | 6 ++--- kernel/cgroup/cpuset.c | 54 +++++++++++++++++++++++++------------- mm/memcontrol.c | 16 +++++++++-- mm/vmscan.c | 34 +++++++++++++++--------- 5 files changed, 78 insertions(+), 38 deletions(-) diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h index a98d3330385c2..631577384677a 100644 --- a/include/linux/cpuset.h +++ b/include/linux/cpuset.h @@ -174,7 +174,7 @@ static inline void set_mems_allowed(nodemask_t nodemask) task_unlock(current); } =20 -extern bool cpuset_node_allowed(struct cgroup *cgroup, int nid); +extern void cpuset_nodes_allowed(struct cgroup *cgroup, nodemask_t *mask); #else /* !CONFIG_CPUSETS */ =20 static inline bool cpusets_enabled(void) { return false; } @@ -301,9 +301,9 @@ static inline bool read_mems_allowed_retry(unsigned int= seq) return false; } =20 -static inline bool cpuset_node_allowed(struct cgroup *cgroup, int nid) +static inline void cpuset_nodes_allowed(struct cgroup *cgroup, nodemask_t = *mask) { - return true; + nodes_copy(*mask, node_states[N_MEMORY]); } #endif /* !CONFIG_CPUSETS */ =20 diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 0651865a4564f..412db7663357e 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -1744,7 +1744,7 @@ static inline void count_objcg_events(struct obj_cgro= up *objcg, rcu_read_unlock(); } =20 -bool mem_cgroup_node_allowed(struct mem_cgroup *memcg, int nid); +void mem_cgroup_node_filter_allowed(struct mem_cgroup *memcg, nodemask_t *= mask); =20 void mem_cgroup_show_protected_memory(struct mem_cgroup *memcg); =20 @@ -1815,9 +1815,9 @@ static inline ino_t page_cgroup_ino(struct page *page) return 0; } =20 -static inline bool mem_cgroup_node_allowed(struct mem_cgroup *memcg, int n= id) +static inline void mem_cgroup_node_filter_allowed(struct mem_cgroup *memcg, + nodemask_t *mask) { - return true; } =20 static inline void mem_cgroup_show_protected_memory(struct mem_cgroup *mem= cg) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index dc3ac38c5d160..62e1807b23448 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -4424,40 +4424,58 @@ bool cpuset_current_node_allowed(int node, gfp_t gf= p_mask) return allowed; } =20 -bool cpuset_node_allowed(struct cgroup *cgroup, int nid) +/** + * cpuset_nodes_allowed - return effective_mems mask from a cgroup cpuset. + * @cgroup: pointer to struct cgroup. + * @mask: pointer to struct nodemask_t to be returned. + * + * Returns effective_mems mask from a cgroup cpuset if it is cgroup v2 and + * has cpuset subsys. Otherwise, returns node_states[N_MEMORY]. + * + * This function intentionally avoids taking the cpuset_mutex or callback_= lock + * when accessing effective_mems. This is because the obtained effective_m= ems + * is stale immediately after the query anyway (e.g., effective_mems is up= dated + * immediately after releasing the lock but before returning). + * + * As a result, returned @mask may be empty because cs->effective_mems can= be + * rebound during this call. Besides, nodes in @mask are not guaranteed to= be + * online due to hot plugins. Callers should check the mask for validity on + * return based on its subsequent use. + **/ +void cpuset_nodes_allowed(struct cgroup *cgroup, nodemask_t *mask) { struct cgroup_subsys_state *css; struct cpuset *cs; - bool allowed; =20 /* * In v1, mem_cgroup and cpuset are unlikely in the same hierarchy * and mems_allowed is likely to be empty even if we could get to it, - * so return true to avoid taking a global lock on the empty check. + * so return directly to avoid taking a global lock on the empty check. */ - if (!cpuset_v2()) - return true; + if (!cgroup || !cpuset_v2()) { + nodes_copy(*mask, node_states[N_MEMORY]); + return; + } =20 css =3D cgroup_get_e_css(cgroup, &cpuset_cgrp_subsys); - if (!css) - return true; + if (!css) { + nodes_copy(*mask, node_states[N_MEMORY]); + return; + } =20 /* - * Normally, accessing effective_mems would require the cpuset_mutex - * or callback_lock - but node_isset is atomic and the reference - * taken via cgroup_get_e_css is sufficient to protect css. - * - * Since this interface is intended for use by migration paths, we - * relax locking here to avoid taking global locks - while accepting - * there may be rare scenarios where the result may be innaccurate. + * The reference taken via cgroup_get_e_css is sufficient to + * protect css, but it does not imply safe accesses to effective_mems. * - * Reclaim and migration are subject to these same race conditions, and - * cannot make strong isolation guarantees, so this is acceptable. + * Normally, accessing effective_mems would require the cpuset_mutex + * or callback_lock - but the correctness of this information is stale + * immediately after the query anyway. We do not acquire the lock + * during this process to save lock contention in exchange for racing + * against mems_allowed rebinds. */ cs =3D container_of(css, struct cpuset, css); - allowed =3D node_isset(nid, cs->effective_mems); + nodes_copy(*mask, cs->effective_mems); css_put(css); - return allowed; } =20 /** diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 86f43b7e5f710..702c3db624a0c 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5624,9 +5624,21 @@ subsys_initcall(mem_cgroup_swap_init); =20 #endif /* CONFIG_SWAP */ =20 -bool mem_cgroup_node_allowed(struct mem_cgroup *memcg, int nid) +void mem_cgroup_node_filter_allowed(struct mem_cgroup *memcg, nodemask_t *= mask) { - return memcg ? cpuset_node_allowed(memcg->css.cgroup, nid) : true; + nodemask_t allowed; + + if (!memcg) + return; + + /* + * Since this interface is intended for use by migration paths, and + * reclaim and migration are subject to race conditions such as changes + * in effective_mems and hot-unpluging of nodes, inaccurate allowed + * mask is acceptable. + */ + cpuset_nodes_allowed(memcg->css.cgroup, &allowed); + nodes_and(*mask, *mask, allowed); } =20 void mem_cgroup_show_protected_memory(struct mem_cgroup *memcg) diff --git a/mm/vmscan.c b/mm/vmscan.c index 614ccf39fe3fa..7724b1a1a8b52 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -344,19 +344,21 @@ static void flush_reclaim_state(struct scan_control *= sc) static bool can_demote(int nid, struct scan_control *sc, struct mem_cgroup *memcg) { - int demotion_nid; + struct pglist_data *pgdat =3D NODE_DATA(nid); + nodemask_t allowed_mask; =20 - if (!numa_demotion_enabled) + if (!pgdat || !numa_demotion_enabled) return false; if (sc && sc->no_demotion) return false; =20 - demotion_nid =3D next_demotion_node(nid); - if (demotion_nid =3D=3D NUMA_NO_NODE) + node_get_allowed_targets(pgdat, &allowed_mask); + if (nodes_empty(allowed_mask)) return false; =20 - /* If demotion node isn't in the cgroup's mems_allowed, fall back */ - return mem_cgroup_node_allowed(memcg, demotion_nid); + /* Filter out nodes that are not in cgroup's mems_allowed. */ + mem_cgroup_node_filter_allowed(memcg, &allowed_mask); + return !nodes_empty(allowed_mask); } =20 static inline bool can_reclaim_anon_pages(struct mem_cgroup *memcg, @@ -1019,9 +1021,10 @@ static struct folio *alloc_demote_folio(struct folio= *src, * Folios which are not demoted are left on @demote_folios. */ static unsigned int demote_folio_list(struct list_head *demote_folios, - struct pglist_data *pgdat) + struct pglist_data *pgdat, + struct mem_cgroup *memcg) { - int target_nid =3D next_demotion_node(pgdat->node_id); + int target_nid; unsigned int nr_succeeded; nodemask_t allowed_mask; =20 @@ -1033,7 +1036,6 @@ static unsigned int demote_folio_list(struct list_hea= d *demote_folios, */ .gfp_mask =3D (GFP_HIGHUSER_MOVABLE & ~__GFP_RECLAIM) | __GFP_NOMEMALLOC | GFP_NOWAIT, - .nid =3D target_nid, .nmask =3D &allowed_mask, .reason =3D MR_DEMOTION, }; @@ -1041,10 +1043,18 @@ static unsigned int demote_folio_list(struct list_h= ead *demote_folios, if (list_empty(demote_folios)) return 0; =20 - if (target_nid =3D=3D NUMA_NO_NODE) + node_get_allowed_targets(pgdat, &allowed_mask); + mem_cgroup_node_filter_allowed(memcg, &allowed_mask); + if (nodes_empty(allowed_mask)) return 0; =20 - node_get_allowed_targets(pgdat, &allowed_mask); + target_nid =3D next_demotion_node(pgdat->node_id); + if (target_nid =3D=3D NUMA_NO_NODE) + /* No lower-tier nodes or nodes were hot-unplugged. */ + return 0; + if (!node_isset(target_nid, allowed_mask)) + target_nid =3D node_random(&allowed_mask); + mtc.nid =3D target_nid; =20 /* Demotion ignores all cpuset and mempolicy settings */ migrate_pages(demote_folios, alloc_demote_folio, NULL, @@ -1566,7 +1576,7 @@ static unsigned int shrink_folio_list(struct list_hea= d *folio_list, /* 'folio_list' is always empty here */ =20 /* Migrate folios selected for demotion */ - nr_demoted =3D demote_folio_list(&demote_folios, pgdat); + nr_demoted =3D demote_folio_list(&demote_folios, pgdat, memcg); nr_reclaimed +=3D nr_demoted; stat->nr_demoted +=3D nr_demoted; /* Folios that could not be demoted are still in @demote_folios */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 224BD495533; Sat, 28 Feb 2026 17:46:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300766; cv=none; b=cwqqrCBhreDXLraZzNImyQ2Kss4G1SmifgroCW/UfRJBLkN1lBJDO7Y7TKji9xNYExUyhbK2YDPisD+tW3dlUPXwTP7vu6kFc/m5o4FAAXiXmgutCpuELk+idXZBmwvMRwjHaW9MQANCfVwaY2b1mGuA67+EyIl+rbt7IxjuqOE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300766; c=relaxed/simple; bh=5BRXygWSe9z9u0wEphqVihDWuv/lI+QkbvdRomdKYdQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cfulKybNwO3IOeqVqBpqqI+6EsqXjY2G9LnVIfm7KDqQTgO9CMeVtAR3zoOY3aLM+zLGxXSE4+wQxCHpBnTqniRFe+xRB1y3NnY/Iv73Oz9pVq1AC1nthCEuuspqF3tmuXv4IQBHWlCCyBHRKbxw+PMLYsNxsO3u7glxlZU3ebs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mOlPCHFH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mOlPCHFH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C7D0C19424; Sat, 28 Feb 2026 17:46:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300766; bh=5BRXygWSe9z9u0wEphqVihDWuv/lI+QkbvdRomdKYdQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mOlPCHFHd0CY1xwZArIjbHmOFruZWG9DqiFrPkVbUcgSl9/JCB9ZUshdJKeLUSBxx 61z4nUV/0DduT7QVBKyTXUsBL0jqC/+6+QJBV63fU3/xAJr/Ju97CWUhmUsTccK3iR O7GIzwqhDAgrVmMS0yNBTE5Cpm6V4qLEd6aFGC83+X3KXoapshLbXJF+2ePE5QkSRH 0ToFV4Egz76DGYE8ij9J3O9iuqBnetlDrmyABlMGLC4BrhTXgpg6blcHlhnsojGr0i 6aNeLt3+0Z0+D8fcDgLj3ne7uaK3tF3BIhEZVswaKBGha7BqcezQ30sijZbAsk7ExS x5ZPpO+rIQNow== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mikhail Gavrilov , Zi Yan , "David Hildenbrand (Arm)" , Vlastimil Babka , Brendan Jackman , Chris Li , Hugh Dickins , Johannes Weiner , Kairui Song , "Matthew Wilcox (Oracle)" , Michal Hocko , Nicholas Piggin , Suren Baghdasaryan , Andrew Morton , Sasha Levin Subject: [PATCH 6.19 797/844] mm/page_alloc: clear page->private in free_pages_prepare() Date: Sat, 28 Feb 2026 12:31:50 -0500 Message-ID: <20260228173244.1509663-798-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mikhail Gavrilov [ Upstream commit ac1ea219590c09572ed5992dc233bbf7bb70fef9 ] Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private =3D=3D 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000= 000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use. Link: https://lkml.kernel.org/r/20260207173615.146159-1-mikhail.v.gavrilov@= gmail.com Fixes: 3b8000ae185c ("mm/vmalloc: huge vmalloc backing pages should be spli= t rather than compound") Signed-off-by: Mikhail Gavrilov Suggested-by: Zi Yan Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Reviewed-by: Vlastimil Babka Cc: Brendan Jackman Cc: Chris Li Cc: Hugh Dickins Cc: Johannes Weiner Cc: Kairui Song Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Nicholas Piggin Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/page_alloc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 48af3d7b47849..04e32adaeb1dd 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1430,6 +1430,7 @@ __always_inline bool __free_pages_prepare(struct page= *page, =20 page_cpupid_reset_last(page); page->flags.f &=3D ~PAGE_FLAGS_CHECK_AT_PREP; + page->private =3D 0; reset_page_owner(page, order); page_table_check_free(page, order); pgalloc_tag_sub(page, 1 << order); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A1D5420982; Sat, 28 Feb 2026 17:46:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300767; cv=none; b=THBzVsHeevjVlXNZaXH3BVVRSXLzKl32l4aCOdGMdGF1V2TJxlB+FwmDCyTwO32v/SMu51B2lFAVsVzY/WJAFwcVNaRXeaOKOv+SejSUm+l89lSzYV833QIoRLW29PdpAONHaa0l1N1LOyynsr+TSucrNyi+rOxooFmezcjghHo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300767; c=relaxed/simple; bh=BPQEXgJWm9wvOEPxV+0o5agExO0mhG0/KDfc73p04Hk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G2ZLSKhcspumu+CPdEDlqyFKMjriV5DaA6JUiZ1cgqQ+ekNUubEOoTThQrfh/3DE/G3+DccTuHS2YEsE4V2E9ihKcYdyFDNQ9fEB4sZfR6MqQWNrXU3Ejt17CPC99NFNN5FC1XR3Kjv1mkezNrYFKNvULdnaJg8nh0I90RLideI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C85uffKx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C85uffKx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50F86C116D0; Sat, 28 Feb 2026 17:46:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300767; bh=BPQEXgJWm9wvOEPxV+0o5agExO0mhG0/KDfc73p04Hk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C85uffKxDIvoBJOfIWliB1Tq7Xpj78uRbDnRbGN7YyzIW0GAaoquieFkFTPcas3HQ zeV9X/HU08qqOH7X6KsyT7hWyehnXu2Lgd+xhy8fFESw5yJCFk3ViRwFUqo28dQChL W1q3n2X7EvHEDCTeh86YJQ1B+kBy+VrAVe2kpur6xb6VSbKzm/iqdp1XW/ZmV69LLu 0K2v7vmd6xkmI18ryS0XL4HgHH9JuAw7/sZwVzeTtIPNyCFrPpxp62d0FMfxzVCTDZ 6bHUdbiyxux2l54/YkNAKI+mPWYrDANi836LqWIU3Jry36v7ba2RmUEKVYVmW9HB81 OND0TL8rkbfxg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Nelson-Moore , Johannes Berg , Aleksandr Loktionov , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 798/844] net: intel: fix PCI device ID conflict between i40e and ipw2200 Date: Sat, 28 Feb 2026 12:31:51 -0500 Message-ID: <20260228173244.1509663-799-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Nelson-Moore [ Upstream commit d03e094473ecdeb68d853752ba467abe13e1de44 ] The ID 8086:104f is matched by both i40e and ipw2200. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. Fix this by taking advantage of the fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200 devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices. Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards") Cc: stable@vger.kernel.org Acked-by: Johannes Berg Signed-off-by: Ethan Nelson-Moore Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/20260210021235.16315-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +++++++- drivers/net/wireless/intel/ipw2x00/ipw2200.c | 8 +++++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethe= rnet/intel/i40e/i40e_main.c index d3bc3207054f9..02de186dcc8f5 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -75,7 +75,13 @@ static const struct pci_device_id i40e_pci_tbl[] =3D { {PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T4), 0}, {PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T_BC), 0}, {PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_SFP), 0}, - {PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_B), 0}, + /* + * This ID conflicts with ipw2200, but the devices can be differentiated + * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200 + * devices use PCI_CLASS_NETWORK_OTHER. + */ + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_10G_B), + PCI_CLASS_NETWORK_ETHERNET << 8, 0xffff00, 0}, {PCI_VDEVICE(INTEL, I40E_DEV_ID_KX_X722), 0}, {PCI_VDEVICE(INTEL, I40E_DEV_ID_QSFP_X722), 0}, {PCI_VDEVICE(INTEL, I40E_DEV_ID_SFP_X722), 0}, diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wir= eless/intel/ipw2x00/ipw2200.c index 09035a77e775f..b0e769da94156 100644 --- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c +++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c @@ -11387,7 +11387,13 @@ static const struct pci_device_id card_ids[] =3D { {PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2754, 0, 0, 0}, {PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2761, 0, 0, 0}, {PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2762, 0, 0, 0}, - {PCI_VDEVICE(INTEL, 0x104f), 0}, + /* + * This ID conflicts with i40e, but the devices can be differentiated + * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200 + * devices use PCI_CLASS_NETWORK_OTHER. + */ + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x104f), + PCI_CLASS_NETWORK_OTHER << 8, 0xffff00, 0}, {PCI_VDEVICE(INTEL, 0x4220), 0}, /* BG */ {PCI_VDEVICE(INTEL, 0x4221), 0}, /* BG */ {PCI_VDEVICE(INTEL, 0x4223), 0}, /* ABG */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 71F1F4209A1; Sat, 28 Feb 2026 17:46:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300768; cv=none; b=oXYDwsvlYYEIGvP3dxO6QHNo/JW4qBaSP6tChvSqwVTlwdp7w4ffOULIRTBCtZB2DAF8xqoQkj7sT33ftyllNdUhF0iPwp2pAKV5rtmXaHZbAIteugkn83fczzBkRlFlrO0+LVIQoqOYZlQqAWqPH9mzOEqCs3kpZoAiUQ8U/pg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300768; c=relaxed/simple; bh=DjEEaLP6mBKwe3/JXcQr75wphCCvX2O5/yn3K2hrHDc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YhWjxKTVhOwdT3EbUkN3hniU/luZN0I7D/1AnAxkPZoi054oysUZLW2xX21Tull9i933perbu+ZAJnnbTT8pCVnqF039ngRKffmc1BUoCbTTlU5MJeExmV7VHLTvThHT2HPDCJzOI48rnr/QSH0E5NqQpYSSPprYwJA2I+8Fp4E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZgDpzg28; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZgDpzg28" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6194AC19423; Sat, 28 Feb 2026 17:46:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300768; bh=DjEEaLP6mBKwe3/JXcQr75wphCCvX2O5/yn3K2hrHDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZgDpzg28rh0sB5LbZuMII/somyvmjJcZwWvPMQv2sO0nqhrg24Mb2RNDhto0XxNVV v3/8Ly3oFZodB90PovgPU/I13yd0hL4oRfHibBx/bhaQvdX8Qi9dd5R/n8rz++dRt5 K1T6vjStNjPDC3WBBjH4m/nCjytfEn+0ftoFgWFQkCccuoWWYVJkg6Lm2UovDZoNlF oL7D7jNi31qc5t8pGhDgsY04btFk1VqHlVZZ4AHdDFYyya9WevNwwoNlzlmW+jQLkc XW2+Oi63wyidyyZ2hUfFxAjbJNSSEjZ50YN8Hd9LAlDt6g4AXwPn40qwxNfhM+omor MJ8PO1BaJRUOw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Duoming Zhou , stable@kernel.org, Jijie Shao , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 799/844] atm: fore200e: fix use-after-free in tasklets during device removal Date: Sat, 28 Feb 2026 12:31:52 -0500 Message-ID: <20260228173244.1509663-800-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Duoming Zhou [ Upstream commit 8930878101cd40063888a68af73b1b0f8b6c79bc ] When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@kernel.org Suggested-by: Jijie Shao Signed-off-by: Duoming Zhou Reviewed-by: Jijie Shao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260210094537.9767-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/atm/fore200e.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c index f62e385714403..fec081db36dc4 100644 --- a/drivers/atm/fore200e.c +++ b/drivers/atm/fore200e.c @@ -373,6 +373,10 @@ fore200e_shutdown(struct fore200e* fore200e) fallthrough; case FORE200E_STATE_IRQ: free_irq(fore200e->irq, fore200e->atm_dev); +#ifdef FORE200E_USE_TASKLET + tasklet_kill(&fore200e->tx_tasklet); + tasklet_kill(&fore200e->rx_tasklet); +#endif =20 fallthrough; case FORE200E_STATE_ALLOC_BUF: --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E8E84209B6; Sat, 28 Feb 2026 17:46:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300769; cv=none; b=YtFXj5HKG71OHgtrSO7DZW3bcnCu+G7EflDeKOFGOhUNkOstUQZ78zAggtcSS6uKJOqCHZ3IqZyj6yxLtZZXFdSfrFA42KehcTgcl87LqzwM/AGlYJi02gyd5+dyfzsDTLs4DIgAJEoBsjJYC7XF9xv8aAV28hlpFF0KXbWl/uE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300769; c=relaxed/simple; bh=kUE4WSTKMv+JLxw/HZxQybOAqh2nTAx9uk2KXDrhArE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=at7yUk23kcjDHNCO/J6xCvjKuB7pAFWKN54j4siwtYXFn9NhcV8epL2ZDuBjsxgR4jTsw8YBu083xi02KkexOnXFUeOUHePTvmhZzSAZDaZZeuEEjTWCE///6ERP+1O83BWjLHGOB/QSsoKhHZ+F8IVzB83u3Cbf/kuMWHRcrZY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G71gpomC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="G71gpomC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8995CC19424; Sat, 28 Feb 2026 17:46:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300769; bh=kUE4WSTKMv+JLxw/HZxQybOAqh2nTAx9uk2KXDrhArE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G71gpomCMDAPmEpytgbyG+DV8Hq3YiTZWM6lJOArJmNpOvfyD5BAXiVTF5oKCUbeQ btpiM+glMrIeYBp6nGL4j2FhKa26qApoAiWzelw215ebGZgnCwTv+vfgQBtFibYw9t QP+K9hu+7VxpBRrWzUTJKSF00TGq0ryLAQNqhqLJ563GqYKSL2+RlnkNZq3l+IYyEu VLm1dvB/TdqgbGRrlXdseQrmQvLVkTWIfWFlvzmSOB0VO1Zt3PT3o9XyvaEjgjE2pg JJwPfi8CvxfHbNY3ueurtxi0WTK/DkmAbW06bIFk+pwPmL/7k32VR3rW4E6tN2j89S q2AZhzDEvn88Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shengming Hu , "Steven Rostedt (Google)" , Sasha Levin Subject: [PATCH 6.19 800/844] function_graph: Restore direct mode when callbacks drop to one Date: Sat, 28 Feb 2026 12:31:53 -0500 Message-ID: <20260228173244.1509663-801-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shengming Hu [ Upstream commit 53b2fae90ff01fede6520ca744ed5e8e366497ba ] When registering a second fgraph callback, direct path is disabled and array loop is used instead. When ftrace_graph_active falls back to one, we try to re-enable direct mode via ftrace_graph_enable_direct(true, ...). But ftrace_graph_enable_direct() incorrectly disables the static key rather than enabling it. This leaves fgraph_do_direct permanently off after first multi-callback transition, so direct fast mode is never restored. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260213142932519cuWSpEXeS4-UnCvNXnK2P@zte.c= om.cn Fixes: cc60ee813b503 ("function_graph: Use static_call and branch to optimi= ze entry function") Signed-off-by: Shengming Hu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/trace/fgraph.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c index cc48d16be43e0..4df766c690f92 100644 --- a/kernel/trace/fgraph.c +++ b/kernel/trace/fgraph.c @@ -1303,7 +1303,7 @@ static void ftrace_graph_enable_direct(bool enable_br= anch, struct fgraph_ops *go static_call_update(fgraph_func, func); static_call_update(fgraph_retfunc, retfunc); if (enable_branch) - static_branch_disable(&fgraph_do_direct); + static_branch_enable(&fgraph_do_direct); } =20 static void ftrace_graph_disable_direct(bool disable_branch) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 85042421230; Sat, 28 Feb 2026 17:46:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300770; cv=none; b=WRgPDzvBNj3CRy8fs2cMuvHWziIbF/cdGB/o4lzYnrx5xHhY8dlhhS7AV1WfTvKuDLm941MdpG+d/jvQZzor/W9OtDj34HsNtgH0xAxcPoo2RC6VwzGfj/dMZ2WvrozU3f2GE5x3jHxqSToIMlgolF0zWr9NGQ7WJjoRODj+JX4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300770; c=relaxed/simple; bh=coOCPQaLt3/lxoVZ3zWsfYGpDvAz1Ila6eSME24QlyQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nIDMXj7hvlPubEKsVqXD3ETOlHUt5iHIdweJSLFRV6mIvf7dqEwdrEfwMQJWWaBZPv2dQcWmt4A1NyzTmOqTgcI9s6a2/Q55FJmtjjrk4nkG4o3fg1DWYD7YRgqNrYyDhsDdjNJ9bK/mP3YhBEZ9Hy0jcIC15AXTLogKObUzmMs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IkpLLn8o; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IkpLLn8o" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 692B8C116D0; Sat, 28 Feb 2026 17:46:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300770; bh=coOCPQaLt3/lxoVZ3zWsfYGpDvAz1Ila6eSME24QlyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IkpLLn8oz4B9/MwEn/2snIv5Z1/Y2qygpOV1H9VlKBMYFF/4l0OuzT+gXjvfCi1Nm 8Ak0IwNUCtvKNtN+ztYx/od0hs/ORERIG/1tnWlUST39gJE25AxjQZ5m+iQ/vrf3pq Fn/Yvs1IPBrCYoh47lYsf8EzrHt8HeJ11NgEMPWDaVYGiJiensA1NEdqreozKqQMYN K4/uwa9KYaZteFRVaxv0rJiWvhO9Suc9Crwszy1myuJwrUE3vhfQQGEVLUVTsjrn/L Mamxed/uaEwKDvYWVUq/7G4P/Sn+RxNhH7SkTBlK9INGNVXltTxP0Vd4Yh8dWjwX5y 4ABWBv3Xn7Ynw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= , Nicolas Schier , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , Nathan Chancellor , Sasha Levin Subject: [PATCH 6.19 801/844] kbuild: Fix CC_CAN_LINK detection Date: Sat, 28 Feb 2026 12:31:54 -0500 Message-ID: <20260228173244.1509663-802-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Micka=C3=ABl Sala=C3=BCn [ Upstream commit be55899b71630c79ad01df54c92e467e47644f87 ] Most samples cannot be build on some environments because they depend on CC_CAN_LINK, which is set according to the result of scripts/cc-can-link.sh called by cc_can_link_user. Because cc-can-link.sh must now build without warning, it may fail because it is calling printf() with an empty string: + cat + gcc -m32 -Werror -Wl,--fatal-warnings -x c - -o /dev/null : In function =E2=80=98main=E2=80=99: :4:9: error: zero-length gnu_printf format string [-Werror=3Dforma= t-zero-length] cc1: all warnings being treated as errors Fix this warning and the samples build by actually printing something. Cc: stable@vger.kernel.org Fixes: d81d9d389b9b ("kbuild: don't enable CC_CAN_LINK if the dummy program= generates warnings") Signed-off-by: Micka=C3=ABl Sala=C3=BCn Reviewed-by: Nicolas Schier Reviewed-by: Thomas Wei=C3=9Fschuh Link: https://patch.msgid.link/20260212133544.1331437-1-mic@digikod.net Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- scripts/cc-can-link.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/cc-can-link.sh b/scripts/cc-can-link.sh index e67fd8d7b6841..58dc7dd6d5568 100755 --- a/scripts/cc-can-link.sh +++ b/scripts/cc-can-link.sh @@ -5,7 +5,7 @@ cat << "END" | $@ -Werror -Wl,--fatal-warnings -x c - -o /d= ev/null >/dev/null 2> #include int main(void) { - printf(""); + printf("\n"); return 0; } END --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C40A42124D; Sat, 28 Feb 2026 17:46:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300771; cv=none; b=fUOFoWdfmhnbYE2KgW52RRP/UNanaj4IHVwkIvagLYdfy+8ng1lGzzNnsfQ16zZkpcwSNkXUjEWiCkTMq91aB5J8zyE+LJFx2larCC6DVZ48QoO3Tv/33axVrZAnRbGJpNn9wLNUumDKgKf/wBygW9pt04p27MRjJ9i9XqMsp6I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300771; c=relaxed/simple; bh=9c42ecIz9hQ9+pcNEMXWiBZo4N95fyeynxQzrsL/Tg0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G0tmyBgP7aNaBSZrVAfpiga1A84H6r29mhvQOvlhmJw2mdSs6D8HflX8Xd9VTR+iSvE3uhb7hpCvh9xc6b9ZDrZuLAXd/xmb5lkG/vmqtFBvqDjVJPpLmjDmR3mM7ET8PfD13TQ3dpVIlgkDnOEEW7EFtLhjymY8mrVv+5ywzvs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bjvaEbBp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bjvaEbBp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8341EC2BC9E; Sat, 28 Feb 2026 17:46:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300771; bh=9c42ecIz9hQ9+pcNEMXWiBZo4N95fyeynxQzrsL/Tg0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bjvaEbBpq73vAaTB79HsJBPHugSpR4kai/NHpbkfpnlhUTm8oVNBsBcKeGDp4uqFz lSTKXX4XIdtLUN77l+CwQ6Qtcy9RLd0l7TKBTAVULHgdLtBFSFKw0HU6eVYJJiPGRu s/Z4sgb6xGplgU7hOg+7+6cff3v+lRX4XJxhIN+WXXl5hHxV5pv06JDgRw15rUTJgS 2fzQt3jscqIZFm2/iXkskq8pheGKiQVeS2dWLAQoHlSaxr7dda6itP6dGScyU95cb8 idSJiF/C+Txh7r1NcLrCHdUu3QJ8nqM9oGe/FXF6lrh4JUOZecV4NrABrGIhUKAQW9 G7UrJR/k9C1dA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nathan Chancellor , Steve French , Stefano Garzarella , Steve French , Juergen Gross , Nicolas Schier , Sasha Levin Subject: [PATCH 6.19 802/844] kbuild: rpm-pkg: Restrict manual debug package creation Date: Sat, 28 Feb 2026 12:31:55 -0500 Message-ID: <20260228173244.1509663-803-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nathan Chancellor [ Upstream commit 6d6b8b0e28c468263d7fcb071e5cb284ae343df2 ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") moved away from the built-in RPM machinery for generating -debuginfo packages to a more manual way to be compatible with module signing, as the built-in machinery strips the modules after the installation process, breaking the signatures. Unfortunately, prior to rpm 4.20.0, there is a bug where a custom %files directive is ignored for a -debuginfo subpackage [1], meaning builds using older versions of RPM (such as on RHEL9 or RHEL10) fail with: Checking for unpackaged file(s): /usr/lib/rpm/check-files .../rpmbuild/BU= ILDROOT/kernel-6.19.0_dirty-1.x86_64 error: Installed (but unpackaged) file(s) found: /debuginfo.list /usr/lib/debug/.build-id/09/748c214974bfba1522d434a7e0a02e2fd7f29b.deb= ug /usr/lib/debug/.build-id/0b/b96dd9c7d3689d82e56d2e73b46f53103cc6c7.deb= ug /usr/lib/debug/.build-id/0e/979a2f34967c7437fd30aabb41de1f0c8b6a66.deb= ug ... To workaround this, restrict the manual debug info package creation process to when it is necessary (CONFIG_MODULE_SIG=3Dy) and possible (when using RPM >=3D 4.20.0). A follow up change will restore the RPM debuginfo creation process using a separate internal flag to allow the package to be built in more situations, as RPM 4.20.0 is a fairly recent version and the built-in -debuginfo generation works fine when module signing is disabled. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Link: https://github.com/rpm-software-management/rpm/commit/49f906998f3cf1f= 4152162ca61ac0869251c380f [1] Reported-by: Steve French Closes: https://lore.kernel.org/CAH2r5mugbrHTwnaQwQiYEUVwbtqmvFYf0WZiLrrJWp= gT8iwftw@mail.gmail.com/ Tested-by: Stefano Garzarella Tested-by: Steve French Tested-by: Juergen Gross Acked-by: Nicolas Schier Link: https://patch.msgid.link/20260210-kbuild-fix-debuginfo-rpm-v1-1-0730b= 92b14bc@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- scripts/package/kernel.spec | 9 +++++---- scripts/package/mkspec | 33 ++++++++++++++++++++++++++++++--- 2 files changed, 35 insertions(+), 7 deletions(-) diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec index 0f1c8de1bd95f..b7deb159f404d 100644 --- a/scripts/package/kernel.spec +++ b/scripts/package/kernel.spec @@ -47,12 +47,13 @@ This package provides kernel headers and makefiles suff= icient to build modules against the %{version} kernel package. %endif =20 -%if %{with_debuginfo} +%if %{with_debuginfo_manual} %package debuginfo Summary: Debug information package for the Linux kernel %description debuginfo This package provides debug information for the kernel image and modules f= rom the %{version} package. +%define install_mod_strip 1 %endif =20 %prep @@ -67,7 +68,7 @@ patch -p1 < %{SOURCE2} mkdir -p %{buildroot}/lib/modules/%{KERNELRELEASE} cp $(%{make} %{makeflags} -s image_name) %{buildroot}/lib/modules/%{KERNEL= RELEASE}/vmlinuz # DEPMOD=3Dtrue makes depmod no-op. We do not package depmod-generated fil= es. -%{make} %{makeflags} INSTALL_MOD_PATH=3D%{buildroot} INSTALL_MOD_STRIP=3D1= DEPMOD=3Dtrue modules_install +%{make} %{makeflags} INSTALL_MOD_PATH=3D%{buildroot} %{?install_mod_strip:= INSTALL_MOD_STRIP=3D1} DEPMOD=3Dtrue modules_install %{make} %{makeflags} INSTALL_HDR_PATH=3D%{buildroot}/usr headers_install cp System.map %{buildroot}/lib/modules/%{KERNELRELEASE} cp .config %{buildroot}/lib/modules/%{KERNELRELEASE}/config @@ -98,7 +99,7 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/li= b/modules/%{KERNELRELEA echo "%exclude /lib/modules/%{KERNELRELEASE}/build" } > %{buildroot}/kernel.list =20 -%if %{with_debuginfo} +%if %{with_debuginfo_manual} # copying vmlinux directly to the debug directory means it will not get # stripped (but its source paths will still be collected + fixed up) mkdir -p %{buildroot}/usr/lib/debug/lib/modules/%{KERNELRELEASE} @@ -162,7 +163,7 @@ fi /lib/modules/%{KERNELRELEASE}/build %endif =20 -%if %{with_debuginfo} +%if %{with_debuginfo_manual} %files -f %{buildroot}/debuginfo.list debuginfo %defattr (-, root, root) %exclude /debuginfo.list diff --git a/scripts/package/mkspec b/scripts/package/mkspec index c7375bfc25a9a..1080395ca0e16 100755 --- a/scripts/package/mkspec +++ b/scripts/package/mkspec @@ -23,15 +23,42 @@ else echo '%define with_devel 0' fi =20 +# manually generate -debuginfo package +with_debuginfo_manual=3D0 # debuginfo package generation uses find-debuginfo.sh under the hood, # which only works on uncompressed modules that contain debuginfo if grep -q CONFIG_DEBUG_INFO=3Dy include/config/auto.conf && (! grep -q CONFIG_MODULE_COMPRESS=3Dy include/config/auto.conf) && (! grep -q CONFIG_DEBUG_INFO_SPLIT=3Dy include/config/auto.conf); then -echo '%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debugi= nfo: 1}' -else -echo '%define with_debuginfo 0' + # If module signing is enabled (which may be required to boot with + # lockdown enabled), the find-debuginfo.sh machinery cannot be used + # because the signatures will be stripped off the modules. However, due + # to an rpm bug in versions prior to 4.20.0 + # + # https://github.com/rpm-software-management/rpm/issues/3057 + # https://github.com/rpm-software-management/rpm/commit/49f906998f3cf= 1f4152162ca61ac0869251c380f + # + # We cannot provide our own debuginfo package because it does not listen + # to our custom files list, failing the build due to unpackaged files. + # Manually generate the debug info package if using rpm 4.20.0. If not + # using rpm 4.20.0, avoid generating a -debuginfo package altogether, + # as it is not safe. + if grep -q CONFIG_MODULE_SIG=3Dy include/config/auto.conf; then + rpm_ver_str=3D$(rpm --version 2>/dev/null) + # Split the version on spaces + IFS=3D' ' + set -- $rpm_ver_str + if [ "${1:-}" =3D RPM -a "${2:-}" =3D version ]; then + IFS=3D. + set -- $3 + rpm_ver=3D$(( 1000000 * $1 + 10000 * $2 + 100 * $3 + ${4:-0} )) + if [ "$rpm_ver" -ge 4200000 ]; then + with_debuginfo_manual=3D'%{?_without_debuginfo:0}%{?!_without_debuginf= o:1}' + fi + fi + fi fi +echo "%define with_debuginfo_manual $with_debuginfo_manual" =20 cat< To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nathan Chancellor , Stefano Garzarella , Steve French , Juergen Gross , Nicolas Schier , Sasha Levin Subject: [PATCH 6.19 803/844] kernel: rpm-pkg: Restore find-debuginfo.sh approach to -debuginfo package Date: Sat, 28 Feb 2026 12:31:56 -0500 Message-ID: <20260228173244.1509663-804-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nathan Chancellor [ Upstream commit ffe9ac1ad56df8f915896b97bd7645f522c47ce9 ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") effectively reverted commit a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") but the approach it took is not safe for older RPM releases. Restore commit a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") for the !CONFIG_MODULE_SIG case to allow more environments and configurations to take advantage of the separate debug information package process. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Tested-by: Stefano Garzarella Tested-by: Steve French Tested-by: Juergen Gross Acked-by: Nicolas Schier Link: https://patch.msgid.link/20260210-kbuild-fix-debuginfo-rpm-v1-2-0730b= 92b14bc@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- scripts/package/kernel.spec | 50 ++++++++++++++++++++++++++++++++++--- scripts/package/mkspec | 5 ++++ 2 files changed, 51 insertions(+), 4 deletions(-) diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec index b7deb159f404d..af682a7054779 100644 --- a/scripts/package/kernel.spec +++ b/scripts/package/kernel.spec @@ -2,8 +2,6 @@ %{!?_arch: %define _arch dummy} %{!?make: %define make make} %define makeflags %{?_smp_mflags} ARCH=3D%{ARCH} -%define __spec_install_post /usr/lib/rpm/brp-compress || : -%define debug_package %{nil} =20 Name: kernel Summary: The Linux Kernel @@ -56,6 +54,38 @@ This package provides debug information for the kernel i= mage and modules from th %define install_mod_strip 1 %endif =20 +%if %{with_debuginfo_rpm} +# list of debuginfo-related options taken from distribution kernel.spec +# files +%undefine _include_minidebuginfo +%undefine _find_debuginfo_dwz_opts +%undefine _unique_build_ids +%undefine _unique_debug_names +%undefine _unique_debug_srcs +%undefine _debugsource_packages +%undefine _debuginfo_subpackages +%global _find_debuginfo_opts -r +%global _missing_build_ids_terminate_build 1 +%global _no_recompute_build_ids 1 +%{debug_package} + +# later, we make all modules executable so that find-debuginfo.sh strips +# them up. but they don't actually need to be executable, so remove the +# executable bit, taking care to do it _after_ find-debuginfo.sh has run +%define __spec_install_post \ + %{?__debug_package:%{__debug_install_post}} \ + %{__arch_install_post} \ + %{__os_install_post} \ + find %{buildroot}/lib/modules/%{KERNELRELEASE} -name "*.ko" -type f \\\ + | xargs --no-run-if-empty chmod u-x +%else +%define __spec_install_post /usr/lib/rpm/brp-compress || : +%endif +# some (but not all) versions of rpmbuild emit %%debug_package with +# %%install. since we've already emitted it manually, that would cause +# a package redefinition error. ensure that doesn't happen +%define debug_package %{nil} + %prep %setup -q -n linux cp %{SOURCE1} .config @@ -99,14 +129,22 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}= /lib/modules/%{KERNELRELEA echo "%exclude /lib/modules/%{KERNELRELEASE}/build" } > %{buildroot}/kernel.list =20 -%if %{with_debuginfo_manual} +%if 0%{with_debuginfo_manual}%{with_debuginfo_rpm} > 0 # copying vmlinux directly to the debug directory means it will not get # stripped (but its source paths will still be collected + fixed up) mkdir -p %{buildroot}/usr/lib/debug/lib/modules/%{KERNELRELEASE} cp vmlinux %{buildroot}/usr/lib/debug/lib/modules/%{KERNELRELEASE} +%endif =20 -echo /usr/lib/debug/lib/modules/%{KERNELRELEASE}/vmlinux > %{buildroot}/de= buginfo.list +%if %{with_debuginfo_rpm} +# make modules executable so that find-debuginfo.sh strips them. this +# will be undone later in %%__spec_install_post +find %{buildroot}/lib/modules/%{KERNELRELEASE} -name "*.ko" -type f \ + | xargs --no-run-if-empty chmod u+x +%endif =20 +%if %{with_debuginfo_manual} +echo /usr/lib/debug/lib/modules/%{KERNELRELEASE}/vmlinux > %{buildroot}/de= buginfo.list while read -r mod; do mod=3D"${mod%.o}.ko" dbg=3D"%{buildroot}/usr/lib/debug/lib/modules/%{KERNELRELEASE}/kernel/${m= od}" @@ -124,6 +162,10 @@ done < modules.order =20 %clean rm -rf %{buildroot} +%if %{with_debuginfo_rpm} +rm -f debugfiles.list debuglinks.list debugsourcefiles.list debugsources.l= ist \ + elfbins.list +%endif =20 %post if [ -x /usr/bin/kernel-install ]; then diff --git a/scripts/package/mkspec b/scripts/package/mkspec index 1080395ca0e16..c604f8c174e2c 100755 --- a/scripts/package/mkspec +++ b/scripts/package/mkspec @@ -23,6 +23,8 @@ else echo '%define with_devel 0' fi =20 +# use %{debug_package} machinery to generate -debuginfo +with_debuginfo_rpm=3D0 # manually generate -debuginfo package with_debuginfo_manual=3D0 # debuginfo package generation uses find-debuginfo.sh under the hood, @@ -56,9 +58,12 @@ if grep -q CONFIG_DEBUG_INFO=3Dy include/config/auto.con= f && with_debuginfo_manual=3D'%{?_without_debuginfo:0}%{?!_without_debuginf= o:1}' fi fi + else + with_debuginfo_rpm=3D'%{?_without_debuginfo:0}%{?!_without_debuginfo:1}' fi fi echo "%define with_debuginfo_manual $with_debuginfo_manual" +echo "%define with_debuginfo_rpm $with_debuginfo_rpm" =20 cat< To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nathan Chancellor , Lukas Herbolt , Sasha Levin Subject: [PATCH 6.19 804/844] kbuild: rpm-pkg: Fix manual debuginfo generation when using .src.rpm Date: Sat, 28 Feb 2026 12:31:57 -0500 Message-ID: <20260228173244.1509663-805-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nathan Chancellor [ Upstream commit afdfb71c018e9a0aa2e51fb8186d3fb1acdd3f0e ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") added uses of OBJCOPY and READELF, variables from Kbuild. These variables are defined and work properly when using the binrpm-pkg target because rpmbuild is run within Kbuild. However, these variables are not defined when building from a source RPM package generated with the srcrpm-pkg target, breaking the build when generating the debug info subpackage. Define a default value for these variables so that these commands respect the value from Kbuild but continue to work when built from a source RPM package. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Reported-by: Lukas Herbolt Closes: https://lore.kernel.org/20260212135855.147906-2-lukas@herbolt.com/ Tested-by: Lukas Herbolt Link: https://patch.msgid.link/20260213-fix-debuginfo-srcrpm-pkg-v1-1-45cd0= c0501b9@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- scripts/package/kernel.spec | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec index af682a7054779..bccf58bdd45fd 100644 --- a/scripts/package/kernel.spec +++ b/scripts/package/kernel.spec @@ -148,11 +148,11 @@ echo /usr/lib/debug/lib/modules/%{KERNELRELEASE}/vmli= nux > %{buildroot}/debuginf while read -r mod; do mod=3D"${mod%.o}.ko" dbg=3D"%{buildroot}/usr/lib/debug/lib/modules/%{KERNELRELEASE}/kernel/${m= od}" - buildid=3D$("${READELF}" -n "${mod}" | sed -n 's@^.*Build ID: \(..\)\(.*\= )@\1/\2@p') + buildid=3D$("${READELF:-readelf}" -n "${mod}" | sed -n 's@^.*Build ID: \(= ..\)\(.*\)@\1/\2@p') link=3D"%{buildroot}/usr/lib/debug/.build-id/${buildid}.debug" =20 mkdir -p "${dbg%/*}" "${link%/*}" - "${OBJCOPY}" --only-keep-debug "${mod}" "${dbg}" + "${OBJCOPY:-objcopy}" --only-keep-debug "${mod}" "${dbg}" ln -sf --relative "${dbg}" "${link}" =20 echo "${dbg#%{buildroot}}" >> %{buildroot}/debuginfo.list --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C83E6422879; Sat, 28 Feb 2026 17:46:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300774; cv=none; b=NiAFeoR+Xt0sehoThzpfaFfkctSKsxh7ZXn8vnOjdUwJ03yc3+g+VtxbphqpY9gNkARkZ2RPXn966l2ZyP2/7mHEt0xFwsk8K3ixDwzpCEI7e9juEe74EJaG0Bt3G/kodLofv63B1tftjrQjfYwj5gVev+LoTAZyBA5gNz8z6N0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300774; c=relaxed/simple; bh=ZMGr9zlLKvUGwFobXcT97WA+X/+/KbFE5hJxL/qb/Cg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FUFtZlM9WpOVYHH+zUZPTjqBjsiW34DgfwtgLHQwj3LvkCv9eoHJgkDhXoNmgE9HATmVOelukjuSaAQwcgN955gyvr290dJh7q460t79uH54u4mPxTh1MuMA68/iOvulBBpmZIoUsw6qeXzegy1oYKLc9rrh6JgGm8hjouHgbto= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sUMLbQKm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sUMLbQKm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5CE4C2BCB0; Sat, 28 Feb 2026 17:46:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300774; bh=ZMGr9zlLKvUGwFobXcT97WA+X/+/KbFE5hJxL/qb/Cg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sUMLbQKmF2Dspuv2oF4uagzp/sQH9jBEyXxakUYRI93Br0PrthbcI/KtRr6mDEA7C 3mYrtfO3oayOSP+9NGPmdC4cL/cxb1KpdXSMXet9FvWHw3Yz2GDxQErwjCBYfBmbln NJ4HQQlXEYGTKvL+HBTbj+DqRJA5a9/ZUgMqsVAw9LVS1UPv1aD7L5qwC1xNtH2s7z pfCUsY3WkuQppgGBUH7jB/yhR32UXgTbZv30Scs68l4YTuysFVECuWwaej/RnL6upY ZvoBLYY666Q02Iy0FXNhanwWPkWRnHXGyfL0uWZU7NHLZA617HVJVT2hlRO8hfIMgd 0Tf1m3iXjxTgw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Qanux , Justin Iurman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 805/844] ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() Date: Sat, 28 Feb 2026 12:31:58 -0500 Message-ID: <20260228173244.1509663-806-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Qanux [ Upstream commit 6db8b56eed62baacaf37486e83378a72635c04cc ] On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=3D0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00). Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trac= e") Cc: stable@vger.kernel.org Signed-off-by: Junxi Qian Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260211040412.86195-1-qjx1298677004@gmail.c= om Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/net/ioam6.h | 2 ++ net/ipv6/exthdrs.c | 5 +++++ net/ipv6/ioam6.c | 14 ++++++++++++++ net/ipv6/ioam6_iptunnel.c | 10 +--------- 4 files changed, 22 insertions(+), 9 deletions(-) diff --git a/include/net/ioam6.h b/include/net/ioam6.h index 2cbbee6e806aa..a75912fe247e6 100644 --- a/include/net/ioam6.h +++ b/include/net/ioam6.h @@ -60,6 +60,8 @@ void ioam6_fill_trace_data(struct sk_buff *skb, struct ioam6_trace_hdr *trace, bool is_input); =20 +u8 ioam6_trace_compute_nodelen(u32 trace_type); + int ioam6_init(void); void ioam6_exit(void); =20 diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c index 54088fa0c09d0..310836a0cf17b 100644 --- a/net/ipv6/exthdrs.c +++ b/net/ipv6/exthdrs.c @@ -931,6 +931,11 @@ static bool ipv6_hop_ioam(struct sk_buff *skb, int opt= off) if (hdr->opt_len < 2 + sizeof(*trace) + trace->remlen * 4) goto drop; =20 + /* Inconsistent Pre-allocated Trace header */ + if (trace->nodelen !=3D + ioam6_trace_compute_nodelen(be32_to_cpu(trace->type_be32))) + goto drop; + /* Ignore if the IOAM namespace is unknown */ ns =3D ioam6_namespace(dev_net(skb->dev), trace->namespace_id); if (!ns) diff --git a/net/ipv6/ioam6.c b/net/ipv6/ioam6.c index 9553a32000813..08b7ac8c99b7e 100644 --- a/net/ipv6/ioam6.c +++ b/net/ipv6/ioam6.c @@ -690,6 +690,20 @@ struct ioam6_namespace *ioam6_namespace(struct net *ne= t, __be16 id) return rhashtable_lookup_fast(&nsdata->namespaces, &id, rht_ns_params); } =20 +#define IOAM6_MASK_SHORT_FIELDS 0xff1ffc00 +#define IOAM6_MASK_WIDE_FIELDS 0x00e00000 + +u8 ioam6_trace_compute_nodelen(u32 trace_type) +{ + u8 nodelen =3D hweight32(trace_type & IOAM6_MASK_SHORT_FIELDS) + * (sizeof(__be32) / 4); + + nodelen +=3D hweight32(trace_type & IOAM6_MASK_WIDE_FIELDS) + * (sizeof(__be64) / 4); + + return nodelen; +} + static void __ioam6_fill_trace_data(struct sk_buff *skb, struct ioam6_namespace *ns, struct ioam6_trace_hdr *trace, diff --git a/net/ipv6/ioam6_iptunnel.c b/net/ipv6/ioam6_iptunnel.c index 1fe7894f14dd9..b9f6d892a566c 100644 --- a/net/ipv6/ioam6_iptunnel.c +++ b/net/ipv6/ioam6_iptunnel.c @@ -22,9 +22,6 @@ #include #include =20 -#define IOAM6_MASK_SHORT_FIELDS 0xff100000 -#define IOAM6_MASK_WIDE_FIELDS 0xe00000 - struct ioam6_lwt_encap { struct ipv6_hopopt_hdr eh; u8 pad[2]; /* 2-octet padding for 4n-alignment */ @@ -93,13 +90,8 @@ static bool ioam6_validate_trace_hdr(struct ioam6_trace_= hdr *trace) trace->type.bit21 | trace->type.bit23) return false; =20 - trace->nodelen =3D 0; fields =3D be32_to_cpu(trace->type_be32); - - trace->nodelen +=3D hweight32(fields & IOAM6_MASK_SHORT_FIELDS) - * (sizeof(__be32) / 4); - trace->nodelen +=3D hweight32(fields & IOAM6_MASK_WIDE_FIELDS) - * (sizeof(__be64) / 4); + trace->nodelen =3D ioam6_trace_compute_nodelen(fields); =20 return true; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D93C48C409; Sat, 28 Feb 2026 17:46:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300776; cv=none; b=OLYfR25pB+ALy1mmxvm7rhOfRpY4yF+ro4x4wI5MNM/gjUzFZHuZ3N9jXRIR6NSe598bh2UCXmGvCfs85T7Oh9cwOFFBY1GX8YGeadVYQIdGBQNlgOHDJhAOKqpg7Vtny47J+cEwrqSFtuRHKxg6FVXMBROoih/qABHVjHJ3LRE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300776; c=relaxed/simple; bh=JjtGG2n/yeEkZ8iqF8FTMNX/ar1yKwTPTMTVOqLlhzg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kOXI/W81DLFTvEzjxKNjR0PNtevjKX8/UZ5U8761fbt2mpdNDwig3hbGm2nSNcnhDn3r+3aaAx1Ja+Kd9whEYnQfY6lgN8Gywx+Xoiv5My9xSiKV7EZgjXt40ogz4Z6tvfMEt9tGglmR2AuGK+Oljhhd8Gzm30kCj2Ac1BFH6UU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eKQ6NWJv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eKQ6NWJv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7170C19423; Sat, 28 Feb 2026 17:46:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300775; bh=JjtGG2n/yeEkZ8iqF8FTMNX/ar1yKwTPTMTVOqLlhzg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eKQ6NWJvzuN/tf2Uvwsguy+oVWOhFEDH2JpwWOkcfnIjy/CcD4iKWY+4H4cvbMqAj qZcrGNmbUniqULiqzRGKdTrjEep7w2jJ729E33y97fjYm45g3/QrPRqr3tEkmy/m5b 1YQf0Ih2BqVHe0F7dCQtvM/xy6LWOYfa/FxcmkhRkccZihOxFMBXAk0ehcZWcxqxEu WNgUtMYJUEKIsjTQ0d9DVeVe9ilM5i1igyn1+8EBzaziOEReDKWtvaxD20UT7u+rUm FXLAN1tsUHaR4JNO+ujvA2YxD3OlYYRdM2txGVqhVlSmxa+IYNTIrqADfKBbA3HrB9 jGr1Eelh+E9yA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Cui Chao , Jonathan Cameron , Gregory Price , Dan Williams , "Mike Rapoport (Microsoft)" , Sasha Levin Subject: [PATCH 6.19 806/844] mm: numa_memblks: Identify the accurate NUMA ID of CFMW Date: Sat, 28 Feb 2026 12:31:59 -0500 Message-ID: <20260228173244.1509663-807-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Cui Chao [ Upstream commit f043a93fff9e3e3e648b6525483f59104b0819fa ] In some physical memory layout designs, the address space of CFMW (CXL Fixed Memory Window) resides between multiple segments of system memory belonging to the same NUMA node. In numa_cleanup_meminfo, these multiple segments of system memory are merged into a larger numa_memblk. When identifying which NUMA node the CFMW belongs to, it may be incorrectly assigned to the NUMA node of the merged system memory. When a CXL RAM region is created in userspace, the memory capacity of the newly created region is not added to the CFMW-dedicated NUMA node. Instead, it is accumulated into an existing NUMA node (e.g., NUMA0 containing RAM). This makes it impossible to clearly distinguish between the two types of memory, which may affect memory-tiering applications. Example memory layout: Physical address space: 0x00000000 - 0x1FFFFFFF System RAM (node0) 0x20000000 - 0x2FFFFFFF CXL CFMW (node2) 0x40000000 - 0x5FFFFFFF System RAM (node0) 0x60000000 - 0x7FFFFFFF System RAM (node1) After numa_cleanup_meminfo, the two node0 segments are merged into one: 0x00000000 - 0x5FFFFFFF System RAM (node0) // CFMW is inside the range 0x60000000 - 0x7FFFFFFF System RAM (node1) So the CFMW (0x20000000-0x2FFFFFFF) will be incorrectly assigned to node0. To address this scenario, accurately identifying the correct NUMA node can be achieved by checking whether the region belongs to both numa_meminfo and numa_reserved_meminfo. While this issue is only observed in a QEMU configuration, and no known end users are impacted by this problem, it is likely that some firmware implementation is leaving memory map holes in a CXL Fixed Memory Window. CXL hotplug depends on mapping free window capacity, and it seems to be only a coincidence to have not hit this problem yet. Fixes: 779dd20cfb56 ("cxl/region: Add region creation support") Signed-off-by: Cui Chao Cc: stable@vger.kernel.org Reviewed-by: Jonathan Cameron Reviewed-by: Gregory Price Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260213060347.2389818-2-cuichao1753@phytium= .com.cn Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- mm/numa_memblks.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c index 8f5735fda0a21..3f53464240e8d 100644 --- a/mm/numa_memblks.c +++ b/mm/numa_memblks.c @@ -570,15 +570,16 @@ static int meminfo_to_nid(struct numa_meminfo *mi, u6= 4 start) int phys_to_target_node(u64 start) { int nid =3D meminfo_to_nid(&numa_meminfo, start); + int reserved_nid =3D meminfo_to_nid(&numa_reserved_meminfo, start); =20 /* - * Prefer online nodes, but if reserved memory might be - * hot-added continue the search with reserved ranges. + * Prefer online nodes unless the address is also described + * by reserved ranges, in which case use the reserved nid. */ - if (nid !=3D NUMA_NO_NODE) + if (nid !=3D NUMA_NO_NODE && reserved_nid =3D=3D NUMA_NO_NODE) return nid; =20 - return meminfo_to_nid(&numa_reserved_meminfo, start); + return reserved_nid; } EXPORT_SYMBOL_GPL(phys_to_target_node); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA859423573; Sat, 28 Feb 2026 17:46:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300776; cv=none; b=g6RvbWh4+jIyui0I61eq3JKnDzHG2pdLZU/fYgp0i7kJF29fUt4SE/RXwJQABQmxi5NjzvHudPTP2qwghq5+C9sRG1CwjzkXGGoXdT7TO4tbVbqh4JeZ6JEkeidrj26O6AM74T9ICc03XGf/fxF1L77r4sVz/OrbG3tjkwgF66Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300776; c=relaxed/simple; bh=D22sXEeJMslmAAsbB8Dliwp+gkAeNSn++Ovxt/kE01Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bjmU2cqNZC3NqQBevN7o9IBdYPc4D8gBRTg1Q7Xm9lAl/RTOE4EtagbM4xFj+hXGsVKpqIFODwbEQIp1BRm8uE+zZ+o7tSXq/WthCKeWPeVA9l1DBu6rYLyil11MdAKmS6znaJydK+yujfwShSGWuZbegoTNiJjkCZ8QFrSd9XA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CUtJrKE+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CUtJrKE+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CB0BC116D0; Sat, 28 Feb 2026 17:46:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300776; bh=D22sXEeJMslmAAsbB8Dliwp+gkAeNSn++Ovxt/kE01Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CUtJrKE+98p4spnXgAAO5ukXYlN4SanPrPp1F6ezrqMj3vtdem6lEh8dAx8E4R2bC fhYzI69/tLGy1DMMOwdlNYB+q21/OWT7ylEAg6xkW9cftNZwyz6uTcoDY4lC5Ul4FK fFSRa5QcntePxhgJAa5KmjGMT7/PeQ38YxNlclRjrdAiLpK46JLhLe58rwrH/IWyhF E74oSr34LjVxBPIGz1JG9YN3td2+H88sO3sPb2OQCPVa69NOFjEbUy8crI02tL+hZp vnk9902LAt1wcHLky0F3vu5N15yP+INPKuxC9GPPdwu//7XHiFfC8c6Kj9B0f4IiLn V/LJTojrPnRJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hans de Goede , Shixiong Ou , Helge Deller , Sasha Levin Subject: [PATCH 6.19 807/844] fbdev: Use device_create_with_groups() to fix sysfs groups registration race Date: Sat, 28 Feb 2026 12:32:00 -0500 Message-ID: <20260228173244.1509663-808-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hans de Goede [ Upstream commit 68eeb0871e986ae5462439dae881e3a27bcef85f ] The fbdev sysfs attributes are registered after sending the uevent for the device creation, leaving a race window where e.g. udev rules may not be able to access the sysfs attributes because the registration is not done yet. Fix this by switching to device_create_with_groups(). This also results in a nice cleanup. After switching to device_create_with_groups() all that is left of fb_init_device() is setting the drvdata and that can be passed to device_create[_with_groups]() too. After which fb_init_device() can be completely removed. Dropping fb_init_device() + fb_cleanup_device() in turn allows removing fb_info.class_flag as they were the only user of this field. Fixes: 5fc830d6aca1 ("fbdev: Register sysfs groups through device_add_group= ") Cc: stable@vger.kernel.org Cc: Shixiong Ou Signed-off-by: Hans de Goede Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/video/fbdev/core/fbsysfs.c | 36 +++--------------------------- include/linux/fb.h | 1 - 2 files changed, 3 insertions(+), 34 deletions(-) diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/= fbsysfs.c index b8344c40073b4..baa2bae0fb5b3 100644 --- a/drivers/video/fbdev/core/fbsysfs.c +++ b/drivers/video/fbdev/core/fbsysfs.c @@ -12,8 +12,6 @@ =20 #include "fb_internal.h" =20 -#define FB_SYSFS_FLAG_ATTR 1 - static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var) { int err; @@ -451,33 +449,7 @@ static struct attribute *fb_device_attrs[] =3D { NULL, }; =20 -static const struct attribute_group fb_device_attr_group =3D { - .attrs =3D fb_device_attrs, -}; - -static int fb_init_device(struct fb_info *fb_info) -{ - int ret; - - dev_set_drvdata(fb_info->dev, fb_info); - - fb_info->class_flag |=3D FB_SYSFS_FLAG_ATTR; - - ret =3D device_add_group(fb_info->dev, &fb_device_attr_group); - if (ret) - fb_info->class_flag &=3D ~FB_SYSFS_FLAG_ATTR; - - return 0; -} - -static void fb_cleanup_device(struct fb_info *fb_info) -{ - if (fb_info->class_flag & FB_SYSFS_FLAG_ATTR) { - device_remove_group(fb_info->dev, &fb_device_attr_group); - - fb_info->class_flag &=3D ~FB_SYSFS_FLAG_ATTR; - } -} +ATTRIBUTE_GROUPS(fb_device); =20 int fb_device_create(struct fb_info *fb_info) { @@ -485,14 +457,13 @@ int fb_device_create(struct fb_info *fb_info) dev_t devt =3D MKDEV(FB_MAJOR, node); int ret; =20 - fb_info->dev =3D device_create(fb_class, fb_info->device, devt, NULL, "fb= %d", node); + fb_info->dev =3D device_create_with_groups(fb_class, fb_info->device, dev= t, fb_info, + fb_device_groups, "fb%d", node); if (IS_ERR(fb_info->dev)) { /* Not fatal */ ret =3D PTR_ERR(fb_info->dev); pr_warn("Unable to create device for framebuffer %d; error %d\n", node, = ret); fb_info->dev =3D NULL; - } else { - fb_init_device(fb_info); } =20 return 0; @@ -505,7 +476,6 @@ void fb_device_destroy(struct fb_info *fb_info) if (!fb_info->dev) return; =20 - fb_cleanup_device(fb_info); device_destroy(fb_class, devt); fb_info->dev =3D NULL; } diff --git a/include/linux/fb.h b/include/linux/fb.h index 05cc251035da9..c3302d5135466 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -497,7 +497,6 @@ struct fb_info { #if defined(CONFIG_FB_DEVICE) struct device *dev; /* This is this fb device */ #endif - int class_flag; /* private sysfs flags */ #ifdef CONFIG_FB_TILEBLITTING struct fb_tile_ops *tileops; /* Tile Blitting */ #endif --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01063423590; Sat, 28 Feb 2026 17:46:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300778; cv=none; b=dNqpceYDv6MSOd/2MVPMlKH9ExuIzux7SxJy+D/16LUy0cXoxZaLQbunmL1J/ITnZjFhE6wGVvKtDZZMnCZ/8OZMp3g4ac88M/Uv3d5VjO6e7mlYrBKSAVY/gsG5l05XFJUC8hAjEgm5c1+ASl6BJfqAqOrq4OhLU9tVzbSFmAU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300778; c=relaxed/simple; bh=SgPq7xrhOcLQj6wkSLJcjM+Gd+ZOYudKrRPy5x5YVY8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RJVb2N2S2R/9yicnfNIYptP4+1BHKaWYcDmFwDzRVtE6G8pEeO1h7R/yu1rHPaweEdYxTmxyCbKlUUK+eeCN5/na01ii1iZKHQ3qlVcR/2rbyzzojBEh3rSHxitlg42oHbAgBVrCR9s92sbvUJ7ObByX0/hKEROrYgjrugj3eqQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Pr2yvlxd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Pr2yvlxd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12885C116D0; Sat, 28 Feb 2026 17:46:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300777; bh=SgPq7xrhOcLQj6wkSLJcjM+Gd+ZOYudKrRPy5x5YVY8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Pr2yvlxdk3unBMCkigwgRRNYPxICUnerVjFJCB/7+hXWJB9M1nLUIEeJ4M9kucCWf KGmrTSy7aIf0iUTOHJ39ruCXsbeAtp7QCjGHqHmT2csTkHcxYlDtTqGe9gUtSORxFQ B/9C399MUdM4nbzUKI1r9KvhPZrR4QfvrRC1W5D+8gVHl6y4SDp55sSKK6sZJxuoi1 hc+ZMrkcXECoyaj/mxwBIewklkfnxouB1EHOCROAY2UsCE/ylURPqGNIcHFZLy7fwr u7KRVlCU63oEJPHKMQp1yE5bImOrn7obSLv4GqAZV2KKSXES5hRk/eoQ3eCLROMvMq SMzMj3TLKoeGA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrey Vatoropin , Helge Deller , Sasha Levin Subject: [PATCH 6.19 808/844] fbcon: check return value of con2fb_acquire_newinfo() Date: Sat, 28 Feb 2026 12:32:01 -0500 Message-ID: <20260228173244.1509663-809-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrey Vatoropin [ Upstream commit 011a0502801c8536f64141a2b61362c14f456544 ] If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d1baa4ffa677 ("fbcon: set_con2fb_map fixes") Cc: stable@vger.kernel.org Signed-off-by: Andrey Vatoropin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/video/fbdev/core/fbcon.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fb= con.c index 7be9e865325d9..a07737dcb45ad 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -1068,7 +1068,8 @@ static void fbcon_init(struct vc_data *vc, bool init) return; =20 if (!info->fbcon_par) - con2fb_acquire_newinfo(vc, info, vc->vc_num); + if (con2fb_acquire_newinfo(vc, info, vc->vc_num)) + return; =20 /* If we are not the first console on this fb, copy the font from that console */ --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD55B4968FF; Sat, 28 Feb 2026 17:46:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300778; cv=none; b=ep5MshJ02Sk0qPuVe2mwE6SIbdNewB+ukyZ9s3jay75Rc9wVFr7ETe+6sWaJSOiJtTQFQ/ccvHCc7FWrqf4rl2XDXFo0Ih+xIcr3eH7qLEtvYOWhRWr1OMls87WckAh+lJrmaHroUzbTq17fnQVUfp463OJZ9QAxXCTp6dB1C68= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300778; c=relaxed/simple; bh=dKiC0icjXP1TlfS6TPltT1637LnsHXjHUdGIYuZnsoM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Kkbuzn2bWtLterXx0HDLRB60jgMcnJeqpVZt/9vleddz5q2oOCUj8UnqlDfCW/q0Bu/OhQeJxzkv+BFxYyoXE1EDtXmGPDYALEzDmAivfET5SyjlgKFbeUFJkBWurOHNP3/BGp18HOrq3TpRIb1dUAdQHfbtb4iSWiF8Bc/FYOY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y7vIzwTK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y7vIzwTK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E46DBC19423; Sat, 28 Feb 2026 17:46:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300778; bh=dKiC0icjXP1TlfS6TPltT1637LnsHXjHUdGIYuZnsoM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y7vIzwTKi9Rcfg/LwZBNOUdkwO1YPz7/vKq8LLvmRjh+4CQkExiWT+5KNprdy/g2A UUYClyq4EgD48wHon4k8/jCHZgjaUJO0RVbUIOQeswVNaNPPlmHb+UVdvC5eGkfPCF sxdFF8sDOyfJdrBriSt13NUjrsT0crLqwbcVOhz4gXEYKIFAs1Uscb54aSVFq/24eI 2Ke7kRV34O6Txwgzv5lOVx3/zabAi7DDBYLJXsfI6nE/KQ6/tZ2joTXedxje+c1jlP SnQ8zRfF473/nh14ArLXzYZKRuCdz4L5kjFJ1+LzeiLK996C6+TxCj/ekE3mjTbdUt EwDebFFYoKavQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Fourier , Helge Deller , Sasha Levin Subject: [PATCH 6.19 809/844] fbdev: vt8500lcdfb: fix missing dma_free_coherent() Date: Sat, 28 Feb 2026 12:32:02 -0500 Message-ID: <20260228173244.1509663-810-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Fourier [ Upstream commit 88b3b9924337336a31cefbe99a22ed09401be74a ] fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached. Fixes: e7b995371fe1 ("video: vt8500: Add devicetree support for vt8500-fb a= nd wm8505-fb") Cc: Signed-off-by: Thomas Fourier Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/video/fbdev/vt8500lcdfb.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/vt8500lcdfb.c b/drivers/video/fbdev/vt8500= lcdfb.c index b08a6fdc53fd2..85c7a99a7d648 100644 --- a/drivers/video/fbdev/vt8500lcdfb.c +++ b/drivers/video/fbdev/vt8500lcdfb.c @@ -369,7 +369,7 @@ static int vt8500lcd_probe(struct platform_device *pdev) if (fbi->palette_cpu =3D=3D NULL) { dev_err(&pdev->dev, "Failed to allocate palette buffer\n"); ret =3D -ENOMEM; - goto failed_free_io; + goto failed_free_mem_virt; } =20 irq =3D platform_get_irq(pdev, 0); @@ -432,6 +432,9 @@ static int vt8500lcd_probe(struct platform_device *pdev) failed_free_palette: dma_free_coherent(&pdev->dev, fbi->palette_size, fbi->palette_cpu, fbi->palette_phys); +failed_free_mem_virt: + dma_free_coherent(&pdev->dev, fbi->fb.fix.smem_len, + fbi->fb.screen_buffer, fbi->fb.fix.smem_start); failed_free_io: iounmap(fbi->regbase); failed_free_res: --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 754C9424331; Sat, 28 Feb 2026 17:46:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300779; cv=none; b=qAflvvClW5oSzlR0HSc+63ifN13Lh0urPNI+JX6kziTygUlVJ2yMIahUYzVjcLiczeK9z8ORWa+rhzJOULh5NkyVCi6rr5FzUU00vm0Tm0lHGNw2DyyIcUHTjr6pbA2Q3HeXU6ezyQYrg53hw1L9XDGn9J7D04qzAtE8RWajnPE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300779; c=relaxed/simple; bh=M8MWHRNU2U3V/ORthrQefka7sZGGqMMKX/UwrSEEr04=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qg2kymO7ZFjcqBtHnyg6tJDJLy9Hr8bxQjsIHUaRBFXPZ8v5D+hm/pK0y2Z7eXQ0oGf7OmwnAK8UN8eoGzzsbZPZFFv8pXfh7U25blEqmHVh1kG+RlWM6cw52cAvLMWlyBJRJwRAVEYCP8bTuyKj3U7UityyDmuzeQx92oCj9fE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Uft/8JNL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Uft/8JNL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1D0CC116D0; Sat, 28 Feb 2026 17:46:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300779; bh=M8MWHRNU2U3V/ORthrQefka7sZGGqMMKX/UwrSEEr04=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Uft/8JNLcimCPmle/E8K6YPVnxo6RP1hXDGjIzQnv8O4di0UjpHEDaHn+hIUMl8W5 uwcr3diQXcsIff5yaoTxbz1VTAp8pMZ63TVDnWpXJJDcf4J0XrU0g5evSjVCZfczaN V0SBVopKd5gO1FvnnC0fS1z2doJH/a167rNrlOjcOUVQRqQBf+t39u2vJfj15MIytn mcJnzUqASor/XQcYjPXrUWFS6YhNrj/GxDESdthdD/Hhrc/SekHYcBeeQpNsKEJlBK LYsSiGqNAcpwS00h1Qg0DWMnV6PyPLDeW33q1ybwcuNcE8erEeCVAkOxPbzRuSfuc9 jKogJ8hd6SiMg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Weigang He , Helge Deller , Sasha Levin Subject: [PATCH 6.19 810/844] fbdev: of: display_timing: fix refcount leak in of_get_display_timings() Date: Sat, 28 Feb 2026 12:32:03 -0500 Message-ID: <20260228173244.1509663-811-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Weigang He [ Upstream commit eacf9840ae1285a1ef47eb0ce16d786e542bd4d7 ] of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup. Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode") Cc: stable@vger.kernel.org Signed-off-by: Weigang He Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/video/of_display_timing.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_t= iming.c index a4cd446ac5a59..a6ec392253c3e 100644 --- a/drivers/video/of_display_timing.c +++ b/drivers/video/of_display_timing.c @@ -181,7 +181,7 @@ struct display_timings *of_get_display_timings(const st= ruct device_node *np) if (disp->num_timings =3D=3D 0) { /* should never happen, as entry was already found above */ pr_err("%pOF: no timings specified\n", np); - goto entryfail; + goto timingfail; } =20 disp->timings =3D kcalloc(disp->num_timings, @@ -189,7 +189,7 @@ struct display_timings *of_get_display_timings(const st= ruct device_node *np) GFP_KERNEL); if (!disp->timings) { pr_err("%pOF: could not allocate timings array\n", np); - goto entryfail; + goto timingfail; } =20 disp->num_timings =3D 0; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6769E42434F; Sat, 28 Feb 2026 17:46:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300780; cv=none; b=saaD26w4lSz+CXveRkxcJZWoeM4c/WUMscu2zmjEPTwFXiKuIL6bCWMPZaes+4+MX4cW1YoYUf+wmcD+T8MPHQM46FPgDmoLh0amvygfo73opSZbirAeuWr5rZ/h1iWX7LQGwr3wZuXbzJbau0qVOFTKvzzCvJ2RxEoryVfmAPM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300780; c=relaxed/simple; bh=V2tvp4dZtMlmn6CDDyghQpc2R+K7b9K7s10vy4//yF8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pAF1MKRY5Zw1K3OLN6ZQTAYeogch5RnZ7NjEdA8Uvp/xCWO54r9IMUavDbBsmVEDDt933pHKh3ymrg/PYcjfdaDWVtzZtJbf/S1/77ZSsMXMH3jTlmtkEKP8nuoslT9J4TmdLi9PjIjC54MoCa8H2LRuKIV9DtVGTfWicdFvRRI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sX+/hb9n; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sX+/hb9n" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BF81C19423; Sat, 28 Feb 2026 17:46:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300780; bh=V2tvp4dZtMlmn6CDDyghQpc2R+K7b9K7s10vy4//yF8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sX+/hb9nzcnOSLlowikUEGpdEL+PWz6lishRMXgYAv9qnOdra0jNSJUtocoQBiTj0 GrH3Cx/YCgmAKFCyYAVztiEzEFUf5i6eZHxTWxsJYh7z7h7T7h8sB8LC/vOnG2D0Ot KLHji79nqx4dkIIQ7Q4MEDKgZ7C44leRDdWkUhZWwG1p33l5mgQreCaUVLNz9Con0z EeSZm1Cl52D6vyssWTHJDiWqByJI7FcTAg+Y8PwKWk5anJbzIxq+1sDiZa+26HegME K8QKUjX8BQpvKJDegdV1lN8voGIf1RBjuFDMc4uK1sfQgnbOYSOQrwD0WLX+TMKjHJ 4iuL814MpgTnQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ren=C3=A9=20Rebe?= , stable@kernel.org, Helge Deller , Sasha Levin Subject: [PATCH 6.19 811/844] fbdev: ffb: fix corrupted video output on Sun FFB1 Date: Sat, 28 Feb 2026 12:32:04 -0500 Message-ID: <20260228173244.1509663-812-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ren=C3=A9 Rebe [ Upstream commit b28da0d092461ac239ff034a8ac3129320177ba3 ] Fix Sun FFB1 corrupted video out ([1] and [2]) by disabling overlay and initializing window mode to a known state. The issue never appeared on my FFB2+/vertical nor Elite3D/M6. It could also depend on the PROM version. /SUNW,ffb@1e,0: FFB at 000001fc00000000, type 11, DAC pnum[236c] rev[10] ma= nuf_rev[4] X (II) /dev/fb0: Detected FFB1, Z-buffer, Single-buffered. X (II) /dev/fb0: BT9068 (PAC1) ramdac detected (with normal cursor control) X (II) /dev/fb0: Detected Creator/Creator3D [1] https://www.instagram.com/p/DUTcSmSjSem/ [2] https://chaos.social/@ReneRebe/116023241660154102 Signed-off-by: Ren=C3=A9 Rebe Cc: stable@kernel.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/video/fbdev/ffb.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/ffb.c b/drivers/video/fbdev/ffb.c index 34b6abff9493e..da531b4cb4513 100644 --- a/drivers/video/fbdev/ffb.c +++ b/drivers/video/fbdev/ffb.c @@ -335,6 +335,9 @@ struct ffb_dac { }; =20 #define FFB_DAC_UCTRL 0x1001 /* User Control */ +#define FFB_DAC_UCTRL_OVENAB 0x00000008 /* Overlay Enable */ +#define FFB_DAC_UCTRL_WMODE 0x00000030 /* Window Mode */ +#define FFB_DAC_UCTRL_WM_COMB 0x00000000 /* Window Mode =3D Combined */ #define FFB_DAC_UCTRL_MANREV 0x00000f00 /* 4-bit Manufacturing Revision */ #define FFB_DAC_UCTRL_MANREV_SHIFT 8 #define FFB_DAC_TGEN 0x6000 /* Timing Generator */ @@ -425,7 +428,7 @@ static void ffb_switch_from_graph(struct ffb_par *par) { struct ffb_fbc __iomem *fbc =3D par->fbc; struct ffb_dac __iomem *dac =3D par->dac; - unsigned long flags; + unsigned long flags, uctrl; =20 spin_lock_irqsave(&par->lock, flags); FFBWait(par); @@ -450,6 +453,15 @@ static void ffb_switch_from_graph(struct ffb_par *par) upa_writel((FFB_DAC_CUR_CTRL_P0 | FFB_DAC_CUR_CTRL_P1), &dac->value2); =20 + /* Disable overlay and window modes. */ + upa_writel(FFB_DAC_UCTRL, &dac->type); + uctrl =3D upa_readl(&dac->value); + uctrl &=3D ~FFB_DAC_UCTRL_WMODE; + uctrl |=3D FFB_DAC_UCTRL_WM_COMB; + uctrl &=3D ~FFB_DAC_UCTRL_OVENAB; + upa_writel(FFB_DAC_UCTRL, &dac->type); + upa_writel(uctrl, &dac->value); + spin_unlock_irqrestore(&par->lock, flags); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 662B4424E41; Sat, 28 Feb 2026 17:46:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300781; cv=none; b=bMW+ViT/DkuP/LXs6Czqe7bvCM7jojecc0Cd/kSdaTZuNFDzIHqQ2xc0sB0I3glgYil9fD9Z33f57oqkb9gM++JPHDSf9L2Dyj01gcSRCJsHjzVHXQ1odVqdGw3YpyphrmNhajWB85w8kgyxxI8Wg60zYKh5bOeFuk1kOyON6qE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300781; c=relaxed/simple; bh=RzykjqbxI860RyMl76kUWU06jUsyYYPYyBd7OBFoEjU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OiP318rqkhv+Ai+l/oIPJkvszFpgcfVUadR/QJL/r4tjQgBzAFK8OxdSaDJirx31TbBKvgRXTBj9fqRNKMoTf8V9Y7bw3UELdLuK+UOjP8F4bXrqSG76U46r59W5Jb0dGHQXgnQLwEY5ZjwD9+1ddkDK4NdYCV1BRj1jqASFRHs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=df1LMhA9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="df1LMhA9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8ECE1C19423; Sat, 28 Feb 2026 17:46:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300781; bh=RzykjqbxI860RyMl76kUWU06jUsyYYPYyBd7OBFoEjU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=df1LMhA9lge7qC64QJ3mJSuEQfHOQ9jITxBdNMxYV+2cheM+Tm7Mvp3cufdj4h1vE QEEXadFFfwvIC+Zc5IHHo8Le9mD2zmHfWZHpA/DthT8H5rK6Hv0DUpEfpOF6IVpIoF n7qcoSGxQWrMN6THxuS76L6y8yuaFiiBw8B9e2SXH8mSIIk1wg/93PLD+IyvQiF4ya xTa999JIqtuKaeru9cZZ/3jUD/SUHXjPal1wW79PRI2r2lq7T97UDa7IoHoOUfiJpT 1wQVCJBQG1A7bdUP3yULB5VgFICKEjdzTq5kbQnWCB0zi8kXyW4NNHggcP1+fZ9Qa0 q3sY7ZT3FMwGw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Zimmermann , Helge Deller , Sasha Levin Subject: [PATCH 6.19 812/844] fbcon: Remove struct fbcon_display.inverse Date: Sat, 28 Feb 2026 12:32:05 -0500 Message-ID: <20260228173244.1509663-813-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Zimmermann [ Upstream commit 30baedeeeab524172abc0b58cb101e8df86b5be8 ] The field inverse in struct fbcon_display is unused. Remove it. Signed-off-by: Thomas Zimmermann Cc: # v6.0+ Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/video/fbdev/core/fbcon.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fb= con.h index 44ea4ae4bba0d..9cabafd2d91ca 100644 --- a/drivers/video/fbdev/core/fbcon.h +++ b/drivers/video/fbdev/core/fbcon.h @@ -30,7 +30,6 @@ struct fbcon_display { #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION u_short scrollmode; /* Scroll Method, use fb_scrollmode() = */ #endif - u_short inverse; /* !=3D 0 text black on white as defau= lt */ short yscroll; /* Hardware scrolling */ int vrows; /* number of virtual rows */ int cursor_shape; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 22094424E5C; Sat, 28 Feb 2026 17:46:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300782; cv=none; b=EsyzBRcIa9R02KNeNnTzMl06x76mhYsA+W72PnNX4uRCSR3u3qd8XMZEEI5vwx+OoZHNH1NkJrIdtc4e15kwNmsFKfZRUgIZdk3W+KQsA4AyA6RQYLwmhyPSihB5RcCihahDwMo+TT8IfISpv34F792HAQrYObud0SW5PWxbXp8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300782; c=relaxed/simple; bh=oTP09YI/Pkrs6Rd3W3Jt/xedViZH/Wz+wk5aZE2TSg4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DwSl1H7OYCL7YUgvZiQl/RkQe8H4Kuy5qZnpd4TVaes/EbKpSbOZ12nk36zGq5YqSYGQYkemZeWuAw2g0qvq8g6QUv+JA7TuM2f7qSMWG3pFOdN6/VZt2j/U6tACqbGst8UgdOKiZqE38blV/EWOe782KloSnzRz9wJ3hkTk9D0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N6JdFSCv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N6JdFSCv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 681C3C116D0; Sat, 28 Feb 2026 17:46:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300782; bh=oTP09YI/Pkrs6Rd3W3Jt/xedViZH/Wz+wk5aZE2TSg4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N6JdFSCvGlMKvHs/VbMubiM3WAAxgGxBgaLJtousV6dftfBOnUnYnLU4quV/9FMTE sN+PoKSzZLasEV5LN3/UpK7iPh8rW1nMdWczWGI5aNk36w+7CGNvKpQnidmU09MNHh RUo9i488/F2EqjVsGuST2NpqolGh3AncCceXP+3lXIiRbV4JdMmzm/2KUYz4Lmf5WK xfptG7NIltWURhrxUyGjAfGIK2v+8x/+JK1o7IBRQiRdOUD6+VOP+ycXU580AnJ0+S CQ9RsA8aH39xZWQIJ8+vk/k+HPfW8iq07uSAX8BONghkmJ77TkDdmFuI95e9hFK/UE qSat0q45vr9OA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Pavel Begunkov , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 813/844] io_uring/zcrx: fix sgtable leak on mapping failures Date: Sat, 28 Feb 2026 12:32:06 -0500 Message-ID: <20260228173244.1509663-814-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pavel Begunkov [ Upstream commit a983aae397767e9da931128ff2b5bf9066513ce3 ] In an unlikely case when io_populate_area_dma() fails, which could only happen on a PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA machine, io_zcrx_map_area() will have an initialised and not freed table. It was supposed to be cleaned up in the error path, but !is_mapped prevents that. Fixes: 439a98b972fbb ("io_uring/zcrx: deduplicate area mapping") Cc: stable@vger.kernel.org Reported-by: Jens Axboe Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/zcrx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c index 3d398283cf340..b133c85793c9c 100644 --- a/io_uring/zcrx.c +++ b/io_uring/zcrx.c @@ -288,6 +288,9 @@ static int io_zcrx_map_area(struct io_zcrx_ifq *ifq, st= ruct io_zcrx_area *area) } =20 ret =3D io_populate_area_dma(ifq, area); + if (ret && !area->mem.is_dmabuf) + dma_unmap_sgtable(ifq->dev, &area->mem.page_sg_table, + DMA_FROM_DEVICE, IO_DMA_ATTR); if (ret =3D=3D 0) area->is_mapped =3D true; return ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00C75424E78; Sat, 28 Feb 2026 17:46:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300783; cv=none; b=d00Pvj+wrui8E0ioLwFYCm86qvLcA7CK510gBs257xVSMwwm7lCNJKX0lnwllPKIJgpUywbEORnMHRi7wH1FVcTr2DQ8T72mHtvX6GopDUX7zdTX2UCq0Wg55kRBH+bdxKVqWYrg8HDNCYPVlcJu3dhxDMcQ0d/xbAaBKJRt5pI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300783; c=relaxed/simple; bh=uHYavhVPPsvJNwy5w2zPvNAhQLb38Qw9M/j+w5Q7EOo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cbqruoOSDoPf1RfAUHH0/I5co/Mnzwpa2LlYCWmQEQwSeqGRJVJ5xN/JcdhZkrTUmVqXthiirMyKo4wolyBhTMgnSQV8cbyucZLDdf/vI97/P7ktpbqmtbORbdGx1ICj54NtVjGf+wTqEKSoYbwg7C3oXzOlJDG2AHidpX5vFj0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RT2O0sxh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RT2O0sxh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49C21C19423; Sat, 28 Feb 2026 17:46:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300782; bh=uHYavhVPPsvJNwy5w2zPvNAhQLb38Qw9M/j+w5Q7EOo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RT2O0sxhVND+7T/SXLXsJUlZgTrLd83BfDeX1tu/lPLKU0xRxCv3Lh6a1yXd5IBWe dYoU5S5HbXw+c15FQOxMoiwLAFP5XYktR6gpU0T/M+zAlqzDOKnsSe8F+b+KR88DMH rZtp4OrcVco0Co7IEuJ5TVGqX1Bj0Tk8eB6Zpd6Viobbt/2Anahv5p3Nj4ng9AGMlF /zQZsqjz3IF7rBZrzgQ0DgTn+s4P0hrTn6e6ZWxlP+o7ssy6SHbdmzOyp2VG6oUjMN 6J2BPoILvl0o74H0Han0s4lIdFL1xBcVV7ns7hPT5lob6qnNMCmAAXpRHNi9Ru+X6I PKsqeMC7LfqRw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Pavel Begunkov , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 814/844] io_uring/zcrx: fix post open error handling Date: Sat, 28 Feb 2026 12:32:07 -0500 Message-ID: <20260228173244.1509663-815-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pavel Begunkov [ Upstream commit 5d540e4508950c674d6feef1d95463d039bbf4f5 ] Closing a queue doesn't guarantee that all associated page pools are terminated right away, let the refcounting do the work instead of releasing the zcrx ctx directly. Cc: stable@vger.kernel.org Fixes: e0793de24a9f6 ("io_uring/zcrx: set pp memory provider for an rx queu= e") Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/zcrx.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c index b133c85793c9c..84e37900c0682 100644 --- a/io_uring/zcrx.c +++ b/io_uring/zcrx.c @@ -515,9 +515,6 @@ static void io_close_queue(struct io_zcrx_ifq *ifq) .mp_priv =3D ifq, }; =20 - if (ifq->if_rxq =3D=3D -1) - return; - scoped_guard(mutex, &ifq->pp_lock) { netdev =3D ifq->netdev; netdev_tracker =3D ifq->netdev_tracker; @@ -525,7 +522,8 @@ static void io_close_queue(struct io_zcrx_ifq *ifq) } =20 if (netdev) { - net_mp_close_rxq(netdev, ifq->if_rxq, &p); + if (ifq->if_rxq !=3D -1) + net_mp_close_rxq(netdev, ifq->if_rxq, &p); netdev_put(netdev, &netdev_tracker); } ifq->if_rxq =3D -1; @@ -833,13 +831,12 @@ int io_register_zcrx_ifq(struct io_ring_ctx *ctx, } return 0; netdev_put_unlock: - netdev_put(ifq->netdev, &ifq->netdev_tracker); netdev_unlock(ifq->netdev); err: scoped_guard(mutex, &ctx->mmap_lock) xa_erase(&ctx->zcrx_ctxs, id); ifq_free: - io_zcrx_ifq_free(ifq); + zcrx_unregister(ifq); return ret; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE5E936784B; Sat, 28 Feb 2026 17:46:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300783; cv=none; b=Q6yQFOWsZGVipWgnsVZmtzcCRdmxtuWYavpougUNb4isvN3iagn9s5KnFACmoFWz0z6PHo78B8d4XucrhotW6pZjKKBmC+cBc2W3uaYoIXlJkrm+FaffKy/35PzNfMVXTwdHWVhCJOywdr43vgPn4Mq2qdUh/Tuv6Op5zqGh//g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300783; c=relaxed/simple; bh=JB0I4pQvCKHiqn6le86sQBGFZc/z/XZ4cik2Xy2pCC0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YSMt1GQ5x3MaY7jpIoEpfglTCBJahjclyoe87+oQGDcUzjOqg0QZjsfD57ZCqJso+6RHbk8NBzKJQcb393IOAg5vbDrS46QacAsBtLilC6kZAdPmB5X88dlZgFKt6IFfmY5qWXTYeP+hEwgp7/FcmNde/pF8HvqEhopEAvFnLIk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IhMPZS2T; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IhMPZS2T" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 262FDC2BC87; Sat, 28 Feb 2026 17:46:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300783; bh=JB0I4pQvCKHiqn6le86sQBGFZc/z/XZ4cik2Xy2pCC0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IhMPZS2TsaiYnZaW/TiYVJVeT76so0nXFo3QT0RZIkdZ+CdKYVPG+R56kdjpuXNGo mNKZ7fX5SZ1ONSJq7mEWAxheCcNNHjlhbAFZlsazCa+tWS0CiEMdhFgZL6Sz0PADmH Pv9le2Uxmg6mOfdNHVqNNH7ThnPx/7lRV1jf+ySn6JyvBMl0hwqGX8CohLP0tyvtes n/fz7LPks3YjN8SgOKvuYjbwxB3x6JFyT1c7Ot/9rZ1JnU1H3vdf638IjXfTPbRx2T xys4cJHvEDNtG0BNVENs5VHs4nEPZrj6+LTQ8kzOulF/zSNZixgFl5WbPlIDdaqbd+ GvnW0ntHF8lrw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Pavel Begunkov , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 815/844] io_uring/zcrx: check unsupported flags on import Date: Sat, 28 Feb 2026 12:32:08 -0500 Message-ID: <20260228173244.1509663-816-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pavel Begunkov [ Upstream commit 7496e658a76a61758b20e27cea8abcfeafe3aec4 ] The imoorted zcrx registration path checks for ZCRX_REG_IMPORT, as it should, but doesn't reject any unsupported flags. Fix that. Cc: stable@vger.kernel.org Fixes: 00d91481279fb ("io_uring/zcrx: share an ifq between rings") Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/zcrx.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c index 84e37900c0682..d41aa01a26d31 100644 --- a/io_uring/zcrx.c +++ b/io_uring/zcrx.c @@ -677,6 +677,8 @@ static int import_zcrx(struct io_ring_ctx *ctx, return -EINVAL; if (reg->if_rxq || reg->rq_entries || reg->area_ptr || reg->region_ptr) return -EINVAL; + if (reg->flags & ~ZCRX_REG_IMPORT) + return -EINVAL; =20 fd =3D reg->if_idx; CLASS(fd, f)(fd); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 160AA367872; Sat, 28 Feb 2026 17:46:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300785; cv=none; b=VAYEx9mikAg0LTQECJ/3VXtciNlS+gkXHHUkU77+xL2uwJQ98c+cNWOYhdRGsCsyMzIY3pHBpyDEx/4uXY/0J014K1bOGkPyYhT2Jkb2t7JKwzjePqb3cxP2P/N4dFiQukUbWAAGapi187Cosk8BuTrcpD0Zxb/hg8mhZ6Tz/WA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300785; c=relaxed/simple; bh=pENoBtgTFyKqD8hX45iHf3pkkGxcMuELQ5ruuB6O5cU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CJVDqkd9+h8qIgphzHC6/Ed+39jHRJelYTV901lK/IQ5ILoPa7MzK0iBBNiDr3vyDju94whV6Cs8PhI6y1SYbe40bLeY9a/adQ1mdElGMVqO0UN/C88QIXrbMB/3rAZRPKeMolvaWZE5vjURMcrh+Bqh1YQewwTxZSajYEExXGU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z3UbOTT/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z3UbOTT/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 023E9C19425; Sat, 28 Feb 2026 17:46:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300784; bh=pENoBtgTFyKqD8hX45iHf3pkkGxcMuELQ5ruuB6O5cU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z3UbOTT/L7j+H8Cgjv7HeXhhsAu+wOGcgkiNVVHmDO4aLYCUm6cLlzp+e3uPGm/B4 bfwKwCPlCmbcvZQT+nzBu0zzpzI+FRhKGQ0yo609l0XJoSklsJHGrWaFx0fTzgNbc/ 1VIi5WmxUpfcs18q0c8sheO5kVCUgLMBDg/8CM2lXyQeFU6aJy0eOgKm4rmtpi9VUX MPnfEWqwEE3NRyVBWfRGqIbN078zlYDkpG/E6t5xs3B5OGmpfPMNkhdYE4is3XhNKo zQ1Cwi7MNTvUEX/oQSARQ8xXAtB3TdxluQrOXQjpurVrUNEM07gJFVJeYg01lr3Fel DcX+NVY+CQbpg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shyam Prasad N , Yuchan Nam , Steve French , Sasha Levin Subject: [PATCH 6.19 816/844] cifs: some missing initializations on replay Date: Sat, 28 Feb 2026 12:32:09 -0500 Message-ID: <20260228173244.1509663-817-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shyam Prasad N [ Upstream commit 14f66f44646333d2bfd7ece36585874fd72f8286 ] In several places in the code, we have a label to signify the start of the code where a request can be replayed if necessary. However, some of these places were missing the necessary reinitializations of certain local variables before replay. This change makes sure that these variables get initialized after the label. Cc: stable@vger.kernel.org Reported-by: Yuchan Nam Tested-by: Yuchan Nam Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- fs/smb/client/smb2ops.c | 2 ++ fs/smb/client/smb2pdu.c | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index d76d79e50e8e7..4eb7879479baf 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -1185,6 +1185,7 @@ smb2_set_ea(const unsigned int xid, struct cifs_tcon = *tcon, =20 replay_again: /* reinitialize for possible replay */ + used_len =3D 0; flags =3D CIFS_CP_CREATE_CLOSE_OP; oplock =3D SMB2_OPLOCK_LEVEL_NONE; server =3D cifs_pick_channel(ses); @@ -1583,6 +1584,7 @@ smb2_ioctl_query_info(const unsigned int xid, =20 replay_again: /* reinitialize for possible replay */ + buffer =3D NULL; flags =3D CIFS_CP_CREATE_CLOSE_OP; oplock =3D SMB2_OPLOCK_LEVEL_NONE; server =3D cifs_pick_channel(ses); diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index c7e086dfb1765..758d6f4256726 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -2908,6 +2908,7 @@ int smb311_posix_mkdir(const unsigned int xid, struct= inode *inode, =20 replay_again: /* reinitialize for possible replay */ + pc_buf =3D NULL; flags =3D 0; n_iov =3D 2; server =3D cifs_pick_channel(ses); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B562A424E72; Sat, 28 Feb 2026 17:46:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300785; cv=none; b=D1widm/6krh2k6fErS5jA3JypEzAPDHp45P84LHIiS/AKuoP8TStc+R4rYQDgjv6WS6BUHkNcHQMQTYozUzhmA6cHLttBnOtFCpyagqHnx4ewnv6x3s89uTkUR1UGgysuCgxSb5tQk8Ga0bE6+6uiHVzln6s63gdqu2c66YCh6Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300785; c=relaxed/simple; bh=THbQHgaq61jho7D5uWewRwo0XMnNLOZ1XtokK5cfmRY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oFXQr27WXZPOLTd3V1GoZ5h+AgQCUsM+T+nOHNohVkEyE2J1YH2bl2sqYMDla9iq2hJ3cvEG6yq3EObZwYN/NgWo3nj39J8tYTToWXu3Ib0LEt2pW2UjoRdvRoi1qWmUEBwFVGXmfExRGy/ptckl6hUDDkMgy3ib9kHFryWNPbA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CIvw8Pqk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CIvw8Pqk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7627C19424; Sat, 28 Feb 2026 17:46:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300785; bh=THbQHgaq61jho7D5uWewRwo0XMnNLOZ1XtokK5cfmRY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CIvw8Pqks0Rd71lpJzVHUGyjnRZw9HNHYcOnMiJpIgr8CTA6/RNIir4Wu6nR+Unfx yBRx7jo+VvrkSlRsrFMwfF3rGgXPmTVk0hniIvvxk74ayiUxzH/lvDTpvv5AUw6bnb 3RLNpscfvUGm8eG32C1UYW1KmlOd4aYnporpgfSizD0LSSyxR1BWo7JRveATxdvqmb z+WCbBMnDqd1B+zD/tQ0uYhHU9she1amtmjk+7SGOb+au+m38OqQlCuOlvITxmj5Ly 9yqV/KQ7+uCe7erdUahDeoFDwRG9UqUMlhbKeVS//yVo6+pj7jNIzb/h1XYPQGiAPO LcuT+0o7vsi2Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Tidmore , Bartosz Golaszewski , Sasha Levin Subject: [PATCH 6.19 817/844] gpio: nomadik: Add missing IS_ERR() check Date: Sat, 28 Feb 2026 12:32:10 -0500 Message-ID: <20260228173244.1509663-818-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Tidmore [ Upstream commit 58433885ee99e8c96757e82ccf6d50646c4dfe09 ] The function gpio_device_get_desc() can return an error pointer and is not checked for one. Add check for error pointer. Fixes: ddeb66d2cb10f ("gpio: nomadik: don't print out global GPIO numbers i= n debugfs callbacks") Cc: stable@vger.kernel.org Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260214044531.43539-1-ethantidmore06@gmail.= com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpio/gpio-nomadik.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpio/gpio-nomadik.c b/drivers/gpio/gpio-nomadik.c index 97c5cd33279d5..e22b713166d71 100644 --- a/drivers/gpio/gpio-nomadik.c +++ b/drivers/gpio/gpio-nomadik.c @@ -430,6 +430,9 @@ void nmk_gpio_dbg_show_one(struct seq_file *s, struct p= inctrl_dev *pctldev, #ifdef CONFIG_PINCTRL_NOMADIK if (mode =3D=3D NMK_GPIO_ALT_C && pctldev) { desc =3D gpio_device_get_desc(chip->gpiodev, offset); + if (IS_ERR(desc)) + return; + mode =3D nmk_prcm_gpiocr_get_mode(pctldev, desc_to_gpio(desc)); } #endif --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA0CA426299; Sat, 28 Feb 2026 17:46:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300786; cv=none; b=luRcFTsahPtNWLqJQLYTsEWUL00sgDmHl1FdXQIrKtq5VRy6pjA6gtHQxUL0JuavZrTGKZwDTUbEc0fanhE/1YcvKmsKIFQbZZ53yQLwhYw/G1/rqpqY90T09IaLKqapPf75eLWxLa5BuEMB8WRMq+1RUC8V9K6NghvH3Mz0PPM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300786; c=relaxed/simple; bh=0b1vuObYsEZ9ud6Aegk2XNO6ah6NuCR4+PMJ1tMhXag=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FvHlSA1HZj4/IWzLC4sCTIDsnpPBJbf68cx+Qx7fku06+ZJVb+iiG2pWdh69HM2HpeTDC7nKUD8OOTjddBZ0jA6TPbi+PqWF+W+kos9JTWKgRlm1D5bFEFzzW6cgDFe7L2ztB/GbE+rGh/WLwHtnQBQOpdqo6FkABjon7vc3KHs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qRlxaI6n; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qRlxaI6n" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3564C19423; Sat, 28 Feb 2026 17:46:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300786; bh=0b1vuObYsEZ9ud6Aegk2XNO6ah6NuCR4+PMJ1tMhXag=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qRlxaI6ngstsn+idFa4pWroCkqYYrPWgNpYIA/c1gnK8Nap8DikJniDY3sr0RiU22 5sE+nM4ys98fi5Zcj8QKR1uwuVgEHCCKTCyIYBB7zuwoSb+201Zw9vStT0Fy2VMGu9 J5eIHrYAkwX49/Jpzd2q0+fzq4dwHhnhPsPJGADHMxtRBNVjkYAbIDHuewDhDSURgU 2SwzgO4HJzQlqQhg49YCaT2pd/TA0vs6QYnYbZOHUok3jmdQFzleFAlUgVyeUG/MHk b/1TAtLNnPGxVGyjooyu3BhyRDEdhuAtToRq0ajupTHg0H8FhXOSXNql4myvfF4mKx bwIksD1/wERbw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Asbj=C3=B8rn=20Sloth=20T=C3=B8nnesen?= , Gabriel Krisman Bertazi , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 818/844] io_uring/cmd_net: fix too strict requirement on ioctl Date: Sat, 28 Feb 2026 12:32:11 -0500 Message-ID: <20260228173244.1509663-819-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Asbj=C3=B8rn Sloth T=C3=B8nnesen [ Upstream commit 600b665b903733bd60334e86031b157cc823ee55 ] Attempting SOCKET_URING_OP_SETSOCKOPT on an AF_NETLINK socket resulted in an -EOPNOTSUPP, as AF_NETLINK doesn't have an ioctl in its struct proto, but only in struct proto_ops. Prior to the blamed commit, io_uring_cmd_sock() only had two cmd_op operations, both requiring ioctl, thus the check was warranted. Since then, 4 new cmd_op operations have been added, none of which depend on ioctl. This patch moves the ioctl check, so it only applies to the original operations. AFAICT, the ioctl requirement was unintentional, and it wasn't visible in the blamed patch within 3 lines of context. Cc: stable@vger.kernel.org Fixes: a5d2f99aff6b ("io_uring/cmd: Introduce SOCKET_URING_OP_GETSOCKOPT") Signed-off-by: Asbj=C3=B8rn Sloth T=C3=B8nnesen Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/cmd_net.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/io_uring/cmd_net.c b/io_uring/cmd_net.c index 19d3ce2bd20ad..3db34e2d22ee5 100644 --- a/io_uring/cmd_net.c +++ b/io_uring/cmd_net.c @@ -159,16 +159,19 @@ int io_uring_cmd_sock(struct io_uring_cmd *cmd, unsig= ned int issue_flags) struct proto *prot =3D READ_ONCE(sk->sk_prot); int ret, arg =3D 0; =20 - if (!prot || !prot->ioctl) - return -EOPNOTSUPP; - switch (cmd->cmd_op) { case SOCKET_URING_OP_SIOCINQ: + if (!prot || !prot->ioctl) + return -EOPNOTSUPP; + ret =3D prot->ioctl(sk, SIOCINQ, &arg); if (ret) return ret; return arg; case SOCKET_URING_OP_SIOCOUTQ: + if (!prot || !prot->ioctl) + return -EOPNOTSUPP; + ret =3D prot->ioctl(sk, SIOCOUTQ, &arg); if (ret) return ret; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 651DE4262B0; Sat, 28 Feb 2026 17:46:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300787; cv=none; b=cvzBsvy+ffdXkhvbjDmx55QaX7lnNnEelu7LJlRsfOYUDhKVCbSzWdfDaQQF3fjAYe561agQeqKW4zEK3iXiho584GmvHLGe8SWxeQfVh4bEOge8+L/pBPg7AIYPghIBGd4wqTB7zNTe9Qv2eebJVbTuxd16CBQdd+wfPTr726Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300787; c=relaxed/simple; bh=/PlTOHnxU+YtZ/oVw0B8iKFTALZYB8xaIPwatim10WM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Oj5yUEabrLSQTm3WzB4ZirSZaBGffGHtlOFiHyxVd83Oaj0ffFhIkbS55hs83FpLUkY+3tYZhs+LlSXZJsAvtOyTfF9AB+WJJBjMAtMwpGOW67ZASzwu8Dwxo3ZJhEFkFCGh0Nyv5kXqbFUHC0lFQprsnvecn/BGyZoRCVDw8+A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AjuIlDpq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AjuIlDpq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B223BC19424; Sat, 28 Feb 2026 17:46:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300787; bh=/PlTOHnxU+YtZ/oVw0B8iKFTALZYB8xaIPwatim10WM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AjuIlDpqx3irCfd35TG9hgykb3cPSRIQLt2f+i81TfxcNjrSquChYua6f8vlWK5Kt 7ISdP+hEaDMQvnMVf38VcGP71qPLpstf5fK3gZfiV3Af+XdTlmYBSayJIhSP/8cVo4 sYu5Uf3kX6e59hatmw5UtsvUrIbnoIOlCEwMzYtslGaBSI41kgL+qmsQwJ79V23gFt aDciUazCwr6OKM5+59a0nVpF2hCSiyIDiBqdHK+XyyT0Wz9kvEDANzKk7YOSxb+9qv RjWDRzdZA0vIWLwTLcxJkQmEhtLT8W++sQxFpTWdME3gerWu9rwD0dDezNBdsHcIQz IGD/PpV/UsOvw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gustavo Salvini , Mark Brown , Sasha Levin Subject: [PATCH 6.19 819/844] ASoC: amd: yc: Add DMI quirk for ASUS Vivobook Pro 15X M6501RR Date: Sat, 28 Feb 2026 12:32:12 -0500 Message-ID: <20260228173244.1509663-820-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gustavo Salvini [ Upstream commit ff9cadd1a2c0b2665b7377ac79540d66f212e7e3 ] The ASUS Vivobook Pro 15X (M6501RR) with AMD Ryzen 9 6900HX has an internal DMIC that is not detected without a DMI quirk entry, as the BIOS does not set the AcpDmicConnected ACPI _DSD property. Adding the DMI entry enables the ACP6x DMIC machine driver to probe successfully. Cc: stable@vger.kernel.org Signed-off-by: Gustavo Salvini Link: https://patch.msgid.link/20260210155156.29079-1-guspatagonico@gmail.c= om Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/soc/amd/yc/acp6x-mach.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index 67f2fee193980..f1a63475100d1 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -696,7 +696,13 @@ static const struct dmi_system_id yc_acp_quirk_table[]= =3D { DMI_MATCH(DMI_BOARD_NAME, "XyloD5_RBU"), } }, - + { + .driver_data =3D &acp6x_card, + .matches =3D { + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_PRODUCT_NAME, "Vivobook_ASUSLaptop M6501RR_M6501RR"), + } + }, {} }; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D28E496914; Sat, 28 Feb 2026 17:46:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300788; cv=none; b=BuFrTaboOtkTqbJqPCde5jtIwCegDye6J7lm5WpGnros8GrJMN+SROSTEBUviZPKtUGZgQ8C6bmiwj2IBr/IRRD10B//GfogRBWm99BUuLmlSzORPPspdfP4TMSXSxBgTt7vssutdjrCRbuYz2IJKDaIhqPFTxTBFVz0hWFq3cU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300788; c=relaxed/simple; bh=vWWgYDOWrP/1sJh38suuQpb9ZQiOHx8/B0uMDWh4wBU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aIlDt6W3bECqfAsLAUELYyFWBzBeHCNka3XAqwW7mKIfy/51MeCDRi+uKuomtnBuUdHxma5jz6nAiqfVqlG/K12g2uhtQ4R66kYx1PnMDRHliN2Hdnoy/q4lr5wKVNyzeVN5iJKKxZPChX7GF/xxn+t1HSfGoNITDqAuAyLKcW4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jAxGdZhY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jAxGdZhY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B484C116D0; Sat, 28 Feb 2026 17:46:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300788; bh=vWWgYDOWrP/1sJh38suuQpb9ZQiOHx8/B0uMDWh4wBU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jAxGdZhYintqUsVHiC+bVcqXfqN0xJY2jKBTtG5BzDoriZaWMtUGr0xdRFsrtlcgn lR4kYhIafR8ADrHxb9qJ4oxn3204C41htfTZ7B7yhwP5WkjQ/HsJvgQ1GJsNEcYHzG Fnq2jIbhrjHQWVpxiaDeJI6Oq27sfpnY2lEanAeTcG4ERt3KJwBJ+PXXOBLNlmDtR5 jQ4CVbUX0X88qTibnKNAzmbROEhDwLc/BvEVpqQngiQKIPZUjY9a7l3dDwE6zQXEdT w3aRmxB15mStySNCbTBQFKmsn0zggScQYc4/q4pwrse8eEAvAJfqEIrCDeyUUxZS+H vQ7myuChk+ykw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nathan Chancellor , Stefano Garzarella , Sasha Levin Subject: [PATCH 6.19 820/844] kbuild: rpm-pkg: Disable automatic requires for manual debuginfo package Date: Sat, 28 Feb 2026 12:32:13 -0500 Message-ID: <20260228173244.1509663-821-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Nathan Chancellor [ Upstream commit f94711255a73d8938cf3bb405a0af3a4d2700ed1 ] Stefano reports that after commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually"), building with an rpm package using rpm 4.20.0 fails with: RPM build errors: Dependency tokens must begin with alpha-numeric, '_' or '/': #=EF=BF= =BD) =3D 0x0d000002 Dependency tokens must begin with alpha-numeric, '_' or '/': =EF=BF= =BD) =3D 0x0d000000 Dependency tokens must begin with alpha-numeric, '_' or '/': ) =3D 0x= 7c0e000000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) =3D 0x313036323= 0322000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) =3D 0x4728203a4= 3434800 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) =3D 0x313036323= 0322000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) =3D 0x4728203a4= 3434800 This error comes from the automatic requirements feature of rpm. The -debuginfo subpackage has no dependencies, so disable this feature with 'AutoReq: 0' for this subpackage, avoiding the error. This matches the official %_debug_template macro that rpm provides. While automatic provides should be default enabled, be explicit like %_debug_template does. Additionally, while in the area, add the manual debug information package to the Development/Debug group, further aligning with %_debug_template. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Reported-by: Stefano Garzarella Closes: https://lore.kernel.org/CAGxU2F7FFNgb781_A7a1oL63n9Oy8wsyWceKhUpeZ6= mLk=3Dfocw@mail.gmail.com/ Tested-by: Stefano Garzarella Link: https://patch.msgid.link/20260216-improve-manual-debuginfo-template-v= 1-1-e584b3f8d3be@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- scripts/package/kernel.spec | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec index bccf58bdd45fd..b3c956205af00 100644 --- a/scripts/package/kernel.spec +++ b/scripts/package/kernel.spec @@ -48,6 +48,9 @@ against the %{version} kernel package. %if %{with_debuginfo_manual} %package debuginfo Summary: Debug information package for the Linux kernel +Group: Development/Debug +AutoReq: 0 +AutoProv: 1 %description debuginfo This package provides debug information for the kernel image and modules f= rom the %{version} package. --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A321427D35; Sat, 28 Feb 2026 17:46:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300789; cv=none; b=V9AIdXQDGlJGKCm5KPx3zVv/zd2u3+dP6vCccTazJnxbLZmkUikJlEr3pHszlbAwAfYt+pTIJh2PKnbri09PWxqcTz46d8FFAuoPR4ta0d52luDFsls/4gzYq4+13SHuH96MLYsnRbw1Tx50MlLTCHYe3mCNoNtuJIPzQBP6sB0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300789; c=relaxed/simple; bh=Ez11OVOkHbz5VC+1582CGU9v60g9JtJcp2H6KwN942A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U58nPzS+8lIz72tOd/tDAZZGxk5VuOnVMfAamYEw0YEw9nhF2WeFkFqDRBkyTlgtEFfkW73Tz/zE6GKTivbYNLdvXS2k6P3aquLCEIYlNebHv35OJQJw3tgP9eLhWYBCSbh7YL82hqdH5DxEwouSJbzGaOqtjXXezs+ZR5NUqBI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z77yvwg3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z77yvwg3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63960C19423; Sat, 28 Feb 2026 17:46:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300789; bh=Ez11OVOkHbz5VC+1582CGU9v60g9JtJcp2H6KwN942A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z77yvwg3CfoMgYPZv4gvilwH/lnbIq5sCWnGdg8MGJPOT91fCjuD+1zdn4hT7Womj Oxt1X5R/Fu7nOPXVksdP12mZkXMf57ptGDYPNNDO3qLGhmx5xDnPO8wKZFarKDaRDq jESwMcFYiE9hmVefUfiN3DC4uMWs1KLXbLKTxkQ5hA56f0LalremZLgd91a6GHUWWX 93dv1MRO3JlDjobImCMK5qyM1+VrCvFXHthyuhPP4nalL+m4Y2tzD6CxhpS1tI+iwQ gV1zQXFjQvYmKN8SIAXuHYgNYs0BaolSH63NZtuBxAWeneQQDB9H9ZkzKe//+qBi8w nZ01vnKrc/1Vw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Nelson-Moore , Simon Horman , Paolo Abeni , Sasha Levin Subject: [PATCH 6.19 821/844] net: arcnet: com20020-pci: fix support for 2.5Mbit cards Date: Sat, 28 Feb 2026 12:32:14 -0500 Message-ID: <20260228173244.1509663-822-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Nelson-Moore [ Upstream commit c7d9be66b71af490446127c6ffcb66d6bb71b8b9 ] Commit 8c14f9c70327 ("ARCNET: add com20020 PCI IDs with metadata") converted the com20020-pci driver to use a card info structure instead of a single flag mask in driver_data. However, it failed to take into account that in the original code, driver_data of 0 indicates a card with no special flags, not a card that should not have any card info structure. This introduced a null pointer dereference when cards with no flags were probed. Commit bd6f1fd5d33d ("net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()") then papered over this issue by rejecting cards with no driver_data instead of resolving the problem at its source. Fix the original issue by introducing a new card info structure for 2.5Mbit cards that does not set any flags and using it if no driver_data is present. Fixes: 8c14f9c70327 ("ARCNET: add com20020 PCI IDs with metadata") Fixes: bd6f1fd5d33d ("net: arcnet: com20020: Fix null-ptr-deref in com20020= pci_probe()") Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Signed-off-by: Ethan Nelson-Moore Link: https://patch.msgid.link/20260213045510.32368-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/arcnet/com20020-pci.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/net/arcnet/com20020-pci.c b/drivers/net/arcnet/com2002= 0-pci.c index 0472bcdff1307..b5729d6c0b47c 100644 --- a/drivers/net/arcnet/com20020-pci.c +++ b/drivers/net/arcnet/com20020-pci.c @@ -115,6 +115,8 @@ static const struct attribute_group com20020_state_grou= p =3D { .attrs =3D com20020_state_attrs, }; =20 +static struct com20020_pci_card_info card_info_2p5mbit; + static void com20020pci_remove(struct pci_dev *pdev); =20 static int com20020pci_probe(struct pci_dev *pdev, @@ -140,7 +142,7 @@ static int com20020pci_probe(struct pci_dev *pdev, =20 ci =3D (struct com20020_pci_card_info *)id->driver_data; if (!ci) - return -EINVAL; + ci =3D &card_info_2p5mbit; =20 priv->ci =3D ci; mm =3D &ci->misc_map; @@ -347,6 +349,18 @@ static struct com20020_pci_card_info card_info_5mbit = =3D { .flags =3D ARC_IS_5MBIT, }; =20 +static struct com20020_pci_card_info card_info_2p5mbit =3D { + .name =3D "ARC-PCI", + .devcount =3D 1, + .chan_map_tbl =3D { + { + .bar =3D 2, + .offset =3D 0x00, + .size =3D 0x08, + }, + }, +}; + static struct com20020_pci_card_info card_info_sohard =3D { .name =3D "SOHARD SH ARC-PCI", .devcount =3D 1, --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 76B5A496919; Sat, 28 Feb 2026 17:46:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300790; cv=none; b=E4KhSP/LE0vjJMi608a0G7GqBUzp/XSD6KP5D7lEuIdojx9b5cE3KNV7diy32r+ibsv2vqZ+RpL9aGBSN0x5/HqMkKwZ0Ksjbw1/edIoviuPze6kIZ4Tlv+YLBNPiYXI2LZ5RFyIBpKZGZcy/4UIoOcoAmccobxkwRViAMie+AY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300790; c=relaxed/simple; bh=Ad8rp7JJ8JuTBBW0xVn+Hrn34sFXYY/i1r51x1S/7+c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ufUQ37ocMabHgZo7DI4Cv75EVIiCICsr+DTugRRFo9e94s0+ky6/L0XwzOSlC3Xiw9lC9s3Rv5fNmrp68Dp8IqN6xTUDrPSnBu06v2ls7dTlxF+pWJwHChVK7w+ZUWJeqJjHNswfc1V4hq5TrSzz2pnfjQ1vqn+QDzFtCBIpOGc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iWIj0fJk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iWIj0fJk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54EFFC116D0; Sat, 28 Feb 2026 17:46:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300790; bh=Ad8rp7JJ8JuTBBW0xVn+Hrn34sFXYY/i1r51x1S/7+c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iWIj0fJk3SFF3scMnklTFKO1pNOnvCAb59p9Jqs05KPXyP20fxAn/+ech82xgyvW+ 8XZQc3VoO5P9j8TT3HiEkDpoPEB09d4YdO8kuLLg8rR8/QDNE4uHVg/RCFjETQZ8gG fNbdJvCCus0aPsRHLWEMwwAwh72iiUa/paIf1DQgan6PxBZinHNNQtC8EMJEjSkHxt Y3f85sbX2ek8e/xXVDN+ckDhb4phQpAf9se0Cm2ykaAgkbP4dWD2zxMDGampC8sRrZ fPo0g9YH2fGc+JVSm959rJk1ZQ+/95oMBi+hmOle2ZNIv5mqq+4FFmDr2T1U/LiCB+ hwZtN7lWsZfXg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jia Yao , Matthew Auld , Matthew Brost , Shuicheng Lin , Himal Prasad Ghimiray , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Rodrigo Vivi , Sasha Levin Subject: [PATCH 6.19 822/844] drm/xe: Add bounds check on pat_index to prevent OOB kernel read in madvise Date: Sat, 28 Feb 2026 12:32:15 -0500 Message-ID: <20260228173244.1509663-823-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Jia Yao [ Upstream commit fbbe32618e97eff81577a01eb7d9adcd64a216d7 ] When user provides a bogus pat_index value through the madvise IOCTL, the xe_pat_index_get_coh_mode() function performs an array access without validating bounds. This allows a malicious user to trigger an out-of-bounds kernel read from the xe->pat.table array. The vulnerability exists because the validation in madvise_args_are_sane() directly calls xe_pat_index_get_coh_mode(xe, args->pat_index.val) without first checking if pat_index is within [0, xe->pat.n_entries). Although xe_pat_index_get_coh_mode() has a WARN_ON to catch this in debug builds, it still performs the unsafe array access in production kernels. v2(Matthew Auld) - Using array_index_nospec() to mitigate spectre attacks when the value is used v3(Matthew Auld) - Put the declarations at the start of the block Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Reviewed-by: Matthew Auld Cc: # v6.18+ Cc: Matthew Brost Cc: Shuicheng Lin Cc: Himal Prasad Ghimiray Cc: "Thomas Hellstr=C3=B6m" Cc: Rodrigo Vivi Cc: Matthew Auld Signed-off-by: Jia Yao Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260205161529.1819276-1-jia.yao@intel.com (cherry picked from commit 944a3329b05510d55c69c2ef455136e2fc02de29) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/xe/xe_vm_madvise.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_vm_madvise.c b/drivers/gpu/drm/xe/xe_vm_= madvise.c index cad3cf627c3f2..fe7e1b45f5c0c 100644 --- a/drivers/gpu/drm/xe/xe_vm_madvise.c +++ b/drivers/gpu/drm/xe/xe_vm_madvise.c @@ -268,8 +268,13 @@ static bool madvise_args_are_sane(struct xe_device *xe= , const struct drm_xe_madv break; case DRM_XE_MEM_RANGE_ATTR_PAT: { - u16 coh_mode =3D xe_pat_index_get_coh_mode(xe, args->pat_index.val); + u16 pat_index, coh_mode; =20 + if (XE_IOCTL_DBG(xe, args->pat_index.val >=3D xe->pat.n_entries)) + return false; + + pat_index =3D array_index_nospec(args->pat_index.val, xe->pat.n_entries); + coh_mode =3D xe_pat_index_get_coh_mode(xe, pat_index); if (XE_IOCTL_DBG(xe, !coh_mode)) return false; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 511B7429073; Sat, 28 Feb 2026 17:46:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300791; cv=none; b=GxETTfl9A0doFqdB3H7jBf3fjmitxvR+BVsT1wyKBmQ4i7EWgjdPbY42lUACnisO7H5bLZby4kbdh12x+9CPFne3YsPEvDXHg0+82s0tkkVG46Pk4VCZ/9jv4uT+hrFvy9WViu8nEb+ujAlGSWW1UfUZyWXIYFQFiSqj0V6LbAg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300791; c=relaxed/simple; bh=QHca3r2l3zROSicefrNcatC2gyxEbz5tmBfbzmPLDEc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZQgJghU+efnUvBjpF/+9PksllsiOErsGpl1jOAb+Doo8J/qo9KJDUnKGhHbNHxa4D07eHUazL1biu2ZCfLDdvhEvxDOPyUM3ZWJ5BIEdRqbDbswuIS0+j5Ee2TLVs6gCICNrgKstaeZiYkDeoAFPIuB4e1Cq905QrSslaLE/KqA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s2eAUxK9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s2eAUxK9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D244C116D0; Sat, 28 Feb 2026 17:46:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300791; bh=QHca3r2l3zROSicefrNcatC2gyxEbz5tmBfbzmPLDEc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s2eAUxK9FU3OZHGTQfVE9/vthqjKSt+PIEXlJhtmQL70NjeTgqAq4PxduOoMvLvHr re2mNXBYHUYdsj2j2VkGPBB3CYlvl1geB1n4+jKjfI5T3C9c7c8ilxFRk52x8Qv9AP ay0M6AUezKhethikDlZPc7Qkn37poHw9WYVbMzzgjVws8LdDiNpwtig3tOVugXJ5v9 rCZeBJ4ANxlDmrXq99rhKHq9H84w6gJgdA1/xFNfUgS0/lIi0EIjNcKcMD3sMf1R4v LDXYBnu0eg0EpTkjreaIzyPyVzz7/wnKJ5MkcYMgGxDrw/kcPA6nVi8aBxIdEt3Egp HwAV9b/Dhe/8g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Fourier , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 823/844] net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle Date: Sat, 28 Feb 2026 12:32:16 -0500 Message-ID: <20260228173244.1509663-824-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Fourier [ Upstream commit ffe68c3766997d82e9ccaf1cdbd47eba269c4aa2 ] dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys. Fixes: 6af55ff52b02 ("Driver for Beckhoff CX5020 EtherCAT master module.") Cc: Signed-off-by: Thomas Fourier Link: https://patch.msgid.link/20260213164340.77272-2-fourier.thomas@gmail.= com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/net/ethernet/ec_bhf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ec_bhf.c b/drivers/net/ethernet/ec_bhf.c index 67275aa4f65b2..0c86cbb0313c3 100644 --- a/drivers/net/ethernet/ec_bhf.c +++ b/drivers/net/ethernet/ec_bhf.c @@ -423,7 +423,7 @@ static int ec_bhf_open(struct net_device *net_dev) =20 error_rx_free: dma_free_coherent(dev, priv->rx_buf.alloc_len, priv->rx_buf.alloc, - priv->rx_buf.alloc_len); + priv->rx_buf.alloc_phys); out: return err; } --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 320F4429097; Sat, 28 Feb 2026 17:46:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300792; cv=none; b=YmG60ICS+Q+OIm+gBLp+cFoQQ0Bi5dVwCxs9oTQJ4Ea7dZ6FV4hFXgo3gD5vLe6bqReaoObC/xIVSq7JXuCSwT1oM0PunR6BW//hHMB9gRvPv9cIRYQ1+EXY5dPiBM++JNWgpEoRGpr6ac5ZQdQvMXTwKo6sW3SvdUPfiNCWiw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300792; c=relaxed/simple; bh=UyULersl7ZgEjSJZEV+xxB3ZkP0sOWni99ZT4GmK+ac=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LWA2sHOVUfd5gy59MSXK0p7sxYxpG3EkDXnFU2CaW2iHsV53Oudqg+WJGXMF+X+oLCRIZGxzLP+3vKUZ+oaFYDX8r0znfLM9r7sw76LkmyVgFCOPvLUlEV8GeW4eEjj++8iImbq68HOw4RgoQgw6aK26IYAf7ERjMEWOuc0xOJE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BGbpVDAR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BGbpVDAR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77536C19425; Sat, 28 Feb 2026 17:46:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300792; bh=UyULersl7ZgEjSJZEV+xxB3ZkP0sOWni99ZT4GmK+ac=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BGbpVDARoBel6C/ycM9bU223fZQezqvw7GQzl6Ny535p59ua3VumRvHMLBPkZio9w Jd4NrvfQo9CCEuPKTnml+ZZ/KHgmufE4CGPqt2saGKg13lo8HvGeNndX51EK+wvFuj fZnoA49Xil9CquW1UT3J+HfdO8epYAay2hGUbM+jwTKCAPWEgZ/C5cXadr78LS8H3v KEGxu822JtAkZ1H7UdJDBaR10sSpFzoelOa/jePQFBENcD+3sg/8702hHUNrH1d0Fi O9XMtJW6TaGhqeNak5QAqgnYKQuHL7dekhFaKP1GJXN/pBcdRguDYuPa4yR/xjYUFd qDnH8vSso7nSA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ruitong Liu , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 824/844] net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash() Date: Sat, 28 Feb 2026 12:32:17 -0500 Message-ID: <20260228173244.1509663-825-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ruitong Liu [ Upstream commit be054cc66f739a9ba615dba9012a07fab8e7dd6f ] Commit 38a6f0865796 ("net: sched: support hash selecting tx queue") added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is computed as: mapping_mod =3D queue_mapping_max - queue_mapping + 1; The range size can be 65536 when the requested range covers all possible u16 queue IDs (e.g. queue_mapping=3D0 and queue_mapping_max=3DU16_MAX). That value cannot be represented in a u16 and previously wrapped to 0, so tcf_skbedit_hash() could trigger a divide-by-zero: queue_mapping +=3D skb_get_hash(skb) % params->mapping_mod; Compute mapping_mod in a wider type and reject ranges larger than U16_MAX to prevent params->mapping_mod from becoming 0 and avoid the crash. Fixes: 38a6f0865796 ("net: sched: support hash selecting tx queue") Cc: stable@vger.kernel.org # 6.12+ Signed-off-by: Ruitong Liu Link: https://patch.msgid.link/20260213175948.1505257-1-cnitlrt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/sched/act_skbedit.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/sched/act_skbedit.c b/net/sched/act_skbedit.c index 8c1d1554f6575..5450c1293eb50 100644 --- a/net/sched/act_skbedit.c +++ b/net/sched/act_skbedit.c @@ -126,7 +126,7 @@ static int tcf_skbedit_init(struct net *net, struct nla= ttr *nla, struct tcf_skbedit *d; u32 flags =3D 0, *priority =3D NULL, *mark =3D NULL, *mask =3D NULL; u16 *queue_mapping =3D NULL, *ptype =3D NULL; - u16 mapping_mod =3D 1; + u32 mapping_mod =3D 1; bool exists =3D false; int ret =3D 0, err; u32 index; @@ -194,6 +194,10 @@ static int tcf_skbedit_init(struct net *net, struct nl= attr *nla, } =20 mapping_mod =3D *queue_mapping_max - *queue_mapping + 1; + if (mapping_mod > U16_MAX) { + NL_SET_ERR_MSG_MOD(extack, "The range of queue_mapping is invalid."); + return -EINVAL; + } flags |=3D SKBEDIT_F_TXQ_SKBHASH; } if (*pure_flags & SKBEDIT_F_INHERITDSFIELD) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 71CB7429E45; Sat, 28 Feb 2026 17:46:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300793; cv=none; b=beV1+LtMVcBdtIeghj76VFr+5Cx10yz9SQXY4hyA29qywxCLFFWqZG97X/N4CoWuMLzP0yzthqXMkoCS+qdOUF7ZLXL8bWZHXjAoue9tDyVSLSSA1Za11OzPnN8vC0UnOzgQt76p4akPW7NpJrUs3xkf4xnu3J5PDLVjCV1mSRc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300793; c=relaxed/simple; bh=IymXDE+KqA+YMw3aZHf+yx0denkWGPnhBUAVRO0hsY0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KljGN0OLXqSQ2+9T7dhZk6thyZ2osrLAOdNmsHwzZfxHmecHTGF+mwhjT8HC/KPAE3wEpp05naWxDyoNzSS7zHM0LWu4WF/NxPdqXC8WgIdMuqE5pRQkc7AiGFhTuogOnxmNmGpkvKIYBeX3T4h3Hqh9pledPn28ISiyEgLeVgk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K9P5eNtJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K9P5eNtJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54C70C116D0; Sat, 28 Feb 2026 17:46:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300793; bh=IymXDE+KqA+YMw3aZHf+yx0denkWGPnhBUAVRO0hsY0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K9P5eNtJTGqqZ5MYMPD01BX7HBR6xcd7Xk9JZoopcAFiJDwZ52qobc121IGot16qV ck8Bvzg9HNRNgdz5C4wpna4QkmIARMXXxwDpoKORsmu4/6k+TXeMQHhwzTyK0NN048 1YSuYgg7tluEyoUeM9lq5OZWxlMVqTAtmxvL3LfBtlgT4oP5h37nA4RXiUKDP43LPM q1thOm9ti+PRHZVg64DTp2oXOxPDNQM6sKsDpKlEcVeTQG1qIIB1sx8/xNyZ7/HqHc Zts949tAL/lRPyU8m8VCcW0tF8+SBKSl9p6MeJP3xF28gGIqUbpOhsjgISb6wbTrIc VHqxq2hykg3ww== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bartosz Golaszewski , Andy Shevchenko , Hans de Goede , Sasha Levin Subject: [PATCH 6.19 825/844] gpio: swnode: restore the swnode-name-against-chip-label matching Date: Sat, 28 Feb 2026 12:32:18 -0500 Message-ID: <20260228173244.1509663-826-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bartosz Golaszewski [ Upstream commit ff91965ad8b214e0771bc5a15253f14f583a7649 ] Using the remote firmware node for software node lookup is the right thing to do. The GPIO controller we want to resolve should have the software node we scooped out of the reference attached to it. However, there are existing users who abuse the software node API by creating dummy swnodes whose name is set to the expected label string of the GPIO controller whose pins they want to control and use them in their local swnode references as GPIO properties. This used to work when we compared the software node's name to the chip's label. When we switched to using a real fwnode lookup, these users broke down because the firmware nodes in question were never attached to the controllers they were looking for. Restore the label matching as a fallback to fix the broken users but add a big FIXME urging for a better solution. Cc: stable@vger.kernel.org # v6.18, v6.19 Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmwar= e nodes") Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/ Acked-by: Andy Shevchenko Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260211085313.16792-1-bartosz.golaszewski@o= ss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c index b44f35d684590..f02f5a61ddb83 100644 --- a/drivers/gpio/gpiolib-swnode.c +++ b/drivers/gpio/gpiolib-swnode.c @@ -43,6 +43,25 @@ static struct gpio_device *swnode_get_gpio_device(struct= fwnode_handle *fwnode) =20 fwnode_lookup: gdev =3D gpio_device_find_by_fwnode(fwnode); + if (!gdev && gdev_node && gdev_node->name) + /* + * FIXME: We shouldn't need to compare the GPIO controller's + * label against the software node that is supposedly attached + * to it. However there are currently GPIO users that - knowing + * the expected label of the GPIO chip whose pins they want to + * control - set up dummy software nodes named after those GPIO + * controllers, which aren't actually attached to them. In this + * case gpio_device_find_by_fwnode() will fail as no device on + * the GPIO bus is actually associated with the fwnode we're + * looking for. + * + * As a fallback: continue checking the label if we have no + * match. However, the situation described above is an abuse + * of the software node API and should be phased out and the + * following line - eventually removed. + */ + gdev =3D gpio_device_find_by_label(gdev_node->name); + return gdev ?: ERR_PTR(-EPROBE_DEFER); } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5967429E59; Sat, 28 Feb 2026 17:46:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300794; cv=none; b=EA3/g+0V+LTktWPh8Brhew7XZlkGeuwPMVGUkVAa9jno5fOBytwFQEz6VXLkDLZzv9ZatdzD3GTVmpXZ8HJsnToIye2sTfyHXh4wCkFmaP7s3t7XFMP8HyMZhnuxUgRzfztj+51QlMwp80ObI7kp33hgckFLuGwHIt0EVL5j52g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300794; c=relaxed/simple; bh=cs/97a256N680BtD71IFBJGPXwTJYGVdh7qNlNd6X54=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lAcc95C003DzKX36CBzcFa4D3qXhuTRwj+qMlBBugr6F6laQuCsbxt+/Ja8+JuY+4DepDxuKrYNY0GRWoT6WobzgRnAcOUQ1R7cnZ1j2BjdkbRWLt9ibkO8PvGVoFtE9zAMDdsOZarno4YveajbByDS9RntF6M0J1lFC3843S0c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EXiKLlE4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EXiKLlE4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 454FDC19423; Sat, 28 Feb 2026 17:46:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300793; bh=cs/97a256N680BtD71IFBJGPXwTJYGVdh7qNlNd6X54=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EXiKLlE4rurv/qfPpBsPcDGUm9mAacDEIMKT/VQhVYDWulTL2Y+glQjwSU3IqOZIL d1wvJxa7O1By6RJv8XsSY8F7GUqX/e82hQ6se9+5Jn+iaKvbuwy1PPhtKsG76t+rw/ TYByDirquFVN/BppntGWTUOwDIZ4eMozUpG9W/st8CxJ2JpNsE2nZiimxcJMZzVaDI bNsvp2Y6lnpFw8DrGy9AHADpuKWf65u4Ad2AiiBskylXD9ZbIFtjNIEwa46INIn4f/ wJnnrwqghHym18Ql7B+pqp4Pxd5eTWJBz3toH4P2mWaaIR/qLp7yGBVKgs9GH5mXtY PhKpa+tvZkimQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bartosz Golaszewski , Sasha Levin Subject: [PATCH 6.19 826/844] gpio: sysfs: fix chip removal with GPIOs exported over sysfs Date: Sat, 28 Feb 2026 12:32:19 -0500 Message-ID: <20260228173244.1509663-827-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bartosz Golaszewski [ Upstream commit 6766f59012301f1bf3f46c6e7149caca45d92309 ] Currently if we export a GPIO over sysfs and unbind the parent GPIO controller, the exported attribute will remain under /sys/class/gpio because once we remove the parent device, we can no longer associate the descriptor with it in gpiod_unexport() and never drop the final reference. Rework the teardown code: provide an unlocked variant of gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken before unregistering the parent device itself. This is done to prevent any new exports happening before we unregister the device completely. Cc: stable@vger.kernel.org Fixes: 1cd53df733c2 ("gpio: sysfs: don't look up exported lines as class de= vices") Link: https://patch.msgid.link/20260212133505.81516-1-bartosz.golaszewski@o= ss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpio/gpiolib-sysfs.c | 106 ++++++++++++++++++----------------- 1 file changed, 55 insertions(+), 51 deletions(-) diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c index cd553acf3055e..d4a46a0a37d8f 100644 --- a/drivers/gpio/gpiolib-sysfs.c +++ b/drivers/gpio/gpiolib-sysfs.c @@ -919,63 +919,68 @@ int gpiod_export_link(struct device *dev, const char = *name, } EXPORT_SYMBOL_GPL(gpiod_export_link); =20 -/** - * gpiod_unexport - reverse effect of gpiod_export() - * @desc: GPIO to make unavailable - * - * This is implicit on gpiod_free(). - */ -void gpiod_unexport(struct gpio_desc *desc) +static void gpiod_unexport_unlocked(struct gpio_desc *desc) { struct gpiod_data *tmp, *desc_data =3D NULL; struct gpiodev_data *gdev_data; struct gpio_device *gdev; =20 - if (!desc) { - pr_warn("%s: invalid GPIO\n", __func__); + if (!test_bit(GPIOD_FLAG_EXPORT, &desc->flags)) return; - } =20 - scoped_guard(mutex, &sysfs_lock) { - if (!test_bit(GPIOD_FLAG_EXPORT, &desc->flags)) - return; - - gdev =3D gpiod_to_gpio_device(desc); - gdev_data =3D gdev_get_data(gdev); - if (!gdev_data) - return; + gdev =3D gpiod_to_gpio_device(desc); + gdev_data =3D gdev_get_data(gdev); + if (!gdev_data) + return; =20 - list_for_each_entry(tmp, &gdev_data->exported_lines, list) { - if (gpiod_is_equal(desc, tmp->desc)) { - desc_data =3D tmp; - break; - } + list_for_each_entry(tmp, &gdev_data->exported_lines, list) { + if (gpiod_is_equal(desc, tmp->desc)) { + desc_data =3D tmp; + break; } + } =20 - if (!desc_data) - return; + if (!desc_data) + return; =20 - list_del(&desc_data->list); - clear_bit(GPIOD_FLAG_EXPORT, &desc->flags); + list_del(&desc_data->list); + clear_bit(GPIOD_FLAG_EXPORT, &desc->flags); #if IS_ENABLED(CONFIG_GPIO_SYSFS_LEGACY) - sysfs_put(desc_data->value_kn); - device_unregister(desc_data->dev); - - /* - * Release irq after deregistration to prevent race with - * edge_store. - */ - if (desc_data->irq_flags) - gpio_sysfs_free_irq(desc_data); + sysfs_put(desc_data->value_kn); + device_unregister(desc_data->dev); + + /* + * Release irq after deregistration to prevent race with + * edge_store. + */ + if (desc_data->irq_flags) + gpio_sysfs_free_irq(desc_data); #endif /* CONFIG_GPIO_SYSFS_LEGACY */ =20 - sysfs_remove_groups(desc_data->parent, - desc_data->chip_attr_groups); - } + sysfs_remove_groups(desc_data->parent, + desc_data->chip_attr_groups); =20 mutex_destroy(&desc_data->mutex); kfree(desc_data); } + +/** + * gpiod_unexport - reverse effect of gpiod_export() + * @desc: GPIO to make unavailable + * + * This is implicit on gpiod_free(). + */ +void gpiod_unexport(struct gpio_desc *desc) +{ + if (!desc) { + pr_warn("%s: invalid GPIO\n", __func__); + return; + } + + guard(mutex)(&sysfs_lock); + + gpiod_unexport_unlocked(desc); +} EXPORT_SYMBOL_GPL(gpiod_unexport); =20 int gpiochip_sysfs_register(struct gpio_device *gdev) @@ -1054,29 +1059,28 @@ void gpiochip_sysfs_unregister(struct gpio_device *= gdev) struct gpio_desc *desc; struct gpio_chip *chip; =20 - scoped_guard(mutex, &sysfs_lock) { - data =3D gdev_get_data(gdev); - if (!data) - return; + guard(mutex)(&sysfs_lock); =20 -#if IS_ENABLED(CONFIG_GPIO_SYSFS_LEGACY) - device_unregister(data->cdev_base); -#endif /* CONFIG_GPIO_SYSFS_LEGACY */ - device_unregister(data->cdev_id); - kfree(data); - } + data =3D gdev_get_data(gdev); + if (!data) + return; =20 guard(srcu)(&gdev->srcu); - chip =3D srcu_dereference(gdev->chip, &gdev->srcu); if (!chip) return; =20 /* unregister gpiod class devices owned by sysfs */ for_each_gpio_desc_with_flag(chip, desc, GPIOD_FLAG_SYSFS) { - gpiod_unexport(desc); + gpiod_unexport_unlocked(desc); gpiod_free(desc); } + +#if IS_ENABLED(CONFIG_GPIO_SYSFS_LEGACY) + device_unregister(data->cdev_base); +#endif /* CONFIG_GPIO_SYSFS_LEGACY */ + device_unregister(data->cdev_id); + kfree(data); } =20 /* --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B6F0A429E76; Sat, 28 Feb 2026 17:46:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300794; cv=none; b=EQWYBk8Q7zre6WVqevCwv4Wqu05DiQ86BemQxpiXcubLTIbnVE9WA1A5wbV5UcSPsTacmkdj7ae8Bk0Qr1WjctE2wAnnc+2/hQ1akmSuxFefJT4IA4bQ7vZVCHXlRc16CwxW4vPkrATWFOMhUx1lHu3mVll4SIDNIkEAG5wruqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300794; c=relaxed/simple; bh=49oIs/oTGfxRNFYKoZCt0EzCE9469vwMbZg/yGgoTnM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=J8UIK7WbmxQi4aigXmFnlCmKYznI1AuK3Xb3Xx+67FdcooGIrR6wjHPXqpZco2gXwZEpXxdVEflxZMRj3htqL7x4PGSst1xTUUJpNvOqRj/99BnnramYhjDHVKQ/UowaBtvEZaCzLDlFLPIBxltt0AhG7GXDXWuNAZb/IyeeQn0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s4yrIJ0K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s4yrIJ0K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F811C19424; Sat, 28 Feb 2026 17:46:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300794; bh=49oIs/oTGfxRNFYKoZCt0EzCE9469vwMbZg/yGgoTnM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s4yrIJ0KoTXuYK2QKaUMz1BypxTYpS1iM4v49nqF7/hvwgtLu58dgCeEXM+095g9q t6zXLL3bvigmEMkC15CGAdg6VcdXhL+X35p0EgdGD/y1zC1b7AwMMw+YceyKBkyK8L 6UlWAOSGY22hVkNvhnGxlGoVHF2fg0rFuZ/5Qou4rFxhNYlSuI2MpDfV7JfpFWMrHy bce3C7KJ5w/MoKjaieWhTkIj6WkKizHganuOJMTOT7WiYHJQ6i2oEN04tZJXgwiG22 BVY98v2pkG12rj6xJ1rrWbMsd5MUONcTEO7WelliJd6f/pTHLoeIvjFiFnruiuUOm+ TE99WhckBRfIg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ard Biesheuvel , Dave Young , Sasha Levin Subject: [PATCH 6.19 827/844] x86/kexec: Copy ACPI root pointer address from config table Date: Sat, 28 Feb 2026 12:32:20 -0500 Message-ID: <20260228173244.1509663-828-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ard Biesheuvel [ Upstream commit e00ac9e5afb5d80c0168ec88d8e8662a54af8249 ] Dave reports that kexec may fail when the first kernel boots via the EFI stub but without EFI runtime services, as in that case, the RSDP address field in struct bootparams is never assigned. Kexec copies this value into the version of struct bootparams that it provides to the incoming kernel, which may have no other means to locate the ACPI root pointer. So take the value from the EFI config tables if no root pointer has been set in the first kernel's struct bootparams. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI= boot") Cc: # v6.1 Reported-by: Dave Young Tested-by: Dave Young Link: https://lore.kernel.org/linux-efi/aZQg_tRQmdKNadCg@darkstar.users.ipa= .redhat.com/ Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/x86/kernel/kexec-bzimage64.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzim= age64.c index c3244ac680d14..f3b451eb49be1 100644 --- a/arch/x86/kernel/kexec-bzimage64.c +++ b/arch/x86/kernel/kexec-bzimage64.c @@ -192,6 +192,13 @@ setup_efi_state(struct boot_params *params, unsigned l= ong params_load_addr, struct efi_info *current_ei =3D &boot_params.efi_info; struct efi_info *ei =3D ¶ms->efi_info; =20 + if (!params->acpi_rsdp_addr) { + if (efi.acpi20 !=3D EFI_INVALID_TABLE_ADDR) + params->acpi_rsdp_addr =3D efi.acpi20; + else if (efi.acpi !=3D EFI_INVALID_TABLE_ADDR) + params->acpi_rsdp_addr =3D efi.acpi; + } + if (!efi_enabled(EFI_RUNTIME_SERVICES)) return 0; =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C01D942A781; Sat, 28 Feb 2026 17:46:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300795; cv=none; b=sCd6z7/FQ3UaYuM+jN3tt+qjTyQ0dBdewqNjQ9eDL2+VXLQYFfI8F4k7VI8VAYVptu5ktD66alaa6OSibfSrZ2vd+2X0D3Nrfb3jGSUolg3avMrPtzVdF5hlWIAfRaxGooQwzTUOSq4zxRddQLmZS1Lk3N3NQwzidG1KipkFS8o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300795; c=relaxed/simple; bh=gbqZ++Duhupp4YG/TedHWSOdtQHqxkp2I7pBN0yhjOE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rYyQUilkHgWYxa3pJBeXAjvVLlQUX1WeelLh8C7ZBPyPuV9FE7EHQe03AnbPGIMG4QP2yyQfp4euZN+s76CNv/QI9Wulfsj71BMBmf0byFvBbKaywRjThD/t4H1ovFCFscmSv92xxrvRDSaP0yqIguqH+vkcUw0fTRy/CUgjyf4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UIamdP1Z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UIamdP1Z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF189C19423; Sat, 28 Feb 2026 17:46:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300795; bh=gbqZ++Duhupp4YG/TedHWSOdtQHqxkp2I7pBN0yhjOE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UIamdP1Z1u9nMN3+muvIkyRwMRE/6Qvyi9V4hL6XRU4HOZ2EUrjgKwtsJkW0keNOG Ml1SHXWCOQpLvPlNHdZkZscKatq9kAcd1gvx4fyXvxubCrgE4dSXwYfQ0bijmw97Co LC6/b8SNeZv6zZyy8IWtER2ciZrpkU6e+iOUz1W+qEC/tArQ/RZdrwpUEHr2mXvYx1 I8SP8Vb+fg97oMaKc4phS6IZv8fQ3oPlAPCuSGNKzMyyg6vo/WhyoYi39NXMIInMgY CEgCGXFs5O5bm6MyUobck0euxxogsJNZLBwbolfSy7y7m8/4+EeOhOPQ+bRDIiDXyB uaf8+jxr/aT2g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kai Aizen , Pavel Begunkov , Jens Axboe , Sasha Levin Subject: [PATCH 6.19 828/844] io_uring/zcrx: fix user_ref race between scrub and refill paths Date: Sat, 28 Feb 2026 12:32:21 -0500 Message-ID: <20260228173244.1509663-829-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kai Aizen [ Upstream commit 003049b1c4fb8aabb93febb7d1e49004f6ad653b ] The io_zcrx_put_niov_uref() function uses a non-atomic check-then-decrement pattern (atomic_read followed by separate atomic_dec) to manipulate user_refs. This is serialized against other callers by rq_lock, but io_zcrx_scrub() modifies the same counter with atomic_xchg() WITHOUT holding rq_lock. On SMP systems, the following race exists: CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock) put_niov_uref: atomic_read(uref) - 1 // window opens atomic_xchg(uref, 0) - 1 return_niov_freelist(niov) [PUSH #1] // window closes atomic_dec(uref) - wraps to -1 returns true return_niov(niov) return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE] The same niov is pushed to the freelist twice, causing free_count to exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds write (a u32 value) past the kvmalloc'd freelist array into the adjacent slab object. Fix this by replacing the non-atomic read-then-dec in io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically tests and decrements user_refs. This makes the operation safe against concurrent atomic_xchg from scrub without requiring scrub to acquire rq_lock. Fixes: 34a3e60821ab ("io_uring/zcrx: implement zerocopy receive pp memory p= rovider") Cc: stable@vger.kernel.org Signed-off-by: Kai Aizen [pavel: removed a warning and a comment] Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- io_uring/zcrx.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c index d41aa01a26d31..93da8933a91fa 100644 --- a/io_uring/zcrx.c +++ b/io_uring/zcrx.c @@ -337,10 +337,14 @@ static inline atomic_t *io_get_user_counter(struct ne= t_iov *niov) static bool io_zcrx_put_niov_uref(struct net_iov *niov) { atomic_t *uref =3D io_get_user_counter(niov); + int old; + + old =3D atomic_read(uref); + do { + if (unlikely(old =3D=3D 0)) + return false; + } while (!atomic_try_cmpxchg(uref, &old, old - 1)); =20 - if (unlikely(!atomic_read(uref))) - return false; - atomic_dec(uref); return true; } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4EFA42A79B; Sat, 28 Feb 2026 17:46:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300797; cv=none; b=hmU3zzzqjZutwMonCVTa+g8Vln7/UD5uSHAcZrNE7zmU16T/gDQcKGDSYL5nhk5kDIps1fLcqq0LHYoSHMIIE2LEIewGvUCR89iWkiuyCyP1Ms6wKZ+fiwjjlopdAShuVV0CbEZi+BKwy3B0P5SHyG3/ZyyjQvorFTsa0CYFqww= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300797; c=relaxed/simple; bh=+iy7ptYSLkD1fYrg74BQKN/mzogfPzwxLiHBiEWfsOA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eG1jzKWP5VYAeHMvF25mfP+7EMlJCq9eZ4CMp2MtVJHLnlJ4EPqfS9i3u2VpmdaLGMJ9idGIuriM3CR1OKZ8Y9r7Ksgir+dO3eG2pdtqVsruKj7zGha+X9hHbc+kt/Yg2zG73tWRJB8tXyg3VTDl1DaXFItFL3UC6HW2YfYwTXY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Sc+8xAOv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Sc+8xAOv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEEEAC116D0; Sat, 28 Feb 2026 17:46:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300796; bh=+iy7ptYSLkD1fYrg74BQKN/mzogfPzwxLiHBiEWfsOA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Sc+8xAOvb33lqZNTPgNA7h1/5pFruC6MwAci8/Rkmt8QqwUJEAw2GuC3M7OkAA1jP F3PPap9UKXOaF3gTIDYgc3lG7XZzyJuk9Kb4bk8qlMvnmnhJd9ucx/j0xa8MfmyhH4 bH4cG5Jjed7GwwjQs4SWZHjLcCFE+2+/BQ03FmZBGHKZcXBJhm0NoOWVNiAfFSsRT/ vUvB5bOc6W8OBdTiaWgCBLMDz01DAsY2WGTxB+ZSHMTuMmvna1pSdMUSUFktzDIuvh uqyL/JDaLzN+k84z9W7M5hR+6Lco6EdX8sKLA29r8AQAzvHLrR9XAFzK3UrkNzls5O ctyAn1ThOzD7g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benno Lossin , Gary Guo , Daniel Almeida , Danilo Krummrich , Miguel Ojeda , Sasha Levin Subject: [PATCH 6.19 829/844] rust: irq: add `'static` bounds to irq callbacks Date: Sat, 28 Feb 2026 12:32:22 -0500 Message-ID: <20260228173244.1509663-830-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benno Lossin [ Upstream commit 621609f1e5ca43a75edd497dd1c28bd84aa66433 ] These callback functions take a generic `T` that is used in the body as the generic argument in `Registration` and `ThreadedRegistration`. Those types require `T: 'static`, but due to a compiler bug this requirement isn't propagated to the function. Thus add the bound. This was caught in the upstream Rust CI [1]. [ The three errors looked similar and will start appearing with Rust 1.95.0 (expected 2026-04-16). The first one was: error[E0310]: the parameter type `T` may not live long enough Error: --> rust/kernel/irq/request.rs:266:43 | 266 | let registration =3D unsafe { &*(ptr as *const Registration= ) }; | ^^^^^^^^^^^^^^^^^^^^^^ | | | the parameter type `T= ` must be valid for the static lifetime... | ...so that the type `= T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound | 264 | unsafe extern "C" fn handle_irq_callback(= _irq: i32, ptr: *mut c_void) -> c_uint { | +++++++++ - Miguel ] Link: https://github.com/rust-lang/rust/pull/149389 [1] Signed-off-by: Benno Lossin Cc: stable@vger.kernel.org Fixes: 29e16fcd67ee ("rust: irq: add &Device argument to irq callbac= ks") Reviewed-by: Gary Guo Reviewed-by: Daniel Almeida Acked-by: Danilo Krummrich Link: https://lore.kernel.org/rust-for-linux/20260217222425.8755-1-cole@unw= rap.rs/ Link: https://patch.msgid.link/20260214092740.3201946-1-lossin@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- rust/kernel/irq/request.rs | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/rust/kernel/irq/request.rs b/rust/kernel/irq/request.rs index b150563fdef80..2ceeaeb0543a4 100644 --- a/rust/kernel/irq/request.rs +++ b/rust/kernel/irq/request.rs @@ -261,7 +261,10 @@ pub fn synchronize(&self, dev: &Device) -> Resu= lt { /// # Safety /// /// This function should be only used as the callback in `request_irq`. -unsafe extern "C" fn handle_irq_callback(_irq: i32, ptr: *mut = c_void) -> c_uint { +unsafe extern "C" fn handle_irq_callback( + _irq: i32, + ptr: *mut c_void, +) -> c_uint { // SAFETY: `ptr` is a pointer to `Registration` set in `Registratio= n::new` let registration =3D unsafe { &*(ptr as *const Registration) }; // SAFETY: The irq callback is removed before the device is unbound, s= o the fact that the irq @@ -480,7 +483,7 @@ pub fn synchronize(&self, dev: &Device) -> Resul= t { /// # Safety /// /// This function should be only used as the callback in `request_threaded= _irq`. -unsafe extern "C" fn handle_threaded_irq_callback( +unsafe extern "C" fn handle_threaded_irq_callback( _irq: i32, ptr: *mut c_void, ) -> c_uint { @@ -496,7 +499,10 @@ pub fn synchronize(&self, dev: &Device) -> Resu= lt { /// # Safety /// /// This function should be only used as the callback in `request_threaded= _irq`. -unsafe extern "C" fn thread_fn_callback(_irq: i32, ptr= : *mut c_void) -> c_uint { +unsafe extern "C" fn thread_fn_callback( + _irq: i32, + ptr: *mut c_void, +) -> c_uint { // SAFETY: `ptr` is a pointer to `ThreadedRegistration` set in `Thr= eadedRegistration::new` let registration =3D unsafe { &*(ptr as *const ThreadedRegistration= ) }; // SAFETY: The irq callback is removed before the device is unbound, s= o the fact that the irq --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BEC9642A7B8; Sat, 28 Feb 2026 17:46:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300797; cv=none; b=IXNmh6leUZQkpkYaZZe4XxbDnpI2k/FK+zuDOXP3qKRmGG7I3BPGvm59JZ0iPkTH9Nn0WWKd0yMB9PABL4yrkASyUJT01uyVriwXSXBMZEsJ3F+BByShC75Nwt1HycDE0SVhCrfQLdlC5P6CekvGpxqGvqzakwSLdbaMGggieuQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300797; c=relaxed/simple; bh=FoIjzdS00i5VPlniV9Kw+gfba6hiPgszo8/fC9hnjXc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cjqE8AKKNRo8cbMi5tLzuPYYFXbt+hXRnXxNx8OH02+1Jh/MDvBwJYb2VeYqqgD2mmmvT+3KmjN+iCA1MbQag9Anc7PlQXFzVhI22I3cBkXLC53/Y9I1Mxxf2H/rVFphGaQ1a3M1jjeUElYC/++leIHdDAi9atBi4VlMstigK00= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lx3iMF5Y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lx3iMF5Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E99CC19423; Sat, 28 Feb 2026 17:46:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300797; bh=FoIjzdS00i5VPlniV9Kw+gfba6hiPgszo8/fC9hnjXc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lx3iMF5YpLjv0q/ObAm9Z7z0RcKy3WhI/uJPV+9///1LO/2Q87jtRjwzBO+w/ANaQ 3LK1PFh84jE1d41gHu3tFCKCnreY1JO4ETIdmERs0cBfkXfV7qxC5ARjAgfwfiZJDY aqSn7NH70zlBam+R3jEceu9LWORGwcyMbRR8RW+MPKPVCCO6z4OLW3sPeHdUDPHZZ8 fwC9XqhYZmdGjoVmTysjVoAHdbqUslnrSjH9KEvxHhBHzJNENQ6LvyoMP/YluI9jpt KMuLCtOfeHC4ShVK7fO7BelGK6xiu+hgPXOss7xLDQaDZJM9rMZC0FJRl7LTufh5WN auCI/U49FOGGQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benno Lossin , Miguel Ojeda , Sasha Levin Subject: [PATCH 6.19 830/844] rust: pin-init: replace clippy `expect` with `allow` Date: Sat, 28 Feb 2026 12:32:23 -0500 Message-ID: <20260228173244.1509663-831-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benno Lossin [ Upstream commit a58b8764aed9648357b1c5b6368c9943ba33b7f9 ] `clippy` has changed behavior in [1] (Rust 1.95) where it no longer warns about the `let_and_return` lint when a comment is placed between the let binding and the return expression. Nightly thus fails to build, because the expectation is no longer fulfilled. Thus replace the expectation with an `allow`. [ The errors were: error: this lint expectation is unfulfilled --> rust/pin-init/src/lib.rs:1279:10 | 1279 | #[expect(clippy::let_and_return)] | ^^^^^^^^^^^^^^^^^^^^^^ | =3D note: `-D unfulfilled-lint-expectations` implied by `-D warn= ings` =3D help: to override `-D warnings` add `#[allow(unfulfilled_lin= t_expectations)]` error: this lint expectation is unfulfilled --> rust/pin-init/src/lib.rs:1295:10 | 1295 | #[expect(clippy::let_and_return)] | ^^^^^^^^^^^^^^^^^^^^^^ - Miguel ] Link: https://github.com/rust-lang/rust-clippy/pull/16461 [1] Signed-off-by: Benno Lossin Cc: stable@vger.kernel.org # Needed in 6.18.y and later. Link: https://patch.msgid.link/20260215132232.1549861-1-lossin@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- rust/pin-init/src/lib.rs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rust/pin-init/src/lib.rs b/rust/pin-init/src/lib.rs index 8dc9dd5ac6fd3..3da65db9e2dd3 100644 --- a/rust/pin-init/src/lib.rs +++ b/rust/pin-init/src/lib.rs @@ -1276,13 +1276,13 @@ unsafe fn __pinned_init(self, slot: *mut T) -> Resu= lt<(), E> { /// /// - `*mut U` must be castable to `*mut T` and any value of type `T` writ= ten through such a /// pointer must result in a valid `U`. -#[expect(clippy::let_and_return)] pub const unsafe fn cast_pin_init(init: impl PinInit) -> im= pl PinInit { // SAFETY: initialization delegated to a valid initializer. Cast is va= lid by function safety // requirements. let res =3D unsafe { pin_init_from_closure(|ptr: *mut U| init.__pinned= _init(ptr.cast::())) }; // FIXME: remove the let statement once the nightly-MSRV allows it (1.= 78 otherwise encounters a // cycle when computing the type returned by this function) + #[allow(clippy::let_and_return)] res } =20 @@ -1292,13 +1292,13 @@ unsafe fn __pinned_init(self, slot: *mut T) -> Resu= lt<(), E> { /// /// - `*mut U` must be castable to `*mut T` and any value of type `T` writ= ten through such a /// pointer must result in a valid `U`. -#[expect(clippy::let_and_return)] pub const unsafe fn cast_init(init: impl Init) -> impl Init= { // SAFETY: initialization delegated to a valid initializer. Cast is va= lid by function safety // requirements. let res =3D unsafe { init_from_closure(|ptr: *mut U| init.__init(ptr.c= ast::())) }; // FIXME: remove the let statement once the nightly-MSRV allows it (1.= 78 otherwise encounters a // cycle when computing the type returned by this function) + #[allow(clippy::let_and_return)] res } =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C341F42B381; Sat, 28 Feb 2026 17:46:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300798; cv=none; b=Bx5kc/3faWcf9YAccZB8shApFZF5gGC5joxik6qa1CB+0Z/czHUtPlFzvqS1eGPxixbLNZ+8bQOmahx4BE5Vwe8o4186Y3Y7sQpQGdq6/IS/F44M1XylZs14gU7UsPs89ZQzb2nmDwaOqeCXjXIG/2z2JkBp0Cp6wWvr3t/93ws= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300798; c=relaxed/simple; bh=hltn4iAg83Z7gjNUIC0IGnvd9Mk/IAu0sNdAKc0pSVM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Bb65We3lu60FTTgywoqkNoK3nYofK/2R8RyCLDTpiY2TXBqJhsIyv09jg4IbzsV+5ZcxJ5ii7a/HHq0IEZXSfdQ3kIAxcygZVT0qufZHABoFyXZPr+2WCGMfktra70DCxd3MW6XTTPFwGEB7cT+scvjhe6X0QFzBnn5wn3+HqYE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MiflLcv3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MiflLcv3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2E8AC116D0; Sat, 28 Feb 2026 17:46:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300798; bh=hltn4iAg83Z7gjNUIC0IGnvd9Mk/IAu0sNdAKc0pSVM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MiflLcv3dvUJUnaEc6Y5qfWGjntnn/SjM/rwSvtNf3RDalXrRYb3WIyNTKm6H/b7/ MLimeRwqPqSnCkX06VPQMwxpNtdPB+UVGuyg5sCaukjOzL7023vPd6g0pvwScNkKym hDTlrnB1sxpq47M4S3AmtrYVFAdEjRzI2iWCjpoUKPcCxFhXoQLVV9JCteTF0hB7xE 2DBRZ4XTKgrLovcCOKRTj2ONZs/C9J6+Gl/WstEHRLLgEVsl3ykJTnF4cxvCdJxJuW rTCFvnTZ0DYjSbQPnAjla5jX31yohW4Eoa10xdByvMEDlXB8nNJCY7grfE/HstEl1I h6jsEMQvM4yxQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Marc Zyngier , Hyesoo Yu , Quentin Perret , Will Deacon , Sasha Levin Subject: [PATCH 6.19 831/844] arm64: Force the use of CNTVCT_EL0 in __delay() Date: Sat, 28 Feb 2026 12:32:24 -0500 Message-ID: <20260228173244.1509663-832-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marc Zyngier [ Upstream commit 29cc0f3aa7c64d3b3cb9d94c0a0984ba6717bf72 ] 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 Reported-by: Quentin Perret Reviewed-by: Quentin Perret Fixes: 7d26b0516a0d ("arm64: Use WFxT for __delay() when possible") Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/ktosachvft2cgqd5qkukn275ugmhy6xrhxur4zqpdxl= fr3qh5h@o3zrfnsq63od Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- arch/arm64/lib/delay.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c index cb2062e7e2340..d02341303899e 100644 --- a/arch/arm64/lib/delay.c +++ b/arch/arm64/lib/delay.c @@ -23,9 +23,20 @@ static inline unsigned long xloops_to_cycles(unsigned lo= ng xloops) return (xloops * loops_per_jiffy * HZ) >> 32; } =20 +/* + * Force the use of CNTVCT_EL0 in order to have the same base as WFxT. + * This avoids some annoying issues when CNTVOFF_EL2 is not reset 0 on a + * KVM host running at EL1 until we do a vcpu_put() on the vcpu. When + * running at EL2, the effective offset is always 0. + * + * Note that userspace cannot change the offset behind our back either, + * as the vcpu mutex is held as long as KVM_RUN is in progress. + */ +#define __delay_cycles() __arch_counter_get_cntvct_stable() + void __delay(unsigned long cycles) { - cycles_t start =3D get_cycles(); + cycles_t start =3D __delay_cycles(); =20 if (alternative_has_cap_unlikely(ARM64_HAS_WFXT)) { u64 end =3D start + cycles; @@ -35,17 +46,17 @@ void __delay(unsigned long cycles) * early, use a WFET loop to complete the delay. */ wfit(end); - while ((get_cycles() - start) < cycles) + while ((__delay_cycles() - start) < cycles) wfet(end); } else if (arch_timer_evtstrm_available()) { const cycles_t timer_evt_period =3D USECS_TO_CYCLES(ARCH_TIMER_EVT_STREAM_PERIOD_US); =20 - while ((get_cycles() - start + timer_evt_period) < cycles) + while ((__delay_cycles() - start + timer_evt_period) < cycles) wfe(); } =20 - while ((get_cycles() - start) < cycles) + while ((__delay_cycles() - start) < cycles) cpu_relax(); } EXPORT_SYMBOL(__delay); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F35A742B3AB; Sat, 28 Feb 2026 17:46:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300800; cv=none; b=MV3UlKJxwYT1wRIElFtUkcCtkzpX/dKehzQG7weODcvUDtdSBsY8F28Evul6S/XMPo9nW6FKp/KYvJIfwz5m/mYeOIAOBIxBf2F4QtuXxmowE2aub+Kq0TFhlNtB8Xn5COST7PhSOCQyGx1q3bz0flTW2Oqd/vXZ8Eo7GaECgIc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300800; c=relaxed/simple; bh=DywTTD/mFYVFeVIeDP4xYU2oPCzjCoYlZdqd8b1uyZI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RL5tuLs7sdwze54tQfao+uK3tsBIHnsiH/TX3Amk00cbfd7J7JnjOqrwNzEdQKRDjuPilftLc5GsEd7q6GJCoYZzaAoXkv7Bvk+sAJmM4DyPxpakzxLmHbs2EY+16ix9LH3L7GiuJoQl30gKE+5mWXaJgNBJtxeWz/cMIe5MAc8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kM3C10cq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kM3C10cq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB2D1C19425; Sat, 28 Feb 2026 17:46:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300799; bh=DywTTD/mFYVFeVIeDP4xYU2oPCzjCoYlZdqd8b1uyZI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kM3C10cqmKdX9+JYbTvhijUTob2SEJeC0N1PTbhqUbNWG2TpwWZEgEAw7Av22TzqW Uih/uAaG0QkCwi65f/a7biDHIyl64ECf4ocBle2lbWy89njy6JaQumHpoqIOUiZERj fyUn7dgzPLGevfUem/h+r7FHrjkBPWz9t8a8j3XN5OjxCnMpStHVzkjfpnwIK1FmZH WXz0t/GINkfkz9PrCCYdRbg0iBqW9DyUDWu2V0ssJXuT7LkTkNohloDm7eacyuZjC6 neif6Bebz0vN38geyWyd5dcOAVStULy21Z06P/e1BLk8xRCOL+QE6u3nuTXZOKwUC2 H2uWlLrz8MNQg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Charlene Liu , Mario Limonciello , Ovidiu Bunea , Ray Wu , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 832/844] drm/amd/display: Correct logic check error for fastboot Date: Sat, 28 Feb 2026 12:32:25 -0500 Message-ID: <20260228173244.1509663-833-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Charlene Liu [ Upstream commit b6a65009e7ce3f0cc72da18f186adb60717b51a0 ] [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 Reviewed-by: Ovidiu Bunea Signed-off-by: Charlene Liu Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c b/dr= ivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c index 3d2673a22759a..8b8410ef3e47a 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c @@ -1941,8 +1941,8 @@ void dce110_enable_accelerated_mode(struct dc *dc, st= ruct dc_state *context) =20 get_edp_streams(context, edp_streams, &edp_stream_num); =20 - /* Check fastboot support, disable on DCE 6-8 because of blank screens */ - if (edp_num && edp_stream_num && dc->ctx->dce_version < DCE_VERSION_10_0)= { + /* Check fastboot support, disable on DCE 6-8-10 because of blank screens= */ + if (edp_num && edp_stream_num && dc->ctx->dce_version > DCE_VERSION_10_0)= { for (i =3D 0; i < edp_num; i++) { edp_link =3D edp_links[i]; if (edp_link !=3D edp_streams[0]->link) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D59784A1396; Sat, 28 Feb 2026 17:46:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300800; cv=none; b=UCsGY8w4FT9Nz4uEK0Bjy6hcNb+kiApeOh6dZxugrxvlwByxIYhcwle9UNgjvI/y9UEAHUKcnrJhzbrA1N8hrETkocaID2ng4J0uockVZO4K5NE9rE+M1KFSsPAqRK5s1sl0T6EmGm7qIhWpvyZcZSnPbQmpHz78WRBTpFfHCLI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300800; c=relaxed/simple; bh=2scoCBvhZAIoQeLtM290ODpfT1nL/8CztbW9CC9dEcQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CqtmswGSpOjk6uBHURdV9JXBp3Jg6pQqub/0c1rHpXwltybnDHC0H0Dn37r2op79rLo4N2yk3zVNO2rigGJWc1uy9MBsafq22UPQ6dog9luEuwJWJNgmfo+SomQByljXbdJzIgH0N79COtcrMQooLFlK38K5M7e/w5SYv+OEGY0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YGXdmVrF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YGXdmVrF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28729C19423; Sat, 28 Feb 2026 17:46:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300800; bh=2scoCBvhZAIoQeLtM290ODpfT1nL/8CztbW9CC9dEcQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YGXdmVrFxBJfQ+UHBnXmukjW3Mk0yyjQgWIZhNWdRBZNynoW90zbWpOuW/ROUSeS5 t2oqRvxrXxfKlsq6On2Sjr/I9DowI79ZUExxAQjAmw7ckCIX2Ck27nYpWs05iOc4Ib OoN8cRRaQEVpYnEgreyPKQCoMSnjcAchHUNIqEpBgAHCnqfvsHT7E8tU8uqxUYuFV5 m2Enz2XjtcTn2woNS240VJI1Vw7olgbT01/In45KQxMUZz1OzYqUwysEeVqw7IKSxQ 5bauBZD1FASIRA9YS15blNouDGf8t1RguEHAlZ2yvkSbvI8XSjfQ8JmcfWUIsMp1Jn I2MR3whrX6LOQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alex Deucher , Mario Kleiner , Sasha Levin Subject: [PATCH 6.19 833/844] drm/amdgpu: keep vga memory on MacBooks with switchable graphics Date: Sat, 28 Feb 2026 12:32:26 -0500 Message-ID: <20260228173244.1509663-834-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alex Deucher [ Upstream commit 096bb75e13cc508d3915b7604e356bcb12b17766 ] 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 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4302 Cc: stable@vger.kernel.org Cc: Mario Kleiner Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c b/drivers/gpu/drm/amd/= amdgpu/amdgpu_gmc.c index 2b37398337afc..b8613888c5c33 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c @@ -1019,6 +1019,16 @@ void amdgpu_gmc_get_vbios_allocations(struct amdgpu_= device *adev) case CHIP_RENOIR: adev->mman.keep_stolen_vga_memory =3D true; break; + case CHIP_POLARIS10: + case CHIP_POLARIS11: + case CHIP_POLARIS12: + /* MacBookPros with switchable graphics put VRAM at 0 when + * the iGPU is enabled which results in cursor issues if + * the cursor ends up at 0. Reserve vram at 0 in that case. + */ + if (adev->gmc.vram_start =3D=3D 0) + adev->mman.keep_stolen_vga_memory =3D true; + break; default: adev->mman.keep_stolen_vga_memory =3D false; break; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C89D142C274; Sat, 28 Feb 2026 17:46:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300801; cv=none; b=V3/sBhRFosc9Fj1rvMnwBnVc4hS+wcne9xIcDS4E3UCvP5EIydJ2o3DBs7ERsXJXADz2LvETv9aXQ0yrcLWpwoIGR0PUFL2J025OXkEkiKeLYKZX3uA5n97GRORCq+s2VbwpLbu/TphrFKzsmENaO0NMFfW+tkAzIc8DZeqYce4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300801; c=relaxed/simple; bh=Qma7NC5BURQs7e7UjsZJDrlGWn7LL53tfVNmQ/NvUsg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QKa5AAxEAtkKuO4jBeqV308Ir6W9E9QohOYMbla+MlwvtuxO+Fbey1O+TMnjSNwt7FcU0cfB+rEEcRb2OOVBkf8Ot2reXpc2BHu9pcr2Ei5S0cA7oTxb3aJwwDqasxz08FXkPcSk9bWg8ASkGmiMmvMUyoLZ/clLqTOzBd4ZW7Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X1Y9KtdE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X1Y9KtdE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07A6EC19425; Sat, 28 Feb 2026 17:46:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300801; bh=Qma7NC5BURQs7e7UjsZJDrlGWn7LL53tfVNmQ/NvUsg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X1Y9KtdEIhwj3ns797+LYkx75Dz8YXYSRb/+q9LxDmfyzQyvXBKgfJXxIqDG3xsCZ 2Achwl0/OwwfSlTGJz2deF8RuqgZRIAjzqH36NH9O0C7EFKPtz6JMYj8O/i2x/WGBB lUfTclWiu3hCyJS8DJXehRAxL0p3+I5ssSXoM1AR7Ux45nLSwl4h1fgm8A3MLYPp11 A5z33LJdaBuzR58HSoU/Ye7/OvCkghxHFg49GmOAmqhhP4b0znYQssftM+vzUakWqL TvSflWQqmJSvYiAU0GAcdzfYQ/Mvg203VA6uhm5gY3GaFU5GfD7OJZ34Wad1/mExNJ 17t+qjvNWBDYA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Michael Thalmeier , syzbot+740e04c2a93467a0f8c8@syzkaller.appspotmail.com, Jakub Kicinski , Sasha Levin Subject: [PATCH 6.19 834/844] net: nfc: nci: Fix parameter validation for packet data Date: Sat, 28 Feb 2026 12:32:27 -0500 Message-ID: <20260228173244.1509663-835-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Michael Thalmeier [ Upstream commit 571dcbeb8e635182bb825ae758399831805693c2 ] Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct). Fixes: 9c328f54741b ("net: nfc: nci: Add parameter validation for packet da= ta") Cc: stable@vger.kernel.org Signed-off-by: Michael Thalmeier Reported-by: syzbot+740e04c2a93467a0f8c8@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260218083000.301354-1-michael.thalmeier@ha= le.at Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- net/nfc/nci/ntf.c | 159 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 141 insertions(+), 18 deletions(-) diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c index 418b84e2b2605..c96512bb86531 100644 --- a/net/nfc/nci/ntf.c +++ b/net/nfc/nci/ntf.c @@ -58,7 +58,7 @@ static int nci_core_conn_credits_ntf_packet(struct nci_de= v *ndev, struct nci_conn_info *conn_info; int i; =20 - if (skb->len < sizeof(struct nci_core_conn_credit_ntf)) + if (skb->len < offsetofend(struct nci_core_conn_credit_ntf, num_entries)) return -EINVAL; =20 ntf =3D (struct nci_core_conn_credit_ntf *)skb->data; @@ -68,6 +68,10 @@ static int nci_core_conn_credits_ntf_packet(struct nci_d= ev *ndev, if (ntf->num_entries > NCI_MAX_NUM_CONN) ntf->num_entries =3D NCI_MAX_NUM_CONN; =20 + if (skb->len < offsetofend(struct nci_core_conn_credit_ntf, num_entries) + + ntf->num_entries * sizeof(struct conn_credit_entry)) + return -EINVAL; + /* update the credits */ for (i =3D 0; i < ntf->num_entries; i++) { ntf->conn_entries[i].conn_id =3D @@ -138,23 +142,48 @@ static int nci_core_conn_intf_error_ntf_packet(struct= nci_dev *ndev, static const __u8 * nci_extract_rf_params_nfca_passive_poll(struct nci_dev *ndev, struct rf_tech_specific_params_nfca_poll *nfca_poll, - const __u8 *data) + const __u8 *data, ssize_t data_len) { + /* Check if we have enough data for sens_res (2 bytes) */ + if (data_len < 2) + return ERR_PTR(-EINVAL); + nfca_poll->sens_res =3D __le16_to_cpu(*((__le16 *)data)); data +=3D 2; + data_len -=3D 2; + + /* Check if we have enough data for nfcid1_len (1 byte) */ + if (data_len < 1) + return ERR_PTR(-EINVAL); =20 nfca_poll->nfcid1_len =3D min_t(__u8, *data++, NFC_NFCID1_MAXSIZE); + data_len--; =20 pr_debug("sens_res 0x%x, nfcid1_len %d\n", nfca_poll->sens_res, nfca_poll->nfcid1_len); =20 + /* Check if we have enough data for nfcid1 */ + if (data_len < nfca_poll->nfcid1_len) + return ERR_PTR(-EINVAL); + memcpy(nfca_poll->nfcid1, data, nfca_poll->nfcid1_len); data +=3D nfca_poll->nfcid1_len; + data_len -=3D nfca_poll->nfcid1_len; + + /* Check if we have enough data for sel_res_len (1 byte) */ + if (data_len < 1) + return ERR_PTR(-EINVAL); =20 nfca_poll->sel_res_len =3D *data++; + data_len--; + + if (nfca_poll->sel_res_len !=3D 0) { + /* Check if we have enough data for sel_res (1 byte) */ + if (data_len < 1) + return ERR_PTR(-EINVAL); =20 - if (nfca_poll->sel_res_len !=3D 0) nfca_poll->sel_res =3D *data++; + } =20 pr_debug("sel_res_len %d, sel_res 0x%x\n", nfca_poll->sel_res_len, @@ -166,12 +195,21 @@ nci_extract_rf_params_nfca_passive_poll(struct nci_de= v *ndev, static const __u8 * nci_extract_rf_params_nfcb_passive_poll(struct nci_dev *ndev, struct rf_tech_specific_params_nfcb_poll *nfcb_poll, - const __u8 *data) + const __u8 *data, ssize_t data_len) { + /* Check if we have enough data for sensb_res_len (1 byte) */ + if (data_len < 1) + return ERR_PTR(-EINVAL); + nfcb_poll->sensb_res_len =3D min_t(__u8, *data++, NFC_SENSB_RES_MAXSIZE); + data_len--; =20 pr_debug("sensb_res_len %d\n", nfcb_poll->sensb_res_len); =20 + /* Check if we have enough data for sensb_res */ + if (data_len < nfcb_poll->sensb_res_len) + return ERR_PTR(-EINVAL); + memcpy(nfcb_poll->sensb_res, data, nfcb_poll->sensb_res_len); data +=3D nfcb_poll->sensb_res_len; =20 @@ -181,14 +219,29 @@ nci_extract_rf_params_nfcb_passive_poll(struct nci_de= v *ndev, static const __u8 * nci_extract_rf_params_nfcf_passive_poll(struct nci_dev *ndev, struct rf_tech_specific_params_nfcf_poll *nfcf_poll, - const __u8 *data) + const __u8 *data, ssize_t data_len) { + /* Check if we have enough data for bit_rate (1 byte) */ + if (data_len < 1) + return ERR_PTR(-EINVAL); + nfcf_poll->bit_rate =3D *data++; + data_len--; + + /* Check if we have enough data for sensf_res_len (1 byte) */ + if (data_len < 1) + return ERR_PTR(-EINVAL); + nfcf_poll->sensf_res_len =3D min_t(__u8, *data++, NFC_SENSF_RES_MAXSIZE); + data_len--; =20 pr_debug("bit_rate %d, sensf_res_len %d\n", nfcf_poll->bit_rate, nfcf_poll->sensf_res_len); =20 + /* Check if we have enough data for sensf_res */ + if (data_len < nfcf_poll->sensf_res_len) + return ERR_PTR(-EINVAL); + memcpy(nfcf_poll->sensf_res, data, nfcf_poll->sensf_res_len); data +=3D nfcf_poll->sensf_res_len; =20 @@ -198,22 +251,49 @@ nci_extract_rf_params_nfcf_passive_poll(struct nci_de= v *ndev, static const __u8 * nci_extract_rf_params_nfcv_passive_poll(struct nci_dev *ndev, struct rf_tech_specific_params_nfcv_poll *nfcv_poll, - const __u8 *data) + const __u8 *data, ssize_t data_len) { + /* Skip 1 byte (reserved) */ + if (data_len < 1) + return ERR_PTR(-EINVAL); + ++data; + data_len--; + + /* Check if we have enough data for dsfid (1 byte) */ + if (data_len < 1) + return ERR_PTR(-EINVAL); + nfcv_poll->dsfid =3D *data++; + data_len--; + + /* Check if we have enough data for uid (8 bytes) */ + if (data_len < NFC_ISO15693_UID_MAXSIZE) + return ERR_PTR(-EINVAL); + memcpy(nfcv_poll->uid, data, NFC_ISO15693_UID_MAXSIZE); data +=3D NFC_ISO15693_UID_MAXSIZE; + return data; } =20 static const __u8 * nci_extract_rf_params_nfcf_passive_listen(struct nci_dev *ndev, struct rf_tech_specific_params_nfcf_listen *nfcf_listen, - const __u8 *data) + const __u8 *data, ssize_t data_len) { + /* Check if we have enough data for local_nfcid2_len (1 byte) */ + if (data_len < 1) + return ERR_PTR(-EINVAL); + nfcf_listen->local_nfcid2_len =3D min_t(__u8, *data++, NFC_NFCID2_MAXSIZE); + data_len--; + + /* Check if we have enough data for local_nfcid2 */ + if (data_len < nfcf_listen->local_nfcid2_len) + return ERR_PTR(-EINVAL); + memcpy(nfcf_listen->local_nfcid2, data, nfcf_listen->local_nfcid2_len); data +=3D nfcf_listen->local_nfcid2_len; =20 @@ -364,7 +444,7 @@ static int nci_rf_discover_ntf_packet(struct nci_dev *n= dev, const __u8 *data; bool add_target =3D true; =20 - if (skb->len < sizeof(struct nci_rf_discover_ntf)) + if (skb->len < offsetofend(struct nci_rf_discover_ntf, rf_tech_specific_p= arams_len)) return -EINVAL; =20 data =3D skb->data; @@ -380,26 +460,42 @@ static int nci_rf_discover_ntf_packet(struct nci_dev = *ndev, pr_debug("rf_tech_specific_params_len %d\n", ntf.rf_tech_specific_params_len); =20 + if (skb->len < (data - skb->data) + + ntf.rf_tech_specific_params_len + sizeof(ntf.ntf_type)) + return -EINVAL; + if (ntf.rf_tech_specific_params_len > 0) { switch (ntf.rf_tech_and_mode) { case NCI_NFC_A_PASSIVE_POLL_MODE: data =3D nci_extract_rf_params_nfca_passive_poll(ndev, - &(ntf.rf_tech_specific_params.nfca_poll), data); + &(ntf.rf_tech_specific_params.nfca_poll), data, + ntf.rf_tech_specific_params_len); + if (IS_ERR(data)) + return PTR_ERR(data); break; =20 case NCI_NFC_B_PASSIVE_POLL_MODE: data =3D nci_extract_rf_params_nfcb_passive_poll(ndev, - &(ntf.rf_tech_specific_params.nfcb_poll), data); + &(ntf.rf_tech_specific_params.nfcb_poll), data, + ntf.rf_tech_specific_params_len); + if (IS_ERR(data)) + return PTR_ERR(data); break; =20 case NCI_NFC_F_PASSIVE_POLL_MODE: data =3D nci_extract_rf_params_nfcf_passive_poll(ndev, - &(ntf.rf_tech_specific_params.nfcf_poll), data); + &(ntf.rf_tech_specific_params.nfcf_poll), data, + ntf.rf_tech_specific_params_len); + if (IS_ERR(data)) + return PTR_ERR(data); break; =20 case NCI_NFC_V_PASSIVE_POLL_MODE: data =3D nci_extract_rf_params_nfcv_passive_poll(ndev, - &(ntf.rf_tech_specific_params.nfcv_poll), data); + &(ntf.rf_tech_specific_params.nfcv_poll), data, + ntf.rf_tech_specific_params_len); + if (IS_ERR(data)) + return PTR_ERR(data); break; =20 default: @@ -596,7 +692,7 @@ static int nci_rf_intf_activated_ntf_packet(struct nci_= dev *ndev, const __u8 *data; int err =3D NCI_STATUS_OK; =20 - if (skb->len < sizeof(struct nci_rf_intf_activated_ntf)) + if (skb->len < offsetofend(struct nci_rf_intf_activated_ntf, rf_tech_spec= ific_params_len)) return -EINVAL; =20 data =3D skb->data; @@ -628,26 +724,41 @@ static int nci_rf_intf_activated_ntf_packet(struct nc= i_dev *ndev, if (ntf.rf_interface =3D=3D NCI_RF_INTERFACE_NFCEE_DIRECT) goto listen; =20 + if (skb->len < (data - skb->data) + ntf.rf_tech_specific_params_len) + return -EINVAL; + if (ntf.rf_tech_specific_params_len > 0) { switch (ntf.activation_rf_tech_and_mode) { case NCI_NFC_A_PASSIVE_POLL_MODE: data =3D nci_extract_rf_params_nfca_passive_poll(ndev, - &(ntf.rf_tech_specific_params.nfca_poll), data); + &(ntf.rf_tech_specific_params.nfca_poll), data, + ntf.rf_tech_specific_params_len); + if (IS_ERR(data)) + return -EINVAL; break; =20 case NCI_NFC_B_PASSIVE_POLL_MODE: data =3D nci_extract_rf_params_nfcb_passive_poll(ndev, - &(ntf.rf_tech_specific_params.nfcb_poll), data); + &(ntf.rf_tech_specific_params.nfcb_poll), data, + ntf.rf_tech_specific_params_len); + if (IS_ERR(data)) + return -EINVAL; break; =20 case NCI_NFC_F_PASSIVE_POLL_MODE: data =3D nci_extract_rf_params_nfcf_passive_poll(ndev, - &(ntf.rf_tech_specific_params.nfcf_poll), data); + &(ntf.rf_tech_specific_params.nfcf_poll), data, + ntf.rf_tech_specific_params_len); + if (IS_ERR(data)) + return -EINVAL; break; =20 case NCI_NFC_V_PASSIVE_POLL_MODE: data =3D nci_extract_rf_params_nfcv_passive_poll(ndev, - &(ntf.rf_tech_specific_params.nfcv_poll), data); + &(ntf.rf_tech_specific_params.nfcv_poll), data, + ntf.rf_tech_specific_params_len); + if (IS_ERR(data)) + return -EINVAL; break; =20 case NCI_NFC_A_PASSIVE_LISTEN_MODE: @@ -657,7 +768,9 @@ static int nci_rf_intf_activated_ntf_packet(struct nci_= dev *ndev, case NCI_NFC_F_PASSIVE_LISTEN_MODE: data =3D nci_extract_rf_params_nfcf_passive_listen(ndev, &(ntf.rf_tech_specific_params.nfcf_listen), - data); + data, ntf.rf_tech_specific_params_len); + if (IS_ERR(data)) + return -EINVAL; break; =20 default: @@ -668,6 +781,13 @@ static int nci_rf_intf_activated_ntf_packet(struct nci= _dev *ndev, } } =20 + if (skb->len < (data - skb->data) + + sizeof(ntf.data_exch_rf_tech_and_mode) + + sizeof(ntf.data_exch_tx_bit_rate) + + sizeof(ntf.data_exch_rx_bit_rate) + + sizeof(ntf.activation_params_len)) + return -EINVAL; + ntf.data_exch_rf_tech_and_mode =3D *data++; ntf.data_exch_tx_bit_rate =3D *data++; ntf.data_exch_rx_bit_rate =3D *data++; @@ -679,6 +799,9 @@ static int nci_rf_intf_activated_ntf_packet(struct nci_= dev *ndev, pr_debug("data_exch_rx_bit_rate 0x%x\n", ntf.data_exch_rx_bit_rate); pr_debug("activation_params_len %d\n", ntf.activation_params_len); =20 + if (skb->len < (data - skb->data) + ntf.activation_params_len) + return -EINVAL; + if (ntf.activation_params_len > 0) { switch (ntf.rf_interface) { case NCI_RF_INTERFACE_ISO_DEP: --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E200042C290; Sat, 28 Feb 2026 17:46:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300803; cv=none; b=oTu38s3FhbWNxZjmqSQskX9OPY93q4Z47zil0xoDXHr6DYMYj2g0foFDiE9OY8hZ9crD5YLPYOt5xjijrmfyqgzukBCGTUTXcC6QnrfrvnDW49FUSqRjugE9v2eKUd/gN2/ucIAG6hXsfjIuLekyrUdTszBC92sNlYxESfA2/Ao= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300803; c=relaxed/simple; bh=emS6QuFF9VEhdCkIz/+zQpypOAt1iUdrxrOV78XzjHQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=khIwubypNoQn/VsxFOjAZBS2erGzELF/wNCXqS8x4Q8UAm0a0ucUDdfy4oVEcTYQ12RwRk17lIipPLOvR4ZmPVMNrY5MtRM5foRRSMCck9wy4clK0BUiGkJpjGcJ5qFgbX6nRgC0pwernCTCyedlpsby9FsHKVyFFo2yofQI7mA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sqQWy5HA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sqQWy5HA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECAB1C116D0; Sat, 28 Feb 2026 17:46:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300802; bh=emS6QuFF9VEhdCkIz/+zQpypOAt1iUdrxrOV78XzjHQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sqQWy5HADR2ubVjlKmiuoQoIQcI0JzecJ6PGhcACZIewIsXYxCBLZsrHqKIFpEUiZ FRk3LhZkNuQBWC835euXMQwsVm8R1RXH6s7aO0SILLHAcCCrewhE6TzclpVBLdlmlo 9qsBBrVXVMEoXhkCbmxtoQVevnwh/oDSmES2GdLls4kx9230dI/jlYafJtG07TEXGs WU9nelDvzvWbhvWXs3aMdikM+ez6LeghVqFURVVVRoWyeN6AvJf2w7fFWiVpI3aA0o amhzJf8C7vc+8GiA5ALEIKOEsNt+XzoCycZOAcDzxfxssoaO8E/l6X1MkWCSlDwvE5 P5esuIjQUIosQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Daniil Dulov , kernel test robot , Dan Carpenter , "Masami Hiramatsu (Google)" , "Steven Rostedt (Google)" , Sasha Levin Subject: [PATCH 6.19 835/844] ring-buffer: Fix possible dereference of uninitialized pointer Date: Sat, 28 Feb 2026 12:32:28 -0500 Message-ID: <20260228173244.1509663-836-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Daniil Dulov [ Upstream commit f1547779402c4cd67755c33616b7203baa88420b ] There is a pointer head_page in rb_meta_validate_events() which is not initialized at the beginning of a function. This pointer can be dereferenced if there is a failure during reader page validation. In this case the contr= ol is passed to "invalid" label where the pointer is dereferenced in a loop. To fix the issue initialize orig_head and head_page before calling rb_validate_buffer. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable@vger.kernel.org Reported-by: kernel test robot Reported-by: Dan Carpenter Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260213100130.2013839-1-d.dulov@aladdin.ru Closes: https://lore.kernel.org/r/202406130130.JtTGRf7W-lkp@intel.com/ Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events") Signed-off-by: Daniil Dulov Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/trace/ring_buffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 630221b00838e..ad08430347b06 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -1918,6 +1918,8 @@ static void rb_meta_validate_events(struct ring_buffe= r_per_cpu *cpu_buffer) if (!meta || !meta->head_buffer) return; =20 + orig_head =3D head_page =3D cpu_buffer->head_page; + /* Do the reader page first */ ret =3D rb_validate_buffer(cpu_buffer->reader_page->page, cpu_buffer->cpu= ); if (ret < 0) { @@ -1928,7 +1930,6 @@ static void rb_meta_validate_events(struct ring_buffe= r_per_cpu *cpu_buffer) entry_bytes +=3D local_read(&cpu_buffer->reader_page->page->commit); local_set(&cpu_buffer->reader_page->entries, ret); =20 - orig_head =3D head_page =3D cpu_buffer->head_page; ts =3D head_page->page->time_stamp; =20 /* --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0A2942B3AD; Sat, 28 Feb 2026 17:46:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300803; cv=none; b=joh/RT/a15j9fWXbI5zXCabZSp1nNkXEphcXiwNy/GN0XphfLvc5ICKXyJwnwXFfkT2SOps4zi8J87N9c1bMn/07vtUqSvbILzBMYTr0Xv8xKZry4W+T/ixL2kx+9fzAuycwTrwNix/BYg/9vWtG4vWx0565wZZTFxqKUimA0N0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300803; c=relaxed/simple; bh=jMounPxqv3isWkbawRiFG1IEvs2hnYQdhs0x/ep8b94=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FRDW/QHQDmdrIBp6dqcFbQG/onrrsJNlOIauX+l8wCUacdBEjoP+o237Hzev2e860mFqzO9BP5oK0LUAA4LFyGOeSEaL/ldG/SgP0xj6nf/mxfnQxb0s9MBFvaY/RsKpFFi+nf8EiUImu+KpryUJynbZKbDDMzFXU7Mbj4bkSvw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o6667ocq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o6667ocq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 130F3C19425; Sat, 28 Feb 2026 17:46:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300803; bh=jMounPxqv3isWkbawRiFG1IEvs2hnYQdhs0x/ep8b94=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o6667ocq2xA1hNZtjjuUOWqpkkcUMj+7cWGjPReKscthlxolZEYILTMfXscst5bpp WoMg6qrEXolA2R+fZEVxx/ZtxDTG22hoWOqs2O0029BseDK3ponHOwG9ru7WN7n3BD U7n8u+zABqCaJYigwAsZLk4r02mf2QGyeJP5RqlQPEBA79fyaIVjfETmHlHtTR1Sg7 JMMr9/oOLAuA4xMEm+pVRiYxhti/hAFnAKP+y36C17/oMKgrLS6TF9uo5ZcmySm+eK 5OgyjFzPqMHFuTd2J6IAfTReBbSMkXcx8YTgjG/09BcdIB60zQ0FJM1IvWyp1tQ6LM KGrHt0iXCC8kg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Masami Hiramatsu (Google)" , Mathieu Desnoyers , "Steven Rostedt (Google)" , Sasha Levin Subject: [PATCH 6.19 836/844] tracing: ring-buffer: Fix to check event length before using Date: Sat, 28 Feb 2026 12:32:29 -0500 Message-ID: <20260228173244.1509663-837-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Masami Hiramatsu (Google)" [ Upstream commit 912b0ee248c529a4f45d1e7f568dc1adddbf2a4a ] Check the event length before adding it for accessing next index in rb_read_data_buffer(). Since this function is used for validating possibly broken ring buffers, the length of the event could be broken. In that case, the new event (e + len) can point a wrong address. To avoid invalid memory access at boot, check whether the length of each event is in the possible range before using it. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events") Link: https://patch.msgid.link/177123421541.142205.9414352170164678966.stgi= t@devnote2 Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/trace/ring_buffer.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index ad08430347b06..2f44063c666f2 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -1848,6 +1848,7 @@ static int rb_read_data_buffer(struct buffer_data_pag= e *dpage, int tail, int cpu struct ring_buffer_event *event; u64 ts, delta; int events =3D 0; + int len; int e; =20 *delta_ptr =3D 0; @@ -1855,9 +1856,12 @@ static int rb_read_data_buffer(struct buffer_data_pa= ge *dpage, int tail, int cpu =20 ts =3D dpage->time_stamp; =20 - for (e =3D 0; e < tail; e +=3D rb_event_length(event)) { + for (e =3D 0; e < tail; e +=3D len) { =20 event =3D (struct ring_buffer_event *)(dpage->data + e); + len =3D rb_event_length(event); + if (len <=3D 0 || len > tail - e) + return -1; =20 switch (event->type_len) { =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D917642CCD5; Sat, 28 Feb 2026 17:46:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300804; cv=none; b=jPW9NkjnWWyJYytsomu9MHMFzgFQAI9sV5Fr8zQw2VQAhL1vuZ0nV5p0wUaoYGnVLT1qokmZPrwYjKZp0dmUnHCKREdlpMXlNI2wGb4r+xik6CJ1mWeTkY98+hSDj32eety101fa4ysgop9iBjpT5ptlTcpIt+7bfnUM7pPnXkk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300804; c=relaxed/simple; bh=u6XffEUn8okCWeW12Hb68HWqNxZELSMa3aZJCkbcFKU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ul3ixAkcVIz/FW2nTeQu0YwLiUD70RzVZvtuZEblA0vGH7rjIX6FWfHEKgWvlmdbM+55WFZA9+5pBJNy+o+LoeP9R1pgiSMm8oByx5hfpY4fGWqpFnzPc49AvFVFL8gOA77WgXBCBT5ZxRKzpShx7BwCRUUMmzQGZR9UjxlFbW4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t5TNLsOD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="t5TNLsOD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05896C19424; Sat, 28 Feb 2026 17:46:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300804; bh=u6XffEUn8okCWeW12Hb68HWqNxZELSMa3aZJCkbcFKU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=t5TNLsODFJTp1lOxIeF8hv74H20XH6wyMj0NBu8TODnUejOpGKGUAyQxL5IjVJEhD c9DBjhADEluq6W13TWUu6ghEWH0Xl7u10bhCMZxqHQdhKh3yArLG3K7AoaOHJk5GBI QpSVn8pbbxs57S/NiD/NW8NuRBG55qxNmHgns6yzPpn1L+yQEXFlPhDg3FTCthMcAh +9SIBY6XvjSXU9fjJJQ4DZ+ZrhjUddfQL5vncukurQlKdDZW4+WEQpJjt+RWwnfSER UKBrogRdveDaYTMFp0GDQQVfQYz8qKb/Feabdn8iE6eWdBgLfvMcMKpn2ro2SPa6DF kH6iKHXPnA6Cw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Mark Rutland , Sasha Levin Subject: [PATCH 6.19 837/844] fgraph: Do not call handlers direct when not using ftrace_ops Date: Sat, 28 Feb 2026 12:32:30 -0500 Message-ID: <20260228173244.1509663-838-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Steven Rostedt [ Upstream commit f4ff9f646a4d373f9e895c2f0073305da288bc0a ] The function graph tracer was modified to us the ftrace_ops of the function tracer. This simplified the code as well as allowed more features of the function graph tracer. Not all architectures were converted over as it required the implementation of HAVE_DYNAMIC_FTRACE_WITH_ARGS to implement. For those architectures, it still did it the old way where the function graph tracer handle was called by the function tracer trampoline. The handler then had to check the hash to see if the registered handlers wanted to be called by that function or not. In order to speed up the function graph tracer that used ftrace_ops, if only one callback was registered with function graph, it would call its function directly via a static call. Now, if the architecture does not support the use of using ftrace_ops and still has the ftrace function trampoline calling the function graph handler, then by doing a direct call it removes the check against the handler's hash (list of functions it wants callbacks to), and it may call that handler for functions that the handler did not request calls for. On 32bit x86, which does not support the ftrace_ops use with function graph tracer, it shows the issue: ~# trace-cmd start -p function -l schedule ~# trace-cmd show # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 2) * 11898.94 us | schedule(); 3) # 1783.041 us | schedule(); 1) | schedule() { ------------------------------------------ 1) bash-8369 =3D> kworker-7669 ------------------------------------------ 1) | schedule() { ------------------------------------------ 1) kworker-7669 =3D> bash-8369 ------------------------------------------ 1) + 97.004 us | } 1) | schedule() { [..] Now by starting the function tracer is another instance: ~# trace-cmd start -B foo -p function This causes the function graph tracer to trace all functions (because the function trace calls the function graph tracer for each on, and the function graph trace is doing a direct call): ~# trace-cmd show # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 1) 1.669 us | } /* preempt_count_sub */ 1) + 10.443 us | } /* _raw_spin_unlock_irqrestore */ 1) | tick_program_event() { 1) | clockevents_program_event() { 1) 1.044 us | ktime_get(); 1) 6.481 us | lapic_next_event(); 1) + 10.114 us | } 1) + 11.790 us | } 1) ! 181.223 us | } /* hrtimer_interrupt */ 1) ! 184.624 us | } /* __sysvec_apic_timer_interrupt */ 1) | irq_exit_rcu() { 1) 0.678 us | preempt_count_sub(); When it should still only be tracing the schedule() function. To fix this, add a macro FGRAPH_NO_DIRECT to be set to 0 when the architecture does not support function graph use of ftrace_ops, and set to 1 otherwise. Then use this macro to know to allow function graph tracer to call the handlers directly or not. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Mark Rutland Link: https://patch.msgid.link/20260218104244.5f14dade@gandalf.local.home Fixes: cc60ee813b503 ("function_graph: Use static_call and branch to optimi= ze entry function") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/ftrace.h | 13 ++++++++++--- kernel/trace/fgraph.c | 12 +++++++++++- 2 files changed, 21 insertions(+), 4 deletions(-) diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h index fa74ae5cc9dae..d029afcd22a5d 100644 --- a/include/linux/ftrace.h +++ b/include/linux/ftrace.h @@ -1064,10 +1064,17 @@ static inline bool is_ftrace_trampoline(unsigned lo= ng addr) =20 #ifdef CONFIG_FUNCTION_GRAPH_TRACER #ifndef ftrace_graph_func -#define ftrace_graph_func ftrace_stub -#define FTRACE_OPS_GRAPH_STUB FTRACE_OPS_FL_STUB +# define ftrace_graph_func ftrace_stub +# define FTRACE_OPS_GRAPH_STUB FTRACE_OPS_FL_STUB +/* + * The function graph is called every time the function tracer is called. + * It must always test the ops hash and cannot just directly call + * the handler. + */ +# define FGRAPH_NO_DIRECT 1 #else -#define FTRACE_OPS_GRAPH_STUB 0 +# define FTRACE_OPS_GRAPH_STUB 0 +# define FGRAPH_NO_DIRECT 0 #endif #endif /* CONFIG_FUNCTION_GRAPH_TRACER */ =20 diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c index 4df766c690f92..40d373d65f9b9 100644 --- a/kernel/trace/fgraph.c +++ b/kernel/trace/fgraph.c @@ -539,7 +539,11 @@ static struct fgraph_ops fgraph_stub =3D { static struct fgraph_ops *fgraph_direct_gops =3D &fgraph_stub; DEFINE_STATIC_CALL(fgraph_func, ftrace_graph_entry_stub); DEFINE_STATIC_CALL(fgraph_retfunc, ftrace_graph_ret_stub); +#if FGRAPH_NO_DIRECT +static DEFINE_STATIC_KEY_FALSE(fgraph_do_direct); +#else static DEFINE_STATIC_KEY_TRUE(fgraph_do_direct); +#endif =20 /** * ftrace_graph_stop - set to permanently disable function graph tracing @@ -843,7 +847,7 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, u= nsigned long frame_pointe bitmap =3D get_bitmap_bits(current, offset); =20 #ifdef CONFIG_HAVE_STATIC_CALL - if (static_branch_likely(&fgraph_do_direct)) { + if (!FGRAPH_NO_DIRECT && static_branch_likely(&fgraph_do_direct)) { if (test_bit(fgraph_direct_gops->idx, &bitmap)) static_call(fgraph_retfunc)(&trace, fgraph_direct_gops, fregs); } else @@ -1285,6 +1289,9 @@ static void ftrace_graph_enable_direct(bool enable_br= anch, struct fgraph_ops *go trace_func_graph_ret_t retfunc =3D NULL; int i; =20 + if (FGRAPH_NO_DIRECT) + return; + if (gops) { func =3D gops->entryfunc; retfunc =3D gops->retfunc; @@ -1308,6 +1315,9 @@ static void ftrace_graph_enable_direct(bool enable_br= anch, struct fgraph_ops *go =20 static void ftrace_graph_disable_direct(bool disable_branch) { + if (FGRAPH_NO_DIRECT) + return; + if (disable_branch) static_branch_disable(&fgraph_do_direct); static_call_update(fgraph_func, ftrace_graph_entry_stub); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 005E642CCF3; Sat, 28 Feb 2026 17:46:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300806; cv=none; b=DRhf3mf95nk8N695Qk0HQ2BbKGp3CsU8PjuvbFXA7CwNrrTDhB66m8rHdCgS8zFD+KiuMaCDkgNghuK5juONGqWA7QhTPzUo6F/4brqM2JTO+WLa1/uphzt9BehewJgVw15F4EUkePLh5Sc8LaFUhEaunVFaT2L3eASVj3pwLks= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300806; c=relaxed/simple; bh=vUinIj0FNWMSLtEF/cm2Xly3yd7xmnPuhsRTpxkw2HI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BPoZadXoLz3j88sjj8OWX9cBLoRfim5ZWcBRupCwNBh2zQknqSX0bthaQEbzUvku60YYtB4XkFV1O+EVi2n8Dask9OJnPYWdEkQgKtJtzvnkwRYPleb9AJALx92UNF3MChTrwA3m+W3F4i3XAWAZ/lAa+KUkHOweb5urZxGfAQo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WXRHBS+s; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WXRHBS+s" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B2EDC19424; Sat, 28 Feb 2026 17:46:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300805; bh=vUinIj0FNWMSLtEF/cm2Xly3yd7xmnPuhsRTpxkw2HI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WXRHBS+s1qKokdCg8lT/QiqMTnzcvbwvMeaQe21fHnaoItk1kqJ2oAF4blQ8Sj7FX t9bE3gNc6n3rMYP4nI/n3c0QuxRpdiAqV0De8KNQtKa2DYQjEB8AihDe6tbaM3Jhpm TiN7VnU2YCjWhYYMF0SINk/qx1ABmygn9St2Hw42teV3oFE59eY13P0frG8N2jLuAH 9jpUg+fCOdR7s9G59BOuQESVWTVpZwmLJIwL1xO2NQ7pepphX3VhQVyRdIQdCL7m97 u7RxDZu7GbcM9X2npbINFOOyBTapymz1vHPUgvYiqlmJjfk51A7xteNPmIi5CjQb8Z DelpD03Cc8Eig== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Petr Pavlu , Mathieu Desnoyers , Tom Zanussi , "Masami Hiramatsu (Google)" , "Steven Rostedt (Google)" , Sasha Levin Subject: [PATCH 6.19 838/844] tracing: Fix checking of freed trace_event_file for hist files Date: Sat, 28 Feb 2026 12:32:31 -0500 Message-ID: <20260228173244.1509663-839-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Petr Pavlu [ Upstream commit f0a0da1f907e8488826d91c465f7967a56a95aca ] The event_hist_open() and event_hist_poll() functions currently retrieve a trace_event_file pointer from a file struct by invoking event_file_data(), which simply returns file->f_inode->i_private. The functions then check if the pointer is NULL to determine whether the event is still valid. This approach is flawed because i_private is assigned when an eventfs inode is allocated and remains set throughout its lifetime. Instead, the code should call event_file_file(), which checks for EVENT_FILE_FL_FREED. Using the incorrect access function may result in the code potentially opening a hist file for an event that is being removed or becoming stuck while polling on this file. Correct the access method to event_file_file() in both functions. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20260219162737.314231-2-petr.pavlu@suse.com Fixes: 1bd13edbbed6 ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- kernel/trace/trace_events_hist.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_h= ist.c index 7e50df8b800b1..864aa33712ce4 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -5778,7 +5778,7 @@ static __poll_t event_hist_poll(struct file *file, st= ruct poll_table_struct *wai =20 guard(mutex)(&event_mutex); =20 - event_file =3D event_file_data(file); + event_file =3D event_file_file(file); if (!event_file) return EPOLLERR; =20 @@ -5816,7 +5816,7 @@ static int event_hist_open(struct inode *inode, struc= t file *file) =20 guard(mutex)(&event_mutex); =20 - event_file =3D event_file_data(file); + event_file =3D event_file_file(file); if (!event_file) { ret =3D -ENODEV; goto err; --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2219A42D964; Sat, 28 Feb 2026 17:46:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300807; cv=none; b=QVryTY55L8JrBgwi4lxG+qnkGC9El4c3BQvA5UFLSDgq6mXJGnuRmbbz00Zn9FSiJUCmGqsWSH3UG8fdu0EPlm0RvZDBBRxD8V7y1f6ZPnY7vvNVLFGY4Qb/c1OlKjAQXCMSoMEwA0Qw2XzuR55yGkcWAcW5YnBXyp6TxMfFCoQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300807; c=relaxed/simple; bh=AmLdO0QPKnhH6ZGLu6FlqBEAVfRFCPeqGx5cMIZlodw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=umLJiixN/6goZC67O8RYC0Q9NZEP7AOGyg2ER7Lfags+ULIJLsTfLOddmeC0xfsNZFp0LV/uhtbAMATaTXXuGI3os2AwkPE0ylJwZMC6TvEHQ0MeBZewcLqsbFjZl1Bk5ZcewL5uo58e4KvLlpTSQr7ch9fUoZecRj706dT/s74= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TG3iifcC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TG3iifcC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A8AAC116D0; Sat, 28 Feb 2026 17:46:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300807; bh=AmLdO0QPKnhH6ZGLu6FlqBEAVfRFCPeqGx5cMIZlodw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TG3iifcCQGCJW7QZL7BsvLcuNJNV+ln7rG3iDiIIj8t9pRPL7f0e7lmCr7bDZXaOR iN20GUqvXOTzP6FnHDdaw0bKFZKXgKkXwSQs+GWRHjTRyiLHEHyV53pGkhC2mf8jJt 2b398RSm+WO+pUfsfMv5Ufg1nXpsFXouWQz1N+euejJsw6zuXZ47e9QMBzxU8jsLUB tEyJsHFrlQs7du6gDu64uNYpD3aKsE8elV3yM5ymQ0dWt0EQcfhR2SzJqwzbZ+QDVg acJW+bnSgLkBfSce4s27F6UTFddZmnBLDg4n/MkYUjzGui4VevwaTIM4KyqA90+Kv0 Cko7C87C82aXA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Petr Pavlu , Mathieu Desnoyers , Tom Zanussi , "Masami Hiramatsu (Google)" , "Steven Rostedt (Google)" , Sasha Levin Subject: [PATCH 6.19 839/844] tracing: Wake up poll waiters for hist files when removing an event Date: Sat, 28 Feb 2026 12:32:32 -0500 Message-ID: <20260228173244.1509663-840-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Petr Pavlu [ Upstream commit 9678e53179aa7e907360f5b5b275769008a69b80 ] The event_hist_poll() function attempts to verify whether an event file is being removed, but this check may not occur or could be unnecessarily delayed. This happens because hist_poll_wakeup() is currently invoked only from event_hist_trigger() when a hist command is triggered. If the event file is being removed, no associated hist command will be triggered and a waiter will be woken up only after an unrelated hist command is triggered. Fix the issue by adding a call to hist_poll_wakeup() in remove_event_file_dir() after setting the EVENT_FILE_FL_FREED flag. This ensures that a task polling on a hist file is woken up and receives EPOLLERR. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Tom Zanussi Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260219162737.314231-3-petr.pavlu@suse.com Fixes: 1bd13edbbed6 ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- include/linux/trace_events.h | 5 +++++ kernel/trace/trace_events.c | 3 +++ 2 files changed, 8 insertions(+) diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h index 3690221ba3d80..f925034e402dc 100644 --- a/include/linux/trace_events.h +++ b/include/linux/trace_events.h @@ -683,6 +683,11 @@ static inline void hist_poll_wakeup(void) =20 #define hist_poll_wait(file, wait) \ poll_wait(file, &hist_poll_wq, wait) + +#else +static inline void hist_poll_wakeup(void) +{ +} #endif =20 #define __TRACE_EVENT_FLAGS(name, value) \ diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 2c6d3e33b9fb4..ec66170637102 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -1295,6 +1295,9 @@ static void remove_event_file_dir(struct trace_event_= file *file) free_event_filter(file->filter); file->flags |=3D EVENT_FILE_FL_FREED; event_file_put(file); + + /* Wake up hist poll waiters to notice the EVENT_FILE_FL_FREED flag. */ + hist_poll_wakeup(); } =20 /* --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 28C4442D984; Sat, 28 Feb 2026 17:46:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300808; cv=none; b=oh/CF1PYuA7eqE5LmnRBCjoKzYou3lU9LNCJMCgBICv9HRBLZ2AD6CjQ7Rta1E9DhU2VLR4mWxffOCvYp24clhun7XHaIMzmp225FB4cAVmA0sIw8xYK0rs0MSkbcaMQWrYgh9PA7IpjTSHYJGAhQ4uwxG+4IuVqRrNMorrugi4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300808; c=relaxed/simple; bh=r+PK9VDdIvxQ6bySWpE+o6mudA87YwV4OAj0DmyxXbE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h7Ywj1IyzDdY71Ec43794NjTtWZ6w6DtvgLIdwvGUVNNyV87HebrjxKqipe9/u4tghNdUYeYIJqGjBYB4rJY/yhjhlmRS4L23OdxpNOpP8t9oNqGvqayzn+i6+vaMK3Ylbk35XDiE1vVWv3nw89OcMaiJlSwEcABf2NoCQ5vlac= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WvQ31psF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WvQ31psF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46BE8C116D0; Sat, 28 Feb 2026 17:46:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300808; bh=r+PK9VDdIvxQ6bySWpE+o6mudA87YwV4OAj0DmyxXbE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WvQ31psFsCp2rWrqUELbhNFZBm3YHPzEDX56HYWhlIPID7aKQ9rRBokfiMY2EnTCG KaF6c4cr3dJPSizlLvSnTAXjUkXisJEBdpSQdDIcmpukfIYj8piQJzXTkxO4wqksc9 P8lB02VFCf3RIDmAYrDFcPBjtpXcb1cWW+jpIsjhdvEOu4kd8qKNaywmurcg9Bl+no 0V/ktURtikoVuuHSeoWfOsbdMRFft3u14GlG6o9/xLg1hB9UwZZaUg1gI5p0UjnQju UPggXlIN1gSp3ppdB38nHLNXmXelwu+T5yVSloYM8Oyva2GGgOs+S3h7KRG66kxLyk pBtZbY73qfkZw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Philipp Stanner , Alice Ryhl , Gary Guo , Miguel Ojeda , Sasha Levin Subject: [PATCH 6.19 840/844] rust: list: Add unsafe blocks for container_of and safety comments Date: Sat, 28 Feb 2026 12:32:33 -0500 Message-ID: <20260228173244.1509663-841-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Philipp Stanner [ Upstream commit 97b281d7edb2ae662365be2809cd728470119720 ] impl_list_item_mod.rs calls container_of! without unsafe blocks at a couple of places. Since container_of! is unsafe, the blocks are strictly necessary. The problem was so far not visible because the "unsafe-op-in-unsafe-fn" check is a lint rather than a hard compiler error, and Rust suppresses lints triggered inside of a macro from another crate. Thus, the error becomes only visible once someone from within the kernel crate tries to use linked lists: error[E0133]: call to unsafe function `core::ptr::mut_ptr::::byte_sub` is unsafe and requires unsafe block --> rust/kernel/lib.rs:252:29 | 252 | let container_ptr =3D field_ptr.byte_sub(offset).cast::= <$Container>(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to = unsafe function | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.lin= ks }; } 100 | | } | |_- in this macro invocation | note: an unsafe function restricts its caller, but its body is safe by = default --> rust/kernel/list/impl_list_item_mod.rs:216:13 | 216 | unsafe fn view_value(me: *mut $crate::list::ListLin= ks<$num>) -> *const Self { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^ | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.lin= ks }; } 100 | | } | |_- in this macro invocation =3D note: requested on the command line with `-D unsafe-op-in-unsaf= e-fn` =3D note: this error originates in the macro `$crate::container_of`= which comes from the expansion of the macro `impl_list_item` Therefore, add unsafe blocks to container_of! calls to fix the issue. [ As discussed, let's fix the build for those that want to use the macro within the `kernel` crate now and we can discuss the proper safety comments afterwards. Thus I removed the ones from the patch. However, we cannot just avoid the comments with `CLIPPY=3D1`, so I provided placeholders for now, like we did in the past. They were also needed for an `unsafe impl`. While I am not happy about it, it isn't worse than the current status (the comments were meant to be there), and at least this shows what is missing -- our pre-existing "good first issue" [1] may motivate new contributors to complete them properly. Finally, I moved one of the existing safety comments one line down so that Clippy could locate it. Link: https://github.com/Rust-for-Linux/linux/issues/351 [1] - Miguel ] Cc: stable@vger.kernel.org Fixes: c77f85b347dd ("rust: list: remove OFFSET constants") Suggested-by: Alice Ryhl Signed-off-by: Philipp Stanner Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260216131613.45344-3-phasta@kernel.org [ Fixed formatting. Reworded to fix the lint suppression explanation. Indent build error. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- rust/kernel/list/impl_list_item_mod.rs | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/rust/kernel/list/impl_list_item_mod.rs b/rust/kernel/list/impl= _list_item_mod.rs index 202bc6f97c132..ee53d0387e63d 100644 --- a/rust/kernel/list/impl_list_item_mod.rs +++ b/rust/kernel/list/impl_list_item_mod.rs @@ -84,11 +84,12 @@ macro_rules! impl_has_list_links_self_ptr { // right type. unsafe impl$(<$($generics)*>)? $crate::list::HasSelfPtr<$item_type= $(, $id)?> for $self {} =20 + // SAFETY: TODO. unsafe impl$(<$($generics)*>)? $crate::list::HasListLinks$(<$id>)?= for $self { #[inline] unsafe fn raw_get_list_links(ptr: *mut Self) -> *mut $crate::l= ist::ListLinks$(<$id>)? { - // SAFETY: The caller promises that the pointer is not dan= gling. let ptr: *mut $crate::list::ListLinksSelfPtr<$item_type $(= , $id)?> =3D + // SAFETY: The caller promises that the pointer is not= dangling. unsafe { ::core::ptr::addr_of_mut!((*ptr)$(.$field)*) = }; ptr.cast() } @@ -217,7 +218,7 @@ unsafe fn view_value(me: *mut $crate::list::ListLinks<$= num>) -> *const Self { // SAFETY: `me` originates from the most recent call to `p= repare_to_insert`, so it // points at the field `$field` in a value of type `Self`.= Thus, reversing that // operation is still in-bounds of the allocation. - $crate::container_of!(me, Self, $($field).*) + unsafe { $crate::container_of!(me, Self, $($field).*) } } =20 // GUARANTEES: @@ -242,7 +243,7 @@ unsafe fn post_remove(me: *mut $crate::list::ListLinks<= $num>) -> *const Self { // SAFETY: `me` originates from the most recent call to `p= repare_to_insert`, so it // points at the field `$field` in a value of type `Self`.= Thus, reversing that // operation is still in-bounds of the allocation. - $crate::container_of!(me, Self, $($field).*) + unsafe { $crate::container_of!(me, Self, $($field).*) } } } )*}; @@ -270,9 +271,12 @@ unsafe fn prepare_to_insert(me: *const Self) -> *mut $= crate::list::ListLinks<$nu // SAFETY: The caller promises that `me` points at a valid= value of type `Self`. let links_field =3D unsafe { >::view_links(me) }; =20 - let container =3D $crate::container_of!( - links_field, $crate::list::ListLinksSelfPtr, inner - ); + // SAFETY: TODO. + let container =3D unsafe { + $crate::container_of!( + links_field, $crate::list::ListLinksSelfPtr, inner + ) + }; =20 // SAFETY: By the same reasoning above, `links_field` is a= valid pointer. let self_ptr =3D unsafe { @@ -319,9 +323,12 @@ unsafe fn view_links(me: *const Self) -> *mut $crate::= list::ListLinks<$num> { // `ListArc` containing `Self` until the next call to `post_= remove`. The value cannot // be destroyed while a `ListArc` reference exists. unsafe fn view_value(links_field: *mut $crate::list::ListLinks= <$num>) -> *const Self { - let container =3D $crate::container_of!( - links_field, $crate::list::ListLinksSelfPtr, inner - ); + // SAFETY: TODO. + let container =3D unsafe { + $crate::container_of!( + links_field, $crate::list::ListLinksSelfPtr, inner + ) + }; =20 // SAFETY: By the same reasoning above, `links_field` is a= valid pointer. let self_ptr =3D unsafe { --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A8F642D99A; Sat, 28 Feb 2026 17:46:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300809; cv=none; b=sudeOMqMlAfzfZGJ48IYwad3jKxcFBT9bChV+KCuuGUlEoq8HYZgM9NhuX0atQizZmCOLTMU1oUoxRjXSVu28LCGCum896s2ZtwJCUzbN7XBJWskrQkNMx4TjYSqrfpcP7Ci255A/YlmhUSysg6GKAhEIlSR1XEMWO1wZam6jig= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300809; c=relaxed/simple; bh=0ke89qIkCP1Vx3mCNyJmsf87GelHhrDmZ1+IDmagLCk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WErKWPgJ3n264AJT1R5jfxquA83rRFp7D7Vpu6H904PSNhNz/tDm5yCCX8AIgUEdtIVPSGArsBaOqKNhG+XzDIPntst4kNxtgkDLzzS/muUR9z+Kv/x+rYdOU5crilAvJK8N9Ky/eFbqdusOJr7boQKokq8mIxHTw7unlgjDQa4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Fk8n1OrY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Fk8n1OrY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F7B0C116D0; Sat, 28 Feb 2026 17:46:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300809; bh=0ke89qIkCP1Vx3mCNyJmsf87GelHhrDmZ1+IDmagLCk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fk8n1OrYSSpQub0by70LdTJq5p3GpB2x3P0LUyTLtohEiHhL/PS66RDnvrqX6duk2 2gKxGkg1+reHmTmYXzH/xjRT4iQ60HzQnpn416HbuUnIM9cLRYYsB+TSqiFWuKKudg Im3K3IKpA/60SUWSL1Kqphtpn31m6uBMA9iS61r/IfQ/gGqeSyomtDTo/D4cPMwUVl rurwwyie59MUriFl6M7qKiHhxyX2jp4tCpcTs1arrGklUS8UNgumkKBCy2vAGoQd+S /KuAQs/cKBDj1/iF+bKdjWSGghKvrfb66DduhIMlzQHjN8xjWQ0/f2PD+QKeYuSOH1 dLv95sqlXC7iQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Koichiro Den , Frank Li , Dave Jiang , Jon Mason , Sasha Levin Subject: [PATCH 6.19 841/844] NTB: ntb_transport: Fix too small buffer for debugfs_name Date: Sat, 28 Feb 2026 12:32:34 -0500 Message-ID: <20260228173244.1509663-842-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Koichiro Den [ Upstream commit 6a4b50585d74fe45d3ade1e3e86ba8aae79761a5 ] The buffer used for "qp%d" was only 4 bytes, which truncates names like "qp10" to "qp1" and causes multiple queues to share the same directory. Enlarge the buffer and use sizeof() to avoid truncation. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: # v3.9+ Reviewed-by: Frank Li Reviewed-by: Dave Jiang Signed-off-by: Koichiro Den Signed-off-by: Jon Mason Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/ntb/ntb_transport.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c index 71d4bb25f7fdd..4d00263ebc934 100644 --- a/drivers/ntb/ntb_transport.c +++ b/drivers/ntb/ntb_transport.c @@ -1236,9 +1236,9 @@ static int ntb_transport_init_queue(struct ntb_transp= ort_ctx *nt, qp->tx_max_entry =3D tx_size / qp->tx_max_frame; =20 if (nt->debugfs_node_dir) { - char debugfs_name[4]; + char debugfs_name[8]; =20 - snprintf(debugfs_name, 4, "qp%d", qp_num); + snprintf(debugfs_name, sizeof(debugfs_name), "qp%d", qp_num); qp->debugfs_dir =3D debugfs_create_dir(debugfs_name, nt->debugfs_node_dir); =20 --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1BFEB42E6ED; Sat, 28 Feb 2026 17:46:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300810; cv=none; b=NPoBOMvMBs0T9+dYVaU6VA8d/nulvPqMrPXdlICLvRgKbFWO6cCegBa5Fhv9sou/rbSeIRVuUsLWGCq8hTklIyTUxZgDEQ8CSbwl4rSuilE7KXPQec/s+q/HTsKbrxAcknu8FzXNY1aPl5rKT0PHHju6MANk004XF7i+2B9VVQ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300810; c=relaxed/simple; bh=wlnoMeWexWJA2dF9SfOHwqItuv9hz4ScmW9Lp2Fq6Zc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ad6ARA9Coep8lu2grIzZEhHyMfssQSPtCMTE+Fd4X39/PL+ZeIKAYW3+ry298xBJz01BC0Rt8AjOqkqHqqVt7nU6LMme5Y3QhREOa3MYBCUJLtLNDYff8C8t2kq0xVhAdJOQbehPlUetS2iq9+Gnb2lwIce/NDiT7nLQllLuIHI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ICN6ft/e; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ICN6ft/e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 507B3C2BC87; Sat, 28 Feb 2026 17:46:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300810; bh=wlnoMeWexWJA2dF9SfOHwqItuv9hz4ScmW9Lp2Fq6Zc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ICN6ft/eiMKLZdgQ3qVqUDV9BZ1VhZOF0jDGHjvx/tNXdfScTRyb6UkcASKU7Vj8L Oc6gi0urSyXf8V6+TcqfTCVGwz7/s4MqA0OjzoyEFFYiP4b7T5al2tjPnkTcNssAKx EE6EuhCHK7f6dz+2QGjd2XI1xt6Ui1bSS5Ip7XnKCXqKmCg+NCoun45dWoDJMOjr+c fMBHxCFR6EyX6jQZipSGHvuXLUom8RqGeLyhebOqHGYsJjwKGL5TQ7BBrE3tSyANg3 3zs5u0ZJT1L5xNk20Jc+AScrRSDosOnsI+wpaVqJlFYGQFpr6wsxEY++sYoiJ6oeda 8UuXlqkfiQnrA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nathan Chancellor , kernel test robot , Takashi Iwai , Sasha Levin Subject: [PATCH 6.19 842/844] ALSA: pcm: Revert bufs move in snd_pcm_xfern_frames_ioctl() Date: Sat, 28 Feb 2026 12:32:35 -0500 Message-ID: <20260228173244.1509663-843-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nathan Chancellor [ Upstream commit 0585c53b21541cd6b17ad5ab41b371a0d52e358c ] When building with clang older than 17 targeting architectures that use asm goto for their get_user() and put_user(), such as arm64, after commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations"), there are bogus errors around skipping over a variable declared with the cleanup attribute: sound/core/pcm_native.c:3308:6: error: cannot jump from this asm goto sta= tement to one of its possible targets if (put_user(result, &_xfern->result)) ^ ... arch/arm64/include/asm/uaccess.h:298:2: note: expanded from macro '__put_= mem_asm' asm goto( ^ sound/core/pcm_native.c:3295:6: note: possible target of asm goto stateme= nt if (put_user(0, &_xfern->result)) ^ ... sound/core/pcm_native.c:3300:8: note: jump exits scope of variable with _= _attribute__((cleanup)) void *bufs __free(kfree) =3D ^ clang-17 fixed a bug in clang's jump scope checker [1] where all labels in a function were checked as valid targets for all asm goto instances in a function, regardless of whether they were actual targets in a paricular asm goto's provided list of labels. To workaround this, revert the change done to snd_pcm_xfern_frames_ioctl() by commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations") to avoid a variable declared with cleanup from existing between multiple uses of asm goto. There are no other uses of cleanup in this function so there should be low risk from moving this variable back to the top of the function. Link: https://github.com/ClangBuiltLinux/linux/issues/1886 [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512190802.i4Jzbcsl-lkp@int= el.com/ Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20260106-pcm_native-revert-var-move-free-for= -old-clang-v1-1-06a03693423d@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- sound/core/pcm_native.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 844ee1b4d286f..0a358d94b17c6 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3291,6 +3291,7 @@ static int snd_pcm_xfern_frames_ioctl(struct snd_pcm_= substream *substream, { struct snd_xfern xfern; struct snd_pcm_runtime *runtime =3D substream->runtime; + void *bufs __free(kfree) =3D NULL; snd_pcm_sframes_t result; =20 if (runtime->state =3D=3D SNDRV_PCM_STATE_OPEN) @@ -3302,8 +3303,7 @@ static int snd_pcm_xfern_frames_ioctl(struct snd_pcm_= substream *substream, if (copy_from_user(&xfern, _xfern, sizeof(xfern))) return -EFAULT; =20 - void *bufs __free(kfree) =3D - memdup_array_user(xfern.bufs, runtime->channels, sizeof(void *)); + bufs =3D memdup_array_user(xfern.bufs, runtime->channels, sizeof(void *)); if (IS_ERR(bufs)) return PTR_ERR(bufs); if (substream->stream =3D=3D SNDRV_PCM_STREAM_PLAYBACK) --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E8B7542E709; Sat, 28 Feb 2026 17:46:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300811; cv=none; b=UNOiyzbtdHNvp5jZLWm4cyg3OXphn7/mFfEFMYzdNqylCbCSyoagUjtYKsn4DyDIJHZjnPokuKEVm6muWfsxr/AyJGRvIU8Jk11sh7GaTETALZA89iFZDprZy3+SJ8A14BK9eOK9jtzP5Nm9o9yYj8VS63vLbDm4WxB0kBHh59I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300811; c=relaxed/simple; bh=kjYl48MKzqGpME0ktYz7rGI9bYGvuvntwezuXTvt6mA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rgl39gWLq0Kdw+9Zt3xoWJJDPWdfgAxgWvFw5xbfQlY4jXxw/XJ1+aOHK17TNjTB7ua/WEVedsXo8lXygwkaMBCPiqJV7efcXuPs6nvMwTrMjNAXLXkHUWk7Xr9pDKE+G/EsOxKvIUqRK9MIPmX1ITu/FzRHl1AKiOwUEDYOXqA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V2QZL8C+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V2QZL8C+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 428B4C2BCB4; Sat, 28 Feb 2026 17:46:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300810; bh=kjYl48MKzqGpME0ktYz7rGI9bYGvuvntwezuXTvt6mA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V2QZL8C+bcCE9zUdKOCA1evDantnd8VrNUhFDVOErncMcpY2UKIopVaT41BSDLyW4 IQEayyjBtdygrCpN8EgeK7qsTrsgkRcXatqaY6c+PTl45ggm93TMfiSRy5qXr1LNsN DzZCnF5v3wdTKwZAAPSnqHUaoYEl8BJCpt1mRf4jf2sh4oqpVEr2M2f8n6ep++brDC v1Ss9VJQoIp56u0qqiPP7XkA41cwjoVcxlAJzms+dl/FkWvNCEp3F0s67h3dEJP0Ee X1qTv4jV6VrO8T1tNs3D+o9pLCHYVbCK5+envRf6/JeQRSs1+Wg3/ttQncnJTDGwBK AYneuonY/S2WQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sasha Levin , Athul Krishna Subject: [PATCH 6.19 843/844] Revert "ACPI: processor: Update cpuidle driver check in __acpi_processor_start()" Date: Sat, 28 Feb 2026 12:32:36 -0500 Message-ID: <20260228173244.1509663-844-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This reverts commit 0089ce1c056aee547115bdc25c223f8f88c08498 which is upstream commit 6cfed39c2ce64ac024bbde458a9727105e0b8c66. This commit is causing a suspend regression on systems such as the Asus Zephyrus G14 (GA402RJ) with Ryzen 7 6700H: when suspending, the display turns off but the device fails to fully power down. This is not seen with v7.0-rc1 which indicates that there are changes missing. Therefore, revert this change. Link: https://lore.kernel.org/all/lA7Dz_m7_nCF8KkRyEOcSCLg799Mm9_DN2r9hx7IS= jw32OoKiB1r_YjGHIFX8vgqxpOkVJ8d_yHb-VsGAvIWC942D4-zdWxAIP4_k6ZIQi8=3D@proto= nmail.com/ Fixes: 0089ce1c056a ("ACPI: processor: Update cpuidle driver check in __acp= i_processor_start()") Reported-by: Athul Krishna Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- drivers/acpi/processor_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_drive= r.c index 7644de24d2faa..65e779be64ffc 100644 --- a/drivers/acpi/processor_driver.c +++ b/drivers/acpi/processor_driver.c @@ -166,7 +166,7 @@ static int __acpi_processor_start(struct acpi_device *d= evice) if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS)) dev_dbg(&device->dev, "CPPC data invalid or not present\n"); =20 - if (cpuidle_get_driver() =3D=3D &acpi_idle_driver) + if (!cpuidle_get_driver() || cpuidle_get_driver() =3D=3D &acpi_idle_drive= r) acpi_processor_power_init(pr); =20 acpi_pss_perf_init(pr); --=20 2.51.0 From nobody Sat Apr 18 09:32:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9FB624A13B0; Sat, 28 Feb 2026 17:46:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300811; cv=none; b=YOhpOq67JbxjCBN11ugnTtgU13u16TJ1v6Ia0aRo7KBI6c8aT2bFWyQoeFyHLqrfacD3KD0MTfzwQuZ6Dvljbqt4jgc1MA6/Gf+ZWK7kj7Z93Baj1/3WGMr+H9U2UzpbnOD/0WRvXgRuwVwPsYdJi3jOq4tLopbbVLGnvf6FoCQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300811; c=relaxed/simple; bh=SPe0+iqz6muqsA+aUVSzBHkbxKZYx7UYCVsomXMyUXE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Fm6nwXRqLeOBKCJRqSW30AFAfoa1O/rsJ7UqN9bbgGj1SMqzwOlcm8QDaDy2qxr9el/1CdoKOxgS4/++IPDYij9QUr3h0cVPfiVxq+pEFnUCnVPEH2E1DiBVCAj6qsKGWbE7Uej5q1u/w2qECzuBxL4zt4jIPl6NpbjclkZR8ZM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cQgw0Yyf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cQgw0Yyf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15022C2BCB2; Sat, 28 Feb 2026 17:46:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300811; bh=SPe0+iqz6muqsA+aUVSzBHkbxKZYx7UYCVsomXMyUXE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cQgw0YyfzHDfQCMP4mZjfFCGnfRJIhF8ogevrijt/ATYEEoUpWC5iQotKKJ1YBHEq SPrAQHH6ItkLzMqx8840SJjdG0+VDXhWlvluwlYcKnb7QERMo595sGMxkzjLgx7A5c uYeVhzjbD2jloDIImOG12j5YkB8jGbBgElfS0eYPc9FzoWt9wbmYOJ9emfRdRnJnYk bBR7L0T8T7mo43tLRrJjM2W+sBSd1MIu/Lenfkn3+LjykoUD1Vw/SHBq9kWR1P1AFI Xo6BxcFptPeRexpIR+q764yixd4dZjq8zsE0upSSHDmm/jIi5jhWTlWKTMYqSZmrZX E4aybeGELTBbQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sasha Levin Subject: [PATCH 6.19 844/844] Linux 6.19.6-rc1 Date: Sat, 28 Feb 2026 12:32:37 -0500 Message-ID: <20260228173244.1509663-845-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Signed-off-by: Sasha Levin Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Hardik Garg Tested-by: Mark Brown Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index f486050e0bee4..4a101ca9a0456 100644 --- a/Makefile +++ b/Makefile @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 VERSION =3D 6 PATCHLEVEL =3D 19 -SUBLEVEL =3D 5 -EXTRAVERSION =3D +SUBLEVEL =3D 6 +EXTRAVERSION =3D -rc1 NAME =3D Baby Opossum Posse =20 # *DOCUMENTATION* --=20 2.51.0