reformat with latest settings
Reformat with the latest settings from openbmc-build-scripts (and
copy latest config files where appropriate). Fix a few minor
markdownlint issues.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I55205817c29dc3f182a165ddf9cd5d4e07b90063
diff --git a/yaml/xyz/openbmc_project/Led/Group.interface.yaml b/yaml/xyz/openbmc_project/Led/Group.interface.yaml
index daf4aa7..83a0728 100644
--- a/yaml/xyz/openbmc_project/Led/Group.interface.yaml
+++ b/yaml/xyz/openbmc_project/Led/Group.interface.yaml
@@ -4,8 +4,8 @@
- name: Asserted
type: boolean
description: >
- Whether or not the group is currently asserted.
- To assert a group, set to True. To de-assert a group, set to False.
+ Whether or not the group is currently asserted. To assert a group, set
+ to True. To de-assert a group, set to False.
associations:
- name: identifying
diff --git a/yaml/xyz/openbmc_project/Led/README.md b/yaml/xyz/openbmc_project/Led/README.md
index b6d259a..7bc2df5 100644
--- a/yaml/xyz/openbmc_project/Led/README.md
+++ b/yaml/xyz/openbmc_project/Led/README.md
@@ -3,35 +3,34 @@
## Overview
LEDs that are present in the system can be managed by:
-`BMC / Hardware controller / Operating system`. This document describes how
-to control the LEDs that are managed by BMC.
+`BMC / Hardware controller / Operating system`. This document describes how to
+control the LEDs that are managed by BMC.
## Understanding LED groups
-While it is entirely possible to act directly on a physical LED, it makes
-hard when more than one LED is to be acted on for a particular usecase.
+While it is entirely possible to act directly on a physical LED, it makes hard
+when more than one LED is to be acted on for a particular usecase.
For example: Certain systems may have a requirement to **Blink** one particular
LED upon reaching some state. However, some other systems may have a requirement
to **Blink** set of LEDs in different frequencies. Few more systems may have a
-requirement to act on set of LEDs with different actions. Meaning, some LEDs
-to be solid [ON] while some LEDs to be Blinking etc.
+requirement to act on set of LEDs with different actions. Meaning, some LEDs to
+be solid [ON] while some LEDs to be Blinking etc.
-As described above, it is more of a system specific policy on what set
-of LEDs to be acted on in different usecases. Taking all that complexity into
-the code makes it impossible to extend across implementations and hence the need
-of a manager that works on the set of LEDs and policies and that is the Group.
+As described above, it is more of a system specific policy on what set of LEDs
+to be acted on in different usecases. Taking all that complexity into the code
+makes it impossible to extend across implementations and hence the need of a
+manager that works on the set of LEDs and policies and that is the Group.
-To make concept of Group more evident, here is another example:
-Consider a requirement of blinking system Enclosure LED indicating
-an internal problem:
+To make concept of Group more evident, here is another example: Consider a
+requirement of blinking system Enclosure LED indicating an internal problem:
If the DIMM has some issues then the system admin needs a way of identifying
-that system before acting on it. In one case, the LED group may consist of
-DIMM LED + Enclosure Fault LED. However, if the DIMM is attached to a Raiser
-card, then the LED group may consist of DIMM LED + Raise card LED + Enclosure
-Fault LED. Defining this path will make it easier to locate the box and the
-exact part that needs servicing.
+that system before acting on it. In one case, the LED group may consist of DIMM
+LED + Enclosure Fault LED. However, if the DIMM is attached to a Raiser card,
+then the LED group may consist of DIMM LED + Raise card LED + Enclosure Fault
+LED. Defining this path will make it easier to locate the box and the exact part
+that needs servicing.
Definition of LED groups could be static or generated from MRW and must be in
YAML format. A group definition looks like this:
@@ -57,29 +56,30 @@
DutyOn: 50
```
-This says that the group `bmc_booted` consists of 2 physical LEDs in it.
-When this group is acted on, led_1 will turn solid [ON], while led_2
-would be blinking at 50% duty cycle.
+This says that the group `bmc_booted` consists of 2 physical LEDs in it. When
+this group is acted on, led_1 will turn solid [ON], while led_2 would be
+blinking at 50% duty cycle.
## Dbus interfaces for LED groups
Refer to the [specification][group_specification].
-[group_specification]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Led/Group.interface.yaml
+[group_specification]:
+ https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Led/Group.interface.yaml
There is only one property called **asserted** defined on groups and when set to
boolean **true**, the actions listed for the LEDs in that group will get into
-effect as described above.
-When the property is set to **false**, the actions are un-done.
+effect as described above. When the property is set to **false**, the actions
+are un-done.
-- Henceforth, the term **asserted** would mean writing boolean **true**
- onto `assert` property of the group. Term **de-assert** would mean
- writing **false** to `assert` property.
+- Henceforth, the term **asserted** would mean writing boolean **true** onto
+ `assert` property of the group. Term **de-assert** would mean writing
+ **false** to `assert` property.
## Group Dbus information
-**Path: `/xyz/openbmc_project/led/groups/<name>`**
-**Interface: `xyz.openbmc_Project.Led.Group`**
+**Path: `/xyz/openbmc_project/led/groups/<name>`** **Interface:
+`xyz.openbmc_Project.Led.Group`**
Using the yaml definition above, a user can just set the `asserted` property to
boolean `true` on `/xyz/openbmc_project/led/groups/enclosure_identify` and that
@@ -105,23 +105,24 @@
## Understanding Physical LEDs
It is always **recommended** that external users use **only** the LED groups.
-Describing the Physical LED here just for documenting it and strictly NOT to
-be used outside of the firmware code.
+Describing the Physical LED here just for documenting it and strictly NOT to be
+used outside of the firmware code.
## Dbus interfaces for physical LEDs
Refer to the [specification][phys_specification].
-[phys_specification]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Led/Physical.interface.yaml
+[phys_specification]:
+ https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Led/Physical.interface.yaml
## Dbus information
-**Path: `/xyz/openbmc_project/led/physical/<name>`**
-**Interface: `xyz.openbmc_Project.Led.Physical`**
+**Path: `/xyz/openbmc_project/led/physical/<name>`** **Interface:
+`xyz.openbmc_Project.Led.Physical`**
-Using **/xyz/openbmc_project/led/groups/enclosure_identify** as example;
-setting the `asserted` property to `true` would result in these actions in
-`id_front` and `id_rear` physical LEDs.
+Using **/xyz/openbmc_project/led/groups/enclosure_identify** as example; setting
+the `asserted` property to `true` would result in these actions in `id_front`
+and `id_rear` physical LEDs.
1. Property `DutyOn` is set to `50` in;
`/xyz/openbmc/project/led/physical/id_front` and