docs: leds: convert to ReST

Rename the leds documentation files to ReST, add an index for them and adjust in order to produce a nice html output via the Sphinx build system. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

docs: leds: convert to ReST
Rename the leds documentation files to ReST, add an index for them and adjust in order to produce a nice html output via the Sphinx build system. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
8dab9197 · Mauro Carvalho Chehab · Jacek Anaszewski · 25529ede · 8dab9197 · 8dab9197
Commit 8dab9197 authored Jun 28, 2019 by Mauro Carvalho Chehab Committed by Jacek Anaszewski Jun 28, 2019
20 changed files
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -679,7 +679,7 @@ status as "unknown". The available commands are:
 sysfs notes:
 The ThinkLight sysfs interface is documented by the LED class
-documentation, in Documentation/leds/leds-class.txt.  The ThinkLight LED name
+documentation, in Documentation/leds/leds-class.rst.  The ThinkLight LED name
 is "tpacpi::thinklight".
 Due to limitations in the sysfs LED class, if the status of the ThinkLight
@@ -779,7 +779,7 @@ All of the above can be turned on and off and can be made to blink.
 sysfs notes:
 The ThinkPad LED sysfs interface is described in detail by the LED class
-documentation, in Documentation/leds/leds-class.txt.
+documentation, in Documentation/leds/leds-class.rst.
 The LEDs are named (in LED ID order, from 0 to 12):
 "tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt",

--- a/Documentation/leds/index.rst
+++ b/Documentation/leds/index.rst
+:orphan:
+====
+LEDs
+====
+.. toctree::
+   :maxdepth: 1
+   leds-class
+   leds-class-flash
+   ledtrig-oneshot
+   ledtrig-transient
+   ledtrig-usbport
+   uleds
+   leds-blinkm
+   leds-lm3556
+   leds-lp3944
+   leds-lp5521
+   leds-lp5523
+   leds-lp5562
+   leds-lp55xx
+   leds-mlxcpld
--- a/Documentation/leds/leds-blinkm.txt
+++ b/Documentation/leds/leds-blinkm.txt
+==================
+Leds BlinkM driver
+==================
 The leds-blinkm driver supports the devices of the BlinkM family.
 They are RGB-LED modules driven by a (AT)tiny microcontroller and
@@ -14,35 +18,36 @@ The interface this driver provides is 2-fold:
 a) LED class interface for use with triggers
 ############################################
-The registration follows the scheme:
+The registration follows the scheme::
-blinkm-<i2c-bus-nr>-<i2c-device-nr>-<color>
+  blinkm-<i2c-bus-nr>-<i2c-device-nr>-<color>
-$ ls -h /sys/class/leds/blinkm-6-*
+  $ ls -h /sys/class/leds/blinkm-6-*
-/sys/class/leds/blinkm-6-9-blue:
+  /sys/class/leds/blinkm-6-9-blue:
-brightness  device  max_brightness  power  subsystem  trigger  uevent
+  brightness  device  max_brightness  power  subsystem  trigger  uevent
-/sys/class/leds/blinkm-6-9-green:
+  /sys/class/leds/blinkm-6-9-green:
-brightness  device  max_brightness  power  subsystem  trigger  uevent
+  brightness  device  max_brightness  power  subsystem  trigger  uevent
-/sys/class/leds/blinkm-6-9-red:
+  /sys/class/leds/blinkm-6-9-red:
-brightness  device  max_brightness  power  subsystem  trigger  uevent
+  brightness  device  max_brightness  power  subsystem  trigger  uevent
 (same is /sys/bus/i2c/devices/6-0009/leds)
 We can control the colors separated into red, green and blue and
 assign triggers on each color.
-E.g.:
+E.g.::
-$ cat blinkm-6-9-blue/brightness
+  $ cat blinkm-6-9-blue/brightness
-05
+  05
-$ echo 200 > blinkm-6-9-blue/brightness
+  $ echo 200 > blinkm-6-9-blue/brightness
-$
+  $
-$ modprobe ledtrig-heartbeat
+  $ modprobe ledtrig-heartbeat
-$ echo heartbeat > blinkm-6-9-green/trigger
+  $ echo heartbeat > blinkm-6-9-green/trigger
-$
+  $
 b) Sysfs group to control rgb, fade, hsb, scripts ...
@@ -52,29 +57,28 @@ This extended interface is available as folder blinkm
 in the sysfs folder of the I2C device.
 E.g. below /sys/bus/i2c/devices/6-0009/blinkm
-$ ls -h /sys/bus/i2c/devices/6-0009/blinkm/
+  $ ls -h /sys/bus/i2c/devices/6-0009/blinkm/
-blue  green  red  test
+  blue  green  red  test
 Currently supported is just setting red, green, blue
 and a test sequence.
-E.g.:
+E.g.::
-$ cat *
+  $ cat *
-00
+  00
-00
+  00
-00
+  00
-#Write into test to start test sequence!#
+  #Write into test to start test sequence!#
-$ echo 1 > test
+  $ echo 1 > test
-$
+  $
-$ echo 255 > red
+  $ echo 255 > red
-$
+  $
 as of 6/2012
 dl9pf <at> gmx <dot> de
--- a/Documentation/leds/leds-class-flash.txt
+++ b/Documentation/leds/leds-class-flash.txt
+==============================
 Flash LED handling under Linux
 ==============================
 Some LED devices provide two modes - torch and flash. In the LED subsystem
-those modes are supported by LED class (see Documentation/leds/leds-class.txt)
+those modes are supported by LED class (see Documentation/leds/leds-class.rst)
 and LED Flash class respectively. The torch mode related features are enabled
 by default and the flash ones only if a driver declares it by setting
 LED_DEV_CAP_FLASH flag.
@@ -14,6 +14,7 @@ registered in the LED subsystem with led_classdev_flash_register function.
 Following sysfs attributes are exposed for controlling flash LED devices:
 (see Documentation/ABI/testing/sysfs-class-led-flash)
 	- flash_brightness
 	- max_flash_brightness
 	- flash_timeout
@@ -31,30 +32,46 @@ be defined in the kernel config.
 The driver must call the v4l2_flash_init function to get registered in the
 V4L2 subsystem. The function takes six arguments:
- dev       : flash device, e.g. an I2C device
- of_node   : of_node of the LED, may be NULL if the same as device's
+- dev:
- fled_cdev : LED flash class device to wrap
+	flash device, e.g. an I2C device
- iled_cdev : LED flash class device representing indicator LED associated with
+- of_node:
-	      fled_cdev, may be NULL
+	of_node of the LED, may be NULL if the same as device's
- ops : V4L2 specific ops
+- fled_cdev:
-	* external_strobe_set - defines the source of the flash LED strobe -
+	LED flash class device to wrap
+- iled_cdev:
+	LED flash class device representing indicator LED associated with
+	fled_cdev, may be NULL
+- ops:
+	V4L2 specific ops
+	* external_strobe_set
+		defines the source of the flash LED strobe -
 		V4L2_CID_FLASH_STROBE control or external source, typically
 		a sensor, which makes it possible to synchronise the flash
 		strobe start with exposure start,
-	* intensity_to_led_brightness and led_brightness_to_intensity - perform
+	* intensity_to_led_brightness and led_brightness_to_intensity
+		perform
 		enum led_brightness <-> V4L2 intensity conversion in a device
 		specific manner - they can be used for devices with non-linear
 		LED current scale.
