[PATCH 2/3] doc: fix the warnings when building the doc

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

It seems that Markdown is now parsed slightly differently and
now generate some warnings.

So tweak the .md files to shut up the warnings.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
 Documentation/TODO.md              |  6 +++++-
 Documentation/nocast-vs-bitwise.md | 34 ++++++++++++++++--------------
 2 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/Documentation/TODO.md b/Documentation/TODO.md
index cbda1c397e46..31826df33aae 100644
--- a/Documentation/TODO.md
+++ b/Documentation/TODO.md
@@ -32,7 +32,7 @@ Core
   ```
 
 Testsuite
---------
+---------
 * there are more than 50 failing tests. They should be fixed
   (but most are non-trivial to fix).
 
@@ -84,9 +84,13 @@ Longer term/to investigate
 * should support "-Werror=..." ?
 * All warning messages should include the option how to disable it.
   For example:
+
   	"warning: Variable length array is used."
+
   should be something like:
+
 	"warning: Variable length array is used. (-Wno-vla)"
+
 * ptrlists must have elements be removed while being iterated but this
   is hard to insure it is not done.
 * having 'struct symbol' used to represent symbols *and* types is
diff --git a/Documentation/nocast-vs-bitwise.md b/Documentation/nocast-vs-bitwise.md
index b649abcd5947..9ba5a789fc26 100644
--- a/Documentation/nocast-vs-bitwise.md
+++ b/Documentation/nocast-vs-bitwise.md
@@ -1,4 +1,5 @@
-# __nocast vs __bitwise
+__nocast vs __bitwise
+=====================
 
 `__nocast` warns about explicit or implicit casting to different types.
 HOWEVER, it doesn't consider two 32-bit integers to be different
@@ -16,25 +17,26 @@ harder to lose the type by mistake.
 
 So the basic rule is:
 
- - `__nocast` on its own tends to be more useful for *big* integers
-that still need to act like integers, but you want to make it much
-less likely that they get truncated by mistake. So a 64-bit integer
-that you don't want to mistakenly/silently be returned as `int`, for
-example. But they mix well with random integer types, so you can add
-to them etc without using anything special. However, that mixing also
-means that the `__nocast` really gets lost fairly easily.
-
- - `__bitwise` is for *unique types* that cannot be mixed with other
-types, and that you'd never want to just use as a random integer (the
-integer `0` is special, though, and gets silently accepted - it's
-kind of like `NULL` for pointers). So `gfp_t` or the `safe endianness`
-types would be `__bitwise`: you can only operate on them by doing
-specific operations that know about *that* particular type.
+- `__nocast` on its own tends to be more useful for *big* integers
+  that still need to act like integers, but you want to make it much
+  less likely that they get truncated by mistake. So a 64-bit integer
+  that you don't want to mistakenly/silently be returned as `int`, for
+  example. But they mix well with random integer types, so you can add
+  to them etc without using anything special. However, that mixing also
+  means that the `__nocast` really gets lost fairly easily.
+
+- `__bitwise` is for *unique types* that cannot be mixed with other
+  types, and that you'd never want to just use as a random integer (the
+  integer `0` is special, though, and gets silently accepted - it's
+  kind of like `NULL` for pointers). So `gfp_t` or the `safe endianness`
+  types would be `__bitwise`: you can only operate on them by doing
+  specific operations that know about *that* particular type.
 
 Generally, you want `__bitwise` if you are looking for type safety.
 `__nocast` really is pretty weak.
 
-## Reference:
+Reference:
+----------
 
 * Linus' e-mail about `__nocast` vs `__bitwise`:
 
-- 
2.26.2