[PATCH AUTOSEL 6.18-6.12] RDMA/efa: Add EFA 0xefa4 PCI ID
From: Sasha Levin
Date: Mon Oct 19 2026 - 12:34:11 EST
From: Anas Mousa <anasmous@xxxxxxxxxx>
[ Upstream commit 6a57af838b1a56405a9bde9030de16df901ae2ca ]
Add support for 0xefa4 devices.
Reviewed-by: Michael Margolin <mrgolin@xxxxxxxxxx>
Signed-off-by: Anas Mousa <anasmous@xxxxxxxxxx>
Link: https://patch.msgid.link/20260712134413.19226-3-mrgolin@xxxxxxxxxx
Signed-off-by: Leon Romanovsky <leon@xxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
LLM Generated explanations, may be completely bogus:
This is a two-line PCI ID addition to the existing Amazon EFA RDMA
driver. That matches the stable-tree device-ID exception, and the local
7.3-rc4 tree already has the driver and ID table.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: PARSE THE SUBJECT LINE**
- Subsystem: `RDMA/efa`
- Action verb: **Add**
- Claimed intent: register PCI device ID `0xefa4` so the in-tree EFA
driver binds new Amazon Elastic Fabric Adapter hardware.
Record: `[RDMA/efa] [add] [PCI ID 0xefa4 for next-gen EFA VF]`
**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
- `Reviewed-by: Michael Margolin <mrgolin@xxxxxxxxxx>` (Amazon EFA
contributor; 20 commits in this driver)
- `Signed-off-by: Anas Mousa <anasmous@xxxxxxxxxx>` (author)
- `Link:
https://patch.msgid.link/20260712134413.19226-3-mrgolin@xxxxxxxxxx`
- `Signed-off-by: Leon Romanovsky <leon@xxxxxxxxxx>` (RDMA maintainer,
committer)
- No `Fixes:` tag (expected)
- No `Cc: stable@xxxxxxxxxxxxxxx` (expected)
- No `Reported-by:`, `Tested-by:`, `Acked-by:`
- Ignore any pipeline `Signed-off-by: Sasha Levin` / `[Upstream commit
...]` markers (none in the real commit)
Record: Maintainer-applied PCI ID patch; Amazon internal review; lore
link present; no syzbot/bug report (not applicable).
**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Body is one sentence: “Add support for 0xefa4 devices.” Cover letter
(mbox): “Make a minor device interface change needed for new EFA devices
and enable support for 0xefa4 PCI ID.” No crash, no reproducer — this is
hardware enablement.
Record: `[Bug description: none — new PCI ID] [Symptom: 0xefa4 adapters
unbound / unused by in-tree efa] [Version info: none] [Root cause: ID
missing from pci_device_id table]`
**Step 1.4: DETECT HIDDEN BUG FIXES**
Not a disguised leak/race/UAF fix. It is exactly a device-ID addition.
Record: `[Not a hidden bug fix. Explicit PCI ID enablement.]`
---
## PHASE 2: DIFF ANALYSIS
**Step 2.1: INVENTORY THE CHANGES**
- File: `drivers/infiniband/hw/efa/efa_main.c` — **+2 / -0**
- `#define PCI_DEV_ID_EFA4_VF 0xefa4`
- `{ PCI_VDEVICE(AMAZON, PCI_DEV_ID_EFA4_VF) }` in `efa_pci_tbl[]`
- Scope: single-file surgical ID addition
Record: `[efa_main.c +2] [pci_device_id table] [surgical single-file]`
**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Before: PCI core matches Amazon vendor `0x1d0f` with IDs
`0xefa0`–`0xefa3` only. `0xefa4` is ignored (no probe).
After: `0xefa4` matches `efa_pci_driver`, `efa_probe()` runs the same
path as older generations.
`efa_probe(struct pci_dev *pdev, const struct pci_device_id *ent)` does
not use `ent` for generation-specific branching. `vendor_part_id` is
taken from `pdev->device`. Capabilities come from admin query
(`page_size_cap`, etc.).
Record: `[PCI match table: 4 IDs -> 5 IDs; probe path unchanged]`
**Step 2.3: IDENTIFY THE BUG MECHANISM**
Category **(h) Hardware workarounds / device ID additions**. Without the
ID, new EFA VFs never bind.
Record: `[Device ID addition] [Missing 0xefa4 in efa_pci_tbl prevented
driver bind]`
**Step 2.4: ASSESS THE FIX QUALITY**
Obviously correct. Same pattern as `0xefa2` (`b75927cff13e0`) and
`0xefa3` (`346d2fc606a85`). Does not change locking, APIs, or existing-
ID behavior. Regression risk is confined to `1d0f:efa4` hardware.
Record: `[Minimal, obviously correct] [Regression risk: only 0xefa4
devices]`
---
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: BLAME THE CHANGED LINES**
```
efa0/efa1: d4f9cb5c5b224 (Gal Pressman, 2020)
efa2: b75927cff13e0 (Michael Margolin, 2022) → v6.1-rc4
efa3: 346d2fc606a85 (Michael Margolin, 2024) → present in v6.11 /
v7.2.7
efa4: 6a57af838b1a5 (Anas Mousa, 2026-07-12)
Driver: b7f5e880f3774 (2019) → v5.2-rc1
```
The table has been the enablement mechanism since the driver was added.
Record: `[ID table since v5.2; this ID added 2026-07-12 / 7.3 merge
window]`
**Step 3.2: FOLLOW THE FIXES: TAG**
No `Fixes:` tag. Not a regression fix.
Record: `[N/A — device ID, not a regression]`
**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Same msgid series `20260712134413`:
1. `4266547bdce74` RDMA/efa: Extend page-shift field in MR registration
(`19226-2`)
2. `6a57af838b1a5` RDMA/efa: Add EFA 0xefa4 PCI ID (`19226-3`) — this
commit
Cover letter: 2-patch `for-next` series. Patch 1 widens
`EFA_ADMIN_REG_MR_CMD_PHYS_PAGE_SIZE_SHIFT_MASK` from `GENMASK(4,0)` to
`GENMASK(5,0)` for **>4GB page sizes** on 0xefa4. That is extra
capability, not required for PCI bind/probe. `efa_probe` does not depend
on that mask.
Record: `[Series of 2; this patch is standalone for bind] [page-shift is
feature, not probe prerequisite]`
**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Anas Mousa: this is the only in-tree EFA commit. Reviewed by Michael
Margolin (regular EFA author). Applied by Leon Romanovsky.
Record: `[First-time author; reviewed by EFA regular; applied by RDMA
maintainer]`
**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Local tree already has `PCI_DEV_ID_EFA3_VF`, `PCI_VDEVICE(AMAZON, ...)`,
and `efa_pci_tbl`. No new helpers. Companion page-shift commit is
already in this tree (`git merge-base --is-ancestor 4266547bdce74
HEAD`).
Record: `[Applies standalone] [No missing structs/APIs in this tree]`
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
`b4 dig -c 6a57af838b1a5` →
https://patch.msgid.link/20260712134413.19226-3-mrgolin@xxxxxxxxxx
`b4 dig -a`: **v1 only** (no v2/v3).
Thread saved to mbox (6 messages).
Key review (on patch 1/2, not this ID patch): Leon asked how non-0xefa4
devices handle the extra page-shift bit. Michael: kernel uses device-
reported `page_size_cap` with `ib_umem_find_best_pgsz()`, so the extra
bit is not set on older devices; device also validates. Leon then
**Applied, thanks!** both patches. No NAK on the PCI ID patch. No `Cc:
stable` request.
Record: `[lore via patch.msgid.link/20260712134413.19226-3] [v1 only]
[no NAK on ID patch] [no stable nomination]`
**Step 4.2: CHECK WHO REVIEWED THE PATCH**
`b4 dig -w` recipients: `jgg@xxxxxxxxxx`, `leon@xxxxxxxxxx`, `linux-
rdma@xxxxxxxxxxxxxxx`, Amazon EFA engineers (`sleybo`, `matua`,
`gal.pressman`). Right lists and maintainers.
Record: `[RDMA maintainers + linux-rdma CC'd; Leon applied]`
**Step 4.3: SEARCH FOR THE BUG REPORT**
No bugzilla/syzbot. External confirmation that 0xefa4 is real hardware:
- DeviceHunt: PCI `1D0F:EFA4` Amazon Elastic Fabric Adapter
- Amazon out-of-tree `efa_linux_3.3.0`: “Add 0xefa4 device support”
- rdma-core: `efa: Add EFA 0xefa4 PCI ID`
Record: `[Real shipping device; userspace + out-of-tree driver already
list the ID]`
**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
2/2 of “Add support for 0xefa4 devices”. Evaluating only the ID patch:
self-contained for enumeration. Full >4GB MR pages needs patch 1/2
(already in this tree).
Record: `[Standalone for bind; series mate is optional extra
capability]`
**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
lore.kernel.org WebFetch returned 403. `b4 dig` mbox has no stable-list
traffic. No evidence this ID was rejected for stable.
Record: `[No stable-list discussion found (lore HTTP 403; mbox has
none)]`
---
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: KEY FUNCTIONS**
No function body changed. Data: `PCI_DEV_ID_EFA4_VF`, `efa_pci_tbl[]`.
Consumers: `MODULE_DEVICE_TABLE(pci, efa_pci_tbl)` and
`efa_pci_driver.id_table`.
Record: `[efa_pci_tbl / efa_pci_driver only]`
**Step 5.2: TRACE CALLERS**
PCI core `pci_device_probe` → `efa_probe` → `efa_probe_device` /
`efa_ib_device_add`. Userspace-visible once the VF is assigned (typical
AWS EFA instance).
Record: `[PCI enumeration; bind on matching VF]`
**Step 5.3: TRACE CALLEES**
Unchanged. Probe still does BAR map, MSI-X, admin queues, IB register.
Record: `[Probe callees unchanged]`
**Step 5.4: FOLLOW THE CALL CHAIN**
Reachable when `CONFIG_INFINIBAND_EFA` is set (`PCI_MSI && 64BIT &&
!CPU_BIG_ENDIAN && INFINIBAND_USER_ACCESS`) and `1d0f:efa4` is present.
Common on AWS HPC/ML instances, not a syscall fuzzer path.
Record: `[Reachable from device hotplug/boot on EFA instances]`
**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Identical ID adds for efa2/efa3. No `switch (pdev->device)` /
`driver_data` generation quirks in `drivers/infiniband/hw/efa/`.
Record: `[Same pattern as prior EFA IDs; no per-ID code]`
---
## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Local tree: **v7.3-rc4-27-gf0100363d8c37**, `make kernelversion` =
**7.3.0-rc4**.
`INFINIBAND_EFA` and `efa_pci_tbl` exist. `0xefa0`–`0xefa3` exist.
Without this change, `0xefa4` would not match.
`git merge-base --is-ancestor 6a57af838b1a5 HEAD` → yes (landed by
**v7.3-rc1**). Not in **v7.2.7**. Introduced in the 7.3 window, not
after this branch point.
Record: `[Driver and ID table present in this 7.3-rc4 tree] [ID added in
7.3-rc1]`
**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Hunk is two lines next to `PCI_DEV_ID_EFA3_VF`. Would apply cleanly to
this file’s table. No refactor of the ID table.
Record: `[Expected apply: clean]`
**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
No alternate 0xefa4 enablement. This is the only `0xefa4` PCI table
change.
Record: `[No other 0xefa4 bind fix]`
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: SUBSYSTEM AND CRITICALITY**
`drivers/infiniband/hw/efa/` — Amazon EFA RDMA NIC.
Criticality: **IMPORTANT** for AWS EFA users; **PERIPHERAL** globally.
Not core mm/net.
Record: `[RDMA/efa] [IMPORTANT for EFA hardware, otherwise peripheral]`
**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Actively maintained (completion counters, 128B admin SQ, IRQ lifetime
fixes in 2026). ID adds are a long-standing pattern, not a new
subsystem.
Record: `[Active but mature ID-table pattern]`
MAINTAINERS: “AMAZON RDMA EFA DRIVER”.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: WHO IS AFFECTED**
Users of Amazon EFA VF `1d0f:efa4` with `CONFIG_INFINIBAND_EFA`. Older
EFA IDs unchanged.
Record: `[driver-specific / config-specific (INFINIBAND_EFA)]`
**Step 8.2: TRIGGER CONDITIONS**
Boot or VF assignment of 0xefa4. Not a race. Unprivileged users cannot
trigger a crash; they just get a working RDMA device after bind.
Record: `[Hotplug/boot of 0xefa4] [Likely on new EFA instances] [Not a
UAF/syscall crash]`
**Step 8.3: FAILURE MODE SEVERITY**
Without the ID: device unused by in-tree driver (lost HPC/RDMA). Not
panic/corruption. For affected hardware this is functional breakage.
Record: `[Device not bound] [Severity: HIGH for 0xefa4 users, LOW for
everyone else]`
**Step 8.4: RISK-BENEFIT RATIO**
Benefit: enables real hardware on an existing driver (stable-kernel-
rules explicitly allow this).
Risk: two lines, ID-table only, no API/lock/hot-path change.
Record: `[Benefit: high for EFA 0xefa4] [Risk: very low] [Favorable]`
---
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: COMPILE THE EVIDENCE**
FOR:
- `Documentation/process/stable-kernel-rules.rst`: “must either fix a
real bug that bothers people **or just add a device ID**.”
- Canonical PCI ID exception: driver already in tree; only the ID is
new.
- +2 lines, obviously correct, same as efa2/efa3.
- No per-ID branching; probe is generation-agnostic.
- Real device (`1d0f:efa4`); Amazon out-of-tree and rdma-core already
list it.
- Reviewed and applied by RDMA maintainer Leon Romanovsky.
- Applies cleanly; no new APIs.
AGAINST:
- Not a crash/security/corruption fix (not required for device IDs).
- Submitted as `for-next`, no `Cc: stable` (absence is expected).
- Series mate extends page-shift for >4GB MRs; not needed for bind.
- Author is a first-time in-tree EFA contributor (offset by Margolin
review + Leon apply).
UNRESOLVED:
- Direct lore.kernel.org HTTP fetches returned 403; thread recovered via
`b4 dig -m`.
- Stable mailing list search via WebFetch also 403; no stable discussion
in the rdma mbox.
**Step 9.2: STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — 2-line ID table; maintainer
applied after review.
2. Fixes a real bug that affects users? **PASS** — device ID exception;
otherwise 0xefa4 never binds.
3. Important issue? **PASS** under the documented device-ID exception
(not a panic).
4. Small and contained? **PASS** — +2 lines, one file.
5. No new features or APIs? **PASS** — existing driver, new ID only
(page-shift is a different commit).
6. Can apply to the local tree? **PASS** — `efa_main.c` ID table
present; hunk matches.
**Step 9.3: EXCEPTION CATEGORY**
**Device ID addition to existing driver** — automatic stable qualifier.
**Step 9.4: DECISION**
This tree is **7.3.0-rc4**. The EFA driver and PCI table are here.
Adding `0xefa4` is the standard, low-risk hardware-enablement backport.
The companion page-shift change is a separate feature and is not
required for this ID patch to be correct.
### What it solves for users of this tree
Without `0xefa4` in `efa_pci_tbl`, new Amazon EFA adapters are invisible
to the in-tree driver. With it, the existing probe path binds them. That
is exactly what stable trees take PCI IDs for.
### Risk vs benefit
Benefit is hardware enablement for EFA 0xefa4. Risk is two lines that
cannot affect other devices.
---
### Verification
- [Phase 1] Parsed commit `6a57af838b1a56405a9bde9030de16df901ae2ca`:
Reviewed-by Margolin, SOB Anas Mousa + Leon Romanovsky, Link msgid
`20260712134413.19226-3`
- [Phase 2] Diff: +2 lines in `efa_pci_tbl` / `PCI_DEV_ID_EFA4_VF` only
- [Phase 2] `efa_probe()` does not branch on `ent`/`pdev->device` for
quirks (verified in `efa_main.c`)
- [Phase 3] `git blame -L 16,29 efa_main.c`: efa0–efa3 older; efa4 is
this commit
- [Phase 3] Prior IDs: efa2 `b75927cff13e0`, efa3 `346d2fc606a85` — same
2-line pattern
- [Phase 3] Series mate `4266547bdce74` is page-shift GENMASK only, not
a probe dependency
- [Phase 4] `b4 dig -c 6a57af838b1a5`: matched lore thread; v1 only
- [Phase 4] `b4 dig -w`: linux-rdma, jgg, leon CC’d
- [Phase 4] mbox: Leon question on patch 1/2 only; both patches applied
2026-07-14; no NAK on ID patch
- [Phase 4] WebFetch lore/stable: HTTP 403 — UNVERIFIED via HTTP;
covered by b4 mbox
- [Phase 5] Call path: PCI `id_table` → `efa_probe`; `page_size_cap`
used in `efa_verbs.c` for MR pages
- [Phase 6] `git describe HEAD` = `v7.3-rc4-27-gf0100363d8c37`; `make
kernelversion` = 7.3.0-rc4
- [Phase 6] `git merge-base --is-ancestor 6a57af838b1a5 HEAD` = yes; not
ancestor of `v7.2.7`
- [Phase 6] Driver added `b7f5e880f3774` (v5.2-rc1); present in this
tree
- [Phase 7] `Documentation/process/stable-kernel-rules.rst` line 15:
device ID explicitly allowed
- [Phase 8] Failure mode: device not bound on 0xefa4; no panic path
- UNVERIFIED: stable@vger archive contents (HTTP 403)
The change is a contained PCI ID addition to a driver this tree already
ships, which stable policy explicitly accepts.
**YES**
drivers/infiniband/hw/efa/efa_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/infiniband/hw/efa/efa_main.c b/drivers/infiniband/hw/efa/efa_main.c
index fdaf88f0122db..b1f3e7ce2c65e 100644
--- a/drivers/infiniband/hw/efa/efa_main.c
+++ b/drivers/infiniband/hw/efa/efa_main.c
@@ -17,12 +17,14 @@
#define PCI_DEV_ID_EFA1_VF 0xefa1
#define PCI_DEV_ID_EFA2_VF 0xefa2
#define PCI_DEV_ID_EFA3_VF 0xefa3
+#define PCI_DEV_ID_EFA4_VF 0xefa4
static const struct pci_device_id efa_pci_tbl[] = {
{ PCI_VDEVICE(AMAZON, PCI_DEV_ID_EFA0_VF) },
{ PCI_VDEVICE(AMAZON, PCI_DEV_ID_EFA1_VF) },
{ PCI_VDEVICE(AMAZON, PCI_DEV_ID_EFA2_VF) },
{ PCI_VDEVICE(AMAZON, PCI_DEV_ID_EFA3_VF) },
+ { PCI_VDEVICE(AMAZON, PCI_DEV_ID_EFA4_VF) },
{ }
};
--
2.53.0