[PATCH AUTOSEL 7.0-6.18] drm/prime: Limit scatter list size with dedicated DMA device

[Sasha Levin <sashal@kernel.org>]

From: Chen-Yu Tsai <wenst@chromium.org>

[ Upstream commit 864279920b2b2c1dd491eba0d0c64764c0c03d9f ]

If a dedicated DMA device is specified for the DRM device, then the
scatter list size limit should pertain to the DMA device.

Use the dedicated DMA device, if given, to limit the scatter list size.
This only applies to drivers that have called drm_dev_set_dma_dev() and
are using drm_prime_pages_to_sg() either directly or through the SHMEM
helpers. At the time of this writing, the former case only includes the
Rockchip DRM driver, while the latter case includes the gud, udl, and
the tiny appletbdrm and gm12u320 drivers.

Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260311094929.3393338-2-wenst@chromium.org
Signed-off-by: Chen-Yu Tsai <wenst@chromium.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 thorough analysis. Let me
compile everything.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/prime`
- Action verb: "Limit" (correctness-oriented; ensuring proper constraint
  application)
- Summary: Ensure scatter list size limit uses the dedicated DMA
  device's constraints, not the parent device's.
- Record: [drm/prime] [Limit] [Use correct DMA device for scatter list
  size constraint]

**Step 1.2: Tags**
- Reviewed-by: Thomas Zimmermann (DRM core developer at SUSE) - strong
  quality signal
- Reviewed-by: AngeloGioacchino Del Regno (Collabora, MediaTek
  maintainer) - additional review
- Link: patch.msgid.link/20260311094929.3393338-2-wenst@chromium.org
- Signed-off-by: Chen-Yu Tsai (Chromium, also kernel.org contributor
  under `wens@kernel.org`)
- No Fixes: tag, no Cc: stable, no Reported-by
- Record: Two Reviewed-by from recognized DRM developers. No explicit
  bug report or stable nomination.

**Step 1.3: Commit Body**
- Describes the issue: when a dedicated DMA device is set, scatter list
  size limit should use the DMA device, not the parent device
- Identifies affected drivers: Rockchip (direct caller), and USB-based
  drivers (gud, udl, appletbdrm, gm12u320) via SHMEM helpers
- No stack traces, no crash descriptions, no user reports
- Record: Bug is that wrong device is queried for DMA constraints. No
  specific symptom reported by users.

**Step 1.4: Hidden Bug Fix Detection**
- This IS a correctness fix: commit 143ec8d3f9396 introduced
  `drm_dev_dma_dev()` and updated `drm_gem_prime_import()` but missed
  `drm_prime_pages_to_sg()`. The cover letter explicitly says "I believe
  this was missing from the original change."
- Record: Yes, this is a missed fix from the original dedicated DMA
  device support.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Changes Inventory**
- Single file: `drivers/gpu/drm/drm_prime.c`
- 1 line changed: `-` / `+` (net 0 lines)
- Function modified: `drm_prime_pages_to_sg()`
- Record: [1 file, 1 line changed] [drm_prime_pages_to_sg()] [Single-
  line surgical fix]

**Step 2.2: Code Flow Change**
- Before: `dma_max_mapping_size(dev->dev)` - queries the parent device
  for max DMA mapping size
- After: `dma_max_mapping_size(drm_dev_dma_dev(dev))` - queries the
  dedicated DMA device (if set), otherwise falls back to parent device
- `drm_dev_dma_dev()` returns `dev->dma_dev` if set, otherwise
  `dev->dev`, so this is a no-op for drivers that don't use
  `drm_dev_set_dma_dev()`
- Record: [Changes which device is queried for DMA constraint; no
  behavior change for drivers not using dedicated DMA device]

**Step 2.3: Bug Mechanism**
- Category: Logic/correctness fix
- For drivers that set a dedicated DMA device (USB DRM drivers,
  Rockchip), querying the parent device returns wrong constraints:
  - For a device without DMA ops, `dma_go_direct()` returns true
    (because `ops` is NULL)
  - Then `dma_direct_max_mapping_size()` returns SIZE_MAX (unless
    SWIOTLB is involved)
  - The actual DMA controller may have stricter limits (e.g., SWIOTLB
    bounce buffer limit, IOMMU segment limits)
  - Consequence: scatter list segments could exceed the actual DMA
    controller's max mapping size
- Record: [Logic/correctness] [Wrong device queried for DMA max mapping
  size; scatter list segments may exceed actual DMA controller limits]

**Step 2.4: Fix Quality**
- Obviously correct: `drm_dev_dma_dev()` is the canonical way to get the
  DMA device, already used in `drm_gem_prime_import()`
- Minimal/surgical: one-line change
- Regression risk: essentially zero - for drivers without dedicated DMA
  device, `drm_dev_dma_dev()` returns `dev->dev` (identical behavior)
- Record: [Obviously correct, zero regression risk]

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- Line 862: `dma_max_mapping_size(dev->dev)` was introduced by commit
  707d561f77b5e (Gerd Hoffmann, 2020-09-07) "drm: allow limiting the
  scatter list size"
- This code has been in the tree since 2020, but the bug was introduced
  by commit 143ec8d3f9396 (2025-03-07) which added the dedicated DMA
  device concept without updating this call site
- Record: [Original line from 707d561f77b5e (v5.10 era), bug context
  created by 143ec8d3f9396 (v6.16)]

**Step 3.2: Fixes tag**
- No Fixes: tag. The implicit fix target is 143ec8d3f9396 ("drm/prime:
  Support dedicated DMA device for dma-buf imports"), which exists in
  v6.16+.

**Step 3.3: Related Changes**
- Part of a 4-patch series. Patches 2-4 add GEM DMA helper support and
  convert MediaTek/sun4i drivers.
- Patch 1 (this commit) is completely standalone; it has no dependency
  on patches 2-4.
- Record: [Patch 1/4, but fully standalone]

**Step 3.4: Author**
- Chen-Yu Tsai (wenst@chromium.org / wens@kernel.org) is a known kernel
  contributor for MediaTek/ARM platforms.
- Record: [Active ARM/DRM contributor]

**Step 3.5: Dependencies**
- Depends on `drm_dev_dma_dev()` from commit 143ec8d3f9396 (v6.16+)
- For the fix to matter, drivers must call `drm_dev_set_dma_dev()`:
  - USB drivers: since v6.16 (part of same series as 143ec8d3f9396)
  - Rockchip: since commit 7d7bb790aced3 in v6.19
- Record: [Requires 143ec8d3f9396 (v6.16+). Only useful in trees v6.16+
  where drm_dev_dma_dev exists.]

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original Discussion**
- Found on lore.gitlab.freedesktop.org. Series is "drm/gem-dma: Support
  dedicated DMA device for allocation".
- v1: 2026-03-10, v2: 2026-03-11. Minor revision; patch 1 was unchanged
  between versions.
- Thomas Zimmermann gave Reviewed-by on both v1 and v2.
- AngeloGioacchino Del Regno also reviewed v2.
- No NAKs or concerns raised.
- Record: [Two favorable reviews, no objections]

**Step 4.2: Reviewers**
- Thomas Zimmermann: DRM core developer who authored the original
  `drm_dev_dma_dev()` infrastructure
- AngeloGioacchino Del Regno: MediaTek platform maintainer
- Record: [Reviewed by the author of the original DMA device
  infrastructure]

**Step 4.3-4.5: Bug reports and stable history**
- No specific bug reports linked
- The cover letter mentions this was "missing from the original change"
- No explicit stable discussions found
- Record: [No bug reports, no stable discussion]

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Function analysis**
- `drm_prime_pages_to_sg()` is called from 15+ locations across many DRM
  drivers
- For drivers using dedicated DMA device and calling this function:
  - Rockchip: `rockchip_gem_get_pages()` and
    `rockchip_gem_prime_get_sg_table()`
  - USB drivers via SHMEM: `drm_gem_shmem_get_sg_table()` ->
    `drm_gem_shmem_get_pages_sgt_locked()`
- These are common code paths (buffer allocation, dma-buf export)
- Record: [Widely-used function, affected through normal buffer
  allocation paths]

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy code existence**
- `drm_dev_dma_dev()` only exists in v6.16+
- USB drivers only call `drm_dev_set_dma_dev()` in v6.16+
- Rockchip only calls it in v6.19+
- For stable trees < v6.16, the bug doesn't exist (no dedicated DMA
  device concept)
- Record: [Bug exists in v6.16+ only. For 7.0.y stable, the fix is
  relevant.]

**Step 6.2: Backport complications**
- The fix would apply cleanly to any tree containing 143ec8d3f9396
  (v6.16+)
- Record: [Clean apply expected for 7.0.y]

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1**: Subsystem: DRM/GPU drivers (IMPORTANT criticality for
affected devices)
**Step 7.2**: Active subsystem with recent changes

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is affected**
- Users of USB DRM devices (gud, udl, appletbdrm, gm12u320) and Rockchip
  DRM
- Record: [Driver-specific: USB display devices and Rockchip SoCs]

**Step 8.2: Trigger conditions**
- Triggered during buffer allocation and dma-buf operations on affected
  hardware
- Common operations: creating display buffers, PRIME buffer sharing
- Record: [Common display operations on affected hardware]

**Step 8.3: Failure mode**
- Without the fix, `dma_max_mapping_size()` may return an incorrect
  (typically too large) value
- This could cause DMA mapping failures when segments exceed the actual
  controller's limit
- The Rockchip "swiotlb buffer is full" warning (from commit
  7d7bb790aced3) is related to this class of issue
- Severity: MEDIUM - potential DMA failures on affected hardware
- Record: [DMA mapping failures possible; MEDIUM severity]

**Step 8.4: Risk-Benefit**
- Benefit: Ensures correct DMA constraints for scatter list creation on
  USB/Rockchip DRM devices
- Risk: Essentially zero - `drm_dev_dma_dev()` returns `dev->dev` when
  no dedicated device is set, so behavior is unchanged for unaffected
  drivers
- Record: [Low-medium benefit, near-zero risk]

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a missed call site from the original dedicated DMA device
  support (143ec8d3f9396)
- One-line change, obviously correct
- Zero regression risk (no-op for drivers not using dedicated DMA
  device)
- Reviewed by Thomas Zimmermann (author of the original DMA device
  infrastructure)
- Affects real hardware (USB DRM devices, Rockchip SoCs)
- Could cause DMA mapping failures with incorrect max segment sizes

**Evidence AGAINST backporting:**
- No specific user-reported failures
- Part of a 4-patch series (though this patch is standalone)
- Only applicable to stable trees v6.16+ (limited scope)
- The actual failure depends on platform-specific DMA controller
  constraints

**Stable rules checklist:**
1. Obviously correct and tested? YES (reviewed by infrastructure author)
2. Fixes a real bug? YES (wrong DMA device queried, potentially wrong
   constraints)
3. Important issue? MEDIUM (potential DMA failures on specific hardware)
4. Small and contained? YES (1 line, 1 file)
5. No new features? YES (pure correctness fix)
6. Can apply to stable? YES for v6.16+ trees

## Verification

- [Phase 1] Parsed tags: Reviewed-by from Thomas Zimmermann and
  AngeloGioacchino Del Regno. No Fixes: tag, no Reported-by.
- [Phase 2] Diff: single line changed in `drm_prime_pages_to_sg()`,
  `dev->dev` -> `drm_dev_dma_dev(dev)`
- [Phase 3] git blame: line 862 from commit 707d561f77b5e (2020). Bug
  context from 143ec8d3f9396 (v6.16).
- [Phase 3] git show 143ec8d3f9396: confirmed it updated
  `drm_gem_prime_import()` but missed `drm_prime_pages_to_sg()`
- [Phase 3] git tag --contains: 143ec8d3f9396 in v6.16+, 7d7bb790aced3
  (Rockchip DMA dev) in v6.19+
- [Phase 4] Found original patch on lore.gitlab.freedesktop.org - v1 and
  v2, Reviewed-by from Zimmermann
- [Phase 4] Cover letter confirms: "this was missing from the original
  change"
- [Phase 5] grep for callers: 15+ call sites across DRM drivers,
  includes Rockchip direct + USB via SHMEM helper
- [Phase 5] `drm_dev_dma_dev()` verified: returns `dev->dma_dev` if set,
  else `dev->dev` (safe fallback)
- [Phase 6] Code exists in v6.16+ trees; 7.0 tree has all prerequisites
- [Phase 6] `dma_max_mapping_size()` code path verified: for device
  without DMA ops, returns SIZE_MAX via `dma_direct_max_mapping_size()`,
  which may not reflect actual DMA controller limits
- [Phase 8] Rockchip commit 7d7bb790aced3 explicitly mentions "swiotlb
  buffer is full" warnings from GEM prime paths - same class of issue
- UNVERIFIED: Whether USB DRM devices have actually hit DMA failures
  from this specific path (no user reports found)

This is a minimal, obviously correct one-line fix that addresses a
missed update in the dedicated DMA device infrastructure. While no
specific user failure has been reported for this exact path, the fix is
low-risk and addresses a real correctness issue that could manifest as
DMA mapping failures on Rockchip and USB display hardware. The fix is
standalone, reviewed by the infrastructure author, and has zero
regression risk.

**YES**

 drivers/gpu/drm/drm_prime.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 51fdb06d3e9f2..9b44c78cd77fc 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -859,7 +859,7 @@ struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev,
 		return ERR_PTR(-ENOMEM);
 
 	if (dev)
-		max_segment = dma_max_mapping_size(dev->dev);
+		max_segment = dma_max_mapping_size(drm_dev_dma_dev(dev));
 	if (max_segment == 0)
 		max_segment = UINT_MAX;
 	err = sg_alloc_table_from_pages_segment(sg, pages, nr_pages, 0,
-- 
2.53.0