Coding Style cleanup: replace leading SPACEs by TABs

Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Drop changes for PEP 4 following python tools]
Signed-off-by: Tom Rini <trini@ti.com>

21 files changed, 135 insertions, 135 deletions

diff --git a/doc/DocBook/Makefile b/doc/DocBook/Makefile
index 521e8bc0e9..29b79d7cd1 100644
--- a/doc/DocBook/Makefile
+++ b/doc/DocBook/Makefile
@@ -134,7 +134,7 @@ build_main_index = rm -rf $(main_idx); \
 quiet_cmd_db2html = HTML    $@
       cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
 		echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
-        $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
+	$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
 
 %.html:	%.xml
 	@(which xmlto > /dev/null 2>&1) || \
@@ -143,7 +143,7 @@ quiet_cmd_db2html = HTML    $@
 	@rm -rf $@ $(patsubst %.html,%,$@)
 	$(call cmd_db2html)
 	@if [ ! -z "$(PNG-$(basename $(notdir $@)))" ]; then \
-            cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
+	    cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
 
 quiet_cmd_db2man = MAN     $@
       cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi
diff --git a/doc/README.ext4 b/doc/README.ext4
index b7d0ad3930..9a2de5088b 100644
--- a/doc/README.ext4
+++ b/doc/README.ext4
@@ -28,30 +28,30 @@ Steps to test:
 
 1. After applying the patch, ext4 specific commands can be seen
    in the boot loader prompt using
-        UBOOT #help
+	UBOOT #help
 
-        ext4load- load binary file from a Ext4 file system
-        ext4ls  - list files in a directory (default /)
-        ext4write- create a file in ext4 formatted partition
+	ext4load- load binary file from a Ext4 file system
+	ext4ls  - list files in a directory (default /)
+	ext4write- create a file in ext4 formatted partition
 
 2. To list the files in ext4 formatted partition, execute
-        ext4ls <interface> <dev[:part]> [directory]
-        For example:
-        UBOOT #ext4ls mmc 0:5 /usr/lib
+	ext4ls <interface> <dev[:part]> [directory]
+	For example:
+	UBOOT #ext4ls mmc 0:5 /usr/lib
 
 3. To read and load a file from an ext4 formatted partition to RAM, execute
-        ext4load <interface> <dev[:part]> [addr] [filename] [bytes]
-        For example:
-        UBOOT #ext4load mmc 2:2 0x30007fc0 uImage
+	ext4load <interface> <dev[:part]> [addr] [filename] [bytes]
+	For example:
+	UBOOT #ext4load mmc 2:2 0x30007fc0 uImage
 
 4. To write a file to a ext4 formatted partition.
-        a) First load a file to RAM at a particular address for example 0x30007fc0.
-        Now execute ext4write command
-        ext4write <interface> <dev[:part]> [filename] [Address] [sizebytes]
-        For example:
-        UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120
-        (here 6183120 is the size of the file to be written)
-        Note: Absolute path is required for the file to be written
+	a) First load a file to RAM at a particular address for example 0x30007fc0.
+	Now execute ext4write command
+	ext4write <interface> <dev[:part]> [filename] [Address] [sizebytes]
+	For example:
+	UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120
+	(here 6183120 is the size of the file to be written)
+	Note: Absolute path is required for the file to be written
 
 References :
 	-- ext4 implementation in Linux Kernel
diff --git a/doc/README.kwbimage b/doc/README.kwbimage
index e91c387b51..8ed708c356 100644
--- a/doc/README.kwbimage
+++ b/doc/README.kwbimage
@@ -40,9 +40,9 @@ Board specific configuration file specifications:
 ------------------------------------------------
 1. This file must present in the $(BOARDDIR).  The default name is
 	kwbimage.cfg.  The name can be set as part of the full path
