code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-lp55xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: TI/National Semiconductor LP55xx and LP8501 LED Drivers

maintainers:
  - Jacek Anaszewski <jacek.anaszewski@gmail.com>
  - Pavel Machek <pavel@ucw.cz>

description: |
  Bindings for the TI/National Semiconductor LP55xx and LP8501 multi channel
  LED Drivers.

  For more product information please see the link below:
    https://www.ti.com/lit/gpn/lp5521
    https://www.ti.com/lit/gpn/lp5523
    https://www.ti.com/lit/gpn/lp55231
    https://www.ti.com/lit/gpn/lp5562
    https://www.ti.com/lit/gpn/lp8501

properties:
  compatible:
    enum:
      - national,lp5521
      - national,lp5523
      - ti,lp55231
      - ti,lp5562
      - ti,lp8501

  reg:
    maxItems: 1
    description: I2C slave address

  clock-mode:
    $ref: /schemas/types.yaml#/definitions/uint8
    description: |
      Input clock mode
    enum:
      - 0 # automode
      - 1 # internal
      - 2 # external

  enable-gpios:
    maxItems: 1
    description: |
      GPIO attached to the chip's enable pin

  label: true

  pwr-sel:
    $ref: /schemas/types.yaml#/definitions/uint8
    description: |
      LP8501 specific property. Power selection for output channels.
    enum:
      - 0 # D1~9 are connected to VDD
      - 1 # D1~6 with VDD, D7~9 with VOUT
      - 2 # D1~6 with VOUT, D7~9 with VDD
      - 3 # D1~9 are connected to VOUT

  '#address-cells':
    const: 1

  '#size-cells':
    const: 0

patternProperties:
  '^multi-led@[0-8]$':
    type: object
    $ref: leds-class-multicolor.yaml#
    unevaluatedProperties: false

    properties:
      reg:
        maximum: 8

      '#address-cells':
        const: 1

      '#size-cells':
        const: 0

    patternProperties:
      "^led@[0-8]$":
        type: object
        $ref: common.yaml#
        unevaluatedProperties: false

        properties:
          led-cur:
            $ref: /schemas/types.yaml#/definitions/uint8
            description: |
              Current setting at each LED channel (mA x10, 0 if LED is not connected)
            minimum: 0
            maximum: 255

          max-cur:
            $ref: /schemas/types.yaml#/definitions/uint8
            description: Maximun current at each LED channel.

          reg:
            maximum: 8

        required:
          - reg

  "^led@[0-8]$":
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      led-cur:
        $ref: /schemas/types.yaml#/definitions/uint8
        description: |
          Current setting at each LED channel (mA x10, 0 if LED is not connected)
        minimum: 0
        maximum: 255

      max-cur:
        $ref: /schemas/types.yaml#/definitions/uint8
        description: Maximun current at each LED channel.

      reg:
        description: |
          Output channel for the LED.  This is zero based channel identifier and
          the data sheet is a one based channel identifier.
          reg value to output to LED output number
        enum:
          - 0 # LED output D1
          - 1 # LED output D2
          - 2 # LED output D3
          - 3 # LED output D4
          - 4 # LED output D5
          - 5 # LED output D6
          - 6 # LED output D7
          - 7 # LED output D8
          - 8 # LED output D9

      chan-name:
        $ref: /schemas/types.yaml#/definitions/string
        description: name of channel

required:
  - compatible
  - reg

additionalProperties: false

examples:
  - |
    #include <dt-bindings/leds/common.h>

    i2c {
        #address-cells = <1>;
        #size-cells = <0>;

        led-controller@32 {
            #address-cells = <1>;
            #size-cells = <0>;
            compatible = "ti,lp8501";
            reg = <0x32>;
            clock-mode = /bits/ 8 <2>;
            pwr-sel = /bits/ 8 <3>;	/* D1~9 connected to VOUT */

            led@0 {
                reg = <0>;
                chan-name = "d1";
                led-cur = /bits/ 8 <0x14>;
                max-cur = /bits/ 8 <0x20>;
            };

            led@1 {
                reg = <1>;
                chan-name = "d2";
                led-cur = /bits/ 8 <0x14>;
                max-cur = /bits/ 8 <0x20>;
            };

            led@2 {
                reg = <2>;
                chan-name = "d3";
                led-cur = /bits/ 8 <0x14>;
                max-cur = /bits/ 8 <0x20>;
            };

            led@3 {
                reg = <3>;
                chan-name = "d4";
                led-cur = /bits/ 8 <0x14>;
                max-cur = /bits/ 8 <0x20>;
            };

            led@4 {
                reg = <4>;
                chan-name = "d5";
                led-cur = /bits/ 8 <0x14>;
                max-cur = /bits/ 8 <0x20>;
            };

            led@5 {
                reg = <5>;
                chan-name = "d6";
                led-cur = /bits/ 8 <0x14>;
                max-cur = /bits/ 8 <0x20>;
            };

            led@6 {
                reg = <6>;
                chan-name = "d7";
                led-cur = /bits/ 8 <0x14>;
                max-cur = /bits/ 8 <0x20>;
            };

            led@7 {
                reg = <7>;
                chan-name = "d8";
                led-cur = /bits/ 8 <0x14>;
                max-cur = /bits/ 8 <0x20>;
            };

            led@8 {
                reg = <8>;
                chan-name = "d9";
                led-cur = /bits/ 8 <0x14>;
                max-cur = /bits/ 8 <0x20>;
            };
        };

        led-controller@33 {
            #address-cells = <1>;
            #size-cells = <0>;
            compatible = "national,lp5523";
            reg = <0x33>;
            clock-mode = /bits/ 8 <0>;

            multi-led@2 {
                #address-cells = <1>;
                #size-cells = <0>;
                reg = <0x2>;
                color = <LED_COLOR_ID_RGB>;
                function = LED_FUNCTION_STANDBY;
                linux,default-trigger = "heartbeat";

                led@0 {
                    led-cur = /bits/ 8 <50>;
                    max-cur = /bits/ 8 <100>;
                    reg = <0x0>;
                    color = <LED_COLOR_ID_GREEN>;
                };

                led@1 {
                    led-cur = /bits/ 8 <50>;
                    max-cur = /bits/ 8 <100>;
                    reg = <0x1>;
                    color = <LED_COLOR_ID_BLUE>;
                };

                led@6 {
                    led-cur = /bits/ 8 <50>;
                    max-cur = /bits/ 8 <100>;
                    reg = <0x6>;
                    color = <LED_COLOR_ID_RED>;
                };
            };
        };
    };

...


code:
* Texas Instruments - lp8860 4-Channel LED Driver

The LP8860-Q1 is an high-efficiency LED
driver with boost controller. It has 4 high-precision
current sinks that can be controlled by a PWM input
signal, a SPI/I2C master, or both.

Required properties:
	- compatible :
		"ti,lp8860"
	- reg : I2C slave address
	- #address-cells : 1
	- #size-cells : 0

Optional properties:
	- enable-gpios : gpio pin to enable (active high)/disable the device.
	- vled-supply : LED supply

Required child properties:
	- reg : 0

Optional child properties:
	- function : see Documentation/devicetree/bindings/leds/common.txt
	- color : see Documentation/devicetree/bindings/leds/common.txt
	- label : see Documentation/devicetree/bindings/leds/common.txt (deprecated)
	- linux,default-trigger :
	   see Documentation/devicetree/bindings/leds/common.txt

Example:

#include <dt-bindings/leds/common.h>

led-controller@2d {
	compatible = "ti,lp8860";
	#address-cells = <1>;
	#size-cells = <0>;
	reg = <0x2d>;
	enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
	vled-supply = <&vbatt>;

	led@0 {
		reg = <0>;
		function = LED_FUNCTION_BACKLIGHT;
		color = <LED_COLOR_ID_WHITE>;
		linux,default-trigger = "backlight";
	};
}

For more product information please see the link below:
https://www.ti.com/product/lp8860-q1

repo_name: angery/linux


code:
Bindings for Linear Technologies LT3593 LED controller

Required properties:
- compatible:		Should be "lltc,lt3593".
- lltc,ctrl-gpios:	A handle to the GPIO that is connected to the 'CTRL'
			pin of the chip.

The hardware supports only one LED. The properties of this LED are
configured in a sub-node in the device node.

Optional sub-node properties:
- function:		See Documentation/devicetree/bindings/leds/common.txt
- color:		See Documentation/devicetree/bindings/leds/common.txt
- label:		A label for the LED. If none is given, the LED will be
			named "lt3595::" (deprecated)
- linux,default-trigger: The default trigger for the LED.
			See Documentation/devicetree/bindings/leds/common.txt
- default-state:	The initial state of the LED.
			See Documentation/devicetree/bindings/leds/common.txt

If multiple chips of this type are found in a design, each one needs to
be handled by its own device node.

Example:

#include <dt-bindings/leds/common.h>

led-controller {
	compatible = "lltc,lt3593";
	lltc,ctrl-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;

	led {
		function = LED_FUNCTION_BACKLIGHT;
		color = <LED_COLOR_ID_WHITE>;
		default-state = "on";
	};
};


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-max77650.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: LED driver for MAX77650 PMIC from Maxim Integrated.

maintainers:
  - Bartosz Golaszewski <bgolaszewski@baylibre.com>

description: |
  This module is part of the MAX77650 MFD device. For more details
  see Documentation/devicetree/bindings/mfd/max77650.yaml.

  The LED controller is represented as a sub-node of the PMIC node on
  the device tree.

  This device has three current sinks.

properties:
  compatible:
    const: maxim,max77650-led

  "#address-cells":
    const: 1

  "#size-cells":
    const: 0

patternProperties:
  "^led@[0-2]$":
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      reg:
        description:
          Index of the LED.
        minimum: 0
        maximum: 2

required:
  - compatible
  - "#address-cells"
  - "#size-cells"
additionalProperties: false

...


code:
Device Tree Bindings for LED support on MT6323 PMIC

MT6323 LED controller is subfunction provided by MT6323 PMIC, so the LED
controllers are defined as the subnode of the function node provided by MT6323
PMIC controller that is being defined as one kind of Muti-Function Device (MFD)
using shared bus called PMIC wrapper for each subfunction to access remote
MT6323 PMIC hardware.

For MT6323 MFD bindings see:
Documentation/devicetree/bindings/mfd/mt6397.txt
For MediaTek PMIC wrapper bindings see:
Documentation/devicetree/bindings/soc/mediatek/pwrap.txt

Required properties:
- compatible : Must be "mediatek,mt6323-led"
- address-cells : Must be 1
- size-cells : Must be 0

Each led is represented as a child node of the mediatek,mt6323-led that
describes the initial behavior for each LED physically and currently only four
LED child nodes can be supported.

Required properties for the LED child node:
- reg : LED channel number (0..3)

Optional properties for the LED child node:
- label : See Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : See Documentation/devicetree/bindings/leds/common.txt
- default-state: See Documentation/devicetree/bindings/leds/common.txt

Example:

	mt6323: pmic {
		compatible = "mediatek,mt6323";

		...

		mt6323led: leds {
			compatible = "mediatek,mt6323-led";
			#address-cells = <1>;
			#size-cells = <0>;

			led@0 {
				reg = <0>;
				label = "LED0";
				linux,default-trigger = "timer";
				default-state = "on";
			};
			led@1 {
				reg = <1>;
				label = "LED1";
				default-state = "off";
			};
			led@2 {
				reg = <2>;
				label = "LED2";
				default-state = "on";
			};
		};
	};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-mt6360.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: LED driver for MT6360 PMIC from MediaTek Integrated.

maintainers:
  - Gene Chen <gene_chen@richtek.com>

description: |
  This module is part of the MT6360 MFD device.
  see Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml
  Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
  and 4-channel RGB LED support Register/Flash/Breath Mode

properties:
  compatible:
    const: mediatek,mt6360-led

  "#address-cells":
    const: 1

  "#size-cells":
    const: 0

