# DF-5634 — children are created with no `struct iicbus_ivar` ever allocated (the DF-5559 root): `iicbus_write_ivar` returns success while discarding every address write

* File under audit: `sys/bus/iicbus/iicbus.c` (pass 2) — root-cause file of
  DF-5559, whose validated fix patched only the accessor half
* Class: incomplete plumbing / silent data loss (hardening completion)
* Severity: Info (no memory-safety consequence by itself; the
  uninitialized-read consequence was DF-5559)
* Verdict: **REPRODUCED** (stock: ENXIO + untouched value; with DF-5559's
  fix: write returns 0 but the value is silently dropped), fix validated

## The defect

`struct iicbus_ivar` (`iicbus.h:44-47`) exists and the generated accessor
`iicbus_get_addr()` (`iicbus.h:53-56`, `__BUS_ACCESSOR`) routes through
`BUS_READ_IVAR`/`BUS_WRITE_IVAR`, but nothing in `iicbus.c` ever:

* allocates an ivar for a child — `iicbus_attach` (`:144-146`) and
  `iicbus_add_child` (`:164-171`) create children bare
  (`make_device` leaves `dev->ivars = NULL`, subr_bus.c);
* implements `bus_read_ivar`/`bus_write_ivar` (absent from
  `iicbus_methods`, `:59-73`) — the uninitialized-stack half, filed and
  fixed as DF-5559;
* frees ivars (`bus_child_detached` absent).

This is the "longer term allocate iicbus_ivar for children in
bus_add_child per FreeBSD" item from the 2026-10-07 task_log lead. Even
**with** DF-5559's validated fix (read/write_ivar added, NULL-tolerant),
every child still has `ivar == NULL`, so:

```c
case IICBUS_IVAR_ADDR:
        if (ivar != NULL)                 /* never true */
                ivar->addr = (uint32_t)value;
        return (0);                       /* success -- value discarded */
```

— `iicbus_write_ivar` reports success while dropping the write, so no code
path can ever set an iicbus child address through the official interface
(there is no in-tree writer today; the hazard is for the same future
consumers DF-5559 flagged, and the accessor contract itself).

## Reproduction (guest)

* Stock (`run_a2.log`): `BUS_WRITE_IVAR(iicbus0, child, IICBUS_IVAR_ADDR,
  0x42)` → error 6 (ENXIO); `BUS_READ_IVAR` → error 6 with the result
  variable **untouched at 0x42424242** — nobody behind the method
  (DF-5559's uninit class, re-proven from the provider side).
* iicbus.ko + DF-5559 fix (`run_b_5559.log`): `WRITE_IVAR(0x42) error=0`
  (success!) but `READ_IVAR val=0x0` — the write was silently discarded;
  `iicbus_get_addr() == 0` forever.
* Fixed (`run_d_fixed.log`): with `fix.diff` allocating ivars in the
  corrected `bus_add_child` (and freeing them in the new
  `bus_child_detached`): `WRITE error=0`, `READ val=0x42`,
  `iicbus_get_addr=0x42` — the round trip works.

## Fix

`fix.diff` (shared with DF-5632): `iicbus_add_child` allocates a
zeroed `struct iicbus_ivar` and `device_set_ivars(child, ivar)`;
`iicbus_child_detached` frees it; the DF-5559 accessors now have a live
ivar to serve. Also removes the dead `DEVTOIICBUS` macro (`iicbus.c:44`)
that still casts to the nonexistent `struct iicbus_device`.