-        to the file using CONFIG_SYS_KWD_CONFIG (probably in
-        include/configs/<yourboard>.h).   The path should look like:
-        $(SRCTREE)/$(CONFIG_BOARDDIR)/<yourkwbimagename>.cfg
+	to the file using CONFIG_SYS_KWD_CONFIG (probably in
+	include/configs/<yourboard>.h).   The path should look like:
+	$(SRCTREE)/$(CONFIG_BOARDDIR)/<yourkwbimagename>.cfg
 2. This file can have empty lines and lines starting with "#" as first
 	character to put comments
 3. This file can have configuration command lines as mentioned below,
diff --git a/doc/README.mxc_hab b/doc/README.mxc_hab
index 97f8b7d743..43e64a2797 100644
--- a/doc/README.mxc_hab
+++ b/doc/README.mxc_hab
@@ -20,7 +20,7 @@ Data Size:    327680 Bytes = 320.00 kB = 0.31 MB
 Load Address: 177ff420
 Entry Point:  17800000
 HAB Blocks:   177ff400 00000000 0004dc00
-              ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
+	      ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
 		|	|	   |
 		|	|	   -------- (1)
 		|	|
diff --git a/doc/README.mxsimage b/doc/README.mxsimage
index 88a2caf3e6..0d31cba1fb 100644
--- a/doc/README.mxsimage
+++ b/doc/README.mxsimage
@@ -10,7 +10,7 @@ The mxsimage tool is targeted to be a simple replacement for the elftosb2 .
 To generate an image, write an image configuration file and run:
 
  mkimage -A arm -O u-boot -T mxsimage -n <path to configuration file> \
-         <output bootstream file>
+	 <output bootstream file>
 
 The output bootstream file is usually using the .sb file extension. Note
 that the example configuration files for producing bootable BootStream with
@@ -54,33 +54,33 @@ These semantics and rules will be outlined now.
 
       LOAD     u32_address string_filename
       - Instructs the BootROM to load file pointed by "string_filename" onto
-        address "u32_address".
+	address "u32_address".
 
       LOAD IVT u32_address u32_IVT_entry_point
       - Crafts and loads IVT onto address "u32_address" with the entry point
-        of u32_IVT_entry_point.
+	of u32_IVT_entry_point.
       - i.MX28-specific instruction!
 
       LOAD DCD u32_address u32_DCD_block_ID
       - Loads the DCD block with ID "u32_DCD_block_ID" onto address
-        "u32_address" and executes the contents of this DCD block
+	"u32_address" and executes the contents of this DCD block
       - i.MX28-specific instruction!
 
       FILL u32_address u32_pattern u32_length
       - Starts to write memory from addres "u32_address" with a pattern
-        specified by "u32_pattern". Writes exactly "u32_length" bytes of the
+	specified by "u32_pattern". Writes exactly "u32_length" bytes of the
 	pattern.
 
       JUMP [HAB] u32_address [u32_r0_arg]
       - Jumps onto memory address specified by "u32_address" by setting this
-        address in PT. The BootROM will pass the "u32_r0_arg" value in ARM
+	address in PT. The BootROM will pass the "u32_r0_arg" value in ARM
 	register "r0" to the executed code if this option is specified.
 	Otherwise, ARM register "r0" will default to value 0x00000000. The
 	optional "HAB" flag is i.MX28-specific flag turning on the HAB boot.
 
       CALL [HAB] u32_address [u32_r0_arg]
       - See JUMP instruction above, as the operation is exactly the same with
-        one difference. The CALL instruction does allow returning into the
+	one difference. The CALL instruction does allow returning into the
 	BootROM from the executed code. U-Boot makes use of this in it's SPL
 	code.
 
@@ -88,10 +88,10 @@ These semantics and rules will be outlined now.
       - Restart the CPU and start booting from device specified by the
 	"string_mode" argument. The "string_mode" differs for each CPU
 	and can be:
