Changing LEDs status in response to Power Events

Changing LEDs status in response to Power Events

[Maxim Sloyko]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

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.

Thoughts?

Thank you.

-- 
-MS

[-- Attachment #2: Type: text/html, Size: 1405 bytes --]

Re: Changing LEDs status in response to Power Events

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

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.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 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
> 

Re: Changing LEDs status in response to Power Events

[Ed Tanous]

On Thu, Jan 7, 2021 at 1:01 PM Bills, Jason M
<jason.m.bills@linux.intel.com> wrote:
>
>
>
> 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.

This is roughly what I suggested to maxim out of band.  I think he's
trying to avoid the "yet another daemon" problem, but I don't see a
great way to do that in this case.

One interesting thing to note, setting the LED state in a configurable
way is somewhat the problem space that James Feist was trying to solve
with callback manager, but that never got into mainline.  I'm not sure
it solves this problem directly, but might be a more extensible
option.

>
> 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.

Considering we have a public, well defined API that gives the
information we need, I suspect x86-power-control isn't the right place
to be adding callbacks, as that would tie it to systems that implement
that daemon.

>
> Thanks,
> -Jason
> >