From patchwork Mon Jun 18 19:42:57 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Mack X-Patchwork-Id: 931186 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=zonque.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 418hMz6NXyz9s4n for ; Tue, 19 Jun 2018 05:43:11 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936275AbeFRTnJ (ORCPT ); Mon, 18 Jun 2018 15:43:09 -0400 Received: from mail.bugwerft.de ([46.23.86.59]:42730 "EHLO mail.bugwerft.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936208AbeFRTnI (ORCPT ); Mon, 18 Jun 2018 15:43:08 -0400 Received: from localhost.localdomain (pD95EF6C8.dip0.t-ipconnect.de [217.94.246.200]) by mail.bugwerft.de (Postfix) with ESMTPSA id B68E6289D92; Mon, 18 Jun 2018 19:40:04 +0000 (UTC) From: Daniel Mack To: jacek.anaszewski@gmail.com, robh+dt@kernel.org Cc: linux-leds@vger.kernel.org, devicetree@vger.kernel.org, Daniel Mack Subject: [PATCH v2 1/5] dt-bindings: leds: Add bindings for lltc,lt3593 Date: Mon, 18 Jun 2018 21:42:57 +0200 Message-Id: <20180618194301.5667-2-daniel@zonque.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180618194301.5667-1-daniel@zonque.org> References: <20180618194301.5667-1-daniel@zonque.org> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org This patch add the bindings document for LT3593 LED drivers. The binding is kept consistent with other LED driver bindings in that it stores all the LED-specific properties in its own subnode. As the hardware only supports once channel, there can consequently only be one sub-node. Signed-off-by: Daniel Mack --- .../devicetree/bindings/leds/leds-lt3593.txt | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-lt3593.txt diff --git a/Documentation/devicetree/bindings/leds/leds-lt3593.txt b/Documentation/devicetree/bindings/leds/leds-lt3593.txt new file mode 100644 index 000000000000..9e7f308404f8 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-lt3593.txt @@ -0,0 +1,35 @@ +Bindings for Linear Technologies LT3593 LED controller + +Required properties: +- compatible: Should be "lltc,lt3593". + +The hardware supports only one LED. The properties of this LED are +configured in a sub-node in the device node. + +Required sub-node properties: +- gpios: A handle to the GPIO that is connected to the 'CTRL' + pin of the chip. + +Optional sub-node properties: +- label: A label for the LED. If none is given, the LED will be + named "lt3595::". +- 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: + +led-controller { + compatible = "lltc,lt3593"; + + led { + label = "white:backlight"; + gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; + default-state = "on"; + }; +}; +