- config : configuration for V4L2 Flash sub-device
+- config:
-	* dev_name - the name of the media entity, unique in the system,
+	configuration for V4L2 Flash sub-device
-	* flash_faults - bitmask of flash faults that the LED flash class
+	* dev_name
+		the name of the media entity, unique in the system,
+	* flash_faults
+		bitmask of flash faults that the LED flash class
 		device can report; corresponding LED_FAULT* bit definitions are
 		available in <linux/led-class-flash.h>,
-	* torch_intensity - constraints for the LED in TORCH mode
+	* torch_intensity
+		constraints for the LED in TORCH mode
 		in microamperes,
-	* indicator_intensity - constraints for the indicator LED
+	* indicator_intensity
+		constraints for the indicator LED
 		in microamperes,
-	* has_external_strobe - determines whether the flash strobe source
+	* has_external_strobe
+		determines whether the flash strobe source
 		can be switched to external,
 On remove the v4l2_flash_release function has to be called, which takes one

--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
+========================
 LED handling under Linux
 ========================
@@ -43,7 +43,7 @@ LED Device Naming
 Is currently of the form:
-"devicename:colour:function"
+	"devicename:colour:function"
 There have been calls for LED properties such as colour to be exported as
 individual led class attributes. As a solution which doesn't incur as much
@@ -57,9 +57,12 @@ Brightness setting API
 LED subsystem core exposes following API for setting brightness:
-    - led_set_brightness : it is guaranteed not to sleep, passing LED_OFF stops
+    - led_set_brightness:
+		it is guaranteed not to sleep, passing LED_OFF stops
 		blinking,
-    - led_set_brightness_sync : for use cases when immediate effect is desired -
+    - led_set_brightness_sync:
+		for use cases when immediate effect is desired -
 		it can block the caller for the time required for accessing
 		device registers and can sleep, passing LED_OFF stops hardware
 		blinking, returns -EBUSY if software blink fallback is enabled.
@@ -70,7 +73,7 @@ LED registration API
 A driver wanting to register a LED classdev for use by other drivers /
 userspace needs to allocate and fill a led_classdev struct and then call
-[devm_]led_classdev_register. If the non devm version is used the driver
+`[devm_]led_classdev_register`. If the non devm version is used the driver
 must call led_classdev_unregister from its remove function before
 free-ing the led_classdev struct.
@@ -94,7 +97,7 @@ with brightness value LED_OFF, which should stop any software
 timers that may have been required for blinking.
 The blink_set() function should choose a user friendly blinking value
-if it is called with *delay_on==0 && *delay_off==0 parameters. In this
+if it is called with `*delay_on==0` && `*delay_off==0` parameters. In this
 case the driver should give back the chosen value through delay_on and
 delay_off parameters to the leds subsystem.

--- a/Documentation/leds/leds-lm3556.txt
+++ b/Documentation/leds/leds-lm3556.txt
+========================
 Kernel driver for lm3556
 ========================
-*Texas Instrument:
+* Texas Instrument:
- 1.5 A Synchronous Boost LED Flash Driver w/ High-Side Current Source
+  1.5 A Synchronous Boost LED Flash Driver w/ High-Side Current Source
 * Datasheet: http://www.national.com/ds/LM/LM3556.pdf
 Authors:
-	Daniel Jeong
+      - Daniel Jeong
 	Contact:Daniel Jeong(daniel.jeong-at-ti.com, gshark.jeong-at-gmail.com)
 Description
 -----------
 There are 3 functions in LM3556, Flash, Torch and Indicator.
-FLASH MODE
+Flash Mode
+^^^^^^^^^^
 In Flash Mode, the LED current source(LED) provides 16 target current levels
 from 93.75 mA to 1500 mA.The Flash currents are adjusted via the CURRENT
 CONTROL REGISTER(0x09).Flash mode is activated by the ENABLE REGISTER(0x0A),
 or by pulling the STROBE pin HIGH.
 LM3556 Flash can be controlled through sys/class/leds/flash/brightness file
 * if STROBE pin is enabled, below example control brightness only, and
-ON / OFF will be controlled by STROBE pin.
+  ON / OFF will be controlled by STROBE pin.
 Flash Example:
-OFF     : #echo 0 > sys/class/leds/flash/brightness
-93.75 mA: #echo 1 > sys/class/leds/flash/brightness
-... .....
-1500  mA: #echo 16 > sys/class/leds/flash/brightness
-TORCH MODE
+OFF::
+	#echo 0 > sys/class/leds/flash/brightness
+93.75 mA::
+	#echo 1 > sys/class/leds/flash/brightness
+...
+1500  mA::
+	#echo 16 > sys/class/leds/flash/brightness
+Torch Mode
+^^^^^^^^^^
 In Torch Mode, the current source(LED) is programmed via the CURRENT CONTROL
 REGISTER(0x09).Torch Mode is activated by the ENABLE REGISTER(0x0A) or by the
 hardware TORCH input.
 LM3556 torch can be controlled through sys/class/leds/torch/brightness file.
 * if TORCH pin is enabled, below example control brightness only,
 and ON / OFF will be controlled by TORCH pin.
 Torch Example:
-OFF     : #echo 0 > sys/class/leds/torch/brightness
-46.88 mA: #echo 1 > sys/class/leds/torch/brightness
-... .....
-375 mA  : #echo 8 > sys/class/leds/torch/brightness
-INDICATOR MODE
+OFF::
+	#echo 0 > sys/class/leds/torch/brightness
+46.88 mA::
+	#echo 1 > sys/class/leds/torch/brightness
+...
+375 mA::
+	#echo 8 > sys/class/leds/torch/brightness
+Indicator Mode
+^^^^^^^^^^^^^^
 Indicator pattern can be set through sys/class/leds/indicator/pattern file,
 and 4 patterns are pre-defined in indicator_pattern array.
 According to N-lank, Pulse time and N Period values, different pattern wiill
 be generated.If you want new patterns for your own device, change
 indicator_pattern array with your own values and INDIC_PATTERN_SIZE.
 Please refer datasheet for more detail about N-Blank, Pulse time and N Period.
 Indicator pattern example:
-pattern 0: #echo 0 > sys/class/leds/indicator/pattern
-....
+pattern 0::
-pattern 3: #echo 3 > sys/class/leds/indicator/pattern
+	#echo 0 > sys/class/leds/indicator/pattern
+...
+pattern 3::
+	#echo 3 > sys/class/leds/indicator/pattern
 Indicator brightness can be controlled through
 sys/class/leds/indicator/brightness file.
 Example:
-OFF      : #echo 0 > sys/class/leds/indicator/brightness
-5.86 mA  : #echo 1 > sys/class/leds/indicator/brightness
+OFF::
-........
-46.875mA : #echo 8 > sys/class/leds/indicator/brightness
+	#echo 0 > sys/class/leds/indicator/brightness
+5.86 mA::
+	#echo 1 > sys/class/leds/indicator/brightness
+...
+46.875mA::
+	#echo 8 > sys/class/leds/indicator/brightness
 Notes
 -----
@@ -70,7 +120,8 @@ Driver expects it is registered using the i2c_board_info mechanism.
 To register the chip at address 0x63 on specific adapter, set the platform data
 according to include/linux/platform_data/leds-lm3556.h, set the i2c board info
