Previously 1 is unconditionally taken as current brightness value. This
causes problems since it's required to restore brightness settings on
resumption, and a value that doesn't match EC's state before suspension
will cause surprising changes of screen brightness.
Let's get brightness from EC and take it as the current brightness on
probe of the laptop driver to avoid the surprising behavior. Tested on
TongFang L860-T2 3A5000 laptop.
Cc: stable(a)vger.kernel.org
Fixes: 6246ed09111f ("LoongArch: Add ACPI-based generic laptop driver")
Signed-off-by: Yao Zi <ziyao(a)disroot.org>
---
drivers/platform/loongarch/loongson-laptop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/loongarch/loongson-laptop.c b/drivers/platform/loongarch/loongson-laptop.c
index 99203584949d..828bd62e3596 100644
--- a/drivers/platform/loongarch/loongson-laptop.c
+++ b/drivers/platform/loongarch/loongson-laptop.c
@@ -392,7 +392,7 @@ static int laptop_backlight_register(void)
if (!acpi_evalf(hotkey_handle, &status, "ECLL", "d"))
return -EIO;
- props.brightness = 1;
+ props.brightness = ec_get_brightness();
props.max_brightness = status;
props.type = BACKLIGHT_PLATFORM;
--
2.49.0
Add the missing memory barrier to make sure that LMAC source ring
descriptors are written before updating the head pointer to avoid
passing stale data to the firmware on weakly ordered architectures like
aarch64.
Note that non-LMAC rings use MMIO write accessors which have the
required write memory barrier.
Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Cc: stable(a)vger.kernel.org # 6.3
Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org>
---
drivers/net/wireless/ath/ath12k/hal.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/hal.c b/drivers/net/wireless/ath/ath12k/hal.c
index 8615578bb802..1e2d13cc2d19 100644
--- a/drivers/net/wireless/ath/ath12k/hal.c
+++ b/drivers/net/wireless/ath/ath12k/hal.c
@@ -2161,7 +2161,11 @@ void ath12k_hal_srng_access_end(struct ath12k_base *ab, struct hal_srng *srng)
if (srng->ring_dir == HAL_SRNG_DIR_SRC) {
srng->u.src_ring.last_tp =
*(volatile u32 *)srng->u.src_ring.tp_addr;
- *srng->u.src_ring.hp_addr = srng->u.src_ring.hp;
+ /* Make sure descriptor is written before updating the
+ * head pointer.
+ */
+ dma_wmb();
+ WRITE_ONCE(*srng->u.src_ring.hp_addr, srng->u.src_ring.hp);
} else {
srng->u.dst_ring.last_hp = *srng->u.dst_ring.hp_addr;
*srng->u.dst_ring.tp_addr = srng->u.dst_ring.tp;
@@ -2170,6 +2174,10 @@ void ath12k_hal_srng_access_end(struct ath12k_base *ab, struct hal_srng *srng)
if (srng->ring_dir == HAL_SRNG_DIR_SRC) {
srng->u.src_ring.last_tp =
*(volatile u32 *)srng->u.src_ring.tp_addr;
+ /* Assume implementation use an MMIO write accessor
+ * which has the required wmb() so that the descriptor
+ * is written before the updating the head pointer.
+ */
ath12k_hif_write32(ab,
(unsigned long)srng->u.src_ring.hp_addr -
(unsigned long)ab->mem,
--
2.49.0
From: Mike Marshall <hubcap(a)omnibond.com>
A late commit to 6.14-rc7 (665575cf) broke orangefs. I made a patch that
fixes orangefs in 6.15, but some pagecache/folio code got pulled into
6.15 that causes my 6.15 patch not to apply to 6.14. Here is a tested
6.14 flavored patch that was never upstream that I hope can get applied
to 6.14-stable...
---
fs/orangefs/inode.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/orangefs/inode.c b/fs/orangefs/inode.c
index aae6d2b8767d..3e8ce0fea4d7 100644
--- a/fs/orangefs/inode.c
+++ b/fs/orangefs/inode.c
@@ -32,12 +32,13 @@ static int orangefs_writepage_locked(struct page *page,
len = i_size_read(inode);
if (PagePrivate(page)) {
wr = (struct orangefs_write_range *)page_private(page);
- WARN_ON(wr->pos >= len);
off = wr->pos;
- if (off + wr->len > len)
+ if ((off + wr->len > len) && (off <= len))
wlen = len - off;
else
wlen = wr->len;
+ if (wlen == 0)
+ wlen = wr->len;
} else {
WARN_ON(1);
off = page_offset(page);
@@ -46,8 +47,6 @@ static int orangefs_writepage_locked(struct page *page,
else
wlen = PAGE_SIZE;
}
- /* Should've been handled in orangefs_invalidate_folio. */
- WARN_ON(off == len || off + wlen > len);
WARN_ON(wlen == 0);
bvec_set_page(&bv, page, wlen, off % PAGE_SIZE);
@@ -341,6 +340,8 @@ static int orangefs_write_begin(struct file *file,
wr->len += len;
goto okay;
} else {
+ wr->pos = pos;
+ wr->len = len;
ret = orangefs_launder_folio(folio);
if (ret)
return ret;
--
2.49.0
On Thu, May 15, 2025 at 11:01:24AM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, May 14, 2025 at 10:04:26AM +0200, Roger Pau Monne wrote:
> > When adding extra memory regions as ballooned pages also adjust the balloon
> > target, otherwise when the balloon driver is started it will populate
> > memory to match the target value and consume all the extra memory regions
> > added.
> >
> > This made the usage of the Xen `dom0_mem=,max:` command line parameter for
> > dom0 not work as expected, as the target won't be adjusted and when the
> > balloon is started it will populate memory straight to the 'max:' value.
> > It would equally affect domUs that have memory != maxmem.
> >
> > Kernels built with CONFIG_XEN_UNPOPULATED_ALLOC are not affected, because
> > the extra memory regions are consumed by the unpopulated allocation driver,
> > and then balloon_add_regions() becomes a no-op.
> >
> > Reported-by: John <jw(a)nuclearfallout.net>
> > Fixes: 87af633689ce ('x86/xen: fix balloon target initialization for PVH dom0')
> > Signed-off-by: Roger Pau Monné <roger.pau(a)citrix.com>
>
> Tested-by: Marek Marczykowski-Górecki <marmarek(a)invisiblethingslab.com>
I think this wants Cc: stable, since the commit named in Fixes: got
backported too. Or is the Fixes tag enough?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com>
Hi,
Commit 653143ed73ec ("serial: sh-sci: Check if TX data was written
to device in .tx_empty()") doesn't apply cleanly on top of v5.10.y
stable tree. This series adjust it. Along with it, propose for
backporting other sh-sci fixes.
Please provide your feedback.
Thank you,
Claudiu Beznea
Claudiu Beznea (4):
serial: sh-sci: Check if TX data was written to device in .tx_empty()
serial: sh-sci: Move runtime PM enable to sci_probe_single()
serial: sh-sci: Clean sci_ports[0] after at earlycon exit
serial: sh-sci: Increment the runtime usage counter for the earlycon
device
drivers/tty/serial/sh-sci.c | 97 ++++++++++++++++++++++++++++++-------
1 file changed, 79 insertions(+), 18 deletions(-)
--
2.43.0
From: Marek Vasut <marex(a)denx.de>
[ Upstream commit 8bad8c923f217d238ba4f1a6d19d761e53bfbd26 ]
The VSELECT pin is configured as MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT
and not as a GPIO, drop the bogus sd-vsel-gpios property as the eSDHC
block handles the VSELECT pin on its own.
Signed-off-by: Marek Vasut <marex(a)denx.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf(a)kontron.de>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
---
6.1.y is currently broken on imx8mm-verdin, because commit
5591ce0069ddda97cdbbea596bed53e698f399c2, that was backported correctly on 6.1,
depends on this one.
This fixes the following error:
[ 1.735149] gpio-regulator: probe of regulator-usdhc2-vqmmc failed with error -16
---
arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
index 5b2493bb8dd9..37acaf62f5c7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
@@ -362,7 +362,6 @@ pca9450: pmic@25 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pmic>;
reg = <0x25>;
- sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
/*
* The bootloader is expected to switch on the I2C level shifter for the TLA2024 ADC
--
2.39.5
Hi,
can we have:
6da5e6f3028d ACPICA: Introduce ACPI_NONSTRING
2b82118845e0 ACPICA: Apply ACPI_NONSTRING
70662db73d54 ACPICA: Apply ACPI_NONSTRING in more places
in 6.15? They fix the build of acpica against the kernel -- __nonstring
is undefined otherwise.
thanks,
--
js
suse labs
Hi Greg et al,
Please pick up the following commit:
commit 70523f335734b0b42f97647556d331edf684c7dc
Author: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Date: Thu May 29 15:40:43 2025 +0200
Revert "x86/smp: Eliminate mwait_play_dead_cpuid_hint()"
for the closest 6.15.y.
The bug fixed by it is kind of nasty.
Thanks!
From: Kees Cook <kees(a)kernel.org>
[ Upstream commit cedc1b63394a866bf8663a3e40f4546f1d28c8d8 ]
It looks like attempting to write to the "store_modes" sysfs node will
run afoul of unregistered consoles:
UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28
index -1 is out of range for type 'fb_info *[32]'
...
fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122
fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048
fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673
store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113
dev_attr_store+0x55/0x80 drivers/base/core.c:2439
static struct fb_info *fbcon_registered_fb[FB_MAX];
...
static signed char con2fb_map[MAX_NR_CONSOLES];
...
static struct fb_info *fbcon_info_from_console(int console)
...
return fbcon_registered_fb[con2fb_map[console]];
If con2fb_map contains a -1 things go wrong here. Instead, return NULL,
as callers of fbcon_info_from_console() are trying to compare against
existing "info" pointers, so error handling should kick in correctly.
Reported-by: syzbot+a7d4444e7b6e743572f7(a)syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/679d0a8f.050a0220.163cdc.000c.GAE@google.com/
Signed-off-by: Kees Cook <kees(a)kernel.org>
Signed-off-by: Helge Deller <deller(a)gmx.de>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
**YES** This commit should be backported to stable kernel trees. Here's
my analysis: ## Security and Stability Issue This commit fixes a
critical **array-index-out-of-bounds vulnerability** that can be
triggered via sysfs. The issue occurs when `con2fb_map[console]`
contains `-1`, causing `fbcon_info_from_console()` to access
`fbcon_registered_fb[-1]`, which is an out-of-bounds array access. ##
Bug Analysis The problem is in the `fbcon_info_from_console()` function
at line 122: ```c // Before fix: return
fbcon_registered_fb[con2fb_map[console]]; // After fix: fb =
con2fb_map[console]; if (fb < 0 || fb >=
ARRAY_SIZE(fbcon_registered_fb)) return NULL; return
fbcon_registered_fb[fb]; ``` ## Trigger Path The vulnerability can be
triggered through: 1. **sysfs interface**: Writing to
`/sys/class/graphics/fbX/modes` 2. **Call chain**: `store_modes()` →
`fb_new_modelist()` → `fbcon_new_modelist()` →
`fbcon_info_from_console()` 3. **User-accessible**: This is exploitable
from userspace through the sysfs interface ## Code Context from Analysis
Based on the git blame, the vulnerable code path in
`fbcon_new_modelist()` has existed since: - Original code from **2005**
(Linus Torvalds) - The problematic `fbcon_info_from_console()` call was
added in **2022** by commit `409d6c95f9c6` ("fbcon: Introduce wrapper
for console->fb_info lookup") ## Risk Assessment 1. **High Impact**:
UBSAN array bounds violation, potential for memory corruption 2. **User
Triggerable**: Accessible via standard sysfs interface 3. **Long-
standing**: The vulnerable pattern has existed since 2022 when the
wrapper was introduced 4. **Active Exploitation**: Reported by syzbot,
indicating active fuzzing found this issue ## Backport Suitability 1.
**Small & Contained**: Only 6 lines changed in a single function 2.
**Safe Fix**: Adds bounds checking without changing logic flow 3. **No
Dependencies**: The fix is self-contained and doesn't require other
commits 4. **Clear Bug**: Definitively fixes out-of-bounds access with
proper NULL return 5. **Stable Pattern**: Callers already handle NULL
returns from `fbcon_info_from_console()` ## Comparison to Historical
Precedent Looking at the similar commits provided: - **Similar Commit
#1** (Backport Status: YES): Fixed boundary checks in fbcon parameter
parsing - this follows the same pattern of fixing bounds issues in fbcon
- The other NO commits were architectural changes or refactoring, not
security fixes This commit perfectly fits the stable tree criteria: it's
an important bugfix, has minimal regression risk, is contained to a
single subsystem, and fixes a user-triggerable vulnerability.
drivers/video/fbdev/core/fbcon.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index ac3c99ed92d1a..2df48037688d1 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -117,9 +117,14 @@ static signed char con2fb_map_boot[MAX_NR_CONSOLES];
static struct fb_info *fbcon_info_from_console(int console)
{
+ signed char fb;
WARN_CONSOLE_UNLOCKED();
- return fbcon_registered_fb[con2fb_map[console]];
+ fb = con2fb_map[console];
+ if (fb < 0 || fb >= ARRAY_SIZE(fbcon_registered_fb))
+ return NULL;
+
+ return fbcon_registered_fb[fb];
}
static int logo_lines;
--
2.39.5
This series introduces a new metadata format for UVC cameras and adds a
couple of improvements to the UVC metadata handling.
The new metadata format can be enabled in runtime with quirks.
Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org>
---
Changes in v6 (Thanks Laurent):
- Fix typo in metafmt-uvc.rst
- Improve metafmt-uvc-msxu-1-5.rst
- uvc_meta_v4l2_try_format() block MSXU format unless the quirk is
active
- Refactor uvc_enable_msxu
- Document uvc_meta_detect_msxu
- Rebase series
- Add R-b
- Link to v5: https://lore.kernel.org/r/20250404-uvc-meta-v5-0-f79974fc2d20@chromium.org
Changes in v5:
- Fix codestyle and kerneldoc warnings reported by media-ci
- Link to v4: https://lore.kernel.org/r/20250403-uvc-meta-v4-0-877aa6475975@chromium.org
Changes in v4:
- Rename format to V4L2_META_FMT_UVC_MSXU_1_5 (Thanks Mauro)
- Flag the new format with a quirk.
- Autodetect MSXU devices.
- Link to v3: https://lore.kernel.org/linux-media/20250313-uvc-metadata-v3-0-c467af869c60…
Changes in v3:
- Fix doc syntax errors.
- Link to v2: https://lore.kernel.org/r/20250306-uvc-metadata-v2-0-7e939857cad5@chromium.…
Changes in v2:
- Add metadata invalid fix
- Move doc note to a separate patch
- Introduce V4L2_META_FMT_UVC_CUSTOM (thanks HdG!).
- Link to v1: https://lore.kernel.org/r/20250226-uvc-metadata-v1-1-6cd6fe5ec2cb@chromium.…
---
Ricardo Ribalda (4):
media: uvcvideo: Do not mark valid metadata as invalid
media: Documentation: Add note about UVCH length field
media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5
media: uvcvideo: Auto-set UVC_QUIRK_MSXU_META
.../userspace-api/media/v4l/meta-formats.rst | 1 +
.../media/v4l/metafmt-uvc-msxu-1-5.rst | 23 ++++
.../userspace-api/media/v4l/metafmt-uvc.rst | 4 +-
MAINTAINERS | 1 +
drivers/media/usb/uvc/uvc_metadata.c | 116 +++++++++++++++++++--
drivers/media/usb/uvc/uvc_video.c | 12 +--
drivers/media/usb/uvc/uvcvideo.h | 1 +
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/linux/usb/uvc.h | 3 +
include/uapi/linux/videodev2.h | 1 +
10 files changed, 150 insertions(+), 13 deletions(-)
---
base-commit: 5e1ff2314797bf53636468a97719a8222deca9ae
change-id: 20250403-uvc-meta-e556773d12ae
Best regards,
--
Ricardo Ribalda <ribalda(a)chromium.org>
From: Marcus Folkesson <marcus.folkesson(a)gmail.com>
[ Upstream commit 325f510fcd9cda5a44bcb662b74ba4e3dabaca10 ]
We have to wait at least the minimium time for the watchdog window
(TWDMIN) before writings to the wdt register after the
watchdog is activated.
Otherwise the chip will assert TWD_ERROR and power down to reset mode.
Signed-off-by: Marcus Folkesson <marcus.folkesson(a)gmail.com>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Link: https://lore.kernel.org/r/20250326-da9052-fixes-v3-4-a38a560fef0e@gmail.com
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim(a)linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
Based on my analysis, here's my assessment: **YES** This commit should
be backported to stable kernel trees. Here's my extensive analysis: ##
Analysis of the Commit ### 1. **Bug Fix Nature** The commit fixes a
critical hardware timing constraint issue. The DA9052 PMIC has a minimum
watchdog window time (TWDMIN = 256ms) that must be respected. Writing to
the watchdog register before this time elapses causes the chip to assert
TWD_ERROR and power down to reset mode, which is a serious system
failure. ### 2. **Code Changes Analysis** The commit makes a single,
targeted change in `drivers/watchdog/da9052_wdt.c`: ```c
da9052_wdt->timeout = DA9052_DEF_TIMEOUT;
+da9052_wdt->min_hw_heartbeat_ms = DA9052_TWDMIN; da9052_wdt->info =
&da9052_wdt_info; ``` This change adds `min_hw_heartbeat_ms =
DA9052_TWDMIN` (256ms) to the watchdog device structure during probe.
### 3. **Technical Correctness** - **DA9052_TWDMIN is already defined**
as 256 in the driver (line 25) - **The current code already implements
manual timing protection** in `da9052_wdt_ping()` (lines 119-121) using
jiffies tracking and `mdelay()` - **The watchdog core provides proper
infrastructure** for `min_hw_heartbeat_ms` as seen in similar
DA9062/DA9063 drivers and watchdog core code - **This replaces manual
timing logic with standard core handling**, making it more reliable and
consistent ### 4. **Risk Assessment - Very Low** - **Minimal code
change**: Only adds one line setting a field - **No behavioral change**:
The timing constraint was already enforced manually - **Uses existing
infrastructure**: `min_hw_heartbeat_ms` is well-established in watchdog
core - **Consistent with related drivers**: DA9062 and DA9063 drivers
use the same pattern - **No architectural changes**: Just moves timing
enforcement from driver to core ### 5. **User Impact - High** -
**Prevents system resets**: Without this fix, rapid watchdog pings can
cause unexpected system shutdowns - **Hardware protection**: Prevents
TWD_ERROR assertion which leads to PMIC reset - **Critical for
production systems**: Watchdog failures can cause data loss and system
instability ### 6. **Stable Tree Criteria Compliance** - ✅ **Important
bugfix**: Prevents system resets due to hardware timing violations - ✅
**Minimal risk**: Single line addition using existing infrastructure - ✅
**Small and contained**: Only affects DA9052 watchdog driver - ✅ **No
new features**: Just improves existing timing protection - ✅ **Clear
benefit**: Moves from manual to core-handled timing protection ### 7.
**Comparison with Similar Commits** The provided similar commits (all
marked "NO") were different in nature: - **Commits #1-3**: Added new
functionality or made architectural changes to use core protection -
**Commits #4-5**: Simple cleanup removing error messages - **This
commit**: Fixes a critical hardware timing bug that can cause system
resets This commit is fundamentally different - it fixes a real hardware
constraint violation that can cause system failures, not just cleanup or
new features. The commit perfectly fits stable tree criteria: it's a
small, low-risk fix for an important hardware-related bug that can cause
system instability.
drivers/watchdog/da9052_wdt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/watchdog/da9052_wdt.c b/drivers/watchdog/da9052_wdt.c
index d708c091bf1b1..180526220d8c4 100644
--- a/drivers/watchdog/da9052_wdt.c
+++ b/drivers/watchdog/da9052_wdt.c
@@ -164,6 +164,7 @@ static int da9052_wdt_probe(struct platform_device *pdev)
da9052_wdt = &driver_data->wdt;
da9052_wdt->timeout = DA9052_DEF_TIMEOUT;
+ da9052_wdt->min_hw_heartbeat_ms = DA9052_TWDMIN;
da9052_wdt->info = &da9052_wdt_info;
da9052_wdt->ops = &da9052_wdt_ops;
da9052_wdt->parent = dev;
--
2.39.5