| Age | Commit message (Collapse) | Author |
|
exported to device drivers, so rename it and move the declaration to
<dev/sysmon/sysmonvar.h>
|
|
sme_events_worker().
Provide a wrapper that can be called from sensor drivers' interrupt
routines to find and deliver a specific event.
XXX Actually updating sensor drivers (and their parent devices) to
XXX have interrupts is a future enhancement. This is simply an
XXX enabler.
|
|
one place, and functioned as a logical OR of the ENVSYS_FMON* flag bits.
|
|
|
|
exposing them to user-land.
|
|
|
|
sensors.
|
|
|
|
meaningful for a few limited function calls; all persitent storage
of limit-present flags is maintained in the edata->upropset member.
|
|
|
|
flags to determine which limits are present.
|
|
|
|
there is a routine to be called!
|
|
its refresh() callback. Just assume that its value has been properly
updated by other means.
|
|
|
|
by a set (selected via a passed callback predicate) of sensors.
This provides an easy way to query the current temperature of a thermal
zone, for example, from within the kernel - assuming the caller knows
the topology.
|
|
|
|
|
|
constraints to both driver-requested and user-requested monitoring.
While here, clean up some of the debugging DPRINTFs.
|
|
Use the limits_flags only for calls to the {get,set}_limits() callbacks
and merge the results into upropset, rather than trying to maintain both
values (error prone).
|
|
|
|
event data. Otherwise, they're not processed.
XXX This needs to be rethought. While fixing it this way makes things
XXX "work", we really shouldn't need to replicate these flags. The
XXX limits and their flags should be kept as part of the sensor data,
XXX and not part of the event-monitor data. I'll work on this in the
XXX near future.
|
|
|
|
limit. Otherwise we'll never notice if we exceed crit-max (assuming that
crit-max is at least as large as warn-max).
|
|
The longest string in use with this seems to have been "acpi",
so size_t covered that, but on 32-bit ports omited the NUL.
|
|
Use flag bits to determine validity of limit values, rather than
assuming that invalid/not-present values are set to zero.
|
|
have been committed in the first place.
|
|
early enough, and we can easily figure out the driver name from some
subsequent debug messages.
|
|
events being created for devices that don't provide internal limits.
Thanks to Mattias for finding this.
|
|
|
|
argument to them to identify the individual sensor being processed.
|
|
be programmed into device registers. This way we can let the hardware
help us out instead of having to always compare the value against each
limit. (Driver updates for some sensors to take advantage of this
capability will be forthcoming.)
|
|
|
|
precursor to letting sensor drivers actually exchange limits/thresholds
with user-land.
|
|
to use it. Otherwise we end up leaking little bits of memory for each
sensor that is not monitored at time of initial registration.
|
|
we don't need individual flag bits. Clean up extra bit definitions.
Bump kernel version - welcome to 5.99.13
|
|
|
|
|
|
regardless of sensor type. Fixes spurious "device: normal state on
'sensor-name' messages (reported by ad@) which interfere with sysinst.
|
|
|
|
whenever state enters or exits CRITICAL, or whenever value of sensor
changes while the state is CRITICAL.
|
|
particular event being monitored. This avoids duplicate reporting for
sensors that monitor both a normal/critical state and value-within-limits
state as reported by Simon Burge on current-users.
While we're here, clean-up some stair-stepping if's.
OK garbled@
|
|
Removes unreachable code warning.
|
|
the locking and fixes -Wunreachable-code warning.
|
|
time messages that report a "transition" to the Normal state.
|
|
critical-min and critical-max; also, a battery warning-capacity is
added in addition to a critical-capacity.
2. usr.sbin/envstat is modified to introduce a -W command line switch to
display the warning-* values instead of the critical-* values, and
envstat(8) and envsys.conf(5) man pages are updated appropriately.
3. Treat user-defined limits as a single continuum and generate a single
event regardless of how many boundaries a change in sensor value
crosses; ditto for driver-defined limits.
Fixes my PR/39021
Fixes my PR/39022
OK'd by christos@ bouyer@ cube@
|
|
present before using the values read, and clean up the logics
a bit to make it more understandable
|
|
it is polled (and not from GTREDATA).
|
|
|
|
some weeks in both UP and SMP without any issue so far.
|