-Example:
+Example::
 	static struct i2c_board_info board_i2c_ch4[] __initdata = {
 		{
 			 I2C_BOARD_INFO(LM3556_NAME, 0x63),
@@ -80,6 +131,7 @@ Example:
 and register it in the platform init function
-Example:
+Example::
 	board_register_i2c_bus(4, 400,
 				board_i2c_ch4, ARRAY_SIZE(board_i2c_ch4));
--- a/Documentation/leds/leds-lp3944.txt
+++ b/Documentation/leds/leds-lp3944.txt
+====================
 Kernel driver lp3944
 ====================
  * National Semiconductor LP3944 Fun-light Chip
    Prefix: 'lp3944'
    Addresses scanned: None (see the Notes section below)
-    Datasheet: Publicly available at the National Semiconductor website
-               http://www.national.com/pf/LP/LP3944.html
+    Datasheet:
+	Publicly available at the National Semiconductor website
+	http://www.national.com/pf/LP/LP3944.html
 Authors:
-        Antonio Ospite <ospite@studenti.unina.it>
+	Antonio Ospite <ospite@studenti.unina.it>
 Description
@@ -19,8 +25,11 @@ is used as a led controller.
 The DIM modes are used to set _blink_ patterns for leds, the pattern is
 specified supplying two parameters:
-  - period: from 0s to 1.6s
-  - duty cycle: percentage of the period the led is on, from 0 to 100
+  - period:
+	from 0s to 1.6s
+  - duty cycle:
+	percentage of the period the led is on, from 0 to 100
 Setting a led in DIM0 or DIM1 mode makes it blink according to the pattern.
 See the datasheet for details.
@@ -35,7 +44,7 @@ The chip is used mainly in embedded contexts, so this driver expects it is
 registered using the i2c_board_info mechanism.
 To register the chip at address 0x60 on adapter 0, set the platform data
-according to include/linux/leds-lp3944.h, set the i2c board info:
+according to include/linux/leds-lp3944.h, set the i2c board info::
 	static struct i2c_board_info a910_i2c_board_info[] __initdata = {
 		{
@@ -44,7 +53,7 @@ according to include/linux/leds-lp3944.h, set the i2c board info:
 		},
 	};
-and register it in the platform init function
+and register it in the platform init function::
 	i2c_register_board_info(0, a910_i2c_board_info,
 			ARRAY_SIZE(a910_i2c_board_info));
--- a/Documentation/leds/leds-lp5521.txt
+++ b/Documentation/leds/leds-lp5521.txt
+========================
 Kernel driver for lp5521
 ========================
@@ -5,6 +6,7 @@ Kernel driver for lp5521
 * Datasheet: http://www.national.com/pf/LP/LP5521.html
 Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
 Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
 Description
@@ -21,81 +23,93 @@ LP5521 has the internal program memory for running various LED patterns.
 There are two ways to run LED patterns.
 1) Legacy interface - enginex_mode and enginex_load
-  Control interface for the engines:
+   Control interface for the engines:
-  x is 1 .. 3
-  enginex_mode : disabled, load, run
+   x is 1 .. 3
-  enginex_load : store program (visible only in engine load mode)
+   enginex_mode:
+	disabled, load, run
+   enginex_load:
+	store program (visible only in engine load mode)
+  Example (start to blink the channel 2 led)::
+	cd   /sys/class/leds/lp5521:channel2/device
+	echo "load" > engine3_mode
+	echo "037f4d0003ff6000" > engine3_load
+	echo "run" > engine3_mode
-  Example (start to blink the channel 2 led):
+  To stop the engine::
-  cd   /sys/class/leds/lp5521:channel2/device
-  echo "load" > engine3_mode
-  echo "037f4d0003ff6000" > engine3_load
-  echo "run" > engine3_mode
-  To stop the engine:
+	echo "disabled" > engine3_mode
-  echo "disabled" > engine3_mode
 2) Firmware interface - LP55xx common interface
-  For the details, please refer to 'firmware' section in leds-lp55xx.txt
+For the details, please refer to 'firmware' section in leds-lp55xx.txt
 sysfs contains a selftest entry.
 The test communicates with the chip and checks that
 the clock mode is automatically set to the requested one.
 Each channel has its own led current settings.
-/sys/class/leds/lp5521:channel0/led_current - RW
-/sys/class/leds/lp5521:channel0/max_current - RO
-Format: 10x mA i.e 10 means 1.0 mA
-example platform data:
+- /sys/class/leds/lp5521:channel0/led_current - RW
+- /sys/class/leds/lp5521:channel0/max_current - RO
-Note: chan_nr can have values between 0 and 2.
+Format: 10x mA i.e 10 means 1.0 mA
-The name of each channel can be configurable.
-If the name field is not defined, the default name will be set to 'xxxx:channelN'
+example platform data::
-(XXXX : pdata->label or i2c client name, N : channel number)
-static struct lp55xx_led_config lp5521_led_config[] = {
+  static struct lp55xx_led_config lp5521_led_config[] = {
-        {
+	  {
 		.name = "red",
-                .chan_nr        = 0,
+		  .chan_nr        = 0,
-                .led_current    = 50,
+		  .led_current    = 50,
 		.max_current    = 130,
-        }, {
+	  }, {
 		.name = "green",
-                .chan_nr        = 1,
+		  .chan_nr        = 1,
-                .led_current    = 0,
+		  .led_current    = 0,
 		.max_current    = 130,
-        }, {
+	  }, {
 		.name = "blue",
-                .chan_nr        = 2,
+		  .chan_nr        = 2,
-                .led_current    = 0,
+		  .led_current    = 0,
 		.max_current    = 130,
-        }
+	  }
-};
+  };
-static int lp5521_setup(void)
+  static int lp5521_setup(void)
-{
+  {
 	/* setup HW resources */
-}
+  }
-static void lp5521_release(void)
+  static void lp5521_release(void)
-{
+  {
 	/* Release HW resources */
-}
+  }
-static void lp5521_enable(bool state)
+  static void lp5521_enable(bool state)
-{
+  {
 	/* Control of chip enable signal */
-}
+  }
-static struct lp55xx_platform_data lp5521_platform_data = {
+  static struct lp55xx_platform_data lp5521_platform_data = {
-        .led_config     = lp5521_led_config,
+	  .led_config     = lp5521_led_config,
-        .num_channels   = ARRAY_SIZE(lp5521_led_config),
+	  .num_channels   = ARRAY_SIZE(lp5521_led_config),
-        .clock_mode     = LP55XX_CLOCK_EXT,
+	  .clock_mode     = LP55XX_CLOCK_EXT,
-        .setup_resources   = lp5521_setup,
+	  .setup_resources   = lp5521_setup,
-        .release_resources = lp5521_release,
+	  .release_resources = lp5521_release,
-        .enable            = lp5521_enable,
+	  .enable            = lp5521_enable,
-};
+  };
+Note:
+  chan_nr can have values between 0 and 2.
+  The name of each channel can be configurable.
+  If the name field is not defined, the default name will be set to 'xxxx:channelN'
+  (XXXX : pdata->label or i2c client name, N : channel number)
 If the current is set to 0 in the platform data, that channel is
 disabled and it is not visible in the sysfs.
--- a/Documentation/leds/leds-lp5523.txt
+++ b/Documentation/leds/leds-lp5523.txt
+========================
 Kernel driver for lp5523
 ========================