patternProperties:
  "^multi-led@[0-5]$":
    type: object
    $ref: leds-class-multicolor.yaml#
    unevaluatedProperties: false

    properties:
      reg:
        description: Index of the LED.
        enum:
          - 0 # LED output ISINK1
          - 1 # LED output ISINK2
          - 2 # LED output ISINK3
          - 3 # LED output ISINKML
          - 4 # LED output FLASH1
          - 5 # LED output FLASH2

      "#address-cells":
        const: 1

      "#size-cells":
        const: 0

    patternProperties:
      "^led@[0-2]$":
        type: object
        $ref: common.yaml#
        unevaluatedProperties: false

        properties:
          reg:
            enum: [0, 1, 2]

        required:
          - reg
          - color

    required:
      - reg
      - "#address-cells"
      - "#size-cells"

  "^led@[0-5]$":
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false
    description:
      Properties for a single LED.

    properties:
      reg:
        enum: [0, 1, 2, 3, 4, 5]

required:
  - compatible
  - "#address-cells"
  - "#size-cells"

additionalProperties: false

examples:
  - |
   #include <dt-bindings/leds/common.h>
   led-controller {
     compatible = "mediatek,mt6360-led";
     #address-cells = <1>;
     #size-cells = <0>;

     multi-led@0 {
       reg = <0>;
       function = LED_FUNCTION_INDICATOR;
       color = <LED_COLOR_ID_RGB>;
       led-max-microamp = <24000>;
       #address-cells = <1>;
       #size-cells = <0>;
       led@0 {
         reg = <0>;
         color = <LED_COLOR_ID_RED>;
       };
       led@1 {
         reg = <1>;
         color = <LED_COLOR_ID_GREEN>;
       };
       led@2 {
         reg = <2>;
         color = <LED_COLOR_ID_BLUE>;
       };
     };
     led@3 {
       reg = <3>;
       function = LED_FUNCTION_INDICATOR;
       color = <LED_COLOR_ID_WHITE>;
       led-max-microamp = <150000>;
     };
     led@4 {
       reg = <4>;
       function = LED_FUNCTION_FLASH;
       color = <LED_COLOR_ID_WHITE>;
       function-enumerator = <1>;
       led-max-microamp = <200000>;
       flash-max-microamp = <500000>;
       flash-max-timeout-us = <1024000>;
     };
     led@5 {
       reg = <5>;
       function = LED_FUNCTION_FLASH;
       color = <LED_COLOR_ID_WHITE>;
       function-enumerator = <2>;
       led-max-microamp = <200000>;
       flash-max-microamp = <500000>;
       flash-max-timeout-us = <1024000>;
     };
   };

  - |

   led-controller {
     compatible = "mediatek,mt6360-led";
     #address-cells = <1>;
     #size-cells = <0>;

     led@0 {
       reg = <0>;
       function = LED_FUNCTION_INDICATOR;
       color = <LED_COLOR_ID_RED>;
       led-max-microamp = <24000>;
     };
     led@1 {
       reg = <1>;
       function = LED_FUNCTION_INDICATOR;
       color = <LED_COLOR_ID_GREEN>;
       led-max-microamp = <24000>;
     };
     led@2 {
       reg = <2>;
       function = LED_FUNCTION_INDICATOR;
       color = <LED_COLOR_ID_BLUE>;
       led-max-microamp = <24000>;
     };
     led@3 {
       reg = <3>;
       function = LED_FUNCTION_INDICATOR;
       color = <LED_COLOR_ID_WHITE>;
       led-max-microamp = <150000>;
     };
     led@4 {
       reg = <4>;
       function = LED_FUNCTION_FLASH;
       color = <LED_COLOR_ID_WHITE>;
       function-enumerator = <1>;
       led-max-microamp = <200000>;
       flash-max-microamp = <500000>;
       flash-max-timeout-us = <1024000>;
     };
     led@5 {
       reg = <5>;
       function = LED_FUNCTION_FLASH;
       color = <LED_COLOR_ID_WHITE>;
       function-enumerator = <2>;
       led-max-microamp = <200000>;
       flash-max-microamp = <500000>;
       flash-max-timeout-us = <1024000>;
     };
   };
...


code:
Binding for the CPLD LEDs (GPIO extension bus) found on some LaCie/Seagate
boards (Example: 2Big/5Big Network v2, 2Big NAS).

Required properties:
- compatible: "lacie,netxbig-leds".
- gpio-ext: Phandle for the gpio-ext bus.

Optional properties:
- timers: Timer array. Each timer entry is represented by three integers:
  Mode (gpio-ext bus), delay_on and delay_off.

Each LED is represented as a sub-node of the netxbig-leds device.

Required sub-node properties:
- mode-addr: Mode register address on gpio-ext bus.
- mode-val: Mode to value mapping. Each entry is represented by two integers:
  A mode and the corresponding value on the gpio-ext bus.
- bright-addr: Brightness register address on gpio-ext bus.
- max-brightness: Maximum brightness value.

Optional sub-node properties:
- label: Name for this LED. If omitted, the label is taken from the node name.
- linux,default-trigger: Trigger assigned to the LED.

Example:

netxbig-leds {
	compatible = "lacie,netxbig-leds";

	gpio-ext = &gpio_ext;

	timers = <NETXBIG_LED_TIMER1 500 500
		  NETXBIG_LED_TIMER2 500 1000>;

	blue-power {
		label = "netxbig:blue:power";
		mode-addr = <0>;
		mode-val = <NETXBIG_LED_OFF 0
			    NETXBIG_LED_ON 1
			    NETXBIG_LED_TIMER1 3
			    NETXBIG_LED_TIMER2 7>;
		bright-addr = <1>;
		max-brightness = <7>;
	};
	red-power {
		label = "netxbig:red:power";
		mode-addr = <0>;
		mode-val = <NETXBIG_LED_OFF 0
			    NETXBIG_LED_ON 2
			    NETXBIG_LED_TIMER1 4>;
		bright-addr = <1>;
		max-brightness = <7>;
	};
	blue-sata0 {
		label = "netxbig:blue:sata0";
		mode-addr = <3>;
		mode-val = <NETXBIG_LED_OFF 0
			    NETXBIG_LED_ON 7
			    NETXBIG_LED_SATA 1
			    NETXBIG_LED_TIMER1 3>;
		bright-addr = <2>;
		max-brightness = <7>;
	};
	red-sata0 {
		label = "netxbig:red:sata0";
		mode-addr = <3>;
		mode-val = <NETXBIG_LED_OFF 0
			    NETXBIG_LED_ON 2
			    NETXBIG_LED_TIMER1 4>;
		bright-addr = <2>;
		max-brightness = <7>;
	};
	blue-sata1 {
		label = "netxbig:blue:sata1";
		mode-addr = <4>;
		mode-val = <NETXBIG_LED_OFF 0
			    NETXBIG_LED_ON 7
			    NETXBIG_LED_SATA 1
			    NETXBIG_LED_TIMER1 3>;
		bright-addr = <2>;
		max-brightness = <7>;
	};
	red-sata1 {
		label = "netxbig:red:sata1";
		mode-addr = <4>;
		mode-val = <NETXBIG_LED_OFF 0
			    NETXBIG_LED_ON 2
			    NETXBIG_LED_TIMER1 4>;
		bright-addr = <2>;
		max-brightness = <7>;
	};
};


code:
Binding for dual-GPIO LED found on Network Space v2 (and parents).

Required properties:
- compatible: "lacie,ns2-leds".

Each LED is represented as a sub-node of the ns2-leds device.

Required sub-node properties:
- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
- modes-map: A mapping between LED modes (off, on or SATA activity blinking) and
  the corresponding cmd-gpio/slow-gpio values. All the GPIO values combinations
  should be given in order to avoid having an unknown mode at driver probe time.

Optional sub-node properties:
- label: Name for this LED. If omitted, the label is taken from the node name.
- linux,default-trigger: Trigger assigned to the LED.

Example:

#include <dt-bindings/leds/leds-ns2.h>

ns2-leds {
	compatible = "lacie,ns2-leds";

	blue-sata {
		label = "ns2:blue:sata";
		slow-gpio = <&gpio0 29 0>;
		cmd-gpio = <&gpio0 30 0>;
		modes-map = <NS_V2_LED_OFF  0 1
			     NS_V2_LED_ON   1 0
			     NS_V2_LED_ON   0 0
			     NS_V2_LED_SATA 1 1>;
	};
};


code:
*NXP - pca9532 PWM LED Driver

The PCA9532 family is SMBus I/O expander optimized for dimming LEDs.
The PWM support 256 steps.

Required properties:
	- compatible:
		"nxp,pca9530"
		"nxp,pca9531"
		"nxp,pca9532"
		"nxp,pca9533"
	- reg -  I2C slave address

Each led is represented as a sub-node of the nxp,pca9530.

Optional sub-node properties:
	- label: see Documentation/devicetree/bindings/leds/common.txt
	- type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE)
	- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
	- default-state: see Documentation/devicetree/bindings/leds/common.txt
	  This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>.

Example:
  #include <dt-bindings/leds/leds-pca9532.h>

  leds: pca9530@60 {
    compatible = "nxp,pca9530";
    reg = <0x60>;

    red-power {
      label = "pca:red:power";
      type = <PCA9532_TYPE_LED>;
    };
    green-power {
      label = "pca:green:power";
      type = <PCA9532_TYPE_LED>;
    };
    kernel-booting {
      type = <PCA9532_TYPE_LED>;
      default-state = "on";
    };
    sys-stat {
      type = <PCA9532_TYPE_LED>;
      default-state = "keep"; // don't touch, was set by U-Boot
    };
  };

For more product information please see the link below:
http://nxp.com/documents/data_sheet/PCA9532.pdf


code:
* NXP - pca955x LED driver

The PCA955x family of chips are I2C LED blinkers whose pins not used
to control LEDs can be used as general purpose I/Os. The GPIO pins can
be input or output, and output pins can also be pulse-width controlled.

Required properties:
- compatible : should be one of :
	"nxp,pca9550"
	"nxp,pca9551"
	"nxp,pca9552"
	"ibm,pca9552"
	"nxp,pca9553"
- #address-cells: must be 1
- #size-cells: must be 0
- reg: I2C slave address. depends on the model.

Optional properties:
- gpio-controller: allows pins to be used as GPIOs.
- #gpio-cells: must be 2.
- gpio-line-names: define the names of the GPIO lines

LED sub-node properties:
- reg : number of LED line.
		from 0 to  1 for the pca9550
		from 0 to  7 for the pca9551
		from 0 to 15 for the pca9552
		from 0 to  3 for the pca9553
- type: (optional) either
	PCA955X_TYPE_NONE
	PCA955X_TYPE_LED
	PCA955X_TYPE_GPIO
	see dt-bindings/leds/leds-pca955x.h (default to LED)
- label : (optional)
	see Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : (optional)
	see Documentation/devicetree/bindings/leds/common.txt

Examples:

pca9552: pca9552@60 {
	compatible = "nxp,pca9552";
	#address-cells = <1>;
        #size-cells = <0>;
	reg = <0x60>;

	gpio-controller;
	#gpio-cells = <2>;
	gpio-line-names = "GPIO12", "GPIO13", "GPIO14", "GPIO15";

	gpio@12 {
		reg = <12>;
		type = <PCA955X_TYPE_GPIO>;
	};
	gpio@13 {
		reg = <13>;
		type = <PCA955X_TYPE_GPIO>;
	};
	gpio@14 {
		reg = <14>;
		type = <PCA955X_TYPE_GPIO>;
	};
	gpio@15 {
		reg = <15>;
		type = <PCA955X_TYPE_GPIO>;
	};

	led@0 {
		label = "red:power";
		linux,default-trigger = "default-on";
		reg = <0>;
		type = <PCA955X_TYPE_LED>;
	};
	led@1 {
		label = "green:power";
		reg = <1>;
		type = <PCA955X_TYPE_LED>;
	};
	led@2 {
		label = "pca9552:yellow";
		reg = <2>;
		type = <PCA955X_TYPE_LED>;
	};
	led@3 {
		label = "pca9552:white";
		reg = <3>;
		type = <PCA955X_TYPE_LED>;
	};
};


