[PATCH AUTOSEL 6.19-5.15] drm/v3d: Set DMA segment size to avoid debug warnings

[PATCH AUTOSEL 6.19-5.15] drm/v3d: Set DMA segment size to avoid debug warnings

[Sasha Levin]

From: Xiaolei Wang <xiaolei.wang@windriver.com>

[ 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=8290304] [max=65536]
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=--)
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 <xiaolei.wang@windriver.com>
Link: https://patch.msgid.link/20251203130323.2247072-1-xiaolei.wang@windriver.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### 1. Commit Message Analysis

The commit message is clear and well-documented. It explains:
- **The problem**: When CONFIG_DMA_API_DEBUG is enabled, V3D triggers a
  WARNING because `max_seg_size` is not set, defaulting to 64K.
- **The trigger**: Normal GPU rendering on Raspberry Pi 5 running Xorg.
- **The mechanism**: `debug_dma_map_sg()` detects that the scatterlist
  segment (8,290,304 bytes) exceeds the device's reported max (65,536
  bytes).
- A full stack trace is provided, confirming this is a real,
  reproducible issue hit during normal operation (PID 493 is Xorg).

### 2. Code Change Analysis

The patch adds a single line:

```c
dma_set_max_seg_size(&pdev->dev, UINT_MAX);
```

This is placed right after `dma_set_mask_and_coherent()` succeeds, which
is the natural location. It tells the DMA layer that V3D has no hardware
constraint on DMA segment sizes (because V3D uses its own MMU to handle
scatterlist mappings). The 64K default is simply incorrect for this
device.

### 3. Established Pattern Across DRM Subsystem

This is an extremely well-established pattern. My search found **17
other DRM drivers** making the exact same call:

- `drivers/gpu/drm/panfrost/panfrost_gpu.c` —
  `dma_set_max_seg_size(pfdev->base.dev, UINT_MAX);`
- `drivers/gpu/drm/i915/i915_driver.c` —
  `dma_set_max_seg_size(i915->drm.dev, UINT_MAX);`
- `drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c` —
  `dma_set_max_seg_size(adev->dev, UINT_MAX);`
- `drivers/gpu/drm/msm/msm_drv.c` — `dma_set_max_seg_size(dev,
  UINT_MAX);`
- `drivers/gpu/drm/imagination/pvr_device.c`, `lima`, `panthor`,
  `etnaviv`, `mediatek`, `vmwgfx`, `virtio`, `tidss`, `sun4i`, `xlnx`,
  `arm/komeda`, `xe`, `exynos`

The panfrost commit `ac5037afefd33` (2020) has the identical rationale:
"Since all we do with scatterlists is map them in the MMU, we don't have
any hardware constraints on how they're laid out. Let the DMA layer know
so it won't warn when DMA API debugging is enabled." V3D was simply
missed when this pattern was being applied across DRM drivers.

### 4. Bug Classification

This fixes a **kernel WARNING** that fires during normal GPU buffer
allocation. The call path is:

```
v3d_create_bo_ioctl → v3d_bo_create_finish → drm_gem_shmem_get_pages_sgt
→ dma_map_sgtable → debug_dma_map_sg (WARNING)
```

Every time a GPU buffer object larger than 64K is created (which is
virtually every BO for rendering), this warning fires. On a system with
DMA debug enabled, this causes severe log spam and performance
degradation from the warning path.

### 5. Backport Compatibility

- **V3D driver availability**: Added in v4.18, present in all current
  LTS trees (5.4, 5.10, 5.15, 6.1, 6.6, 6.12).
- **API compatibility**: In kernels before v6.12 (commit
  `334304ac2baca`), `dma_set_max_seg_size` returns `int` instead of
  `void`. Since this patch does **not** check the return value, it
  compiles cleanly on both old and new signatures.
- **Context adjustment**: In older stable trees (6.6, 6.1, etc.), the
  error path after `dma_set_mask_and_coherent` uses `return ret;`
  instead of `goto clk_disable;`. This means the patch won't apply
  verbatim, but the fix is trivial to adapt — the `dma_set_max_seg_size`
  line just needs to be inserted between the mask check and
  `v3d->va_width =`, regardless of the surrounding error handling style.

### 6. Risk Assessment

- **Size**: 1 line added, 1 file changed — minimal.
- **Scope**: Only affects V3D DMA segment size metadata — no functional
  change to DMA mapping behavior at runtime.
- **Regression risk**: Near zero. If the call fails (impossible for
  platform devices which always have `dma_parms`), the result is the
  status quo (warnings continue).
- **Testing**: The author tested on Raspberry Pi 5, and the maintainer
  (Maíra Canal) signed off.

### 7. User Impact

- **Who is affected**: Raspberry Pi 5 users (V3D 7.1) and Raspberry Pi 4
  users (V3D 4.2) running any graphical desktop with
  CONFIG_DMA_API_DEBUG enabled.
- **Severity**: Kernel WARNING spam during every buffer allocation,
  causing log pollution and potential performance issues from the
  warning code path.
- **Real-world**: The reporter was using a Yocto-based system
  (6.12.53-yocto-standard), showing this is a production environment.

### 8. Stable Criteria Check

| Criterion | Met? |
|-----------|------|
| Obviously correct and tested | Yes — one-line, well-established
pattern, tested on real hardware |
| Fixes a real bug | Yes — WARNING during normal GPU operation |
| Important issue | Yes — affects normal rendering on popular hardware |
| Small and contained | Yes — 1 line, 1 file |
| No new features | Yes — just configures existing DMA parameter |
| Applies to stable | Yes — trivial context adjustment needed for older
trees |

This is an ideal stable candidate: a tiny, obviously correct fix for a
real issue, following an established pattern used by 17 other DRM
drivers, with zero regression risk.

**YES**

 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_device *pdev)
 	if (ret)
 		goto clk_disable;
 
+	dma_set_max_seg_size(&pdev->dev, UINT_MAX);
+
 	v3d->va_width = 30 + V3D_GET_FIELD(mmu_debug, V3D_MMU_VA_WIDTH);
 
 	ident1 = V3D_READ(V3D_HUB_IDENT1);
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] ASoC: fsl: imx-rpmsg: use snd_soc_find_dai_with_mutex() in probe

[Sasha Levin]

From: Ziyi Guo <n7l8m4@u.northwestern.edu>

