Re: Changing LEDs status in response to Power Events

[Ed Tanous <edtanous@google.com>]

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