@@ -15,116 +16,132 @@ The name of each channel is configurable in the platform data - name and label.
 There are three options to make the channel name.
 a) Define the 'name' in the platform data
 To make specific channel name, then use 'name' platform data.
-/sys/class/leds/R1               (name: 'R1')
-/sys/class/leds/B1               (name: 'B1')
+- /sys/class/leds/R1               (name: 'R1')
+- /sys/class/leds/B1               (name: 'B1')
 b) Use the 'label' with no 'name' field
 For one device name with channel number, then use 'label'.
-/sys/class/leds/RGB:channelN     (label: 'RGB', N: 0 ~ 8)
+- /sys/class/leds/RGB:channelN     (label: 'RGB', N: 0 ~ 8)
 c) Default
 If both fields are NULL, 'lp5523' is used by default.
-/sys/class/leds/lp5523:channelN  (N: 0 ~ 8)
+- /sys/class/leds/lp5523:channelN  (N: 0 ~ 8)
 LP5523 has the internal program memory for running various LED patterns.
 There are two ways to run LED patterns.
 1) Legacy interface - enginex_mode, enginex_load and enginex_leds
  Control interface for the engines:
  x is 1 .. 3
-  enginex_mode : disabled, load, run
-  enginex_load : microcode load
-  enginex_leds : led mux control
-  cd /sys/class/leds/lp5523:channel2/device
+  enginex_mode:
-  echo "load" > engine3_mode
+	disabled, load, run
-  echo "9d80400004ff05ff437f0000" > engine3_load
+  enginex_load:
-  echo "111111111" > engine3_leds
+	microcode load
-  echo "run" > engine3_mode
+  enginex_leds:
+	led mux control
+  ::
+	cd /sys/class/leds/lp5523:channel2/device
+	echo "load" > engine3_mode
+	echo "9d80400004ff05ff437f0000" > engine3_load
+	echo "111111111" > engine3_leds
+	echo "run" > engine3_mode
-  To stop the engine:
+  To stop the engine::
-  echo "disabled" > engine3_mode
+	echo "disabled" > engine3_mode
 2) Firmware interface - LP55xx common interface
-  For the details, please refer to 'firmware' section in leds-lp55xx.txt
+For the details, please refer to 'firmware' section in leds-lp55xx.txt
 LP5523 has three master faders. If a channel is mapped to one of
 the master faders, its output is dimmed based on the value of the master
 fader.
-For example,
+For example::
  echo "123000123" > master_fader_leds
-creates the following channel-fader mappings:
+creates the following channel-fader mappings::
  channel 0,6 to master_fader1
  channel 1,7 to master_fader2
  channel 2,8 to master_fader3
-Then, to have 25% of the original output on channel 0,6:
+Then, to have 25% of the original output on channel 0,6::
  echo 64 > master_fader1
-To have 0% of the original output (i.e. no output) channel 1,7:
+To have 0% of the original output (i.e. no output) channel 1,7::
  echo 0 > master_fader2
-To have 100% of the original output (i.e. no dimming) on channel 2,8:
+To have 100% of the original output (i.e. no dimming) on channel 2,8::
  echo 255 > master_fader3
-To clear all master fader controls:
+To clear all master fader controls::
  echo "000000000" > master_fader_leds
 Selftest uses always the current from the platform data.
 Each channel contains led current settings.
-/sys/class/leds/lp5523:channel2/led_current - RW
+- /sys/class/leds/lp5523:channel2/led_current - RW
-/sys/class/leds/lp5523:channel2/max_current - RO
+- /sys/class/leds/lp5523:channel2/max_current - RO
 Format: 10x mA i.e 10 means 1.0 mA
-Example platform data:
+Example platform data::
-Note - chan_nr can have values between 0 and 8.
+	static struct lp55xx_led_config lp5523_led_config[] = {
+		{
-static struct lp55xx_led_config lp5523_led_config[] = {
+			.name		= "D1",
-        {
+			.chan_nr        = 0,
-		.name		= "D1",
+			.led_current    = 50,
-                .chan_nr        = 0,
+			.max_current    = 130,
-                .led_current    = 50,
+		},
-		.max_current    = 130,
+	...
-        },
+		{
-...
+			.chan_nr        = 8,
-        {
+			.led_current    = 50,
-                .chan_nr        = 8,
+			.max_current    = 130,
-                .led_current    = 50,
+		}
-		.max_current    = 130,
+	};
-        }
-};
+	static int lp5523_setup(void)
+	{
-static int lp5523_setup(void)
+		/* Setup HW resources */
-{
+	}
-	/* Setup HW resources */
-}
+	static void lp5523_release(void)
+	{
-static void lp5523_release(void)
+		/* Release HW resources */
-{
+	}
-	/* Release HW resources */
-}
+	static void lp5523_enable(bool state)
+	{
-static void lp5523_enable(bool state)
+		/* Control chip enable signal */
-{
+	}
-	/* Control chip enable signal */
-}
+	static struct lp55xx_platform_data lp5523_platform_data = {
+		.led_config     = lp5523_led_config,
-static struct lp55xx_platform_data lp5523_platform_data = {
+		.num_channels   = ARRAY_SIZE(lp5523_led_config),
-        .led_config     = lp5523_led_config,
+		.clock_mode     = LP55XX_CLOCK_EXT,
-        .num_channels   = ARRAY_SIZE(lp5523_led_config),
+		.setup_resources   = lp5523_setup,
-        .clock_mode     = LP55XX_CLOCK_EXT,
+		.release_resources = lp5523_release,
-        .setup_resources   = lp5523_setup,
+		.enable            = lp5523_enable,
-        .release_resources = lp5523_release,
+	};
-        .enable            = lp5523_enable,
-};
+Note
+  chan_nr can have values between 0 and 8.
--- a/Documentation/leds/leds-lp5562.txt
+++ b/Documentation/leds/leds-lp5562.txt
-Kernel driver for LP5562
+========================
+Kernel driver for lp5562
 ========================
 * TI LP5562 LED Driver
@@ -6,6 +7,7 @@ Kernel driver for LP5562
 Author: Milo(Woogyom) Kim <milo.kim@ti.com>
 Description
+===========
  LP5562 can drive up to 4 channels. R/G/B and White.
  LEDs can be controlled directly via the led class control interface.
@@ -14,107 +16,122 @@ Description
  LP5562 has the internal program memory for running various LED patterns.
  For the details, please refer to 'firmware' section in leds-lp55xx.txt
-Device attribute: engine_mux
+Device attribute
+================
+engine_mux
  3 Engines are allocated in LP5562, but the number of channel is 4.
  Therefore each channel should be mapped to the engine number.
-  Value : RGB or W
+  Value: RGB or W
  This attribute is used for programming LED data with the firmware interface.
  Unlike the LP5521/LP5523/55231, LP5562 has unique feature for the engine mux,
-  so additional sysfs is required.
+  so additional sysfs is required
  LED Map
+  ===== === ===============================
  Red   ... Engine 1 (fixed)
  Green ... Engine 2 (fixed)
  Blue  ... Engine 3 (fixed)
  White ... Engine 1 or 2 or 3 (selective)
+  ===== === ===============================
 How to load the program data using engine_mux
+=============================================
  Before loading the LP5562 program data, engine_mux should be written between
  the engine selection and loading the firmware.
  Engine mux has two different mode, RGB and W.
  RGB is used for loading RGB program data, W is used for W program data.
