markdownlint: fix all warnings
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I2a77806e59860015339b90957e2226eecd6b5423
diff --git a/.markdownlint.yaml b/.markdownlint.yaml
new file mode 100644
index 0000000..15c9e81
--- /dev/null
+++ b/.markdownlint.yaml
@@ -0,0 +1,3 @@
+default: true
+MD024:
+ siblings_only: true
diff --git a/.prettierrc.yaml b/.prettierrc.yaml
new file mode 100644
index 0000000..a69b879
--- /dev/null
+++ b/.prettierrc.yaml
@@ -0,0 +1,7 @@
+tabWidth: 4
+printWidth: 80
+proseWrap: "always"
+overrides:
+ - files: "*.md"
+ options:
+ tabWidth: 2
diff --git a/CONFIG_FORMAT.md b/CONFIG_FORMAT.md
index 3d69191..f81d6b2 100644
--- a/CONFIG_FORMAT.md
+++ b/CONFIG_FORMAT.md
@@ -86,14 +86,14 @@
Within a configuration file, there is a JSON object which consists of multiple
"string : value" pairs. This Entity Manager defines the following strings.
-| String | Example Value | Description |
-| :------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| "Name" | "X1000 1U Chassis" | Human readable name used for identification and sorting. |
-| "Probe" | "xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME':'FFPANEL'})" | Statement which attempts to read from d-bus. The result determines if a configuration record should be applied. The value for probe can be set to “TRUE” in the case the record should always be applied, or set to more complex lookups, for instance a field in a FRU file that is exposed by the frudevice |
-| "Exposes" | [{"Name" : "CPU fan"}, ...] | An array of JSON objects which are valid if the probe result is successful. These objects describe the devices BMC can interact. |
-| "Status" | "disabled" | An indicator that allows for some records to be disabled by default. |
-| "Bind\*" | "2U System Fan connector 1" | The record isn't complete and needs to be combined with another to be functional. The value is a unique reference to a record elsewhere. |
-| "DisableNode" | "Fan 1" | Sets the status of another Entity to disabled. |
+| String | Example Value | Description |
+| :------------ | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "Name" | `"X1000 1U Chassis"` | Human readable name used for identification and sorting. |
+| "Probe" | `"xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME':'FFPANEL'})"` | Statement which attempts to read from d-bus. The result determines if a configuration record should be applied. The value for probe can be set to “TRUE” in the case the record should always be applied, or set to more complex lookups, for instance a field in a FRU file that is exposed by the frudevice |
+| "Exposes" | `[{"Name" : "CPU fan"}, ...]` | An array of JSON objects which are valid if the probe result is successful. These objects describe the devices BMC can interact. |
+| "Status" | `"disabled"` | An indicator that allows for some records to be disabled by default. |
+| "Bind\*" | `"2U System Fan connector 1"` | The record isn't complete and needs to be combined with another to be functional. The value is a unique reference to a record elsewhere. |
+| "DisableNode" | `"Fan 1"` | Sets the status of another Entity to disabled. |
Template strings in the form of "$identifier" may be used in configuration
files. The following table describes the template strings currently defined.
@@ -121,101 +121,96 @@
considered valid by BMC when the probe command (reads and compares the product
name in FRU) is successful and this baseboard is named as "WFP baseboard".
-```
+```json
{
- "Exposes": [
+ "Exposes": [
+ {
+ "Name": "1U System Fan connector 1",
+ "Pwm": 1,
+ "Status": "disabled",
+ "Tachs": [1, 2],
+ "Type": "IntelFanConnector"
+ },
+ {
+ "Name": "2U System Fan connector 1",
+ "Pwm": 1,
+ "Status": "disabled",
+ "Tachs": [1],
+ "Type": "IntelFanConnector"
+ },
+ {
+ "Address": "0x49",
+ "Bus": 6,
+ "Name": "Left Rear Temp",
+ "Thresholds": [
{
- "Name": "1U System Fan connector 1",
- "Pwm": 1,
- "Status": "disabled",
- "Tachs": [
- 1,
- 2
- ],
- "Type": "IntelFanConnector"
+ "Direction": "greater than",
+ "Name": "upper critical",
+ "Severity": 1,
+ "Value": 115
},
{
- "Name": "2U System Fan connector 1",
- "Pwm": 1,
- "Status": "disabled",
- "Tachs": [
- 1
- ],
- "Type": "IntelFanConnector"
+ "Direction": "greater than",
+ "Name": "upper non critical",
+ "Severity": 0,
+ "Value": 110
},
{
- "Address": "0x49",
- "Bus": 6,
- "Name": "Left Rear Temp",
- "Thresholds": [
- {
- "Direction": "greater than",
- "Name": "upper critical",
- "Severity": 1,
- "Value": 115
- },
- {
- "Direction": "greater than",
- "Name": "upper non critical",
- "Severity": 0,
- "Value": 110
- },
- {
- "Direction": "less than",
- "Name": "lower non critical",
- "Severity": 0,
- "Value": 5
- },
- {
- "Direction": "less than",
- "Name": "lower critical",
- "Severity": 1,
- "Value": 0
- }
- ],
- "Type": "TMP75"
+ "Direction": "less than",
+ "Name": "lower non critical",
+ "Severity": 0,
+ "Value": 5
},
{
- "Address": "0x48",
- "Bus": 6,
- "Name": "Voltage Regulator 1 Temp",
- "Thresholds": [
- {
- "Direction": "greater than",
- "Name": "upper critical",
- "Severity": 1,
- "Value": 115
- },
- {
- "Direction": "greater than",
- "Name": "upper non critical",
- "Severity": 0,
- "Value": 110
- },
- {
- "Direction": "less than",
- "Name": "lower non critical",
- "Severity": 0,
- "Value": 5
- },
- {
- "Direction": "less than",
- "Name": "lower critical",
- "Severity": 1,
- "Value": 0
- }
- ],
- "Type": "TMP75"
+ "Direction": "less than",
+ "Name": "lower critical",
+ "Severity": 1,
+ "Value": 0
}
- ],
- "Name": "WFP Baseboard",
- "Probe": "xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME' : '.*WFT'})"
+ ],
+ "Type": "TMP75"
+ },
+ {
+ "Address": "0x48",
+ "Bus": 6,
+ "Name": "Voltage Regulator 1 Temp",
+ "Thresholds": [
+ {
+ "Direction": "greater than",
+ "Name": "upper critical",
+ "Severity": 1,
+ "Value": 115
+ },
+ {
+ "Direction": "greater than",
+ "Name": "upper non critical",
+ "Severity": 0,
+ "Value": 110
+ },
+ {
+ "Direction": "less than",
+ "Name": "lower non critical",
+ "Severity": 0,
+ "Value": 5
+ },
+ {
+ "Direction": "less than",
+ "Name": "lower critical",
+ "Severity": 1,
+ "Value": 0
+ }
+ ],
+ "Type": "TMP75"
+ }
+ ],
+ "Name": "WFP Baseboard",
+ "Probe": "xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME' : '.*WFT'})"
}
```
[Full Configuration](https://github.com/openbmc/entity-manager/blob/master/configurations/WFT_Baseboard.json)
-#### Configuration Records - Chassis Example
+## Configuration Records - Chassis Example
Although fan connectors are considered a part of a baseboard, the physical fans
themselves are considered as a part of a chassis. In order for a fan to be
@@ -225,29 +220,29 @@
in baseboard FRU, the fan and the connector are considered as being joined
together.
-```
+```json
{
- "Exposes": [
+ "Exposes": [
+ {
+ "BindConnector": "1U System Fan connector 1",
+ "Name": "Fan 1",
+ "Thresholds": [
{
- "BindConnector": "1U System Fan connector 1",
- "Name": "Fan 1",
- "Thresholds": [
- {
- "Direction": "less than",
- "Name": "lower critical",
- "Severity": 1,
- "Value": 1750
- },
- {
- "Direction": "less than",
- "Name": "lower non critical",
- "Severity": 0,
- "Value": 2000
- }
- ],
- "Type": "AspeedFan"
+ "Direction": "less than",
+ "Name": "lower critical",
+ "Severity": 1,
+ "Value": 1750
+ },
+ {
+ "Direction": "less than",
+ "Name": "lower non critical",
+ "Severity": 0,
+ "Value": 2000
}
- ]
+ ],
+ "Type": "AspeedFan"
+ }
+ ]
}
```
diff --git a/docs/entity_manager_dbus_api.md b/docs/entity_manager_dbus_api.md
index 0b50e2b..7e647a2 100644
--- a/docs/entity_manager_dbus_api.md
+++ b/docs/entity_manager_dbus_api.md
@@ -8,15 +8,15 @@
## DBus Object
-### Object Paths:
+### Object Paths
-#### Entities: /xyz/openbmc_project/Inventory/Item/{Entity Type}/{Entity Name}
+#### Entities: `/xyz/openbmc_project/Inventory/Item/{Entity Type}/{Entity Name}`
Entities are top level json objects that describe a piece of hardware. They are
groups of configurations with few properties of their own, they are a container
type for most pratical purposes.
-#### Devices : /xyz/openbmc_project/Inventory/Item/{Entity Type}/{Entity Name}/{Configuration}
+#### Devices: `/xyz/openbmc_project/Inventory/Item/{Entity Type}/{Entity Name}/{Configuration}`
Configurations are components that are exposed when an entity is added to the
"global" system configuration. An example would be a TMP75 sensor that is
@@ -24,13 +24,13 @@
**Example**:
-```
+```text
/xyz/openbmc_project/Inventory/Item/Board/Intel_Front_Panel/Front_Panel_Temp
```
-### Interfaces :
+### Interfaces
-#### xyz.openbmc_project.{InventoryType}
+#### `xyz.openbmc_project.{InventoryType}`
See
[upstream types](https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/Inventory/Item)
@@ -45,23 +45,23 @@
Entity objects describe pieces of physical hardware.
-##### Properties:
+##### Properties
-unsigned int: num_children: Number of configurations under this entity.
+`unsigned int num_children`: Number of configurations under this entity.
-std::string name: name of the inventory item
+`std::string name`: name of the inventory item
-#### xyz.openbmc_project.Configuration
+#### `xyz.openbmc_project.Configuration`
Configuration objects describe components owned by the Entity.
-##### Properties:
+##### Properties
Properties will contain all non-objects (simple types) exposed by the JSON.
**Example**:
-```
+```text
path: /xyz/openbmc_project/Inventory/Item/Board/Intel_Front_Panel/Front_Panel_Temp
Interface: xyz.openbmc_project.Configuration
string name = "front panel temp"
@@ -69,20 +69,20 @@
string "bus" = "1"
```
-#### xyz.openbmc_project.Device.{Object}.{index}
+#### `xyz.openbmc_project.Device.{Object}.{index}`
{Object}s are members of the parent device that were originally described as
dictionaries. This allows for creating more complex types, while still being
able to get a picture of the entire system when doing a get managed objects
method call. Array objects will be indexed zero based.
-##### Properties:
+##### Properties
All members of the dictonary.
**Example**:
-```
+```text
path: /xyz/openbmc_project/Inventory/Item/Board/Intel_Front_Panel/Front_Panel_Temp
Interface: xyz.openbmc_project.Device.threshold.0
string direction = "greater than"
@@ -91,7 +91,7 @@
## JSON Requirements
-### JSON syntax requirements:
+### JSON syntax requirements
Based on the above DBus object, there is an implicit requirement that device
objects may not have more than one level deep of dictionary or list of
@@ -105,7 +105,7 @@
Legal:
-```
+```text
exposes :
[
{
@@ -117,7 +117,7 @@
Not Legal:
-```
+```text
exposes :
[
{
@@ -129,5 +129,4 @@
}
}
]
-
```
diff --git a/docs/my_first_sensors.md b/docs/my_first_sensors.md
index 8e4cfc5..b3558d2 100644
--- a/docs/my_first_sensors.md
+++ b/docs/my_first_sensors.md
@@ -9,7 +9,7 @@
24c02 eeprom and a tmp441 sensor. The PCIe slots are behind an smbus mux on the
motherboard and are in a device-tree such as this:
-```
+```dts
aliases {
i2c16 = &i2c_pe0;
i2c17 = &i2c_pe1;
@@ -56,7 +56,7 @@
Entity-Manager. The exact layout of a FRU is beyond the scope of this guide, but
assume the PCIe card's eeprom holds the following information:
-```
+```text
Product:
MANUFACTURER "Awesome"
PART_NUMBER "12345"
@@ -71,7 +71,7 @@
The dbus tree for this will look like: ```
-```
+```sh
~# busctl tree --no-pager xyz.openbmc_project.FruDevice
`-/xyz
`-/xyz/openbmc_project
@@ -83,7 +83,7 @@
The dbus path for each instance is unimportant beyond needing to be unique.
Digging into one of these FRUs we see:
-```
+```sh
~# busctl introspect --no-pager xyz.openbmc_project.FruDevice \
/xyz/openbmc_project/FruDevice/Super_Great
@@ -121,26 +121,26 @@
We start with a simple hardware profile. We know that if the card's bus is
identified we know the address of the temperature sensor is 0x4c.
-```
+```json
{
- "Exposes": [
- {
- "Address": "$address",
- "Bus": "$bus",
- "Name": "$bus great eeprom",
- "Type": "EEPROM_24C02"
- },
- {
- "Address": "0x4c",
- "Bus": "$bus",
- "Name": "$bus great local",
- "Name1": "$bus great ext",
- "Type": "TMP441"
- }
- ],
- "Name": "$bus Great Card",
- "Probe": "xyz.openbmc_project.FruDevice({'PRODUCT_PRODUCT_NAME': 'Super Great'})",
- "Type": "Board"
+ "Exposes": [
+ {
+ "Address": "$address",
+ "Bus": "$bus",
+ "Name": "$bus great eeprom",
+ "Type": "EEPROM_24C02"
+ },
+ {
+ "Address": "0x4c",
+ "Bus": "$bus",
+ "Name": "$bus great local",
+ "Name1": "$bus great ext",
+ "Type": "TMP441"
+ }
+ ],
+ "Name": "$bus Great Card",
+ "Probe": "xyz.openbmc_project.FruDevice({'PRODUCT_PRODUCT_NAME': 'Super Great'})",
+ "Type": "Board"
}
```
@@ -166,14 +166,14 @@
For the card found on bus 18:
-```
+```sh
echo "24c02 0x50 > /sys/bus/i2c/devices/i2c-18/new_device"
echo "tmp441 0x4c > /sys/bus/i2c/devices/i2c-18/new_device"
```
Beyond this, it also publishes to dbus a configuration:
-```
+```sh
~# busctl tree --no-pager xyz.openbmc_project.EntityManager
`-/xyz
`-/xyz/openbmc_project
@@ -215,7 +215,7 @@
It will look up the device on i2c and see there is a hwmon instance, and map
`temp1_input` to `Name` and since there is also `Name1` it'll map `temp2_input`.
-```
+```sh
~# busctl tree --no-pager xyz.openbmc_project.HwmonTempSensor
`-/xyz
`-/xyz/openbmc_project
diff --git a/schemas/README.md b/schemas/README.md
index 5b4ee81..2d45286 100644
--- a/schemas/README.md
+++ b/schemas/README.md
@@ -1,8 +1,8 @@
-## Entity manager configuration file schema
+# Entity manager configuration file schema
Entity manager configuration files are JSON documents and can be validated with
-a JSON schema[1]. This document provides an overview of the general structure of
-an entity manager configuration file.
+a [JSON schema][1]. This document provides an overview of the general structure
+of an entity manager configuration file.
An entity manager configuration file consists of one or more entity manager
configurations. This provides flexibility for system designers - the
@@ -12,7 +12,7 @@
To remain consistent with the OpenBMC CPP source code file name guidelines,
entity manager configuration file and schema file names must be
-lower_snake_case.
+`lower_snake_case`.
## A single entity manager configuration
@@ -26,16 +26,16 @@
The type property identifies the type of the configuration. When exported,
configuration data will be instantiated as grandchildren of
-/xyz/openbmc_project/inventory/system/<Type>. For a comprehensive list of
+`/xyz/openbmc_project/inventory/system/<Type>`. For a comprehensive list of
supported types, consult the schema (global.json).
## Name
The name property identifies the name of the configuration. When exported,
configuration data will be instantiated as children of
-/xyz/openbmc_project/inventory/system/<Type>/<Name>. Additionally, any DBus
+`/xyz/openbmc_project/inventory/system/<Type>/<Name>`. Additionally, any DBus
interfaces listed in openbmc-dbus.json will be added on
-/xyz/openbmc_project/inventory/system/<Type>/<Name>.
+`/xyz/openbmc_project/inventory/system/<Type>/<Name>`.
## Probe
@@ -52,9 +52,9 @@
since entity manager will construct the Dbus interface name and object path
based on those properties:
-/xyz/openbmc_project/inventory/system/Board/RiserCard1/<Name>:
-xyz.openbmc_project.Configuration.<Type>:
-<remaining properties defined by exposes subschema>
+`/xyz/openbmc_project/inventory/system/Board/RiserCard1/<Name>`:
+`xyz.openbmc_project.Configuration.<Type>`:
+`<remaining properties defined by exposes subschema>`
## Adding new exposes property subschema
@@ -70,4 +70,4 @@
/xyz/openbmc_project/inventory/system/Board/RiserCard1 add additional subschema
to openbmc-dbus.json.
-[1] https://json-schema.org/
+[1]: https://json-schema.org/