[ 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 <n7l8m4@u.northwestern.edu>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260205052429.4046903-1-n7l8m4@u.northwestern.edu
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The wrapper was added in 2020, so it exists in all currently maintained
stable trees (5.10+, 5.15+, 6.1+, 6.6+, 6.12+). This confirms the fix
will apply cleanly to all relevant stable branches.

### User Impact

- Without this fix, users with i.MX RPMSG sound cards will hit **lockdep
  warnings** during probe when `CONFIG_PROVE_LOCKING` is enabled
- More seriously, without the lock, there is a real (though perhaps
  rare) **race condition** where concurrent component
  registration/deregistration during probe could corrupt the component
  list, leading to crashes or undefined behavior
- The i.MX RPMSG audio is used on NXP i.MX SoC platforms, which are
  widely deployed in embedded systems

### Stability Indicators

- **Reviewed-by: Frank Li** (NXP maintainer) - indicates domain
  expertise review
- **Applied by Mark Brown** (ASoC subsystem maintainer) - indicates
  acceptance by the subsystem maintainer
- Single-line change with zero risk of regression

### Summary

This is a textbook stable backport candidate:
1. **Fixes a real bug**: Missing lock protection for a global list
   traversal (race condition + lockdep warning)
2. **Obviously correct**: Uses the existing mutex wrapper that all other
   callers use
3. **Small and surgical**: Single line change
4. **No new features**: Just corrects locking
5. **Low risk**: The wrapper function has existed since 2020 and is
   well-tested
6. **No dependencies**: Self-contained fix

**YES**

 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 = 1;
 
 	data->dai.cpus->dai_name = pdev->dev.platform_data;
-	cpu_dai = snd_soc_find_dai(data->dai.cpus);
+	cpu_dai = snd_soc_find_dai_with_mutex(data->dai.cpus);
 	if (!cpu_dai) {
 		ret = -EPROBE_DEFER;
 		goto fail;
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release

[Sasha Levin]

From: Ludovic Desroches <ludovic.desroches@microchip.com>

[ 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:

=============================================================================
BUG kmalloc-64 (Not tainted): Poison overwritten
-----------------------------------------------------------------------------

0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b
FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b
Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0
pid=29
 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=8 cpu=0
pid=169
 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=21 used=16 fp=0xc611b7c0
flags=0x200(workingset|zone=0)
Object 0xc611b340 @offset=832 fp=0xc611b7c0

Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Reviewed-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-2-79b615130dc3@microchip.com
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This confirms the fix. The key lines in the helper are:

```c
state->fence = NULL;
state->commit = NULL;      // THIS is the critical fix
state->fb_damage_clips = NULL;
```

The old code was missing the `state->commit = NULL` step. By using the
helper, the commit pointer is properly set to NULL in the duplicated
state, preventing the use-after-free when the old state's commit is
freed.

Additionally, `state->fence` and `state->fb_damage_clips` were also not
being properly handled in the old code — the helper fixes multiple
potential issues at once.

### 3. CLASSIFICATION

- **Bug type**: Use-after-free (UAF) — one of the most critical bug
  categories for stable
- **Severity**: HIGH — UAF can lead to kernel crashes, data corruption,
  and potentially security vulnerabilities
- **Reproducibility**: PROVEN — the commit includes a full stack trace
  from a real reproduction

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: Net -1 line (replaced 2 lines with 1 line)
- **Files touched**: 1 file (`atmel_hlcdc_plane.c`)
- **Complexity**: Minimal — uses the standard, well-tested DRM helper
  function
- **Risk of regression**: Extremely low — this replaces incorrect manual
  code with the standard pattern used by virtually all other DRM drivers
- **The destroy_state function already uses
  `__drm_atomic_helper_plane_destroy_state`**, so using the duplicate
  counterpart is the correct and symmetric approach

### 5. USER IMPACT

- Affects users of Atmel HLCDC display controllers (common in
  Atmel/Microchip SoCs used in embedded systems)
- The bug triggers when closing and re-opening display device nodes
  while another client (e.g., fbdev emulation) remains — a realistic
  scenario
- Impact when triggered: kernel BUG (slab corruption), which can lead to
  crashes or worse

### 6. STABILITY INDICATORS

- **Reviewed-by**: Manikandan Muralidharan (subsystem maintainer for
  this driver)
- **Author**: Ludovic Desroches from Microchip — the hardware vendor's
  own engineer
- The fix uses a well-established DRM helper function that has been
  stable for years

### 7. DEPENDENCY CHECK

- `__drm_atomic_helper_plane_duplicate_state()` has existed in the
  kernel since at least 4.x series — no dependency issues for any active
  stable tree
- The atmel-hlcdc driver exists in all active stable trees
- The fix is completely self-contained — no other patches needed

### Summary

This is a textbook stable backport candidate:
- **Obviously correct**: Replaces broken manual code with the standard
  DRM helper
- **Fixes a real bug**: UAF proven with stack trace
- **Small and contained**: 1 file, net -1 line change
- **No new features**: Pure bug fix
- **Low regression risk**: Uses established, well-tested helper function
- **Real-world impact**: Reproducible crash scenario on embedded
  hardware

**YES**

 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_plane *p)
 		return NULL;
 	}
 
-	if (copy->base.fb)
-		drm_framebuffer_get(copy->base.fb);
+	__drm_atomic_helper_plane_duplicate_state(p, &copy->base);
 
 	return &copy->base;
 }
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.15] spi: stm32: fix Overrun issue at < 8bpw

[Sasha Levin]

From: Deepak Kumar <deepak.kumar01@st.com>

