[PATCH 2/2] Documentation/filesystems: pstore: fix formatting

[Sascha Hauer]

On Mon, Feb 29, 2016 at 03:39:52PM +0100, yegorslists at googlemail.com wrote:
> From: Yegor Yefremov <yegorslists at googlemail.com>
> 
> Signed-off-by: Yegor Yefremov <yegorslists at googlemail.com>
> ---
>  Documentation/filesystems/pstore.rst | 51 ++++++++++++++++++------------------
>  1 file changed, 26 insertions(+), 25 deletions(-)
> 
> diff --git a/Documentation/filesystems/pstore.rst b/Documentation/filesystems/pstore.rst
> index 74acd87..a8079c2 100644
> --- a/Documentation/filesystems/pstore.rst
> +++ b/Documentation/filesystems/pstore.rst
> @@ -12,6 +12,7 @@ messages are stored by the kernel in a specified RAM area which is never
>  overwritten by any user. This data can be accessed after a reboot through
>  /pstore in Barebox or the kernel. The pstore filesystem is automatically mounted
>  at boot::
> +
>  	none on / type ramfs
>  	none on /dev type devfs
>  	none on /pstore type pstore
> @@ -40,35 +41,35 @@ and RAM backend support. The kernel receives the parameters describing the
>  layout over the kernel command line. These parameters are automatically
>  generated by Barebox. You can change these parameters in Barebox menuconfig. The
>  RAMOOPS parameters for the Kernel are stored in the variable
> -global.linux.bootargs.ramoops::
> +global.linux.bootargs.ramoops.
>  
>  To see where the RAMOOPS area is located, you can execute iomem in Barebox. The
>  RAMOOPS area is listed as 'persistent ram'::
>  
> -  0x10000000 - 0x1fffffff (size 0x10000000) ram0
> -    0x17e7c0c0 - 0x1fcf817f (size 0x07e7c0c0) malloc space
> -    0x1fcf8180 - 0x1fcfffff (size 0x00007e80) board data
> -    0x1fd00000 - 0x1fd6eeff (size 0x0006ef00) barebox
> -    0x1fd6ef00 - 0x1fd88dff (size 0x00019f00) barebox data
> -    0x1fd88e00 - 0x1fd8c3db (size 0x000035dc) bss
> -    0x1fdf4000 - 0x1fe13fff (size 0x00020000) persistent ram
> -    0x1fe14000 - 0x1fe33fff (size 0x00020000) persistent ram
> -    0x1fe34000 - 0x1fe53fff (size 0x00020000) persistent ram
> -    0x1fe54000 - 0x1fe73fff (size 0x00020000) persistent ram
> -    0x1fe74000 - 0x1fe93fff (size 0x00020000) persistent ram
> -    0x1fe94000 - 0x1feb3fff (size 0x00020000) persistent ram
> -    0x1feb4000 - 0x1fed3fff (size 0x00020000) persistent ram
> -    0x1fed4000 - 0x1fef3fff (size 0x00020000) persistent ram
> -    0x1fef4000 - 0x1ff13fff (size 0x00020000) persistent ram
> -    0x1ff14000 - 0x1ff33fff (size 0x00020000) persistent ram
> -    0x1ff34000 - 0x1ff53fff (size 0x00020000) persistent ram
> -    0x1ff54000 - 0x1ff73fff (size 0x00020000) persistent ram
> -    0x1ff74000 - 0x1ff93fff (size 0x00020000) persistent ram
> -    0x1ff94000 - 0x1ffb3fff (size 0x00020000) persistent ram
> -    0x1ffb4000 - 0x1ffd3fff (size 0x00020000) persistent ram
> -    0x1ffd4000 - 0x1fff3fff (size 0x00020000) persistent ram
> -    0x1fff4000 - 0x1fff7fff (size 0x00004000) ttb
> -    0x1fff8000 - 0x1fffffff (size 0x00008000) stack
> +        0x10000000 - 0x1fffffff (size 0x10000000) ram0
> +        0x17e7c0c0 - 0x1fcf817f (size 0x07e7c0c0) malloc space

It was intentional the the first line has a different indention. It's
from the original 'iomem' output.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |