iio-sensor-proxy 3.9's own rules tag fastrpc-adsp with ssc-light and
ssc-compass, and pmOS's 90- rule adds ssc-accel and ssc-proximity. On
this image nothing serves the SSC registry (no hexagonrpcd), so the
libssc compass discover() probes it for 100 s in a nested main loop,
from find_sensors() in the daemon's name-acquired handler, before the
per-type delayed-invocation arrays exist. A ClaimProximity dispatched
in that window (Plasma sends one at every daemon start) hits
g_ptr_array_add(NULL) and driver_set_polling(NULL): the client is
registered, polling never starts, every later claim is treated as
"already active", and ProximityNear stays false with HasProximity
true. A second claim in the window dereferences the NULL array in the
claim handler and the daemon crashes, which is the boot-time crash the
restart drop-in was papering over.
Clear the tags on the fastrpc devices after both rules. The daemon
then skips the probe, starts in under a second and polls on claim.
Verified on the dev phone 2026-09-24 with the near-level DTB (near
level 25, combined-stable's DTS carry): no assertions or crash at
boot, and monitor-sensor logged one "Proximity value changed: 1"/"0"
pair per hand pass. The near level itself comes from that kernel;
without it the daemon declines the sensor before any of this matters.