[ 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 <deepak.kumar01@st.com>
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://patch.msgid.link/20251218-stm32-spi-enhancements-v2-2-3b69901ca9fe@foss.st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis.

## Comprehensive Analysis

### 1. COMMIT MESSAGE ANALYSIS

The subject line is **"spi: stm32: fix Overrun issue at < 8bpw"** -- a
clear bug fix. The body explains a hardware-level problem on the STM32H7
SPI controller: when SPI communication is suspended by the hardware
automatically, a few bits of the next frame can already be clocked out
due to internal synchronization delay. To achieve safe suspension, each
word must be at least 8 SPI clock cycles long. When `bits_per_word`
(bpw) is less than 8, the MIDI (Minimum Inter-Data Idleness) delay must
be increased to pad the total word time to at least 8 SPI clock cycles.

The commit is authored by an ST Microelectronics engineer (Deepak Kumar
at `st.com`), co-authored/signed by Alain Volmat (STM32 SPI maintainer
at `foss.st.com`), and merged by Mark Brown (SPI subsystem maintainer).
This lends high credibility.

### 2. CODE CHANGE ANALYSIS

The diff modifies `stm32h7_spi_data_idleness()` in `drivers/spi/spi-
stm32.c`:

**Old code (lines 1909-1912):**
```c
u32 midi = min_t(u32,
                 DIV_ROUND_UP(spi->cur_midi, sck_period_ns),
                 FIELD_GET(STM32H7_SPI_CFG2_MIDI,
                 STM32H7_SPI_CFG2_MIDI));
```

**New code:**
```c
u32 midi = DIV_ROUND_UP(spi->cur_midi, sck_period_ns);

if ((spi->cur_bpw + midi) < 8)
    midi = 8 - spi->cur_bpw;

midi = min_t(u32, midi, FIELD_MAX(STM32H7_SPI_CFG2_MIDI));
```

The changes are:
1. **Core fix (3 lines):** After computing the initial midi value, check
   if `bpw + midi < 8`. If so, increase midi to `8 - bpw`, ensuring a
   minimum total of 8 SPI clock cycles per word. This prevents the
   overrun condition.
2. **Style cleanup:** Replace `FIELD_GET(STM32H7_SPI_CFG2_MIDI,
   STM32H7_SPI_CFG2_MIDI)` with `FIELD_MAX(STM32H7_SPI_CFG2_MIDI)`. Both
   evaluate to 15 (the field is GENMASK(7,4), a 4-bit field), but
   `FIELD_MAX` is the semantically correct macro for getting the maximum
   field value.
3. **Reorder:** The clamping to maximum is now done AFTER the overrun
   adjustment, ensuring the adjustment isn't clamped away prematurely.

**Example scenario:** With bpw=4 and midi=1 (from a 100ns delay at 10MHz
clock):
- **Old:** Total = 4+1 = 5 cycles/word. Hardware suspension can corrupt
  next frame. → Overrun
- **New:** Since 4+1 < 8, midi is set to 4. Total = 4+4 = 8 cycles/word.
  → Safe suspension

### 3. THE BUG AND ITS IMPACT

When the STM32H7 SPI controller's overrun condition fires
(`STM32H7_SPI_SR_OVR`), the interrupt handler at line 1111-1113 logs
`"Overrun: RX data lost"` and sets `end = true`, which terminates the
transfer. This means:
- **Data loss** - received SPI data is discarded
- **Transfer failure** - the SPI communication is aborted
- Any device using bpw < 8 with MIDI configured experiences
  corrupted/failed SPI transfers

This is a real hardware bug affecting real STM32H7/STM32MP25 users with
SPI devices that use fewer than 8 bits per word.

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** Net +3 lines of logic. Very small.
- **Files touched:** 1 file (`drivers/spi/spi-stm32.c`).
- **Risk:** Very low. The new logic only activates when `spi->cur_bpw <
  8` AND `cur_midi > 0`. For all transfers with bpw >= 8 (the vast
  majority), behavior is completely unchanged. Even for bpw < 8 cases,
  the fix just increases the inter-data delay slightly, which is correct
  per the hardware spec.
- **Side effects:** Slightly longer word timing for bpw < 8. This is the
  desired behavior to prevent overrun.

### 5. DEPENDENCY ANALYSIS

This is the most significant concern. The function
`stm32h7_spi_data_idleness()` was significantly modified by:
- **`4956bf4452439`** ("spi: stm32: deprecate `st,spi-midi-ns`
  property", June 2025, v6.17-rc1): Changed the function signature from
  `(struct stm32_spi *spi, u32 len)` to `(struct stm32_spi *spi, struct
  spi_transfer *xfer)` and added the `spi_delay_ns` word_delay logic.
- **`244bc18e5f187`** ("spi: stm32: delete stray tabs", June 2025,
  v6.17-rc1+): Fixed indentation.

Both of these are post-6.16. Stable trees (6.12.y, 6.6.y, 6.1.y, 5.15.y)
have the **old** version of this function with the simpler `(spi, len)`
signature. However, the critical MIDI calculation block exists in ALL
versions since the driver's inception:

```c
if ((len > 1) && (spi->cur_midi > 0)) {
    u32 sck_period_ns = DIV_ROUND_UP(NSEC_PER_SEC, spi->cur_speed);
    u32 midi = min_t(u32,
                     DIV_ROUND_UP(spi->cur_midi, sck_period_ns),
                     FIELD_GET(STM32H7_SPI_CFG2_MIDI,
STM32H7_SPI_CFG2_MIDI));
```

The core 3-line overrun fix can be applied to the old function with
trivial context adjustment. The fix does not depend on the new function
signature -- it only uses `spi->cur_bpw` which has existed since the
driver was added.

### 6. CLASSIFICATION

This is a **hardware bug workaround / driver bug fix**. It's analogous
to a hardware quirk -- the STM32H7 SPI hardware requires at least 8
clock cycles per word for safe suspension, and the driver was not
enforcing this. The fix adds the enforcement.

### 7. VERDICT

**Positive factors:**
- Fixes a real, documented hardware issue (overrun = data loss +
  transfer failure)
- Extremely small and surgical (3 lines of logic)
- Very low regression risk (only affects bpw < 8 with midi configured)
- Authored by the hardware vendor (ST Microelectronics) who understands
  the hardware
- Reviewed and merged by the SPI subsystem maintainer
- The affected code exists in all stable trees since the driver was
  added (2017)

**Concerns:**
- The patch as-is won't apply cleanly to stable trees due to the
  function signature change from `4956bf4452439`, but the fix logic is
  self-contained and can be trivially adapted
- The fix only applies when `cur_midi > 0` (some inter-data delay is
  configured), so overrun with zero midi is not addressed (but this
  appears intentional)

The fix is small, surgical, and meets all stable kernel criteria. It
fixes a real hardware bug causing data loss for STM32H7 SPI users using
bpw < 8.

**YES**

 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 |= STM32H7_SPI_CFG2_MIDI;
 	if ((len > 1) && (spi->cur_midi > 0)) {
 		u32 sck_period_ns = DIV_ROUND_UP(NSEC_PER_SEC, spi->cur_speed);
-		u32 midi = min_t(u32,
-				 DIV_ROUND_UP(spi->cur_midi, sck_period_ns),
-				 FIELD_GET(STM32H7_SPI_CFG2_MIDI,
-				 STM32H7_SPI_CFG2_MIDI));
+		u32 midi = DIV_ROUND_UP(spi->cur_midi, sck_period_ns);
 
+		if ((spi->cur_bpw + midi) < 8)
+			midi = 8 - spi->cur_bpw;
+
+		midi = min_t(u32, midi, FIELD_MAX(STM32H7_SPI_CFG2_MIDI));
 
 		dev_dbg(spi->dev, "period=%dns, midi=%d(=%dns)\n",
 			sck_period_ns, midi, midi * sck_period_ns);
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback

[Sasha Levin]

From: Ludovic Desroches <ludovic.desroches@microchip.com>

[ 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 <ludovic.desroches@microchip.com>
Reviewed-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-1-79b615130dc3@microchip.com
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of drm/atmel-hlcdc: fix memory leak from
atomic_destroy_state callback

### 1. Commit Message Analysis

The commit message is explicit and well-documented:
- **Subject clearly states "fix memory leak"** - this is a bug fix
- **Detailed explanation**: `drm_crtc_commit` objects are not being
  freed because the `atomic_destroy_state` callback only puts the
  framebuffer, but doesn't clean up other objects held in the plane
  state
- **Includes kmemleak backtrace** - the bug is reproducible and
  confirmed with a kernel debugging tool
- **Real-world impact described**: "seen after hours of usage of a
  graphics application" - this affects actual users running graphical
  applications on Atmel/Microchip SoCs
- **Reviewed-by tag** from the subsystem maintainer

### 2. Code Change Analysis

The fix is extremely small and surgical - it replaces a manual
`drm_framebuffer_put()` call with
`__drm_atomic_helper_plane_destroy_state()`.

**What was wrong:**
```c
// OLD - only freed the framebuffer reference
if (s->fb)
    drm_framebuffer_put(s->fb);
```

**What the fix does:**
```c
// NEW - properly cleans up ALL objects in the plane state
__drm_atomic_helper_plane_destroy_state(s);
```

The function `__drm_atomic_helper_plane_destroy_state()` is the standard
DRM helper that properly releases all resources associated with a plane
state, including:
- The framebuffer reference (what was already done)
- The fence
- The `drm_crtc_commit` object (what was being leaked)
- Any other state tracked by the DRM core

This is a textbook case of a driver not using the standard helper
function, leading to incomplete cleanup and memory leaks. The
`drm_crtc_commit` objects accumulate over time, consuming slab memory.

### 3. Classification

- **Bug type**: Memory leak (resource leak)
- **Severity**: Medium-high - progressive memory consumption over hours
  of use eventually impacts system stability
- **Category**: Missing cleanup in a standard callback that should use
  the DRM helper function

### 4. Scope and Risk Assessment

- **Lines changed**: 3 lines (2 removed, 1 added) - extremely minimal
- **Files changed**: 1 file only
- **Risk**: Very low - `__drm_atomic_helper_plane_destroy_state()` is a
  well-established DRM core helper function used by virtually all DRM
  drivers. It's a superset of what was already being done (framebuffer
  put), plus proper cleanup of other state objects. This is not
  introducing new behavior; it's completing the cleanup that should have
  always been done.
- **Could it break something?** Extremely unlikely. The helper function
  does exactly what the old code did (put framebuffer) plus additional
  necessary cleanup.

### 5. User Impact

- **Affected users**: Anyone using the Atmel HLCDC display controller
  (common in Microchip/Atmel SAM series SoCs used in embedded systems)
- **Symptoms**: Gradual memory consumption increase during graphics
  usage, eventually leading to OOM or degraded system performance
- **Trigger**: Normal graphics usage over time - this is a hot path hit
  on every atomic commit
- **Severity if triggered**: Memory leak in a frequently-called path
  leads to eventual system degradation or OOM

### 6. Stability Indicators

- **Reviewed-by** from subsystem maintainer (Manikandan Muralidharan)
- Uses a standard, well-tested DRM helper function
- The fix pattern (replacing manual cleanup with the proper helper) is a
  very common and well-understood DRM fix

### 7. Dependency Check

- `__drm_atomic_helper_plane_destroy_state()` has been available in the
  DRM subsystem for many years (since 2015+), so it exists in all active
  stable trees
- No dependency on other patches - this is a self-contained fix

### 8. Stable Kernel Rules Compliance

1. **Obviously correct and tested**: Yes - uses the standard helper,
   confirmed with kmemleak
2. **Fixes a real bug**: Yes - memory leak confirmed with kmemleak and
   observed in production use
3. **Important issue**: Yes - progressive memory leak in a hot path
   affecting embedded systems
4. **Small and contained**: Yes - 3-line change in a single file
5. **No new features**: Correct - pure bug fix
6. **Applies cleanly**: Should apply cleanly as this is a driver-
   specific change in a stable file

### Summary

This is a clear-cut memory leak fix. It's small, surgical, uses a
standard helper function, has been confirmed with kmemleak, affects real
users running graphics applications on Atmel/Microchip embedded
hardware, and carries virtually no regression risk. It meets all stable
kernel backport criteria.

**YES**

 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(struct drm_plane *p,
 			      state->dscrs[i]->self);
 	}
 
-	if (s->fb)
-		drm_framebuffer_put(s->fb);
+	__drm_atomic_helper_plane_destroy_state(s);
 
 	kfree(state);
 }
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.1] media: rkisp1: Fix filter mode register configuration