-  For example, run blinking green channel pattern,
+  For example, run blinking green channel pattern::
-  echo 2 > /sys/bus/i2c/devices/xxxx/select_engine     # 2 is for green channel
-  echo "RGB" > /sys/bus/i2c/devices/xxxx/engine_mux    # engine mux for RGB
+    echo 2 > /sys/bus/i2c/devices/xxxx/select_engine     # 2 is for green channel
-  echo 1 > /sys/class/firmware/lp5562/loading
+    echo "RGB" > /sys/bus/i2c/devices/xxxx/engine_mux    # engine mux for RGB
-  echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
+    echo 1 > /sys/class/firmware/lp5562/loading
-  echo 0 > /sys/class/firmware/lp5562/loading
+    echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
-  echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+    echo 0 > /sys/class/firmware/lp5562/loading
+    echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
-  To run a blinking white pattern,
-  echo 1 or 2 or 3 > /sys/bus/i2c/devices/xxxx/select_engine
+  To run a blinking white pattern::
-  echo "W" > /sys/bus/i2c/devices/xxxx/engine_mux
-  echo 1 > /sys/class/firmware/lp5562/loading
+    echo 1 or 2 or 3 > /sys/bus/i2c/devices/xxxx/select_engine
-  echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
+    echo "W" > /sys/bus/i2c/devices/xxxx/engine_mux
-  echo 0 > /sys/class/firmware/lp5562/loading
+    echo 1 > /sys/class/firmware/lp5562/loading
-  echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+    echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
+    echo 0 > /sys/class/firmware/lp5562/loading
+    echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
 How to load the predefined patterns
+===================================
  Please refer to 'leds-lp55xx.txt"
 Setting Current of Each Channel
+===============================
  Like LP5521 and LP5523/55231, LP5562 provides LED current settings.
  The 'led_current' and 'max_current' are used.
-(Example of Platform data)
+Example of Platform data
+========================
-To configure the platform specific data, lp55xx_platform_data structure is used.
-static struct lp55xx_led_config lp5562_led_config[] = {
+::
-	{
-		.name 		= "R",
+	static struct lp55xx_led_config lp5562_led_config[] = {
-		.chan_nr	= 0,
+		{
-		.led_current	= 20,
+			.name 		= "R",
-		.max_current	= 40,
+			.chan_nr	= 0,
-	},
+			.led_current	= 20,
+			.max_current	= 40,
+		},
+		{
+			.name 		= "G",
+			.chan_nr	= 1,
+			.led_current	= 20,
+			.max_current	= 40,
+		},
+		{
+			.name 		= "B",
+			.chan_nr	= 2,
+			.led_current	= 20,
+			.max_current	= 40,
+		},
+		{
+			.name 		= "W",
+			.chan_nr	= 3,
+			.led_current	= 20,
+			.max_current	= 40,
+		},
+	};
+	static int lp5562_setup(void)
 	{
-		.name 		= "G",
+		/* setup HW resources */
-		.chan_nr	= 1,
+	}
-		.led_current	= 20,
-		.max_current	= 40,
+	static void lp5562_release(void)
-	},
 	{
-		.name 		= "B",
+		/* Release HW resources */
-		.chan_nr	= 2,
+	}
-		.led_current	= 20,
-		.max_current	= 40,
+	static void lp5562_enable(bool state)
-	},
 	{
-		.name 		= "W",
+		/* Control of chip enable signal */
-		.chan_nr	= 3,
+	}
-		.led_current	= 20,
-		.max_current	= 40,
+	static struct lp55xx_platform_data lp5562_platform_data = {
-	},
+		.led_config     = lp5562_led_config,
-};
+		.num_channels   = ARRAY_SIZE(lp5562_led_config),
+		.setup_resources   = lp5562_setup,
-static int lp5562_setup(void)
+		.release_resources = lp5562_release,
-{
+		.enable            = lp5562_enable,
-	/* setup HW resources */
+	};
-}
+To configure the platform specific data, lp55xx_platform_data structure is used
-static void lp5562_release(void)
-{
-	/* Release HW resources */
-}
-static void lp5562_enable(bool state)
-{
-	/* Control of chip enable signal */
-}
-static struct lp55xx_platform_data lp5562_platform_data = {
-        .led_config     = lp5562_led_config,
-        .num_channels   = ARRAY_SIZE(lp5562_led_config),
-        .setup_resources   = lp5562_setup,
-        .release_resources = lp5562_release,
-        .enable            = lp5562_enable,
-};
 If the current is set to 0 in the platform data, that channel is
 disabled and it is not visible in the sysfs.
--- a/Documentation/leds/leds-lp55xx.txt
+++ b/Documentation/leds/leds-lp55xx.txt
+=================================================
 LP5521/LP5523/LP55231/LP5562/LP8501 Common Driver
 =================================================
@@ -14,6 +15,7 @@ LP5521, LP5523/55231, LP5562 and LP8501 have common features as below.
  Program memory for running LED patterns
 The LP55xx common driver provides these features using exported functions.
  lp55xx_init_device() / lp55xx_deinit_device()
  lp55xx_register_leds() / lp55xx_unregister_leds()
  lp55xx_regsister_sysfs() / lp55xx_unregister_sysfs()
@@ -22,143 +24,170 @@ The LP55xx common driver provides these features using exported functions.
 In lp55xx common driver, two different data structure is used.
-o lp55xx_led
+* lp55xx_led
-  control multi output LED channels such as led current, channel index.
+    control multi output LED channels such as led current, channel index.
-o lp55xx_chip
+* lp55xx_chip
-  general chip control such like the I2C and platform data.
+    general chip control such like the I2C and platform data.
 For example, LP5521 has maximum 3 LED channels.
-LP5523/55231 has 9 output channels.
+LP5523/55231 has 9 output channels::
-lp55xx_chip for LP5521 ... lp55xx_led #1
+  lp55xx_chip for LP5521 ... lp55xx_led #1
-                           lp55xx_led #2
+			     lp55xx_led #2
-                           lp55xx_led #3
+			     lp55xx_led #3
-lp55xx_chip for LP5523 ... lp55xx_led #1
+  lp55xx_chip for LP5523 ... lp55xx_led #1
-                           lp55xx_led #2
+			     lp55xx_led #2
-                                 .
+				   .
-                                 .
+				   .
-                           lp55xx_led #9
+			     lp55xx_led #9
 ( Chip Dependent Code )
 To support device specific configurations, special structure
 'lpxx_device_config' is used.
-  Maximum number of channels
+  - Maximum number of channels
-  Reset command, chip enable command
+  - Reset command, chip enable command
-  Chip specific initialization
+  - Chip specific initialization
-  Brightness control register access
+  - Brightness control register access
-  Setting LED output current
+  - Setting LED output current
-  Program memory address access for running patterns
+  - Program memory address access for running patterns
-  Additional device specific attributes
+  - Additional device specific attributes
 ( Firmware Interface )
 LP55xx family devices have the internal program memory for running
 various LED patterns.
 This pattern data is saved as a file in the user-land or
 hex byte string is written into the memory through the I2C.
 LP55xx common driver supports the firmware interface.
 LP55xx chips have three program engines.
 To load and run the pattern, the programming sequence is following.
  (1) Select an engine number (1/2/3)
  (2) Mode change to load
  (3) Write pattern data into selected area
  (4) Mode change to run
 The LP55xx common driver provides simple interfaces as below.
