- don't assume that all batteries have exactly one ENVSYS_INDICATOR
- check capacity and charge sensors for ENVSYS_SVALID before using them
now this works on macppc
2. Update handling of FMONCRITICAL event reporting. The state
transition does not require a corresponding change in value.
With these changes, you can now have an INDICATOR sensor that
reports the presence or absence of a device, and (if the device
is present) separately monitor it for proper functioning.
Should address the concerns expressed recently with the commit
of changes to wmi(4) BBU handling.
whether the properties actually exist.
When setting new limit values, don't complain/ignore about duplicate
values if the associated flag bits (indicating that the limit is valid)
are not set.
These two fixes together should fix a problem reported in private Email
by njoly@ a couple months ago. Issue replicated and solution tested
using my recent swsensor pseudo-device running inside qemu world!
one. Fixes a panic reported by njoly@ in private Email
2. Acquire the device before checking whether or not the get_limits
routine exists.
XXX There's still a bug in here somewhere that prevents setting of
XXX limit values after using 'envstat -S'
are not currently set (and, in case of battery capacity sensors, if there
is no value_max). Ensure that such an event-monitor does not trigger the
delivery of any actual events.
Provide a mechanism for sensors to set their limits at time other than
system startup (for example, when a battery is inserted).
This allows us to boot a system with a battery missing, install the
battery some time later, and automatically monitor it without requiring
any user intervention to create the event-monitor. (The actual changes
for battery sensors to use this new capability will come later.)
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.
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.
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.)
