unexpected configuration output given examples
Patrick Venture
venture at google.com
Thu Aug 15 11:16:47 AEST 2019
On Wed, Aug 14, 2019 at 5:48 PM Patrick Venture <venture at google.com> wrote:
>
> When hard-coding bus and addresses, I ran into an interesting issue.
> Previously, my sensors were dynamically bus'd with hard-coded
> addresses, like:
>
> {
> "Exposes": [
> {
> "Address": "0x1c",
> "Bus": "$bus",
> "Name": "$bus board local",
> "Name1": "$bus board external",
> "Type": "TMP441"
> },
> ...
> }
>
> Leads to:
> xyz.openbmc_project.Configuration.TMP441 interface - - -
> .Address property t 28
> emits-change
> .Bus property t 20
> emits-change
>
> Which is great.
>
> But:
> {
> "Exposes": [
> {
> "Address": "0x54",
> "Bus": 15,
> "Name": "$bus i2cool 0",
> "Type": "MAX31725"
> },
> ...
> }
>
> Leads to:
> xyz.openbmc_project.Configuration.MAX31725 interface - - -
> .Address property s "0x54"
> emits-change
> .Bus property t 15
> emits-change
>
>
> Which crashes the hwmon temp program because it's "getting" a uint64_t
> and not a string.
I verified that if I use decimal for the address as an int it works.
But I'm interested to know why "0x54" doesn't get converted to an int
every time?
>
> My only caveat worthwhile is that the hwmon instance is already
> present because that sensor is in the device-tree. So I would expect
> it to only fail on the export.
>
> Note, I did also try "Address" as an int and not a string, but that
> then failed the json validation.
>
> Thanks,
> Patrick
More information about the openbmc
mailing list