On 19 October 2015 at 11:31, David Higgs <hig...@gmail.com> wrote: > On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov <m...@mxcrypt.com> wrote: >> Also, upd always sets sensor status to "OK," so sensorsd never >> triggers commands for status changes; we have to use low/high limits >> until this is fixed. One proposed hack was to use "low=1:high=2" in >> sensorsd.conf, but this doesn't seem to work for everybody. [...] > This is still all just a hack; I ran out of free time to keep working on > upd(4). I made the driver less terrible and added a few sensors, but > didn't get as far as changing sensor statuses which could make reporting > much easier.
Yes, it looks like http://bxr.su/o/sys/dev/usb/upd.c follows the NetBSD paradigm where ksensor.status is simply tied to SENSOR_FINVALID from ksensor.flags, which is a redundant approach in the OpenBSD ksensor API, and ksensor.status should instead not be set to anything at all in such scenarios where it wouldn't alert one of a WARN or CRIT condition as per http://bxr.su/o/sys/sys/sensors.h#sensor_status. Cns:OpenBSD {8224} fgrep -n -e .status -e .flags sys/dev/usb/upd.c 254: sensor->ksensor.flags |= SENSOR_FINVALID; 255: sensor->ksensor.status = SENSOR_S_UNKNOWN; 398: sensor->ksensor.status = SENSOR_S_UNKNOWN; 399: sensor->ksensor.flags |= SENSOR_FINVALID; 432: sensor->ksensor.status = SENSOR_S_OK; 433: sensor->ksensor.flags &= ~SENSOR_FINVALID; Cns:OpenBSD {8225} All the three lines with `.status` should probably be removed to avoid the extra confusion and not give the impression that ksensor.status is actually supported by the driver. Cheers, Constantine.SU.
