[PATCH AUTOSEL 6.19-5.10] clk: microchip: core: correct return value on *_get_parent()

[PATCH AUTOSEL 6.19-5.10] clk: microchip: core: correct return value on *_get_parent()

[Sasha Levin]

From: Brian Masney <bmasney@redhat.com>

[ 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 <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202512050233.R9hAWsJN-lkp@intel.com/
Signed-off-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Link: https://lore.kernel.org/r/20251205-clk-microchip-fixes-v3-2-a02190705e47@redhat.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The driver was introduced in 2016, around v4.7. This is very old code
that has been in all stable trees.

## Bug Classification

This is a **type mismatch bug** where a signed error code (`-EINVAL`,
which is -22) is returned from a function with unsigned `u8` return
type. The framework API (`struct clk_ops.get_parent`) is defined as
returning `u8`.

When `-EINVAL` is returned as `u8`:
- It becomes 234 (0xEA) due to unsigned truncation
- This gets passed to `clk_core_get_parent_by_index()` which checks
  bounds (`index >= core->num_parents`)
- Since 234 is almost certainly larger than the number of parents, it
  returns NULL
- This means the clock has no parent set, which could cause
  initialization failures or wrong clock behavior

The fix replaces the `-EINVAL` return with returning the raw hardware
register value `v`, which is what the function already does when
`parent_map` is NULL. This is a sensible fallback - if the parent map
doesn't contain the hardware value, use it directly (as if there's no
map).

## Risk Assessment

**Very low risk:**
- The change is small and contained (two functions, same pattern)
- The logic change is straightforward: instead of returning an invalid
  value on the "no match found" path, return the hardware register value
- The fix is reviewed by the subsystem maintainer (Claudiu Beznea)
- The code only affects Microchip PIC32 clock driver - very narrow scope
- `clk_core_get_parent_by_index()` still performs bounds validation on
  the returned value

**Benefit:**
- Prevents incorrect clock parent resolution on Microchip PIC32
  platforms
- Fixes a real type mismatch bug that was caught by static analysis
  tools
- The bug has existed since the driver was introduced (~v4.7), so all
  stable trees are affected

## Verification

- **Verified:** `struct clk_ops.get_parent` returns `u8` (confirmed in
  `include/linux/clk-provider.h`)
- **Verified:** `clk_core_get_parent_by_index()` bounds-checks the index
  against `num_parents` and returns NULL for out-of-range
- **Verified:** `__clk_init_parent()` calls `.get_parent()` and passes
  result to `clk_core_get_parent_by_index()`
- **Verified:** `-EINVAL` is -22, which truncated to `u8` becomes 234
  (0xEA), which would exceed any realistic parent count
- **Verified:** The driver was introduced in 2016 (commit
  ce6e118846599), so the bug exists in all stable trees
- **Verified:** Reported by kernel test robot and Dan Carpenter (well-
  known static analysis reporters)
- **Verified:** Reviewed-by from Claudiu Beznea (subsystem maintainer)
- **Verified:** The fix simply uses the raw hardware value `v` as
  fallback, which is what the function already returns when `parent_map`
  is NULL

## Conclusion

This commit fixes a real bug where two clock `get_parent` callbacks
return a signed error code from a function with unsigned return type.
The fix is small, obvious, well-reviewed, and low-risk. It affects a
driver that has been in the kernel since v4.7, so all stable trees
contain the buggy code. The fix follows the existing pattern in the code
(using the hardware register value directly) and is the correct
approach.

**YES**

 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-core.c
index b34348d491f3e..73c05aa4e1d60 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)
 
 	v = (readl(refo->ctrl_reg) >> REFO_SEL_SHIFT) & REFO_SEL_MASK;
 
-	if (!refo->parent_map)
-		return v;
-
-	for (i = 0; i < clk_hw_get_num_parents(hw); i++)
-		if (refo->parent_map[i] == v)
-			return i;
+	if (refo->parent_map) {
+		for (i = 0; i < clk_hw_get_num_parents(hw); i++)
+			if (refo->parent_map[i] == v)
+				return i;
+	}
 
