commit | bdfaa4dc5856ffd368b4710ceecbc93e3e66d50c | [log] [tgz] |
---|---|---|
author | William de Abreu Pinho <williamdapinho@gmail.com> | Wed Jun 18 07:38:33 2025 -0700 |
committer | William de Abreu Pinho <williamdapinho@gmail.com> | Wed Jul 09 08:26:48 2025 -0700 |
tree | fd9be782a21a39ac99165bd1c168c7a4a71bc582 | |
parent | 0c0944d11d43bdf2b1ac798688e36f9b2d7122d8 [diff] |
move service files from Yocto layer This change relocates phosphor-led-manager service files from the Yocto layer to the phosphor-led-manager repository. It also ensures that non-user executables are installed in the libexec. [1]: https://github.com/openbmc/docs/blob/master/anti-patterns.md#incorrect-placement-of-executables-in-sbin-usrsbin-or-bin-usrbin Tested: ``` $ find /tmp/phosphor-led-manager/ | grep libexec /tmp/phosphor-led-manager/usr/local/libexec /tmp/phosphor-led-manager/usr/local/libexec/phosphor-led-manager /tmp/phosphor-led-manager/usr/local/libexec/phosphor-led-manager/phosphor-ledmanager /tmp/phosphor-led-manager/usr/local/libexec/phosphor-led-manager/phosphor-fru-fault-monitor $ find /tmp/phosphor-led-manager -type f | grep service /tmp/phosphor-led-manager/usr/lib/systemd/system/obmc-fru-fault-monitor.service /tmp/phosphor-led-manager/usr/lib/systemd/system/obmc-led-group-start@.service /tmp/phosphor-led-manager/usr/lib/systemd/system/obmc-led-group-stop@.service /tmp/phosphor-led-manager/usr/lib/systemd/system/xyz.openbmc_project.LED.GroupManager.service ``` Change-Id: Id34402c5d4ec40a6bb72f0a349c6dfb5ed1929e2 Signed-off-by: William de Abreu Pinho <williamdapinho@gmail.com>
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.
The configuration can happen via json or yaml.
Each LED can have "Priority" as "Blink", "Off" 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".
Using LED Priority is fine for simple configurations, but when group state needs to always be consistent, Group Priority can be used to enforce the consistent representation.
The Group Priority
is optional and a higher priority means that when 2 groups are asserted, the one with highest Priority
will be represented consistently. Meaning all its LEDs will have the state as per the configuration.
Here we prioritize the locating group above the fault group since locating may be required to fix the fault.
So independent of the order that these groups are asserted, if both are asserted, "sys_id" should be in "Blink" state.
The "unrelated" group will have the default group priority of 0.
{ "leds": [ { "group": "enclosure_identify", "Priority": 2, "members": [ { "Name": "sys_id", "Action": "Blink" }, { "Name": "rear_id", "Action": "Blink" } ] }, { "group": "fault", "Priority": 1, "members": [ { "Name": "sys_id", "Action": "On" }, { "Name": "fault", "Action": "On" } ] }, { "group": "unrelated", "members": [ { "Name": "rear_id", "Action": "On" } ] } ] }
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
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.
meson setup build
cd build
ninja