* v9 EL15203000
@ 2019-09-18 10:52 Oleh Kravchenko
2019-09-18 10:52 ` [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 Oleh Kravchenko
2019-09-18 10:52 ` [PATCH v9 2/2] leds: add LED driver for EL15203000 board Oleh Kravchenko
0 siblings, 2 replies; 9+ messages in thread
From: Oleh Kravchenko @ 2019-09-18 10:52 UTC (permalink / raw)
To: devicetree, linux-leds, jacek.anaszewski, pavel
[PATCH v9 1/2] dt-bindings: Add docs for EL15203000
[PATCH v9 2/2] leds: add LED driver for EL15203000 board
Changes what was made:
- updated Documentation/devicetree/bindings/leds/leds-el15203000.txt
after code review from Dan Murphy.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v9 1/2] dt-bindings: Add docs for EL15203000
2019-09-18 10:52 v9 EL15203000 Oleh Kravchenko
@ 2019-09-18 10:52 ` Oleh Kravchenko
2019-09-18 21:02 ` Jacek Anaszewski
2019-09-18 10:52 ` [PATCH v9 2/2] leds: add LED driver for EL15203000 board Oleh Kravchenko
1 sibling, 1 reply; 9+ messages in thread
From: Oleh Kravchenko @ 2019-09-18 10:52 UTC (permalink / raw)
To: devicetree, linux-leds, jacek.anaszewski, pavel; +Cc: Oleh Kravchenko
Add documentation and example for dt-bindings EL15203000.
LED board (aka RED LED board) from Crane Merchandising Systems.
Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
---
.../bindings/leds/leds-el15203000.txt | 147 ++++++++++++++++++
1 file changed, 147 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-el15203000.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-el15203000.txt b/Documentation/devicetree/bindings/leds/leds-el15203000.txt
new file mode 100644
index 000000000000..4a9b29cc9f46
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-el15203000.txt
@@ -0,0 +1,147 @@
+Crane Merchandising System - EL15203000 LED driver
+--------------------------------------------------
+
+This LED Board (aka RED LEDs board) is widely used in
+coffee vending machines produced by Crane Merchandising Systems.
+The board manages 3 LEDs and supports predefined blinking patterns
+for specific leds.
+
+Vending area LED encoded with symbol 'V' (hex code 0x56).
+Doesn't have any hardware blinking pattern.
+
+Screen light tube LED which surrounds vending machine screen and
+encoded with symbol 'S' (hex code 0x53). Supports blinking breathing pattern:
+
+ ^
+ |
+Max >_____***___________**
+ | * * *
+ | * * *
+ | * * *
+ | * * *
+Min >*___________***______
+ |
+ +------^------^------> time (sec)
+ 0 4 8
+
+
+Water Pipe LED actually consists from 5 LEDs
+that exposed by protocol like one LED. Supports next patterns:
+
+- cascade pattern
+
+ ^
+ |
+LED0 >*****____________________*****____________________*****
+ |
+LED1 >_____*****____________________*****____________________
+ |
+LED2 >__________*****____________________*****_______________
+ |
+LED3 >_______________*****____________________*****__________
+ |
+LED4 >____________________*****____________________*****_____
+ |
+ +----^----^----^----^----^----^----^----^----^----^----> time (sec)
+ 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
+
+- inversed cascade pattern
+
+ ^
+ |
+LED0 >_____********************_____********************_____
+ |
+LED1 >*****_____********************_____********************
+ |
+LED2 >**********_____********************_____***************
+ |
+LED3 >***************_____********************_____**********
+ |
+LED4 >********************_____********************_____*****
+ |
+ +----^----^----^----^----^----^----^----^----^----^----> time (sec)
+ 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
+
+- bounce pattern
+
+ ^
+ |
+LED0 >*****________________________________________*****_____
+ |
+LED1 >_____*****______________________________*****_____*****
+ |
+LED2 >__________*****____________________*****_______________
+ |
+LED3 >_______________*****__________*****____________________
+ |
+LED4 >____________________**********_________________________
+ |
+ +----^----^----^----^----^----^----^----^----^----^----> time (sec)
+ 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
+
+- inversed bounce pattern
+
+ ^
+ |
+LED0 >_____****************************************_____*****
+ |
+LED1 >*****_____******************************_____*****_____
+ |
+LED2 >**********_____********************_____***************
+ |
+LED3 >***************_____**********_____********************
+ |
+LED4 >********************__________*************************
+ |
+ +----^----^----^----^----^----^----^----^----^----^----> time (sec)
+ 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
+
+Required properties:
+- compatible : "crane,el15203000"
+- #address-cells : must be 1
+- #size-cells : must be 0
+
+Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
+apply. In particular, "reg" and "spi-max-frequency" properties must be given.
+
+Optional LED sub-node 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)
+
+Example
+-------
+
+#include <dt-bindings/leds/common.h>
+
+led-controller@0 {
+ compatible = "crane,el15203000";
+ reg = <0>;
+ spi-max-frequency = <50000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* water pipe */
+ led@50 {
+ reg = <0x50>;
+ function = "pipe";
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ /* screen frame */
+ led@53 {
+ reg = <0x53>;
+ function = "screen";
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ /* vending area */
+ led@56 {
+ reg = <0x56>;
+ function = "vend";
+ color = <LED_COLOR_ID_RED>;
+ };
+};
--
2.21.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH v9 2/2] leds: add LED driver for EL15203000 board
2019-09-18 10:52 v9 EL15203000 Oleh Kravchenko
2019-09-18 10:52 ` [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 Oleh Kravchenko
@ 2019-09-18 10:52 ` Oleh Kravchenko
1 sibling, 0 replies; 9+ messages in thread
From: Oleh Kravchenko @ 2019-09-18 10:52 UTC (permalink / raw)
To: devicetree, linux-leds, jacek.anaszewski, pavel
Cc: Oleh Kravchenko, Dan Murphy
This patch adds a LED class driver for the LEDs found on
the Crane Merchandising System EL15203000 LEDs board
(aka RED LEDs board).
Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
---
.../testing/sysfs-class-led-driver-el15203000 | 32 ++
drivers/leds/Kconfig | 13 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-el15203000.c | 357 ++++++++++++++++++
4 files changed, 403 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-el15203000
create mode 100644 drivers/leds/leds-el15203000.c
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 b/Documentation/ABI/testing/sysfs-class-led-driver-el15203000
new file mode 100644
index 000000000000..5e9cbf49da59
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-el15203000
@@ -0,0 +1,32 @@
+What: /sys/class/leds/<led>/hw_pattern
+Date: September 2019
+KernelVersion: 5.5
+Description:
+ Specify a hardware pattern for the EL15203000 LED.
+ The LEDs board supports only predefined patterns by firmware
+ for specific LEDs.
+
+ Breathing mode for Screen frame light tube:
+ "0 4000 1 4000"
+
+ Cascade mode for Pipe LED:
+ "1 800 2 800 4 800 8 800 16 800"
+
+ Inverted cascade mode for Pipe LED:
+ "30 800 29 800 27 800 23 800 15 800"
+
+ Bounce mode for Pipe LED:
+ "1 800 2 800 4 800 8 800 16 800 16 800 8 800 4 800 2 800 1 800"
+
+ Inverted bounce mode for Pipe LED:
+ "30 800 29 800 27 800 23 800 15 800 15 800 23 800 27 800 29 800 30 800"
+
+What: /sys/class/leds/<led>/repeat
+Date: September 2019
+KernelVersion: 5.5
+Description:
+ EL15203000 supports only indefinitely patterns,
+ so this file should always store -1.
+
+ For more info, please see:
+ Documentation/ABI/testing/sysfs-class-led-trigger-pattern
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1988de1d64c0..6e7703fd03d0 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -132,6 +132,19 @@ config LEDS_CR0014114
To compile this driver as a module, choose M here: the module
will be called leds-cr0014114.
+config LEDS_EL15203000
+ tristate "LED Support for Crane EL15203000"
+ depends on LEDS_CLASS
+ depends on SPI
+ depends on OF
+ help
+ This option enables support for EL15203000 LED Board
+ (aka RED LED board) which is widely used in coffee vending
+ machines produced by Crane Merchandising Systems.
+
+ To compile this driver as a module, choose M here: the module
+ will be called leds-el15203000.
+
config LEDS_LM3530
tristate "LCD Backlight driver for LM3530"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 41fb073a39c1..2da39e896ce8 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_LEDS_LM36274) += leds-lm36274.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_CR0014114) += leds-cr0014114.o
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
+obj-$(CONFIG_LEDS_EL15203000) += leds-el15203000.o
# LED Userspace Drivers
obj-$(CONFIG_LEDS_USER) += uleds.o
diff --git a/drivers/leds/leds-el15203000.c b/drivers/leds/leds-el15203000.c
new file mode 100644
index 000000000000..298b13e4807a
--- /dev/null
+++ b/drivers/leds/leds-el15203000.c
@@ -0,0 +1,357 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2019 Crane Merchandising Systems. All rights reserved.
+// Copyright (C) 2019 Oleh Kravchenko <oleg@kaa.org.ua>
+
+#include <linux/delay.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/spi/spi.h>
+
+/*
+ * EL15203000 SPI protocol description:
+ * +-----+---------+
+ * | LED | COMMAND |
+ * +-----+---------+
+ * | 1 | 1 |
+ * +-----+---------+
+ * (*) LEDs MCU board expects 20 msec delay per byte.
+ *
+ * LEDs:
+ * +----------+--------------+-------------------------------------------+
+ * | ID | NAME | DESCRIPTION |
+ * +----------+--------------+-------------------------------------------+
+ * | 'P' 0x50 | Pipe | Consists from 5 LEDs, controlled by board |
+ * +----------+--------------+-------------------------------------------+
+ * | 'S' 0x53 | Screen frame | Light tube around the screen |
+ * +----------+--------------+-------------------------------------------+
+ * | 'V' 0x56 | Vending area | Highlights a cup of coffee |
+ * +----------+--------------+-------------------------------------------+
+ *
+ * COMMAND:
+ * +----------+-----------------+--------------+--------------+
+ * | VALUES | PIPE | SCREEN FRAME | VENDING AREA |
+ * +----------+-----------------+--------------+--------------+
+ * | '0' 0x30 | Off |
+ * +----------+-----------------------------------------------+
+ * | '1' 0x31 | On |
+ * +----------+-----------------+--------------+--------------+
+ * | '2' 0x32 | Cascade | Breathing |
+ * +----------+-----------------+--------------+
+ * | '3' 0x33 | Inverse cascade |
+ * +----------+-----------------+
+ * | '4' 0x34 | Bounce |
+ * +----------+-----------------+
+ * | '5' 0x35 | Inverse bounce |
+ * +----------+-----------------+
+ */
+
+/* EL15203000 default settings */
+#define EL_FW_DELAY_USEC 20000ul
+#define EL_PATTERN_DELAY_MSEC 800u
+#define EL_PATTERN_LEN 10u
+#define EL_PATTERN_HALF_LEN (EL_PATTERN_LEN / 2)
+
+enum el15203000_command {
+ /* for all LEDs */
+ EL_OFF = '0',
+ EL_ON = '1',
+
+ /* for Screen LED */
+ EL_SCREEN_BREATHING = '2',
+
+ /* for Pipe LED */
+ EL_PIPE_CASCADE = '2',
+ EL_PIPE_INV_CASCADE = '3',
+ EL_PIPE_BOUNCE = '4',
+ EL_PIPE_INV_BOUNCE = '5',
+};
+
+struct el15203000_led {
+ struct el15203000 *priv;
+ struct led_classdev ldev;
+ u32 reg;
+};
+
+struct el15203000 {
+ struct device *dev;
+ struct mutex lock;
+ struct spi_device *spi;
+ unsigned long delay;
+ size_t count;
+ struct el15203000_led leds[];
+};
+
+static int el15203000_cmd(struct el15203000_led *led, u8 brightness)
+{
+ int ret;
+ u8 cmd[2];
+ size_t i;
+
+ mutex_lock(&led->priv->lock);
+
+ dev_dbg(led->priv->dev, "Set brightness of 0x%02x(%c) to 0x%02x(%c)",
+ led->reg, led->reg, brightness, brightness);
+
+ /* to avoid SPI mistiming with firmware we should wait some time */
+ if (time_after(led->priv->delay, jiffies)) {
+ dev_dbg(led->priv->dev, "Wait %luus to sync",
+ EL_FW_DELAY_USEC);
+
+ usleep_range(EL_FW_DELAY_USEC,
+ EL_FW_DELAY_USEC + 1);
+ }
+
+ cmd[0] = led->reg;
+ cmd[1] = brightness;
+
+ for (i = 0; i < ARRAY_SIZE(cmd); i++) {
+ if (i)
+ usleep_range(EL_FW_DELAY_USEC,
+ EL_FW_DELAY_USEC + 1);
+
+ ret = spi_write(led->priv->spi, &cmd[i], sizeof(cmd[i]));
+ if (ret) {
+ dev_err(led->priv->dev,
+ "spi_write() error %d", ret);
+ break;
+ }
+ }
+
+ led->priv->delay = jiffies + usecs_to_jiffies(EL_FW_DELAY_USEC);
+
+ mutex_unlock(&led->priv->lock);
+
+ return ret;
+}
+
+static int el15203000_set_blocking(struct led_classdev *ldev,
+ enum led_brightness brightness)
+{
+ struct el15203000_led *led = container_of(ldev,
+ struct el15203000_led,
+ ldev);
+
+ return el15203000_cmd(led, brightness == LED_OFF ? EL_OFF : EL_ON);
+}
+
+static int el15203000_pattern_set_S(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ u32 len, int repeat)
+{
+ struct el15203000_led *led = container_of(ldev,
+ struct el15203000_led,
+ ldev);
+
+ if (repeat > 0 || len != 2 ||
+ pattern[0].delta_t != 4000 || pattern[0].brightness != 0 ||
+ pattern[1].delta_t != 4000 || pattern[1].brightness != 1)
+ return -EINVAL;
+
+ dev_dbg(led->priv->dev, "Breathing mode for 0x%02x(%c)",
+ led->reg, led->reg);
+
+ return el15203000_cmd(led, EL_SCREEN_BREATHING);
+}
+
+static bool is_cascade(const struct led_pattern *pattern, u32 len,
+ bool inv, bool right)
+{
+ int val, t;
+ u32 i;
+
+ if (len != EL_PATTERN_HALF_LEN)
+ return false;
+
+ val = right ? BIT(4) : BIT(0);
+
+ for (i = 0; i < len; i++) {
+ t = inv ? ~val & GENMASK(4, 0) : val;
+
+ if (pattern[i].delta_t != EL_PATTERN_DELAY_MSEC ||
+ pattern[i].brightness != t)
+ return false;
+
+ val = right ? val >> 1 : val << 1;
+ }
+
+ return true;
+}
+
+static bool is_bounce(const struct led_pattern *pattern, u32 len, bool inv)
+{
+ if (len != EL_PATTERN_LEN)
+ return false;
+
+ return is_cascade(pattern, EL_PATTERN_HALF_LEN, inv, false) &&
+ is_cascade(pattern + EL_PATTERN_HALF_LEN,
+ EL_PATTERN_HALF_LEN, inv, true);
+}
+
+static int el15203000_pattern_set_P(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ u32 len, int repeat)
+{
+ u8 cmd;
+ struct el15203000_led *led = container_of(ldev,
+ struct el15203000_led,
+ ldev);
+
+ if (repeat > 0)
+ return -EINVAL;
+
+ if (is_cascade(pattern, len, false, false)) {
+ dev_dbg(led->priv->dev, "Cascade mode for 0x%02x(%c)",
+ led->reg, led->reg);
+
+ cmd = EL_PIPE_CASCADE;
+ } else if (is_cascade(pattern, len, true, false)) {
+ dev_dbg(led->priv->dev, "Inverse cascade mode for 0x%02x(%c)",
+ led->reg, led->reg);
+
+ cmd = EL_PIPE_INV_CASCADE;
+ } else if (is_bounce(pattern, len, false)) {
+ dev_dbg(led->priv->dev, "Bounce mode for 0x%02x(%c)",
+ led->reg, led->reg);
+
+ cmd = EL_PIPE_BOUNCE;
+ } else if (is_bounce(pattern, len, true)) {
+ dev_dbg(led->priv->dev, "Inverse bounce mode for 0x%02x(%c)",
+ led->reg, led->reg);
+
+ cmd = EL_PIPE_INV_BOUNCE;
+ } else {
+ dev_err(led->priv->dev, "Invalid hw_pattern for 0x%02x(%c)!",
+ led->reg, led->reg);
+
+ return -EINVAL;
+ }
+
+ return el15203000_cmd(led, cmd);
+}
+
+static int el15203000_pattern_clear(struct led_classdev *ldev)
+{
+ struct el15203000_led *led = container_of(ldev,
+ struct el15203000_led,
+ ldev);
+
+ return el15203000_cmd(led, EL_OFF);
+}
+
+static int el15203000_probe_dt(struct el15203000 *priv)
+{
+ struct el15203000_led *led = priv->leds;
+ struct fwnode_handle *child;
+ int ret;
+
+ device_for_each_child_node(priv->dev, child) {
+ struct led_init_data init_data = {};
+
+ ret = fwnode_property_read_u32(child, "reg", &led->reg);
+ if (ret) {
+ dev_err(priv->dev, "LED without ID number");
+ fwnode_handle_put(child);
+
+ break;
+ }
+
+ if (led->reg > U8_MAX) {
+ dev_err(priv->dev, "LED value %d is invalid", led->reg);
+ fwnode_handle_put(child);
+
+ return -EINVAL;
+ }
+
+ fwnode_property_read_string(child, "linux,default-trigger",
+ &led->ldev.default_trigger);
+
+ led->priv = priv;
+ led->ldev.max_brightness = LED_ON;
+ led->ldev.brightness_set_blocking = el15203000_set_blocking;
+
+ if (led->reg == 'S') {
+ led->ldev.pattern_set = el15203000_pattern_set_S;
+ led->ldev.pattern_clear = el15203000_pattern_clear;
+ } else if (led->reg == 'P') {
+ led->ldev.pattern_set = el15203000_pattern_set_P;
+ led->ldev.pattern_clear = el15203000_pattern_clear;
+ }
+
+ init_data.fwnode = child;
+ ret = devm_led_classdev_register_ext(priv->dev, &led->ldev,
+ &init_data);
+ if (ret) {
+ dev_err(priv->dev,
+ "failed to register LED device %s, err %d",
+ led->ldev.name, ret);
+ fwnode_handle_put(child);
+
+ break;
+ }
+
+ led++;
+ }
+
+ return ret;
+}
+
+static int el15203000_probe(struct spi_device *spi)
+{
+ struct el15203000 *priv;
+ size_t count;
+
+ count = device_get_child_node_count(&spi->dev);
+ if (!count) {
+ dev_err(&spi->dev, "LEDs are not defined in device tree!");
+ return -ENODEV;
+ }
+
+ priv = devm_kzalloc(&spi->dev, struct_size(priv, leds, count),
+ GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ mutex_init(&priv->lock);
+ priv->count = count;
+ priv->dev = &spi->dev;
+ priv->spi = spi;
+ priv->delay = jiffies -
+ usecs_to_jiffies(EL_FW_DELAY_USEC);
+
+ spi_set_drvdata(spi, priv);
+
+ return el15203000_probe_dt(priv);
+}
+
+static int el15203000_remove(struct spi_device *spi)
+{
+ struct el15203000 *priv = spi_get_drvdata(spi);
+
+ mutex_destroy(&priv->lock);
+
+ return 0;
+}
+
+static const struct of_device_id el15203000_dt_ids[] = {
+ { .compatible = "crane,el15203000", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, el15203000_dt_ids);
+
+static struct spi_driver el15203000_driver = {
+ .probe = el15203000_probe,
+ .remove = el15203000_remove,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = el15203000_dt_ids,
+ },
+};
+
+module_spi_driver(el15203000_driver);
+
+MODULE_AUTHOR("Oleh Kravchenko <oleg@kaa.org.ua>");
+MODULE_DESCRIPTION("el15203000 LED driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("spi:el15203000");
--
2.21.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000
2019-09-18 10:52 ` [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 Oleh Kravchenko
@ 2019-09-18 21:02 ` Jacek Anaszewski
2019-09-18 21:17 ` Oleh Kravchenko
0 siblings, 1 reply; 9+ messages in thread
From: Jacek Anaszewski @ 2019-09-18 21:02 UTC (permalink / raw)
To: Oleh Kravchenko, devicetree, linux-leds, pavel; +Cc: Rob Herring
Hi Oleh,
Thank you for the update.
I have some comments below. Please take a look.
On 9/18/19 12:52 PM, Oleh Kravchenko wrote:
> Add documentation and example for dt-bindings EL15203000.
> LED board (aka RED LED board) from Crane Merchandising Systems.
>
> Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
> ---
> .../bindings/leds/leds-el15203000.txt | 147 ++++++++++++++++++
> 1 file changed, 147 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-el15203000.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-el15203000.txt b/Documentation/devicetree/bindings/leds/leds-el15203000.txt
> new file mode 100644
> index 000000000000..4a9b29cc9f46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-el15203000.txt
> @@ -0,0 +1,147 @@
> +Crane Merchandising System - EL15203000 LED driver
> +--------------------------------------------------
> +
> +This LED Board (aka RED LEDs board) is widely used in
> +coffee vending machines produced by Crane Merchandising Systems.
> +The board manages 3 LEDs and supports predefined blinking patterns
> +for specific leds.
> +
> +Vending area LED encoded with symbol 'V' (hex code 0x56).
> +Doesn't have any hardware blinking pattern.
> +
> +Screen light tube LED which surrounds vending machine screen and
> +encoded with symbol 'S' (hex code 0x53). Supports blinking breathing pattern:
> +
> + ^
> + |
> +Max >_____***___________**
> + | * * *
> + | * * *
> + | * * *
> + | * * *
> +Min >*___________***______
> + |
> + +------^------^------> time (sec)
> + 0 4 8
> +
> +
> +Water Pipe LED actually consists from 5 LEDs
"(hex code 0x50)" is here missing if you want to be consistent.
> +that exposed by protocol like one LED. Supports next patterns:
> +
> +- cascade pattern
> +
> + ^
> + |
> +LED0 >*****____________________*****____________________*****
> + |
> +LED1 >_____*****____________________*****____________________
> + |
> +LED2 >__________*****____________________*****_______________
> + |
> +LED3 >_______________*****____________________*****__________
> + |
> +LED4 >____________________*****____________________*****_____
> + |
> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
> +
> +- inversed cascade pattern
> +
> + ^
> + |
> +LED0 >_____********************_____********************_____
> + |
> +LED1 >*****_____********************_____********************
> + |
> +LED2 >**********_____********************_____***************
> + |
> +LED3 >***************_____********************_____**********
> + |
> +LED4 >********************_____********************_____*****
> + |
> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
> +
> +- bounce pattern
> +
> + ^
> + |
> +LED0 >*****________________________________________*****_____
> + |
> +LED1 >_____*****______________________________*****_____*****
> + |
> +LED2 >__________*****____________________*****_______________
> + |
> +LED3 >_______________*****__________*****____________________
> + |
> +LED4 >____________________**********_________________________
> + |
> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
> +
> +- inversed bounce pattern
> +
> + ^
> + |
> +LED0 >_____****************************************_____*****
> + |
> +LED1 >*****_____******************************_____*****_____
> + |
> +LED2 >**********_____********************_____***************
> + |
> +LED3 >***************_____**********_____********************
> + |
> +LED4 >********************__________*************************
> + |
> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
Regarding this ASCII art - I presume you wanted to follow
Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt.
It was added to bindings because we support 'pattern' value
for linux,default-trigger, which in turn looks for 'led-pattern'
property, whose format needs to be documented in the LED bindings.
leds-trigger-pattern.txt documents only common syntax for software
pattern engine. Currently we don't have a means to setup hw_pattern
for the pattern trigger from DT, which is obvious omission and your
patch just brings it to light.
That said, I propose to fix it alongside and introduce led-hw-pattern
property. When present, ledtrig-pattern would setup the pattern
using pattern_set op, similarly as if it was set via sysfs hw_pattern
file.
Only in this case placing the pattern depiction here would be justified.
Otherwise, it would have to land in the ABI documentation.
> +
> +Required properties:
> +- compatible : "crane,el15203000"
> +- #address-cells : must be 1
> +- #size-cells : must be 0
> +
> +Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
> +apply. In particular, "reg" and "spi-max-frequency" properties must be given.
> +
> +Optional LED sub-node 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)
> +
> +Example
> +-------
> +
> +#include <dt-bindings/leds/common.h>
> +
> +led-controller@0 {
> + compatible = "crane,el15203000";
> + reg = <0>;
> + spi-max-frequency = <50000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* water pipe */
> + led@50 {
> + reg = <0x50>;
> + function = "pipe";
> + color = <LED_COLOR_ID_RED>;
> + };
> +
> + /* screen frame */
> + led@53 {
> + reg = <0x53>;
> + function = "screen";
> + color = <LED_COLOR_ID_RED>;
> + };
> +
> + /* vending area */
> + led@56 {
> + reg = <0x56>;
> + function = "vend";
> + color = <LED_COLOR_ID_RED>;
> + };
> +};
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000
2019-09-18 21:02 ` Jacek Anaszewski
@ 2019-09-18 21:17 ` Oleh Kravchenko
2019-09-18 21:28 ` Jacek Anaszewski
2019-10-13 12:11 ` Pavel Machek
0 siblings, 2 replies; 9+ messages in thread
From: Oleh Kravchenko @ 2019-09-18 21:17 UTC (permalink / raw)
To: Jacek Anaszewski, devicetree, linux-leds, pavel; +Cc: Rob Herring
Hello Jacek,
19.09.19 00:02, Jacek Anaszewski пише:
> Hi Oleh,
>
> Thank you for the update.
>
> I have some comments below. Please take a look.
>
> On 9/18/19 12:52 PM, Oleh Kravchenko wrote:
>> Add documentation and example for dt-bindings EL15203000.
>> LED board (aka RED LED board) from Crane Merchandising Systems.
>>
>> Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
>> ---
>> .../bindings/leds/leds-el15203000.txt | 147 ++++++++++++++++++
>> 1 file changed, 147 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/leds/leds-el15203000.txt
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-el15203000.txt b/Documentation/devicetree/bindings/leds/leds-el15203000.txt
>> new file mode 100644
>> index 000000000000..4a9b29cc9f46
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-el15203000.txt
>> @@ -0,0 +1,147 @@
>> +Crane Merchandising System - EL15203000 LED driver
>> +--------------------------------------------------
>> +
>> +This LED Board (aka RED LEDs board) is widely used in
>> +coffee vending machines produced by Crane Merchandising Systems.
>> +The board manages 3 LEDs and supports predefined blinking patterns
>> +for specific leds.
>> +
>> +Vending area LED encoded with symbol 'V' (hex code 0x56).
>> +Doesn't have any hardware blinking pattern.
>> +
>> +Screen light tube LED which surrounds vending machine screen and
>> +encoded with symbol 'S' (hex code 0x53). Supports blinking breathing pattern:
>> +
>> + ^
>> + |
>> +Max >_____***___________**
>> + | * * *
>> + | * * *
>> + | * * *
>> + | * * *
>> +Min >*___________***______
>> + |
>> + +------^------^------> time (sec)
>> + 0 4 8
>> +
>> +
>> +Water Pipe LED actually consists from 5 LEDs
>
> "(hex code 0x50)" is here missing if you want to be consistent.
>
>> +that exposed by protocol like one LED. Supports next patterns:
>> +
>> +- cascade pattern
>> +
>> + ^
>> + |
>> +LED0 >*****____________________*****____________________*****
>> + |
>> +LED1 >_____*****____________________*****____________________
>> + |
>> +LED2 >__________*****____________________*****_______________
>> + |
>> +LED3 >_______________*****____________________*****__________
>> + |
>> +LED4 >____________________*****____________________*****_____
>> + |
>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
>> +
>> +- inversed cascade pattern
>> +
>> + ^
>> + |
>> +LED0 >_____********************_____********************_____
>> + |
>> +LED1 >*****_____********************_____********************
>> + |
>> +LED2 >**********_____********************_____***************
>> + |
>> +LED3 >***************_____********************_____**********
>> + |
>> +LED4 >********************_____********************_____*****
>> + |
>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
>> +
>> +- bounce pattern
>> +
>> + ^
>> + |
>> +LED0 >*****________________________________________*****_____
>> + |
>> +LED1 >_____*****______________________________*****_____*****
>> + |
>> +LED2 >__________*****____________________*****_______________
>> + |
>> +LED3 >_______________*****__________*****____________________
>> + |
>> +LED4 >____________________**********_________________________
>> + |
>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
>> +
>> +- inversed bounce pattern
>> +
>> + ^
>> + |
>> +LED0 >_____****************************************_____*****
>> + |
>> +LED1 >*****_____******************************_____*****_____
>> + |
>> +LED2 >**********_____********************_____***************
>> + |
>> +LED3 >***************_____**********_____********************
>> + |
>> +LED4 >********************__________*************************
>> + |
>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
>
> Regarding this ASCII art - I presume you wanted to follow
> Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt.
>
> It was added to bindings because we support 'pattern' value
> for linux,default-trigger, which in turn looks for 'led-pattern'
> property, whose format needs to be documented in the LED bindings.
>
> leds-trigger-pattern.txt documents only common syntax for software
> pattern engine. Currently we don't have a means to setup hw_pattern
> for the pattern trigger from DT, which is obvious omission and your
> patch just brings it to light.
>
> That said, I propose to fix it alongside and introduce led-hw-pattern
> property. When present, ledtrig-pattern would setup the pattern
> using pattern_set op, similarly as if it was set via sysfs hw_pattern
> file.
>
> Only in this case placing the pattern depiction here would be justified.
> Otherwise, it would have to land in the ABI documentation.
You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ?
--
Best regards,
Oleh Kravchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000
2019-09-18 21:17 ` Oleh Kravchenko
@ 2019-09-18 21:28 ` Jacek Anaszewski
2019-10-13 12:11 ` Pavel Machek
1 sibling, 0 replies; 9+ messages in thread
From: Jacek Anaszewski @ 2019-09-18 21:28 UTC (permalink / raw)
To: Oleh Kravchenko, devicetree, linux-leds, pavel; +Cc: Rob Herring
On 9/18/19 11:17 PM, Oleh Kravchenko wrote:
> Hello Jacek,
>
> 19.09.19 00:02, Jacek Anaszewski пише:
>> Hi Oleh,
>>
>> Thank you for the update.
>>
>> I have some comments below. Please take a look.
>>
>> On 9/18/19 12:52 PM, Oleh Kravchenko wrote:
>>> Add documentation and example for dt-bindings EL15203000.
>>> LED board (aka RED LED board) from Crane Merchandising Systems.
>>>
>>> Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
>>> ---
>>> .../bindings/leds/leds-el15203000.txt | 147 ++++++++++++++++++
>>> 1 file changed, 147 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/leds/leds-el15203000.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/leds-el15203000.txt b/Documentation/devicetree/bindings/leds/leds-el15203000.txt
>>> new file mode 100644
>>> index 000000000000..4a9b29cc9f46
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/leds-el15203000.txt
>>> @@ -0,0 +1,147 @@
>>> +Crane Merchandising System - EL15203000 LED driver
>>> +--------------------------------------------------
>>> +
>>> +This LED Board (aka RED LEDs board) is widely used in
>>> +coffee vending machines produced by Crane Merchandising Systems.
>>> +The board manages 3 LEDs and supports predefined blinking patterns
>>> +for specific leds.
>>> +
>>> +Vending area LED encoded with symbol 'V' (hex code 0x56).
>>> +Doesn't have any hardware blinking pattern.
>>> +
>>> +Screen light tube LED which surrounds vending machine screen and
>>> +encoded with symbol 'S' (hex code 0x53). Supports blinking breathing pattern:
>>> +
>>> + ^
>>> + |
>>> +Max >_____***___________**
>>> + | * * *
>>> + | * * *
>>> + | * * *
>>> + | * * *
>>> +Min >*___________***______
>>> + |
>>> + +------^------^------> time (sec)
>>> + 0 4 8
>>> +
>>> +
>>> +Water Pipe LED actually consists from 5 LEDs
>>
>> "(hex code 0x50)" is here missing if you want to be consistent.
>>
>>> +that exposed by protocol like one LED. Supports next patterns:
>>> +
>>> +- cascade pattern
>>> +
>>> + ^
>>> + |
>>> +LED0 >*****____________________*****____________________*****
>>> + |
>>> +LED1 >_____*****____________________*****____________________
>>> + |
>>> +LED2 >__________*****____________________*****_______________
>>> + |
>>> +LED3 >_______________*****____________________*****__________
>>> + |
>>> +LED4 >____________________*****____________________*****_____
>>> + |
>>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
>>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
>>> +
>>> +- inversed cascade pattern
>>> +
>>> + ^
>>> + |
>>> +LED0 >_____********************_____********************_____
>>> + |
>>> +LED1 >*****_____********************_____********************
>>> + |
>>> +LED2 >**********_____********************_____***************
>>> + |
>>> +LED3 >***************_____********************_____**********
>>> + |
>>> +LED4 >********************_____********************_____*****
>>> + |
>>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
>>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
>>> +
>>> +- bounce pattern
>>> +
>>> + ^
>>> + |
>>> +LED0 >*****________________________________________*****_____
>>> + |
>>> +LED1 >_____*****______________________________*****_____*****
>>> + |
>>> +LED2 >__________*****____________________*****_______________
>>> + |
>>> +LED3 >_______________*****__________*****____________________
>>> + |
>>> +LED4 >____________________**********_________________________
>>> + |
>>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
>>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
>>> +
>>> +- inversed bounce pattern
>>> +
>>> + ^
>>> + |
>>> +LED0 >_____****************************************_____*****
>>> + |
>>> +LED1 >*****_____******************************_____*****_____
>>> + |
>>> +LED2 >**********_____********************_____***************
>>> + |
>>> +LED3 >***************_____**********_____********************
>>> + |
>>> +LED4 >********************__________*************************
>>> + |
>>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec)
>>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8
>>
>> Regarding this ASCII art - I presume you wanted to follow
>> Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt.
>>
>> It was added to bindings because we support 'pattern' value
>> for linux,default-trigger, which in turn looks for 'led-pattern'
>> property, whose format needs to be documented in the LED bindings.
>>
>> leds-trigger-pattern.txt documents only common syntax for software
>> pattern engine. Currently we don't have a means to setup hw_pattern
>> for the pattern trigger from DT, which is obvious omission and your
>> patch just brings it to light.
>>
>> That said, I propose to fix it alongside and introduce led-hw-pattern
>> property. When present, ledtrig-pattern would setup the pattern
>> using pattern_set op, similarly as if it was set via sysfs hw_pattern
>> file.
>>
>> Only in this case placing the pattern depiction here would be justified.
>> Otherwise, it would have to land in the ABI documentation.
>
> You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ?
>
Yes, we can cover led-hw-pattern property later.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000
2019-09-18 21:17 ` Oleh Kravchenko
2019-09-18 21:28 ` Jacek Anaszewski
@ 2019-10-13 12:11 ` Pavel Machek
2019-10-13 16:47 ` Jacek Anaszewski
1 sibling, 1 reply; 9+ messages in thread
From: Pavel Machek @ 2019-10-13 12:11 UTC (permalink / raw)
To: Oleh Kravchenko; +Cc: Jacek Anaszewski, devicetree, linux-leds, Rob Herring
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
Hi!
> > Regarding this ASCII art - I presume you wanted to follow
> > Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt.
> >
> > It was added to bindings because we support 'pattern' value
> > for linux,default-trigger, which in turn looks for 'led-pattern'
> > property, whose format needs to be documented in the LED bindings.
> >
> > leds-trigger-pattern.txt documents only common syntax for software
> > pattern engine. Currently we don't have a means to setup hw_pattern
> > for the pattern trigger from DT, which is obvious omission and your
> > patch just brings it to light.
> >
> > That said, I propose to fix it alongside and introduce led-hw-pattern
> > property. When present, ledtrig-pattern would setup the pattern
> > using pattern_set op, similarly as if it was set via sysfs hw_pattern
> > file.
> >
> > Only in this case placing the pattern depiction here would be justified.
> > Otherwise, it would have to land in the ABI documentation.
>
> You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ?
I don't see if this got a reply. Yes,
Documentation/ABI/testing/sysfs-class-led-driver-el15203000 sounds
like a right place for the sysfs description.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000
2019-10-13 12:11 ` Pavel Machek
@ 2019-10-13 16:47 ` Jacek Anaszewski
2019-10-13 17:29 ` Oleh Kravchenko
0 siblings, 1 reply; 9+ messages in thread
From: Jacek Anaszewski @ 2019-10-13 16:47 UTC (permalink / raw)
To: Pavel Machek, Oleh Kravchenko; +Cc: devicetree, linux-leds, Rob Herring
Hi Pavel.
On 10/13/19 2:11 PM, Pavel Machek wrote:
> Hi!
>
>>> Regarding this ASCII art - I presume you wanted to follow
>>> Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt.
>>>
>>> It was added to bindings because we support 'pattern' value
>>> for linux,default-trigger, which in turn looks for 'led-pattern'
>>> property, whose format needs to be documented in the LED bindings.
>>>
>>> leds-trigger-pattern.txt documents only common syntax for software
>>> pattern engine. Currently we don't have a means to setup hw_pattern
>>> for the pattern trigger from DT, which is obvious omission and your
>>> patch just brings it to light.
>>>
>>> That said, I propose to fix it alongside and introduce led-hw-pattern
>>> property. When present, ledtrig-pattern would setup the pattern
>>> using pattern_set op, similarly as if it was set via sysfs hw_pattern
>>> file.
>>>
>>> Only in this case placing the pattern depiction here would be justified.
>>> Otherwise, it would have to land in the ABI documentation.
>>
>> You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ?
>
> I don't see if this got a reply. Yes,
> Documentation/ABI/testing/sysfs-class-led-driver-el15203000 sounds
> like a right place for the sysfs description.
There was no explicit reply because Oleh sent the update with this
change before I managed to respond. And the patch is already in the
for-next branch with the file in the discussed location. So the reply
was in the form of my later confirmation that the patch was applied.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000
2019-10-13 16:47 ` Jacek Anaszewski
@ 2019-10-13 17:29 ` Oleh Kravchenko
0 siblings, 0 replies; 9+ messages in thread
From: Oleh Kravchenko @ 2019-10-13 17:29 UTC (permalink / raw)
To: Jacek Anaszewski, Pavel Machek; +Cc: devicetree, linux-leds, Rob Herring
[-- Attachment #1.1: Type: text/plain, Size: 1772 bytes --]
Hello Pavel,
13.10.19 19:47, Jacek Anaszewski пише:
> Hi Pavel.
>
> On 10/13/19 2:11 PM, Pavel Machek wrote:
>> Hi!
>>
>>>> Regarding this ASCII art - I presume you wanted to follow
>>>> Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt.
>>>>
>>>> It was added to bindings because we support 'pattern' value
>>>> for linux,default-trigger, which in turn looks for 'led-pattern'
>>>> property, whose format needs to be documented in the LED bindings.
>>>>
>>>> leds-trigger-pattern.txt documents only common syntax for software
>>>> pattern engine. Currently we don't have a means to setup hw_pattern
>>>> for the pattern trigger from DT, which is obvious omission and your
>>>> patch just brings it to light.
>>>>
>>>> That said, I propose to fix it alongside and introduce led-hw-pattern
>>>> property. When present, ledtrig-pattern would setup the pattern
>>>> using pattern_set op, similarly as if it was set via sysfs hw_pattern
>>>> file.
>>>>
>>>> Only in this case placing the pattern depiction here would be justified.
>>>> Otherwise, it would have to land in the ABI documentation.
>>>
>>> You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ?
>>
>> I don't see if this got a reply. Yes,
>> Documentation/ABI/testing/sysfs-class-led-driver-el15203000 sounds
>> like a right place for the sysfs description.
>
> There was no explicit reply because Oleh sent the update with this
> change before I managed to respond. And the patch is already in the
> for-next branch with the file in the discussed location. So the reply
> was in the form of my later confirmation that the patch was applied.
>
Anyway thanks for reply.
--
Best regards,
Oleh Kravchenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-10-13 17:29 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-18 10:52 v9 EL15203000 Oleh Kravchenko
2019-09-18 10:52 ` [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 Oleh Kravchenko
2019-09-18 21:02 ` Jacek Anaszewski
2019-09-18 21:17 ` Oleh Kravchenko
2019-09-18 21:28 ` Jacek Anaszewski
2019-10-13 12:11 ` Pavel Machek
2019-10-13 16:47 ` Jacek Anaszewski
2019-10-13 17:29 ` Oleh Kravchenko
2019-09-18 10:52 ` [PATCH v9 2/2] leds: add LED driver for EL15203000 board Oleh Kravchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).