dbus-sensors + phosphor-hwmon
james.feist at linux.intel.com
Wed Jul 24 03:27:12 AEST 2019
On 7/23/2019 10:17 AM, Patrick Venture wrote:
> On Tue, Jul 23, 2019 at 9:58 AM James Feist <james.feist at linux.intel.com> wrote:
>> On 7/22/2019 3:26 PM, Patrick Venture wrote:
>>> I haven't tested yet, but I have a device-tree with a lot of ~40
>>> hard-coded sensors on it, and then the other sensors will be detected
>>> with entity-manager (once that's set up).
>> Entity-manager doesn't detect sensors, it detects removable components
>> then expects certain sensors. For our baseboard here:
>> at the bottom of the file there is a dbus-probe for an
>> xyz.openbmc_project.FruDevice interface with some specific properties.
>> If those match, then entity-manager through sysfs can add some sensors
> Right, so entity-manager writes out a configuration to dbus and
> dbus-sensors works from that exported configuration on dbus -- ?
> That's my current understanding, the trick is, the dynamic versus
> static, and how some sensors are already specified in the device-tree.
We don't define any in the device tree. We just use one very basic
device tree with not much in it (in regards to sensors) besides i2c
buses. Although you could have some in device tree, right now I believe
you'd just get export warnings. It uses sysfs to export sensors. In the
future we'd like to have multiple device trees in u-boot and switch
between them to allow multiple i2c typologies, but we haven't gotten there.
>> You could also use device tree if you wanted, the export just wouldn't
>> succeed. But you would need a json file with the sensors bus and address
>> for dbus-sensors to work.
>>> In this case, will entity-manager populate the dbus configuration with
>>> those in the device-tree initially making them available to
>>> dbus-sensors? (or will we or should we, also configure phosphor-hwmon
>>> for those sensors?)
More information about the openbmc