[Sasha Levin]

From: Rui Wang <rui.wang@ideasonboard.com>

[ 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 <rui.wang@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20260105171142.147792-2-rui.wang@ideasonboard.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit message clearly describes a **bug fix**: the
`rkisp1_flt_config()` function performs an initial direct write to the
`RKISP1_CIF_ISP_FILT_MODE` register that **clears the filter enable
bit** (`RKISP1_CIF_ISP_FLT_ENA`). The subsequent read/modify/write
sequence reads back the register with the enable bit already cleared and
cannot restore it. This results in the **ISP filter being inadvertently
disabled** whenever its configuration is updated.

The fix removes the redundant direct write, leaving only the
read/modify/write sequence that correctly preserves the enable bit.

### Code Change Analysis

The diff is straightforward:

**Removed code (the bug):**
```c
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));
```

This write sets the mode register but does **not** include the
`RKISP1_CIF_ISP_FLT_ENA` bit, effectively disabling the filter in
hardware.

**Preserved code (the correct path):**
```c
filt_mode = rkisp1_read(params->rkisp1, RKISP1_CIF_ISP_FILT_MODE);
filt_mode &= RKISP1_CIF_ISP_FLT_ENA;
// ... build up new mode value preserving enable bit ...
rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_FILT_MODE, filt_mode);
```

The read/modify/write sequence correctly reads the current register
value, preserves only the enable bit, then OR's in the new
configuration. But because the direct write above already cleared the
enable bit, reading it back gets a 0 for the enable bit - defeating the
entire purpose of the read/modify/write pattern.

### Bug Mechanism

1. Filter is enabled (FLT_ENA bit = 1 in hardware register)
2. User updates filter configuration parameters
3. `rkisp1_flt_config()` is called
4. Direct write clears FLT_ENA bit (writes mode without enable)
5. Read/modify/write reads back register with FLT_ENA = 0
6. Final write does not have FLT_ENA set
7. **Filter is now disabled** even though user only wanted to change
   configuration

This is a real functional bug that affects image processing quality on
Rockchip platforms using the ISP (Image Signal Processor).

### Scope and Risk

- **Size**: Removal of 5 lines of code. Extremely small and surgical.
- **Files**: Single file change (`rkisp1-params.c`)
- **Risk**: Very low. The removed code is entirely redundant - the
  read/modify/write sequence that follows does everything the direct
  write did, plus correctly preserves the enable bit. Removing the
  direct write can only improve behavior.
- **Subsystem**: Media/camera driver for Rockchip ISP - well-defined
  scope, won't affect other subsystems.

### Review Quality

The commit has been reviewed by three experienced media subsystem
developers:
- Stefan Klug (Reviewed-by)
- Kieran Bingham (Reviewed-by)
- Laurent Pinchart (Reviewed-by, also signed off as maintainer)

Merged by Hans Verkuil, the V4L2 subsystem maintainer.

### User Impact

This bug affects anyone using the Rockchip ISP filter (noise reduction,
sharpening) on platforms like RK3399 and similar SoCs. When the filter
configuration is updated, the filter gets inadvertently disabled,
leading to degraded image quality. This is particularly relevant for
embedded systems and cameras that use stable kernels.

### Stable Criteria Assessment

- **Obviously correct**: Yes - removing a redundant write that defeats
  the read/modify/write pattern is clearly correct
- **Fixes a real bug**: Yes - filter being disabled when reconfigured is
  a real functional bug
- **Small and contained**: Yes - 5 lines removed from a single function
  in a single file
- **No new features**: Correct - pure bug fix
- **Tested**: Multiple reviews from domain experts

**YES**

 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/drivers/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 *params,
 	rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_FILT_LUM_WEIGHT,
 		     arg->lum_weight);
 