code:
Device Tree binding for LEDs on IBM Power Systems
-------------------------------------------------

Required properties:
- compatible : Should be "ibm,opal-v3-led".
- led-mode   : Should be "lightpath" or "guidinglight".

Each location code of FRU/Enclosure must be expressed in the
form of a sub-node.

Required properties for the sub nodes:
- led-types : Supported LED types (attention/identify/fault) provided
              in the form of string array.

Example:

leds {
	compatible = "ibm,opal-v3-led";
	led-mode = "lightpath";

	U78C9.001.RST0027-P1-C1 {
		led-types = "identify", "fault";
	};
	...
	...
};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-pwm-multicolor.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Multi-color LEDs connected to PWM

maintainers:
  - Sven Schwermer <sven.schwermer@disruptive-technologies.com>

description: |
  This driver combines several monochrome PWM LEDs into one multi-color
  LED using the multicolor LED class.

properties:
  compatible:
    const: pwm-leds-multicolor

  multi-led:
    type: object
    $ref: leds-class-multicolor.yaml#
    unevaluatedProperties: false

    properties:
      max-brightness:
        description:
          Maximum brightness possible for the LED
        $ref: /schemas/types.yaml#/definitions/uint32

    patternProperties:
      "^led-[0-9a-z]+$":
        type: object
        $ref: common.yaml#

        additionalProperties: false

        properties:
          pwms:
            maxItems: 1

          pwm-names: true

          active-low:
            description: For PWMs where the LED is wired to supply rather than ground.
            type: boolean

          color: true

        required:
          - pwms
          - color

required:
  - compatible

additionalProperties: false

examples:
  - |
    #include <dt-bindings/leds/common.h>

    led-controller {
        compatible = "pwm-leds-multicolor";

        multi-led {
            color = <LED_COLOR_ID_RGB>;
            function = LED_FUNCTION_INDICATOR;
            max-brightness = <65535>;

            led-red {
                pwms = <&pwm1 0 1000000>;
                color = <LED_COLOR_ID_RED>;
            };

            led-green {
                pwms = <&pwm2 0 1000000>;
                color = <LED_COLOR_ID_GREEN>;
            };

            led-blue {
                pwms = <&pwm3 0 1000000>;
                color = <LED_COLOR_ID_BLUE>;
            };
        };
    };

...


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-pwm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: LEDs connected to PWM

maintainers:
  - Pavel Machek <pavel@ucw.cz>

description:
  Each LED is represented as a sub-node of the pwm-leds device.  Each
  node's name represents the name of the corresponding LED.

properties:
  compatible:
    const: pwm-leds

patternProperties:
  "^led(-[0-9a-f]+)?$":
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      pwms:
        maxItems: 1

      pwm-names: true

      max-brightness:
        description:
          Maximum brightness possible for the LED
        $ref: /schemas/types.yaml#/definitions/uint32

      active-low:
        description:
          For PWMs where the LED is wired to supply rather than ground.
        type: boolean

    required:
      - pwms
      - max-brightness

additionalProperties: false

examples:
  - |

    #include <dt-bindings/leds/common.h>

    led-controller {
        compatible = "pwm-leds";

        led-1 {
            label = "omap4::keypad";
            pwms = <&twl_pwm 0 7812500>;
            max-brightness = <127>;
        };

        led-2 {
            color = <LED_COLOR_ID_GREEN>;
            function = LED_FUNCTION_CHARGING;
            pwms = <&twl_pwmled 0 7812500>;
            max-brightness = <255>;
        };
    };

...


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-qcom-lpg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Qualcomm Light Pulse Generator

maintainers:
  - Bjorn Andersson <bjorn.andersson@linaro.org>

description: >
  The Qualcomm Light Pulse Generator consists of three different hardware blocks;
  a ramp generator with lookup table, the light pulse generator and a three
  channel current sink. These blocks are found in a wide range of Qualcomm PMICs.

properties:
  compatible:
    enum:
      - qcom,pm660l-lpg
      - qcom,pm8150b-lpg
      - qcom,pm8150l-lpg
      - qcom,pm8350c-pwm
      - qcom,pm8916-pwm
      - qcom,pm8941-lpg
      - qcom,pm8994-lpg
      - qcom,pmc8180c-lpg
      - qcom,pmi8994-lpg
      - qcom,pmi8998-lpg

  "#pwm-cells":
    const: 2

  "#address-cells":
    const: 1

  "#size-cells":
    const: 0

  qcom,power-source:
    $ref: /schemas/types.yaml#/definitions/uint32
    description:
      power-source used to drive the output, as defined in the datasheet.
      Should be specified if the TRILED block is present
    enum: [0, 1, 3]

  qcom,dtest:
    $ref: /schemas/types.yaml#/definitions/uint32-matrix
    description: >
      A list of integer pairs, where each pair represent the dtest line the
      particular channel should be connected to and the flags denoting how the
      value should be outputed, as defined in the datasheet. The number of
      pairs should be the same as the number of channels.
    items:
      items:
        - description: dtest line to attach
        - description: flags for the attachment

  multi-led:
    type: object
    $ref: leds-class-multicolor.yaml#
    unevaluatedProperties: false

    properties:
      "#address-cells":
        const: 1

      "#size-cells":
        const: 0

    patternProperties:
      "^led@[0-9a-f]$":
        type: object
        $ref: common.yaml#
        unevaluatedProperties: false

        properties:
          reg:
            maxItems: 1

        required:
          - reg

patternProperties:
  "^led@[0-9a-f]$":
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      reg:
        maxItems: 1

    required:
      - reg

required:
  - compatible

additionalProperties: false

examples:
  - |
    #include <dt-bindings/leds/common.h>

    led-controller {
      compatible = "qcom,pmi8994-lpg";

      #address-cells = <1>;
      #size-cells = <0>;

      qcom,power-source = <1>;

      qcom,dtest = <0 0>,
                   <0 0>,
                   <0 0>,
                   <4 1>;

      led@1 {
        reg = <1>;
        color = <LED_COLOR_ID_GREEN>;
        function = LED_FUNCTION_INDICATOR;
        function-enumerator = <1>;
      };

      led@2 {
        reg = <2>;
        color = <LED_COLOR_ID_GREEN>;
        function = LED_FUNCTION_INDICATOR;
        function-enumerator = <0>;
        default-state = "on";
      };

      led@3 {
        reg = <3>;
        color = <LED_COLOR_ID_GREEN>;
        function = LED_FUNCTION_INDICATOR;
        function-enumerator = <2>;
      };

      led@4 {
        reg = <4>;
        color = <LED_COLOR_ID_GREEN>;
        function = LED_FUNCTION_INDICATOR;
        function-enumerator = <3>;
      };
    };
  - |
    #include <dt-bindings/leds/common.h>

    led-controller {
      compatible = "qcom,pmi8994-lpg";

      #address-cells = <1>;
      #size-cells = <0>;

      qcom,power-source = <1>;

      multi-led {
        color = <LED_COLOR_ID_RGB>;
        function = LED_FUNCTION_STATUS;

        #address-cells = <1>;
        #size-cells = <0>;

        led@1 {
          reg = <1>;
          color = <LED_COLOR_ID_RED>;
        };

        led@2 {
          reg = <2>;
          color = <LED_COLOR_ID_GREEN>;
        };

        led@3 {
          reg = <3>;
          color = <LED_COLOR_ID_BLUE>;
        };
      };
    };
  - |
    pwm-controller {
      compatible = "qcom,pm8916-pwm";
      #pwm-cells = <2>;
    };
...


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-rt4505.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Richtek RT4505 Single Channel LED Driver

maintainers:
  - ChiYuan Huang <cy_huang@richtek.com>

description: |
  The RT4505 is a flash LED driver that can support up to 375mA and 1.5A for
  torch and flash mode, respectively.

  The data sheet can be found at:
    https://www.richtek.com/assets/product_file/RT4505/DS4505-02.pdf

properties:
  compatible:
    const: richtek,rt4505

  reg:
    description: I2C slave address of the controller.
    maxItems: 1

  led:
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false

required:
  - compatible
  - reg

additionalProperties: false

examples:
  - |
    #include <dt-bindings/leds/common.h>

    i2c0 {
      #address-cells = <1>;
      #size-cells = <0>;

      led-controller@63 {
        compatible = "richtek,rt4505";
        reg = <0x63>;

        rt4505_flash: led {
          function = LED_FUNCTION_FLASH;
          color = <LED_COLOR_ID_WHITE>;
          led-max-microamp = <375000>;
          flash-max-microamp = <1500000>;
          flash-max-timeout-us = <800000>;
        };
      };
    };


code:
LEDs connected to Spreadtrum SC27XX PMIC breathing light controller

The SC27xx breathing light controller supports to 3 outputs:
red LED, green LED and blue LED. Each LED can work at normal
PWM mode or breath light mode.

Required properties:
- compatible: Should be "sprd,sc2731-bltc".
- #address-cells: Must be 1.
- #size-cells: Must be 0.
- reg: Specify the controller address.

Required child properties:
- reg: Port this LED is connected to.

Optional child properties:
- function: See Documentation/devicetree/bindings/leds/common.txt.
- color: See Documentation/devicetree/bindings/leds/common.txt.
- label: See Documentation/devicetree/bindings/leds/common.txt (deprecated).

Examples:

led-controller@200 {
	compatible = "sprd,sc2731-bltc";
	#address-cells = <1>;
	#size-cells = <0>;
	reg = <0x200>;

	led@0 {
		color = <LED_COLOR_ID_RED>;
		reg = <0x0>;
	};

	led@1 {
		color = <LED_COLOR_ID_GREEN>;
		reg = <0x1>;
	};

	led@2 {
		color = <LED_COLOR_ID_BLUE>;
		reg = <0x2>;
	};
};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-sgm3140.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: SGMICRO SGM3140 500mA Buck/Boost Charge Pump LED Driver

maintainers:
  - Luca Weiss <luca@z3ntu.xyz>

description: |
  The SGM3140 is a current-regulated charge pump which can regulate two current
  levels for Flash and Torch modes.

  The data sheet can be found at:
    http://www.sg-micro.com/uploads/soft/20190626/1561535688.pdf

properties:
  compatible:
    enum:
      - ocs,ocp8110
      - sgmicro,sgm3140

  enable-gpios:
    maxItems: 1
    description: A connection to the 'EN' pin.

  flash-gpios:
    maxItems: 1
    description: A connection to the 'FLASH' pin.

  vin-supply:
    description: Regulator providing power to the 'VIN' pin.

  led:
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false

required:
  - compatible
  - flash-gpios
  - enable-gpios

additionalProperties: false

examples:
  - |
    #include <dt-bindings/gpio/gpio.h>
    #include <dt-bindings/leds/common.h>

    led-controller {
        compatible = "sgmicro,sgm3140";
        flash-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
        enable-gpios = <&pio 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
        vin-supply = <&reg_dcdc1>;

        sgm3140_flash: led {
            function = LED_FUNCTION_FLASH;
            color = <LED_COLOR_ID_WHITE>;
            flash-max-timeout-us = <250000>;
        };
    };


code:
* Single Byte SPI LED Device Driver.

The driver can be used for controllers with a very simple SPI protocol:
- one LED is controlled by a single byte on MOSI
- the value of the byte gives the brightness between two values (lowest to
  highest)
- no return value is necessary (no MISO signal)

The value for lowest and highest brightness is dependent on the device and
therefore on the compatible string.

Depending on the compatible string some special functions (like hardware
accelerated blinking) might can be supported too.

The driver currently only supports one LED. The properties of the LED are
configured in a sub-node in the device node.