-         i.MX23, string_mode = USB/I2C/SPI1_FLASH/SPI2_FLASH/NAND_BCH
-                               JTAG/SPI3_EEPROM/SD_SSP0/SD_SSP1
-         i.MX28, string_mode = USB/I2C/SPI2_FLASH/SPI3_FLASH/NAND_BCH
-                               JTAG/SPI2_EEPROM/SD_SSP0/SD_SSP1
+	 i.MX23, string_mode = USB/I2C/SPI1_FLASH/SPI2_FLASH/NAND_BCH
+			       JTAG/SPI3_EEPROM/SD_SSP0/SD_SSP1
+	 i.MX28, string_mode = USB/I2C/SPI2_FLASH/SPI3_FLASH/NAND_BCH
+			       JTAG/SPI2_EEPROM/SD_SSP0/SD_SSP1
 
   - An optional "DCD" blocks can be added at the begining of the configuration
     file. Note that the DCD is only supported on i.MX28.
@@ -99,7 +99,7 @@ These semantics and rules will be outlined now.
       configuration file.
     - The DCD block has the following semantics:
 
-        DCD u32_DCD_block_ID
+	DCD u32_DCD_block_ID
 	- u32_DCD_block_ID	:: The ID number of the DCD block, must match
 				   the ID number used by "LOAD DCD" instruction.
 
diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51
index a8fdfcd372..586ed7c1cc 100644
--- a/doc/README.nokia_rx51
+++ b/doc/README.nokia_rx51
@@ -62,7 +62,7 @@ Available additional commands/variables:
  * run trymmcscriptboot - Try to load and boot script ${mmcscriptfile}
  * run trymmckernboot - Try to load and boot kernel image ${mmckernfile}
  * run trymmckerninitrdboot - Try to load and boot kernel image ${mmckernfile}
-                              with initrd image ${mmcinitrdfile}
+			      with initrd image ${mmcinitrdfile}
 
 Additional variables for loading files from mmc:
 
diff --git a/doc/README.ramboot-ppc85xx b/doc/README.ramboot-ppc85xx
index 8ed45fb46d..5cc546a36f 100644
--- a/doc/README.ramboot-ppc85xx
+++ b/doc/README.ramboot-ppc85xx
@@ -23,11 +23,11 @@ methods could be handy.
    the board.And then execute the bootloader from DDR.
    Some usecases where this may be used:
       - While developing some new feature of u-boot, for example USB driver or
-        SPI driver.
-        Suppose the board already has a working bootloader on it. And you would
-        prefer to keep it intact, at the same time want to test your bootloader.
-        In this case you can get your test bootloader binary into DDR via tftp
-        for example. Then execute the test bootloader.
+	SPI driver.
+	Suppose the board already has a working bootloader on it. And you would
+	prefer to keep it intact, at the same time want to test your bootloader.
+	In this case you can get your test bootloader binary into DDR via tftp
+	for example. Then execute the test bootloader.
      - Suppose a platform already has a propreitery bootloader which does not
        support for example AMP boot. In this case also RAM boot loader can be
        utilized.
diff --git a/doc/README.trace b/doc/README.trace
index 8106290ed9..f0c9699773 100644
--- a/doc/README.trace
+++ b/doc/README.trace
@@ -63,20 +63,20 @@ In:    serial
 Out:   serial
 Err:   serial
 =>trace stats
-        671,406 function sites
-         69,712 function calls
-              0 untracked function calls
-         73,373 traced function calls
-             16 maximum observed call depth
-             15 call depth limit
-         66,491 calls not traced due to depth
+	671,406 function sites
+	 69,712 function calls
+	      0 untracked function calls
+	 73,373 traced function calls
+	     16 maximum observed call depth
+	     15 call depth limit
+	 66,491 calls not traced due to depth
 =>trace stats
-        671,406 function sites
+	671,406 function sites
       1,279,450 function calls
