reformat with latest settings
Reformat with the latest settings from openbmc-build-scripts (and
copy latest config files where appropriate). Fix a few minor
markdownlint issues.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I55205817c29dc3f182a165ddf9cd5d4e07b90063
diff --git a/yaml/xyz/openbmc_project/State/BMC.interface.yaml b/yaml/xyz/openbmc_project/State/BMC.interface.yaml
index 03186c5..4a1d575 100644
--- a/yaml/xyz/openbmc_project/State/BMC.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/BMC.interface.yaml
@@ -1,8 +1,8 @@
description: >
Implementation of BMC state management. When rebooting we are in
transition. When Ready all services required are running
- successfully. When we are Not Ready this implies not all services
- have started that are required to be.
+ successfully. When we are Not Ready this implies not all services have
+ started that are required to be.
properties:
- name: RequestedBMCTransition
@@ -19,8 +19,8 @@
- name: LastRebootTime
type: uint64
description: >
- The last time at which the BMC came out of a reboot as
- determined by its uptime, in epoch time, in milliseconds.
+ The last time at which the BMC came out of a reboot as determined by
+ its uptime, in epoch time, in milliseconds.
- name: LastRebootCause
type: enum[self.RebootCause]
@@ -52,18 +52,20 @@
Ready implies all services started and are running successfully
- name: "NotReady"
description: >
- Not ready implies not all services have started or are not running successfully
+ Not ready implies not all services have started or are not
+ running successfully
- name: "UpdateInProgress"
description: >
- UpdateInProgress implies BMC is in firmware update mode. CurrentBMCState
- will be set to "UpdateInProgress" while starting image download and
- reset to Ready, once activation is done or error case during update process.
+ UpdateInProgress implies BMC is in firmware update mode.
+ CurrentBMCState will be set to "UpdateInProgress" while starting
+ image download and reset to Ready, once activation is done or
+ error case during update process.
- name: "Quiesced"
description: >
BMC firmware is quiesced. The BMC firmware is enabled but either
- unresponsive or only processing a restricted set of commands. This
- state may be the result of a service within the BMC going into a
- failed state.
+ unresponsive or only processing a restricted set of commands.
+ This state may be the result of a service within the BMC going
+ into a failed state.
- name: RebootCause
description: >
diff --git a/yaml/xyz/openbmc_project/State/Boot/PostCode.interface.yaml b/yaml/xyz/openbmc_project/State/Boot/PostCode.interface.yaml
index d72ef2b..cb57e29 100644
--- a/yaml/xyz/openbmc_project/State/Boot/PostCode.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Boot/PostCode.interface.yaml
@@ -1,31 +1,31 @@
description: >
- Monitor Post code coming and buffer all of them based on boot cycle
- into file system.
+ Monitor Post code coming and buffer all of them based on boot cycle into
+ file system.
properties:
- name: CurrentBootCycleCount
type: uint16
description: >
- It is used to indicate number of boot cycles that have
- post codes archived. It starts from 1 and is limited to
- MaxBootCycleNum.
+ It is used to indicate number of boot cycles that have post codes
+ archived. It starts from 1 and is limited to MaxBootCycleNum.
- name: MaxBootCycleNum
type: uint16
description: >
- The max cached boot cycles for post code.
- It is used to indicate end user what's the max boot number,
- and make sure get command parameter less than it.
+ The max cached boot cycles for post code. It is used to indicate end
+ user what's the max boot number, and make sure get command parameter
+ less than it.
methods:
- name: GetPostCodesWithTimeStamp
description: >
- Method to get the cached post codes of the indicated boot cycle with timestamp.
+ Method to get the cached post codes of the indicated boot cycle with
+ timestamp.
parameters:
- name: Index
type: uint16
description: >
- Index indicates which boot cycle of post codes is requested.
- 1 is for the most recent boot cycle. CurrentBootCycleCount is for the
- oldest boot cycle.
+ Index indicates which boot cycle of post codes is requested. 1
+ is for the most recent boot cycle. CurrentBootCycleCount is for
+ the oldest boot cycle.
returns:
- name: Codes
type: dict[uint64, struct[uint64,array[byte]]]
@@ -38,9 +38,9 @@
- name: Index
type: uint16
description: >
- Index indicates which boot cycle of post codes is requested.
- 1 is for the most recent boot cycle. CurrentBootCycleCount is for the
- oldest boot cycle.
+ Index indicates which boot cycle of post codes is requested. 1
+ is for the most recent boot cycle. CurrentBootCycleCount is for
+ the oldest boot cycle.
returns:
- name: Codes
type: array[struct[uint64,array[byte]]]
diff --git a/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml b/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
index 07f2d82..f079640 100644
--- a/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
@@ -12,11 +12,11 @@
type: uint64
default: 0
description: >
- BootProgressLastUpdate is the last time the BootProgress
- property was updated. The time is the Epoch time, number
- of microseconds since 1 Jan 1970 00::00::00 UTC.
- This can be compared with the current BootProgress value
- to know how long the boot has been on the current boot step.
+ BootProgressLastUpdate is the last time the BootProgress property was
+ updated. The time is the Epoch time, number of microseconds since 1
+ Jan 1970 00::00::00 UTC. This can be compared with the current
+ BootProgress value to know how long the boot has been on the current
+ boot step.
enumerations:
- name: ProgressStages
diff --git a/yaml/xyz/openbmc_project/State/Chassis.interface.yaml b/yaml/xyz/openbmc_project/State/Chassis.interface.yaml
index 0d1fb45..7c74a04 100644
--- a/yaml/xyz/openbmc_project/State/Chassis.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Chassis.interface.yaml
@@ -5,32 +5,31 @@
type: enum[self.Transition]
default: "Off"
description: >
- The desired power transition to start on this chassis.
- This will be preserved across AC power cycles of the BMC.
+ The desired power transition to start on this chassis. This will be
+ preserved across AC power cycles of the BMC.
- name: CurrentPowerState
type: enum[self.PowerState]
description: >
- A read-only property describing the current chassis power state.
- A user can determine if a chassis is in transition by comparing
- the CurrentPowerState and RequestedPowerTransition properties.
+ A read-only property describing the current chassis power state. A
+ user can determine if a chassis is in transition by comparing the
+ CurrentPowerState and RequestedPowerTransition properties.
- name: CurrentPowerStatus
type: enum[self.PowerStatus]
description: >
- A read-only property describing the current chassis power status.
- This property aggregates all available information about the status
- of the power coming into the chassis. Note that this is different
- then the CurrentPowerState in that it provides status of the power
- coming into the chassis, not the actual state of the chassis power.
+ A read-only property describing the current chassis power status. This
+ property aggregates all available information about the status of the
+ power coming into the chassis. Note that this is different then the
+ CurrentPowerState in that it provides status of the power coming into
+ the chassis, not the actual state of the chassis power.
- name: LastStateChangeTime
type: uint64
description: >
- The last time at which the chassis power changed state, as
- tracked by the CurrentPowerState property, in epoch time,
- in milliseconds. This can be used to tell when the chassis
- was last powered on or off.
+ The last time at which the chassis power changed state, as tracked by
+ the CurrentPowerState property, in epoch time, in milliseconds. This
+ can be used to tell when the chassis was last powered on or off.
enumerations:
- name: Transition
@@ -78,12 +77,13 @@
- name: "UninterruptiblePowerSupply"
description: >
Chassis power is being provided via an uninterruptible power
- supply. Note that some systems may choose to continue to use this
- status, even once power has returned to the system, to indicate the
- uninterruptible power supply is charging or is below a certain
- threshold of charged. This provides system owners the flexibility on
- whether their system requires a certain level of charged
- uninterruptible power supply to be in a 'Good' state or not.
+ supply. Note that some systems may choose to continue to use
+ this status, even once power has returned to the system, to
+ indicate the uninterruptible power supply is charging or is
+ below a certain threshold of charged. This provides system
+ owners the flexibility on whether their system requires a
+ certain level of charged uninterruptible power supply to be in a
+ 'Good' state or not.
- name: "Good"
description: >
Chassis power status is in a good condition
diff --git a/yaml/xyz/openbmc_project/State/Decorator/PowerSystemInputs.interface.yaml b/yaml/xyz/openbmc_project/State/Decorator/PowerSystemInputs.interface.yaml
index 0dfefdd..22d8dd1 100644
--- a/yaml/xyz/openbmc_project/State/Decorator/PowerSystemInputs.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Decorator/PowerSystemInputs.interface.yaml
@@ -18,10 +18,11 @@
values:
- name: Fault
description: >
- The power supply unit(s) are not providing enough power for normal
- chassis operation, such as in a Brownout/Blackout condition where one
- or more power supplies report AC loss VIN fault.
+ The power supply unit(s) are not providing enough power for
+ normal chassis operation, such as in a Brownout/Blackout
+ condition where one or more power supplies report AC loss VIN
+ fault.
- name: Good
description: >
- The power supply unit(s) are providing enough power for normal chassis
- operation.
+ The power supply unit(s) are providing enough power for normal
+ chassis operation.
diff --git a/yaml/xyz/openbmc_project/State/Drive.interface.yaml b/yaml/xyz/openbmc_project/State/Drive.interface.yaml
index b0500e8..8681a68 100644
--- a/yaml/xyz/openbmc_project/State/Drive.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Drive.interface.yaml
@@ -23,9 +23,9 @@
type: uint64
default: maxint
description: >
- Time when the Drive last rebooted represented in EpochTime.
- The time reference should be based on the BMC's time.
- If not supported, it will be represented as maxint.
+ Time when the Drive last rebooted represented in EpochTime. The time
+ reference should be based on the BMC's time. If not supported, it will
+ be represented as maxint.
flags:
- readonly
diff --git a/yaml/xyz/openbmc_project/State/Host.interface.yaml b/yaml/xyz/openbmc_project/State/Host.interface.yaml
index 02deb2d..6495134 100644
--- a/yaml/xyz/openbmc_project/State/Host.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Host.interface.yaml
@@ -6,8 +6,8 @@
type: enum[self.Transition]
default: "Off"
description: >
- The desired host transition. This will be preserved across AC
- power cycles of the BMC.
+ The desired host transition. This will be preserved across AC power
+ cycles of the BMC.
- name: CurrentHostState
type: enum[self.HostState]
@@ -36,12 +36,12 @@
Host firmware should be on
- name: "Reboot"
description: >
- Host firmware should be rebooted. Chassis power will be cycled from
- off to on during this reboot
+ Host firmware should be rebooted. Chassis power will be cycled
+ from off to on during this reboot
- name: "GracefulWarmReboot"
description: >
- Host firmware be will notified to shutdown and once complete, the
- host firmware will be rebooted. Chassis power will remain on
+ Host firmware be will notified to shutdown and once complete,
+ the host firmware will be rebooted. Chassis power will remain on
throughout the reboot
- name: "ForceWarmReboot"
description: >
@@ -72,17 +72,17 @@
Host firmware is transitioning to a Running state
- name: "Quiesced"
description: >
- Host firmware is quiesced. The host firmware is enabled but either
- unresponsive or only processing a restricted set of commands. This
- state can be a result of the host entering an error state or booting
- into a BIOS setup environment. The BootProgress property will
- provide details on which it is.
+ Host firmware is quiesced. The host firmware is enabled but
+ either unresponsive or only processing a restricted set of
+ commands. This state can be a result of the host entering an
+ error state or booting into a BIOS setup environment. The
+ BootProgress property will provide details on which it is.
- name: "DiagnosticMode"
description: >
Host firmware is capturing debug information. Powering off your
- system while the host is in this state will prevent the debug data
- from being properly collected. The host will move to one of the
- other states once complete.
+ system while the host is in this state will prevent the debug
+ data from being properly collected. The host will move to one of
+ the other states once complete.
- name: RestartCause
description: >
@@ -118,5 +118,5 @@
xyz.openbmc_project.State.ScheduledHostTransition interface
- name: "HostCrash"
description: >
- The host firmware crashed and the BMC has automatically initiated a
- restart of the host firmware
+ The host firmware crashed and the BMC has automatically
+ initiated a restart of the host firmware
diff --git a/yaml/xyz/openbmc_project/State/PowerOnHours.interface.yaml b/yaml/xyz/openbmc_project/State/PowerOnHours.interface.yaml
index 660b2ba..5cfc9ab 100644
--- a/yaml/xyz/openbmc_project/State/PowerOnHours.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/PowerOnHours.interface.yaml
@@ -4,5 +4,6 @@
- name: POHCounter
type: uint32
description: >
- This counter shows how many hours the system has been running. The value
- is a cumulative one and includes all working hours since production.
+ This counter shows how many hours the system has been running. The
+ value is a cumulative one and includes all working hours since
+ production.
diff --git a/yaml/xyz/openbmc_project/State/README.md b/yaml/xyz/openbmc_project/State/README.md
index 1ebe698..d661cdd 100644
--- a/yaml/xyz/openbmc_project/State/README.md
+++ b/yaml/xyz/openbmc_project/State/README.md
@@ -14,26 +14,25 @@
There are three states to track and control on a BMC based server. The states
below in () represent the actual parameter name as found in
`/xyz/openbmc_project/state/`+`/bmcX,/hostY,/chassisZ` where X,Y,Z are the
-instances (in most cases 0). For all three states, the software tracks a
-current state, and a requested transition.
+instances (in most cases 0). For all three states, the software tracks a current
+state, and a requested transition.
1. _BMC_ : The BMC has either started all required systemd services and reached
it's required target (Ready) or it's on it's way there (NotReady). Users can
request a (Reboot).
-2. _Host_ : The host is either (Off), (Running), or it's (Quiesced).
- Running simply implies that the processors are executing instructions. Users
- can request the host be in a (Off), (On), or (Reboot) state. More details on
- different Reboot options below.
- Quiesced means the host OS is in a quiesce state and the system should be
- checked for errors. For more information refer to
- [Error Handling of systemd][1].
+2. _Host_ : The host is either (Off), (Running), or it's (Quiesced). Running
+ simply implies that the processors are executing instructions. Users can
+ request the host be in a (Off), (On), or (Reboot) state. More details on
+ different Reboot options below. Quiesced means the host OS is in a quiesce
+ state and the system should be checked for errors. For more information refer
+ to [Error Handling of systemd][1].
-3. _Chassis_ : The chassis is either (Off) or (On)
- This represents the state of power to the chassis. The Chassis being on
- is a pre-req to the Host being running. Users can request for the chassis to
- be (Off) or (On). A transition to one or the other is implied by the
- transition not matching the current state.
+3. _Chassis_ : The chassis is either (Off) or (On) This represents the state of
+ power to the chassis. The Chassis being on is a pre-req to the Host being
+ running. Users can request for the chassis to be (Off) or (On). A transition
+ to one or the other is implied by the transition not matching the current
+ state.
A simple system design would be to include a single _BMC_, _Host_, and
_Chassis_.
@@ -43,8 +42,7 @@
### BMC
-The _BMC_ would provide interfaces at
-`/xyz/openbmc_project/state/bmc<instance>`
+The _BMC_ would provide interfaces at `/xyz/openbmc_project/state/bmc<instance>`
### _Host_
@@ -61,28 +59,28 @@
This is an instance under _Chassis_ and provide interface at
`/xyz/openbmc_project/state/chassis_system<instance>`
-Instance 0 (chassis_system0) will be treated as a complete chassis system
-which will include BMC, host and chassis. This will support hard power
-cycle of complete system.
+Instance 0 (chassis_system0) will be treated as a complete chassis system which
+will include BMC, host and chassis. This will support hard power cycle of
+complete system.
-In multi-host or multi-chassis system, instance number can be used from
-1-N, as 0 is reserved for complete system. In multi chassis system this
-can be named as chassis_system1 to chassis_systemN
+In multi-host or multi-chassis system, instance number can be used from 1-N, as
+0 is reserved for complete system. In multi chassis system this can be named as
+chassis_system1 to chassis_systemN
## BMC to Host to Chassis Mapping
-In the future, OpenBMC will provide an association API, which allows one
-to programmatically work out the mapping between BMCs, Chassis and Hosts.
+In the future, OpenBMC will provide an association API, which allows one to
+programmatically work out the mapping between BMCs, Chassis and Hosts.
In order to not introduce subtle bugs with existing API users, `bmc0`,
`chassis0` and `host0` are special. If they exist, they are guaranteed to talk
-to the system as a whole as if it was a system with one BMC, one chassis and
-one host. If there are multiple hosts, then bmc0/chassis0/host0
-will _not_ exist. In the event of multiple BMCs or Chassis, bmc0 and chassis0
-will act on all entities as if they are one (if at all possible).
+to the system as a whole as if it was a system with one BMC, one chassis and one
+host. If there are multiple hosts, then bmc0/chassis0/host0 will _not_ exist. In
+the event of multiple BMCs or Chassis, bmc0 and chassis0 will act on all
+entities as if they are one (if at all possible).
-This behaviour means that existing code will continue to work, or error out
-if the request would be ambiguous and probably not what the user wanted.
+This behaviour means that existing code will continue to work, or error out if
+the request would be ambiguous and probably not what the user wanted.
For example, if a system has two chassis, only powering off the first chassis
(while leaving the second chassis on) is certainly _not_ what the API user had
@@ -93,37 +91,40 @@
to function on this multi-chassis system.
For example, a system with multiple hosts would have BMCs, Chassis and Hosts
-_all_ start numbering from 1 rather than 0. This is because multiple hosts
-could be in the same chassis, or controlled by the same BMC, so taking action
-against them would _not_ be what the API user intended.
+_all_ start numbering from 1 rather than 0. This is because multiple hosts could
+be in the same chassis, or controlled by the same BMC, so taking action against
+them would _not_ be what the API user intended.
-It is safe to continue to write code referencing bmc0, host0 and
-chassis0 and that code will continue to function, or error out rather than
-doing something undesirable.
+It is safe to continue to write code referencing bmc0, host0 and chassis0 and
+that code will continue to function, or error out rather than doing something
+undesirable.
## Hard vs. Soft Power Off
-A hard power off is where you simply cut power to a chassis. You don't give
-the software running on that chassis any chance to cleanly shut down.
-A soft power off is where you send a notification to the host that is running
-on that chassis that a shutdown is requested, and wait for that host firmware
-to indicate it has shut itself down. Once complete, power is then removed
-from the chassis. By default, a host off or reboot request does the soft
-power off. If a user desires a cold reboot then they should simply issue a
-power off transition request to the chassis, and then issue an on transition
-request to the host.
+A hard power off is where you simply cut power to a chassis. You don't give the
+software running on that chassis any chance to cleanly shut down. A soft power
+off is where you send a notification to the host that is running on that chassis
+that a shutdown is requested, and wait for that host firmware to indicate it has
+shut itself down. Once complete, power is then removed from the chassis. By
+default, a host off or reboot request does the soft power off. If a user desires
+a cold reboot then they should simply issue a power off transition request to
+the chassis, and then issue an on transition request to the host.
## Operating System State and Boot Progress Properties
-[OperatingSystemState][3] property is used to track different progress states
-of the OS or the hypervisor boot, while the [BootProgress][4] property is used
+[OperatingSystemState][3] property is used to track different progress states of
+the OS or the hypervisor boot, while the [BootProgress][4] property is used
mainly for indicating system firmware boot progress. The enumerations used in
both the cases are influenced by standard interfaces like IPMI 2.0 (Section
42.2, Sensor Type Codes and Data, Table 42, Base OS boot status) and PLDM state
spec (DSP0249, Section 6.3, State Sets Tables, Table 7 – Boot-Related State
Sets, Set ID - 196 Boot Progress).
-[1]: https://github.com/openbmc/docs/blob/master/architecture/openbmc-systemd.md#error-handling-of-systemd
-[2]: https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/
-[3]: https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/OperatingSystem/Status.interface.yaml
-[4]: https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
+[1]:
+ https://github.com/openbmc/docs/blob/master/architecture/openbmc-systemd.md#error-handling-of-systemd
+[2]:
+ https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/
+[3]:
+ https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/OperatingSystem/Status.interface.yaml
+[4]:
+ https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
diff --git a/yaml/xyz/openbmc_project/State/ScheduledHostTransition.interface.yaml b/yaml/xyz/openbmc_project/State/ScheduledHostTransition.interface.yaml
index 74f1fd9..e364ca7 100644
--- a/yaml/xyz/openbmc_project/State/ScheduledHostTransition.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/ScheduledHostTransition.interface.yaml
@@ -5,25 +5,21 @@
type: uint64
default: 0
description: >
- ScheduledTime is a date time when the host will be
- powered on/off. The time is the Epoch time, number
- of seconds since 1 Jan 1970 00::00::00 UTC.
+ ScheduledTime is a date time when the host will be powered on/off. The
+ time is the Epoch time, number of seconds since 1 Jan 1970 00::00::00
+ UTC.
- When ScheduledTime is 0, it means the functionality
- is disabled.
- When ScheduledTime is smaller than current time,
- error InvalidTime will be thrown.
- When the controller detects the ScheduledTime has passed,
- it will execute the ScheduledTransition and reset the
- value to 0. Once the transition starts, there won't be
- any retries.
- When the real time changes, the controller shall check if
- the time is still in the future. If so, it will stop the
- existing timer and restart it with new wait time. Otherwise,
- stop the existing timer and execute the ScheduledTransition.
- When ScheduledTime is reached, but the host is not ready
- to power on/off, e.g. when BMC is rebooting, BMC shall
- set the host ScheduledTransition after it is ready.
+ When ScheduledTime is 0, it means the functionality is disabled. When
+ ScheduledTime is smaller than current time, error InvalidTime will be
+ thrown. When the controller detects the ScheduledTime has passed, it
+ will execute the ScheduledTransition and reset the value to 0. Once
+ the transition starts, there won't be any retries. When the real time
+ changes, the controller shall check if the time is still in the
+ future. If so, it will stop the existing timer and restart it with new
+ wait time. Otherwise, stop the existing timer and execute the
+ ScheduledTransition. When ScheduledTime is reached, but the host is
+ not ready to power on/off, e.g. when BMC is rebooting, BMC shall set
+ the host ScheduledTransition after it is ready.
errors:
- xyz.openbmc_project.ScheduledTime.Error.InvalidTime
@@ -31,5 +27,5 @@
type: enum[xyz.openbmc_project.State.Host.Transition]
default: "On"
description: >
- The desired power transition to support scheduled power on/off.
- The default operation supports scheduled power on.
+ The desired power transition to support scheduled power on/off. The
+ default operation supports scheduled power on.
diff --git a/yaml/xyz/openbmc_project/State/Watchdog.interface.yaml b/yaml/xyz/openbmc_project/State/Watchdog.interface.yaml
index ac71e61..8c7dee1 100644
--- a/yaml/xyz/openbmc_project/State/Watchdog.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Watchdog.interface.yaml
@@ -4,16 +4,16 @@
methods:
- name: ResetTimeRemaining
description: >
- Resets the time remaining to the configured interval.
- This is equivalent to reading the Interval and writing it
- into the TimeRemaining. Optionally the watchdog can be enabled
- during the reset process.
+ Resets the time remaining to the configured interval. This is
+ equivalent to reading the Interval and writing it into the
+ TimeRemaining. Optionally the watchdog can be enabled during the reset
+ process.
parameters:
- name: EnableWatchdog
type: boolean
description: >
- If true the watchdog will be enabled when the reset
- is performed.
+ If true the watchdog will be enabled when the reset is
+ performed.
errors:
- xyz.openbmc_project.Common.Error.InternalFailure
@@ -41,8 +41,8 @@
- name: TimeRemaining
type: uint64
description: >
- Time remaining before timeout, in milli-second.
- Setting this property can re-arm the watchdog.
+ Time remaining before timeout, in milli-second. Setting this property
+ can re-arm the watchdog.
default: 0
- name: CurrentTimerUse
type: enum[self.TimerUse]