# DF-5618 — ig4 ACPI glue hardcodes IG4_ATOM for Haswell/Broadwell/Apollo Lake HIDs

## What

`ig4iic_acpi_attach()`:

```c
107:	/* All the HIDs matched are Atom SOCs. */
108:	sc->version = IG4_ATOM;
```

sets the controller version to `IG4_ATOM` (1) for **every** HID in
`ig4iic_ids[]` (`ig4_acpi.c:70-81`). The comment is false for half the list,
and `ig4_pci.c`'s own device table (`ig4_pci.c:103-138`) classifies the same
silicon differently:

| HID        | Silicon                        | ig4_pci.c classification |
|------------|--------------------------------|--------------------------|
| INT33C2/C3 | Haswell-LP LPSS I2C (9c61/9c62)| **IG4_HASWELL**          |
| INT3432/33 | Broadwell/Wildcat Point-LP     | IG4_HASWELL class        |
| 80860F41   | Braswell                       | IG4_ATOM (correct)       |
| 808622C1   | Apollo Lake (5aac..5aba)       | **IG4_APL**              |
| AMDI0010/50| AMD DesignWare                 | n/a (closest ATOM)       |
| APMC0D0F   | Ampere                         | n/a (closest ATOM)       |

Consequences of the wrong value (all version-gated code in `ig4_iic.c`):

- `ig4_iic.c:513-519` — the **HSW-only `IG4_GENERAL_SWMODE` write is skipped**
  on ACPI-enumerated Haswell LPSS (the write that `ig4_pci.c` performs for
  the same silicon when PCI-enumerated — see DF-5600's inverse direction).
- `ig4_iic.c:522-526` — Haswell `SW_LTR`/`AUTO_LTR` handling skipped
  (log-only).
- `ig4_iic.c:527-532` — Apollo Lake falls out of the `>= IG4_SKYLAKE` branch:
  `ACTIVE_LTR`/`IDLE_LTR` handling skipped.
- `ig4_iic.c:620-626` (`#if 0`) and the debug dump (`:1033-1051`) mislabel.

No memory-safety impact: every version-gated access in the ATOM path is also
valid on the mislabeled silicon (the ATOM path reads only registers that
exist on Haswell-class LPSS). This is the pass-2 checklist (a) twin-check
answer: the ACPI glue has **no bzero bug** (the `sc->version` store at
`ig4_acpi.c:108` happens after softc allocation, which newbus zeroes —
`subr_bus.c:1953-1954` `kmalloc(..., M_INTWAIT | M_ZERO)`), but the value
itself is wrong for Haswell/Broadwell/Apollo Lake.

## Live manifestation

`febf_version_print.log` — planted ig4 ACPI device (HID `INT33C2`, Haswell-LP
silicon per ig4_pci.c:104) via the DF-5617 planted-ACPI rig:

```
ig4iic0: <Designware I2C Controller> iomem 0xfebf0000-0xfebf01ff irq 0 on acpi0
ig4iic0: version 1 type 00000000 params 00000000 general 00000000 comp_version 00000000
```

`version 1` = `IG4_ATOM` for Haswell-HID hardware, exactly as the source
predicts.

## Suggested fix (unvalidated — Info-severity hardening)

Map the HID to the version like `ig4_pci.c` does, e.g.:

```c
static const struct { const char *hid; enum ig4_vers ver; } ig4iic_acpi_vers[] = {
	{ "INT33C2", IG4_HASWELL }, { "INT33C3", IG4_HASWELL },
	{ "INT3432", IG4_HASWELL }, { "INT3433", IG4_HASWELL },
	{ "80860F41", IG4_ATOM },   { "808622C1", IG4_APL },
	{ "AMDI0510", IG4_ATOM },   { "AMDI0010", IG4_ATOM },
	{ "APMC0D0F", IG4_ATOM },
};
```

and select in `ig4iic_acpi_probe()` (storing into the softc, which the ACPI
glue — unlike `ig4_pci.c` — does not bzero afterwards), or read the DW
`COMP_TYPE`/`COMP_PARAM1` IP identity as Linux's `designware` driver does.

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.

(No fix.diff for this item: documented recommendation only - see Fix above.)