[PATCH AUTOSEL 6.18-5.10] drm/amdgpu: Support some Barco AMD based graphics adapters
From: Sasha Levin
Date: Mon Oct 19 2026 - 10:47:10 EST
From: Matthew Jacob <mjacob@xxxxxxxxxxx>
[ Upstream commit 3dc4d68ee26a7ac12069ff0562ad8935106c79b6 ]
These adapters typically are only supported by Barco on the
Windows platform. However, with these changes in the linux
driver, multiple monitor support should work correctly.
Signed-off-by: Matthew Jacob <mjacob@xxxxxxxxxxx>
Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit message forensics
**Step 1.1:** Record: `[drm/amdgpu] [Support] [add PCI IDs so Barco AMD
adapters bind to amdgpu]`
**Step 1.2:** Tags in the commit as given:
- `Signed-off-by: Matthew Jacob <mjacob@xxxxxxxxxxx>` (author)
- `Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>` (amdgpu
maintainer)
- No `Fixes:`, `Reported-by:`, `Cc: stable`, `Link:`, `Tested-by`, or
`Reviewed-by` on the committed message (absence of `Fixes`/`Cc:
stable` is expected for this review)
**Step 1.3:** Record:
- Bug/problem: Barco MXRT cards (AMD GPUs with Barco PCI IDs) are not in
`pciidlist`, so amdgpu never binds; Windows-only vendor support.
- Symptom: cards do not work as DRM devices; multi-monitor setups fail.
- Version info: none in the message.
- Root cause: missing device IDs, not a logic bug in existing chip code.
**Step 1.4:** Record: Not a hidden crash/UAF fix. It is hardware
enablement via PCI IDs. That is an explicit stable exception, not
disguised cleanup.
## Phase 2: Diff analysis
**Step 2.1:** Record:
- File: `drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c` only
- +4 / -0 (four PCI ID rows)
- Function/object: `pciidlist[]`
- Scope: single-file surgical device-ID addition
**Step 2.2:** Record (each hunk is the same pattern):
- Before: ID missing → PCI core does not match amdgpu
- After: ID present with existing `CHIP_*` flags → probe uses already-
supported ASIC paths
- `0x664D` → `CHIP_BONAIRE`
- `0x693B` → `CHIP_TONGA`
- `0x67D4` → `CHIP_POLARIS10`
- `0x698F` → `CHIP_POLARIS12`
- Path: device enumeration / probe, not an error path
**Step 2.3:** Record: `[Hardware workarounds / device ID addition]`
Mechanism: missing IDs so existing Bonaire/Tonga/Polaris code never runs
for those DIDs.
**Step 2.4:** Record: Obviously correct if the IDs belong to those
families. Regression risk is low: only those four DIDs start probing;
neighboring IDs are unchanged. Wrong-family assignment could mis-init a
GPU; public PCI databases and nearby IDs in the same table match the
chosen `CHIP_*` values. Original submission used `//` comments; the
committed form dropped them (kernel style). No API or data-structure
change.
## Phase 3: Git history
**Step 3.1:** Record: `pciidlist` has existed for the life of amdgpu.
Nearby IDs (`0x6649`, `0x6939`, `0x67D0`, `0x6987`) are long-standing.
The gap is missing Barco DIDs, not a newly introduced logic bug.
`CHIP_BONAIRE` / `CHIP_TONGA` / `CHIP_POLARIS10` / `CHIP_POLARIS12` are
in `include/drm/amd_asic_type.h` (enum values 5, 11, 15, 17).
**Step 3.2:** No `Fixes:` tag. Buggy “code” is the absence of IDs. Not
applicable as a Fixes follow-up.
**Step 3.3:** Recent related history on this file includes other PCI ID
work (e.g. cyan skillfish IDs already in v6.18). Standalone; not patch
X/Y. A later named-initializer rewrite of the table exists only as a
later candidate on this branch, not in `v6.18.53`.
**Step 3.4:** Author Matthew Jacob (Feral Software) has this one amdgpu
commit here. Alex Deucher, amdgpu maintainer, applied it (`CommitDate:
Wed Jul 1 2026`, SOB).
**Step 3.5:** No functional prerequisites. Applies against the existing
`pciidlist` format in `v6.18.53`. Does not need new CHIP types, new
helpers, or other series patches.
Upstream object `3dc4d68ee26a7ac12069ff0562ad8935106c79b6` is **not** an
ancestor of `v6.18` or `v6.18.53`.
## Phase 4: Mailing list / external research
**Step 4.1:** `b4 dig -c 3dc4d68ee26a7ac12069ff0562ad8935106c79b6`
failed (lore.kernel.org server error). Fallback: freedesktop amd-gfx.
- Submission: https://lists.freedesktop.org/archives/amd-
gfx/2026-June/147081.html
- First attempt (attachment, not git-format):
https://lists.freedesktop.org/archives/amd-gfx/2026-June/147075.html
- Alex asked for a proper git patch + SOB:
https://lists.freedesktop.org/archives/amd-gfx/2026-June/147077.html
- Alex applied the git-format patch the same day:
https://lists.freedesktop.org/archives/amd-gfx/2026-June/147083.html
(“Applied. Thanks!”)
- Archive index also lists later Christian König and Matthew Jacob
follow-ups; **exact text of those later mails is UNVERIFIED** (message
numbers not resolved). No NAK found on the applied version.
**Step 4.2:** Recipients: amd-gfx. Maintainer Alex Deucher reviewed and
applied. Not a drive-by unreviewed ID dump.
**Step 4.3:** Real-world reports:
- 2023: Matthias Reichl, Barco MXRT-5600 `1002:664d` on HP Z240; neither
radeon nor amdgpu bound; adding the ID made it work (Debian, kernel
6.2-rc3, CIK enabled). Alex noted the DID was missing from AMD’s
Windows list too. https://lists.freedesktop.org/archives/amd-
gfx/2023-January/088522.html
- 2026 cover letter: Kaiser radiology PACS fleets; Barco/Kaiser had no
objection.
- PCI ID databases: `664D` Bonaire/W5100/MXRT-5600; `693B`
Tonga/W7100/MXRT-7600; `67D4` Polaris10/WX 7100/MXRT-8700; `698F`
Polaris12/WX 3100/MXRT 4700.
**Step 4.4:** Standalone 4-line ID add. A later separate patch proposed
`0x67D7` (MXRT-6700); not required for this commit.
**Step 4.5:** lore.kernel.org/stable search returned 403; **UNVERIFIED**
whether stable@ already discussed this ID set. No evidence of a NAK for
stable.
## Phase 5: Code semantic analysis
**Step 5.1:** Record: `pciidlist[]` (static `pci_device_id` table). No
function body edits.
**Step 5.2:** Record: PCI core match → `amdgpu` `.id_table` /
`MODULE_DEVICE_TABLE(pci, pciidlist)` around the probe path in
`amdgpu_drv.c`. Trigger is plugging in / booting with that GPU. Not a
syscall hot path.
**Step 5.3:** Record: probe then uses existing ASIC init for
`CHIP_BONAIRE` / `CHIP_TONGA` / `CHIP_POLARIS10` / `CHIP_POLARIS12`.
Those ASICs already have full driver support in this tree.
**Step 5.4:** Record: Userspace-reachable only in the sense of having
the card. Unprivileged users cannot invent a PCI ID. Impact is “card
works vs. no DRM driver”.
**Step 5.5:** Same table already lists sibling IDs in each family.
`amdgpu_unsupported_pciidlist[]` does not contain these four IDs. radeon
`include/drm/drm_pciids.h` still lacks `0x664D` (Bonaire default driver
is radeon unless CIK is switched to amdgpu). That does not block amdgpu
IDs for Tonga/Polaris.
## Phase 6: Local tree (this checkout)
**Step 6.1:** Record:
- `git describe HEAD` → `v6.18.53-5049-g0f0bdc2b0dffb`; `Makefile` →
**6.18.53**
- `v6.18.53:drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c` does **not**
contain `0x664D`, `0x693B`, `0x67D4`, `0x698F`
- Surrounding rows in `v6.18.53` match the candidate hunks (positional
`{0x1002, 0x...., PCI_ANY_ID, ...}` form)
- `CHIP_*` enums exist in this series
- Bug/gap: missing IDs, present for as long as those families have been
in amdgpu
**Step 6.2:** Record: **clean apply** onto `v6.18.53`. No format
mismatch. (HEAD currently uses `PCI_DEVICE()` named initializers because
a later candidate rewrote the table; that rewrite is not in `v6.18.53`.)
**Step 6.3:** Record: No alternate fix for these four IDs in
`v6.18..v6.18.53`. Cyan skillfish ID adds are a different family and
already in v6.18.
## Phase 7: Subsystem context
**Step 7.1:** Record: `[drm/amdgpu] [IMPORTANT]` — common GPU driver,
not staging. Device-ID-only, not a new driver.
**Step 7.2:** Record: amdgpu is actively developed; these GCN families
(CIK/VI/Polaris) are mature. Adding IDs to old ASICs is the usual
pattern.
## Phase 8: Impact and risk
**Step 8.1:** Record: driver-specific / hardware-specific. Users of
Barco MXRT (medical/pro multi-display) AMD cards. Not universal.
**Step 8.2:** Record: Trigger = boot with that PCI device. Common for
those machines, zero for everyone else. Not a userspace exploit path.
**Step 8.3:** Record: Failure mode today = adapter unbound / no KMS, not
an oops. Severity for affected users: **HIGH** (hardware dead on Linux).
Severity for others: none. Not panic/UAF.
**Step 8.4:** Record:
- Benefit: high for those GPUs (kernel finally binds; Tonga/Polaris work
with default amdgpu; Bonaire needs existing `DRM_AMDGPU_CIK` /
`amdgpu.cik_support=1` like other Bonaire parts)
- Risk: very low (4 rows, existing CHIP flags, maintainer-applied)
- Ratio: favorable; this is the documented device-ID exception
Caveats (not blockers):
- Two IDs were labeled “Tentative” in the mail (`0x67D4` MXRT-8750 vs
databases saying MXRT-8700; `0x698F` MXRT-4700, which does exist).
Family assignment still matches public PCI IDs.
- Bonaire `0x664D` is not added to radeon; default CIK remains radeon.
Same as needing CIK-in-amdgpu for other Bonaire cards.
## Phase 9: Synthesis
**Evidence FOR:**
- Canonical PCI ID addition to an existing driver
- 4 lines, existing `CHIP_*` only
- Families already in 6.18.y; IDs missing from `v6.18.53`
- Applies cleanly
- Maintainer (Alex Deucher) applied it
- Documented users (Kaiser PACS, 2023 MXRT-5600 report)
- PCI ID databases agree with the chip mapping
**Evidence AGAINST:**
- Not a crash/security/corruption fix
- Two IDs originally marked tentative
- Bonaire ID incomplete vs radeon default
- Exact later König comments UNVERIFIED
**Unresolved:** exact text of later amd-gfx follow-ups; whether stable@
already discussed it (lore 403 / b4 lore error).
**Stable rules checklist:**
1. Obviously correct and tested? **PASS** — table rows + maintainer
apply; 2023 user tested `664d`
2. Real bug affecting users? **PASS** — devices never bind
3. Important? **PASS** under the device-ID exception (hardware
enablement, not a new driver)
4. Small and contained? **PASS** — 4 lines, one file
5. No new features/APIs? **PASS** — IDs only; no new ioctls/params
6. Can apply to this tree? **PASS** — `v6.18.53` table format matches
**Exception category:** New PCI IDs on an existing driver.
This should be backported to this 6.18.y tree: the driver and ASIC
support are already here; only the four IDs are missing.
Verification:
- [Phase 1] Parsed subject/tags/body: Support + two SOBs; no
Fixes/Reported-by
- [Phase 2] Diff: +4 PCI IDs in `pciidlist` (`664D` Bonaire, `693B`
Tonga, `67D4` Polaris10, `698F` Polaris12)
- [Phase 3] `git describe HEAD` / Makefile: 6.18.53; upstream
`3dc4d68ee26a` not ancestor of v6.18/v6.18.53
- [Phase 3] `git show v6.18.53:drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c`:
those four IDs absent; neighbor rows match the patch
- [Phase 3] `CHIP_BONAIRE` etc. in `include/drm/amd_asic_type.h`
- [Phase 4] b4 dig: lore server error; used lists.freedesktop.org
instead
- [Phase 4] 147075/147077/147081/147083: resend as git patch, Alex
applied
- [Phase 4] 2023 664d thread: card worked after adding the ID
- [Phase 5] `MODULE_DEVICE_TABLE` / `.id_table = pciidlist`; IDs not on
`amdgpu_unsupported_pciidlist`
- [Phase 6] Clean apply to v6.18.53 old-style table; radeon
`drm_pciids.h` still has `0x6649` but not `0x664D`
- [Phase 7] amdgpu important, families mature
- [Phase 8] Probe-only; risk limited to those DIDs
- UNVERIFIED: full text of later Christian König replies; stable@
archive (403)
**YES**
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 376a7cd2667f6..845ebe041563f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1953,6 +1953,7 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x6646, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BONAIRE|AMD_IS_MOBILITY},
{0x1002, 0x6647, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BONAIRE|AMD_IS_MOBILITY},
{0x1002, 0x6649, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BONAIRE},
+ {0x1002, 0x664D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BONAIRE},
{0x1002, 0x6650, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BONAIRE},
{0x1002, 0x6651, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BONAIRE},
{0x1002, 0x6658, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BONAIRE},
@@ -2022,6 +2023,7 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x6930, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TONGA},
{0x1002, 0x6938, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TONGA},
{0x1002, 0x6939, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TONGA},
+ {0x1002, 0x693B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TONGA},
/* fiji */
{0x1002, 0x7300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_FIJI},
{0x1002, 0x730F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_FIJI},
@@ -2050,6 +2052,7 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x67C4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
{0x1002, 0x67C7, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
{0x1002, 0x67D0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+ {0x1002, 0x67D4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
{0x1002, 0x67DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
{0x1002, 0x67C8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
{0x1002, 0x67C9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
@@ -2063,6 +2066,7 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x6985, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
{0x1002, 0x6986, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
{0x1002, 0x6987, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
+ {0x1002, 0x698F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
{0x1002, 0x6995, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
{0x1002, 0x6997, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
{0x1002, 0x699F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
--
2.53.0