-              0 untracked function calls
-        950,490 traced function calls (333217 dropped due to overflow)
-             16 maximum observed call depth
-             15 call depth limit
+	      0 untracked function calls
+	950,490 traced function calls (333217 dropped due to overflow)
+	     16 maximum observed call depth
+	     15 call depth limit
       1,275,767 calls not traced due to depth
 =>trace calls 0 e00000
 Call list dumped to 00000000, size 0xae0a40
diff --git a/doc/README.ubi b/doc/README.ubi
index d82c75c848..9efab6cdc9 100644
--- a/doc/README.ubi
+++ b/doc/README.ubi
@@ -188,8 +188,8 @@ ubifsls [directory]
 For example:
 
 => ubifsls
-            17442  Thu Jan 01 02:57:38 1970  imx28-evk.dtb
-          2998146  Thu Jan 01 02:57:43 1970  zImage
+	    17442  Thu Jan 01 02:57:38 1970  imx28-evk.dtb
+	  2998146  Thu Jan 01 02:57:43 1970  zImage
 
 
 And the ubifsload command allows you to load a file from a UBI
diff --git a/doc/README.zfs b/doc/README.zfs
index f5998f2f88..7f237c4076 100644
--- a/doc/README.zfs
+++ b/doc/README.zfs
@@ -7,20 +7,20 @@ Steps to test:
 
 1. After applying the patch, zfs specific commands can be seen
    in the boot loader prompt using
-        UBOOT #help
+	UBOOT #help
 
-        zfsload- load binary file from a ZFS file system
-        zfsls  - list files in a directory (default /)
+	zfsload- load binary file from a ZFS file system
+	zfsls  - list files in a directory (default /)
 
 2. To list the files in zfs pool, device or partition, execute
-        zfsls <interface> <dev[:part]> [POOL/@/dir/file]
-        For example:
-        UBOOT #zfsls mmc 0:5 /rpool/@/usr/bin/
+	zfsls <interface> <dev[:part]> [POOL/@/dir/file]
+	For example:
+	UBOOT #zfsls mmc 0:5 /rpool/@/usr/bin/
 
 3. To read and load a file from an ZFS formatted partition to RAM, execute
-        zfsload <interface> <dev[:part]> [addr] [filename] [bytes]
-        For example:
-        UBOOT #zfsload mmc 2:2 0x30007fc0 /rpool/@/boot/uImage
+	zfsload <interface> <dev[:part]> [addr] [filename] [bytes]
+	For example:
+	UBOOT #zfsload mmc 2:2 0x30007fc0 /rpool/@/boot/uImage
 
 References :
 	-- ZFS GRUB sources from Solaris GRUB-0.97
diff --git a/doc/driver-model/UDM-cores.txt b/doc/driver-model/UDM-cores.txt
index 4e1318871a..60323335b8 100644
--- a/doc/driver-model/UDM-cores.txt
+++ b/doc/driver-model/UDM-cores.txt
@@ -94,12 +94,12 @@ Pavel Herrmann <morpheus.ibis@gmail.com>
     driver_activate(instance *inst);
       This call will recursively activate all devices necessary for using the
       specified device. the code could be simplified as:
-        {
-        if (is_activated(inst))
-          return;
-        driver_activate(inst->bus);
-        get_driver(inst)->probe(inst);
-        }
+	{
+	if (is_activated(inst))
+	  return;
+	driver_activate(inst->bus);
+	get_driver(inst)->probe(inst);
+	}
 
       The case with multiple parents will need to be handled here as well.
       get_driver is an accessor to available drivers, which will get struct
@@ -107,12 +107,12 @@ Pavel Herrmann <morpheus.ibis@gmail.com>
 
     i2c_write(instance *inst, ...);
       An actual call to some method of the driver. This code will look like:
-        {
-        driver_activate(inst);
-        struct instance *core = get_core_instance(CORE_I2C);
-        device_ops = get_ops(inst);
-        device_ops->write(...);
-        }
+	{
+	driver_activate(inst);
+	struct instance *core = get_core_instance(CORE_I2C);
+	device_ops = get_ops(inst);
+	device_ops->write(...);
+	}
 
       get_ops will not be an exported function, it will be internal and specific
       to the core, as it needs to know how are the ops stored, and what type