-	return -EINVAL;
+	return v;
 }
 
 static unsigned long roclk_calc_rate(unsigned long parent_rate,
@@ -826,13 +825,13 @@ static u8 sclk_get_parent(struct clk_hw *hw)
 
 	v = (readl(sclk->mux_reg) >> OSC_CUR_SHIFT) & OSC_CUR_MASK;
 
-	if (!sclk->parent_map)
-		return v;
+	if (sclk->parent_map) {
+		for (i = 0; i < clk_hw_get_num_parents(hw); i++)
+			if (sclk->parent_map[i] == v)
+				return i;
+	}
 
-	for (i = 0; i < clk_hw_get_num_parents(hw); i++)
-		if (sclk->parent_map[i] == v)
-			return i;
-	return -EINVAL;
+	return v;
 }
 
 static int sclk_set_parent(struct clk_hw *hw, u8 index)
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] clk: renesas: rzg2l: Deassert reset on assert timeout

[Sasha Levin]

From: Biju Das <biju.das.jz@bp.renesas.com>

[ 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 <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260108123433.104464-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The suspend/resume directly in this driver doesn't call assert. The
commit message mentions "suspend() callback" — this likely refers to
peripheral device drivers that use reset_control_assert() during their
own suspend callbacks, which then calls `rzg2l_cpg_assert()` through the
reset_control_ops.

## Summary of Analysis

### What the commit fixes:
1. **Variable shadowing bug**: `readl_poll_timeout_atomic` overwrites
   `value`, which is then needed for the error recovery path. The patch
   introduces a separate `mon` variable for the poll output, keeping
   `value` intact.
2. **Missing error recovery on assert timeout**: The original code only
   rolls back on deassert failure. If assert fails (e.g., during
   suspend), the device is left in an asserted (reset) state with no
   recovery, making the device non-operational even though the suspend
   callback returns an error. The fix uses `value ^= mask` to undo
   either direction of the operation.

### Dependencies:
This commit has **hard dependencies** on two v6.18 commits:
- `341b0f1b6cba5` - introduces `__rzg2l_cpg_assert()` helper
- `f8c5f0dc77d86` - introduces the deassert-only rollback code that this
  commit modifies

Without these two prerequisite commits, the patch cannot apply to any
stable tree older than v6.18.

### Risk Assessment:
- **Scope**: Small, contained change in one function (~10 lines changed)
- **Risk**: Low — only affects error paths in Renesas RZ/G2L clock/reset
  driver
- **Correctness**: The XOR approach is elegant and correct for both
  assert and deassert cases
- **Review**: Has "Reviewed-by: Geert Uytterhoeven" (Renesas clk
  subsystem maintainer)

### Stable Tree Applicability:
The fix only applies to v6.18.y since its prerequisites were merged in
v6.18-rc1. For older stable trees (6.12.y, 6.6.y, etc.), the code
structure is completely different (separate functions, no rollback
logic), so this specific bug doesn't exist there.

## Verification

- **git log master** showed the prerequisite commits 341b0f1b6cba5 and
  f8c5f0dc77d86 are only in v6.18+
- **git tag --contains** confirmed both prerequisites are in v6.18-rc1+,
  not in any earlier release
- **git show v6.12:drivers/clk/renesas/rzg2l-cpg.c** confirmed older
  stable trees have separate assert/deassert functions without the
  `__rzg2l_cpg_assert()` helper and without any error rollback logic
- **Read of current file** confirmed the code matches the "before" state
  of the diff
- **Code analysis** verified the XOR-based rollback logic is correct:
  when asserting, `value = mask << 16` (no lower mask), XOR with mask
  adds it → deasserts; when deasserting, `value = (mask << 16) | mask`,
  XOR with mask removes it → re-asserts
- **Variable shadowing confirmed**: `readl_poll_timeout_atomic` modifies
  the `value` parameter in-place, so using it for both the initial write
  value and poll output is a real bug (though in practice the old code's
  `if (ret && !assert)` branch reassigned `value`, masking the issue for
  deassert)

## Decision

This is a legitimate bug fix that:
1. Fixes a real issue where assert failure during suspend leaves
   hardware in a non-operational state
2. Also fixes a variable shadowing bug (reusing `value` for two
   different purposes)
3. Is small, contained, reviewed by the subsystem maintainer
4. Meets stable kernel criteria

However, it has hard dependencies on two refactoring/feature commits
from v6.18 that are not in any current stable tree. The only applicable
stable tree would be 6.18.y. Given that this is a genuine fix for an
error recovery path that matters during suspend/resume, and it's
applicable to 6.18.y, it should be backported.

**YES**

 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-cpg.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 = BIT(info->resets[id].bit);
 	s8 monbit = info->resets[id].monbit;
 	u32 value = mask << 16;
+	u32 mon;
 	int ret;
 
 	dev_dbg(rcdev->dev, "%s id:%ld offset:0x%x\n",
@@ -1667,10 +1668,10 @@ static int __rzg2l_cpg_assert(struct reset_controller_dev *rcdev,
 		return 0;
 	}
 
-	ret = readl_poll_timeout_atomic(priv->base + reg, value,
-					assert == !!(value & mask), 10, 200);
-	if (ret && !assert) {
-		value = mask << 16;
+	ret = readl_poll_timeout_atomic(priv->base + reg, mon,
+					assert == !!(mon & mask), 10, 200);
+	if (ret) {
+		value ^= mask;
 		writel(value, priv->base + CLK_RST_R(info->resets[id].off));
 	}
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] 9p/xen: protect xen_9pfs_front_free against concurrent calls

[Sasha Levin]

From: Stefano Stabellini <stefano.stabellini@amd.com>

[ 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 address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
[   27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-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: 0000000000000000
[   27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000
[   27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000
[   27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68
[   27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040
[   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: 0000000000050660
[   27.052418] Call Trace:
[   27.052420]  <TASK>
[   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]  </TASK>
[   27.052465] Modules linked in:
[   27.052471] ---[ end trace 0000000000000000 ]---

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Message-ID: <20260129230348.2390470-1-stefano.stabellini@amd.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The 9p Xen transport driver was introduced in v4.12. So this bug affects
all stable trees from v4.12 onwards.

Now let me verify the specific race scenario described in the commit
message — double-free via concurrent calls to `xen_9pfs_front_free`:

Looking at the code flow in the current (unpatched) tree:

**Scenario for double-free:**

1. `xen_9pfs_front_probe()` allocates `priv`, adds to list, sets drvdata
   → OK
2. `xen_9pfs_front_changed()` receives `XenbusStateInitWait` → calls
   `xen_9pfs_front_init(dev)`
3. If `_init` fails, it calls `xen_9pfs_front_free(priv)` which does
   `list_del`, frees rings, frees `priv` → `priv` is freed, but drvdata
   still points to freed memory
4. Backend state continues changing → `XenbusStateClosing` arrives →
   `xenbus_frontend_closed(dev)` → triggers device removal →
   `xen_9pfs_front_remove()` called
5. `xen_9pfs_front_remove()` does `dev_get_drvdata(&dev->dev)` → gets
   stale pointer to freed memory → calls `xen_9pfs_front_free(priv)`
   again → **GPF/double-free**

This is the exact scenario described in the commit message and matches
the stack trace showing the crash in `xen_9pfs_front_free()` called from
`xen_9pfs_front_changed()`.

## Classification

- **Bug type**: Double-free / Use-after-free
- **Severity**: Kernel crash (general protection fault, Oops)
- **Trigger**: Xenbus backend state changes during 9pfs frontend
  initialization failure
- **Impact**: System crash in Xen guests using 9pfs
- **Scope**: net/9p/trans_xen.c only — single file, well-contained

## Risk Assessment

**Risk of the fix**: MEDIUM-LOW
- The fix restructures `_probe`, `_init`, `_remove`, and `_free`
  functions
- It's not a one-liner — about 170 lines are changed across the file
- However, all changes are logically consistent and well-motivated:
  - Moving allocation from probe to init is safe (probe just returns 0
    now)
  - Adding NULL check in remove prevents double-free
  - Using lock around drvdata access prevents TOCTOU race
  - Adding `if (priv->rings)` guard in free prevents NULL deref
- The author is Stefano Stabellini, the original 9p/xen driver author
- Reviewed and signed off by Dominique Martinet (9p maintainer)

**Risk of NOT backporting**: HIGH
- Kernel crash on Xen guests using 9p filesystem
- Reproducible by backend state changes (not just theoretical)
- Concrete Oops with stack trace demonstrated

## Stable Criteria Check

1. **Obviously correct and tested**: Yes — author is the subsystem
   creator, concrete crash trace provided, fix has clear logic
2. **Fixes a real bug**: Yes — double-free causing kernel GPF/crash
3. **Important issue**: Yes — kernel crash/oops
4. **Small and contained**: The diff is moderately sized (~170 lines)
   but confined to a single file and a single logical change
5. **No new features**: Correct — no new APIs or features added
6. **Clean application**: The stable tree (6.19.y) has the prerequisite
   commits `e43c608f40c06` and `7ef3ae82a6ebb`

## Dependencies

The commit depends on:
- `7ef3ae82a6ebb` "9p/xen: fix init sequence" — present in stable
  (confirmed in `git log HEAD`)
- `e43c608f40c06` "9p/xen: fix release of IRQ" — present in stable
  (confirmed)
- `ea4f1009408ef` "9p/xen: Fix use after free bug" — present in stable
  (confirmed)

All prerequisites are present in the 6.19.y stable tree.

## Verification

- **Read the current (unpatched) trans_xen.c**: Confirmed the pre-patch
  code at lines 276-320, 381-480, 482-499 showing the buggy lifecycle
- **Confirmed the race**: `xen_9pfs_front_init()` error path at line 478
  calls `xen_9pfs_front_free(priv)` which frees `priv`, but drvdata is
  not cleared. Subsequent `_remove()` at line 316 reads stale drvdata
  and calls `_free` again.
- **Confirmed 0x6b6b6b6b6b6b6b6b**: SLAB_FREE_DEBUG poison pattern,
  confirming access to freed slab memory
- **git log master -- net/9p/trans_xen.c**: Confirmed all prerequisite
  commits exist in the tree
- **git describe 868eb122739a5**: Confirmed driver exists since v4.12 —
  bug affects all stable trees
- **Author verification**: Stefano Stabellini is the original driver
  author (confirmed by copyright in file header and commit
  `71ebd71921e45`)
- **Maintainer sign-off**: Dominique Martinet signed off — he is the 9p
  maintainer
- **Checked prior related fixes**: `ea4f1009408ef` fixed a different
  race (work vs free), `7ef3ae82a6ebb` fixed init sequence — both are
  prerequisites present in stable
- **Unverified**: Whether older stable trees (6.6.y, 6.1.y, 5.15.y) have
  all prerequisites — the ring loop variable `XEN_9PFS_NUM_RINGS` and
  some code may differ. The commit may need backport adjustments for
  older trees.

## Conclusion

This is a clear-cut bug fix for a double-free/use-after-free crash in
the Xen 9p filesystem transport. The bug has a concrete reproducer with
a kernel Oops stack trace. The fix is self-contained in a single file,
authored by the original driver creator, and signed off by the subsystem
maintainer. While the change is moderately sized, every part of it
directly addresses the race condition. The risk of the fix is low
compared to the impact of the crash it prevents. All prerequisites exist
in the current stable tree.

**YES**

 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;
 
-	write_lock(&xen_9pfs_lock);
-	list_del(&priv->list);
-	write_unlock(&xen_9pfs_lock);
-
-	for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) {
-		struct xen_9pfs_dataring *ring = &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 = 0;
-			     j < (1 << priv->rings[i].intf->ring_order);
-			     j++) {
-				grant_ref_t ref;
-
-				ref = 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 = 0; i < XEN_9PFS_NUM_RINGS; i++) {
+			struct xen_9pfs_dataring *ring = &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 = 0;
+				     j < (1 << priv->rings[i].intf->ring_order);
+				     j++) {
+					grant_ref_t ref;
+
+					ref = 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);
 }
 
 static void xen_9pfs_front_remove(struct xenbus_device *dev)
 {
-	struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev);
+	struct xen_9pfs_front_priv *priv;
 
+	write_lock(&xen_9pfs_lock);
+	priv = dev_get_drvdata(&dev->dev);
+	if (priv == 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);
 }
 
@@ -382,7 +389,7 @@ static int xen_9pfs_front_init(struct xenbus_device *dev)
 {
 	int ret, i;
 	struct xenbus_transaction xbt;
-	struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev);
+	struct xen_9pfs_front_priv *priv;
 	char *versions, *v;
 	unsigned int max_rings, max_ring_order, len = 0;
 
@@ -410,6 +417,10 @@ static int xen_9pfs_front_init(struct xenbus_device *dev)
 	if (p9_xen_trans.maxsize > XEN_FLEX_RING_SIZE(max_ring_order))
 		p9_xen_trans.maxsize = XEN_FLEX_RING_SIZE(max_ring_order) / 2;
 
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+	priv->dev = dev;
 	priv->rings = 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 *dev)
 		goto error;
 	}
 
+	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;
 
@@ -482,19 +498,6 @@ static int xen_9pfs_front_init(struct xenbus_device *dev)
 static int xen_9pfs_front_probe(struct xenbus_device *dev,
 				const struct xenbus_device_id *id)
 {
-	struct xen_9pfs_front_priv *priv = NULL;
-
-	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-	if (!priv)
-		return -ENOMEM;
-
-	priv->dev = 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;
 }
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] clk: amlogic: remove potentially unsafe flags from S4 video clocks

[Sasha Levin]

From: Chuan Liu <chuan.liu@amlogic.com>

[ 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 <chuan.liu@amlogic.com>
Link: https://lore.kernel.org/r/20250919-add_video_clk-v6-3-fe223161fb3f@amlogic.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Wait, this is very confusing. The mailing list says patch 2 adds new
clocks, but git blame shows these video clock muxes (`cts_enci_sel`,
`cts_encp_sel`, etc.) were already in the original commit from 2023. Let
me re-read the diff more carefully.

Looking at the diff again: the commit removes `CLK_SET_RATE_PARENT` from
`s4_cts_enci_sel`, `s4_cts_encp_sel`, `s4_cts_vdac_sel`, and
`s4_hdmi_tx_sel`. Git blame confirmed these structures were added in
`57b55c76aaf1b` (2023, v6.7). The patch 2 of the series adds **new**
clocks (encl, cdac, demod, adc), but the ones being **fixed** in patch 3
already existed.

This means patch 3 (our commit) is **self-contained** with respect to
the bug fix — it removes flags from clocks that already exist in stable
trees. It does NOT depend on patch 2.

## Final Analysis

### Problem Description
The `CLK_SET_RATE_PARENT` flag on the video clock mux selectors
(`cts_enci_sel`, `cts_encp_sel`, `cts_vdac_sel`, `hdmi_tx_sel`) allows
rate change requests to propagate from these muxes up to their shared
parent clock. Since all four muxes share the same parent clock sources
(vclk_div and vclk2_div families), any one of them requesting a rate
change could alter the parent, breaking the other video outputs.

### Impact Assessment
- **Real bug**: Yes — when one video output (e.g., HDMI) requests a
  clock rate change, it can modify the shared parent clock, causing
  other video outputs (CVBS, encoder) to use the wrong clock rate. This
  could result in display corruption or loss of video signal.
- **Scope**: Affects all Amlogic S4 SoC users with multiple active video
  outputs, since v6.7.
- **Severity**: Medium — display corruption/failure when multiple video
  outputs are active simultaneously.

### Stable Kernel Criteria Assessment
- **Obviously correct**: Yes — removing `CLK_SET_RATE_PARENT` from
  shared mux selectors is a well-understood pattern for preventing
  unintended parent clock modifications.
- **Fixes a real bug**: Yes — prevents unintended shared parent clock
  modification affecting other video clocks.
- **Small and contained**: Yes — removes 4 lines (flag declarations)
  from a single file.
- **No new features**: Correct — purely a bug fix.
- **Risk**: Very low — removing `CLK_SET_RATE_PARENT` means the mux
  won't propagate rate changes upward, which is the desired behavior for
  shared clock sources. The downstream gate clocks still have
  `CLK_SET_RATE_PARENT`, so rate requests still propagate from the gate
  to the mux; they just stop there instead of going further up.

### Concerns
- **Dependency check**: The fix is self-contained. The affected clock
  structures exist since v6.7 (commit `57b55c76aaf1b`). No dependency on
  other patches in the series.
- **Behavioral change**: Users who relied on `CLK_SET_RATE_PARENT`
  propagation through the mux to the parent might see different
  behavior, but this "reliance" was always incorrect since it could
  break other video outputs.

## Verification

- **git blame** confirmed `s4_cts_enci_sel`, `s4_cts_encp_sel`,
  `s4_cts_vdac_sel`, `s4_hdmi_tx_sel` with `CLK_SET_RATE_PARENT` were
  introduced in `57b55c76aaf1b` (v6.7, September 2023).
- **git tag --contains 57b55c76aaf1b** confirmed the buggy code is in
  v6.7+ and v6.12.y LTS.
- **lore.kernel.org** confirmed this is patch 3/3 of the "add video-
  related clocks for S4 SoC" series, accepted December 2025 by Jerome
  Brunet.
- **lore.kernel.org patch 2** confirmed patch 2 adds **different**
  clocks (encl, cdac, demod, adc), not the ones being fixed here — the
  fix is independent.
- **Code inspection** confirmed `s4_cts_encl_sel` already lacked
  `CLK_SET_RATE_PARENT` (consistent architecture — encl was already
  correct).
- **Code inspection** confirmed downstream gate clocks (`s4_cts_enci`,
  `s4_cts_encp`) retain `CLK_SET_RATE_PARENT`, so rate propagation still
  works from gate to mux but stops at the mux level.
- **Could NOT verify** any user reports of actual display corruption
  from this bug (unverified — but the mechanism is sound and the fix is
  obvious).

The fix is small, surgical, self-contained, fixes a real clock-tree
correctness issue affecting all Amlogic S4 users since v6.7, and carries
extremely low regression risk. It meets all stable kernel criteria.

**YES**

 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-peripherals.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 = {
 		.ops = &clk_regmap_mux_ops,
 		.parent_hws = s4_cts_parents,
 		.num_parents = ARRAY_SIZE(s4_cts_parents),
-		.flags = CLK_SET_RATE_PARENT,
 	},
 };
 
@@ -1122,7 +1121,6 @@ static struct clk_regmap s4_cts_encp_sel = {
 		.ops = &clk_regmap_mux_ops,
 		.parent_hws = s4_cts_parents,
 		.num_parents = ARRAY_SIZE(s4_cts_parents),
-		.flags = CLK_SET_RATE_PARENT,
 	},
 };
 
@@ -1138,7 +1136,6 @@ static struct clk_regmap s4_cts_vdac_sel = {
 		.ops = &clk_regmap_mux_ops,
 		.parent_hws = s4_cts_parents,
 		.num_parents = ARRAY_SIZE(s4_cts_parents),
-		.flags = CLK_SET_RATE_PARENT,
 	},
 };
 
@@ -1169,7 +1166,6 @@ static struct clk_regmap s4_hdmi_tx_sel = {
 		.ops = &clk_regmap_mux_ops,
 		.parent_hws = s4_hdmi_tx_parents,
 		.num_parents = ARRAY_SIZE(s4_hdmi_tx_parents),
-		.flags = CLK_SET_RATE_PARENT,
 	},
 };
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] HID: i2c-hid: Add FocalTech FT8112

