dbus interface for SLED reset

Andrew Geissler geissonator at gmail.com
Wed Apr 29 12:17:42 AEST 2020



> On Apr 24, 2020, at 5:42 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> On Thu, Apr 23, 2020 at 06:54:47PM +0000, Vijay Khemka wrote:
>> Hi Andrew,
>> As discussed this in patch review https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/31319/, I have thought of 2 approach to handle this interface.
>> 
>> 
>>  1.  As included in patch create a new method Sled Reset in xyz/openbmc_project/Chassis/Control/Power.interface.yaml. which can be invoked by user for sled reset.
>>  2.  As suggested by many reviewer to have a new chassis instance in xyz/openbmc_project/State/Chassis.interface.yaml and use powerCycle property for Sled reset. As chassis are named as chassis0-N. What should be appropriate name to be used for this instance if we choose this option. Can it be chassis-server or I am not getting proper name, please suggest.
> 
> #2 would be my preference.
> 
> Per xyz/openbmc_project/State/README.md, it is sort of implied that the 
> '{bmc, host, chassis}<instance>' are reserved for those relationships
> but it isn't explicit.  I think we should pick something like
> 'chassis-{system, machine, server}' and add it to the README (I tend
> to like "server" least because switches don't seem to like to be called a
> server).

Yeah, I hadn’t thought about adding something like chassis-system%i

I like that, so it would look like this to power cycle the sled?

busctl set-property xyz.openbmc_project.State.Chassis.System
           /xyz/openbmc_project/state/chassis-system0
           xyz.openbmc_project.State.Chassis
           RequestedPowerTransition s
           xyz.openbmc_project.State.Chassis.Transition.PowerCycle

> 
> -- 
> Patrick Williams



More information about the openbmc mailing list