[PATCH AUTOSEL 6.18-5.10] uio: sercos3: add missing MODULE_DEVICE_TABLE()
From: Sasha Levin
Date: Mon Oct 19 2026 - 11:18:10 EST
From: Pengpeng Hou <pengpeng@xxxxxxxxxxx>
[ Upstream commit a432f68c51fc6761658445e80a798b8425fdb3dc ]
The driver has a match table for the pci bus wired into its driver
structure, but the table is not exported with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE() entry so module alias information
is generated for automatic module loading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the driver registration structure, and the missing module alias
publication.
Signed-off-by: Pengpeng Hou <pengpeng@xxxxxxxxxxx>
Link: https://patch.msgid.link/20260704152642.54769-1-pengpeng@xxxxxxxxxxx
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
LLM Generated explanations, may be completely bogus:
Local tree is **v7.3-rc4** (mainline). The change is a one-line
`MODULE_DEVICE_TABLE()` so PCI aliases are generated; that is a real
autoload bug with no runtime risk.
## Phase 1: Commit message forensics
**Step 1.1: Subject**
Record: **[uio/sercos3] [add] [export the existing PCI ID table with
MODULE_DEVICE_TABLE()]**
**Step 1.2: Tags**
Record:
- `Signed-off-by: Pengpeng Hou <pengpeng@xxxxxxxxxxx>` (author)
- `Link:
https://patch.msgid.link/20260704152642.54769-1-pengpeng@xxxxxxxxxxx`
- `Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>`
(UIO/char-misc maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
by:`, or `Cc: stable` (absence of the last two is expected for this
review)
**Step 1.3: Body**
Record:
- **Bug:** `sercos3_pci_ids` is wired into `sercos3_pci_driver.id_table`
but not published with `MODULE_DEVICE_TABLE()`.
- **Symptom:** depmod/modpost emit no PCI aliases, so udev/kmod will not
autoload `uio_sercos3` when a matching card appears.
- **Version info:** none in the message. The ID table has been in the
driver since 2008.
- **Root cause:** missing module-alias publication, not a wrong match
table.
**Step 1.4: Hidden bug fix?**
Record: **No disguise.** It is an explicit metadata-export fix. The
“source-level / no hardware reproduction” sentence is honesty about
evidence, not a cleanup-only change. Without the macro, modular autoload
is broken.
## Phase 2: Diff analysis
**Step 2.1: Inventory**
Record:
- File: `drivers/uio/uio_sercos3.c` — **+1 / −0**
- Function/data: `sercos3_pci_ids` (static PCI ID table), immediately
before `sercos3_pci_driver`
- Scope: **single-file surgical fix**
**Step 2.2: Code flow**
Record:
- **Before:** table exists and is used at runtime by PCI core *after*
the module is already loaded (or if built-in).
- **After:** same runtime matching, plus `MODULE_DEVICE_TABLE(pci,
sercos3_pci_ids)` so modpost/`file2alias.c` emits
`pci:v...d...sv...sd...` aliases into the module.
- Path affected: **build-time module metadata / userspace autoload**,
not probe/remove/IRQ.
**Step 2.3: Bug mechanism**
Record: **Hardware enablement / missing device-table export** (same
family as adding PCI IDs).
- Mechanism: `scripts/mod/file2alias.c` `do_pci_entry()` only walks
tables found via `MODULE_DEVICE_TABLE()`. No macro → no aliases → no
autoload.
- Runtime `id_table` is unchanged, so probe matching is not altered.
**Step 2.4: Fix quality**
Record: **Obviously correct, one line, no unrelated edits.** Regression
risk is **very low**: aliases match the same
vendor/device/subvendor/subdevice entries the driver already uses. No
locking, no API, no data-structure change.
## Phase 3: Git history
**Step 3.1: Blame**
Record: ID table and `pci_driver` come from **`a6030fcc608bd`** (“UIO:
add automata sercos3 pci card support”, John Ogness, 2008-09-18). That
commit never added `MODULE_DEVICE_TABLE()`. The table was later made
`const` in `511d7a35a438d` (2025). The missing export has been present
for the entire life of the driver.
**Step 3.2: Fixes: tag**
Record: **None.** Introduced by `a6030fcc608bd` (verified: parent of
this fix has no `MODULE_DEVICE_TABLE` in this file). `git grep` on
`a432f68c51fc6^ -- drivers/uio/uio_sercos3.c` returned no match.
**Step 3.3: File history**
Record: Recent commits on this file are constify, devm allocs, SPDX,
`module_pci_driver`. **No prerequisite series.** Standalone one-liner.
Same class of UIO fix already exists historically: **`912335c43bb10`**
(“UIO: fix specific device driver missing statement for depmod”, 2009)
added `MODULE_DEVICE_TABLE` to `uio_cif.c` for the same depmod/alias
reason.
**Step 3.4: Author**
Record: Pengpeng Hou is not the UIO maintainer. Same author has a batch
of “add missing MODULE_DEVICE_TABLE()” patches (rtc, vdpa, watchdog,
fbdev, soc, can, clk, power). Pattern is systematic and consistent.
Maintainer of record is Greg Kroah-Hartman, who applied it.
**Step 3.5: Dependencies**
Record: **None.** Uses the long-standing `MODULE_DEVICE_TABLE()` macro
in `include/linux/module.h`. Can apply standalone.
## Phase 4: Mailing list / external
**Step 4.1: Original discussion**
Record:
- `b4 dig -c a432f68c51fc6` →
https://patch.msgid.link/20260704152642.54769-1-pengpeng@xxxxxxxxxxx
- Openwall copy: https://lists.openwall.net/linux-kernel/2026/07/04/476
- `b4 dig -a`: **v1 only**, 2026-07-04. Applied version is that v1.
- No reviewer comments, NAKs, or `Cc: stable` suggestions found in the
retrieved thread.
**Step 4.2: Recipients (`b4 dig -w`)**
Record: Pengpeng Hou, **Greg Kroah-Hartman**, `linux-
kernel@xxxxxxxxxxxxxxx`. Correct maintainer was To:’d.
**Step 4.3: Bug report**
Record: **No user/syzbot/bugzilla report.** Author states source-level
evidence only.
**Step 4.4: Series**
Record: **Standalone**, not `N/M`.
**Step 4.5: Stable list**
Record: **UNVERIFIED.** `lore.kernel.org/stable` and git.kernel.org
fetches returned 403 (Anubis). Openwall search found the lkml submission
only, not a stable-thread discussion.
## Phase 5: Semantic / impact
**Step 5.1: Functions**
Record: No function body changed. Data: `sercos3_pci_ids`; consumer:
`sercos3_pci_driver`.
**Step 5.2: Callers**
Record:
- Runtime: PCI core uses `.id_table` from
`module_pci_driver(sercos3_pci_driver)` → `sercos3_pci_probe` on
match.
- Autoload: udev/kmod uses aliases generated from `MODULE_DEVICE_TABLE`.
- Not IRQ/hot path; module-load / device-enumeration path.
**Step 5.3: Callees**
Record: The new line expands to an alias symbol for modpost. No new
runtime calls.
**Step 5.4: Reachability**
Record: **Yes, from userspace + hardware.** Trigger is a matching PLX
9030 + Sercos subsystem ID (0x1971 / 0x3530, 0x3535, 0x3780) with
`CONFIG_UIO_SERCOS3=m`. Built-in (`=y`) never needed aliases.
**Step 5.5: Similar patterns**
Record: Sibling UIO PCI drivers already export tables: `uio_cif.c`,
`uio_netx.c`, `uio_mf624.c`, `uio_aec.c`. `uio_sercos3` was the outlier.
OF/vmbus/dfl UIO drivers also use `MODULE_DEVICE_TABLE`.
## Phase 6: This checkout
**Step 6.1: Does the buggy code exist here?**
Record:
- Tree: **`v7.3-rc4-27-gf0100363d8c37`**, `VERSION=7 PATCHLEVEL=3
SUBLEVEL=0 EXTRAVERSION=-rc4`, origin `torvalds/linux.git`.
- File and PCI ID table exist (`drivers/uio/uio_sercos3.c`).
- At **HEAD**, `MODULE_DEVICE_TABLE(pci, sercos3_pci_ids)` is already at
line 215 (`git merge-base --is-ancestor a432f68c51fc6 HEAD`
succeeded). That is expected: this checkout is mainline after 7.3-rc1,
i.e. the **source** of stable candidates, not a missing-driver stable
branch.
- Bug introduced: **2008** (`a6030fcc608bd`). Not a post-branch feature.
**Step 6.2: Backport difficulty**
Record: **Clean apply.** Surrounding table/`pci_driver` layout matches
the hunk. No refactor blocking a one-line insert.
**Step 6.3: Related fixes already here**
Record: This is the fix. No alternate alias-export for this driver.
Historical analogue is `uio_cif`’s 2009 `MODULE_DEVICE_TABLE` addition.
## Phase 7: Subsystem
**Step 7.1:**
Record: **UIO PCI driver** (`drivers/uio/`). Criticality: **PERIPHERAL**
— Automata Sercos III industrial card, `CONFIG_UIO_SERCOS3` tristate,
default n, `depends on PCI`.
**Step 7.2:**
Record: **Mature / low churn.** Driver added 2008; later commits are
cleanup (`module_pci_driver`, SPDX, devm, constify). Not a new
subsystem.
## Phase 8: Impact and risk
**Step 8.1: Who is affected**
Record: **Driver-specific / config-specific:** `CONFIG_UIO_SERCOS3=m`
and a matching PCI card. Built-in and systems without the card are
unaffected.
**Step 8.2: Trigger**
Record: PCI enumeration + udev module lookup. Common on modular distro
kernels **if the hardware is present**. Unprivileged users cannot
trigger it without the card. Not a race.
**Step 8.3: Failure mode**
Record: Module not autoloaded; card stays unbound until `modprobe
uio_sercos3`. **Severity: MEDIUM** (real functional break, not
oops/corruption/security). Workaround exists but is not how PCI drivers
are supposed to load.
**Step 8.4: Risk-benefit**
Record:
- **Benefit:** restores autoload for existing IDs (same user-visible
outcome as a device-ID addition).
- **Risk:** very low (one metadata line, no runtime change).
- **Ratio:** favorable.
## Phase 9: Synthesis
**Step 9.1: Evidence**
For:
- Real autoload bug: ID table registered, aliases never published.
- Same class as the stable “add a device ID” exception; IDs already
exist, they were just invisible to kmod.
- One line, obviously correct, no API/feature.
- Sibling UIO PCI drivers already do this; `uio_cif` got the same depmod
fix in 2009.
- Greg Kroah-Hartman applied v1 unchanged.
- Driver present since 2008; no missing prerequisites on this tree.
Against:
- Niche hardware; no `Reported-by` in ~18 years.
- Not a crash, deadlock, or security issue.
- Author did not reproduce on hardware (stated).
- Manual `modprobe` still works.
Unresolved:
- Stable mailing-list discussion (lore 403).
**Step 9.2: Stable rules**
1. Obviously correct and tested? **PASS** — one-line, standard macro;
Greg applied it. Hardware repro not required for alias generation.
2. Real bug affecting users? **PASS** — modular autoload fails for
matching PCI devices.
3. Important? **PASS** (device-ID / hardware-enablement class) — not a
panic, but it is the userspace half of PCI ID support; stable rules
explicitly allow device-ID additions.
4. Small and contained? **PASS** — +1 line, one file.
5. No new features/APIs? **PASS** — publishes existing IDs.
6. Can apply to this tree? **PASS** — driver and table are here; hunk
matches.
**Step 9.3: Exception**
Record: **Device ID / hardware-enablement.** Closest documented
exception: “just add a device ID.” This exports IDs the driver already
matches.
**Step 9.4: Decision**
This tree has the driver and the ID table; the omission is a real
modular-load bug, the patch is a one-line metadata export with no
runtime risk, and it matches how other UIO PCI drivers (and stable’s
device-ID exception) already work. It should be selected for stable.
---
**What it solves for stable users:** With `CONFIG_UIO_SERCOS3=m`, a
Sercos III PLX 9030 card will not cause udev to load `uio_sercos3`
because `modules.alias` has no PCI entries. The line adds those aliases.
Distro/LTS kernels typically ship such drivers as modules.
**Rules:** Small, correct, no new API; equivalent to enabling existing
device IDs for autoload.
**Risk vs benefit:** Benefit is autoload on real hardware; risk is
essentially zero.
**Concerns:** Niche card and no crash report, but that does not outweigh
a zero-risk hardware-enablement one-liner that applies cleanly.
Verification:
- [Phase 1] Parsed tags: author SOB, Greg KH SOB, lore msgid Link; no
Fixes/Reported-by/Cc: stable
- [Phase 2] Diff: +1 `MODULE_DEVICE_TABLE(pci, sercos3_pci_ids)` after
`sercos3_pci_ids[]` in `drivers/uio/uio_sercos3.c`
- [Phase 2] Confirmed `sercos3_pci_driver.id_table = sercos3_pci_ids`
and `module_pci_driver(sercos3_pci_driver)`
- [Phase 3] `git blame`: table from `a6030fcc608bd` (2008); this line
from `a432f68c51fc6`
- [Phase 3] `git grep` on parent: no `MODULE_DEVICE_TABLE` in this file;
HEAD has it at line 215
- [Phase 3] Historical analogue: `912335c43bb10` added the same macro to
`uio_cif.c` for depmod
- [Phase 4] `b4 dig -c a432f68c51fc6`: lore/msgid match; `-a`: v1 only;
`-w`: Greg KH + lkml
- [Phase 4] Openwall thread matches committed patch; no NAK found
- [Phase 4] lore.kernel.org WebFetch: 403 — stable-list discussion
UNVERIFIED
- [Phase 5] `MODULE_DEVICE_TABLE` in `include/linux/module.h`;
`do_pci_entry()` in `scripts/mod/file2alias.c`
- [Phase 5] Sibling UIO PCI drivers already have `MODULE_DEVICE_TABLE`
- [Phase 6] `git describe HEAD` = `v7.3-rc4-27-gf0100363d8c37`; `make
kernelversion` = 7.3.0-rc4
- [Phase 6] `git merge-base --is-ancestor a432f68c51fc6 HEAD` exit 0
(commit is in this mainline checkout)
- [Phase 6] Commit not in `v7.2`; is in `v7.3-rc1`
- [Phase 7] `CONFIG_UIO_SERCOS3` tristate, depends on PCI, module name
`uio_sercos3`
- [Phase 8] Failure mode: no PCI aliases → no autoload; severity MEDIUM;
risk very low
- UNVERIFIED: whether this hash was already applied on some older stable
branch (not this checkout; not used for the verdict)
**YES**
drivers/uio/uio_sercos3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/uio/uio_sercos3.c b/drivers/uio/uio_sercos3.c
index 12afc2fa1a0bb..80087897f9b86 100644
--- a/drivers/uio/uio_sercos3.c
+++ b/drivers/uio/uio_sercos3.c
@@ -212,6 +212,7 @@ static const struct pci_device_id sercos3_pci_ids[] = {
},
{ 0, }
};
+MODULE_DEVICE_TABLE(pci, sercos3_pci_ids);
static struct pci_driver sercos3_pci_driver = {
.name = "sercos3",
--
2.53.0