Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / phosphor-led-manager / fe476e17ad79896a45be676146f4867c4476edfb
commitfe476e17ad79896a45be676146f4867c4476edfb[log] [tgz]
authorAlexander Hansen <alexander.hansen@9elements.com>Tue Jul 23 15:45:22 2024 +0200
committerAlexander <alexander.hansen@9elements.com>Wed Jul 31 16:52:46 2024 +0000
treeb2ea1f3cfa92793584956f3ec3f6ef51358c5152
parent2099d9f5d581899858aa7d72880f7652b475e4f6 [diff]
readability: remove redundant check before iterate

There were some patterns like

if (collection.size()) {
    for(auto& it : collection){
        //...
    }
}

which is redundant.

Change-Id: I10c0ad1ecd0aa2e96b456dcf9c5ea4d8995ae016
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
2 files changed
tree: b2ea1f3cfa92793584956f3ec3f6ef51358c5152
  1. configs/
  2. example/
  3. fault-monitor/
  4. manager/
  5. scripts/
  6. subprojects/
  7. test/
  8. .clang-format
  9. .gitignore
  10. .linter-ignore
  11. .shellcheck
  12. led.yaml
  13. LICENSE
  14. meson.build
  15. meson.options
  16. OWNERS
  17. pyproject.toml
  18. README.md
  19. utils.cpp
  20. utils.hpp
README.md

phosphor-led-manager

This project manages LED groups on dbus. Sometimes many LEDs must be driven together to indicate some system state.

For example, there can be multiple identify LEDs. When the user wants to identify the system, they should all light up together.

Configuration

The configuration can happen via json or yaml.

Configuration: LED Priority

Each LED can have "Priority" as "Blink" or "On". If this property is defined, it should be defined on each instance of the LED in the config.

When multiple LED groups are asserted and contain the same LED, "Priority" determines the state of the LED.

For example, Group 1 says LED1 should be "Blink", and Group 2 says it should be "On". LED1 will then have the state declared in "Priority".

Configuration Example (JSON)

This is our configuration file. It describes 2 LEDs for the 'enclosure_identify' group, with their respective states and duty cycles.

{
  "leds": [
    {
      "group": "enclosure_identify",
      "members": [
        {
          "Name": "pca955x_front_sys_id0",
          "Action": "On",
          "DutyOn": 50,
          "Period": 0,
          "Priority": "Blink"
        },
        {
          "Name": "led_rear_enc_id0",
          "Action": "On",
          "DutyOn": 50,
          "Period": 0,
          "Priority": "Blink"
        }
      ]
    }
  ]
}

Then start the program with

~# ./phosphor-led-manager --config example.json

Dbus interface

When starting the program, our LED group shows up on dbus. Usually there will be many more groups.

$ busctl tree xyz.openbmc_project.LED.GroupManager
`- /xyz
  `- /xyz/openbmc_project
    `- /xyz/openbmc_project/led
      `- /xyz/openbmc_project/led/groups
        `- /xyz/openbmc_project/led/groups/enclosure_identify


$ busctl introspect xyz.openbmc_project.LED.GroupManager /xyz/openbmc_project/led/groups/enclosure_identify
NAME                                TYPE      SIGNATURE RESULT/VALUE FLAGS
...
xyz.openbmc_project.Led.Group       interface -         -            -
.Asserted                           property  b         false        emits-change writable

In the above output, the usual org.freedesktop.* interfaces have been removed to keep it readable.

We can now drive the entire group by setting it's 'Asserted' property on dbus.

$ busctl set-property \
xyz.openbmc_project.LED.GroupManager \
/xyz/openbmc_project/led/groups/enclosure_identify \
xyz.openbmc_project.Led.Group Asserted b true

The program can then use the xyz.openbmc_project.Led.Physical dbus interface exposed by phosphor-led-sysfs to set each LED state.

How to Build

meson setup build
cd build
ninja