| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Change-Id: I3e35bf78260b1fa29e992b00279f2dd166cd2fe1
Signed-off-by: Tom Joseph <tomjoseph@in.ibm.com>
|
|
|
|
|
|
|
|
| |
readingAssertion is special type where the entire assert bitfield
serves as the value or reading.
Change-Id: Iaddbe846e04d2a53cff69d71670a96ccc66636a8
Signed-off-by: Tom Joseph <tomjoseph@in.ibm.com>
|
|
|
|
|
|
|
|
|
| |
For sensor's with reading type eventData2, the eventdata2 field is
mapped to the reading field in the get sensor reading command
response.
Change-Id: I9ad85ddb48d6c273a22e476e29ea9bbb34c13e24
Signed-off-by: Tom Joseph <tomjoseph@in.ibm.com>
|
|
|
|
|
| |
Change-Id: I30aae9abd7905ae3299856d798d41e10859fed7f
Signed-off-by: Tom Joseph <tomjoseph@in.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor YAML format to denote mutability of sensors.
Sensors which expect different formats for reads and writes
should present two entries in the sensor YAML, one with the read
interface and one with the write interface. Sensors which
share a format for both reads and writes may present only one entry
in the YAML with both readable and writable enums specified.
If a sensor receives a write which has an interface of Sensor.Value,
the "Set" message is sent via DBus to the path provided in the YAML.
The previous codepath is maintained.
Change-Id: I292f95b6fe936de759fd65ce72c842a1bfe66448
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
Signed-off-by: Patrick Venture <venture@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A summary of the changes:
- Do not generate per sensor type code to update d-bus objects
corresponding to sensors. Function to update d-bus objects based on
standard sensor event types, such as assertion, event data, are now
generic functions - the need not be generated per sensor or per sensor
type.
- There's a special case where the assertion is treated as a reading
(i.e read the entire assertion field as-is). In this case, code needs
to be generated per sensor because the type of the mapped d-bus
property can vary. In this case have a generic template function, and
generate minimal code like so:
inline ipmi_ret_t readingAssertion(const SetSensorReadingReq& cmdData,
const Info& sensorInfo)
{
// Corresponding d-bus property is uint32_t
return set::readingAssertion<uint32_t>(cmdData, sensorInfo);
}
- Make sensor-example.yaml succinct.
- Make the code in writesensor.mako.cpp more pythonic.
Change-Id: I84415ca6e3f756bbb51a90e290539eb086a7f78b
Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>
|
|
|
|
|
| |
Change-Id: I611a82ace75ac175f0127b4ee0fd586280f04f8a
Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com>
|
|
Resolves openbmc/openbmc#1608
Change-Id: Id76446061fd0fa6dc3dead702538e424293af7ce
Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com>
|