Lines Matching +full:priority +full:- +full:0
12 OpenBMC must support the [OCP LED Policy](#background-and-references). Currently
14 existing services like phosphor-led-manager.
16 ### Example ([Spec](#background-and-references) 6.2. System General Status)
21 | ---------- | ------------- | ----------------------------------------------- |
22 | 1 | 0 | "All OK" |
23 | 0 | 1 | "Module missing / fault" |
24 | 1 | 1 | LED Priority (cannot represent the fault state) |
29 | --- | ----- | ------------- |
30 | 0 | 0 | initial state |
31 | 1 | 0 | assert ok |
36 be determined by the LED priority. The result is not allowed in the state
37 diagram in [Spec](#background-and-references).
39 In this trivial example we can fix it by just assigning Priority "Off" to the
40 led-blue. But that's not possible at the time of writing (commit
41 [bdbfcde](https://github.com/openbmc/phosphor-led-manager/commit/bdbfcde10520fc841b44d1e777c353a698…
45 ### Example ([Spec](#background-and-references) 6.4 PSU Status)
47 Here we pretend that LED Priority "Off" is allowed and discover that it will not
53 | ------------ | ------------- | ------------- | --------------- | ------------------------- |
54 | 1 | 0 | 0 | 0 | "AC OK" |
55 | 0 | 1 | 0 | 0 | "AC Fault" |
56 | 0 | 1 | 1 | 0 | "AC Under Voltage" |
57 | 0 | 0 | 0 | 1 | "Backup due to AC Outage" |
59 #### LED Priority
62 | ------------ | ------------- | ------------- | --------------- | ------------------------- |
63 | 0 | 0 | 0 | 1 | "Backup due to AC Outage" |
68 | ------------ | ------------- | ------------- | --------------- | ---------------------------- |
69 | 0 | 0 | 0 | 1 | LED Priority (for reference) |
70 | 0 | 0 | 0 | 0 | initial state |
71 | 1 | 0 | 0 | 0 | assert "AC OK" |
72 | 0 | 0 | 0 | 0 | assert "AC Fault" |
73 | 0 | 0 | 0 | 0 | final state |
75 The final state is undefined according to [Spec](#background-and-references)
79 AC Outage" could very well be the highest priority state. And choosing any other
80 LED Priority will prevent it from being applied completely when any other state
88 - [OCP Panel Indicator Specification rev1.0 (pdf)](http://files.opencompute.org/oc/public.php?servi…
89 - [OCP Panel Indicator Specification rev1.0 (presentation)](https://www.opencompute.org/files/OCP18…
95 - Blue
96 - Amber
97 - Combined Blue/Amber in tight spaces
101 - OFF
102 - ON
103 - BLINK (500ms on, 500ms off)
107 - 1 blue LED
108 - 1 to n amber LED to communicate multiple fault conditions OR
109 - 1 blue/amber LED
113 - Ability to prioritize the different LED Groups and thus possible indicator
115 - An Indicator should not be in an inconsistent state. It can display the states
116 as per the [Spec](#background-and-references)
117 - Other services cannot be trusted to keep the assertion of the LED groups in a
123 Extend the concept of "Priority" to groups in phosphor-led-manager. The group
124 priority will be an integer value. A larger number means higher priority for
133 be in a consistent state. The change can be done in a backwards-compatible way.
142 "Priority": 2,
156 "Priority": 1,
183 The group priority and led priority can be mutually exclusive in configuration
185 to work with individual LED Priority and when a group priority is assigned, we
190 - Extend phosphor-led-sysfs to expose 2 LEDs (blue/amber) as a single LED.
191 - This does not work since there may be n different fault LEDs as per
192 [Spec](#background-and-references)
193 - Also this is basically lying to ourselves and making it difficult for other
196 - Allow Priority "Off" for LED config.
197 - This only solves the issue for very simple configurations.
198 - Individual LED priorities are hard to think about when multiple LEDs form an
201 - Allow the mixed use of group and individual led priority
202 - This will require considering more edge cases arising from the mixed use.
203 - Not aware of a use-case which would benefit from mixed use.
205 - Allow each LED to configure the priority of groups it represents, instead of
207 - e.g. "Priority": ["enclosure_identify", "fault", "power"]
208 - This config would have to be repeated on each instance of an LED
209 - Or assumed that the first instance defines it?
210 - Would need to check for equality of all these priority lists for an LED
211 - This does not solve the problem of a group being represented incompletely
212 - For example it is possible for 2 LEDs belonging to the same group to
213 prioritize these groups differently in their priority list.
215 - Allow configuring an "indicator" that's comprised of multiple LEDs and then
217 - Need to translate these states to groups anyways to be compatible with the
219 - Handle the case of member LEDs of that indicator also being members of other
221 - This is basically the same as group priorities but with additional overhead
224 - Only display the group that was last asserted, in case of conflicting groups
225 - This is undesirable since there are groups which are more important to
232 - extend docs on how to configure LED group priority
233 - implement the LED group priority
234 - write unit tests for LED group priority
235 - perhaps change some configs to use this new feature
236 - this is optional as the change is backwards-compatible
238 There should be no impact on d-bus except if we choose to expose the led group
239 priority.
243 - Does this repository require a new repository?
244 - No
245 - Who will be the initial maintainer(s) of this repository?
246 - Which repositories are expected to be modified to execute this design?
247 - phosphor-led-manager
248 - optionally openbmc to upgrade existing configs
249 - Make a list, and add listed repository maintainers to the gerrit review.
255 The feature can easily be unit-tested.