prettier: re-format
The latest prettier (3.6.2) fixed an incompatibility with markdownlint
and requires re-running[1].
[1]: https://github.com/prettier/prettier/pull/17675
Change-Id: Idd9fb1d4f33ef599ec73548a300da7c53ffda8cd
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
diff --git a/REST-cheatsheet.md b/REST-cheatsheet.md
index 6a862ae..cc31cf1 100644
--- a/REST-cheatsheet.md
+++ b/REST-cheatsheet.md
@@ -129,7 +129,6 @@
```
- Delete images from system:
-
- Delete image:
```bash
@@ -149,7 +148,6 @@
```
- Control boot source override:
-
- Read current boot source override settings:
```bash
@@ -189,7 +187,6 @@
- Set NTP and Nameserver:
Examples using public server.
-
- NTP Server:
```bash
@@ -218,7 +215,6 @@
results in
[openbmc/openbmc#3459](https://github.com/openbmc/openbmc/issues/3459), and
the related test cases are updated to cooperate with this behavior change.
-
- Read:
```bash
@@ -245,7 +241,6 @@
```
- Power Supply Redundancy:
-
- Read:
```bash
@@ -260,7 +255,6 @@
```
- Factory Reset:
-
- Factory reset host and BMC software:
```bash
diff --git a/anti-patterns.md b/anti-patterns.md
index afb6356..f309647 100644
--- a/anti-patterns.md
+++ b/anti-patterns.md
@@ -299,7 +299,6 @@
The following example log entries use an IPMI request to set network access
on, but the user input is invalid.
-
- BMC Developer: Reference internal applications, services, pids, etc. the
developer would be familiar with.
diff --git a/architecture/code-update/code-update.md b/architecture/code-update/code-update.md
index 3e415bb..c7b74f3 100644
--- a/architecture/code-update/code-update.md
+++ b/architecture/code-update/code-update.md
@@ -13,7 +13,6 @@
1. Get a BMC image tar: After building OpenBMC, you will end up with a set of
image files in `tmp/deploy/images/<platform>/`.
-
- The UBI layout image is
`obmc-phosphor-image-<platform>-<timestamp>.ubi.mtd.tar`
- The static layout image is
@@ -35,7 +34,6 @@
```
2. Transfer the generated BMC image to the BMC via one of the following methods:
-
- Method 1: Via Redfish Upload:
<https://github.com/openbmc/docs/blob/master/REDFISH-cheatsheet.md#firmware-update>.
If using this method skip ahead to step 5!
@@ -52,7 +50,6 @@
value of 8 hexadecimal numbers, generated by SHA-512 hashing the version
string contained in the image and taking the first 8 characters. Get the
version id via one of the following methods:
-
- Method 1: From the BMC command line, note the most recent directory name
created under `/tmp/images/`, in this example it'd be `2a1022fe`:
@@ -86,7 +83,6 @@
image to `Active`, substitute `<id>` with the hash value noted on the
previous step, this will write the contents of the image to the BMC chip via
one of the following methods:
-
- Method 1: From the BMC command line:
```bash
@@ -109,7 +105,6 @@
5. (Optional) Check the flash progress. This interface is only available during
the activation progress and is not present once the activation is completed
via one of the following:
-
- Method 1: From Redfish: A task is returned from the Redfish upload. The
task can be used to monitor the progress.
@@ -133,7 +128,6 @@
6. Check that the activation is complete by verifying the "Activation" property
is set to "Active" via one of the following methods:
-
- Method 1: From Redfish: Check the task returned from the Redfish upload.
```bash
@@ -155,7 +149,6 @@
```
7. Reboot the BMC for the image to take effect.
-
- Method 1: From Redfish: If ApplyTime was set to "Immediate", the BMC will
automatically reboot:
<https://github.com/openbmc/docs/blob/master/REDFISH-cheatsheet.md#firmware-applytime>.
diff --git a/architecture/code-update/emmc-storage-design.md b/architecture/code-update/emmc-storage-design.md
index 875f2a7..16d81fc 100644
--- a/architecture/code-update/emmc-storage-design.md
+++ b/architecture/code-update/emmc-storage-design.md
@@ -164,7 +164,6 @@
provided to the kernel to append unused physical blocks.
- Logical Volumes:
-
- Volume management: LVM. This allows for dynamic partition/removal, similar
to the current UBI implementation. LVM support increases the size of the
kernel by ~100kB, but the increase in size is worth the ability of being
diff --git a/architecture/code-update/host-code-update.md b/architecture/code-update/host-code-update.md
index 729b0ae..f272049 100644
--- a/architecture/code-update/host-code-update.md
+++ b/architecture/code-update/host-code-update.md
@@ -7,14 +7,12 @@
the host is not accessing its firmware.
1. Get a squashfs image:
-
- Build op-build: <https://github.com/open-power/op-build>
- After building, the image should be a tarball in the output/images
directory called `<system type>.pnor.squashfs.tar`
2. Transfer the generated squashfs image to the BMC via one of the following
methods:
-
- Method 1: Via scp: Copy the generated squashfs image to the `/tmp/images/`
directory on the BMC.
- Method 2: Via REST Upload:
@@ -32,7 +30,6 @@
value of 8 hexadecimal numbers, generated by SHA-512 hashing the version
string contained in the image and taking the first 8 characters. Get the
version id via one of the following methods:
-
- Method 1: From the BMC command line, note the most recent directory name
created under `/tmp/images/`, in this example it'd be `2a1022fe`:
@@ -66,7 +63,6 @@
image to `Active`, substitute `<id>` with the hash value noted on the
previous step, this will write the contents of the image to a UBI volume in
the PNOR chip via one of the following methods:
-
- Method 1: From the BMC command line:
```bash
@@ -89,7 +85,6 @@
5. (Optional) Check the flash progress. This interface is only available during
the activation progress and is not present once the activation is completed
via one of the following:
-
- Method 1: From the BMC command line:
```bash
@@ -106,7 +101,6 @@
6. Check the activation is complete by verifying the Activation property is set
to Active via one of the following methods:
-
- Method 1: From the BMC command line:
```bash
diff --git a/architecture/openbmc-systemd.md b/architecture/openbmc-systemd.md
index db5cbeb..1f05673 100644
--- a/architecture/openbmc-systemd.md
+++ b/architecture/openbmc-systemd.md
@@ -179,7 +179,6 @@
There are two main failure scenarios when it comes to OpenBMC and systemd usage:
1. A service within a target fails
-
- If the service is a "oneshot" type, and the service is required (not
wanted) by the target then the target will fail if the service fails -
Define a behavior for when the target fails using the "OnFailure" option
@@ -193,7 +192,6 @@
2. A failure outside of a normal systemd target/service (host watchdog expires,
host checkstop detected)
-
- The service which detects this failure is responsible for logging the
appropriate error, and instructing systemd to go to the appropriate target
diff --git a/architecture/sensor-architecture.md b/architecture/sensor-architecture.md
index 909e975..2531b19 100644
--- a/architecture/sensor-architecture.md
+++ b/architecture/sensor-architecture.md
@@ -25,7 +25,6 @@
### Path definitions
- **<type\>** : The [HWMon class][2] name in lower case.
-
- Examples include `temperature, fan_tach, voltage`.
- **<label\>** : User defined name of the sensor.
diff --git a/designs/bmc-reboot-cause-update.md b/designs/bmc-reboot-cause-update.md
index 1e10374..6890544 100644
--- a/designs/bmc-reboot-cause-update.md
+++ b/designs/bmc-reboot-cause-update.md
@@ -57,23 +57,19 @@
the new additions and changes:
1. Driver Provision by BMC Vendors:
-
- Each BMC vendor must provide a driver to retrieve the BMC reboot cause and
record the result at the specified location.
2. Definition and Identification of Reboot Cause Type **Software Reset**:
-
- This one is still under discussion, please refer to the following link for
more detail:
<https://lore.kernel.org/all/9565c496-44d8-4214-8038-931926210d0f@roeck-us.net/>
3. Revise the Definition of **WDIOF_CARDRESET**:
-
- The **WDIOF_CARDRESET** type will now specifically indicate resets caused
by the watchdog.
4. Clarification of The **Power-on-reset case**:
-
- When a BMC reset occured, but the flag in the bootstatus remains unchanged
by the watchdog driver (i.e., it stays at 0), this indicates that a
**Power-on-reset** has occurred.
@@ -86,7 +82,6 @@
| POR | 0x00 | Do nothing |
6. Generate Corresponding Event Log:
-
- After interpreting the reboot cause, the system should issue the
corresponding event log based on the determined type.
diff --git a/designs/code-update.md b/designs/code-update.md
index a69e4b1..15b6494 100644
--- a/designs/code-update.md
+++ b/designs/code-update.md
@@ -29,7 +29,6 @@
## Requirements
1. Able to start an update, given a firmware image and update settings.
-
- Update settings shall be able to specify when to apply the image, for
example immediately or on device reset or on-demand.
diff --git a/designs/cper-records.md b/designs/cper-records.md
index ef1c5c2..9b11e33 100644
--- a/designs/cper-records.md
+++ b/designs/cper-records.md
@@ -83,7 +83,6 @@
- Does this repository require a new repository? Yes
- Who will be the initial maintainer(s) of this repository? Ed Tanous
- Which repositories are expected to be modified to execute this design?
-
- openbmc/openbmc
- openbmc/libcper
diff --git a/designs/dump-manager.md b/designs/dump-manager.md
index 3f7613f..f18e594 100644
--- a/designs/dump-manager.md
+++ b/designs/dump-manager.md
@@ -154,10 +154,8 @@
- Dump Manager DBus object provides interfaces for creating and managing dump
- Interfaces
-
- **Create**: The interface to create a dump, called by clients to initiate
user-initiated dump.
-
- AdditionalData: The additional data, if any, for initiating the dump. The
key in this case should be an implementation specific enum defined for the
specific type of dump either in xyz or in a domain. The values can be
diff --git a/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md b/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md
index ef8544b..a156588 100644
--- a/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md
+++ b/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md
@@ -310,7 +310,6 @@
Rejection: "We have all this stuff [.Model, .SerialNumber, ect. properties]
defined already. I'm not going to accept a new "bunch of random properties
HPe thinks are important [today] globbed into a new interface" interface"
-
- Patrick Williams, Phosphor-dbus-interfaces maintainer.
Counter-proposal: "Reuse the existing dbus interfaces and put them at a
diff --git a/designs/event-logging.md b/designs/event-logging.md
index a54d7e4..6f60651 100644
--- a/designs/event-logging.md
+++ b/designs/event-logging.md
@@ -208,7 +208,6 @@
- Applications running on the BMC must be able to report errors and failure
which are persisted and available for external system management through
standards such as Redfish.
-
- These errors must be structured, versioned, and the complete set of errors
able to be created by the BMC should be available at built-time of a BMC
image.
@@ -228,7 +227,6 @@
- Applications running on the BMC should be able to report important tracing
events relevant to system management and/or debug, such as the system
successfully reaching a running state.
-
- All requirements relevant to errors are also applicable to tracing events.
- The implementation must have a mechanism for vendors to be able to disable
specific tracing events to conform to their own system design requirements.
@@ -255,7 +253,6 @@
APIs must provide compile-time identification, for applicable programming
languages, of call sites which do not conform to the BMC error and event
specifications.
-
- The generated error classes and APIs should not require exceptions but
should also integrate with the `sdbusplus` client and server bindings, which
do leverage exceptions.
@@ -313,7 +310,6 @@
- Generate complete C++ exception types, with compile-time checking of missing
metadata and JSON serialization, for errors and events. Metadata can be of one
of the following types:
-
- size-type and signed integer
- floating-point number
- string
@@ -732,18 +728,15 @@
- Use a date code (ex. `2024.17.x`) representing the ISO 8601 week when the
registry was built.
-
- This does not cover vendors that may choose to branch for stabilization
purposes, so we can end up with two machines having the same
OpenBMC-versioned message registry with different content.
- Use the most recent `openbmc/openbmc` tag as the version.
-
- This does not cover vendors that build off HEAD and may deploy multiple
images between two OpenBMC releases.
- Generate the version based on the git-history.
-
- This requires `phosphor-dbus-interfaces` to be built from a git repository,
which may not always be true for Yocto source mirrors, and requires
non-trivial processing that continues to scale over time.
diff --git a/designs/guard-on-bmc.md b/designs/guard-on-bmc.md
index c144cf6..9d90b35 100644
--- a/designs/guard-on-bmc.md
+++ b/designs/guard-on-bmc.md
@@ -111,12 +111,10 @@
- ID: Id of the record which is part of the entry object path.
- Associations:
-
- Guarded hardware inventory path:
- Forward Name must be "isolated_hw".
- Reverse Name must be "isolated_hw_entry".
- BMC Error Log:
-
- Forward Name must be "isolated_hw_errorlog".
- Reverse Name must be "isolated_hw_entry".
@@ -129,7 +127,6 @@
- Warning - Guarded based on an error which is not critical, but eventually,
there can be critical failures.
- Resolved: Status of guarded hardware
-
- Used to indicate whether guarded hardware is repaired or replaced.
**Note:** Setting this to "true" will not delete this entry because in a few
diff --git a/designs/inventory/gpio-based-hardware-inventory.md b/designs/inventory/gpio-based-hardware-inventory.md
index ac349b6..b1cca0b 100644
--- a/designs/inventory/gpio-based-hardware-inventory.md
+++ b/designs/inventory/gpio-based-hardware-inventory.md
@@ -98,7 +98,6 @@
- Allow configuration of the detectable inventory items through entity-manager
configuration
-
- e.g. cable
- e.g. fan board
- e.g. daughter board
diff --git a/designs/management-console/VMI_Certificate_Exchange.md b/designs/management-console/VMI_Certificate_Exchange.md
index 72ef38e..5561efc 100644
--- a/designs/management-console/VMI_Certificate_Exchange.md
+++ b/designs/management-console/VMI_Certificate_Exchange.md
@@ -253,7 +253,6 @@
secure connection to VMI.
- Certificate exchange fails in the following scenarios
-
- If PHYP is not up
- If PHYP throws error for certificate validation. This interface returns
appropriate HTTP error code (4XX/5XX) based on type of error.
diff --git a/designs/mctp/mctp-kernel.md b/designs/mctp/mctp-kernel.md
index 6f77d0a..1e81c43 100644
--- a/designs/mctp/mctp-kernel.md
+++ b/designs/mctp/mctp-kernel.md
@@ -19,7 +19,6 @@
- Infrastructure should be flexible enough to allow for more complex MCTP
networks, allowing:
-
- each MCTP network (as defined by section 3.2.31 of DSP0236) may consist of
multiple local physical interfaces, and/or multiple EIDs;
diff --git a/designs/ocp-led-policy-support.md b/designs/ocp-led-policy-support.md
index c9451a6..aa75e90 100644
--- a/designs/ocp-led-policy-support.md
+++ b/designs/ocp-led-policy-support.md
@@ -188,26 +188,22 @@
## Alternatives Considered
- Extend phosphor-led-sysfs to expose 2 LEDs (blue/amber) as a single LED.
-
- This does not work since there may be n different fault LEDs as per
[Spec](#background-and-references)
- Also this is basically lying to ourselves and making it difficult for other
sw to get any meaningful info about LEDs from dbus anymore.
- Allow Priority "Off" for LED config.
-
- This only solves the issue for very simple configurations.
- Individual LED priorities are hard to think about when multiple LEDs form an
indicator
- Allow the mixed use of group and individual led priority
-
- This will require considering more edge cases arising from the mixed use.
- Not aware of a use-case which would benefit from mixed use.
- Allow each LED to configure the priority of groups it represents, instead of
just one state.
-
- e.g. "Priority": ["enclosure_identify", "fault", "power"]
- This config would have to be repeated on each instance of an LED
- Or assumed that the first instance defines it?
@@ -218,7 +214,6 @@
- Allow configuring an "indicator" that's comprised of multiple LEDs and then
just define states for that indicator.
-
- Need to translate these states to groups anyways to be compatible with the
existing internal data structures
- Handle the case of member LEDs of that indicator also being members of other
diff --git a/designs/pldm-stack.md b/designs/pldm-stack.md
index 47ce5b2..2f99730 100644
--- a/designs/pldm-stack.md
+++ b/designs/pldm-stack.md
@@ -448,7 +448,6 @@
- If the terminus supports `GetPDRs` command type, `pldmd` will send that
command to get the terminus PDRs. Based on the retrieved PDRs, `pldmd` will
collect:
-
- The association between the entities in the system using
`Entity Association PDR` (section 28.17 of DSP0248 1.2.1).
- The entity names using `Entity Auxiliary Names PDR` (Section 28.18 of
diff --git a/designs/power-systems-memory-preserving-reboot.md b/designs/power-systems-memory-preserving-reboot.md
index cc86179..1e4b689 100644
--- a/designs/power-systems-memory-preserving-reboot.md
+++ b/designs/power-systems-memory-preserving-reboot.md
@@ -243,7 +243,6 @@
curl
- Integration testing by
-
- User-initiated dump testing, which invokes a memory preserving reboot to
collect dump.
- Initiate memory preserving reboot by injecting host error
diff --git a/designs/redfish-eventservice.md b/designs/redfish-eventservice.md
index b54c544..0a7daba 100644
--- a/designs/redfish-eventservice.md
+++ b/designs/redfish-eventservice.md
@@ -470,7 +470,6 @@
So EventService design is hooked to Redfish Event Logs majorly for below two
reasons.
-
- Get the notification whenever new event is logged to Redfish event Logs.
- Way to read the Redfish event log information.
@@ -1118,7 +1117,6 @@
```
4. DeleteSubscription: There are two ways to close the connection from client.
-
- Client can close the browser directly which will close the SSE http
connection and so bmcweb service can close and delete the subscription
data.
diff --git a/designs/redfish-resource-supplement-for-pfr.md b/designs/redfish-resource-supplement-for-pfr.md
index 11068e4..0e0d915 100644
--- a/designs/redfish-resource-supplement-for-pfr.md
+++ b/designs/redfish-resource-supplement-for-pfr.md
@@ -69,7 +69,6 @@
- ProvisiongStatus: The value of this property indicates the provisioning status
of platform firmware. It is of Enum Type with below values.
-
1. NotProvisioned: Indicates platform firmware is not provisioned. This is an
unsecured state.
@@ -101,7 +100,6 @@
firmware resiliency errors.
MessageID's:
-
- BIOSFirmwareResiliencyError
- BMCFirmwareResiliencyError
- CPLDFirmwareResiliencyError
@@ -110,7 +108,6 @@
Below are some cases, where firmware resiliency error events logged for
specific components.
-
- Boot failure
- Update Failure
@@ -118,14 +115,12 @@
firmware panic.
MessageID's:
-
- BIOSFirmwarePanicReason
- BMCFirmwarePanicReason
- CPLDFirmwarePanicReason
- MEFirmwarePanicReason Severity: Warning
Below are some cases, where these events can be logged.
-
- Boot time watchdog expired
- Firmware authentication failure
@@ -133,14 +128,12 @@
platform firmware component recovery.
MessageID's:
-
- BIOSFirmwareRecoveryReason
- BMCFirmwareRecoveryReason
- CPLDFirmwareRecoveryReason
- MEFirmwareRecoveryReason Severity: Warning
Below are few cases, where these events can be logged.
-
- Launch failures
- Update failures
- Authentication failures
@@ -229,7 +222,6 @@
recovery mechanism using below URI.
Few examples to attack Firmware components and validate PFR:
-
1. Corrupt the BMC/BIOS etc... firmware and check Panic events and recovery
actions events.
diff --git a/designs/uart-mux-support.md b/designs/uart-mux-support.md
index 1bf0e27..8328f71 100644
--- a/designs/uart-mux-support.md
+++ b/designs/uart-mux-support.md
@@ -53,12 +53,10 @@
1. What the "connection endpoint" (Unix domain socket, D-Bus object) represents.
This could be either:
-
1. The TTY device exposed by Linux
2. The desired downstream mux port
2. How the mux state is controlled. We might control it by any of:
-
1. An out-of-band command (e.g. via a D-Bus method that's somehow associated
with the connection endpoint)
2. An in-band command (e.g. introducing an SSH-style escape-sequence)
@@ -66,7 +64,6 @@
connected
3. The circumstances under which we allow the mux state to be changed
-
1. Active connections prevent the mux state from being changed
2. The mux state can always change but will terminate any existing
conflicting connections
diff --git a/development/dev-environment.md b/development/dev-environment.md
index 69d56b0..c5b9799 100644
--- a/development/dev-environment.md
+++ b/development/dev-environment.md
@@ -62,7 +62,6 @@
**VirtualBox Tips** - You'll want copy/paste working between your VM and
Host. To do that, once you have your VM up and running:
-
- Devices -> Insert Guest Additions CD Image (install)
- Devices -> Shared Clipboard -> Bidirectional
- reboot (the VM)
diff --git a/security/obmc-security-response-team-guidelines.md b/security/obmc-security-response-team-guidelines.md
index 2f1367d..337476a 100644
--- a/security/obmc-security-response-team-guidelines.md
+++ b/security/obmc-security-response-team-guidelines.md
@@ -17,7 +17,6 @@
Workflow highlights:
1. Handle new problem reports.
-
- Within a day, acknowledge you received the report. Note that reports are
archived in the mailing list.
- Communicate by opening the GitHub draft security advistory as soon as the
@@ -25,7 +24,6 @@
2. Analyze the problem and engage collaborators as needed (upstream, downstream,
and OpenBMC).
-
- Determine if the problem is new or known.
- Determine if the problem is in OpenBMC.
- If the problem is in a project that OpenBMC uses, re-route the problem to
@@ -51,7 +49,6 @@
(SPECIAL REPORT CMU/SEI-2017-SR-022) may guide the process.
Example collaborations:
-
- Submit the problem to another security response team, for example, the
[UEFI Security Response Team (USRT)][].
- Privately engage an OpenBMC maintainer or subject matter expert.