chassis_control.py in skeleton
Yong Li
yong.b.li at linux.intel.com
Thu Dec 7 19:41:54 AEDT 2017
Thanks Brad for your comments! My replies started with [YONG LI] below.
Thanks,
Yong
-----Original Message-----
From: bradleyb at bajor.fuzziesquirrel.com [mailto:bradleyb at bajor.fuzziesquirrel.com] On Behalf Of Brad Bishop
Sent: Tuesday, December 5, 2017 6:20 PM
To: Yong Li <yong.b.li at linux.intel.com>
Cc: 'OpenBMC Maillist' <openbmc at lists.ozlabs.org>
Subject: Re: chassis_control.py in skeleton
Hi Brad,
>
> Regarding the "org.openbmc" references, you are correct, there is only
> one in phosphor-state-manager.
> But there are some other "org.openbmc" references in other
> services(such as in ipmid services). I am working on the gpio/power
> related features design/implement, and would like to help to remove
> these dependences one by one.
Excellent! Thanks.
>
> Regarding the pgood property, It is used for power supply GOOD signal,
> I think one Boolean is good enough too. Currently we can implement the
> same as "org.openbmc" in "xyz." namespace, for replacement.
That will certainly make this easier. Would you mind submitting documentation for this new interface somewhere in phosphor-dbus- interfaces, along with your code that implements it?
[YONG LI] Will do, I would like to start from the simpler changes first. For example, adding pgood to the .yaml, and implement the property
>
> Regarding the gpio monitor, I found the phosphor-gpio-monitor is
> different than these power/button services in skeleton. phosphor-
> gpio-monitor uses these gpio pins as gpio keyboard(input device), and
> trigger a systemd service when there is any key input.
>
> I want to trigger more, for examples, when there is one button(gpio
> input pin) is long pressed,
You are correct, phosphor-gpio-monitor does not currently support different systemd targets for short/long press. Perhaps it could be enhanced to do this? I'm not sure if the underlying gpio-keys driver supports this. Another option would be to scrap the use of gpio- keys/libevdev in phosphor-gpio-monitor and replace it with something else? Maybe the new Linux GPIO chardev?
[YONG LI] Will check/test if there is any new solution for the gpio interrupt handing
> I want to set another gpio output pin to high, for LED ON, and then
> perform a force power off action. I think comepared with using systemd
> services, using sdbusplus to implement these triggered actions should
> be easier?
Can you elaborate on how much configurability you intend to provide here? It is most definitely easier to put all the logic into the application, but I think the answer here depends on your intent. Do you intend to:
1 - Implement something that targets a specific platform/use case.
2 - Implement something general purpose.
If you intend to do #1, that is perfectly fine but I try to encourage
#2 because it is more useful to the most people.
If you intend to do #2, you _could_ write it all in C/C++ but wouldn't you have to implement:
1 - A way to express how the application should react.
2 - A way to express the dependencies between those responses.
3 - A way to express what the application should do if a response action fails.
4 - etc...
systemd is already very good at these things.
[YONG LI] Currently I am testing the system using Intel platforms. The current power on/off services are not match the hardware.
For example, our hardware needs not only the PS_GOOD signal, but and other signals to check if the host on(ACPI status, CPU power signals), and there are several different error handing processes.
On first thought, I want to implement all these logic in one single service. Based on your comments, it seems that I can split these checking to several different services, and using systemd to connect them together.
Every service should be simple and easy to implement, The op-wait-power-on at .service is an example, it just wait for pgood signal.
We can just install these needed services on different platforms. For example, power button monitor service is installed on both IA and openpower platforms, but ACPI monitor is installed on IA platforms only.
>
> Let me study on them, and maybe submit some codes for your review?
Sure!
> Thanks,
> Yong Li
> -----Original Message-----
> From: bradleyb at bajor.fuzziesquirrel.com [mailto:bradleyb at bajor.fuzzie
> squirrel.com] On Behalf Of Brad Bishop
> Sent: Thursday, November 30, 2017 10:01 PM
> To: Yong Li <yong.b.li at linux.intel.com>
> Cc: 'OpenBMC Maillist' <openbmc at lists.ozlabs.org>
> Subject: Re: chassis_control.py in skeleton
>
> On Wed, 2017-11-29 at 09:40 +0800, Yong Li wrote:
> > Thanks Brad for your message!
> >
> > I studied on these state-manager services, It seems that the
> > chassis_control.py can be replaced by chassis_state and host_state
> > .cpp files. I will perform some tests to check if there any changes
> > needed.
> >
> > I also found that some of .cpp services still need these apps in
> > skeleton. Below is an example, it needs the skeleton/op-
> > pwrctl/power_control.obj.c:
> > https://github.com/openbmc/phosphor-state-
> > manager/blob/master/chassis_state_manager.cpp#L56
>
> Nice find. I was aware of this, just wasn't sure if it was too much
> information yet. I think that is the only reference to org.openbmc in
> phosphor-state-manager.
>
> This is something we punted on and needs to be addressed. I say
> punted because we assumed that 'pgood' was a POWER concept and a
> better abstraction would be needed to accommodate other architectures.
> Would you agree? On the off chance a single boolean property is good
> enough for everyone, we could just move this interface to the xyz
> namespace.
>
> I know that in the longer term, I'd like to see a much better
> abstraction around power related concepts so we can share/reuse code
> for things like analysis of faults, etc, so I'd be interested in
> hearing any ideas anyone has on that.
>
> >
> > I would like to start to modify/rewrite these buton/power(gpio
> > control
> > related) tools in skeleton, using C++ and sdbusplus, and support
> > multi platforms(X86). Could you share some comments/suggestions?
>
> So for buttons, potentially we have this application called phosphor-
> gpio-monitor:
>
> github.com/openbmc/phosphor-gpio-monitor
>
> You give it a gpio to monitor, and it runs a systemd target when the
> gpio changes state. I'm hoping this application would be sufficient
> for implementing buttons. It doesn't even use any YAML :-). Can you
> have a look at it and let us know what you think?
>
> > Create a new project such as power-button-manager, or add them into
> > this phosphor-state-manager?
> >
> > Thanks,
> > Yong Li
> >
> > -----Original Message-----
> > From: Brad Bishop [mailto:bradleyb at fuzziesquirrel.com]
> > Sent: Wednesday, November 29, 2017 4:53 AM
> > To: Yong Li <yong.b.li at linux.intel.com>
> > Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>; Li, Yong B
> > <yong.b.l i at intel.com>
> > Subject: Re: chassis_control.py in skeleton
> >
> >
> > > On Nov 23, 2017, at 12:38 AM, Yong Li <yong.b.li at linux.intel.com>
> > > wrote:
> > >
> > > Hi All,
> > >
> > > Based on my understanding, these chassis control/system manager
> > > related projects in skeleton should be initial/reference code, and
> > > will be
> >
> > This is correct. The intent is to remove them eventually.
> >
> > The replacement for the chassis manager is https://github.com/openb
> > mc /phosphor-state-manager
> >
> > The functions of the system manager have gradually been replicated
> > elsewhere. For instance its state management functions were moved
> > to phosphor-state-manager or systemd. Other functions were
> > distributed amongst configuration files and other applications.
> >
> > They have not been removed from the current systems because they all
> > need to be scrubbed for any remaining usage.
> >
> > > rewritten/reimplementation. I would like to know if there is any
> > > plan or on-going projects on them?
> >
> > The plan is to scrub the existing systems and eliminate use of these
> > programs. This means identifying any functional gaps in the
> > replacements and implementing those. I don’t think anyone is
> > working on that at the moment.
> >
> > Ideally any new layers/platforms being added would just not use
> > these programs, but I understand if that requires replacement
> > function that isn’t available and wouldn’t want that to hinder
> > upstreaming of a new platform.
> >
> > If I were to begin to work on this, I would start by building images
> > for the current systems, remove these applications from the image
> > and
> > see what breaks.
> >
> >
> > >
> > > Thanks,
> > > Yong Li
> >
> >
> > -brad=
More information about the openbmc
mailing list