nvmed: Adds support for MCTP devices exposed by mctpreactor
Adds a new class, MctpReactorDevice that inherits from MctpDevice and
is specific to the way mctpreactor sets things up.
To get an endpoint ID, MctpReactorDevice queries the "configures"
association in the ObjectMapper, that associates the NVMe device object
with a NVME1000 interface and the MCTP endpoint object.
Additionally, NVMeMi was changed to skip MTU and SMBus frequency setup
for devices that aren't directly accessible over I2C, which is
recognized through the absence of the `bus` parameter in those
devices' JSON configuration files for EntityManager.
Tested: Test were done on a lab machine that has an E1.S SSD
connected to BMC through a USB <-> I2C MCTP bridge.
nvmesensor log:
https://paste.googleplex.com/5240477540548608
Another test on the same machine was ran with mctpreactor
down and then started again after a few minutes:
https://paste.googleplex.com/5326693527060480
Roughly midway down that log periodic retrying can be
observed. A retry happens every 60-90 seconds. Estimate is
based on me looking at the log in realtime rather than
measuring or looking at the code.
Additionally tested on tjbm11 with the new and old
nvmesensor binary to see if there's regressions:
https://paste.googleplex.com/6389420236341248
Finally, tested on tmdja26 to see how does nvmed pick up
regular I2C devices through mctpreactor:
https://paste.googleplex.com/4860794563067904
Google-Bug-Id: 444680700
Change-Id: I3d01d7e6bd7ee6bd9455c0f17e498631cee18cb7
Signed-off-by: Luka Strizic <lstrz@google.com>
dbus-sensors is a collection of sensor applications that provide the xyz.openbmc_project.Sensor collection of interfaces. They read sensor values from hwmon, d-bus, or direct driver access to provide readings. Some advance non-sensor features such as fan presence, pwm control, and automatic cpu detection (x86) are also supported.
runtime re-configurable from d-bus (entity-manager or the like)
isolated: each sensor type is isolated into its own daemon, so a bug in one sensor is unlikely to affect another, and single sensor modifications are possible
async single-threaded: uses sdbusplus/asio bindings
multiple data inputs: hwmon, d-bus, direct driver access
A typical dbus-sensors object support the following dbus interfaces:
Path /xyz/openbmc_project/sensors/<type>/<sensor_name>
Interfaces xyz.openbmc_project.Sensor.Value
xyz.openbmc_project.Sensor.Threshold.Critical
xyz.openbmc_project.Sensor.Threshold.Warning
xyz.openbmc_project.State.Decorator.Availability
xyz.openbmc_project.State.Decorator.OperationalStatus
xyz.openbmc_project.Association.Definitions
Sensor interfaces collection are described here.
Consumer examples of these interfaces are Redfish, Phosphor-Pid-Control, IPMI SDR.
dbus-sensor daemons are reactors that dynamically create and update sensors configuration when system configuration gets updated.
Using asio timers and async calls, dbus-sensor daemons read sensor values and check thresholds periodically. PropertiesChanged signals will be broadcasted for other services to consume when value or threshold status change. OperationStatus is set to false if the sensor is determined to be faulty.
A simple sensor example can be found here.
Sensor devices are described using Exposes records in configuration file. Name and Type fields are required. Different sensor types have different fields. Refer to entity manager schema for complete list.