-select_engine : Select which engine is used for running program
-run_engine    : Start program which is loaded via the firmware interface
+select_engine:
-firmware      : Load program data
+	Select which engine is used for running program
+run_engine:
+	Start program which is loaded via the firmware interface
+firmware:
+	Load program data
 In case of LP5523, one more command is required, 'enginex_leds'.
 It is used for selecting LED output(s) at each engine number.
 In more details, please refer to 'leds-lp5523.txt'.
-For example, run blinking pattern in engine #1 of LP5521
+For example, run blinking pattern in engine #1 of LP5521::
-echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
-echo 1 > /sys/class/firmware/lp5521/loading
+	echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
-echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
+	echo 1 > /sys/class/firmware/lp5521/loading
-echo 0 > /sys/class/firmware/lp5521/loading
+	echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
-echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+	echo 0 > /sys/class/firmware/lp5521/loading
+	echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
 For example, run blinking pattern in engine #3 of LP55231
-Two LEDs are configured as pattern output channels.
-echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
+Two LEDs are configured as pattern output channels::
-echo 1 > /sys/class/firmware/lp55231/loading
-echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data
+	echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
-echo 0 > /sys/class/firmware/lp55231/loading
+	echo 1 > /sys/class/firmware/lp55231/loading
-echo "000001100" > /sys/bus/i2c/devices/xxxx/engine3_leds
+	echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data
-echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+	echo 0 > /sys/class/firmware/lp55231/loading
+	echo "000001100" > /sys/bus/i2c/devices/xxxx/engine3_leds
-To start blinking patterns in engine #2 and #3 simultaneously,
+	echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
-for idx in 2 3
-do
+To start blinking patterns in engine #2 and #3 simultaneously::
-  echo $idx > /sys/class/leds/red/device/select_engine
-  sleep 0.1
+	for idx in 2 3
-  echo 1 > /sys/class/firmware/lp5521/loading
+	do
-  echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
+	echo $idx > /sys/class/leds/red/device/select_engine
-  echo 0 > /sys/class/firmware/lp5521/loading
+	sleep 0.1
-done
+	echo 1 > /sys/class/firmware/lp5521/loading
-echo 1 > /sys/class/leds/red/device/run_engine
+	echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
+	echo 0 > /sys/class/firmware/lp5521/loading
+	done
+	echo 1 > /sys/class/leds/red/device/run_engine
 Here is another example for LP5523.
-Full LED strings are selected by 'engine2_leds'.
-echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
+Full LED strings are selected by 'engine2_leds'::
-echo 1 > /sys/class/firmware/lp5523/loading
-echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data
+	echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
-echo 0 > /sys/class/firmware/lp5523/loading
+	echo 1 > /sys/class/firmware/lp5523/loading
-echo "111111111" > /sys/bus/i2c/devices/xxxx/engine2_leds
+	echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data
-echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+	echo 0 > /sys/class/firmware/lp5523/loading
+	echo "111111111" > /sys/bus/i2c/devices/xxxx/engine2_leds
+	echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
 As soon as 'loading' is set to 0, registered callback is called.
 Inside the callback, the selected engine is loaded and memory is updated.
 To run programmed pattern, 'run_engine' attribute should be enabled.
 The pattern sequence of LP8501 is similar to LP5523.
 However pattern data is specific.
-Ex 1) Engine 1 is used
-echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
+Ex 1) Engine 1 is used::
-echo 1 > /sys/class/firmware/lp8501/loading
-echo "9d0140ff7e0040007e00a001c000" > /sys/class/firmware/lp8501/data
+	echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
-echo 0 > /sys/class/firmware/lp8501/loading
+	echo 1 > /sys/class/firmware/lp8501/loading
-echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+	echo "9d0140ff7e0040007e00a001c000" > /sys/class/firmware/lp8501/data
+	echo 0 > /sys/class/firmware/lp8501/loading
-Ex 2) Engine 2 and 3 are used at the same time
+	echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
-echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
-sleep 1
+Ex 2) Engine 2 and 3 are used at the same time::
-echo 1 > /sys/class/firmware/lp8501/loading
-echo "9d0140ff7e0040007e00a001c000" > /sys/class/firmware/lp8501/data
+	echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
-echo 0 > /sys/class/firmware/lp8501/loading
+	sleep 1
-sleep 1
+	echo 1 > /sys/class/firmware/lp8501/loading
-echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
+	echo "9d0140ff7e0040007e00a001c000" > /sys/class/firmware/lp8501/data
-sleep 1
+	echo 0 > /sys/class/firmware/lp8501/loading
-echo 1 > /sys/class/firmware/lp8501/loading
+	sleep 1
-echo "9d0340ff7e0040007e00a001c000" > /sys/class/firmware/lp8501/data
+	echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
-echo 0 > /sys/class/firmware/lp8501/loading
+	sleep 1
-sleep 1
+	echo 1 > /sys/class/firmware/lp8501/loading
-echo 1 > /sys/class/leds/d1/device/run_engine
+	echo "9d0340ff7e0040007e00a001c000" > /sys/class/firmware/lp8501/data
+	echo 0 > /sys/class/firmware/lp8501/loading
+	sleep 1
+	echo 1 > /sys/class/leds/d1/device/run_engine
 ( 'run_engine' and 'firmware_cb' )
 The sequence of running the program data is common.
 But each device has own specific register addresses for commands.
 To support this, 'run_engine' and 'firmware_cb' are configurable in each driver.
-run_engine  : Control the selected engine
-firmware_cb : The callback function after loading the firmware is done.
+run_engine:
-              Chip specific commands for loading and updating program memory.
+	Control the selected engine
+firmware_cb:
+	The callback function after loading the firmware is done.
+	Chip specific commands for loading and updating program memory.
 ( Predefined pattern data )
 Without the firmware interface, LP55xx driver provides another method for
 loading a LED pattern. That is 'predefined' pattern.
 A predefined pattern is defined in the platform data and load it(or them)
 via the sysfs if needed.
 To use the predefined pattern concept, 'patterns' and 'num_patterns' should be
 configured.
-  Example of predefined pattern data:
+Example of predefined pattern data::
  /* mode_1: blinking data */
  static const u8 mode_1[] = {
@@ -185,10 +214,11 @@ configured.
 	.num_patterns  = ARRAY_SIZE(board_led_patterns),
  };
-Then, mode_1 and mode_2 can be run via through the sysfs.
+Then, mode_1 and mode_2 can be run via through the sysfs::
  echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern    # red blinking LED pattern
  echo 2 > /sys/bus/i2c/devices/xxxx/led_pattern    # blue LED always on
-To stop running pattern,
+To stop running pattern::
  echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern
--- a/Documentation/leds/leds-mlxcpld.txt
+++ b/Documentation/leds/leds-mlxcpld.txt
+=======================================
 Kernel driver for Mellanox systems LEDs
 =======================================
@@ -9,102 +10,109 @@ Description
 -----------
 Driver provides the following LEDs for the systems "msx6710", "msx6720",
 "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740":
