eBMC LED Management

[vishwabmc]

Track all the work related to eBMC LED management

LED subsystem has 2 components:

• Group Manager - http://github.com/openbmc/phosphor-led-manager

• This is the virtual layer containing group of LEDs by a name, with their actions when the group is asserted (

• Physical LED controller - http://github.com/openbmc/phosphor-led-sysfs

• This is responsible for controlling ONE SPECIFIC led. It accesses /sys/class/leds/ to action on the LEDs.

[vishwabmc]

Laundry list of items to be worked on ( A working list )

• Defining the LED groups and actions for Rainier ( MRW or whatever .. )
• Ownership of the LEDs
  • PHYP
  • BMC
  • OS
  • Anything else ?
    • Getting the list of physical LEDs as needed by HMC / PHYP
    • BMC sending the request to PHYP to change the state of LED. Continue the design that PHYP is master of all LEDs when they are up, BMC only master at standby?
    • Enclosure LEDs - SAI aka "System Info", "Enclosure Fault" aka "Fault", "Enclosure Identify" aka "Locate", power LED - all scenarios such as rollup, iso procedure callout, etc
    • Action the LED based on callout in the PEL
    • Handling multiple callout sections
    • Looks like this is going to need a new fru-fault handler and can not be extended over the one that works just at obmc errorlogs
    • Turn on SAI if the fault can not be isolated but the Service Action is set
    • If Lightpath, turn on LEDs for garded FRUs
    • Handling the LEDs based on the FRU service action ( FRU going bad / getting fixed )
    • Turn off all LEDs if the BMC is booting to just Standby state
  • Do not do this if the BMC is automatically booting further
    • LED states to be persisted across reboots
    • Turn off all LEDs on every IPL
    • A RollUp only action caused by OS - for example dasd led rollup, read from io expander
    • Partition detected error ( No Serviceable logs ).
    • BMC to process the request and handle the LED
    • Light Path and Guiding Light --> This is more of how we define the rollup in the MRW
    • What does it mean to switch between LP and GL ? No switching in same system
    • Communicating the LED information between PHYP and BMC ( via PLDM SetStateEffecterStates, GetStateEffecterStates, PDRs )
    • Anything related to FRU gaurd and the associated LED being altered
    • Virtual Service Indicator ( need discussion .. is anything like this still needed ? )
    • Some sort of a bit set by partition and that results in physical SAI being turned on
    • Same as above when the log is created by PHYP
    • Clearing these bits resulting in SAI getting turned off
    • Clearing the physical SAI resulting in turning off of virtual btis.
    • HMC asking for SAI state
    • Checks for state of SAI + any Enclosure fault ( OR 'em ) and then send the result so HMC has accurate status
    • LEDs that are off IO expanders / IO adapters / DASD
    • FRU hotplug events
    • Looks like something with POWR turning off fault etc. Lightpath requires that fault LEDs get turned off when the faulted FRU is replaced. Need to happen if error log manually cleared as well?
    • Anyway, this is to be decided by POWR. Whatever POWR says, LEDs would just take that action
    • Anything with IPMI ?
    • PLDM sensor / effector to communicate / reflect state of LED
    • Working with Groups than physical layer
    • Getting the list of physical LEDs that are part of a group. This can be used to actually get the state of the Physical LEDs
    • Getting the list of associated physical LED for a given LED group
    • LAMP test -- Affected parties
    • When PHYP is up and running
    • At BMC ready State
    • toggle PCIE_SLOT_LED_MF_TEST_EN_N gpio for pci slot power leds during lamp test
    • provide REST API to start lamp test --> Edit: This is to be provided by Op Panel service
    • LED control via GUI - identify, but not fault --> Edit: More of a GUI thing only

[rfrandse]

tracking in jira