Alert Standard Format (ASF) Specification

Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136
DSP0136 23 April 2003 Page 78 of 94
4. All status bits returned by the device (in the Read Result data byte response to an SMBus
Byte Read message) that are set to 1b within the device’s ASF_ALERTDATA Alert Data
Mask must always be valid, regardless of the power state of the function monitored by that
status bit. For example, if a bit indicates a CPU voltage low error, that bit must return 0b
when the system is in a sleep state and the CPU is not powered or a false error will result.
Alternatively, the implementation might cause the device to not respond to polling (by
responding with a NACK to its SMBus address) during a low-power, sleep, or standby state.
In this case, the alert-sending device will skip updating its event state information for this
device until the device again responds to polling.
It is the managed client’s responsibility to guarantee that the sensor reports valid data for
each supported power state or that the sensor does not respond to polling cycles in the
unsupported power states. This may be accomplished by hardware or software mechanisms.
Note: If the implementation elects to have a device stop responding, it is the system’s
responsibility to ensure that the alert-sending device does not get corrupted data if a power
transition occurs during a legacy sensor polling cycle.
6.1.2 Usage of Firmware Legacy Sensor Device Alert Information
An alert-sending device, acting as an SMBus master, periodically polls the legacy sensor device
associated with each entry in the data structure described in section 4.1.2.3. Each entry contains
the Alert Device Address and Alert Command values that an alert-sending device sets in an
SMBus Legacy Sensor Device Alert Poll Message as defined in section 5.5. These poll cycles
are use to see whether the condition specified by the entry has been asserted.
Note: ASF-Sensor devices, described in 6.2, are the preferred hardware implementation for
sensors. Only legacy sensor devices that meet the criteria specified in appendix C.3 are
supported by this specification.
This process assumes two variables, current
and past. The past variable must be set to 00h by
the alert-sending device when the device is reset.
The alert-sending device uses the procedure described below for each entry in the
ASF_ALERTDATA structure:
1. Use the SMBus Read Byte protocol with the SMBus Slave Address field set to the entry’s
Alert Device Address value and the SMBus Command Code field set to the entry’s Alert
Command value.
2. Perform a bit-wise AND of the SMBus message’s Read Result with the entry’s Alert Data
Mask value. The result of this operation is the current
status.
3. If assertion events for the entry are enabled (as specified in the ASF_ALRT structure's
Assertion Event Mask), determine whether an assertion event has occurred or not. If so, the
alert-sending device sends a PET frame that includes the Alert PET-related information in the
entry. An assertion event has occurred if either of the following cases (A or B) are true:
A. Bit Mask Assertion Event – true if all of the following are true:
i) Bit 0 of the entry’s Alert Device Address field is cleared (0b).
ii) A bit in the current
status is set and the entire past status is cleared.
B. Compare Byte Assertion Event – true if all of the following are true:
i) Bit 0 of the entry’s Alert Device Address field is set (1b).
ii) A bit in the current
status is different than the corresponding bit in the past status.
iii) The current
value matches the entry’s Alert Compare Value.
4. If de-assertion events for the entry are enabled (as specified in the ASF_ALRT structure's
De-AssertionEventMask
), determine whether a de-assertion event has occurred or not. If so,
the alert-sending device sends a PET frame that includes the PET-related information in the
entry and sets the de-assertion bit (bit 7) within the PET frame’s Event Offset field.. A de-
assertion event has occurred if either of the following cases (A or B) are true: