All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Williams <patrick@stwcx.xyz>
To: Maxim Sloyko <maxims@google.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Changing LEDs status in response to Power Events
Date: Thu, 7 Jan 2021 10:48:52 -0600	[thread overview]
Message-ID: <X/c7dM7/uDIDTlFI@heinlein> (raw)
In-Reply-To: <CAFR_W8pjBgn=V9ye-R9ThvyvqwxqYnY94vAX0q1h4sVEaLWN2Q@mail.gmail.com>

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

  reply	other threads:[~2021-01-07 16:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-07  0:52 Changing LEDs status in response to Power Events Maxim Sloyko
2021-01-07 16:48 ` Patrick Williams [this message]
2021-01-07 21:00   ` Bills, Jason M
2021-01-07 21:07     ` Ed Tanous

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X/c7dM7/uDIDTlFI@heinlein \
    --to=patrick@stwcx.xyz \
    --cc=maxims@google.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.