# DF-3926 — `siba_cc_power_init` NULL-deref panic on the suspend/resume path when no ChipCommon core was found

## What
`sys/dev/netif/bwn/siba/siba_core.c`:

```c
static void
siba_cc_power_init(struct siba_cc *scc)
{
	struct siba_softc *siba = scc->scc_dev->sd_bus;   /* :1042 — NO NULL check */
```
(its sibling `siba_cc_powerup_delay` has the same unguarded deref at :1071.)

Every other consumer of `scc->scc_dev` guards it (`siba_cc_clock` :786-787,
`siba_cc_pmu_init` caller gate :210, `siba_powerdown_sub` :1900). The attach
path is safe because `siba_core_attach` only calls these under
`if (scc->scc_dev != NULL)` (siba_core.c:210-215).

**The resume path is not**:
```c
siba_core_resume (siba_core.c:2236-2249)
  -> siba_cc_resume(&siba->siba_cc)        /* :2245 — unconditional */
     -> siba_cc_power_init(scc)            /* :2223 */
        -> scc->scc_dev->sd_bus            /* :1042 PANIC if scc_dev == NULL */
```

## How scc_dev ends up NULL on a live device
`siba_scan` (siba_core.c:284-414) sets `siba_cc.scc_dev` only when some core
reports `SIBA_DEVID_CHIPCOMMON` (:351-360). It stays NULL when:
- the very first `siba_switchcore(siba, 0)` fails → early `return` (:296-298);
- hardware reports `siba_ndevs > SIBA_MAX_CORES` → early `return` after the
  warning (:325-330) — `siba_ndevs` comes straight from the MMIO
  ChipCommon `SIBA_CC_NCORES(tmp)` field (:307), i.e. device-controlled;
- core windows return garbage IDHIGH so no core matches CHIPCOMMON.

In all these states the bwn child is never created, but the siba PCI bus
device *is* attached (probe matched the DID table, siba_bwn.c:91-137), so
`siba_bwn_suspend` → `siba_bwn_resume` (siba_bwn.c:211-249) still run on the
next suspend/resume cycle (ACPI S3, laptop lid) → deterministic NULL-deref
panic at a small fixed offset (`sd_bus` is at offset 0 of siba_dev_softc, so
the fault address is ~0).

Sibling of DF-1939 (NULL-deref in siba_bwn_read_ivar) but a distinct
function/path (resume vs ivar read).

## Impact
Kernel panic (NULL deref) from a suspend/resume cycle on a card whose scan
failed — device-controlled preconditions (bad MMIO/NCORES), hardware-gated.
Severity Low, confidence certain at source level.

## Reproduce (needs a Broadcom SSB card + forced scan failure / S3 cycle)
Not possible on the audit guest: no 14e4 PCI device (env.txt).

## Fix
```diff
 (move the deref below the guard:)
+	if (scc->scc_dev == NULL)
+		return;
+	siba = scc->scc_dev->sd_bus;
```
(also guard `siba_cc_powerup_delay`; see fix.diff)