diff --git a/doc/driver-model/UDM-design.txt b/doc/driver-model/UDM-design.txt
index 185f477b06..9f03bbaad3 100644
--- a/doc/driver-model/UDM-design.txt
+++ b/doc/driver-model/UDM-design.txt
@@ -87,7 +87,7 @@ III) The drivers
   of the cores.
 
   FIXME: Should *cores[] be really struct driver, pointing to drivers that
-         represent the cores? Shouldn't it be core instance pointer?
+	 represent the cores? Shouldn't it be core instance pointer?
 
   2) Instantiation of a driver
   ----------------------------
@@ -101,7 +101,7 @@ III) The drivers
   functions.
 
   FIXME: We need some functions that will return list of busses of certain type
-         registered with the system so the user can find proper instance even if
+	 registered with the system so the user can find proper instance even if
 	 he has no bus pointer (this will come handy if the user isn't
 	 registering the driver from board init function, but somewhere else).
 
@@ -183,12 +183,12 @@ III) The drivers
   int driver_bind(struct instance *in)
   {
 	...
-        core_bind(&core_i2c_static_instance, in, i2c_bus_funcs);
-        ...
+	core_bind(&core_i2c_static_instance, in, i2c_bus_funcs);
+	...
   }
 
   FIXME: What if we need to run-time determine, depending on some hardware
-         register, what kind of i2c_bus_funcs to pass?
+	 register, what kind of i2c_bus_funcs to pass?
 
   This makes the i2c core aware of a new bus. The i2c_bus_funcs is a constant
   structure of functions any i2c bus driver must provide to work. This will
@@ -196,7 +196,7 @@ III) The drivers
   the pointer to the instance of a core this driver provides function to.
 
   FIXME: Maybe replace "core-i2c" with CORE_I2C global pointer to an instance of
-         the core?
+	 the core?
 
   4) The instantiation of a core driver
   -------------------------------------
diff --git a/doc/driver-model/UDM-gpio.txt b/doc/driver-model/UDM-gpio.txt
index 8ff0a965c7..87554dde68 100644
--- a/doc/driver-model/UDM-gpio.txt
+++ b/doc/driver-model/UDM-gpio.txt
@@ -56,11 +56,11 @@ II) Approach
 
   struct gpio_driver_ops {
     int  (*gpio_request)(struct instance *i, unsigned gpio,
-                         const char *label);
+			 const char *label);
     int  (*gpio_free)(struct instance *i, unsigned gpio);
     int  (*gpio_direction_input)(struct instance *i, unsigned gpio);
     int  (*gpio_direction_output)(struct instance *i, unsigned gpio,
-                                  int value);
+				  int value);
     int  (*gpio_get_value)(struct instance *i, unsigned gpio);
     void (*gpio_set_value)(struct instance *i, unsigned gpio, int value);
   }
diff --git a/doc/driver-model/UDM-hwmon.txt b/doc/driver-model/UDM-hwmon.txt
index cc5d529c3b..9048cc0f00 100644
--- a/doc/driver-model/UDM-hwmon.txt
+++ b/doc/driver-model/UDM-hwmon.txt
@@ -36,15 +36,15 @@ II) Approach
   In the UDM each hwmon driver would register itself by a function
 
     int hwmon_device_register(struct instance *i,
-                              struct hwmon_device_ops *o);
+			      struct hwmon_device_ops *o);
 
   The structure being defined as follows:
 
     struct hwmon_device_ops {
-        int  (*read)(struct instance *i, int sensor, int reg);
-        int  (*write)(struct instance *i, int sensor, int reg,
-                      int val);
-        int  (*get_temp)(struct instance *i, int sensor);
+	int  (*read)(struct instance *i, int sensor, int reg);
+	int  (*write)(struct instance *i, int sensor, int reg,
+		      int val);
+	int  (*get_temp)(struct instance *i, int sensor);
     };
 
 