Required properties:
- compatible: should be one of
   * "ubnt,acb-spi-led"		microcontroller (SONiX 8F26E611LA) based device
				used for example in Ubiquiti airCube ISP

Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
apply.

LED sub-node properties:
- label:
	see Documentation/devicetree/bindings/leds/common.txt
- default-state:
	see Documentation/devicetree/bindings/leds/common.txt
	Only "on" and "off" are supported.

Example:

led-controller@0 {
	compatible = "ubnt,acb-spi-led";
	reg = <0>;
	spi-max-frequency = <100000>;

	led {
		label = "white:status";
		default-state = "on";
	};
};


code:
LEDs connected to tlc59116 or tlc59108

Required properties
- compatible: should be "ti,tlc59116" or "ti,tlc59108"
- #address-cells: must be 1
- #size-cells: must be 0
- reg: typically 0x68

Each led is represented as a sub-node of the ti,tlc59116.
See Documentation/devicetree/bindings/leds/common.txt

LED sub-node properties:
- reg: number of LED line, 0 to 15 or 0 to 7
- label: (optional) name of LED
- linux,default-trigger : (optional)

Examples:

tlc59116@68 {
	#address-cells = <1>;
	#size-cells = <0>;
	compatible = "ti,tlc59116";
	reg = <0x68>;

	wan@0 {
		label = "wrt1900ac:amber:wan";
		reg = <0x0>;
	};

	2g@2 {
		label = "wrt1900ac:white:2g";
		reg = <0x2>;
	};

	alive@9 {
		label = "wrt1900ac:green:alive";
		reg = <0x9>;
		linux,default_trigger = "heartbeat";
	};
};


code:
* Pattern format for LED pattern trigger

The pattern is given by a series of tuples, of brightness and duration (ms).
The LED is expected to traverse the series and each brightness value for the
specified duration. Duration of 0 means brightness should immediately change to
new value, and writing malformed pattern deactivates any active one.

1. For gradual dimming, the dimming interval now is set as 50 milliseconds. So
the tuple with duration less than dimming interval (50ms) is treated as a step
change of brightness, i.e. the subsequent brightness will be applied without
adding intervening dimming intervals.

The gradual dimming format of the software pattern values should be:
"brightness_1 duration_1 brightness_2 duration_2 brightness_3 duration_3 ...".
For example (using sysfs interface):

echo 0 1000 255 2000 > pattern

It will make the LED go gradually from zero-intensity to max (255) intensity in
1000 milliseconds, then back to zero intensity in 2000 milliseconds:

LED brightness
    ^
255-|       / \            / \            /
    |      /    \         /    \         /
    |     /       \      /       \      /
    |    /          \   /          \   /
  0-|   /             \/             \/
    +---0----1----2----3----4----5----6------------> time (s)

