Remove closing header

No need to have closing #s to close a header.
https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers
Looking online, headers only start with #s.

Change-Id: Ib048367ea1483103822962dd5bfacc9d019944ae
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>

2 files changed, 16 insertions, 16 deletions

diff --git a/sensor-architecture.md b/sensor-architecture.md
index b640605..50d919b 100644
--- a/sensor-architecture.md
+++ b/sensor-architecture.md
@@ -1,4 +1,4 @@
-# Sensor Support for OpenBMC #
+# Sensor Support for OpenBMC
 OpenBMC makes it easy to add sensors for your hardware and is compliant with
 the traditional Linux HWMon sensor format.  The architecture of OpenBMC
 sensors is to map sensors to [D-Bus][1]
@@ -6,7 +6,7 @@ objects.  The D-Bus object will broadcast the `PropertiesChanged` signal when ei
 the sensor or threshold value changes. It is the responsibility of other
 applications to determine the effect of the signal on the system.
 
-## D-Bus ##
+## D-Bus
 
 ```
 Service     xyz.openbmc_project.Hwmon-<hash>.Hwmon1
@@ -33,7 +33,7 @@ The hash value in the service name is used to give the service a unique
 and stable name.  It is a decimal number that is obtained by hashing
 characteristics of the device it is monitoring using std::hash().
 
-## Development Details ##
+## Development Details
 
 Sensor properties are standardized based on the type of sensor.  A Threshold
 sensor contains specific properties associated with the rise and fall of a
@@ -81,7 +81,7 @@ busctl --system introspect xyz.openbmc_project.Hwmon-3301914901.Hwmon1 \
 
 ```
 
-### REST ###
+### REST
 
 ```
 "/xyz/openbmc_project/Sensors/temperature/ambient": {
@@ -95,7 +95,7 @@ busctl --system introspect xyz.openbmc_project.Hwmon-3301914901.Hwmon1 \
 }
 ```
 
-### Other Interfaces ###
+### Other Interfaces
 
 Aside from the `xyz.openbmc_project.Sensor` interfaces, the sensor D-Bus objects
 may also expose the following interfaces:
@@ -107,7 +107,7 @@ may also expose the following interfaces:
 3.  `xyz.openbmc_project.State.Decorator.OperationalStatus`
     - Provides a Functional property that tracks the state of any fault files
 
-### Signals ###
+### Signals
 
 Any property value change broadcasts a signal on D-Bus.  When a value trips
 past a threshold, an additional D-Bus signal is sent.
@@ -122,20 +122,20 @@ Example, if the value of WarningLow is 5...
 | 6 | 1 | "xyz.openbmc\_project.Sensor.Value" : value = 1 ,<br>"xyz.openbmc\_project.Sensor.Threshold.Warning" : WarningAlarmLow = 1 |
 
 
-### System Configuration ###
+### System Configuration
 
 On the BMC each sensor's configuration is located in a file.  These files
 can be found as a child of the `/etc/default/obmc/hwmon` path.
 
 
-## Creating a Sensor ##
+## Creating a Sensor
 
 There are two techniques to add a sensor to your system and which to use
 depends on if your system defines sensors via an MRW (Machine Readable
 Workbook) or not.
 
 
-### My sensors are not defined in an MRW ###
+### My sensors are not defined in an MRW
 
 HWMon sensors are defined in the `recipes-phosphor/sensor/phosphor-hwmon%`
 path within the [machine configuration][7].
@@ -223,7 +223,7 @@ WARNLO_temp2=10000
 WARNHI_temp2=80000
 ```
 
-#### Additional Config File Entries ####
+#### Additional Config File Entries
 The phosphor-hwmon code supports these additional config file entries:
 
 **INTERVAL**
@@ -304,7 +304,7 @@ Will write a value to a pwmN\_enable file on startup if present.
 ENABLE_fan1 = 2 #Write a 2 to pwm1_enable
 ```
 
-### My sensors are defined in an MRW ###
+### My sensors are defined in an MRW
 
 Setting up sensor support with an MRW is done by adding a unit-hwmon-feature
 unit, for each hwmon feature needing to be monitored and then filling in the
@@ -346,7 +346,7 @@ added.  The instance path will be `/xyz/openbmc_project/Sensors/fan/fan0`.
 ```
 
 
-## Additional Reading ##
+## Additional Reading
 Mailing List [Comments on Sensor design][9]
 
 
diff --git a/yocto-development.md b/yocto-development.md
index cc89483..e6e5af7 100644
--- a/yocto-development.md
+++ b/yocto-development.md
@@ -1,4 +1,4 @@
-# Yocto in OpenBMC #
+# Yocto in OpenBMC
 
 The Yocto Project is an open source collaboration project that provides
 templates, tools and methods to help you create custom Linux-based systems for
@@ -7,7 +7,7 @@ embedded products regardless of the hardware architecture.
 OpenBMC uses the Yocto tools to manage configuration and creation of BMC
 images.
 
-## Developing with Yocto ##
+## Developing with Yocto
 
 There are two main use-cases for Yocto in OpenBMC:
 
@@ -47,7 +47,7 @@ from the devtool Yocto layer.
 Further information on [devtool][0] can be found in the [Yocto Mega Manual][1].
 
 
-### Adding a file to your image ###
+### Adding a file to your image
 
 There are a lot of examples of working with BitBake out there.  The [recipe
 example](http://docs.openembedded.org/usermanual/html/recipes_examples.html)
@@ -94,7 +94,7 @@ That's it, recompile and boot your system, the binary `hello` will be in
 `/usr/bin` and the `README.md` will be in `/usr/shared/doc/welcome`.
 
 
-### Know what your image has ###
+### Know what your image has
 
 Sure you could flash and boot your system to see if your file made it, but there
 is a faster way.  The `rootfs` directory down in the depths of the `build/tmp`