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