2. To make the LED go instantly from one brightness value to another, we should
use zero-time lengths (the brightness must be same as the previous tuple's). So
the format should be: "brightness_1 duration_1 brightness_1 0 brightness_2
duration_2 brightness_2 0 ...".
For example (using sysfs interface):

echo 0 1000 0 0 255 2000 255 0 > pattern

It will make the LED stay off for one second, then stay at max brightness for
two seconds:

LED brightness
    ^
255-|        +---------+    +---------+
    |        |         |    |         |
    |        |         |    |         |
    |        |         |    |         |
  0-|   -----+         +----+         +----
    +---0----1----2----3----4----5----6------------> time (s)


code:
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/maxim,max77693.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Maxim MAX77693 MicroUSB and Companion Power Management IC LEDs

maintainers:
  - Krzysztof Kozlowski <krzk@kernel.org>

description: |
  This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated
  Circuit (MUIC).

  There are two LED outputs available - FLED1 and FLED2. Each of them can
  control a separate LED or they can be connected together to double the
  maximum current for a single connected LED. One LED is represented by one
  child node.

  See also Documentation/devicetree/bindings/mfd/maxim,max77693.yaml for
  additional information and example.

properties:
  compatible:
    const: maxim,max77693-led

  maxim,boost-mode:
    description:
      In boost mode the device can produce up to 1.2A of total current on both
      outputs. The maximum current on each output is reduced to 625mA then. If
      not enabled explicitly, boost setting defaults to LEDS_BOOST_FIXED in
      case both current sources are used.
      See LEDS_BOOST_* in include/dt-bindings/leds/common.h.
    $ref: /schemas/types.yaml#/definitions/uint32
    enum: [0, 1, 2]

  maxim,boost-mvout:
    description: |
      Output voltage of the boost module in millivolts.
      Valid values: 3300 - 5500, step by 25 (rounded down)
    $ref: /schemas/types.yaml#/definitions/uint32
    minimum: 3300
    maximum: 5500
    default: 3300

  maxim,mvsys-min:
    description: |
      Low input voltage level in millivolts. Flash is not fired if chip
      estimates that system voltage could drop below this level due to flash
      power consumption.
      Valid values: 2400 - 3400, step by 33 (rounded down)
    $ref: /schemas/types.yaml#/definitions/uint32
    minimum: 2400
    maximum: 3400
    default: 2400

patternProperties:
  "^([a-z]+-)?led[01]?$":
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      led-sources:
        allOf:
          - minItems: 1
            maxItems: 2
            items:
              minimum: 0
              maximum: 1

      led-max-microamp:
        description: |
          Valid values for a LED connected to one FLED output:
            15625 - 250000, step by 15625 (rounded down)
          Valid values for a LED connected to both FLED outputs:
            15625 - 500000, step by 15625 (rounded down)

      flash-max-microamp:
        description: |
          Valid values for a single LED connected to one FLED output
          (boost mode must be turned off):
            15625 - 1000000, step by 15625 (rounded down)
          Valid values for a single LED connected to both FLED outputs:
            15625 - 1250000, step by 15625 (rounded down)
          Valid values for two LEDs case:
            15625 - 625000, step by 15625 (rounded down)

      flash-max-timeout-us:
        description: |
          Valid values: 62500 - 1000000, step by 62500 (rounded down)
        minimum: 62500
        maximum: 1000000

    required:
      - flash-max-microamp
      - flash-max-timeout-us
      - led-max-microamp
      - led-sources

required:
  - compatible

additionalProperties: false


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/mediatek,mt6370-flashlight.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Flash LED driver for MT6370 PMIC from MediaTek Integrated.

maintainers:
  - Alice Chen <alice_chen@richtek.com>

description: |
  This module is part of the MT6370 MFD device.
  Add MT6370 flash LED driver include 2-channel flash LED support Torch/Strobe Mode.

properties:
  compatible:
    const: mediatek,mt6370-flashlight

  "#address-cells":
    const: 1

  "#size-cells":
    const: 0

patternProperties:
  "^led@[0-1]$":
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      reg:
        enum: [0, 1]

required:
  - compatible
  - "#address-cells"
  - "#size-cells"

additionalProperties: false


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/mediatek,mt6370-indicator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: LED driver for MT6370 PMIC from MediaTek Integrated.

maintainers:
  - Alice Chen <alice_chen@richtek.com>

description: |
  This module is part of the MT6370 MFD device.
  Add MT6370 LED driver include 4-channel RGB LED support Register/PWM/Breath Mode

properties:
  compatible:
    const: mediatek,mt6370-indicator

  "#address-cells":
    const: 1

  "#size-cells":
    const: 0

patternProperties:
  "^multi-led@[0-3]$":
    type: object
    $ref: leds-class-multicolor.yaml#
    unevaluatedProperties: false

    properties:
      reg:
        enum: [0, 1, 2, 3]

      "#address-cells":
        const: 1

      "#size-cells":
        const: 0

    patternProperties:
      "^led@[0-2]$":
        type: object
        $ref: common.yaml#
        unevaluatedProperties: false

        properties:
          reg:
            enum: [0, 1, 2]

        required:
          - reg
          - color

    required:
      - reg
      - color
      - "#address-cells"
      - "#size-cells"

  "^led@[0-3]$":
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      reg:
        enum: [0, 1, 2, 3]

    required:
      - reg
      - color

required:
  - compatible
  - "#address-cells"
  - "#size-cells"

additionalProperties: false


code:
LEDs connected to pca9632, pca9633 or pca9634

Required properties:
- compatible : should be : "nxp,pca9632", "nxp,pca9633", "nxp,pca9634" or "nxp,pca9635"

Optional properties:
- nxp,totem-pole : use totem pole (push-pull) instead of open-drain (pca9632 defaults
  to open-drain, newer chips to totem pole)
- nxp,hw-blink : use hardware blinking instead of software blinking
- nxp,period-scale : In some configurations, the chip blinks faster than expected.
		     This parameter provides a scaling ratio (fixed point, decimal divided
		     by 1000) to compensate, e.g. 1300=1.3x and 750=0.75x.
- nxp,inverted-out: invert the polarity of the generated PWM

Each led is represented as a sub-node of the nxp,pca963x device.

LED sub-node properties:
- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
- reg : number of LED line (could be from 0 to 3 in pca9632 or pca9633,
		0 to 7 in pca9634, or 0 to 15 in pca9635)
- linux,default-trigger : (optional)
   see Documentation/devicetree/bindings/leds/common.txt

Examples:

pca9632: pca9632 {
	compatible = "nxp,pca9632";
	#address-cells = <1>;
	#size-cells = <0>;
	reg = <0x62>;

	red@0 {
		label = "red";
		reg = <0>;
		linux,default-trigger = "none";
	};
	green@1 {
		label = "green";
		reg = <1>;
		linux,default-trigger = "none";
	};
	blue@2 {
		label = "blue";
		reg = <2>;
		linux,default-trigger = "none";
	};
	unused@3 {
		label = "unused";
		reg = <3>;
		linux,default-trigger = "none";
	};
};


code:
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/qcom,pm8058-led.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Qualcomm PM8058 PMIC LED

maintainers:
  - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

description: |
  The Qualcomm PM8058 contains an LED block for up to six LEDs:: three normal
  LEDs, two "flash" LEDs and one "keypad backlight" LED. The names are quoted
  because sometimes these LED drivers are used for wildly different things than
  flash or keypad backlight:: their names are more of a suggestion than a
  hard-wired usecase.

  Hardware-wise the different LEDs support slightly different output currents.
  The "flash" LEDs do not need to charge nor do they support external triggers.
  They are just powerful LED drivers.

allOf:
  - $ref: common.yaml#

properties:
  compatible:
    enum:
      - qcom,pm8058-led
      - qcom,pm8058-keypad-led
      - qcom,pm8058-flash-led

  reg:
    maxItems: 1

required:
  - compatible
  - reg

unevaluatedProperties: false

examples:
  - |
    #include <dt-bindings/leds/common.h>

    pmic {
        #address-cells = <1>;
        #size-cells = <0>;

        led@131 {
            compatible = "qcom,pm8058-led";
            reg = <0x131>;
            label = "pm8058:red";
            color = <LED_COLOR_ID_RED>;
            default-state = "off";
        };
    };


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/register-bit-led.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Device Tree Bindings for Register Bit LEDs

maintainers:
  - Linus Walleij <linus.walleij@linaro.org>

description: |+
  Register bit leds are used with syscon multifunctional devices where single
  bits in a certain register can turn on/off a single LED. The register bit LEDs
  appear as children to the syscon device, with the proper compatible string.
  For the syscon bindings see:
  Documentation/devicetree/bindings/mfd/syscon.yaml

allOf:
  - $ref: /schemas/leds/common.yaml#

properties:
  $nodename:
    description:
      The unit-address is in the form of @<reg addr>,<bit offset>
    pattern: '^led@[0-9a-f]+,[0-9a-f]{1,2}$'

  compatible:
    const: register-bit-led

  reg:
    description:
      The register address and size
    maxItems: 1

  mask:
    description:
      bit mask for the bit controlling this LED in the register
    $ref: /schemas/types.yaml#/definitions/uint32
    enum:
      [ 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80, 0x100, 0x200, 0x400, 0x800,
        0x1000, 0x2000, 0x4000, 0x8000, 0x10000, 0x20000, 0x40000, 0x80000,
        0x100000, 0x200000, 0x400000, 0x800000, 0x1000000, 0x2000000, 0x4000000,
        0x8000000, 0x10000000, 0x20000000, 0x40000000, 0x80000000 ]

  offset:
    description:
      register offset to the register controlling this LED
    $ref: /schemas/types.yaml#/definitions/uint32
    deprecated: true

required:
  - compatible
  - mask
  - reg

unevaluatedProperties: false

examples:
  - |

    syscon@10000000 {
        compatible = "arm,realview-pb1176-syscon", "syscon";
        reg = <0x10000000 0x1000>;
        #address-cells = <1>;
        #size-cells = <1>;
        ranges = <0x0 0x10000000 0x1000>;

        led@8,0 {
            compatible = "register-bit-led";
            reg = <0x08 0x04>;
            offset = <0x08>;
            mask = <0x01>;
            label = "versatile:0";
            linux,default-trigger = "heartbeat";
            default-state = "on";
        };
        led@8,1 {
            compatible = "register-bit-led";
            reg = <0x08 0x04>;
            offset = <0x08>;
            mask = <0x02>;
            label = "versatile:1";
            default-state = "off";
        };
        led@8,2 {
            compatible = "register-bit-led";
            reg = <0x08 0x04>;
            offset = <0x08>;
            mask = <0x04>;
            label = "versatile:2";
            default-state = "off";
        };
    };
...


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/regulator-led.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Device Tree Bindings for Regulator LEDs

maintainers:
  - Linus Walleij <linus.walleij@linaro.org>

description: |
  Regulator LEDs are powered by a single regulator such that they can
  be turned on or off by enabling or disabling the regulator. The available
  brightness settings will be inferred from the available voltages on the
  regulator, and any constraints on the voltage or current will need to be
  specified on the regulator.

allOf:
  - $ref: common.yaml#

properties:
  $nodename:
    pattern: '^led.*$'

  compatible:
    const: regulator-led

  vled-supply:
    description:
      The regulator controlling the current to the LED.

  function: true
  color: true
  linux,default-trigger: true
  default-state: true

required:
  - compatible
  - vled-supply

additionalProperties: false

examples:
  - |
    #include <dt-bindings/leds/common.h>

    led-heartbeat {
        compatible = "regulator-led";
        vled-supply = <&regulator>;
        function = LED_FUNCTION_STATUS;
        color = <LED_COLOR_ID_BLUE>;
        linux,default-trigger = "heartbeat";
    };
...


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/richtek,rt8515.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Richtek RT8515 1.5A dual channel LED driver

maintainers:
  - Linus Walleij <linus.walleij@linaro.org>

description: |
  The Richtek RT8515 is a dual channel (two mode) LED driver that
  supports driving a white LED in flash or torch mode. The maximum
  current for each mode is defined in hardware using two resistors
  RFS and RTS.

properties:
  compatible:
    const: richtek,rt8515

  enf-gpios:
    maxItems: 1
    description: A connection to the 'ENF' (enable flash) pin.

  ent-gpios:
    maxItems: 1
    description: A connection to the 'ENT' (enable torch) pin.

  richtek,rfs-ohms:
    minimum: 7680
    maximum: 367000
    description: The resistance value of the RFS resistor. This
      resistors limits the maximum flash current. This must be set
      for the property flash-max-microamp to work, the RFS resistor
      defines the range of the dimmer setting (brightness) of the
      flash LED.

  richtek,rts-ohms:
    minimum: 7680
    maximum: 367000
    description: The resistance value of the RTS resistor. This
      resistors limits the maximum torch current. This must be set
      for the property torch-max-microamp to work, the RTS resistor
      defines the range of the dimmer setting (brightness) of the
      torch LED.

  led:
    type: object
    $ref: common.yaml#
    properties:
      function: true
      color: true
      flash-max-timeout-us: true

      flash-max-microamp:
        maximum: 700000
        description: The maximum current for flash mode
          is hardwired to the component using the RFS resistor to
          ground. The maximum hardware current setting is calculated
          according to the formula Imax = 5500 / RFS. The lowest
          allowed resistance value is 7.86 kOhm giving an absolute
          maximum current of 700mA. By setting this attribute in
          the device tree, you can further restrict the maximum
          current below the hardware limit. This requires the RFS
          to be defined as it defines the maximum range.

      led-max-microamp:
        maximum: 700000
        description: The maximum current for torch mode
          is hardwired to the component using the RTS resistor to
          ground. The maximum hardware current setting is calculated
          according to the formula Imax = 5500 / RTS. The lowest
          allowed resistance value is 7.86 kOhm giving an absolute
          maximum current of 700mA. By setting this attribute in
          the device tree, you can further restrict the maximum
          current below the hardware limit. This requires the RTS
          to be defined as it defines the maximum range.

    additionalProperties: false

required:
  - compatible
  - ent-gpios
  - enf-gpios
  - led

additionalProperties: false

examples:
  - |
    #include <dt-bindings/gpio/gpio.h>
    #include <dt-bindings/leds/common.h>

    led-controller {
        compatible = "richtek,rt8515";
        enf-gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>;
        ent-gpios = <&gpio4 13 GPIO_ACTIVE_HIGH>;
        richtek,rfs-ohms = <16000>;
        richtek,rts-ohms = <100000>;

        led {
            function = LED_FUNCTION_FLASH;
            color = <LED_COLOR_ID_WHITE>;
            flash-max-timeout-us = <250000>;
            flash-max-microamp = <150000>;
            led-max-microamp = <25000>;
        };
    };

...


code:
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/rohm,bd71828-leds.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: ROHM BD71828 Power Management Integrated Circuit LED driver

maintainers:
  - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>

description: |
  This module is part of the ROHM BD71828 MFD device. For more details
  see Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml.

  The LED controller is represented as a sub-node of the PMIC node on the device
  tree.

  The device has two LED outputs referred as GRNLED and AMBLED in data-sheet.

select: false

properties:
  compatible:
    const: rohm,bd71828-leds

patternProperties:
  "^led-[1-2]$":
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      rohm,led-compatible:
        description: LED identification string
        $ref: "/schemas/types.yaml#/definitions/string"
        enum:
          - bd71828-ambled
          - bd71828-grnled

required:
  - compatible
additionalProperties: false

...


code:
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/skyworks,aat1290.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Skyworks Solutions, Inc. AAT1290 Current Regulator for Flash LEDs

maintainers:
  - Jacek Anaszewski <jacek.anaszewski@gmail.com>
  - Krzysztof Kozlowski <krzk@kernel.org>

description: |
  The device is controlled through two pins:: FL_EN and EN_SET. The pins when,
  asserted high, enable flash strobe and movie mode (max 1/2 of flash current)
  respectively. In order to add a capability of selecting the strobe signal
  source (e.g. CPU or camera sensor) there is an additional switch required,
  independent of the flash chip. The switch is controlled with pin control.

properties:
  compatible:
    const: skyworks,aat1290

  enset-gpios:
    maxItems: 1
    description: EN_SET pin

  flen-gpios:
    maxItems: 1
    description: FL_EN pin

  led:
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      led-max-microamp: true

      flash-max-microamp:
        description: |
          Maximum flash LED supply current can be calculated using following
          formula:: I = 1A * 162 kOhm / Rset.

      flash-max-timeout-us:
        description: |
          Maximum flash timeout can be calculated using following formula::
            T = 8.82 * 10^9 * Ct.

    required:
      - flash-max-microamp
      - flash-max-timeout-us
      - led-max-microamp

  pinctrl-names:
    items:
      - const: default
      - const: host
      - const: isp

  pinctrl-0: true
  pinctrl-1: true
  pinctrl-2: true

required:
  - compatible
  - enset-gpios
  - flen-gpios
  - led

additionalProperties: false

examples:
  - |
    #include <dt-bindings/gpio/gpio.h>
    #include <dt-bindings/leds/common.h>

    // Ct = 220 nF, Rset = 160 kOhm
    led-controller {
        compatible = "skyworks,aat1290";
        flen-gpios = <&gpj1 1 GPIO_ACTIVE_HIGH>;
        enset-gpios = <&gpj1 2 GPIO_ACTIVE_HIGH>;

        pinctrl-names = "default", "host", "isp";
        pinctrl-0 = <&camera_flash_host>;
        pinctrl-1 = <&camera_flash_host>;
        pinctrl-2 = <&camera_flash_isp>;

        led {
            function = LED_FUNCTION_FLASH;
            color = <LED_COLOR_ID_WHITE>;
            led-max-microamp = <520833>;
            flash-max-microamp = <1012500>;
            flash-max-timeout-us = <1940000>;
        };
    };


code:
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/ti,tca6507.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: TCA6507 LED and GPIO controller

maintainers:
  - NeilBrown <neilb@suse.de>

description:
  The TCA6507 is a programmable LED controller connected via I2C that can drive
  7 separate lines either by holding them low, or by pulsing them with modulated
  width.

properties:
  compatible:
    const: ti,tca6507

  reg:
    description: I2C slave address of the controller.
    maxItems: 1

  "#address-cells":
    const: 1

  "#size-cells":
    const: 0

  gpio-controller: true

  "#gpio-cells":
    const: 2

  gpio-line-names: true

patternProperties:
  "^led@[0-6]$":
    type: object
    $ref: common.yaml#
    unevaluatedProperties: false

    properties:
      reg:
        minimum: 0
        maximum: 6

    required:
      - reg

  "^gpio@[0-6]$":
    type: object

    properties:
      compatible:
        const: gpio

      reg:
        minimum: 0
        maximum: 6

    additionalProperties: false

    required:
      - reg
      - compatible

if:
  patternProperties:
    "^gpio@[0-6]$":
      type: object
      properties:
        compatible:
          contains:
            const: gpio
then:
  required:
    - gpio-controller
    - "#gpio-cells"

additionalProperties: false

examples:
  - |

    #include <dt-bindings/gpio/gpio.h>
    #include <dt-bindings/leds/common.h>

    i2c0 {
        #address-cells = <1>;
        #size-cells = <0>;

        led-controller@45 {
            compatible = "ti,tca6507";
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <0x45>;

            gpio-controller;
            #gpio-cells = <2>;

            gpio-line-names = "wifi_reset@6";

            led@0 {
                label = "gta04:red:aux";
                reg = <0x0>;
            };

            led@1 {
                label = "gta04:green:aux";
                reg = <0x1>;
            };

            led@3 {
                reg = <0x3>;
                color = <LED_COLOR_ID_RED>;
                function = LED_FUNCTION_POWER;
                linux,default-trigger = "default-on";
            };

            led@4 {
                color = <LED_COLOR_ID_GREEN>;
                function = LED_FUNCTION_POWER;
                reg = <0x4>;
            };

            gpio@6 {
                compatible = "gpio";
                reg = <0x6>;
            };
        };
    };

...


code:
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/trigger-source.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Trigger source providers

maintainers:
  - Jacek Anaszewski <jacek.anaszewski@gmail.com>
  - Pavel Machek <pavel@ucw.cz>

description:
  Each trigger source provider should be represented by a device tree node. It
  may be e.g. a USB port or an Ethernet device.

properties:
  '#trigger-source-cells':
    description:
      Number of cells in a source trigger. Typically 0 for nodes of simple
      trigger sources (e.g. a specific USB port).
    enum: [ 0, 1 ]

additionalProperties: true

...


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/allwinner,sun6i-a31-msgbox.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Allwinner sunxi Message Box

maintainers:
  - Samuel Holland <samuel@sholland.org>

description: |
  The hardware message box on sun6i, sun8i, sun9i, and sun50i SoCs is a
  two-user mailbox controller containing 8 unidirectional FIFOs. An interrupt
  is raised for received messages, but software must poll to know when a
  transmitted message has been acknowledged by the remote user. Each FIFO can
  hold four 32-bit messages; when a FIFO is full, clients must wait before
  attempting more transmissions.

  Refer to ./mailbox.txt for generic information about mailbox device-tree
  bindings.

properties:
  compatible:
    oneOf:
      - items:
          - enum:
              - allwinner,sun8i-a83t-msgbox
              - allwinner,sun8i-h3-msgbox
              - allwinner,sun9i-a80-msgbox
              - allwinner,sun50i-a64-msgbox
              - allwinner,sun50i-h6-msgbox
          - const: allwinner,sun6i-a31-msgbox
      - const: allwinner,sun6i-a31-msgbox

  reg:
    maxItems: 1

  clocks:
    maxItems: 1
    description: bus clock

  resets:
    maxItems: 1
    description: bus reset

  interrupts:
    maxItems: 1

  '#mbox-cells':
    const: 1
    description: first cell is the channel number (0-7)

required:
  - compatible
  - reg
  - clocks
  - resets
  - interrupts
  - '#mbox-cells'

additionalProperties: false

examples:
  - |
    #include <dt-bindings/clock/sun8i-h3-ccu.h>
    #include <dt-bindings/interrupt-controller/arm-gic.h>
    #include <dt-bindings/reset/sun8i-h3-ccu.h>

    msgbox: mailbox@1c17000 {
            compatible = "allwinner,sun8i-h3-msgbox",
                         "allwinner,sun6i-a31-msgbox";
            reg = <0x01c17000 0x1000>;
            clocks = <&ccu CLK_BUS_MSGBOX>;
            resets = <&ccu RST_BUS_MSGBOX>;
            interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
            #mbox-cells = <1>;
    };

...


code:
Altera Mailbox Driver
=====================

Required properties:
- compatible :	"altr,mailbox-1.0".
- reg : 	physical base address of the mailbox and length of
		memory mapped region.
- #mbox-cells:	Common mailbox binding property to identify the number
		of cells required for the mailbox specifier. Should be 1.

Optional properties:
- interrupts :		interrupt number. The interrupt specifier format
			depends on the interrupt controller parent.

Example:
	mbox_tx: mailbox@100 {
		compatible = "altr,mailbox-1.0";
		reg = <0x100 0x8>;
		interrupt-parent = < &gic_0 >;
		interrupts = <5>;
		#mbox-cells = <1>;
	};

	mbox_rx: mailbox@200 {
		compatible = "altr,mailbox-1.0";
		reg = <0x200 0x8>;
		interrupt-parent = < &gic_0 >;
		interrupts = <6>;
		#mbox-cells = <1>;
	};

Mailbox client
===============
"mboxes" and the optional "mbox-names" (please see
Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each value
of the mboxes property should contain a phandle to the mailbox controller
device node and second argument is the channel index. It must be 0 (hardware
support only one channel).The equivalent "mbox-names" property value can be
used to give a name to the communication channel to be used by the client user.

Example:
	mclient0: mclient0@400 {
		compatible = "client-1.0";
		reg = <0x400 0x10>;
		mbox-names = "mbox-tx", "mbox-rx";
		mboxes = <&mbox_tx 0>,
			 <&mbox_rx 0>;
	};


code:
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
$id: "http://devicetree.org/schemas/mailbox/amlogic,meson-gxbb-mhu.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"

title: Amlogic Meson Message-Handling-Unit Controller

maintainers:
  - Neil Armstrong <neil.armstrong@linaro.org>

description: |
  The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller
  that has 3 independent channels/links to communicate with remote processor(s).
  MHU links are hardwired on a platform. A link raises interrupt for any
  received data. However, there is no specified way of knowing if the sent
  data has been read by the remote. This driver assumes the sender polls
  STAT register and the remote clears it after having read the data.

properties:
  compatible:
    enum:
      - amlogic,meson-gxbb-mhu

  reg:
    maxItems: 1

  interrupts:
    minItems: 3
    description:
      Contains the interrupt information corresponding to each of the 3 links
      of MHU.

  "#mbox-cells":
    const: 1

required:
  - compatible
  - reg
  - interrupts
  - "#mbox-cells"

additionalProperties: false

examples:
  - |
    mailbox@c883c404 {
          compatible = "amlogic,meson-gxbb-mhu";
          reg = <0xc883c404 0x4c>;
          interrupts = <208>, <209>, <210>;
          #mbox-cells = <1>;
    };


code:
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/apple,mailbox.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Apple Mailbox Controller

maintainers:
  - Hector Martin <marcan@marcan.st>
  - Sven Peter <sven@svenpeter.dev>

description:
  The Apple mailbox consists of two FIFOs used to exchange 64+32 bit
  messages between the main CPU and a co-processor. Multiple instances
  of this mailbox can be found on Apple SoCs.
  One of the two FIFOs is used to send data to a co-processor while the other
  FIFO is used for the other direction.
  Various clients implement different IPC protocols based on these simple
  messages and shared memory buffers.

properties:
  compatible:
    oneOf:
      - description:
          ASC mailboxes are the most common variant found on the M1 used
          for example for the display controller, the system management
          controller and the NVMe coprocessor.
        items:
          - enum:
              - apple,t8103-asc-mailbox
              - apple,t6000-asc-mailbox
          - const: apple,asc-mailbox-v4

      - description:
          M3 mailboxes are an older variant with a slightly different MMIO
          interface still found on the M1. It is used for the Thunderbolt
          co-processors.
        items:
          - enum:
              - apple,t8103-m3-mailbox
              - apple,t6000-m3-mailbox
          - const: apple,m3-mailbox-v2

  reg:
    maxItems: 1

  interrupts:
    items:
      - description: send fifo is empty interrupt
      - description: send fifo is not empty interrupt
      - description: receive fifo is empty interrupt
      - description: receive fifo is not empty interrupt

  interrupt-names:
    items:
      - const: send-empty
      - const: send-not-empty
      - const: recv-empty
      - const: recv-not-empty

  "#mbox-cells":
    const: 0

  power-domains:
    maxItems: 1

required:
  - compatible
  - reg
  - interrupts
  - interrupt-names
  - "#mbox-cells"

additionalProperties: false

examples:
  - |
        mailbox@77408000 {
                compatible = "apple,t8103-asc-mailbox", "apple,asc-mailbox-v4";
                reg = <0x77408000 0x4000>;
                interrupts = <1 583 4>, <1 584 4>, <1 585 4>, <1 586 4>;
                interrupt-names = "send-empty", "send-not-empty",
                 "recv-empty", "recv-not-empty";
                #mbox-cells = <0>;
        };


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/arm,mhu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: ARM MHU Mailbox Controller

maintainers:
  - Jassi Brar <jaswinder.singh@linaro.org>

description: |
  The ARM's Message-Handling-Unit (MHU) is a mailbox controller that has 3
  independent channels/links to communicate with remote processor(s).  MHU links
  are hardwired on a platform. A link raises interrupt for any received data.
  However, there is no specified way of knowing if the sent data has been read
  by the remote. This driver assumes the sender polls STAT register and the
  remote clears it after having read the data.  The last channel is specified to
  be a 'Secure' resource, hence can't be used by Linux running NS.

  The MHU hardware also allows operations in doorbell mode. The MHU drives the
  interrupt signal using a 32-bit register, with all 32-bits logically ORed
  together. It provides a set of registers to enable software to set, clear and
  check the status of each of the bits of this register independently. The use
  of 32 bits per interrupt line enables software to provide more information
  about the source of the interrupt. For example, each bit of the register can
  be associated with a type of event that can contribute to raising the
  interrupt. Each of the 32-bits can be used as "doorbell" to alert the remote
  processor.

# We need a select here so we don't match all nodes with 'arm,primecell'
select:
  properties:
    compatible:
      contains:
        enum:
          - arm,mhu
          - arm,mhu-doorbell
  required:
    - compatible

properties:
  compatible:
    oneOf:
      - description: Data transfer mode
        items:
          - const: arm,mhu
          - const: arm,primecell

      - description: Doorbell mode
        items:
          - const: arm,mhu-doorbell
          - const: arm,primecell

  reg:
    maxItems: 1

  interrupts:
    minItems: 2
    items:
      - description: low-priority non-secure
      - description: high-priority non-secure
      - description: Secure

  clocks:
    maxItems: 1

  clock-names:
    items:
      - const: apb_pclk

  '#mbox-cells':
    description: |
      Set to 1 in data transfer mode and represents index of the channel.
      Set to 2 in doorbell mode and represents index of the channel and doorbell
      number.
    enum: [ 1, 2 ]

required:
  - compatible
  - reg
  - interrupts
  - '#mbox-cells'

additionalProperties: false

examples:
  # Data transfer mode.
  - |
    soc {
        #address-cells = <2>;
        #size-cells = <2>;

        mhuA: mailbox@2b1f0000 {
            #mbox-cells = <1>;
            compatible = "arm,mhu", "arm,primecell";
            reg = <0 0x2b1f0000 0 0x1000>;
            interrupts = <0 36 4>, /* LP-NonSecure */
                         <0 35 4>, /* HP-NonSecure */
                         <0 37 4>; /* Secure */
            clocks = <&clock 0 2 1>;
            clock-names = "apb_pclk";
        };
    };

    firmware {
        scpi {
            compatible = "arm,scpi";
            mboxes = <&mhuA 1>; /* HP-NonSecure */
            shmem = <&cpu_scp_hpri>; /* HP-NonSecure */

            scpi_devpd: power-controller {
                compatible = "arm,scpi-power-domains";
                num-domains = <2>;
                #power-domain-cells = <1>;
            };
        };
    };

  # Doorbell mode.
  - |
    soc {
        #address-cells = <2>;
        #size-cells = <2>;

        mhuB: mailbox@2b2f0000 {
            #mbox-cells = <2>;
            compatible = "arm,mhu-doorbell", "arm,primecell";
            reg = <0 0x2b2f0000 0 0x1000>;
            interrupts = <0 36 4>, /* LP-NonSecure */
                         <0 35 4>, /* HP-NonSecure */
                         <0 37 4>; /* Secure */
            clocks = <&clock 0 2 1>;
            clock-names = "apb_pclk";
        };
    };

    firmware {
        scmi {
            compatible = "arm,scmi";
            mboxes = <&mhuB 0 0>, /* LP-NonSecure, 1st doorbell */
                     <&mhuB 0 1>; /* LP-NonSecure, 2nd doorbell */
            mbox-names = "tx", "rx";
            shmem = <&cpu_scp_lpri0>,
                    <&cpu_scp_lpri1>;

            #address-cells = <1>;
            #size-cells = <0>;

            scmi_devpd: protocol@11 {
                reg = <0x11>;
                #power-domain-cells = <1>;
            };

            scmi_dvfs: protocol@13 {
                reg = <0x13>;
                #clock-cells = <1>;

                mboxes = <&mhuB 1 2>, /* HP-NonSecure, 3rd doorbell */
                         <&mhuB 1 3>; /* HP-NonSecure, 4th doorbell */
                mbox-names = "tx", "rx";
                shmem = <&cpu_scp_hpri0>,
                        <&cpu_scp_hpri1>;
            };
        };
    };

...


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/arm,mhuv2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: ARM MHUv2 Mailbox Controller

maintainers:
  - Tushar Khandelwal <tushar.khandelwal@arm.com>
  - Viresh Kumar <viresh.kumar@linaro.org>

description: |
  The Arm Message Handling Unit (MHU) Version 2 is a mailbox controller that has
  between 1 and 124 channel windows (each 32-bit wide) to provide unidirectional
  communication with remote processor(s), where the number of channel windows
  are implementation dependent.

  Given the unidirectional nature of the controller, an MHUv2 mailbox may only
  be written to or read from. If a pair of MHU controllers is implemented
  between two processing elements to provide bidirectional communication, these
  must be specified as two separate mailboxes.

  If the interrupts property is present in device tree node, then its treated as
  a "receiver" mailbox, otherwise a "sender".

  An MHU controller must be specified along with the supported transport
  protocols. The transport protocols determine the method of data transmission
  as well as the number of provided mailbox channels.

  Following are the possible transport protocols.

  - Data-transfer: Each transfer is made of one or more words, using one or more
    channel windows.

  - Doorbell: Each transfer is made up of single bit flag, using any one of the
    bits in a channel window. A channel window can support up to 32 doorbells
    and the entire window shall be used in doorbell protocol.  Optionally, data
    may be transmitted through a shared memory region, wherein the MHU is used
    strictly as an interrupt generation mechanism but that is out of the scope
    of these bindings.

# We need a select here so we don't match all nodes with 'arm,primecell'
select:
  properties:
    compatible:
      contains:
        enum:
          - arm,mhuv2-tx
          - arm,mhuv2-rx
  required:
    - compatible

properties:
  compatible:
    oneOf:
      - description: Sender mode
        items:
          - const: arm,mhuv2-tx
          - const: arm,primecell

      - description: Receiver-mode
        items:
          - const: arm,mhuv2-rx
          - const: arm,primecell

  reg:
    maxItems: 1

  interrupts:
    description: |
      The MHUv2 controller always implements an interrupt in the "receiver"
      mode, while the interrupt in the "sender" mode was not available in the
      version MHUv2.0, but the later versions do have it.
    maxItems: 1

  clocks:
    maxItems: 1

  clock-names:
    maxItems: 1

  arm,mhuv2-protocols:
    $ref: /schemas/types.yaml#/definitions/uint32-matrix
    description: |
      The MHUv2 controller may contain up to 124 channel windows (each 32-bit
      wide). The hardware and the DT bindings allows any combination of those to
      be used for various transport protocols.

      This property allows a platform to describe how these channel windows are
      used in various transport protocols. The entries in this property shall be
      present as an array of tuples, where each tuple describes details about
      one of the transport protocol being implemented over some channel
      window(s).

      The first field of a tuple signifies the transfer protocol, 0 is reserved
      for doorbell protocol, and 1 is reserved for data-transfer protocol.
      Using any other value in the first field of a tuple makes it invalid.

      The second field of a tuple signifies the number of channel windows where
      the protocol would be used and should be set to a non zero value. For
      doorbell protocol this field signifies the number of 32-bit channel
      windows that implement the doorbell protocol. For data-transfer protocol,
      this field signifies the number of 32-bit channel windows that implement
      the data-transfer protocol.

      The total number of channel windows specified here shouldn't be more than
      the ones implemented by the platform, though one can specify lesser number
      of windows here than what the platform implements.

      mhu: mailbox@2b1f0000 {
          ...

          arm,mhuv2-protocols = <0 2>, <1 1>, <1 5>, <1 7>;
      }

      The above example defines the protocols of an ARM MHUv2 mailbox
      controller, where a total of 15 channel windows are used. The first two
      windows are used in doorbell protocol (64 doorbells), followed by 1, 5 and
      7 windows (separately) used in data-transfer protocol.

    minItems: 1
    maxItems: 124
    items:
      items:
        - enum: [ 0, 1 ]
        - minimum: 0
          maximum: 124

  '#mbox-cells':
    description: |
      It is always set to 2. The first argument in the consumers 'mboxes'
      property represents the channel window group, which may be used in
      doorbell, or data-transfer protocol, and the second argument (only
      relevant in doorbell protocol, should be 0 otherwise) represents the
      doorbell number within the 32 bit wide channel window.

      From the example given above for arm,mhuv2-protocols, here is how a client
      node can reference them.

      mboxes = <&mhu 0 5>; // Channel Window Group 0, doorbell 5.
      mboxes = <&mhu 1 7>; // Channel Window Group 1, doorbell 7.
      mboxes = <&mhu 2 0>; // Channel Window Group 2, data transfer protocol with 1 window.
      mboxes = <&mhu 3 0>; // Channel Window Group 3, data transfer protocol with 5 windows.
      mboxes = <&mhu 4 0>; // Channel Window Group 4, data transfer protocol with 7 windows.

    const: 2

if:
  # Interrupt is compulsory for receiver
  properties:
    compatible:
      contains:
        const: arm,mhuv2-rx
then:
  required:
    - interrupts

required:
  - compatible
  - reg
  - '#mbox-cells'
  - arm,mhuv2-protocols

additionalProperties: false

examples:
  # Multiple transport protocols implemented by the mailbox controllers
  - |
    soc {
        #address-cells = <2>;
        #size-cells = <2>;

        mhu_tx: mailbox@2b1f0000 {
            #mbox-cells = <2>;
            compatible = "arm,mhuv2-tx", "arm,primecell";
            reg = <0 0x2b1f0000 0 0x1000>;
            clocks = <&clock 0>;
            clock-names = "apb_pclk";
            interrupts = <0 45 4>;
            arm,mhuv2-protocols = <1 5>, <1 2>, <1 5>, <1 7>, <0 2>;
        };

        mhu_rx: mailbox@2b1f1000 {
            #mbox-cells = <2>;
            compatible = "arm,mhuv2-rx", "arm,primecell";
            reg = <0 0x2b1f1000 0 0x1000>;
            clocks = <&clock 0>;
            clock-names = "apb_pclk";
            interrupts = <0 46 4>;
            arm,mhuv2-protocols = <1 1>, <1 7>, <0 2>;
        };

        mhu_client: dsp@596e8000 {
            compatible = "fsl,imx8qxp-dsp";
            reg = <0 0x596e8000 0 0x88000>;
            clocks = <&adma_lpcg 0>, <&adma_lpcg 1>, <&adma_lpcg 2>;
            clock-names = "ipg", "ocram", "core";
            power-domains = <&pd 0>, <&pd 1>, <&pd 2>, <&pd 3>;
            mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
            mboxes = <&mhu_tx 2 0>, //data-transfer protocol with 5 windows, mhu-tx
                     <&mhu_tx 3 0>, //data-transfer protocol with 7 windows, mhu-tx
                     <&mhu_rx 2 27>, //doorbell protocol channel 2, doorbell 27, mhu-rx
                     <&mhu_rx 0 0>;  //data-transfer protocol with 1 window, mhu-rx
            memory-region = <&dsp_reserved>;
        };
    };


code:
Broadcom BCM2835 VideoCore mailbox IPC

Required properties:

- compatible:	Should be "brcm,bcm2835-mbox"
- reg:		Specifies base physical address and size of the registers
- interrupts:	The interrupt number
		  See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
- #mbox-cells:	Specifies the number of cells needed to encode a mailbox
		  channel. The value shall be 0, since there is only one
		  mailbox channel implemented by the device.

Example:

mailbox: mailbox@7e00b880 {
	compatible = "brcm,bcm2835-mbox";
	reg = <0x7e00b880 0x40>;
	interrupts = <0 1>;
	#mbox-cells = <0>;
};

firmware: firmware {
	compatible = "raspberrypi,firmware";
	mboxes = <&mailbox>;
	#power-domain-cells = <1>;
};


code:
Broadcom FlexRM Ring Manager
============================
The Broadcom FlexRM ring manager provides a set of rings which can be
used to submit work to offload engines. An SoC may have multiple FlexRM
hardware blocks. There is one device tree entry per FlexRM block. The
FlexRM driver will create a mailbox-controller instance for given FlexRM
hardware block where each mailbox channel is a separate FlexRM ring.

Required properties:
--------------------
- compatible:	Should be "brcm,iproc-flexrm-mbox"
- reg:		Specifies base physical address and size of the FlexRM
		ring registers
- msi-parent:	Phandles (and potential Device IDs) to MSI controllers
		The FlexRM engine will send MSIs (instead of wired
		interrupts) to CPU. There is one MSI for each FlexRM ring.
		Refer devicetree/bindings/interrupt-controller/msi.txt
- #mbox-cells:	Specifies the number of cells needed to encode a mailbox
		channel. This should be 3.

		The 1st cell is the mailbox channel number.

		The 2nd cell contains MSI completion threshold. This is the
		number of completion messages for which FlexRM will inject
		one MSI interrupt to CPU.

		The 3nd cell contains MSI timer value representing time for
		which FlexRM will wait to accumulate N completion messages
		where N is the value specified by 2nd cell above. If FlexRM
		does not get required number of completion messages in time
		specified by this cell then it will inject one MSI interrupt
		to CPU provided atleast one completion message is available.

Optional properties:
--------------------
- dma-coherent:	Present if DMA operations made by the FlexRM engine (such
		as DMA descriptor access, access to buffers pointed by DMA
		descriptors and read/write pointer updates to DDR) are
		cache coherent with the CPU.

Example:
--------
crypto_mbox: mbox@67000000 {
	compatible = "brcm,iproc-flexrm-mbox";
	reg = <0x67000000 0x200000>;
	msi-parent = <&gic_its 0x7f00>;
	#mbox-cells = <3>;
};

crypto@672c0000 {
	compatible = "brcm,spu2-v2-crypto";
	reg = <0x672c0000 0x1000>;
	mboxes = <&crypto_mbox 0 0x1 0xffff>,
		 <&crypto_mbox 1 0x1 0xffff>,
		 <&crypto_mbox 16 0x1 0xffff>,
		 <&crypto_mbox 17 0x1 0xffff>,
		 <&crypto_mbox 30 0x1 0xffff>,
		 <&crypto_mbox 31 0x1 0xffff>;
};


code:
The PDC driver manages data transfer to and from various offload engines
on some Broadcom SoCs. An SoC may have multiple PDC hardware blocks. There is
one device tree entry per block.  On some chips, the PDC functionality is
handled by the FA2 (Northstar Plus).

Required properties:
- compatible : Should be "brcm,iproc-pdc-mbox" or "brcm,iproc-fa2-mbox" for
  FA2/Northstar Plus.
- reg: Should contain PDC registers location and length.
- interrupts: Should contain the IRQ line for the PDC.
- #mbox-cells: 1
- brcm,rx-status-len: Length of metadata preceding received frames, in bytes.

Optional properties:
- brcm,use-bcm-hdr:  present if a BCM header precedes each frame.

Example:
	pdc0: iproc-pdc0@612c0000 {
		compatible = "brcm,iproc-pdc-mbox";
		reg = <0 0x612c0000 0 0x445>;  /* PDC FS0 regs */
		interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
		#mbox-cells = <1>;   /* one cell per mailbox channel */
		brcm,rx-status-len = <32>;
		brcm,use-bcm-hdr;
	};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/fsl,mu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: NXP i.MX Messaging Unit (MU)

maintainers:
  - Dong Aisheng <aisheng.dong@nxp.com>

description: |
  The Messaging Unit module enables two processors within the SoC to
  communicate and coordinate by passing messages (e.g. data, status
  and control) through the MU interface. The MU also provides the ability
  for one processor to signal the other processor using interrupts.

  Because the MU manages the messaging between processors, the MU uses
  different clocks (from each side of the different peripheral buses).
  Therefore, the MU must synchronize the accesses from one side to the
  other. The MU accomplishes synchronization using two sets of matching
  registers (Processor A-facing, Processor B-facing).

properties:
  compatible:
    oneOf:
      - const: fsl,imx6sx-mu
      - const: fsl,imx7ulp-mu
      - const: fsl,imx8ulp-mu
      - const: fsl,imx8-mu-scu
      - const: fsl,imx8-mu-seco
      - const: fsl,imx93-mu-s4
      - const: fsl,imx8ulp-mu-s4
      - items:
          - const: fsl,imx93-mu
          - const: fsl,imx8ulp-mu
      - items:
          - enum:
              - fsl,imx7s-mu
              - fsl,imx8mq-mu
              - fsl,imx8mm-mu
              - fsl,imx8mn-mu
              - fsl,imx8mp-mu
              - fsl,imx8qm-mu
              - fsl,imx8qxp-mu
          - const: fsl,imx6sx-mu
      - description: To communicate with i.MX8 SCU with fast IPC
        items:
          - const: fsl,imx8-mu-scu
          - enum:
              - fsl,imx8qm-mu
              - fsl,imx8qxp-mu
          - const: fsl,imx6sx-mu

  reg:
    maxItems: 1

  interrupts:
    minItems: 1
    maxItems: 2

  interrupt-names:
    minItems: 1
    items:
      - const: tx
      - const: rx

  "#mbox-cells":
    description: |
      <&phandle type channel>
      phandle   : Label name of controller
      type      : Channel type
      channel   : Channel number

      This MU support 5 type of unidirectional channels, each type
      has 4 channels except RST channel which only has 1 channel.
      A total of 17 channels.  Following types are
      supported:
      0 - TX channel with 32bit transmit register and IRQ transmit
          acknowledgment support.
      1 - RX channel with 32bit receive register and IRQ support
      2 - TX doorbell channel. Without own register and no ACK support.
      3 - RX doorbell channel.
      4 - RST channel
    const: 2

  clocks:
    maxItems: 1

  fsl,mu-side-b:
    description: boolean, if present, means it is for side B MU.
    type: boolean

  power-domains:
    maxItems: 1

required:
  - compatible
  - reg
  - interrupts
  - "#mbox-cells"

allOf:
  - if:
      properties:
        compatible:
          enum:
            - fsl,imx93-mu-s4
    then:
      properties:
        interrupt-names:
          minItems: 2
        interrupts:
          minItems: 2

    else:
      properties:
        interrupts:
          maxItems: 1
      not:
        required:
          - interrupt-names

additionalProperties: false

examples:
  - |
    #include <dt-bindings/interrupt-controller/arm-gic.h>

    mailbox@5d1b0000 {
        compatible = "fsl,imx8qxp-mu", "fsl,imx6sx-mu";
        reg = <0x5d1b0000 0x10000>;
        interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
        #mbox-cells = <2>;
    };


code:
Hisilicon Hi3660 Mailbox Controller

Hisilicon Hi3660 mailbox controller supports up to 32 channels.  Messages
are passed between processors, including application & communication
processors, MCU, HIFI, etc.  Each channel is unidirectional and accessed
by using MMIO registers; it supports maximum to 8 words message.

Controller
----------

Required properties:
- compatible:		: Shall be "hisilicon,hi3660-mbox"
- reg:			: Offset and length of the device's register set
- #mbox-cells:		: Must be 3
			  <&phandle channel dst_irq ack_irq>
			    phandle	: Label name of controller
			    channel	: Channel number
			    dst_irq	: Remote interrupt vector
			    ack_irq	: Local interrupt vector

- interrupts:		: Contains the two IRQ lines for mailbox.

Example:

mailbox: mailbox@e896b000 {
	compatible = "hisilicon,hi3660-mbox";
	reg = <0x0 0xe896b000 0x0 0x1000>;
	interrupts = <0x0 0xc0 0x4>,
		     <0x0 0xc1 0x4>;
	#mbox-cells = <3>;
};

Client
------

Required properties:
- compatible		: See the client docs
- mboxes		: Standard property to specify a Mailbox (See ./mailbox.txt)
			  Cells must match 'mbox-cells' (See Controller docs above)

Optional properties
- mbox-names		: Name given to channels seen in the 'mboxes' property.

Example:

stub_clock: stub_clock@e896b500 {
	compatible = "hisilicon,hi3660-stub-clk";
	reg = <0x0 0xe896b500 0x0 0x0100>;
	#clock-cells = <1>;
	mboxes = <&mailbox 13 3 0>;
};


code:
Hisilicon Hi6220 Mailbox Driver
===============================

Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
is unidirectional with a maximum message size of 8 words. I/O is
performed using register access (there is no DMA) and the cell
raises an interrupt when messages are received.

Mailbox Device Node:
====================

Required properties:
--------------------
- compatible:		Shall be "hisilicon,hi6220-mbox"
- reg:			Contains the mailbox register address range (base
			address and length); the first item is for IPC
			registers, the second item is shared buffer for
			slots.
- #mbox-cells:		Common mailbox binding property to identify the number
			of cells required for the mailbox specifier. Must be 3.
			<&phandle slot_id dst_irq ack_irq>
			  phandle: Label name of mailbox controller
			  slot_id: Slot id used either for TX or RX
			  dst_irq: IRQ identifier index number which used by MCU
			  ack_irq: IRQ identifier index number with generating a
			           TX/RX interrupt to application processor,
				   mailbox driver uses it to acknowledge interrupt
- interrupts:		Contains the interrupt information for the mailbox
			device. The format is dependent on which interrupt
			controller the SoCs use.

Optional Properties:
--------------------
- hi6220,mbox-tx-noirq: Property of MCU firmware's feature, so mailbox driver
			use this flag to ask MCU to enable "automatic idle
			flag" mode or IRQ generated mode to acknowledge a TX
			completion.

Example:
--------

	mailbox: mailbox@f7510000 {
		compatible = "hisilicon,hi6220-mbox";
		reg = <0x0 0xf7510000 0x0 0x1000>, /* IPC_S */
		      <0x0 0x06dff800 0x0 0x0800>; /* Mailbox */
		interrupt-parent = <&gic>;
		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
		#mbox-cells = <3>;
	};

Mailbox client
===============

Required properties:
--------------------
- compatible:		Many (See the client docs).
- mboxes:		Standard property to specify a Mailbox (See ./mailbox.txt)
			Cells must match 'mbox-cells' (See Mailbox Device Node above).

Optional Properties:
--------------------
- mbox-names:		Name given to channels seen in the 'mboxes' property.

Example:
--------

	stub_clock: stub_clock {
		compatible = "hisilicon,hi6220-stub-clk";
		hisilicon,hi6220-clk-sram = <&sram>;
		#clock-cells = <1>;
		mbox-names = "mbox-tx", "mbox-rx";
		mboxes = <&mailbox 1 0 11>, <&mailbox 0 1 10>;
	};


code:
* Generic Mailbox Controller and client driver bindings

Generic binding to provide a way for Mailbox controller drivers to
assign appropriate mailbox channel to client drivers.

* Mailbox Controller

Required property:
- #mbox-cells: Must be at least 1. Number of cells in a mailbox
		specifier.

Example:
	mailbox: mailbox {
		...
		#mbox-cells = <1>;
	};

* Mailbox Client

Required property:
- mboxes: List of phandle and mailbox channel specifiers.

Optional property:
- mbox-names: List of identifier strings for each mailbox channel.
- shmem : List of phandle pointing to the shared memory(SHM) area between the
	  users of these mailboxes for IPC, one for each mailbox. This shared
	  memory can be part of any memory reserved for the purpose of this
	  communication between the mailbox client and the remote.

Example:
	pwr_cntrl: power {
		...
		mbox-names = "pwr-ctrl", "rpc";
		mboxes = <&mailbox 0 &mailbox 1>;
	};

Example with shared memory(shmem):

	sram: sram@50000000 {
		compatible = "mmio-sram";
		reg = <0x50000000 0x10000>;

		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0 0x50000000 0x10000>;

		cl_shmem: shmem@0 {
			compatible = "client-shmem";
			reg = <0x0 0x200>;
		};
	};

	client@2e000000 {
		...
		mboxes = <&mailbox 0>;
		shmem = <&cl_shmem>;
		..
	};


code:
* rWTM BIU Mailbox driver for Armada 37xx

Required properties:
- compatible:	must be "marvell,armada-3700-rwtm-mailbox"
- reg:		physical base address of the mailbox and length of memory mapped
		region
- interrupts:	the IRQ line for the mailbox
- #mbox-cells:	must be 1

Example:
	rwtm: mailbox@b0000 {
		compatible = "marvell,armada-3700-rwtm-mailbox";
		reg = <0xb0000 0x100>;
		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
		#mbox-cells = <1>;
	};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/mediatek,gce-mailbox.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Mediatek Global Command Engine Mailbox

maintainers:
  - Houlong Wei <houlong.wei@mediatek.com>

description:
  The Global Command Engine (GCE) is used to help read/write registers with
  critical time limitation, such as updating display configuration during the
  vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.

properties:
  compatible:
    enum:
      - mediatek,mt6779-gce
      - mediatek,mt8173-gce
      - mediatek,mt8183-gce
      - mediatek,mt8186-gce
      - mediatek,mt8192-gce
      - mediatek,mt8195-gce

  "#mbox-cells":
    const: 2
    description:
      The first cell describes the Thread ID of the GCE,
      the second cell describes the priority of the GCE thread

  reg:
    maxItems: 1

  interrupts:
    maxItems: 1

  clocks:
    items:
      - description: Global Command Engine clock

  clock-names:
    items:
      - const: gce

required:
  - compatible
  - "#mbox-cells"
  - reg
  - interrupts
  - clocks

allOf:
  - if:
      not:
        properties:
          compatible:
            contains:
              const: mediatek,mt8195-gce
    then:
      required:
        - clock-names

additionalProperties: false

examples:
  - |
    #include <dt-bindings/clock/mt8173-clk.h>
    #include <dt-bindings/interrupt-controller/arm-gic.h>
    #include <dt-bindings/interrupt-controller/irq.h>

    soc {
        #address-cells = <2>;
        #size-cells = <2>;

        gce: mailbox@10212000 {
            compatible = "mediatek,mt8173-gce";
            reg = <0 0x10212000 0 0x1000>;
            interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
            #mbox-cells = <2>;
            clocks = <&infracfg CLK_INFRA_GCE>;
            clock-names = "gce";
        };
    };


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/mailbox/microchip,mpfs-mailbox.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"

title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) mailbox controller

maintainers:
  - Conor Dooley <conor.dooley@microchip.com>

properties:
  compatible:
    const: microchip,mpfs-mailbox

  reg:
    oneOf:
      - items:
          - description: mailbox control & data registers
          - description: mailbox interrupt registers
        deprecated: true
      - items:
          - description: mailbox control registers
          - description: mailbox interrupt registers
          - description: mailbox data registers

  interrupts:
    maxItems: 1

  "#mbox-cells":
    const: 1

required:
  - compatible
  - reg
  - interrupts
  - "#mbox-cells"

additionalProperties: false

examples:
  - |
    soc {
      #address-cells = <2>;
      #size-cells = <2>;
      mbox: mailbox@37020000 {
        compatible = "microchip,mpfs-mailbox";
        reg = <0x0 0x37020000 0x0 0x58>, <0x0 0x2000318C 0x0 0x40>,
              <0x0 0x37020800 0x0 0x100>;
        interrupt-parent = <&L1>;
        interrupts = <96>;
        #mbox-cells = <1>;
      };
    };


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/mtk,adsp-mbox.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Mediatek ADSP mailbox

maintainers:
  - Allen-KH Cheng <Allen-KH.Cheng@mediatek.com>

description: |
  The MTK ADSP mailbox Inter-Processor Communication (IPC) enables the SoC
  to communicate with ADSP by passing messages through two mailbox channels.
  The MTK ADSP mailbox IPC also provides the ability for one processor to
  signal the other processor using interrupts.

properties:
  compatible:
    enum:
      - mediatek,mt8195-adsp-mbox
      - mediatek,mt8186-adsp-mbox

  "#mbox-cells":
    const: 0

  reg:
    maxItems: 1

  interrupts:
    maxItems: 1

required:
  - compatible
  - "#mbox-cells"
  - reg
  - interrupts

additionalProperties: false

examples:
  - |
    #include <dt-bindings/interrupt-controller/arm-gic.h>
    #include <dt-bindings/interrupt-controller/irq.h>

    adsp_mailbox0:mailbox@10816000 {
        compatible = "mediatek,mt8195-adsp-mbox";
        #mbox-cells = <0>;
        reg = <0x10816000 0x1000>;
        interrupts = <GIC_SPI 702 IRQ_TYPE_LEVEL_HIGH 0>;
    };