Changing LEDs status in response to Power Events

[Bills, Jason M]

On 1/7/2021 8:48 AM, Patrick Williams wrote:
> On Wed, Jan 06, 2021 at 04:52:32PM -0800, Maxim Sloyko wrote:
>> Hi all,
>>
>> We would like to change the state of some of the LEDs in response to some
>> power events. For example, if the system goes from Standby to On, the LED
>> needs to change from blinking fast to blinking slowly.  The way we are
>> doing it right now is we have a script that runs every second, polls system
>> state over D-Bus (xyz.openbmc_project.State.Chassis and
>> xyz.openbmc_project.State.Host) and then, again over D-Bus, ask
>> phosphor-led-manager to switch LED into a new state. This does not sound
>> like a good solution to me, so I have a few questions:
>>
>> 0. Did I miss some existing way to do it in OpenBMC?
>> 1. If not, does anybody have the same problem and how do you solve this?
>> 2. If not, Is anybody working on a solution for this?
>> 3. If not, any thoughts on what's the best way to handle this? I can see at
>> least two approaches:
>>     a) Implement some callbacks in x86-power-control, so that one can
>> register their services/targets to be notified of the event.
>>     b) Implement this in phosphor-led-manager, so that it can listen to
>> D-Bus events and respond to them.
> 
> This usecase is one of the reasons phosphor-state-manager was
> implemented using systemd targets (or at least one of the nice fallouts
> of that design).  The intention was that system-specific things like
> this could easily install themselves into dependencies on the state
> transition targets.
> 
> Unfortunately, if you're using x86-power-control as your state-manager
> I don't think you get this feature.

x86-power-control was built to solve a very specific problem to get some 
of our power-up timing and error-handling issues solved that we couldn't 
figure out how to do with systemd targets in phosphor-state-manager. 
Because of that, it wasn't designed to be very flexible or extensible.

I've thought about how we might be able to improve that but don't want 
to re-invent the wheel where phosphor-state-manager has already solved 
the flexibility and extensibility problem.

I have wanted to get back and spend some more time to see if I can get 
the same reliability, timing and error-handling using systemd targets 
with phosphor-state-manager, but have not had a chance.

For this issue, another option instead of the polling script may be to 
have a new daemon that matches on the Host state property changes and 
updates the LED.

We can consider adding callbacks to x86-power-control, but it may not be 
worth it if phosphor-state-manager can already handle it or there is a 
simpler alternative.

Thanks,
-Jason
>