diff --git a/doc/driver-model/UDM-mmc.txt b/doc/driver-model/UDM-mmc.txt
index bed430643b..1f07d874ea 100644
--- a/doc/driver-model/UDM-mmc.txt
+++ b/doc/driver-model/UDM-mmc.txt
@@ -107,7 +107,7 @@ struct mmc {
 
   /* DRIVER: Function used to submit command to the card */
   int (*send_cmd)(struct mmc *mmc,
-                  struct mmc_cmd *cmd, struct mmc_data *data);
+		  struct mmc_cmd *cmd, struct mmc_data *data);
 
   /* DRIVER: Function used to configure the host */
   void (*set_ios)(struct mmc *mmc);
@@ -139,7 +139,7 @@ provided by the MMC driver:
 struct mmc_driver_ops {
   /* Function used to submit command to the card */
   int  (*send_cmd)(struct mmc *mmc,
-                  struct mmc_cmd *cmd, struct mmc_data *data);
+		  struct mmc_cmd *cmd, struct mmc_data *data);
   /* DRIVER: Function used to configure the host */
   void (*set_ios)(struct mmc *mmc);
   /* Function used to initialize the host */
@@ -206,7 +206,7 @@ struct mmc_card_props {
 The probe() function will then register the MMC driver by calling:
 
   mmc_device_register(struct instance *i, struct mmc_driver_ops *o,
-                                          struct mmc_driver_params *p);
+					  struct mmc_driver_params *p);
 
 The struct mmc_driver_params will have to be dynamic in some cases, but the
 driver shouldn't modify it's contents elsewhere than in probe() call.
diff --git a/doc/driver-model/UDM-power.txt b/doc/driver-model/UDM-power.txt
index 9ac1a5fbb5..015c7737f6 100644
--- a/doc/driver-model/UDM-power.txt
+++ b/doc/driver-model/UDM-power.txt
@@ -57,20 +57,20 @@ III) Analysis of in-tree drivers
   All methods of this file are moved to another location.
     void ftpmu010_32768osc_enable(void): Move to boards hacks
     void ftpmu010_mfpsr_select_dev(unsigned int dev): Move to board file
-                                                      arch/nds32/lib/board.c
+						      arch/nds32/lib/board.c
     void ftpmu010_mfpsr_diselect_dev(unsigned int dev): Dead code
     void ftpmu010_dlldis_disable(void): Dead code
     void ftpmu010_sdram_clk_disable(unsigned int cr0): Move to board file
-                                                       arch/nds32/lib/board.c
+						       arch/nds32/lib/board.c
     void ftpmu010_sdramhtc_set(unsigned int val): Move to board file
-                                                  arch/nds32/lib/board.c
+						  arch/nds32/lib/board.c
 
   2) twl4030.c
   ------------
   All methods of this file are moved to another location.
     void twl4030_power_reset_init(void): Move to board hacks
     void twl4030_pmrecv_vsel_cfg(u8 vsel_reg, u8 vsel_val, u8 dev_grp,
-                                 u8 dev_grp_sel): Move to board hacks
+				 u8 dev_grp_sel): Move to board hacks
     void twl4030_power_init(void): Move to board hacks
     void twl4030_power_mmc_init(void): Move to board hacks
 
@@ -83,6 +83,6 @@ III) Analysis of in-tree drivers
     int twl6030_get_battery_voltage(void): Convert to new API
     void twl6030_init_battery_charging(void): Convert to new API
     void twl6030_power_mmc_init(): Move to board file
-                                   drivers/mmc/omap_hsmmc.c
+				   drivers/mmc/omap_hsmmc.c
     void twl6030_usb_device_settings(): Move to board file
