DF-5618 — hardcoded IG4_ATOM for non-Atom HIDs

See VERDICT.md. Evidence: febf_version_print.log (real boot, planted INT33C2 device: "ig4iic0: version 1" = IG4_ATOM). Reproduce with the DF-5617 planted-ACPI rig (../DF-5617/) using a device whose _CRS window is any allocatable MMIO (e.g. 0xFEBF0000+0x200): the attach prints stop at the compat gate ("Compat version too low") after the "version 1" line — the mis-programming is visible on the console without any harness code.

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

What

ig4iic_acpi_attach():

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:

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.:

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.)