[Sasha Levin]

From: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>

[ 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 <Daniel_Peng@pegatron.corp-partner.google.com>
Acked-by: Jiri Kosina <jkosina@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20251117094041.300083-2-Daniel_Peng@pegatron.corp-partner.google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The ili2901 entry was added in December 2023. For older stable trees
that don't have that entry, the patch would need minor context
adjustment but the change itself is straightforward. Even without the
ili2901 entry as context, the addition inserts cleanly in the match
table.

## Verification

- **git log** confirmed `i2c-hid-of-elan.c` was first added in commit
  `bd3cba00dcc63` (May 2022), present in 6.1.y+ stable trees
- **git log** confirmed the file has had similar device additions
  (ili9882t, ili2901, ekth6a12nay) following the same pattern
- The code diff shows the new entry follows the exact struct pattern of
  existing entries
- The commit has `Reviewed-by: Douglas Anderson` and `Acked-by: Jiri
  Kosina` (verified in commit message)
- The compatible string `"focaltech,ft8112"` is a new vendor, but the
  driver architecture supports multiple vendors (it already has elan and
  ilitek)
- The `elan_i2c_hid_chip_data` struct is used identically for all
  devices in this driver
- The `ili2901` context entry was added in Dec 2023 (commit
  `03ddb7de012c6`), so the patch may need minor context adjustment for
  6.1.y but the logical change is trivial

## Conclusion

This is a textbook device ID / compatible string addition to an existing
driver. It enables a FocalTech FT8112 touchscreen that would otherwise
be completely non-functional. The change is:
- Small (~10 lines), isolated, and low-risk
- Following an established pattern in the driver
- Reviewed and acked by maintainers
- Critical for users with this hardware (no touchscreen = unusable
  device)

This is exactly the type of commit that the stable kernel exception for
device IDs was designed for.

**YES**

 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/i2c-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_ekth6a12nay_chip_data = {
 	.power_after_backlight = true,
 };
 
+static const struct elan_i2c_hid_chip_data focaltech_ft8112_chip_data = {
+	.post_power_delay_ms = 10,
+	.post_gpio_reset_on_delay_ms = 150,
+	.hid_descriptor_address = 0x0001,
+	.main_supply_name = "vcc33",
+};
+
 static const struct elan_i2c_hid_chip_data ilitek_ili9882t_chip_data = {
 	.post_power_delay_ms = 1,
 	.post_gpio_reset_on_delay_ms = 200,
@@ -191,6 +198,7 @@ static const struct elan_i2c_hid_chip_data ilitek_ili2901_chip_data = {
 static const struct of_device_id elan_i2c_hid_of_match[] = {
 	{ .compatible = "elan,ekth6915", .data = &elan_ekth6915_chip_data },
 	{ .compatible = "elan,ekth6a12nay", .data = &elan_ekth6a12nay_chip_data },
+	{ .compatible = "focaltech,ft8112", .data = &focaltech_ft8112_chip_data },
 	{ .compatible = "ilitek,ili9882t", .data = &ilitek_ili9882t_chip_data },
 	{ .compatible = "ilitek,ili2901", .data = &ilitek_ili2901_chip_data },
 	{ }
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Sasha Levin]

From: Daniel Palmer <daniel@thingy.jp>

[ 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=205, src=0x2f3971 <printk_shared_pbufs+205>, dest=0x2f3980 <printk_shared_pbufs+220>) at arch/m68k/lib/memmove.c:82

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
Signed-off-by: Greg Ungerer <gerg@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This file has existed since 2011, so it's in all current stable trees.
Let me also verify the CONFIG_M68000 check in memcpy to confirm the
pattern.

## Summary of Analysis

### Problem Being Fixed
On 68000 CPUs (CONFIG_M68000), `memmove()` performs word and long-word
memory accesses through a source pointer that may be at an odd address.
The 68000 CPU (unlike 68020+) generates an **address error exception**
(essentially a bus error/crash) on unaligned word or long-word accesses.

The existing `memcpy()` implementation already handles this correctly:
after aligning the destination pointer, it checks if the source is still
misaligned and falls back to byte-by-byte copy. The `memmove()`
implementation was missing this identical check.

### Real-World Impact
The commit message explicitly states this is triggered by `printk` — one
of the most fundamental kernel functions. This means:
- **Any kernel message output** on a 68000 system can crash the kernel
- The bug is easily triggered in normal operation
- It affects basic kernel boot and operation

### Code Change Assessment
- **Size**: +18 lines (two identical 9-line blocks for forward and
  backward copy paths)
- **Scope**: Single file, single function, architecture-specific
  (`CONFIG_M68000` only)
- **Pattern**: Exactly mirrors existing, tested `memcpy()` code
- **Risk**: Very low — the added code is conditionally compiled only for
  CONFIG_M68000, and follows an established pattern already used in
  `memcpy.c`
- **No new features**: This is purely a bug fix bringing `memmove()` to
  parity with `memcpy()`

### Stable Kernel Rules Compliance
1. **Obviously correct and tested**: Yes — mirrors `memcpy()` and author
   shows concrete triggering example
2. **Fixes a real bug**: Yes — unaligned access causes CPU
   exception/crash on 68000
3. **Fixes an important issue**: Yes — crashes on basic `printk`
   operations
4. **Small and contained**: Yes — 18 lines, single file, single
   function, only affects CONFIG_M68000
5. **No new features**: Correct — this is a bug fix only
6. **Clean application**: The file has minimal history, so this should
   apply cleanly to any stable tree

### Verification

- **Verified** that `memcpy.c` (lines 25-32) already has the identical
  `CONFIG_M68000` alignment fallback pattern that this patch adds to
  `memmove.c`
- **Verified** that `memmove.c` (the unpatched version read above) is
  missing this check — after aligning `dest`, it proceeds directly to
  word/long copies without checking `src` alignment
- **Verified** that the file `arch/m68k/lib/memmove.c` was originally
  added in commit 982cd252ca0b6 (2011), meaning it exists in all current
  stable kernel trees
- **Verified** the patch adds two `#if defined(CONFIG_M68000)` blocks,
  one for each copy direction (forward and backward), matching the
  structure of the existing `memcpy()` fix
- **Verified** via `git log` that this file has had very few changes
  since creation (only 2 commits in history: original creation and a
  dedup cleanup), meaning it should apply cleanly
- **Unverified**: Exact stable tree versions affected — but since the
  file dates to 2011 and the bug has existed since then, all current
  stable trees are affected

### Risk vs. Benefit
- **Risk**: Extremely low. The change is guarded by `#if
  defined(CONFIG_M68000)`, affects only 68000 CPUs, and mirrors proven
  code from `memcpy()`
- **Benefit**: Prevents crashes on a fundamental kernel operation
  (`printk` → `memmove`) on all 68000 systems

This is a clear, well-understood bug fix for a crash that affects basic
kernel operation on 68000 platforms. It's small, surgical, follows an
established pattern, and has zero risk to non-68000 systems.

**YES**

 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 = csrc;
 			n--;
 		}
+#if defined(CONFIG_M68000)
+		if ((long)src & 1) {
+			char *cdest = dest;
+			const char *csrc = src;
+			for (; n; n--)
+				*cdest++ = *csrc++;
+			return xdest;
+		}
+#endif
 		if (n > 2 && (long)dest & 2) {
 			short *sdest = dest;
 			const short *ssrc = src;
@@ -66,6 +75,15 @@ void *memmove(void *dest, const void *src, size_t n)
 			src = csrc;
 			n--;
 		}
+#if defined(CONFIG_M68000)
+		if ((long)src & 1) {
+			char *cdest = dest;
+			const char *csrc = src;
+			for (; n; n--)
+				*--cdest = *--csrc;
+			return xdest;
+		}
+#endif
 		if (n > 2 && (long)dest & 2) {
 			short *sdest = dest;
 			const short *ssrc = src;
-- 
2.51.0