-  mlxcpld:fan1:green
-  mlxcpld:fan1:red
+  - mlxcpld:fan1:green
-  mlxcpld:fan2:green
+  - mlxcpld:fan1:red
-  mlxcpld:fan2:red
+  - mlxcpld:fan2:green
-  mlxcpld:fan3:green
+  - mlxcpld:fan2:red
-  mlxcpld:fan3:red
+  - mlxcpld:fan3:green
-  mlxcpld:fan4:green
+  - mlxcpld:fan3:red
-  mlxcpld:fan4:red
+  - mlxcpld:fan4:green
-  mlxcpld:psu:green
+  - mlxcpld:fan4:red
-  mlxcpld:psu:red
+  - mlxcpld:psu:green
-  mlxcpld:status:green
+  - mlxcpld:psu:red
-  mlxcpld:status:red
+  - mlxcpld:status:green
+  - mlxcpld:status:red
 "status"
-  CPLD reg offset: 0x20
+  - CPLD reg offset: 0x20
-  Bits [3:0]
+  - Bits [3:0]
 "psu"
-  CPLD reg offset: 0x20
+  - CPLD reg offset: 0x20
-  Bits [7:4]
+  - Bits [7:4]
 "fan1"
-  CPLD reg offset: 0x21
+  - CPLD reg offset: 0x21
-  Bits [3:0]
+  - Bits [3:0]
 "fan2"
-  CPLD reg offset: 0x21
+  - CPLD reg offset: 0x21
-  Bits [7:4]
+  - Bits [7:4]
 "fan3"
-  CPLD reg offset: 0x22
+  - CPLD reg offset: 0x22
-  Bits [3:0]
+  - Bits [3:0]
 "fan4"
-  CPLD reg offset: 0x22
+  - CPLD reg offset: 0x22
-  Bits [7:4]
+  - Bits [7:4]
 Color mask for all the above LEDs:
  [bit3,bit2,bit1,bit0] or
  [bit7,bit6,bit5,bit4]:
-	[0,0,0,0] = LED OFF
-	[0,1,0,1] = Red static ON
+	- [0,0,0,0] = LED OFF
-	[1,1,0,1] = Green static ON
+	- [0,1,0,1] = Red static ON
-	[0,1,1,0] = Red blink 3Hz
+	- [1,1,0,1] = Green static ON
-	[1,1,1,0] = Green blink 3Hz
+	- [0,1,1,0] = Red blink 3Hz
-	[0,1,1,1] = Red blink 6Hz
+	- [1,1,1,0] = Green blink 3Hz
-	[1,1,1,1] = Green blink 6Hz
+	- [0,1,1,1] = Red blink 6Hz
+	- [1,1,1,1] = Green blink 6Hz
 Driver provides the following LEDs for the system "msn2100":
-  mlxcpld:fan:green
-  mlxcpld:fan:red
+  - mlxcpld:fan:green
-  mlxcpld:psu1:green
+  - mlxcpld:fan:red
-  mlxcpld:psu1:red
+  - mlxcpld:psu1:green
-  mlxcpld:psu2:green
+  - mlxcpld:psu1:red
-  mlxcpld:psu2:red
+  - mlxcpld:psu2:green
-  mlxcpld:status:green
+  - mlxcpld:psu2:red
-  mlxcpld:status:red
+  - mlxcpld:status:green
-  mlxcpld:uid:blue
+  - mlxcpld:status:red
+  - mlxcpld:uid:blue
 "status"
-  CPLD reg offset: 0x20
+  - CPLD reg offset: 0x20
-  Bits [3:0]
+  - Bits [3:0]
 "fan"
-  CPLD reg offset: 0x21
+  - CPLD reg offset: 0x21
-  Bits [3:0]
+  - Bits [3:0]
 "psu1"
-  CPLD reg offset: 0x23
+  - CPLD reg offset: 0x23
-  Bits [3:0]
+  - Bits [3:0]
 "psu2"
-  CPLD reg offset: 0x23
+  - CPLD reg offset: 0x23
-  Bits [7:4]
+  - Bits [7:4]
 "uid"
-  CPLD reg offset: 0x24
+  - CPLD reg offset: 0x24
-  Bits [3:0]
+  - Bits [3:0]
 Color mask for all the above LEDs, excepted uid:
  [bit3,bit2,bit1,bit0] or
  [bit7,bit6,bit5,bit4]:
-	[0,0,0,0] = LED OFF
-	[0,1,0,1] = Red static ON
+	- [0,0,0,0] = LED OFF
-	[1,1,0,1] = Green static ON
+	- [0,1,0,1] = Red static ON
-	[0,1,1,0] = Red blink 3Hz
+	- [1,1,0,1] = Green static ON
-	[1,1,1,0] = Green blink 3Hz
+	- [0,1,1,0] = Red blink 3Hz
-	[0,1,1,1] = Red blink 6Hz
+	- [1,1,1,0] = Green blink 3Hz
-	[1,1,1,1] = Green blink 6Hz
+	- [0,1,1,1] = Red blink 6Hz
+	- [1,1,1,1] = Green blink 6Hz
 Color mask for uid LED:
  [bit3,bit2,bit1,bit0]:
-	[0,0,0,0] = LED OFF
-	[1,1,0,1] = Blue static ON
+	- [0,0,0,0] = LED OFF
-	[1,1,1,0] = Blue blink 3Hz
+	- [1,1,0,1] = Blue static ON
-	[1,1,1,1] = Blue blink 6Hz
+	- [1,1,1,0] = Blue blink 3Hz
+	- [1,1,1,1] = Blue blink 6Hz
 Driver supports HW blinking at 3Hz and 6Hz frequency (50% duty cycle).
 For 3Hz duty cylce is about 167 msec, for 6Hz is about 83 msec.
--- a/Documentation/leds/ledtrig-oneshot.txt
+++ b/Documentation/leds/ledtrig-oneshot.txt
+====================
 One-shot LED Trigger
 ====================
@@ -17,27 +18,27 @@ additional "invert" property specifies if the LED has to stay off (normal) or
 on (inverted) when not rearmed.
 The trigger can be activated from user space on led class devices as shown
-below:
+below::
  echo oneshot > trigger
 This adds sysfs attributes to the LED that are documented in:
 Documentation/ABI/testing/sysfs-class-led-trigger-oneshot
-Example use-case: network devices, initialization:
+Example use-case: network devices, initialization::
  echo oneshot > trigger # set trigger for this led
  echo 33 > delay_on     # blink at 1 / (33 + 33) Hz on continuous traffic
  echo 33 > delay_off
-interface goes up:
+interface goes up::
  echo 1 > invert # set led as normally-on, turn the led on
-packet received/transmitted:
+packet received/transmitted::
  echo 1 > shot # led starts blinking, ignored if already blinking
-interface goes down
+interface goes down::
  echo 0 > invert # set led as normally-off, turn the led off
--- a/Documentation/leds/ledtrig-transient.txt
+++ b/Documentation/leds/ledtrig-transient.txt
+=====================
 LED Transient Trigger
 =====================
@@ -62,12 +63,13 @@ non-transient state. When driver gets suspended, irrespective of the transient
 state, the LED state changes to LED_OFF.
 Transient trigger can be enabled and disabled from user space on led class
-devices, that support this trigger as shown below:
+devices, that support this trigger as shown below::
-echo transient > trigger
+	echo transient > trigger
-echo none > trigger
+	echo none > trigger
-NOTE: Add a new property trigger state to control the state.
+NOTE:
+	Add a new property trigger state to control the state.
 This trigger exports three properties, activate, state, and duration. When
 transient trigger is activated these properties are set to default values.