-                                        drivers/usb/musb/omap3.c
+					drivers/usb/musb/omap3.c
diff --git a/doc/driver-model/UDM-rtc.txt b/doc/driver-model/UDM-rtc.txt
index 6aaeb86f27..8391f38723 100644
--- a/doc/driver-model/UDM-rtc.txt
+++ b/doc/driver-model/UDM-rtc.txt
@@ -12,15 +12,15 @@ U-Boot currently implements one common API for RTC devices. The interface
 is defined in include/rtc.h and comprises of functions and structures:
 
     struct rtc_time {
-        int tm_sec;
-        int tm_min;
-        int tm_hour;
-        int tm_mday;
-        int tm_mon;
-        int tm_year;
-        int tm_wday;
-        int tm_yday;
-        int tm_isdst;
+	int tm_sec;
+	int tm_min;
+	int tm_hour;
+	int tm_mday;
+	int tm_mon;
+	int tm_year;
+	int tm_wday;
+	int tm_yday;
+	int tm_isdst;
     };
 
     int rtc_get (struct rtc_time *);
@@ -42,14 +42,14 @@ II) Approach
   In the UDM each rtc driver would register itself by a function
 
     int rtc_device_register(struct instance *i,
-                            struct rtc_device_ops *o);
+			    struct rtc_device_ops *o);
 
   The structure being defined as follows:
 
     struct rtc_device_ops {
-        int  (*get_time)(struct instance *i, struct rtc_time *t);
-        int  (*set_time)(struct instance *i, struct rtc_time *t);
-        int  (*reset)(struct instance *i);
+	int  (*get_time)(struct instance *i, struct rtc_time *t);
+	int  (*set_time)(struct instance *i, struct rtc_time *t);
+	int  (*reset)(struct instance *i);
     };
 
 
diff --git a/doc/driver-model/UDM-spi.txt b/doc/driver-model/UDM-spi.txt
index 7442a32bd0..6e6acc8787 100644
--- a/doc/driver-model/UDM-spi.txt
+++ b/doc/driver-model/UDM-spi.txt
@@ -15,12 +15,12 @@ I) Overview
 
   void spi_init(void);
   struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
-                                    unsigned int max_hz, unsigned int mode);
+				    unsigned int max_hz, unsigned int mode);
   void spi_free_slave(struct spi_slave *slave);
   int  spi_claim_bus(struct spi_slave *slave);
   void spi_release_bus(struct spi_slave *slave);
   int  spi_xfer(struct spi_slave *slave, unsigned int bitlen,
-                const void *dout, void *din, unsigned long flags);
+		const void *dout, void *din, unsigned long flags);
   int  spi_cs_is_valid(unsigned int bus, unsigned int cs);
   void spi_cs_activate(struct spi_slave *slave);
   void spi_cs_deactivate(struct spi_slave *slave);
@@ -69,13 +69,13 @@ II) Approach
 
   struct ops {
     int  (*spi_request_bus)(struct instance *i, unsigned int bus,
-                            unsigned int cs, unsigned int max_hz,
-                            unsigned int mode);
+			    unsigned int cs, unsigned int max_hz,
+			    unsigned int mode);
     void (*spi_release_bus)(struct instance *i);
     int  (*spi_xfer) (struct instance *i, unsigned int bitlen,
-                      const void *dout, void *din, unsigned long flags);
+		      const void *dout, void *din, unsigned long flags);
     int  (*spi_cs_is_valid)(struct instance *i, unsigned int bus,
-                            unsigned int cs);
+			    unsigned int cs);
     void (*spi_cs_activate)(struct instance *i);
     void (*spi_cs_deactivate)(struct instance *i);
     void (*spi_set_speed)(struct instance *i, uint hz);