-	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 = rkisp1_read(params->rkisp1, RKISP1_CIF_ISP_FILT_MODE);
 	filt_mode &= RKISP1_CIF_ISP_FLT_ENA;
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.15] drm/atmel-hlcdc: don't reject the commit if the src rect has fractional parts

[Sasha Levin]

From: Ludovic Desroches <ludovic.desroches@microchip.com>

[ Upstream commit 06682206e2a1883354ed758c09efeb51f435adbd ]

Don’t reject the commit when the source rectangle has fractional parts.
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 <ludovic.desroches@microchip.com>
Reviewed-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Link: https://patch.msgid.link/20251120-lcd_scaling_fix-v1-1-5ffc98557923@microchip.com
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of drm/atmel-hlcdc: don't reject the commit if the src rect
has fractional parts

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly describes a bug fix: the driver was
incorrectly rejecting valid plane configurations when the source
rectangle had fractional (subpixel) parts. The fractional parts are
legitimately introduced by `drm_rect_clip_scaled()` during the atomic
check process, but the driver was treating them as invalid input and
returning `-EINVAL`.

Keywords: "don't reject" — this is fixing a false rejection of valid
display configurations.

### 2. CODE CHANGE ANALYSIS

The change is straightforward and well-contained:

**What was happening before:**
1. `hstate->src_x/y/w/h` were assigned the raw 16.16 fixed-point values
   from `s->src`
2. A check was performed: if any of these values had bits set in the
   lower 16 bits (fractional part, via `SUBPIXEL_MASK = 0xffff`), the
   function returned `-EINVAL`
3. Only after passing that check were the values right-shifted by 16 to
   get integer pixel coordinates

**What happens now:**
1. `hstate->src_x/y/w/h` are assigned the values right-shifted by 16
   immediately (converting to integer pixels)
2. The subpixel mask check is completely removed
3. The `SUBPIXEL_MASK` macro definition is removed as it's no longer
   needed

**The bug:** `drm_atomic_helper_check_plane_state()` calls
`drm_rect_clip_scaled()`, which can introduce fractional parts when
computing clipped source rectangles during scaling operations. This is
normal DRM behavior — the fractional parts represent subpixel precision
in the scaling calculation. The Atmel HLCDC hardware doesn't support
subpixel addressing, so the correct behavior is to truncate (>> 16) and
use integer coordinates, not reject the entire configuration.

**Impact of the bug:** When scaling is involved and clipping produces
fractional coordinates, display operations would fail with `-EINVAL`.
This means users would see display failures (plane updates rejected) in
legitimate scaling scenarios. This is a real user-visible bug — display
output fails when it shouldn't.

### 3. CLASSIFICATION

This is a **bug fix**. The driver was incorrectly rejecting valid atomic
commits, causing display failures during scaling operations. No new
features are added, no new APIs introduced.

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** ~15 lines removed, ~4 lines modified — very small
- **Files touched:** 1 file (`atmel_hlcdc_plane.c`)
- **Subsystem:** DRM driver for Atmel HLCDC (embedded ARM display
  controller)
- **Risk:** Very low. The change simply truncates subpixel precision
  instead of rejecting it. The hardware can only address whole pixels
  anyway, so truncation is the correct behavior. The integer parts of
  the coordinates are unchanged.
- **Could it break something?** Extremely unlikely. The only behavioral
  change is accepting configurations that were previously rejected. The
  pixel coordinates used are identical (same >> 16 operation, just done
  earlier).

### 5. USER IMPACT

This affects users of Atmel/Microchip SAM9/SAMA5 SoC-based embedded
systems that use the HLCDC display controller with plane scaling. When
scaling is active and clipping occurs, display updates would fail. This
is a real-world scenario for embedded display applications.

### 6. STABILITY INDICATORS

- **Reviewed-by:** Manikandan Muralidharan (subsystem maintainer)
- **Author:** Ludovic Desroches (Microchip engineer, familiar with the
  hardware)
- The fix is logically sound — truncating subpixel coordinates is
  standard practice in DRM drivers that don't support subpixel precision

### 7. DEPENDENCY CHECK

The commit is self-contained. It doesn't depend on any other changes.
The code it modifies (`atmel_hlcdc_plane_atomic_check`) has been present
in stable trees for a long time. The functions it interacts with
(`drm_atomic_helper_check_plane_state`, `drm_rect_width/height`) are
standard DRM helpers available in all stable trees.

### Summary

This is a small, well-understood bug fix for an incorrect rejection of
valid display configurations in the Atmel HLCDC driver. The fix is
surgical (removes an overly strict validation check and shifts the
coordinate conversion earlier), has been reviewed by the subsystem
maintainer, and carries minimal risk of regression. It fixes a real
user-visible bug (display failures during scaling with clipping) that
affects embedded systems using this display controller.

**YES**

 .../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_plane_state *s)
 	return container_of(s, struct atmel_hlcdc_plane_state, base);
 }
 
-#define SUBPIXEL_MASK			0xffff
-
 static uint32_t rgb_formats[] = {
 	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;
 
-	hstate->src_x = s->src.x1;
-	hstate->src_y = s->src.y1;
-	hstate->src_w = drm_rect_width(&s->src);
-	hstate->src_h = drm_rect_height(&s->src);
+	hstate->src_x = s->src.x1 >> 16;
+	hstate->src_y = s->src.y1 >> 16;
+	hstate->src_w = drm_rect_width(&s->src) >> 16;
+	hstate->src_h = drm_rect_height(&s->src) >> 16;
 	hstate->crtc_x = s->dst.x1;
 	hstate->crtc_y = s->dst.y1;
 	hstate->crtc_w = drm_rect_width(&s->dst);
 	hstate->crtc_h = drm_rect_height(&s->dst);
 
-	if ((hstate->src_x | hstate->src_y | hstate->src_w | hstate->src_h) &
-	    SUBPIXEL_MASK)
-		return -EINVAL;
-
-	hstate->src_x >>= 16;
-	hstate->src_y >>= 16;
-	hstate->src_w >>= 16;
-	hstate->src_h >>= 16;
-
 	hstate->nplanes = fb->format->num_planes;
 	if (hstate->nplanes > ATMEL_HLCDC_LAYER_MAX_PLANES)
 		return -EINVAL;
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] gpio: aspeed-sgpio: Change the macro to support deferred probe