@@ -79,7 +81,8 @@ transient trigger is activated these properties are set to default values.
 - state allows user to specify a transient state to be held for the specified
  duration.
-	activate - one shot timer activate mechanism.
+	activate
+	      - one shot timer activate mechanism.
 		1 when activated, 0 when deactivated.
 		default value is zero when transient trigger is enabled,
 		to allow duration to be set.
@@ -89,12 +92,14 @@ transient trigger is activated these properties are set to default values.
 		deactivated state indicates that there is no active timer
 		running.
-	duration - one shot timer value. When activate is set, duration value
+	duration
+	      - one shot timer value. When activate is set, duration value
 		is used to start a timer that runs once. This value doesn't
 		get changed by the trigger unless user does a set via
 		echo new_value > duration
-	state - transient state to be held. It has two values 0 or 1. 0 maps
+	state
+	      - transient state to be held. It has two values 0 or 1. 0 maps
 		to LED_OFF and 1 maps to LED_FULL. The specified state is
 		held for the duration of the one shot timer and then the
 		state gets changed to the non-transient state which is the
@@ -114,39 +119,49 @@ When timer expires activate goes back to deactivated state, duration is left
 at the set value to be used when activate is set at a future time. This will
 allow user app to set the time once and activate it to run it once for the
 specified value as needed. When timer expires, state is restored to the
-non-transient state which is the inverse of the transient state.
+non-transient state which is the inverse of the transient state:
-	echo 1 > activate - starts timer = duration when duration is not 0.
+	=================   ===============================================
-	echo 0 > activate - cancels currently running timer.
+	echo 1 > activate   starts timer = duration when duration is not 0.
-	echo n > duration - stores timer value to be used upon next
+	echo 0 > activate   cancels currently running timer.
-                            activate. Currently active timer if
+	echo n > duration   stores timer value to be used upon next
-                            any, continues to run for the specified time.
+			    activate. Currently active timer if
-	echo 0 > duration - stores timer value to be used upon next
+			    any, continues to run for the specified time.
-                            activate. Currently active timer if any,
+	echo 0 > duration   stores timer value to be used upon next
-                            continues to run for the specified time.
+			    activate. Currently active timer if any,
-	echo 1 > state    - stores desired transient state LED_FULL to be
+			    continues to run for the specified time.
+	echo 1 > state      stores desired transient state LED_FULL to be
 			    held for the specified duration.
-	echo 0 > state    - stores desired transient state LED_OFF to be
+	echo 0 > state      stores desired transient state LED_OFF to be
 			    held for the specified duration.
+	=================   ===============================================
+What is not supported
+=====================
-What is not supported:
-======================
 - Timer activation is one shot and extending and/or shortening the timer
  is not supported.
-Example use-case 1:
+Examples
+========
+use-case 1::
 	echo transient > trigger
 	echo n > duration
 	echo 1 > state
-repeat the following step as needed:
+repeat the following step as needed::
 	echo 1 > activate - start timer = duration to run once
 	echo 1 > activate - start timer = duration to run once
 	echo none > trigger
 This trigger is intended to be used for for the following example use cases:
 - Control of vibrate (phones, tablets etc.) hardware by user space app.
 - Use of LED by user space app as activity indicator.
 - Use of LED by user space app as a kind of watchdog indicator -- as
-       long as the app is alive, it can keep the LED illuminated, if it dies
+   long as the app is alive, it can keep the LED illuminated, if it dies
-       the LED will be extinguished automatically.
+   the LED will be extinguished automatically.
 - Use by any user space app that needs a transient GPIO output.
--- a/Documentation/leds/ledtrig-usbport.txt
+++ b/Documentation/leds/ledtrig-usbport.txt
+====================
 USB port LED trigger
 ====================
@@ -10,14 +11,18 @@ listed as separated entries in a "ports" subdirectory. Selecting is handled by
 echoing "1" to a chosen port.
 Please note that this trigger allows selecting multiple USB ports for a single
-LED. This can be useful in two cases:
+LED.
+This can be useful in two cases:
 1) Device with single USB LED and few physical ports
+====================================================
 In such a case LED will be turned on as long as there is at least one connected
 USB device.
 2) Device with a physical port handled by few controllers
+=========================================================
 Some devices may have one controller per PHY standard. E.g. USB 3.0 physical
 port may be handled by ohci-platform, ehci-platform and xhci-hcd. If there is
@@ -25,14 +30,14 @@ only one LED user will most likely want to assign ports from all 3 hubs.
 This trigger can be activated from user space on led class devices as shown
-below:
+below::
  echo usbport > trigger
 This adds sysfs attributes to the LED that are documented in:
 Documentation/ABI/testing/sysfs-class-led-trigger-usbport
-Example use-case:
+Example use-case::
  echo usbport > trigger
  echo 1 > ports/usb1-port1

--- a/Documentation/leds/uleds.txt
+++ b/Documentation/leds/uleds.txt
+==============
 Userspace LEDs
 ==============
@@ -10,12 +11,12 @@ Usage
 When the driver is loaded, a character device is created at /dev/uleds. To
 create a new LED class device, open /dev/uleds and write a uleds_user_dev
-structure to it (found in kernel public header file linux/uleds.h).
+structure to it (found in kernel public header file linux/uleds.h)::
    #define LED_MAX_NAME_SIZE 64
    struct uleds_user_dev {
-        char name[LED_MAX_NAME_SIZE];
+	char name[LED_MAX_NAME_SIZE];
    };
 A new LED class device will be created with the name given. The name can be

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10117,7 +10117,7 @@ L:	linux-leds@vger.kernel.org
 S:	Supported
 F:	drivers/leds/leds-mlxcpld.c
 F:	drivers/leds/leds-mlxreg.c
-F:	Documentation/leds/leds-mlxcpld.txt
+F:	Documentation/leds/leds-mlxcpld.rst
 MELLANOX PLATFORM DRIVER
 M:	Vadim Pasternak <vadimp@mellanox.com>

--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -14,7 +14,7 @@ config LEDS_TRIGGER_TIMER
 	  This allows LEDs to be controlled by a programmable timer
 	  via sysfs. Some LED hardware can be programmed to start
 	  blinking the LED without any further software interaction.
-	  For more details read Documentation/leds/leds-class.txt.
+	  For more details read Documentation/leds/leds-class.rst.
 	  If unsure, say Y.

--- a/drivers/leds/trigger/ledtrig-transient.c
+++ b/drivers/leds/trigger/ledtrig-transient.c
@@ -3,7 +3,7 @@
 // LED Kernel Transient Trigger
 //
 // Transient trigger allows one shot timer activation. Please refer to
-// Documentation/leds/ledtrig-transient.txt for details
+// Documentation/leds/ledtrig-transient.rst for details
 // Copyright (C) 2012 Shuah Khan <shuahkhan@gmail.com>
 //
 // Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's

--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -905,7 +905,7 @@ config NETFILTER_XT_TARGET_LED
 	    echo netfilter-ssh > /sys/class/leds/<ledname>/trigger
 	  For more information on the LEDs available on your system, see
-	  Documentation/leds/leds-class.txt
+	  Documentation/leds/leds-class.rst
 config NETFILTER_XT_TARGET_LOG
 	tristate "LOG target support"