diff --git a/doc/driver-model/UDM-stdio.txt b/doc/driver-model/UDM-stdio.txt
index a6c484f37c..c0b1c90b29 100644
--- a/doc/driver-model/UDM-stdio.txt
+++ b/doc/driver-model/UDM-stdio.txt
@@ -17,29 +17,29 @@ Each device that wants to register with STDIO subsystem has to define struct
 stdio_dev, defined in include/stdio_dev.h and containing the following fields:
 
 struct stdio_dev {
-        int     flags;                  /* Device flags: input/output/system */
-        int     ext;                    /* Supported extensions              */
-        char    name[16];               /* Device name                       */
+	int     flags;                  /* Device flags: input/output/system */
+	int     ext;                    /* Supported extensions              */
+	char    name[16];               /* Device name                       */
 
 /* GENERAL functions */
 
-        int (*start) (void);            /* To start the device               */
-        int (*stop) (void);             /* To stop the device                */
+	int (*start) (void);            /* To start the device               */
+	int (*stop) (void);             /* To stop the device                */
 
 /* OUTPUT functions */
 
-        void (*putc) (const char c);    /* To put a char                     */
-        void (*puts) (const char *s);   /* To put a string (accelerator)     */
+	void (*putc) (const char c);    /* To put a char                     */
+	void (*puts) (const char *s);   /* To put a string (accelerator)     */
 
 /* INPUT functions */
 
-        int (*tstc) (void);             /* To test if a char is ready...     */
-        int (*getc) (void);             /* To get that char                  */
+	int (*tstc) (void);             /* To test if a char is ready...     */
+	int (*getc) (void);             /* To get that char                  */
 
 /* Other functions */
 
-        void *priv;                     /* Private extensions                */
-        struct list_head list;
+	void *priv;                     /* Private extensions                */
+	struct list_head list;
 };
 
 Currently used flags are DEV_FLAGS_INPUT, DEV_FLAGS_OUTPUT and DEV_FLAGS_SYSTEM,
@@ -139,13 +139,13 @@ II) Approach
   purpose. The following flags will be defined:
 
     STDIO_FLG_STDIN ..... This device will be used as an input device. All input
-                          from all devices with this flag set will be received
+			  from all devices with this flag set will be received
 			  and passed to the upper layers.
     STDIO_FLG_STDOUT .... This device will be used as an output device. All
-                          output sent to stdout will be routed to all devices
+			  output sent to stdout will be routed to all devices
 			  with this flag set.
     STDIO_FLG_STDERR .... This device will be used as an standard error output
-                          device. All output sent to stderr will be routed to
+			  device. All output sent to stderr will be routed to
 			  all devices with this flag set.
 
   The "list" member of this structure allows to have a linked list of all
diff --git a/doc/driver-model/UDM-tpm.txt b/doc/driver-model/UDM-tpm.txt
index 91a953a72e..0beff4a857 100644
--- a/doc/driver-model/UDM-tpm.txt
+++ b/doc/driver-model/UDM-tpm.txt
@@ -14,7 +14,7 @@ controlling it is very much based on this. The API is very simple:
   int tis_open(void);
   int tis_close(void);
   int tis_sendrecv(const u8 *sendbuf, size_t send_size,
-                         u8 *recvbuf, size_t *recv_len);
+			 u8 *recvbuf, size_t *recv_len);
 
 The command operating the TPM chip only provides operations to send and receive
 bytes from the chip.
diff --git a/doc/driver-model/UDM-watchdog.txt b/doc/driver-model/UDM-watchdog.txt
index 7db328639f..7948e59260 100644
--- a/doc/driver-model/UDM-watchdog.txt
+++ b/doc/driver-model/UDM-watchdog.txt
@@ -41,13 +41,13 @@ II) Approach
   In the UDM each watchdog driver would register itself by a function
 
     int watchdog_device_register(struct instance *i,
-                                 const struct watchdog_device_ops *o);
+				 const struct watchdog_device_ops *o);
 
   The structure being defined as follows:
 
     struct watchdog_device_ops {
-        int (*disable)(struct instance *i);
-        void (*reset)(struct instance *i);
+	int (*disable)(struct instance *i);
+	void (*reset)(struct instance *i);
     };
 
   The watchdog_init() function will be dissolved into probe() function.