From: ChiYuan Huang <cy_huang(a)richtek.com>
To make sure LED enter off state after file handle is closed, initiatively
configure LED_MODE to NONE. This can guarantee whatever the previous state
is torch or strobe mode, the final state will be off.
Cc: stable(a)vger.kernel.org
Fixes: 42bd6f59ae90 ("media: Add registration helpers for V4L2 flash sub-devices")
Reported-by: Roger Wang <roger-hy.wang(a)mediatek.com>
Signed-off-by: ChiYuan Huang <cy_huang(a)richtek.com>
---
v2
- Fix commit message redudant space cause patch robot parsing error
Hi,
We encounter an issue. When the upper layer camera process is crashed,
if the new process did not reinit the LED, it will keeps the previous
state whatever it's in torch or strobe mode
OS will handle the resource management. So when the process is crashed
or terminated, the 'close' API will be called to release resources.
That's why we add the initiative action to trigger LED off in file
handle close is called.
---
drivers/media/v4l2-core/v4l2-flash-led-class.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index 355595a0fefa..347b37f3ef69 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -623,6 +623,12 @@ static int v4l2_flash_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
return 0;
if (led_cdev) {
+ /* If file handle is released, make sure LED enter off state */
+ ret = v4l2_ctrl_s_ctrl(v4l2_flash->ctrls[LED_MODE],
+ V4L2_FLASH_LED_MODE_NONE);
+ if (ret)
+ return ret;
+
mutex_lock(&led_cdev->led_access);
if (v4l2_flash->ctrls[STROBE_SOURCE])
base-commit: 8ac28a6642d1cc8bac0632222e66add800b027fa
--
2.34.1
Fintek F81504/508/512 can support both RTS_ON_SEND and RTS_AFTER_SEND,
but pci_fintek_rs485_supported only announces the former.
This makes it impossible to unset SER_RS485_RTS_ON_SEND from
userspace because of uart_sanitize_serial_rs485(). Some devices
with these chips need RTS low on TX, so they are effectively broken.
Fix this by announcing the support for SER_RS485_RTS_AFTER_SEND,
similar to commit 068d35a7be65 ("serial: sc16is7xx: announce support
for SER_RS485_RTS_ON_SEND").
Fixes: 4afeced55baa ("serial: core: fix sanitizing check for RTS settings")
Cc: stable(a)vger.kernel.org
Signed-off-by: Marnix Rijnart <marnix.rijnart(a)iwell.eu>
---
Changes in v3:
- Rewrite commit message to clarify problem
- Use longer commit hashes
- v2: https://patch.msgid.link/20260111135933.31316-1-marnix.rijnart@iwell.eu
Changes in v2:
- Added fixes tags
- Cc stable
- v1: https://patch.msgid.link/20250923221756.26770-1-marnix.rijnart@iwell.eu
---
drivers/tty/serial/8250/8250_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 152f914c599d..a9da222bd174 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1645,7 +1645,7 @@ static int pci_fintek_rs485_config(struct uart_port *port, struct ktermios *term
}
static const struct serial_rs485 pci_fintek_rs485_supported = {
- .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND,
+ .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | SER_RS485_RTS_AFTER_SEND,
/* F81504/508/512 does not support RTS delay before or after send */
};
--
2.52.0
From: Kairui Song <kasong(a)tencent.com>
The helper for shmem swap freeing is not handling the order of swap
entries correctly. It uses xa_cmpxchg_irq to erase the swap entry,
but it gets the entry order before that using xa_get_order
without lock protection. As a result the order could be a stalled value
if the entry is split after the xa_get_order and before the
xa_cmpxchg_irq. In fact that are more way for other races to occur
during the time window.
To fix that, open code the Xarray cmpxchg and put the order retrivial and
value checking in the same critical section. Also ensure the order won't
exceed the truncate border.
I observed random swapoff hangs and swap entry leaks when stress
testing ZSWAP with shmem. After applying this patch, the problem is resolved.
Fixes: 809bc86517cc ("mm: shmem: support large folio swap out")
Cc: stable(a)vger.kernel.org
Signed-off-by: Kairui Song <kasong(a)tencent.com>
---
mm/shmem.c | 35 +++++++++++++++++++++++------------
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 0b4c8c70d017..e160da0cd30f 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -961,18 +961,28 @@ static void shmem_delete_from_page_cache(struct folio *folio, void *radswap)
* the number of pages being freed. 0 means entry not found in XArray (0 pages
* being freed).
*/
-static long shmem_free_swap(struct address_space *mapping,
- pgoff_t index, void *radswap)
+static long shmem_free_swap(struct address_space *mapping, pgoff_t index,
+ unsigned int max_nr, void *radswap)
{
- int order = xa_get_order(&mapping->i_pages, index);
- void *old;
+ XA_STATE(xas, &mapping->i_pages, index);
+ unsigned int nr_pages = 0;
+ void *entry;
- old = xa_cmpxchg_irq(&mapping->i_pages, index, radswap, NULL, 0);
- if (old != radswap)
- return 0;
- swap_put_entries_direct(radix_to_swp_entry(radswap), 1 << order);
+ xas_lock_irq(&xas);
+ entry = xas_load(&xas);
+ if (entry == radswap) {
+ nr_pages = 1 << xas_get_order(&xas);
+ if (index == round_down(xas.xa_index, nr_pages) && nr_pages < max_nr)
+ xas_store(&xas, NULL);
+ else
+ nr_pages = 0;
+ }
+ xas_unlock_irq(&xas);
+
+ if (nr_pages)
+ swap_put_entries_direct(radix_to_swp_entry(radswap), nr_pages);
- return 1 << order;
+ return nr_pages;
}
/*
@@ -1124,8 +1134,8 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, uoff_t lend,
if (xa_is_value(folio)) {
if (unfalloc)
continue;
- nr_swaps_freed += shmem_free_swap(mapping,
- indices[i], folio);
+ nr_swaps_freed += shmem_free_swap(mapping, indices[i],
+ end - indices[i], folio);
continue;
}
@@ -1195,7 +1205,8 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, uoff_t lend,
if (unfalloc)
continue;
- swaps_freed = shmem_free_swap(mapping, indices[i], folio);
+ swaps_freed = shmem_free_swap(mapping, indices[i],
+ end - indices[i], folio);
if (!swaps_freed) {
/* Swap was replaced by page: retry */
index = indices[i];
---
base-commit: ab3d40bdac831c67e130fda12f3011505556500f
change-id: 20260111-shmem-swap-fix-8d0e20a14b5d
Best regards,
--
Kairui Song <kasong(a)tencent.com>
From: Stefan Binding <sbinding(a)opensource.cirrus.com>
[ Upstream commit 826c0b1ed09e5335abcae07292440ce72346e578 ]
Laptops use 2 CS35L41 Amps with HDA, using External boost, with I2C
Signed-off-by: Stefan Binding <sbinding(a)opensource.cirrus.com>
Link: https://patch.msgid.link/20251205150614.49590-3-sbinding@opensource.cirrus.…
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Commit Analysis: ALSA: hda/realtek: Add support for ASUS UM3406GA
### 1. COMMIT MESSAGE ANALYSIS
The commit message is straightforward: it adds support for a specific
ASUS laptop model (UM3406GA) that uses 2 CS35L41 amplifiers connected
via I2C with external boost. The message describes the hardware
configuration, which is standard for such device ID additions.
No Fixes: or Cc: stable tags are present, but as noted, this is expected
for commits requiring manual review.
### 2. CODE CHANGE ANALYSIS
The entire change is a single line addition:
```c
SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ",
ALC287_FIXUP_CS35L41_I2C_2),
```
This adds:
- Vendor ID: 0x1043 (ASUS)
- Device/Subsystem ID: 0x1584 (ASUS UM3406GA)
- Fixup: `ALC287_FIXUP_CS35L41_I2C_2` (an **existing** fixup already
used by many other ASUS models)
Looking at the surrounding code, multiple other ASUS laptops use the
same fixup:
- ASUS PM3406CKA (0x1454)
- ASUS G513PI/PU/PV (0x14e3)
- ASUS G733PY/PZ/PZV/PYV (0x1503)
- ASUS GV302XA/XJ/XQ/XU/XV/XI (0x1533)
- ASUS UM3402YAR (0x1683)
### 3. CLASSIFICATION
This is a **NEW DEVICE ID** addition - explicitly listed as an exception
that IS appropriate for stable backporting. The driver infrastructure
and fixup code already exist; this merely adds an ID to enable the
existing fix for new hardware.
### 4. SCOPE AND RISK ASSESSMENT
- **Lines changed**: 1 line
- **Files touched**: 1 file
- **Complexity**: Zero - table entry addition only
- **Risk**: Extremely low - this cannot affect any other hardware
- **No new code paths**: Uses pre-existing `ALC287_FIXUP_CS35L41_I2C_2`
fixup
### 5. USER IMPACT
- **Who is affected**: Owners of ASUS UM3406GA laptops
- **Problem without fix**: Audio (specifically the CS35L41 amplifiers)
won't function properly
- **Severity**: Non-working audio is a significant user-facing issue for
laptop users
### 6. STABILITY INDICATORS
- Signed-off by Takashi Iwai (ALSA maintainer at SUSE)
- Standard quirk addition pattern used extensively throughout this file
- Follows exact same format as dozens of other ASUS quirk entries
### 7. DEPENDENCY CHECK
- The fixup `ALC287_FIXUP_CS35L41_I2C_2` has been in the kernel for some
time, supporting multiple other ASUS models
- No other commits are required for this to work
- This should apply cleanly to stable trees that have the CS35L41
support infrastructure
### CONCLUSION
This commit is a textbook example of what should be backported to stable
trees:
1. **Falls under explicit exception**: Adding device IDs to existing
drivers is explicitly allowed
2. **Minimal change**: Single line, single table entry
3. **Zero regression risk**: Cannot affect any hardware except the
targeted laptop
4. **Uses existing infrastructure**: The fixup is already well-tested on
similar ASUS models
5. **Fixes real user problem**: Enables audio on a production laptop
6. **Obviously correct**: Identical pattern to surrounding entries
The risk-benefit analysis strongly favors backporting: virtually zero
risk with clear user benefit (working audio on a specific laptop model).
**YES**
sound/hda/codecs/realtek/alc269.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index b45fcc9a3785e..008bf9d5148e1 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6752,6 +6752,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x1533, "ASUS GV302XA/XJ/XQ/XU/XV/XI", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x1043, 0x1573, "ASUS GZ301VV/VQ/VU/VJ/VA/VC/VE/VVC/VQC/VUC/VJC/VEC/VCC", ALC285_FIXUP_ASUS_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x1043, 0x1652, "ASUS ROG Zephyrus Do 15 SE", ALC289_FIXUP_ASUS_ZEPHYRUS_DUAL_SPK),
SND_PCI_QUIRK(0x1043, 0x1662, "ASUS GV301QH", ALC294_FIXUP_ASUS_DUAL_SPK),
SND_PCI_QUIRK(0x1043, 0x1663, "ASUS GU603ZI/ZJ/ZQ/ZU/ZV", ALC285_FIXUP_ASUS_HEADSET_MIC),
--
2.51.0
I'm announcing the release of the 6.18.5 kernel.
All users of the 6.18 kernel series must upgrade.
The updated 6.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.18.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 -
fs/nfs/localio.c | 12 +++----
include/linux/sched/topology.h | 3 +
kernel/sched/core.c | 3 +
kernel/sched/fair.c | 65 +++++++++++++++++++++++++++++++++--------
kernel/sched/features.h | 5 +++
kernel/sched/sched.h | 7 ++++
kernel/sched/topology.c | 6 +++
net/mptcp/protocol.c | 8 +++--
net/mptcp/protocol.h | 3 +
10 files changed, 91 insertions(+), 23 deletions(-)
Greg Kroah-Hartman (1):
Linux 6.18.5
Mike Snitzer (1):
nfs/localio: fix regression due to out-of-order __put_cred
Paolo Abeni (1):
mptcp: ensure context reset on disconnect()
Peter Zijlstra (3):
sched/fair: Small cleanup to sched_balance_newidle()
sched/fair: Small cleanup to update_newidle_cost()
sched/fair: Proportional newidle balance