[Sasha Levin]

From: Billy Tsai <billy_tsai@aspeedtech.com>

[ 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 <linusw@kernel.org>
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-1-69cfd1631400@aspeedtech.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of gpio: aspeed-sgpio: Change the macro to support deferred
probe

### Commit Message Analysis

The commit changes `module_platform_driver_probe()` to
`module_platform_driver()` in the Aspeed SGPIO driver. The motivation is
to support deferred probing — when the clock resource isn't available
yet at probe time due to probe ordering, the driver should be able to
defer and retry later. With `module_platform_driver_probe()` (which uses
`__platform_driver_probe()`), deferred probing is explicitly not
supported.

### Code Change Analysis

The changes are:

1. **Remove `__init` annotation** from `aspeed_sgpio_probe()` —
   necessary because with `module_platform_driver()`, the probe function
   can be called after init (during deferred probe), so it can't be in
   `.init` section.

2. **Move `.probe` into the `platform_driver` struct** — from being
   passed as a second argument to `module_platform_driver_probe()` to
   being set as `.probe = aspeed_sgpio_probe` in the struct.

3. **Replace `module_platform_driver_probe()` with
   `module_platform_driver()`** — the actual behavioral change.

The probe function itself is completely unchanged in logic.

### Bug Classification

This fixes a **real probe failure bug**. When the Aspeed SGPIO driver is
compiled and the clock resource it depends on isn't yet available
(common on device-tree platforms where probe order isn't guaranteed),
the driver will fail to probe and **never retry**. This means the SGPIO
hardware is permanently non-functional until reboot, and even then only
if probe order happens to be favorable.

This is a real-world issue on Aspeed BMC platforms (AST2400, AST2500,
AST2600) which are widely used in server management. GPIO functionality
being unavailable due to probe ordering is a tangible user-facing bug.

### Scope and Risk Assessment

- **Lines changed**: Very small — removal of `__init`, moving the
  `.probe` assignment, macro swap
- **Files touched**: 1 file
- **Risk**: Very low. The probe function logic is completely unchanged.
  The only behavioral difference is that:
  1. The probe function is no longer in `.init` section (minor memory
     impact, but standard practice)
  2. Deferred probing is now supported (fixes the bug)
  3. The probe function pointer is stored in the driver struct rather
     than being patched in at registration time

This is a well-understood pattern — many drivers have made this exact
same transition over the years. The `module_platform_driver_probe()` to
`module_platform_driver()` conversion is one of the most common and
safest changes in the kernel.

### Stable Criteria Check

1. **Obviously correct and tested**: Yes — reviewed by Linus Walleij
   (GPIO subsystem co-maintainer), standard pattern
2. **Fixes a real bug**: Yes — probe failure when clock resource isn't
   available due to ordering
3. **Important issue**: Moderate — makes hardware permanently non-
   functional on affected platforms
4. **Small and contained**: Yes — minimal changes to one file
5. **No new features**: Correct — deferred probing is an existing kernel
   mechanism, this just enables the driver to participate in it
6. **Applies cleanly**: Should apply cleanly to any stable tree that has
   this driver

### User Impact

Aspeed BMC platforms are common in enterprise server management
(OpenBMC). If SGPIO fails to probe due to clock resource ordering, GPIO
pins managed by the SGPIO controller become unavailable, which can
affect system monitoring, power control, and other BMC functions. This
is a real-world issue that affects actual deployments.

### Concerns

- The commit doesn't have a `Fixes:` tag, which is expected for commits
  under review
- No explicit mention of user reports, but the commit author is from
  Aspeed Technology, indicating this is a known issue in their platform
- Minor: probe function no longer freed after init, but this is
  negligible memory impact

### Decision

This is a small, well-understood fix for a real probe failure bug on
Aspeed BMC platforms. The pattern change (`module_platform_driver_probe`
→ `module_platform_driver`) is one of the safest and most common
conversions in the kernel. It fixes a real-world issue where hardware
becomes non-functional due to probe ordering. The risk is minimal and
the benefit is clear.

**YES**

 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-sgpio.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[] = {
 
 MODULE_DEVICE_TABLE(of, aspeed_sgpio_of_table);
 
-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)
 }
 
 static struct platform_driver aspeed_sgpio_driver = {
+	.probe = aspeed_sgpio_probe,
 	.driver = {
 		.name = KBUILD_MODNAME,
 		.of_match_table = aspeed_sgpio_of_table,
 	},
 };
 
-module_platform_driver_probe(aspeed_sgpio_driver, aspeed_sgpio_probe);
+module_platform_driver(aspeed_sgpio_driver);
 MODULE_DESCRIPTION("Aspeed Serial GPIO Driver");
-- 
2.51.0

[PATCH AUTOSEL 6.19] drm/atmel-hlcdc: destroy properly the plane state in the reset callback

[Sasha Levin]

From: Ludovic Desroches <ludovic.desroches@microchip.com>

[ 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 <ludovic.desroches@microchip.com>
Reviewed-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Link: https://patch.msgid.link/20251218-lcd_cleanup_mainline-v2-8-df837aba878f@microchip.com
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of the Commit

### Commit Message Analysis

The commit message says: "destroy properly the plane state in the reset
callback" — the key word is **properly**. This suggests the previous
destruction was **improper**, meaning there was a bug in the old code.

### Code Change Analysis

Let me examine the old vs new `atmel_hlcdc_plane_reset()` function
carefully.

**Old code (being removed):**
```c
if (p->state) {
    state = drm_plane_state_to_atmel_hlcdc_plane_state(p->state);
    if (state->base.fb)
        drm_framebuffer_put(state->base.fb);
    kfree(state);
    p->state = NULL;
}
```

**New code (replacement):**
```c
if (p->state) {
    atmel_hlcdc_plane_atomic_destroy_state(p, p->state);
    p->state = NULL;
}
```

**What `atmel_hlcdc_plane_atomic_destroy_state()` does that the old
inline code did NOT:**
```c
static void atmel_hlcdc_plane_atomic_destroy_state(...)
{
    // 1. Frees DMA descriptors from the DMA pool
    for (i = 0; i < ARRAY_SIZE(state->dscrs); i++) {
        dma_pool_free(dc->dscrpool, state->dscrs[i],
                      state->dscrs[i]->self);
    }
    // 2. Puts the framebuffer reference
    if (s->fb)
        drm_framebuffer_put(s->fb);
    // 3. Frees the state
    kfree(state);
}
```

### Bug Identified: DMA Descriptor Resource Leak

The old reset code was **missing the DMA pool free** for the descriptors
(`state->dscrs[i]`). Every time `atmel_hlcdc_plane_reset()` was called
with an existing plane state, the DMA descriptors allocated from
`dc->dscrpool` were **leaked** — they were never returned to the DMA
pool.

This is a **real resource leak**. DMA pool memory is coherent DMA
memory, a finite and precious resource, especially on embedded ARM
systems where this Atmel HLCDC display controller runs. DMA pool
exhaustion can lead to allocation failures and display malfunction.

Additionally, the old code was also **missing the
`__drm_atomic_helper_plane_destroy_state()` call** that the proper
destroy function would provide (though in this driver the destroy
function doesn't call it either, it does its own fb put + kfree).
However, the DMA descriptor leak is the primary bug.

### Additional Change: CSC Initialization

The new reset function also adds:
```c
if (plane->layer.desc->layout.csc)
    dc->desc->ops->lcdc_csc_init(plane, plane->layer.desc);
```

This is a **new addition** — CSC (Color Space Conversion) initialization
during plane reset. This is arguably a feature addition or a separate
fix for missing initialization. This adds a bit of risk since it's not
purely fixing the leak but also changing initialization behavior.

### Scope and Risk Assessment

- **Files changed:** 1 file
- **Net change:** The function is reorganized, and the core fix (using
  proper destroy) is straightforward
- **Risk:** LOW for the resource leak fix. MEDIUM for the CSC init
  addition — but CSC init during reset is standard practice and the code
  only runs on Atmel HLCDC hardware
- **Subsystem:** DRM driver for a specific ARM SoC (Atmel/Microchip
  SAM9/SAMA5) — limited blast radius

### Stable Criteria Assessment

1. **Obviously correct:** Yes — the DMA descriptors were being leaked;
   they must be freed via the proper destroy path
2. **Fixes a real bug:** Yes — DMA pool memory leak on plane reset
3. **Important issue:** Moderate — resource leak in a display driver; on
   embedded systems with limited DMA pool memory, this could eventually
   cause display failures
4. **Small and contained:** Yes — one file, one function reorganized
5. **No new features:** The CSC init addition is borderline — it's
   initialization that was arguably missing, but it does add new
   behavior
6. **Applies cleanly:** Would need to verify, but it's self-contained

### Concerns

1. The CSC initialization addition goes beyond the pure leak fix and
   introduces new behavior. This makes it slightly riskier than a pure
   fix.
2. The commit message doesn't emphasize the DMA descriptor leak — it's
   described as avoiding "code duplication," which undersells the actual
   bug being fixed. This is a classic case of a bug fix disguised as
   cleanup.
3. No `Fixes:` tag or syzbot report, but the bug is clearly visible in
   the code.

### Verdict

The core of this commit fixes a **real DMA pool memory leak** — DMA
descriptors were not being freed when the plane state was destroyed
during reset. This is a legitimate resource leak bug fix. The change is
small, contained to a single driver file, and the fix approach (reusing
the existing proper destroy function) is obviously correct.

The CSC initialization addition adds some risk but is limited to
specific hardware and is part of proper plane reset behavior.

On balance, the resource leak fix makes this worth backporting despite
the small additional CSC change.

**YES**

 .../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;
 }
 
-static void atmel_hlcdc_plane_reset(struct drm_plane *p)
-{
-	struct atmel_hlcdc_plane_state *state;
-
-	if (p->state) {
-		state = drm_plane_state_to_atmel_hlcdc_plane_state(p->state);
-
-		if (state->base.fb)
-			drm_framebuffer_put(state->base.fb);
-
-		kfree(state);
-		p->state = NULL;
-	}
-
-	state = 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(struct drm_plane *p,
 	kfree(state);
 }
 
+static void atmel_hlcdc_plane_reset(struct drm_plane *p)
+{
+	struct atmel_hlcdc_plane_state *state;
+	struct atmel_hlcdc_dc *dc = p->dev->dev_private;
+	struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
+
+	if (p->state) {
+		atmel_hlcdc_plane_atomic_destroy_state(p, p->state);
+		p->state = NULL;
+	}
+
+	state = 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 = {
 	.update_plane = drm_atomic_helper_update_plane,
 	.disable_plane = drm_atomic_helper_disable_plane,
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.6] media: mediatek: vcodec: Don't try to decode 422/444 VP9

[Sasha Levin]

From: Nicolas Dufresne <nicolas.dufresne@collabora.com>

[ 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 <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### 1. Commit Message Analysis

The commit message is clear and direct: "Don't try to decode 422/444
VP9" with the explanation that "this is not supported by the hardware
and trying to decode these leads to LAT timeout errors." This describes
a real hardware limitation that causes a user-visible failure (decode
timeout).

### 2. Code Change Analysis

The change adds exactly 6 lines of code to the
`V4L2_CID_STATELESS_VP9_FRAME` case in `mtk_vdec_s_ctrl()`:

```496:505:drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec
_stateless.c
        case V4L2_CID_STATELESS_VP9_FRAME:
                frame = (struct v4l2_ctrl_vp9_frame *)hdr_ctrl->p_new.p;

                if (frame->bit_depth == 10) {
                        ctx->is_10bit_bitstream = true;
                } else if (frame->bit_depth != 8) {
                        mtk_v4l2_vdec_err(ctx, "VP9: bit_depth:%d",
frame->bit_depth);
                        return -EINVAL;
                }
                break;
```

The new code, inserted between the bit_depth check and the `break`,
checks the VP9 frame's subsampling flags. Both
`V4L2_VP9_FRAME_FLAG_X_SUBSAMPLING` and
`V4L2_VP9_FRAME_FLAG_Y_SUBSAMPLING` must be set (indicating 4:2:0). If
either is missing, it means the stream uses 4:2:2, 4:4:0, or 4:4:4 — all
unsupported.

### 3. The Bug Mechanism (Detailed)

The critical path that allows unsupported VP9 streams to reach the
hardware:

**Step 1**: The V4L2 core validates VP9 frame data in
`validate_vp9_frame()` (in `v4l2-ctrls-core.c`). This validates *VP9
spec compliance* — e.g., profile 0/2 must be 4:2:0, profile 1/3 must be
non-4:2:0. It does NOT enforce driver-specific hardware limitations.

```606:616:drivers/media/v4l2-core/v4l2-ctrls-core.c
        /* Profile 0 and 2 only accept YUV 4:2:0. */
        if ((frame->profile == 0 || frame->profile == 2) &&
            (!(frame->flags & V4L2_VP9_FRAME_FLAG_X_SUBSAMPLING) ||
             !(frame->flags & V4L2_VP9_FRAME_FLAG_Y_SUBSAMPLING)))
                return -EINVAL;

        /* Profile 1 and 3 only accept YUV 4:2:2, 4:4:0 and 4:4:4. */
        if ((frame->profile == 1 || frame->profile == 3) &&
            ((frame->flags & V4L2_VP9_FRAME_FLAG_X_SUBSAMPLING) &&
             (frame->flags & V4L2_VP9_FRAME_FLAG_Y_SUBSAMPLING)))
                return -EINVAL;
```

**Step 2**: The VP9 PROFILE menu control and the VP9 FRAME compound
control are **separate, independent V4L2 controls**. The profile field
inside the FRAME control is not cross-validated against the PROFILE menu
control. So userspace can submit a VP9 frame with profile=1 even if the
PROFILE control only advertises support for profiles 0 and 2.

**Step 3**: The driver's `s_ctrl` handler only checked `bit_depth`, not
subsampling. So a valid VP9 spec frame with profile 1 and 4:2:2
subsampling would pass all checks and reach the hardware.

**Step 4**: The MediaTek hardware decoder only supports 4:2:0. The VP9
LAT decoder has a `struct vdec_vp9_slice_reference` with `subsampling_x`
and `subsampling_y` fields that get passed to firmware/hardware.
Attempting to decode non-4:2:0 causes a LAT hardware timeout (1000ms via
`WAIT_INTR_TIMEOUT_MS`).

### 4. Impact on Stable Trees

**v6.6** is especially affected. I verified that:
- The file and the `mtk_vdec_s_ctrl` function exist in v6.6 (added via
  commit `9d86be9bda6cd`)
- In v6.6, the VP9 profile control allows ALL profiles 0-3 (`max =
  V4L2_MPEG_VIDEO_VP9_PROFILE_3`) with **no skip mask**. This means
  profiles 1 and 3 (which require non-4:2:0 subsampling) are explicitly
  advertised as supported, making the bug trivially reproducible with
  any VP9 4:2:2 content.
- The code context at the insertion point in v6.6 is identical to the
  diff context, so the patch applies cleanly.

**v6.12** already has the profile restriction (`menu_skip_mask =
BIT(V4L2_MPEG_VIDEO_VP9_PROFILE_1)`, `max = PROFILE_2`), which reduces
the attack surface, but the bug still exists because the FRAME control's
profile field is not validated against the PROFILE control.

**v6.1 and earlier**: The `s_ctrl` handler doesn't exist, so the patch
doesn't apply.

### 5. Patch Characteristics

- **Size**: 6 new lines
- **Self-contained**: No dependencies on any other commits
- **Pattern**: Follows the exact same validation pattern as the
  `bit_depth` check immediately above it
- **Error handling**: Standard `-EINVAL` return with diagnostic error
  message
- **Risk**: Extremely low — only rejects invalid configurations that the
  hardware cannot handle
- **Reviewed-by**: AngeloGioacchino Del Regno (Collabora, MediaTek
  subsystem maintainer)

### 6. Conclusion

This commit fixes a real, user-visible hardware bug. Without this fix,
attempting to decode VP9 4:2:2 or 4:4:4 content on MediaTek SoCs causes
a 1-second hardware timeout, resulting in decode errors. The fix is
small (6 lines), surgical, self-contained, follows existing code
patterns exactly, and has zero risk of regression (it only rejects
configurations that will always fail). It's especially important for
v6.6 where the profile control doesn't even restrict non-4:2:0 profiles.

**YES**

 .../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_stateless.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.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 = (struct v4l2_ctrl_av1_sequence *)hdr_ctrl->p_new.p;
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.1] ASoC: sunxi: sun50i-dmic: Add missing check for devm_regmap_init_mmio

[Sasha Levin]

From: Chen Ni <nichen@iscas.ac.cn>

[ 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 <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20260127033250.2044608-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit adds a missing error check for `devm_regmap_init_mmio()` in
the sun50i-dmic audio driver's probe function. The message is
straightforward - it's adding a return value check that was missing.

### Code Change Analysis

The change is a 3-line addition:
```c
if (IS_ERR(host->regmap))
    return dev_err_probe(&pdev->dev, PTR_ERR(host->regmap),
                         "failed to initialise regmap\n");
```

This is inserted right after `devm_regmap_init_mmio()` returns into
`host->regmap`. Without this check, if `devm_regmap_init_mmio()` fails,
`host->regmap` will contain an ERR_PTR value. The driver then continues
execution and eventually uses this regmap pointer in subsequent
operations (regmap reads/writes), which would cause a NULL pointer
dereference or other crash since the ERR_PTR would be interpreted as a
valid pointer.

### Bug Mechanism

If `devm_regmap_init_mmio()` fails (e.g., memory allocation failure
inside regmap), the error pointer gets stored in `host->regmap`. Later,
when the driver tries to use regmap APIs with this invalid pointer, it
will crash. This is a real bug - a missing error check that leads to use
of an error pointer as a valid pointer.

### Severity Assessment

- **Trigger**: `devm_regmap_init_mmio()` would need to fail, which is
  uncommon but possible (memory pressure, internal regmap errors)
- **Consequence**: Kernel crash/oops when the invalid regmap pointer is
  subsequently used
- **Likelihood**: Low probability but non-zero, especially under memory
  pressure

### Stable Kernel Criteria

1. **Obviously correct and tested**: Yes - this follows the exact same
   pattern as all surrounding error checks in the same function. It's a
   textbook missing error check fix.
2. **Fixes a real bug**: Yes - missing error check on a function that
   can fail, leading to use of an ERR_PTR as a valid pointer.
3. **Important issue**: Moderate - it's a potential NULL deref/crash,
   though the trigger condition is uncommon.
4. **Small and contained**: Yes - 3 lines added, single file, no
   behavioral change on success path.
5. **No new features**: Correct - purely defensive error checking.
6. **Applies cleanly**: The change is self-contained with no
   dependencies.

### Risk Assessment

- **Risk**: Extremely low. The change only affects the error path. On
  the success path, behavior is identical.
- **Benefit**: Prevents a kernel crash if regmap initialization fails.
- **Pattern**: This is a very common type of stable fix - adding missing
  error checks in driver probe functions.

### Concerns

This is a fairly minor fix for an uncommon failure path in a specific
ARM SoC audio driver. The user base is limited to Allwinner sun50i
platforms. However, the fix is trivially correct, has zero risk of
regression, and prevents a real (if unlikely) crash.

### Decision

The fix is small, obviously correct, follows existing patterns in the
same function, prevents a potential crash from using an ERR_PTR, and has
essentially zero regression risk. It meets all stable kernel criteria.

**YES**

 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 *pdev)
 
 	host->regmap = 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");
 
 	/* Clocks */
 	host->bus_clk = devm_clk_get(&pdev->dev, "bus");
-- 
2.51.0