| /openbmc/u-boot/doc/device-tree-bindings/leds/ |
| H A D | leds-bcm6328.txt | 1 LEDs connected to Broadcom BCM6328 controller
4 In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
5 However, on some devices there are Serial LEDs (LEDs connected to a 74x164
9 Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and
10 exporting the 74x164 as spi-gpio prevents those LEDs to be hardware
14 - compatible : should be "brcm,bcm6328-leds".
20 - brcm,serial-leds : Boolean, enables Serial LEDs.
22 - brcm,serial-mux : Boolean, enables Serial LEDs multiplexing.
28 - brcm,serial-shift-inv : Boolean, inverts Serial LEDs shift direction.
31 Each LED is represented as a sub-node of the brcm,bcm6328-leds device.
[all …]
|
| H A D | leds-gpio.txt | 1 LEDs connected to GPIO lines
4 - compatible : should be "gpio-leds".
6 Each LED is represented as a sub-node of the gpio-leds device. Each
11 Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be
14 see Documentation/devicetree/bindings/leds/common.txt
16 see Documentation/devicetree/bindings/leds/common.txt
27 leds {
28 compatible = "gpio-leds";
43 compatible = "gpio-leds";
|
| H A D | leds-bcm6358.txt | 1 LEDs connected to Broadcom BCM6358 controller
4 In these SoCs there are Serial LEDs (LEDs connected to a 74x164 controller),
10 - compatible : should be "brcm,bcm6358-leds".
21 Each LED is represented as a sub-node of the brcm,bcm6358-leds device.
24 - reg : LED pin number (only LEDs 0 to 31 are valid).
27 - label : see Documentation/devicetree/bindings/leds/common.txt
34 compatible = "brcm,bcm6358-leds";
63 compatible = "brcm,bcm6358-leds";
|
| /openbmc/openbmc/meta-ibm/recipes-phosphor/leds/ |
| H A D | phosphor-led-manager_%.bbappend | 3 SYSTEMD_SERVICE:${PN}:append:ibm-enterprise = " obmc-led-create-virtual-leds@.service"
20 …emd_system_unitdir/multi-user.target.wants/obmc-led-create-virtual-leds@sys-class-leds-virtual-enc…
21 TARGET_FAULT="../obmc-led-create-virtual-leds@.service"
26 …emd_system_unitdir/multi-user.target.wants/obmc-led-create-virtual-leds@sys-class-leds-virtual-enc…
27 TARGET_ID="../obmc-led-create-virtual-leds@.service"
33 …emd_system_unitdir/multi-user.target.wants/obmc-led-create-virtual-leds@sys-class-leds-virtual-enc…
36 …emd_system_unitdir/multi-user.target.wants/obmc-led-create-virtual-leds@sys-class-leds-virtual-enc…
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Led/ |
| H A D | README.md | 1 # Managing LED groups and physical LEDs through BMC
5 LEDs that are present in the system can be managed by:
7 control the LEDs that are managed by BMC.
16 to **Blink** set of LEDs in different frequencies. Few more systems may have a
17 requirement to act on set of LEDs with different actions. Meaning, some LEDs to
18 be solid [ON] while some LEDs to be Blinking etc.
20 As described above, it is more of a system specific policy on what set of LEDs
23 manager that works on the set of LEDs and policies and that is the Group.
59 This says that the group `bmc_booted` consists of 2 physical LEDs in it. When
71 boolean **true**, the actions listed for the LEDs in that group will get into
[all …]
|
| /openbmc/u-boot/arch/arm/dts/ |
| H A D | kirkwood-d2net.dts | 11 #include <dt-bindings/leds/leds-ns2.h>
23 ns2-leds {
24 compatible = "lacie,ns2-leds";
37 gpio-leds {
38 compatible = "gpio-leds";
|
| H A D | kirkwood-ns2.dts | 4 #include <dt-bindings/leds/leds-ns2.h>
25 ns2-leds {
26 compatible = "lacie,ns2-leds";
|
| H A D | kirkwood-is2.dts | 4 #include <dt-bindings/leds/leds-ns2.h>
25 ns2-leds {
26 compatible = "lacie,ns2-leds";
|
| H A D | kirkwood-ns2max.dts | 4 #include <dt-bindings/leds/leds-ns2.h>
44 ns2-leds {
45 compatible = "lacie,ns2-leds";
|
| H A D | kirkwood-ns2mini.dts | 4 #include <dt-bindings/leds/leds-ns2.h>
45 ns2-leds {
46 compatible = "lacie,ns2-leds";
|
| H A D | socfpga_cyclone5_socrates.dts | 27 leds: gpio-leds { label
53 &leds {
54 compatible = "gpio-leds";
|
| /openbmc/phosphor-led-manager/manager/lamptest/ |
| H A D | lamptest.hpp | 44 // Get the force update and/or skipped physical LEDs names from the
64 /** @brief Update physical LEDs states during lamp test and the lamp test is
67 * @param[in] ledsAssert - LEDs that are to be asserted newly or to a
69 * @param[in] ledsDeAssert - LEDs that are to be Deasserted
76 /** @brief Clear LEDs triggered by lamptest
77 * When system reboots during lamptest, leds triggered by lamptest needs to
78 * be cleared in the upcoming boot. This method clears all the leds along
85 /** @brief Timer used for LEDs lamp test period */
106 /** @brief Vector of names of physical LEDs, whose changes will be forcibly
110 /** @brief Vector of names of physical LEDs, that will be exempted from lamp
[all …]
|
| /openbmc/u-boot/drivers/led/ |
| H A D | Kconfig | 7 Many boards have LEDs which can be used to signal status or alerts.
9 can provide access to board-specific LEDs. Use of the device tree
16 This option enables support for LEDs connected to the BCM6328
18 HW blinking is supported and up to 24 LEDs can be controlled.
19 All LEDs can blink at the same time but the delay is shared, which
27 This option enables support for LEDs connected to the BCM6358
29 HW has no blinking capabilities and up to 32 LEDs can be controlled.
35 Some drivers can support automatic blinking of LEDs with a given
45 If this is acceptable and you have a need to use LEDs in SPL,
50 bool "LED support for GPIO-connected LEDs"
[all …]
|
| /openbmc/docs/designs/ |
| H A D | multihost-physical-led.md | 14 configured for LEDs.
16 There are cases where multiple LEDs were configured in the device tree for each
17 host and needs to be paired as a group of LEDs for the specified host in the
21 bicolor blue-yellow LED per host. A total of 4 × LEDs will be placed along the
22 front edge of the board in a grid. The grid will be 2 × rows of 2 × LEDs to
26 or ON and other LEDs needs to be in OFF state. Therefore, bi-color LED needs to
31 and also to create LEDs under a single service, a new application is proposed.
137 - Physical Leds are defined in the device tree under "leds" section and
141 leds {
142 compatible = "gpio-leds";
[all …]
|
| H A D | ocp-led-policy-support.md | 43 There are other examples with more LEDs where that alone will not fix the issue.
84 terms of groups and not single LEDs.
132 with locating and fault states having higher priorities. The LEDs would always
139 "leds": [
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
194 sw to get any meaningful info about LEDs from dbus anymore.
198 - Individual LED priorities are hard to think about when multiple LEDs form an
212 - For example it is possible for 2 LEDs belonging to the same group to
215 - Allow configuring an "indicator" that's comprised of multiple LEDs and then
[all …]
|
| /openbmc/openbmc-test-automation/gui/gui_test/hardware_status_menu/ |
| H A D | test_inventory_and_leds_sub_menu.robot | 3 Documentation Test OpenBMC GUI "Inventory and LEDs" sub-menu of "Hardware status" menu.
14 ${xpath_inventory_and_leds_heading} //h1[text()="Inventory and LEDs"]
19 Verify Navigation To Inventory And LEDs Page
26 Verify Components On Inventory And LEDs Page
27 [Documentation] Verify whether required components are displayed under inventory and LEDs page.
|
| /openbmc/phosphor-led-manager/manager/ |
| H A D | manager.hpp | 28 * @brief Manages group of LEDs and applies action on the elements of group
58 /** @brief Comparator for finding LEDs to be DeAsserted */
78 * @param [in] GroupMap - LEDs group layout
97 * @param[in] ledsAssert - LEDs that are to be asserted new
99 * @param[in] ledsDeAssert - LEDs that are to be Deasserted
106 /** @brief Finds the set of LEDs to operate on and executes action
108 * @param[in] ledsAssert - LEDs that are to be asserted newly
110 * @param[in] ledsDeAssert - LEDs that are to be Deasserted
151 /** @brief Timer used for LEDs handler callback*/
154 /** @brief Contains the required set of assert LEDs action */
[all …]
|
| /openbmc/u-boot/arch/mips/mach-bmips/ |
| H A D | Kconfig | 137 ethernet ports, 2 USB ports, 1 UART, GPIO buttons and LEDs, and
148 ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
159 ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
170 ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and a
181 ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs,
192 ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs,
203 ethernet ports, 3 USB ports, 1 UART, GPIO buttons and LEDs, and
214 ethernet ports, 1 UART, GPIO buttons and LEDs, and a BCM43225
225 ethernet ports, 2 USB ports, 1 UART, GPIO buttons and LEDs, and a
236 ethernet ports, 1 UART, GPIO buttons and LEDs, and a BCM4312
[all …]
|
| /openbmc/docs/architecture/ |
| H A D | LED-architecture.md | 103 drive the physical LEDs. The logical groups are defined in the machine's
105 for the individual LEDs that are part of the group.
109 Physical LED wiring is defined in the `leds` section of the machine's [device
115 leds {
116 compatible = "gpio-leds";
127 ls -l /sys/class/leds/fault/
130 lrwxrwxrwx 1 root root 0 Jun 21 20:29 device -> ../../../leds
133 lrwxrwxrwx 1 root root 0 Jun 21 20:04 subsystem -> ../../../../../class/leds
140 An LED Group can contain zero or more LEDs and is defined in the machines
146 meta-ibm/meta-palmetto/recipes-phosphor/leds/palmetto-led-manager-config/led.yaml
[all …]
|
| /openbmc/u-boot/include/ |
| H A D | input.h | 17 /* Keyboard LEDs */
45 uchar leds; /* active LEDs (INPUT_LED_...) */ member
46 uchar leds_changed; /* LEDs that just changed */
165 * Check if keyboard LEDs need to be updated
167 * This can be called after input_tstc() to see if keyboard LEDs need
171 * @return -1 if no LEDs need updating, other value if they do
190 * @param leds Initial LED value (INPUT_LED_ mask), 0 suggested
193 int input_init(struct input_config *config, int leds);
|
| H A D | keyboard.h | 65 * update_leds() - update keyboard LEDs
67 * This is called when the LEDs have changed and need to be updated.
72 * @leds: New LED mask (see INPUT_LED_... in input.h)
74 int (*update_leds)(struct udevice *dev, int leds);
|
| /openbmc/phosphor-led-manager/ |
| H A D | README.md | 3 This project manages LED groups on dbus. Sometimes many LEDs must be driven
6 For example, there can be multiple identify LEDs. When the user wants to
32 Meaning all its LEDs will have the state as per the configuration.
46 "leds": [
90 This is our configuration file. It describes 2 LEDs for the
95 "leds": [
|
| /openbmc/phosphor-logging/extensions/openpower-pels/ |
| H A D | service_indicators.hpp | 51 * activating LEDs. It has a set of rules to use to choose
52 * which callouts inside PELs should have their LEDs asserted,
75 * @brief Turns on LEDs for certain FRUs called out in the PEL.
78 * callout section that it wants to turn on LEDs for. Next it
88 * group, then it will stop and not activate any LEDs at all.
96 * callouts list that need their LEDs turned on.
109 * bother looking in the callouts to find LEDs to turn on.
139 * any LEDs for that FRU.
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-extended/linuxconsole/linuxconsole/ |
| H A D | 60-joystick.rules | 4 # Set PS3 controller leds to the same value bluez will choose for it.
7 …ny PLAYSTATION(R)3 Controller", RUN+="/lib/udev/js-set-enum-leds /sys/%E{DEVPATH}/device/leds/ $nu…
|
| /openbmc/phosphor-led-sysfs/ |
| H A D | README.md | 3 This project exposes physical LEDs on dbus.
10 leds {
11 compatible = "gpio-leds";
23 ./add-led-action --path /sys/class/leds/identify
|