* [PATCH v6 0/5] Add DT support for netxbig LEDs
@ 2015-09-26 21:02 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: Jacek Anaszewski, Bryan Wu, Richard Purdie
Cc: Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vincent Donnefort, Yoann Sculo,
Linus Walleij, Alexandre Courbot, Rob Herring, linux-leds,
linux-arm-kernel, devicetree
Hello,
This patch series adds DT support for the LEDs found on the
Kirkwood-based LaCie boards 2Big and 5Big Network v2.
Changes for v2:
- Check timer mode value retrieved from DT.
- In netxbig_leds_get_of_pdata, don't use unsigned long variables to get
timer delay values from DT with function of_property_read_u32_index.
Instead, use a temporary u32 variable. This allows to silence a static
checker warning.
- Make timer property optional in the binding documentation. It is now
aligned with the driver code.
Changes for v3:
- Fix pointer usage with the temporary u32 variable while calling
of_property_read_u32_index.
Changes for v4:
- In DT binding document netxbig-gpio-ext.txt, detail byte order for
registers and latch mechanism for "enable-gpio".
- In leds-netxbig.c, add some error messages.
- In leds-netxbig.c, fix some "sizeof" style issues.
- In leds-netxbig.c, in netxbig_leds_get_of_pdata(), move the
of_property_read_string() calls after the error-prone checks.
- Add some Acked-by.
Changes for v5:
- Rename DT property "bright-max" into the more common "max-brightness".
- Make use of the "max-brightness" DT property. Instead of counting the
data pins of the GPIO extension bus, use "max-brightness" to get the
maximum brightness level.
- Add a patch to convert the leds-netxbig driver to the devm_ functions.
Changes for v6:
- Add a patch to set led_classdev max_brightness in the leds-netxbig
driver.
- Decrement the current child node refcount with of_node_put() when an
error happens while iterating with for_each_child_of_node().
Thanks,
Simon
Simon Guinot (5):
leds: netxbig: add device tree binding
ARM: Kirkwood: add LED DT entries for netxbig boards
ARM: mvebu: remove static LED setup for netxbig boards
leds: netxbig: convert to use the devm_ functions
leds: netxbig: set led_classdev max_brightness
.../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
.../devicetree/bindings/leds/leds-netxbig.txt | 92 ++++++
arch/arm/boot/dts/kirkwood-net5big.dts | 60 ++++
arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++
arch/arm/mach-mvebu/Kconfig | 7 -
arch/arm/mach-mvebu/Makefile | 1 -
arch/arm/mach-mvebu/board.h | 21 --
arch/arm/mach-mvebu/kirkwood.c | 4 -
arch/arm/mach-mvebu/netxbig.c | 191 ------------
drivers/leds/leds-netxbig.c | 336 ++++++++++++++++-----
include/dt-bindings/leds/leds-netxbig.h | 18 ++
.../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
12 files changed, 531 insertions(+), 302 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
delete mode 100644 arch/arm/mach-mvebu/board.h
delete mode 100644 arch/arm/mach-mvebu/netxbig.c
create mode 100644 include/dt-bindings/leds/leds-netxbig.h
--
2.1.4
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 0/5] Add DT support for netxbig LEDs
@ 2015-09-26 21:02 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This patch series adds DT support for the LEDs found on the
Kirkwood-based LaCie boards 2Big and 5Big Network v2.
Changes for v2:
- Check timer mode value retrieved from DT.
- In netxbig_leds_get_of_pdata, don't use unsigned long variables to get
timer delay values from DT with function of_property_read_u32_index.
Instead, use a temporary u32 variable. This allows to silence a static
checker warning.
- Make timer property optional in the binding documentation. It is now
aligned with the driver code.
Changes for v3:
- Fix pointer usage with the temporary u32 variable while calling
of_property_read_u32_index.
Changes for v4:
- In DT binding document netxbig-gpio-ext.txt, detail byte order for
registers and latch mechanism for "enable-gpio".
- In leds-netxbig.c, add some error messages.
- In leds-netxbig.c, fix some "sizeof" style issues.
- In leds-netxbig.c, in netxbig_leds_get_of_pdata(), move the
of_property_read_string() calls after the error-prone checks.
- Add some Acked-by.
Changes for v5:
- Rename DT property "bright-max" into the more common "max-brightness".
- Make use of the "max-brightness" DT property. Instead of counting the
data pins of the GPIO extension bus, use "max-brightness" to get the
maximum brightness level.
- Add a patch to convert the leds-netxbig driver to the devm_ functions.
Changes for v6:
- Add a patch to set led_classdev max_brightness in the leds-netxbig
driver.
- Decrement the current child node refcount with of_node_put() when an
error happens while iterating with for_each_child_of_node().
Thanks,
Simon
Simon Guinot (5):
leds: netxbig: add device tree binding
ARM: Kirkwood: add LED DT entries for netxbig boards
ARM: mvebu: remove static LED setup for netxbig boards
leds: netxbig: convert to use the devm_ functions
leds: netxbig: set led_classdev max_brightness
.../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
.../devicetree/bindings/leds/leds-netxbig.txt | 92 ++++++
arch/arm/boot/dts/kirkwood-net5big.dts | 60 ++++
arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++
arch/arm/mach-mvebu/Kconfig | 7 -
arch/arm/mach-mvebu/Makefile | 1 -
arch/arm/mach-mvebu/board.h | 21 --
arch/arm/mach-mvebu/kirkwood.c | 4 -
arch/arm/mach-mvebu/netxbig.c | 191 ------------
drivers/leds/leds-netxbig.c | 336 ++++++++++++++++-----
include/dt-bindings/leds/leds-netxbig.h | 18 ++
.../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
12 files changed, 531 insertions(+), 302 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
delete mode 100644 arch/arm/mach-mvebu/board.h
delete mode 100644 arch/arm/mach-mvebu/netxbig.c
create mode 100644 include/dt-bindings/leds/leds-netxbig.h
--
2.1.4
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 1/5] leds: netxbig: add device tree binding
2015-09-26 21:02 ` Simon Guinot
@ 2015-09-26 21:02 ` Simon Guinot
-1 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: Jacek Anaszewski, Bryan Wu, Richard Purdie
Cc: Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vincent Donnefort, Yoann Sculo,
Linus Walleij, Alexandre Courbot, Rob Herring, linux-leds,
linux-arm-kernel, devicetree
This patch adds device tree support for the netxbig LEDs.
This also introduces a additionnal DT binding for the GPIO extension bus
(netxbig-gpio-ext) used to configure the LEDs. Since this bus could also
be used to control other devices, then it seems more suitable to have it
in a separate DT binding.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
.../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
.../devicetree/bindings/leds/leds-netxbig.txt | 92 +++++++
drivers/leds/leds-netxbig.c | 280 +++++++++++++++++++--
include/dt-bindings/leds/leds-netxbig.h | 18 ++
.../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
5 files changed, 391 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
create mode 100644 include/dt-bindings/leds/leds-netxbig.h
Changes for v2:
- Check timer mode value retrieved from DT.
- In netxbig_leds_get_of_pdata, don't use unsigned long variables to get
timer delay values from DT with function of_property_read_u32_index.
Instead, use a temporary u32 variable. This allows to silence a static
checker warning.
- Make timer property optional in the binding documentation. It is now
aligned with the driver code.
Changes for v3:
- Fix pointer usage with the temporary u32 variable while calling
of_property_read_u32_index.
Changes for v4:
- In DT binding document netxbig-gpio-ext.txt, detail byte order for
registers and latch mechanism for "enable-gpio".
- In leds-netxbig.c, add some error messages.
- In leds-netxbig.c, fix some "sizeof" style issues.
- In leds-netxbig.c, in netxbig_leds_get_of_pdata(), move the
of_property_read_string() calls after the error-prone checks.
- Add some Acked-by.
Changes for v5:
- Rename DT property "bright-max" into the more common "max-brightness".
- Make use of the "max-brightness" DT property. Instead of counting the
data pins of the GPIO extension bus, use "max-brightness" to get the
maximum brightness level.
Changes for v6:
- Decrement the current child node refcount with of_node_put() when an
error happens while iterating with for_each_child_of_node().
diff --git a/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt b/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
new file mode 100644
index 000000000000..50ec2e690701
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
@@ -0,0 +1,22 @@
+Binding for the GPIO extension bus found on some LaCie/Seagate boards
+(Example: 2Big/5Big Network v2, 2Big NAS).
+
+Required properties:
+- compatible: "lacie,netxbig-gpio-ext".
+- addr-gpios: GPIOs representing the address register (LSB -> MSB).
+- data-gpios: GPIOs representing the data register (LSB -> MSB).
+- enable-gpio: latches the new configuration (address, data) on raising edge.
+
+Example:
+
+netxbig_gpio_ext: netxbig-gpio-ext {
+ compatible = "lacie,netxbig-gpio-ext";
+
+ addr-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH
+ &gpio1 16 GPIO_ACTIVE_HIGH
+ &gpio1 17 GPIO_ACTIVE_HIGH>;
+ data-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH
+ &gpio1 13 GPIO_ACTIVE_HIGH
+ &gpio1 14 GPIO_ACTIVE_HIGH>;
+ enable-gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/leds/leds-netxbig.txt b/Documentation/devicetree/bindings/leds/leds-netxbig.txt
new file mode 100644
index 000000000000..5ef92a26d768
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-netxbig.txt
@@ -0,0 +1,92 @@
+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>;
+ };
+};
diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
index 25e419752a7b..e1f3c2632278 100644
--- a/drivers/leds/leds-netxbig.c
+++ b/drivers/leds/leds-netxbig.c
@@ -26,6 +26,7 @@
#include <linux/spinlock.h>
#include <linux/platform_device.h>
#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <linux/leds.h>
#include <linux/platform_data/leds-kirkwood-netxbig.h>
@@ -140,6 +141,11 @@ struct netxbig_led_data {
spinlock_t lock;
};
+struct netxbig_led_priv {
+ struct netxbig_led_platform_data *pdata;
+ struct netxbig_led_data leds_data[];
+};
+
static int netxbig_led_get_timer_mode(enum netxbig_led_mode *mode,
unsigned long delay_on,
unsigned long delay_off,
@@ -304,12 +310,12 @@ static void delete_netxbig_led(struct netxbig_led_data *led_dat)
led_classdev_unregister(&led_dat->cdev);
}
-static int
-create_netxbig_led(struct platform_device *pdev,
- struct netxbig_led_data *led_dat,
- const struct netxbig_led *template)
+static int create_netxbig_led(struct platform_device *pdev, int led,
+ struct netxbig_led_priv *priv)
{
- struct netxbig_led_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ struct netxbig_led_platform_data *pdata = priv->pdata;
+ struct netxbig_led_data *led_dat = &priv->leds_data[led];
+ const struct netxbig_led *template = &priv->pdata->leds[led];
spin_lock_init(&led_dat->lock);
led_dat->gpio_ext = pdata->gpio_ext;
@@ -333,7 +339,7 @@ create_netxbig_led(struct platform_device *pdev,
led_dat->mode_addr = template->mode_addr;
led_dat->mode_val = template->mode_val;
led_dat->bright_addr = template->bright_addr;
- led_dat->bright_max = (1 << pdata->gpio_ext->num_data) - 1;
+ led_dat->bright_max = template->bright_max;
led_dat->timer = pdata->timer;
led_dat->num_timer = pdata->num_timer;
/*
@@ -346,38 +352,269 @@ create_netxbig_led(struct platform_device *pdev,
return led_classdev_register(&pdev->dev, &led_dat->cdev);
}
+#ifdef CONFIG_OF_GPIO
+static int gpio_ext_get_of_pdata(struct device *dev, struct device_node *np,
+ struct netxbig_gpio_ext *gpio_ext)
+{
+ int *addr, *data;
+ int num_addr, num_data;
+ int ret;
+ int i;
+
+ ret = of_gpio_named_count(np, "addr-gpios");
+ if (ret < 0) {
+ dev_err(dev,
+ "Failed to count GPIOs in DT property addr-gpios\n");
+ return ret;
+ }
+ num_addr = ret;
+ addr = devm_kzalloc(dev, num_addr * sizeof(*addr), GFP_KERNEL);
+ if (!addr)
+ return -ENOMEM;
+
+ for (i = 0; i < num_addr; i++) {
+ ret = of_get_named_gpio(np, "addr-gpios", i);
+ if (ret < 0)
+ return ret;
+ addr[i] = ret;
+ }
+ gpio_ext->addr = addr;
+ gpio_ext->num_addr = num_addr;
+
+ ret = of_gpio_named_count(np, "data-gpios");
+ if (ret < 0) {
+ dev_err(dev,
+ "Failed to count GPIOs in DT property data-gpios\n");
+ return ret;
+ }
+ num_data = ret;
+ data = devm_kzalloc(dev, num_data * sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ for (i = 0; i < num_data; i++) {
+ ret = of_get_named_gpio(np, "data-gpios", i);
+ if (ret < 0)
+ return ret;
+ data[i] = ret;
+ }
+ gpio_ext->data = data;
+ gpio_ext->num_data = num_data;
+
+ ret = of_get_named_gpio(np, "enable-gpio", 0);
+ if (ret < 0) {
+ dev_err(dev,
+ "Failed to get GPIO from DT property enable-gpio\n");
+ return ret;
+ }
+ gpio_ext->enable = ret;
+
+ return 0;
+}
+
+static int netxbig_leds_get_of_pdata(struct device *dev,
+ struct netxbig_led_platform_data *pdata)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *gpio_ext_np;
+ struct device_node *child;
+ struct netxbig_gpio_ext *gpio_ext;
+ struct netxbig_led_timer *timers;
+ struct netxbig_led *leds, *led;
+ int num_timers;
+ int num_leds = 0;
+ int ret;
+ int i;
+
+ /* GPIO extension */
+ gpio_ext_np = of_parse_phandle(np, "gpio-ext", 0);
+ if (!gpio_ext_np) {
+ dev_err(dev, "Failed to get DT handle gpio-ext\n");
+ return -EINVAL;
+ }
+
+ gpio_ext = devm_kzalloc(dev, sizeof(*gpio_ext), GFP_KERNEL);
+ if (!gpio_ext)
+ return -ENOMEM;
+ ret = gpio_ext_get_of_pdata(dev, gpio_ext_np, gpio_ext);
+ if (ret)
+ return ret;
+ of_node_put(gpio_ext_np);
+ pdata->gpio_ext = gpio_ext;
+
+ /* Timers (optional) */
+ ret = of_property_count_u32_elems(np, "timers");
+ if (ret > 0) {
+ if (ret % 3)
+ return -EINVAL;
+ num_timers = ret / 3;
+ timers = devm_kzalloc(dev, num_timers * sizeof(*timers),
+ GFP_KERNEL);
+ if (!timers)
+ return -ENOMEM;
+ for (i = 0; i < num_timers; i++) {
+ u32 tmp;
+
+ of_property_read_u32_index(np, "timers", 3 * i,
+ &timers[i].mode);
+ if (timers[i].mode >= NETXBIG_LED_MODE_NUM)
+ return -EINVAL;
+ of_property_read_u32_index(np, "timers",
+ 3 * i + 1, &tmp);
+ timers[i].delay_on = tmp;
+ of_property_read_u32_index(np, "timers",
+ 3 * i + 2, &tmp);
+ timers[i].delay_off = tmp;
+ }
+ pdata->timer = timers;
+ pdata->num_timer = num_timers;
+ }
+
+ /* LEDs */
+ num_leds = of_get_child_count(np);
+ if (!num_leds) {
+ dev_err(dev, "No LED subnodes found in DT\n");
+ return -ENODEV;
+ }
+
+ leds = devm_kzalloc(dev, num_leds * sizeof(*leds), GFP_KERNEL);
+ if (!leds)
+ return -ENOMEM;
+
+ led = leds;
+ for_each_child_of_node(np, child) {
+ const char *string;
+ int *mode_val;
+ int num_modes;
+
+ ret = of_property_read_u32(child, "mode-addr",
+ &led->mode_addr);
+ if (ret)
+ goto err_node_put;
+
+ ret = of_property_read_u32(child, "bright-addr",
+ &led->bright_addr);
+ if (ret)
+ goto err_node_put;
+
+ ret = of_property_read_u32(child, "max-brightness",
+ &led->bright_max);
+ if (ret)
+ goto err_node_put;
+
+ mode_val =
+ devm_kzalloc(dev,
+ NETXBIG_LED_MODE_NUM * sizeof(*mode_val),
+ GFP_KERNEL);
+ if (!mode_val) {
+ ret = -ENOMEM;
+ goto err_node_put;
+ }
+
+ for (i = 0; i < NETXBIG_LED_MODE_NUM; i++)
+ mode_val[i] = NETXBIG_LED_INVALID_MODE;
+
+ ret = of_property_count_u32_elems(child, "mode-val");
+ if (ret < 0 || ret % 2) {
+ ret = -EINVAL;
+ goto err_node_put;
+ }
+ num_modes = ret / 2;
+ if (num_modes > NETXBIG_LED_MODE_NUM) {
+ ret = -EINVAL;
+ goto err_node_put;
+ }
+
+ for (i = 0; i < num_modes; i++) {
+ int mode;
+ int val;
+
+ of_property_read_u32_index(child,
+ "mode-val", 2 * i, &mode);
+ of_property_read_u32_index(child,
+ "mode-val", 2 * i + 1, &val);
+ if (mode >= NETXBIG_LED_MODE_NUM) {
+ ret = -EINVAL;
+ goto err_node_put;
+ }
+ mode_val[mode] = val;
+ }
+ led->mode_val = mode_val;
+
+ if (!of_property_read_string(child, "label", &string))
+ led->name = string;
+ else
+ led->name = child->name;
+
+ if (!of_property_read_string(child,
+ "linux,default-trigger", &string))
+ led->default_trigger = string;
+
+ led++;
+ }
+
+ pdata->leds = leds;
+ pdata->num_leds = num_leds;
+
+ return 0;
+
+err_node_put:
+ of_node_put(child);
+ return ret;
+}
+
+static const struct of_device_id of_netxbig_leds_match[] = {
+ { .compatible = "lacie,netxbig-leds", },
+ {},
+};
+#else
+static inline int
+netxbig_leds_get_of_pdata(struct device *dev,
+ struct netxbig_led_platform_data *pdata)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_OF_GPIO */
+
static int netxbig_led_probe(struct platform_device *pdev)
{
struct netxbig_led_platform_data *pdata = dev_get_platdata(&pdev->dev);
- struct netxbig_led_data *leds_data;
+ struct netxbig_led_priv *priv;
int i;
int ret;
- if (!pdata)
- return -EINVAL;
+ if (!pdata) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ ret = netxbig_leds_get_of_pdata(&pdev->dev, pdata);
+ if (ret)
+ return ret;
+ }
- leds_data = devm_kzalloc(&pdev->dev,
- sizeof(struct netxbig_led_data) * pdata->num_leds, GFP_KERNEL);
- if (!leds_data)
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv) +
+ pdata->num_leds * sizeof(struct netxbig_led_data),
+ GFP_KERNEL);
+ if (!priv)
return -ENOMEM;
+ priv->pdata = pdata;
ret = gpio_ext_init(pdata->gpio_ext);
if (ret < 0)
return ret;
for (i = 0; i < pdata->num_leds; i++) {
- ret = create_netxbig_led(pdev, &leds_data[i], &pdata->leds[i]);
+ ret = create_netxbig_led(pdev, i, priv);
if (ret < 0)
goto err_free_leds;
}
-
- platform_set_drvdata(pdev, leds_data);
+ platform_set_drvdata(pdev, priv);
return 0;
err_free_leds:
for (i = i - 1; i >= 0; i--)
- delete_netxbig_led(&leds_data[i]);
+ delete_netxbig_led(&priv->leds_data[i]);
gpio_ext_free(pdata->gpio_ext);
return ret;
@@ -385,14 +622,12 @@ err_free_leds:
static int netxbig_led_remove(struct platform_device *pdev)
{
- struct netxbig_led_platform_data *pdata = dev_get_platdata(&pdev->dev);
- struct netxbig_led_data *leds_data;
+ struct netxbig_led_priv *priv = platform_get_drvdata(pdev);
+ struct netxbig_led_platform_data *pdata = priv->pdata;
int i;
- leds_data = platform_get_drvdata(pdev);
-
for (i = 0; i < pdata->num_leds; i++)
- delete_netxbig_led(&leds_data[i]);
+ delete_netxbig_led(&priv->leds_data[i]);
gpio_ext_free(pdata->gpio_ext);
@@ -403,7 +638,8 @@ static struct platform_driver netxbig_led_driver = {
.probe = netxbig_led_probe,
.remove = netxbig_led_remove,
.driver = {
- .name = "leds-netxbig",
+ .name = "leds-netxbig",
+ .of_match_table = of_match_ptr(of_netxbig_leds_match),
},
};
diff --git a/include/dt-bindings/leds/leds-netxbig.h b/include/dt-bindings/leds/leds-netxbig.h
new file mode 100644
index 000000000000..92658b0310b2
--- /dev/null
+++ b/include/dt-bindings/leds/leds-netxbig.h
@@ -0,0 +1,18 @@
+/*
+ * This header provides constants for netxbig LED bindings.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _DT_BINDINGS_LEDS_NETXBIG_H
+#define _DT_BINDINGS_LEDS_NETXBIG_H
+
+#define NETXBIG_LED_OFF 0
+#define NETXBIG_LED_ON 1
+#define NETXBIG_LED_SATA 2
+#define NETXBIG_LED_TIMER1 3
+#define NETXBIG_LED_TIMER2 4
+
+#endif /* _DT_BINDINGS_LEDS_NETXBIG_H */
diff --git a/include/linux/platform_data/leds-kirkwood-netxbig.h b/include/linux/platform_data/leds-kirkwood-netxbig.h
index d2be19a51acd..3c85a735c380 100644
--- a/include/linux/platform_data/leds-kirkwood-netxbig.h
+++ b/include/linux/platform_data/leds-kirkwood-netxbig.h
@@ -40,6 +40,7 @@ struct netxbig_led {
int mode_addr;
int *mode_val;
int bright_addr;
+ int bright_max;
};
struct netxbig_led_platform_data {
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v6 1/5] leds: netxbig: add device tree binding
@ 2015-09-26 21:02 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds device tree support for the netxbig LEDs.
This also introduces a additionnal DT binding for the GPIO extension bus
(netxbig-gpio-ext) used to configure the LEDs. Since this bus could also
be used to control other devices, then it seems more suitable to have it
in a separate DT binding.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
.../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
.../devicetree/bindings/leds/leds-netxbig.txt | 92 +++++++
drivers/leds/leds-netxbig.c | 280 +++++++++++++++++++--
include/dt-bindings/leds/leds-netxbig.h | 18 ++
.../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
5 files changed, 391 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
create mode 100644 include/dt-bindings/leds/leds-netxbig.h
Changes for v2:
- Check timer mode value retrieved from DT.
- In netxbig_leds_get_of_pdata, don't use unsigned long variables to get
timer delay values from DT with function of_property_read_u32_index.
Instead, use a temporary u32 variable. This allows to silence a static
checker warning.
- Make timer property optional in the binding documentation. It is now
aligned with the driver code.
Changes for v3:
- Fix pointer usage with the temporary u32 variable while calling
of_property_read_u32_index.
Changes for v4:
- In DT binding document netxbig-gpio-ext.txt, detail byte order for
registers and latch mechanism for "enable-gpio".
- In leds-netxbig.c, add some error messages.
- In leds-netxbig.c, fix some "sizeof" style issues.
- In leds-netxbig.c, in netxbig_leds_get_of_pdata(), move the
of_property_read_string() calls after the error-prone checks.
- Add some Acked-by.
Changes for v5:
- Rename DT property "bright-max" into the more common "max-brightness".
- Make use of the "max-brightness" DT property. Instead of counting the
data pins of the GPIO extension bus, use "max-brightness" to get the
maximum brightness level.
Changes for v6:
- Decrement the current child node refcount with of_node_put() when an
error happens while iterating with for_each_child_of_node().
diff --git a/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt b/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
new file mode 100644
index 000000000000..50ec2e690701
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
@@ -0,0 +1,22 @@
+Binding for the GPIO extension bus found on some LaCie/Seagate boards
+(Example: 2Big/5Big Network v2, 2Big NAS).
+
+Required properties:
+- compatible: "lacie,netxbig-gpio-ext".
+- addr-gpios: GPIOs representing the address register (LSB -> MSB).
+- data-gpios: GPIOs representing the data register (LSB -> MSB).
+- enable-gpio: latches the new configuration (address, data) on raising edge.
+
+Example:
+
+netxbig_gpio_ext: netxbig-gpio-ext {
+ compatible = "lacie,netxbig-gpio-ext";
+
+ addr-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH
+ &gpio1 16 GPIO_ACTIVE_HIGH
+ &gpio1 17 GPIO_ACTIVE_HIGH>;
+ data-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH
+ &gpio1 13 GPIO_ACTIVE_HIGH
+ &gpio1 14 GPIO_ACTIVE_HIGH>;
+ enable-gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/leds/leds-netxbig.txt b/Documentation/devicetree/bindings/leds/leds-netxbig.txt
new file mode 100644
index 000000000000..5ef92a26d768
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-netxbig.txt
@@ -0,0 +1,92 @@
+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>;
+ };
+};
diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
index 25e419752a7b..e1f3c2632278 100644
--- a/drivers/leds/leds-netxbig.c
+++ b/drivers/leds/leds-netxbig.c
@@ -26,6 +26,7 @@
#include <linux/spinlock.h>
#include <linux/platform_device.h>
#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <linux/leds.h>
#include <linux/platform_data/leds-kirkwood-netxbig.h>
@@ -140,6 +141,11 @@ struct netxbig_led_data {
spinlock_t lock;
};
+struct netxbig_led_priv {
+ struct netxbig_led_platform_data *pdata;
+ struct netxbig_led_data leds_data[];
+};
+
static int netxbig_led_get_timer_mode(enum netxbig_led_mode *mode,
unsigned long delay_on,
unsigned long delay_off,
@@ -304,12 +310,12 @@ static void delete_netxbig_led(struct netxbig_led_data *led_dat)
led_classdev_unregister(&led_dat->cdev);
}
-static int
-create_netxbig_led(struct platform_device *pdev,
- struct netxbig_led_data *led_dat,
- const struct netxbig_led *template)
+static int create_netxbig_led(struct platform_device *pdev, int led,
+ struct netxbig_led_priv *priv)
{
- struct netxbig_led_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ struct netxbig_led_platform_data *pdata = priv->pdata;
+ struct netxbig_led_data *led_dat = &priv->leds_data[led];
+ const struct netxbig_led *template = &priv->pdata->leds[led];
spin_lock_init(&led_dat->lock);
led_dat->gpio_ext = pdata->gpio_ext;
@@ -333,7 +339,7 @@ create_netxbig_led(struct platform_device *pdev,
led_dat->mode_addr = template->mode_addr;
led_dat->mode_val = template->mode_val;
led_dat->bright_addr = template->bright_addr;
- led_dat->bright_max = (1 << pdata->gpio_ext->num_data) - 1;
+ led_dat->bright_max = template->bright_max;
led_dat->timer = pdata->timer;
led_dat->num_timer = pdata->num_timer;
/*
@@ -346,38 +352,269 @@ create_netxbig_led(struct platform_device *pdev,
return led_classdev_register(&pdev->dev, &led_dat->cdev);
}
+#ifdef CONFIG_OF_GPIO
+static int gpio_ext_get_of_pdata(struct device *dev, struct device_node *np,
+ struct netxbig_gpio_ext *gpio_ext)
+{
+ int *addr, *data;
+ int num_addr, num_data;
+ int ret;
+ int i;
+
+ ret = of_gpio_named_count(np, "addr-gpios");
+ if (ret < 0) {
+ dev_err(dev,
+ "Failed to count GPIOs in DT property addr-gpios\n");
+ return ret;
+ }
+ num_addr = ret;
+ addr = devm_kzalloc(dev, num_addr * sizeof(*addr), GFP_KERNEL);
+ if (!addr)
+ return -ENOMEM;
+
+ for (i = 0; i < num_addr; i++) {
+ ret = of_get_named_gpio(np, "addr-gpios", i);
+ if (ret < 0)
+ return ret;
+ addr[i] = ret;
+ }
+ gpio_ext->addr = addr;
+ gpio_ext->num_addr = num_addr;
+
+ ret = of_gpio_named_count(np, "data-gpios");
+ if (ret < 0) {
+ dev_err(dev,
+ "Failed to count GPIOs in DT property data-gpios\n");
+ return ret;
+ }
+ num_data = ret;
+ data = devm_kzalloc(dev, num_data * sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ for (i = 0; i < num_data; i++) {
+ ret = of_get_named_gpio(np, "data-gpios", i);
+ if (ret < 0)
+ return ret;
+ data[i] = ret;
+ }
+ gpio_ext->data = data;
+ gpio_ext->num_data = num_data;
+
+ ret = of_get_named_gpio(np, "enable-gpio", 0);
+ if (ret < 0) {
+ dev_err(dev,
+ "Failed to get GPIO from DT property enable-gpio\n");
+ return ret;
+ }
+ gpio_ext->enable = ret;
+
+ return 0;
+}
+
+static int netxbig_leds_get_of_pdata(struct device *dev,
+ struct netxbig_led_platform_data *pdata)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *gpio_ext_np;
+ struct device_node *child;
+ struct netxbig_gpio_ext *gpio_ext;
+ struct netxbig_led_timer *timers;
+ struct netxbig_led *leds, *led;
+ int num_timers;
+ int num_leds = 0;
+ int ret;
+ int i;
+
+ /* GPIO extension */
+ gpio_ext_np = of_parse_phandle(np, "gpio-ext", 0);
+ if (!gpio_ext_np) {
+ dev_err(dev, "Failed to get DT handle gpio-ext\n");
+ return -EINVAL;
+ }
+
+ gpio_ext = devm_kzalloc(dev, sizeof(*gpio_ext), GFP_KERNEL);
+ if (!gpio_ext)
+ return -ENOMEM;
+ ret = gpio_ext_get_of_pdata(dev, gpio_ext_np, gpio_ext);
+ if (ret)
+ return ret;
+ of_node_put(gpio_ext_np);
+ pdata->gpio_ext = gpio_ext;
+
+ /* Timers (optional) */
+ ret = of_property_count_u32_elems(np, "timers");
+ if (ret > 0) {
+ if (ret % 3)
+ return -EINVAL;
+ num_timers = ret / 3;
+ timers = devm_kzalloc(dev, num_timers * sizeof(*timers),
+ GFP_KERNEL);
+ if (!timers)
+ return -ENOMEM;
+ for (i = 0; i < num_timers; i++) {
+ u32 tmp;
+
+ of_property_read_u32_index(np, "timers", 3 * i,
+ &timers[i].mode);
+ if (timers[i].mode >= NETXBIG_LED_MODE_NUM)
+ return -EINVAL;
+ of_property_read_u32_index(np, "timers",
+ 3 * i + 1, &tmp);
+ timers[i].delay_on = tmp;
+ of_property_read_u32_index(np, "timers",
+ 3 * i + 2, &tmp);
+ timers[i].delay_off = tmp;
+ }
+ pdata->timer = timers;
+ pdata->num_timer = num_timers;
+ }
+
+ /* LEDs */
+ num_leds = of_get_child_count(np);
+ if (!num_leds) {
+ dev_err(dev, "No LED subnodes found in DT\n");
+ return -ENODEV;
+ }
+
+ leds = devm_kzalloc(dev, num_leds * sizeof(*leds), GFP_KERNEL);
+ if (!leds)
+ return -ENOMEM;
+
+ led = leds;
+ for_each_child_of_node(np, child) {
+ const char *string;
+ int *mode_val;
+ int num_modes;
+
+ ret = of_property_read_u32(child, "mode-addr",
+ &led->mode_addr);
+ if (ret)
+ goto err_node_put;
+
+ ret = of_property_read_u32(child, "bright-addr",
+ &led->bright_addr);
+ if (ret)
+ goto err_node_put;
+
+ ret = of_property_read_u32(child, "max-brightness",
+ &led->bright_max);
+ if (ret)
+ goto err_node_put;
+
+ mode_val =
+ devm_kzalloc(dev,
+ NETXBIG_LED_MODE_NUM * sizeof(*mode_val),
+ GFP_KERNEL);
+ if (!mode_val) {
+ ret = -ENOMEM;
+ goto err_node_put;
+ }
+
+ for (i = 0; i < NETXBIG_LED_MODE_NUM; i++)
+ mode_val[i] = NETXBIG_LED_INVALID_MODE;
+
+ ret = of_property_count_u32_elems(child, "mode-val");
+ if (ret < 0 || ret % 2) {
+ ret = -EINVAL;
+ goto err_node_put;
+ }
+ num_modes = ret / 2;
+ if (num_modes > NETXBIG_LED_MODE_NUM) {
+ ret = -EINVAL;
+ goto err_node_put;
+ }
+
+ for (i = 0; i < num_modes; i++) {
+ int mode;
+ int val;
+
+ of_property_read_u32_index(child,
+ "mode-val", 2 * i, &mode);
+ of_property_read_u32_index(child,
+ "mode-val", 2 * i + 1, &val);
+ if (mode >= NETXBIG_LED_MODE_NUM) {
+ ret = -EINVAL;
+ goto err_node_put;
+ }
+ mode_val[mode] = val;
+ }
+ led->mode_val = mode_val;
+
+ if (!of_property_read_string(child, "label", &string))
+ led->name = string;
+ else
+ led->name = child->name;
+
+ if (!of_property_read_string(child,
+ "linux,default-trigger", &string))
+ led->default_trigger = string;
+
+ led++;
+ }
+
+ pdata->leds = leds;
+ pdata->num_leds = num_leds;
+
+ return 0;
+
+err_node_put:
+ of_node_put(child);
+ return ret;
+}
+
+static const struct of_device_id of_netxbig_leds_match[] = {
+ { .compatible = "lacie,netxbig-leds", },
+ {},
+};
+#else
+static inline int
+netxbig_leds_get_of_pdata(struct device *dev,
+ struct netxbig_led_platform_data *pdata)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_OF_GPIO */
+
static int netxbig_led_probe(struct platform_device *pdev)
{
struct netxbig_led_platform_data *pdata = dev_get_platdata(&pdev->dev);
- struct netxbig_led_data *leds_data;
+ struct netxbig_led_priv *priv;
int i;
int ret;
- if (!pdata)
- return -EINVAL;
+ if (!pdata) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ ret = netxbig_leds_get_of_pdata(&pdev->dev, pdata);
+ if (ret)
+ return ret;
+ }
- leds_data = devm_kzalloc(&pdev->dev,
- sizeof(struct netxbig_led_data) * pdata->num_leds, GFP_KERNEL);
- if (!leds_data)
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv) +
+ pdata->num_leds * sizeof(struct netxbig_led_data),
+ GFP_KERNEL);
+ if (!priv)
return -ENOMEM;
+ priv->pdata = pdata;
ret = gpio_ext_init(pdata->gpio_ext);
if (ret < 0)
return ret;
for (i = 0; i < pdata->num_leds; i++) {
- ret = create_netxbig_led(pdev, &leds_data[i], &pdata->leds[i]);
+ ret = create_netxbig_led(pdev, i, priv);
if (ret < 0)
goto err_free_leds;
}
-
- platform_set_drvdata(pdev, leds_data);
+ platform_set_drvdata(pdev, priv);
return 0;
err_free_leds:
for (i = i - 1; i >= 0; i--)
- delete_netxbig_led(&leds_data[i]);
+ delete_netxbig_led(&priv->leds_data[i]);
gpio_ext_free(pdata->gpio_ext);
return ret;
@@ -385,14 +622,12 @@ err_free_leds:
static int netxbig_led_remove(struct platform_device *pdev)
{
- struct netxbig_led_platform_data *pdata = dev_get_platdata(&pdev->dev);
- struct netxbig_led_data *leds_data;
+ struct netxbig_led_priv *priv = platform_get_drvdata(pdev);
+ struct netxbig_led_platform_data *pdata = priv->pdata;
int i;
- leds_data = platform_get_drvdata(pdev);
-
for (i = 0; i < pdata->num_leds; i++)
- delete_netxbig_led(&leds_data[i]);
+ delete_netxbig_led(&priv->leds_data[i]);
gpio_ext_free(pdata->gpio_ext);
@@ -403,7 +638,8 @@ static struct platform_driver netxbig_led_driver = {
.probe = netxbig_led_probe,
.remove = netxbig_led_remove,
.driver = {
- .name = "leds-netxbig",
+ .name = "leds-netxbig",
+ .of_match_table = of_match_ptr(of_netxbig_leds_match),
},
};
diff --git a/include/dt-bindings/leds/leds-netxbig.h b/include/dt-bindings/leds/leds-netxbig.h
new file mode 100644
index 000000000000..92658b0310b2
--- /dev/null
+++ b/include/dt-bindings/leds/leds-netxbig.h
@@ -0,0 +1,18 @@
+/*
+ * This header provides constants for netxbig LED bindings.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _DT_BINDINGS_LEDS_NETXBIG_H
+#define _DT_BINDINGS_LEDS_NETXBIG_H
+
+#define NETXBIG_LED_OFF 0
+#define NETXBIG_LED_ON 1
+#define NETXBIG_LED_SATA 2
+#define NETXBIG_LED_TIMER1 3
+#define NETXBIG_LED_TIMER2 4
+
+#endif /* _DT_BINDINGS_LEDS_NETXBIG_H */
diff --git a/include/linux/platform_data/leds-kirkwood-netxbig.h b/include/linux/platform_data/leds-kirkwood-netxbig.h
index d2be19a51acd..3c85a735c380 100644
--- a/include/linux/platform_data/leds-kirkwood-netxbig.h
+++ b/include/linux/platform_data/leds-kirkwood-netxbig.h
@@ -40,6 +40,7 @@ struct netxbig_led {
int mode_addr;
int *mode_val;
int bright_addr;
+ int bright_max;
};
struct netxbig_led_platform_data {
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v6 2/5] ARM: Kirkwood: add LED DT entries for netxbig boards
2015-09-26 21:02 ` Simon Guinot
@ 2015-09-26 21:02 ` Simon Guinot
-1 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: Jacek Anaszewski, Bryan Wu, Richard Purdie
Cc: Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vincent Donnefort, Yoann Sculo,
Linus Walleij, Alexandre Courbot, Rob Herring, linux-leds,
linux-arm-kernel, devicetree
This patch adds DT entries for the LEDs found on the Kirkwood-based
LaCie boards 2Big and 5Big Network v2.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/kirkwood-net5big.dts | 60 +++++++++++++++++++++++++
arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++++++++++++++++++++++++++++++
2 files changed, 140 insertions(+)
Changes for v4:
- Add some Acked-by.
Changes for v5:
- Rename DT property "bright-max" into the more common "max-brightness".
diff --git a/arch/arm/boot/dts/kirkwood-net5big.dts b/arch/arm/boot/dts/kirkwood-net5big.dts
index 36155b749d9f..d2d44df9c8c0 100644
--- a/arch/arm/boot/dts/kirkwood-net5big.dts
+++ b/arch/arm/boot/dts/kirkwood-net5big.dts
@@ -86,6 +86,66 @@
clock-frequency = <32768>;
};
};
+
+ netxbig-leds {
+ blue-sata2 {
+ label = "netxbig:blue:sata2";
+ mode-addr = <5>;
+ 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-sata2 {
+ label = "netxbig:red:sata2";
+ mode-addr = <5>;
+ mode-val = <NETXBIG_LED_OFF 0
+ NETXBIG_LED_ON 2
+ NETXBIG_LED_TIMER1 4>;
+ bright-addr = <2>;
+ max-brightness = <7>;
+ };
+ blue-sata3 {
+ label = "netxbig:blue:sata3";
+ mode-addr = <6>;
+ 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-sata3 {
+ label = "netxbig:red:sata3";
+ mode-addr = <6>;
+ mode-val = <NETXBIG_LED_OFF 0
+ NETXBIG_LED_ON 2
+ NETXBIG_LED_TIMER1 4>;
+ bright-addr = <2>;
+ max-brightness = <7>;
+ };
+ blue-sata4 {
+ label = "netxbig:blue:sata4";
+ mode-addr = <7>;
+ 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-sata4 {
+ label = "netxbig:red:sata4";
+ mode-addr = <7>;
+ mode-val = <NETXBIG_LED_OFF 0
+ NETXBIG_LED_ON 2
+ NETXBIG_LED_TIMER1 4>;
+ bright-addr = <2>;
+ max-brightness = <7>;
+ };
+ };
};
&mdio {
diff --git a/arch/arm/boot/dts/kirkwood-netxbig.dtsi b/arch/arm/boot/dts/kirkwood-netxbig.dtsi
index 1508b12147df..62515a8b99b9 100644
--- a/arch/arm/boot/dts/kirkwood-netxbig.dtsi
+++ b/arch/arm/boot/dts/kirkwood-netxbig.dtsi
@@ -13,6 +13,7 @@
* warranty of any kind, whether express or implied.
*/
+#include <dt-bindings/leds/leds-netxbig.h>
#include "kirkwood.dtsi"
#include "kirkwood-6281.dtsi"
@@ -105,6 +106,85 @@
gpio = <&gpio0 16 GPIO_ACTIVE_HIGH>;
};
};
+
+ netxbig_gpio_ext: netxbig-gpio-ext {
+ compatible = "lacie,netxbig-gpio-ext";
+
+ addr-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH
+ &gpio1 16 GPIO_ACTIVE_HIGH
+ &gpio1 17 GPIO_ACTIVE_HIGH>;
+ data-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH
+ &gpio1 13 GPIO_ACTIVE_HIGH
+ &gpio1 14 GPIO_ACTIVE_HIGH>;
+ enable-gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>;
+ };
+
+ netxbig-leds {
+ compatible = "lacie,netxbig-leds";
+
+ gpio-ext = <&netxbig_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>;
+ };
+ };
};
&mdio {
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v6 2/5] ARM: Kirkwood: add LED DT entries for netxbig boards
@ 2015-09-26 21:02 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds DT entries for the LEDs found on the Kirkwood-based
LaCie boards 2Big and 5Big Network v2.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/kirkwood-net5big.dts | 60 +++++++++++++++++++++++++
arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++++++++++++++++++++++++++++++
2 files changed, 140 insertions(+)
Changes for v4:
- Add some Acked-by.
Changes for v5:
- Rename DT property "bright-max" into the more common "max-brightness".
diff --git a/arch/arm/boot/dts/kirkwood-net5big.dts b/arch/arm/boot/dts/kirkwood-net5big.dts
index 36155b749d9f..d2d44df9c8c0 100644
--- a/arch/arm/boot/dts/kirkwood-net5big.dts
+++ b/arch/arm/boot/dts/kirkwood-net5big.dts
@@ -86,6 +86,66 @@
clock-frequency = <32768>;
};
};
+
+ netxbig-leds {
+ blue-sata2 {
+ label = "netxbig:blue:sata2";
+ mode-addr = <5>;
+ 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-sata2 {
+ label = "netxbig:red:sata2";
+ mode-addr = <5>;
+ mode-val = <NETXBIG_LED_OFF 0
+ NETXBIG_LED_ON 2
+ NETXBIG_LED_TIMER1 4>;
+ bright-addr = <2>;
+ max-brightness = <7>;
+ };
+ blue-sata3 {
+ label = "netxbig:blue:sata3";
+ mode-addr = <6>;
+ 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-sata3 {
+ label = "netxbig:red:sata3";
+ mode-addr = <6>;
+ mode-val = <NETXBIG_LED_OFF 0
+ NETXBIG_LED_ON 2
+ NETXBIG_LED_TIMER1 4>;
+ bright-addr = <2>;
+ max-brightness = <7>;
+ };
+ blue-sata4 {
+ label = "netxbig:blue:sata4";
+ mode-addr = <7>;
+ 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-sata4 {
+ label = "netxbig:red:sata4";
+ mode-addr = <7>;
+ mode-val = <NETXBIG_LED_OFF 0
+ NETXBIG_LED_ON 2
+ NETXBIG_LED_TIMER1 4>;
+ bright-addr = <2>;
+ max-brightness = <7>;
+ };
+ };
};
&mdio {
diff --git a/arch/arm/boot/dts/kirkwood-netxbig.dtsi b/arch/arm/boot/dts/kirkwood-netxbig.dtsi
index 1508b12147df..62515a8b99b9 100644
--- a/arch/arm/boot/dts/kirkwood-netxbig.dtsi
+++ b/arch/arm/boot/dts/kirkwood-netxbig.dtsi
@@ -13,6 +13,7 @@
* warranty of any kind, whether express or implied.
*/
+#include <dt-bindings/leds/leds-netxbig.h>
#include "kirkwood.dtsi"
#include "kirkwood-6281.dtsi"
@@ -105,6 +106,85 @@
gpio = <&gpio0 16 GPIO_ACTIVE_HIGH>;
};
};
+
+ netxbig_gpio_ext: netxbig-gpio-ext {
+ compatible = "lacie,netxbig-gpio-ext";
+
+ addr-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH
+ &gpio1 16 GPIO_ACTIVE_HIGH
+ &gpio1 17 GPIO_ACTIVE_HIGH>;
+ data-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH
+ &gpio1 13 GPIO_ACTIVE_HIGH
+ &gpio1 14 GPIO_ACTIVE_HIGH>;
+ enable-gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>;
+ };
+
+ netxbig-leds {
+ compatible = "lacie,netxbig-leds";
+
+ gpio-ext = <&netxbig_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>;
+ };
+ };
};
&mdio {
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v6 3/5] ARM: mvebu: remove static LED setup for netxbig boards
2015-09-26 21:02 ` Simon Guinot
@ 2015-09-26 21:02 ` Simon Guinot
-1 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: Jacek Anaszewski, Bryan Wu, Richard Purdie
Cc: Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vincent Donnefort, Yoann Sculo,
Linus Walleij, Alexandre Courbot, Rob Herring, linux-leds,
linux-arm-kernel, devicetree
Since DT support is now available for the LEDs found on the LaCie
netxbig boards (Kirkwood-based), then the old-fashion netxbig board
setup file is no longer needed. This patch removes this file.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/Kconfig | 7 --
arch/arm/mach-mvebu/Makefile | 1 -
arch/arm/mach-mvebu/board.h | 21 -----
arch/arm/mach-mvebu/kirkwood.c | 4 -
arch/arm/mach-mvebu/netxbig.c | 191 -----------------------------------------
5 files changed, 224 deletions(-)
delete mode 100644 arch/arm/mach-mvebu/board.h
delete mode 100644 arch/arm/mach-mvebu/netxbig.c
Changes for v4:
- Add some Acked-by.
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index c86a5a0aefac..e20fc4178b15 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -117,11 +117,4 @@ config MACH_KIRKWOOD
Say 'Y' here if you want your kernel to support boards based
on the Marvell Kirkwood device tree.
-config MACH_NETXBIG
- bool "LaCie 2Big and 5Big Network v2"
- depends on MACH_KIRKWOOD
- help
- Say 'Y' here if you want your kernel to support the
- LaCie 2Big and 5Big Network v2
-
endif
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index b4f01497ce0b..ecf9e0c3b107 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -13,4 +13,3 @@ endif
obj-$(CONFIG_MACH_DOVE) += dove.o
obj-$(CONFIG_MACH_KIRKWOOD) += kirkwood.o kirkwood-pm.o
-obj-$(CONFIG_MACH_NETXBIG) += netxbig.o
diff --git a/arch/arm/mach-mvebu/board.h b/arch/arm/mach-mvebu/board.h
deleted file mode 100644
index 98e32cc2ef3d..000000000000
--- a/arch/arm/mach-mvebu/board.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Board functions for Marvell System On Chip
- *
- * Copyright (C) 2014
- *
- * Andrew Lunn <andrew@lunn.ch>
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#ifndef __ARCH_MVEBU_BOARD_H
-#define __ARCH_MVEBU_BOARD_H
-
-#ifdef CONFIG_MACH_NETXBIG
-void netxbig_init(void);
-#else
-static inline void netxbig_init(void) {};
-#endif
-#endif
diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
index 925f75f54268..f9d8e1ea7183 100644
--- a/arch/arm/mach-mvebu/kirkwood.c
+++ b/arch/arm/mach-mvebu/kirkwood.c
@@ -25,7 +25,6 @@
#include "kirkwood.h"
#include "kirkwood-pm.h"
#include "common.h"
-#include "board.h"
static struct resource kirkwood_cpufreq_resources[] = {
[0] = {
@@ -180,9 +179,6 @@ static void __init kirkwood_dt_init(void)
kirkwood_pm_init();
kirkwood_dt_eth_fixup();
- if (of_machine_is_compatible("lacie,netxbig"))
- netxbig_init();
-
of_platform_populate(NULL, of_default_bus_match_table, auxdata, NULL);
}
diff --git a/arch/arm/mach-mvebu/netxbig.c b/arch/arm/mach-mvebu/netxbig.c
deleted file mode 100644
index 94b11b6585a4..000000000000
--- a/arch/arm/mach-mvebu/netxbig.c
+++ /dev/null
@@ -1,191 +0,0 @@
-/*
- * arch/arm/mach-mvbu/board-netxbig.c
- *
- * LaCie 2Big and 5Big Network v2 board setup
- *
- * Copyright (C) 2010 Simon Guinot <sguinot@lacie.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/kernel.h>
-#include <linux/of.h>
-#include <linux/platform_device.h>
-#include <linux/platform_data/leds-kirkwood-netxbig.h>
-#include "common.h"
-
-/*****************************************************************************
- * GPIO extension LEDs
- ****************************************************************************/
-
-/*
- * The LEDs are controlled by a CPLD and can be configured through a GPIO
- * extension bus:
- *
- * - address register : bit [0-2] -> GPIO [47-49]
- * - data register : bit [0-2] -> GPIO [44-46]
- * - enable register : GPIO 29
- */
-
-static int netxbig_v2_gpio_ext_addr[] = { 47, 48, 49 };
-static int netxbig_v2_gpio_ext_data[] = { 44, 45, 46 };
-
-static struct netxbig_gpio_ext netxbig_v2_gpio_ext = {
- .addr = netxbig_v2_gpio_ext_addr,
- .num_addr = ARRAY_SIZE(netxbig_v2_gpio_ext_addr),
- .data = netxbig_v2_gpio_ext_data,
- .num_data = ARRAY_SIZE(netxbig_v2_gpio_ext_data),
- .enable = 29,
-};
-
-/*
- * Address register selection:
- *
- * addr | register
- * ----------------------------
- * 0 | front LED
- * 1 | front LED brightness
- * 2 | SATA LED brightness
- * 3 | SATA0 LED
- * 4 | SATA1 LED
- * 5 | SATA2 LED
- * 6 | SATA3 LED
- * 7 | SATA4 LED
- *
- * Data register configuration:
- *
- * data | LED brightness
- * -------------------------------------------------
- * 0 | min (off)
- * - | -
- * 7 | max
- *
- * data | front LED mode
- * -------------------------------------------------
- * 0 | fix off
- * 1 | fix blue on
- * 2 | fix red on
- * 3 | blink blue on=1 sec and blue off=1 sec
- * 4 | blink red on=1 sec and red off=1 sec
- * 5 | blink blue on=2.5 sec and red on=0.5 sec
- * 6 | blink blue on=1 sec and red on=1 sec
- * 7 | blink blue on=0.5 sec and blue off=2.5 sec
- *
- * data | SATA LED mode
- * -------------------------------------------------
- * 0 | fix off
- * 1 | SATA activity blink
- * 2 | fix red on
- * 3 | blink blue on=1 sec and blue off=1 sec
- * 4 | blink red on=1 sec and red off=1 sec
- * 5 | blink blue on=2.5 sec and red on=0.5 sec
- * 6 | blink blue on=1 sec and red on=1 sec
- * 7 | fix blue on
- */
-
-static int netxbig_v2_red_mled[NETXBIG_LED_MODE_NUM] = {
- [NETXBIG_LED_OFF] = 0,
- [NETXBIG_LED_ON] = 2,
- [NETXBIG_LED_SATA] = NETXBIG_LED_INVALID_MODE,
- [NETXBIG_LED_TIMER1] = 4,
- [NETXBIG_LED_TIMER2] = NETXBIG_LED_INVALID_MODE,
-};
-
-static int netxbig_v2_blue_pwr_mled[NETXBIG_LED_MODE_NUM] = {
- [NETXBIG_LED_OFF] = 0,
- [NETXBIG_LED_ON] = 1,
- [NETXBIG_LED_SATA] = NETXBIG_LED_INVALID_MODE,
- [NETXBIG_LED_TIMER1] = 3,
- [NETXBIG_LED_TIMER2] = 7,
-};
-
-static int netxbig_v2_blue_sata_mled[NETXBIG_LED_MODE_NUM] = {
- [NETXBIG_LED_OFF] = 0,
- [NETXBIG_LED_ON] = 7,
- [NETXBIG_LED_SATA] = 1,
- [NETXBIG_LED_TIMER1] = 3,
- [NETXBIG_LED_TIMER2] = NETXBIG_LED_INVALID_MODE,
-};
-
-static struct netxbig_led_timer netxbig_v2_led_timer[] = {
- [0] = {
- .delay_on = 500,
- .delay_off = 500,
- .mode = NETXBIG_LED_TIMER1,
- },
- [1] = {
- .delay_on = 500,
- .delay_off = 1000,
- .mode = NETXBIG_LED_TIMER2,
- },
-};
-
-#define NETXBIG_LED(_name, maddr, mval, baddr) \
- { .name = _name, \
- .mode_addr = maddr, \
- .mode_val = mval, \
- .bright_addr = baddr }
-
-static struct netxbig_led net2big_v2_leds_ctrl[] = {
- NETXBIG_LED("net2big-v2:blue:power", 0, netxbig_v2_blue_pwr_mled, 1),
- NETXBIG_LED("net2big-v2:red:power", 0, netxbig_v2_red_mled, 1),
- NETXBIG_LED("net2big-v2:blue:sata0", 3, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net2big-v2:red:sata0", 3, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net2big-v2:blue:sata1", 4, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net2big-v2:red:sata1", 4, netxbig_v2_red_mled, 2),
-};
-
-static struct netxbig_led_platform_data net2big_v2_leds_data = {
- .gpio_ext = &netxbig_v2_gpio_ext,
- .timer = netxbig_v2_led_timer,
- .num_timer = ARRAY_SIZE(netxbig_v2_led_timer),
- .leds = net2big_v2_leds_ctrl,
- .num_leds = ARRAY_SIZE(net2big_v2_leds_ctrl),
-};
-
-static struct netxbig_led net5big_v2_leds_ctrl[] = {
- NETXBIG_LED("net5big-v2:blue:power", 0, netxbig_v2_blue_pwr_mled, 1),
- NETXBIG_LED("net5big-v2:red:power", 0, netxbig_v2_red_mled, 1),
- NETXBIG_LED("net5big-v2:blue:sata0", 3, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata0", 3, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net5big-v2:blue:sata1", 4, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata1", 4, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net5big-v2:blue:sata2", 5, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata2", 5, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net5big-v2:blue:sata3", 6, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata3", 6, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net5big-v2:blue:sata4", 7, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata4", 7, netxbig_v2_red_mled, 2),
-};
-
-static struct netxbig_led_platform_data net5big_v2_leds_data = {
- .gpio_ext = &netxbig_v2_gpio_ext,
- .timer = netxbig_v2_led_timer,
- .num_timer = ARRAY_SIZE(netxbig_v2_led_timer),
- .leds = net5big_v2_leds_ctrl,
- .num_leds = ARRAY_SIZE(net5big_v2_leds_ctrl),
-};
-
-static struct platform_device netxbig_v2_leds = {
- .name = "leds-netxbig",
- .id = -1,
- .dev = {
- .platform_data = &net2big_v2_leds_data,
- },
-};
-
-void __init netxbig_init(void)
-{
-
- if (of_machine_is_compatible("lacie,net5big_v2"))
- netxbig_v2_leds.dev.platform_data = &net5big_v2_leds_data;
- platform_device_register(&netxbig_v2_leds);
-}
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v6 3/5] ARM: mvebu: remove static LED setup for netxbig boards
@ 2015-09-26 21:02 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: linux-arm-kernel
Since DT support is now available for the LEDs found on the LaCie
netxbig boards (Kirkwood-based), then the old-fashion netxbig board
setup file is no longer needed. This patch removes this file.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/Kconfig | 7 --
arch/arm/mach-mvebu/Makefile | 1 -
arch/arm/mach-mvebu/board.h | 21 -----
arch/arm/mach-mvebu/kirkwood.c | 4 -
arch/arm/mach-mvebu/netxbig.c | 191 -----------------------------------------
5 files changed, 224 deletions(-)
delete mode 100644 arch/arm/mach-mvebu/board.h
delete mode 100644 arch/arm/mach-mvebu/netxbig.c
Changes for v4:
- Add some Acked-by.
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index c86a5a0aefac..e20fc4178b15 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -117,11 +117,4 @@ config MACH_KIRKWOOD
Say 'Y' here if you want your kernel to support boards based
on the Marvell Kirkwood device tree.
-config MACH_NETXBIG
- bool "LaCie 2Big and 5Big Network v2"
- depends on MACH_KIRKWOOD
- help
- Say 'Y' here if you want your kernel to support the
- LaCie 2Big and 5Big Network v2
-
endif
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index b4f01497ce0b..ecf9e0c3b107 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -13,4 +13,3 @@ endif
obj-$(CONFIG_MACH_DOVE) += dove.o
obj-$(CONFIG_MACH_KIRKWOOD) += kirkwood.o kirkwood-pm.o
-obj-$(CONFIG_MACH_NETXBIG) += netxbig.o
diff --git a/arch/arm/mach-mvebu/board.h b/arch/arm/mach-mvebu/board.h
deleted file mode 100644
index 98e32cc2ef3d..000000000000
--- a/arch/arm/mach-mvebu/board.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Board functions for Marvell System On Chip
- *
- * Copyright (C) 2014
- *
- * Andrew Lunn <andrew@lunn.ch>
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#ifndef __ARCH_MVEBU_BOARD_H
-#define __ARCH_MVEBU_BOARD_H
-
-#ifdef CONFIG_MACH_NETXBIG
-void netxbig_init(void);
-#else
-static inline void netxbig_init(void) {};
-#endif
-#endif
diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
index 925f75f54268..f9d8e1ea7183 100644
--- a/arch/arm/mach-mvebu/kirkwood.c
+++ b/arch/arm/mach-mvebu/kirkwood.c
@@ -25,7 +25,6 @@
#include "kirkwood.h"
#include "kirkwood-pm.h"
#include "common.h"
-#include "board.h"
static struct resource kirkwood_cpufreq_resources[] = {
[0] = {
@@ -180,9 +179,6 @@ static void __init kirkwood_dt_init(void)
kirkwood_pm_init();
kirkwood_dt_eth_fixup();
- if (of_machine_is_compatible("lacie,netxbig"))
- netxbig_init();
-
of_platform_populate(NULL, of_default_bus_match_table, auxdata, NULL);
}
diff --git a/arch/arm/mach-mvebu/netxbig.c b/arch/arm/mach-mvebu/netxbig.c
deleted file mode 100644
index 94b11b6585a4..000000000000
--- a/arch/arm/mach-mvebu/netxbig.c
+++ /dev/null
@@ -1,191 +0,0 @@
-/*
- * arch/arm/mach-mvbu/board-netxbig.c
- *
- * LaCie 2Big and 5Big Network v2 board setup
- *
- * Copyright (C) 2010 Simon Guinot <sguinot@lacie.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/kernel.h>
-#include <linux/of.h>
-#include <linux/platform_device.h>
-#include <linux/platform_data/leds-kirkwood-netxbig.h>
-#include "common.h"
-
-/*****************************************************************************
- * GPIO extension LEDs
- ****************************************************************************/
-
-/*
- * The LEDs are controlled by a CPLD and can be configured through a GPIO
- * extension bus:
- *
- * - address register : bit [0-2] -> GPIO [47-49]
- * - data register : bit [0-2] -> GPIO [44-46]
- * - enable register : GPIO 29
- */
-
-static int netxbig_v2_gpio_ext_addr[] = { 47, 48, 49 };
-static int netxbig_v2_gpio_ext_data[] = { 44, 45, 46 };
-
-static struct netxbig_gpio_ext netxbig_v2_gpio_ext = {
- .addr = netxbig_v2_gpio_ext_addr,
- .num_addr = ARRAY_SIZE(netxbig_v2_gpio_ext_addr),
- .data = netxbig_v2_gpio_ext_data,
- .num_data = ARRAY_SIZE(netxbig_v2_gpio_ext_data),
- .enable = 29,
-};
-
-/*
- * Address register selection:
- *
- * addr | register
- * ----------------------------
- * 0 | front LED
- * 1 | front LED brightness
- * 2 | SATA LED brightness
- * 3 | SATA0 LED
- * 4 | SATA1 LED
- * 5 | SATA2 LED
- * 6 | SATA3 LED
- * 7 | SATA4 LED
- *
- * Data register configuration:
- *
- * data | LED brightness
- * -------------------------------------------------
- * 0 | min (off)
- * - | -
- * 7 | max
- *
- * data | front LED mode
- * -------------------------------------------------
- * 0 | fix off
- * 1 | fix blue on
- * 2 | fix red on
- * 3 | blink blue on=1 sec and blue off=1 sec
- * 4 | blink red on=1 sec and red off=1 sec
- * 5 | blink blue on=2.5 sec and red on=0.5 sec
- * 6 | blink blue on=1 sec and red on=1 sec
- * 7 | blink blue on=0.5 sec and blue off=2.5 sec
- *
- * data | SATA LED mode
- * -------------------------------------------------
- * 0 | fix off
- * 1 | SATA activity blink
- * 2 | fix red on
- * 3 | blink blue on=1 sec and blue off=1 sec
- * 4 | blink red on=1 sec and red off=1 sec
- * 5 | blink blue on=2.5 sec and red on=0.5 sec
- * 6 | blink blue on=1 sec and red on=1 sec
- * 7 | fix blue on
- */
-
-static int netxbig_v2_red_mled[NETXBIG_LED_MODE_NUM] = {
- [NETXBIG_LED_OFF] = 0,
- [NETXBIG_LED_ON] = 2,
- [NETXBIG_LED_SATA] = NETXBIG_LED_INVALID_MODE,
- [NETXBIG_LED_TIMER1] = 4,
- [NETXBIG_LED_TIMER2] = NETXBIG_LED_INVALID_MODE,
-};
-
-static int netxbig_v2_blue_pwr_mled[NETXBIG_LED_MODE_NUM] = {
- [NETXBIG_LED_OFF] = 0,
- [NETXBIG_LED_ON] = 1,
- [NETXBIG_LED_SATA] = NETXBIG_LED_INVALID_MODE,
- [NETXBIG_LED_TIMER1] = 3,
- [NETXBIG_LED_TIMER2] = 7,
-};
-
-static int netxbig_v2_blue_sata_mled[NETXBIG_LED_MODE_NUM] = {
- [NETXBIG_LED_OFF] = 0,
- [NETXBIG_LED_ON] = 7,
- [NETXBIG_LED_SATA] = 1,
- [NETXBIG_LED_TIMER1] = 3,
- [NETXBIG_LED_TIMER2] = NETXBIG_LED_INVALID_MODE,
-};
-
-static struct netxbig_led_timer netxbig_v2_led_timer[] = {
- [0] = {
- .delay_on = 500,
- .delay_off = 500,
- .mode = NETXBIG_LED_TIMER1,
- },
- [1] = {
- .delay_on = 500,
- .delay_off = 1000,
- .mode = NETXBIG_LED_TIMER2,
- },
-};
-
-#define NETXBIG_LED(_name, maddr, mval, baddr) \
- { .name = _name, \
- .mode_addr = maddr, \
- .mode_val = mval, \
- .bright_addr = baddr }
-
-static struct netxbig_led net2big_v2_leds_ctrl[] = {
- NETXBIG_LED("net2big-v2:blue:power", 0, netxbig_v2_blue_pwr_mled, 1),
- NETXBIG_LED("net2big-v2:red:power", 0, netxbig_v2_red_mled, 1),
- NETXBIG_LED("net2big-v2:blue:sata0", 3, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net2big-v2:red:sata0", 3, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net2big-v2:blue:sata1", 4, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net2big-v2:red:sata1", 4, netxbig_v2_red_mled, 2),
-};
-
-static struct netxbig_led_platform_data net2big_v2_leds_data = {
- .gpio_ext = &netxbig_v2_gpio_ext,
- .timer = netxbig_v2_led_timer,
- .num_timer = ARRAY_SIZE(netxbig_v2_led_timer),
- .leds = net2big_v2_leds_ctrl,
- .num_leds = ARRAY_SIZE(net2big_v2_leds_ctrl),
-};
-
-static struct netxbig_led net5big_v2_leds_ctrl[] = {
- NETXBIG_LED("net5big-v2:blue:power", 0, netxbig_v2_blue_pwr_mled, 1),
- NETXBIG_LED("net5big-v2:red:power", 0, netxbig_v2_red_mled, 1),
- NETXBIG_LED("net5big-v2:blue:sata0", 3, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata0", 3, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net5big-v2:blue:sata1", 4, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata1", 4, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net5big-v2:blue:sata2", 5, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata2", 5, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net5big-v2:blue:sata3", 6, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata3", 6, netxbig_v2_red_mled, 2),
- NETXBIG_LED("net5big-v2:blue:sata4", 7, netxbig_v2_blue_sata_mled, 2),
- NETXBIG_LED("net5big-v2:red:sata4", 7, netxbig_v2_red_mled, 2),
-};
-
-static struct netxbig_led_platform_data net5big_v2_leds_data = {
- .gpio_ext = &netxbig_v2_gpio_ext,
- .timer = netxbig_v2_led_timer,
- .num_timer = ARRAY_SIZE(netxbig_v2_led_timer),
- .leds = net5big_v2_leds_ctrl,
- .num_leds = ARRAY_SIZE(net5big_v2_leds_ctrl),
-};
-
-static struct platform_device netxbig_v2_leds = {
- .name = "leds-netxbig",
- .id = -1,
- .dev = {
- .platform_data = &net2big_v2_leds_data,
- },
-};
-
-void __init netxbig_init(void)
-{
-
- if (of_machine_is_compatible("lacie,net5big_v2"))
- netxbig_v2_leds.dev.platform_data = &net5big_v2_leds_data;
- platform_device_register(&netxbig_v2_leds);
-}
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v6 4/5] leds: netxbig: convert to use the devm_ functions
2015-09-26 21:02 ` Simon Guinot
@ 2015-09-26 21:02 ` Simon Guinot
-1 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: Jacek Anaszewski, Bryan Wu, Richard Purdie
Cc: Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vincent Donnefort, Yoann Sculo,
Linus Walleij, Alexandre Courbot, Rob Herring, linux-leds,
linux-arm-kernel, devicetree
This patch converts the leds-netxbig driver to use the devres functions
devm_gpio_request_one() and devm_led_classdev_register(). This allows to
simplify the code a bit.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
drivers/leds/leds-netxbig.c | 108 ++++++++++++--------------------------------
1 file changed, 28 insertions(+), 80 deletions(-)
diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
index e1f3c2632278..b166fd9f4186 100644
--- a/drivers/leds/leds-netxbig.c
+++ b/drivers/leds/leds-netxbig.c
@@ -71,7 +71,8 @@ static void gpio_ext_set_value(struct netxbig_gpio_ext *gpio_ext,
spin_unlock_irqrestore(&gpio_ext_lock, flags);
}
-static int gpio_ext_init(struct netxbig_gpio_ext *gpio_ext)
+static int gpio_ext_init(struct platform_device *pdev,
+ struct netxbig_gpio_ext *gpio_ext)
{
int err;
int i;
@@ -81,46 +82,28 @@ static int gpio_ext_init(struct netxbig_gpio_ext *gpio_ext)
/* Configure address GPIOs. */
for (i = 0; i < gpio_ext->num_addr; i++) {
- err = gpio_request_one(gpio_ext->addr[i], GPIOF_OUT_INIT_LOW,
- "GPIO extension addr");
+ err = devm_gpio_request_one(&pdev->dev, gpio_ext->addr[i],
+ GPIOF_OUT_INIT_LOW,
+ "GPIO extension addr");
if (err)
- goto err_free_addr;
+ return err;
}
/* Configure data GPIOs. */
for (i = 0; i < gpio_ext->num_data; i++) {
- err = gpio_request_one(gpio_ext->data[i], GPIOF_OUT_INIT_LOW,
- "GPIO extension data");
+ err = devm_gpio_request_one(&pdev->dev, gpio_ext->data[i],
+ GPIOF_OUT_INIT_LOW,
+ "GPIO extension data");
if (err)
- goto err_free_data;
+ return err;
}
/* Configure "enable select" GPIO. */
- err = gpio_request_one(gpio_ext->enable, GPIOF_OUT_INIT_LOW,
- "GPIO extension enable");
+ err = devm_gpio_request_one(&pdev->dev, gpio_ext->enable,
+ GPIOF_OUT_INIT_LOW,
+ "GPIO extension enable");
if (err)
- goto err_free_data;
+ return err;
return 0;
-
-err_free_data:
- for (i = i - 1; i >= 0; i--)
- gpio_free(gpio_ext->data[i]);
- i = gpio_ext->num_addr;
-err_free_addr:
- for (i = i - 1; i >= 0; i--)
- gpio_free(gpio_ext->addr[i]);
-
- return err;
-}
-
-static void gpio_ext_free(struct netxbig_gpio_ext *gpio_ext)
-{
- int i;
-
- gpio_free(gpio_ext->enable);
- for (i = gpio_ext->num_addr - 1; i >= 0; i--)
- gpio_free(gpio_ext->addr[i]);
- for (i = gpio_ext->num_data - 1; i >= 0; i--)
- gpio_free(gpio_ext->data[i]);
}
/*
@@ -141,11 +124,6 @@ struct netxbig_led_data {
spinlock_t lock;
};
-struct netxbig_led_priv {
- struct netxbig_led_platform_data *pdata;
- struct netxbig_led_data leds_data[];
-};
-
static int netxbig_led_get_timer_mode(enum netxbig_led_mode *mode,
unsigned long delay_on,
unsigned long delay_off,
@@ -305,18 +283,11 @@ static struct attribute *netxbig_led_attrs[] = {
};
ATTRIBUTE_GROUPS(netxbig_led);
-static void delete_netxbig_led(struct netxbig_led_data *led_dat)
-{
- led_classdev_unregister(&led_dat->cdev);
-}
-
-static int create_netxbig_led(struct platform_device *pdev, int led,
- struct netxbig_led_priv *priv)
+static int create_netxbig_led(struct platform_device *pdev,
+ struct netxbig_led_platform_data *pdata,
+ struct netxbig_led_data *led_dat,
+ const struct netxbig_led *template)
{
- struct netxbig_led_platform_data *pdata = priv->pdata;
- struct netxbig_led_data *led_dat = &priv->leds_data[led];
- const struct netxbig_led *template = &priv->pdata->leds[led];
-
spin_lock_init(&led_dat->lock);
led_dat->gpio_ext = pdata->gpio_ext;
led_dat->cdev.name = template->name;
@@ -349,7 +320,7 @@ static int create_netxbig_led(struct platform_device *pdev, int led,
if (led_dat->mode_val[NETXBIG_LED_SATA] != NETXBIG_LED_INVALID_MODE)
led_dat->cdev.groups = netxbig_led_groups;
- return led_classdev_register(&pdev->dev, &led_dat->cdev);
+ return devm_led_classdev_register(&pdev->dev, &led_dat->cdev);
}
#ifdef CONFIG_OF_GPIO
@@ -579,7 +550,7 @@ netxbig_leds_get_of_pdata(struct device *dev,
static int netxbig_led_probe(struct platform_device *pdev)
{
struct netxbig_led_platform_data *pdata = dev_get_platdata(&pdev->dev);
- struct netxbig_led_priv *priv;
+ struct netxbig_led_data *leds_data;
int i;
int ret;
@@ -592,51 +563,28 @@ static int netxbig_led_probe(struct platform_device *pdev)
return ret;
}
- priv = devm_kzalloc(&pdev->dev, sizeof(*priv) +
- pdata->num_leds * sizeof(struct netxbig_led_data),
- GFP_KERNEL);
- if (!priv)
+ leds_data = devm_kzalloc(&pdev->dev,
+ pdata->num_leds * sizeof(*leds_data),
+ GFP_KERNEL);
+ if (!leds_data)
return -ENOMEM;
- priv->pdata = pdata;
- ret = gpio_ext_init(pdata->gpio_ext);
+ ret = gpio_ext_init(pdev, pdata->gpio_ext);
if (ret < 0)
return ret;
for (i = 0; i < pdata->num_leds; i++) {
- ret = create_netxbig_led(pdev, i, priv);
+ ret = create_netxbig_led(pdev, pdata,
+ &leds_data[i], &pdata->leds[i]);
if (ret < 0)
- goto err_free_leds;
+ return ret;
}
- platform_set_drvdata(pdev, priv);
-
- return 0;
-
-err_free_leds:
- for (i = i - 1; i >= 0; i--)
- delete_netxbig_led(&priv->leds_data[i]);
-
- gpio_ext_free(pdata->gpio_ext);
- return ret;
-}
-
-static int netxbig_led_remove(struct platform_device *pdev)
-{
- struct netxbig_led_priv *priv = platform_get_drvdata(pdev);
- struct netxbig_led_platform_data *pdata = priv->pdata;
- int i;
-
- for (i = 0; i < pdata->num_leds; i++)
- delete_netxbig_led(&priv->leds_data[i]);
-
- gpio_ext_free(pdata->gpio_ext);
return 0;
}
static struct platform_driver netxbig_led_driver = {
.probe = netxbig_led_probe,
- .remove = netxbig_led_remove,
.driver = {
.name = "leds-netxbig",
.of_match_table = of_match_ptr(of_netxbig_leds_match),
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v6 4/5] leds: netxbig: convert to use the devm_ functions
@ 2015-09-26 21:02 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: linux-arm-kernel
This patch converts the leds-netxbig driver to use the devres functions
devm_gpio_request_one() and devm_led_classdev_register(). This allows to
simplify the code a bit.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
drivers/leds/leds-netxbig.c | 108 ++++++++++++--------------------------------
1 file changed, 28 insertions(+), 80 deletions(-)
diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
index e1f3c2632278..b166fd9f4186 100644
--- a/drivers/leds/leds-netxbig.c
+++ b/drivers/leds/leds-netxbig.c
@@ -71,7 +71,8 @@ static void gpio_ext_set_value(struct netxbig_gpio_ext *gpio_ext,
spin_unlock_irqrestore(&gpio_ext_lock, flags);
}
-static int gpio_ext_init(struct netxbig_gpio_ext *gpio_ext)
+static int gpio_ext_init(struct platform_device *pdev,
+ struct netxbig_gpio_ext *gpio_ext)
{
int err;
int i;
@@ -81,46 +82,28 @@ static int gpio_ext_init(struct netxbig_gpio_ext *gpio_ext)
/* Configure address GPIOs. */
for (i = 0; i < gpio_ext->num_addr; i++) {
- err = gpio_request_one(gpio_ext->addr[i], GPIOF_OUT_INIT_LOW,
- "GPIO extension addr");
+ err = devm_gpio_request_one(&pdev->dev, gpio_ext->addr[i],
+ GPIOF_OUT_INIT_LOW,
+ "GPIO extension addr");
if (err)
- goto err_free_addr;
+ return err;
}
/* Configure data GPIOs. */
for (i = 0; i < gpio_ext->num_data; i++) {
- err = gpio_request_one(gpio_ext->data[i], GPIOF_OUT_INIT_LOW,
- "GPIO extension data");
+ err = devm_gpio_request_one(&pdev->dev, gpio_ext->data[i],
+ GPIOF_OUT_INIT_LOW,
+ "GPIO extension data");
if (err)
- goto err_free_data;
+ return err;
}
/* Configure "enable select" GPIO. */
- err = gpio_request_one(gpio_ext->enable, GPIOF_OUT_INIT_LOW,
- "GPIO extension enable");
+ err = devm_gpio_request_one(&pdev->dev, gpio_ext->enable,
+ GPIOF_OUT_INIT_LOW,
+ "GPIO extension enable");
if (err)
- goto err_free_data;
+ return err;
return 0;
-
-err_free_data:
- for (i = i - 1; i >= 0; i--)
- gpio_free(gpio_ext->data[i]);
- i = gpio_ext->num_addr;
-err_free_addr:
- for (i = i - 1; i >= 0; i--)
- gpio_free(gpio_ext->addr[i]);
-
- return err;
-}
-
-static void gpio_ext_free(struct netxbig_gpio_ext *gpio_ext)
-{
- int i;
-
- gpio_free(gpio_ext->enable);
- for (i = gpio_ext->num_addr - 1; i >= 0; i--)
- gpio_free(gpio_ext->addr[i]);
- for (i = gpio_ext->num_data - 1; i >= 0; i--)
- gpio_free(gpio_ext->data[i]);
}
/*
@@ -141,11 +124,6 @@ struct netxbig_led_data {
spinlock_t lock;
};
-struct netxbig_led_priv {
- struct netxbig_led_platform_data *pdata;
- struct netxbig_led_data leds_data[];
-};
-
static int netxbig_led_get_timer_mode(enum netxbig_led_mode *mode,
unsigned long delay_on,
unsigned long delay_off,
@@ -305,18 +283,11 @@ static struct attribute *netxbig_led_attrs[] = {
};
ATTRIBUTE_GROUPS(netxbig_led);
-static void delete_netxbig_led(struct netxbig_led_data *led_dat)
-{
- led_classdev_unregister(&led_dat->cdev);
-}
-
-static int create_netxbig_led(struct platform_device *pdev, int led,
- struct netxbig_led_priv *priv)
+static int create_netxbig_led(struct platform_device *pdev,
+ struct netxbig_led_platform_data *pdata,
+ struct netxbig_led_data *led_dat,
+ const struct netxbig_led *template)
{
- struct netxbig_led_platform_data *pdata = priv->pdata;
- struct netxbig_led_data *led_dat = &priv->leds_data[led];
- const struct netxbig_led *template = &priv->pdata->leds[led];
-
spin_lock_init(&led_dat->lock);
led_dat->gpio_ext = pdata->gpio_ext;
led_dat->cdev.name = template->name;
@@ -349,7 +320,7 @@ static int create_netxbig_led(struct platform_device *pdev, int led,
if (led_dat->mode_val[NETXBIG_LED_SATA] != NETXBIG_LED_INVALID_MODE)
led_dat->cdev.groups = netxbig_led_groups;
- return led_classdev_register(&pdev->dev, &led_dat->cdev);
+ return devm_led_classdev_register(&pdev->dev, &led_dat->cdev);
}
#ifdef CONFIG_OF_GPIO
@@ -579,7 +550,7 @@ netxbig_leds_get_of_pdata(struct device *dev,
static int netxbig_led_probe(struct platform_device *pdev)
{
struct netxbig_led_platform_data *pdata = dev_get_platdata(&pdev->dev);
- struct netxbig_led_priv *priv;
+ struct netxbig_led_data *leds_data;
int i;
int ret;
@@ -592,51 +563,28 @@ static int netxbig_led_probe(struct platform_device *pdev)
return ret;
}
- priv = devm_kzalloc(&pdev->dev, sizeof(*priv) +
- pdata->num_leds * sizeof(struct netxbig_led_data),
- GFP_KERNEL);
- if (!priv)
+ leds_data = devm_kzalloc(&pdev->dev,
+ pdata->num_leds * sizeof(*leds_data),
+ GFP_KERNEL);
+ if (!leds_data)
return -ENOMEM;
- priv->pdata = pdata;
- ret = gpio_ext_init(pdata->gpio_ext);
+ ret = gpio_ext_init(pdev, pdata->gpio_ext);
if (ret < 0)
return ret;
for (i = 0; i < pdata->num_leds; i++) {
- ret = create_netxbig_led(pdev, i, priv);
+ ret = create_netxbig_led(pdev, pdata,
+ &leds_data[i], &pdata->leds[i]);
if (ret < 0)
- goto err_free_leds;
+ return ret;
}
- platform_set_drvdata(pdev, priv);
-
- return 0;
-
-err_free_leds:
- for (i = i - 1; i >= 0; i--)
- delete_netxbig_led(&priv->leds_data[i]);
-
- gpio_ext_free(pdata->gpio_ext);
- return ret;
-}
-
-static int netxbig_led_remove(struct platform_device *pdev)
-{
- struct netxbig_led_priv *priv = platform_get_drvdata(pdev);
- struct netxbig_led_platform_data *pdata = priv->pdata;
- int i;
-
- for (i = 0; i < pdata->num_leds; i++)
- delete_netxbig_led(&priv->leds_data[i]);
-
- gpio_ext_free(pdata->gpio_ext);
return 0;
}
static struct platform_driver netxbig_led_driver = {
.probe = netxbig_led_probe,
- .remove = netxbig_led_remove,
.driver = {
.name = "leds-netxbig",
.of_match_table = of_match_ptr(of_netxbig_leds_match),
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
2015-09-26 21:02 ` Simon Guinot
@ 2015-09-26 21:02 ` Simon Guinot
-1 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: Jacek Anaszewski, Bryan Wu, Richard Purdie
Cc: Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vincent Donnefort, Yoann Sculo,
Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
This patch sets the led_classdev max_brightness to the maximum level
value supported by hardware. This allows to get rid of the brightness
conversion operation (from software [0:LED_FULL] to hardware ranges) in
brightness_set().
Signed-off-by: Simon Guinot <simon.guinot-jKBdWWKqtFpg9hUCZPvPmw@public.gmane.org>
---
drivers/leds/leds-netxbig.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
index b166fd9f4186..4b88b93244be 100644
--- a/drivers/leds/leds-netxbig.c
+++ b/drivers/leds/leds-netxbig.c
@@ -116,7 +116,6 @@ struct netxbig_led_data {
int mode_addr;
int *mode_val;
int bright_addr;
- int bright_max;
struct netxbig_led_timer *timer;
int num_timer;
enum netxbig_led_mode mode;
@@ -178,7 +177,7 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
struct netxbig_led_data *led_dat =
container_of(led_cdev, struct netxbig_led_data, cdev);
enum netxbig_led_mode mode;
- int mode_val, bright_val;
+ int mode_val;
int set_brightness = 1;
unsigned long flags;
@@ -204,12 +203,9 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
* SATA LEDs. So, change the brightness setting for a single
* SATA LED will affect all the others.
*/
- if (set_brightness) {
- bright_val = DIV_ROUND_UP(value * led_dat->bright_max,
- LED_FULL);
+ if (set_brightness)
gpio_ext_set_value(led_dat->gpio_ext,
- led_dat->bright_addr, bright_val);
- }
+ led_dat->bright_addr, value);
spin_unlock_irqrestore(&led_dat->lock, flags);
}
@@ -306,11 +302,11 @@ static int create_netxbig_led(struct platform_device *pdev,
*/
led_dat->sata = 0;
led_dat->cdev.brightness = LED_OFF;
+ led_dat->cdev.max_brightness = template->bright_max;
led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
led_dat->mode_addr = template->mode_addr;
led_dat->mode_val = template->mode_val;
led_dat->bright_addr = template->bright_addr;
- led_dat->bright_max = template->bright_max;
led_dat->timer = pdata->timer;
led_dat->num_timer = pdata->num_timer;
/*
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
@ 2015-09-26 21:02 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-26 21:02 UTC (permalink / raw)
To: linux-arm-kernel
This patch sets the led_classdev max_brightness to the maximum level
value supported by hardware. This allows to get rid of the brightness
conversion operation (from software [0:LED_FULL] to hardware ranges) in
brightness_set().
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
drivers/leds/leds-netxbig.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
index b166fd9f4186..4b88b93244be 100644
--- a/drivers/leds/leds-netxbig.c
+++ b/drivers/leds/leds-netxbig.c
@@ -116,7 +116,6 @@ struct netxbig_led_data {
int mode_addr;
int *mode_val;
int bright_addr;
- int bright_max;
struct netxbig_led_timer *timer;
int num_timer;
enum netxbig_led_mode mode;
@@ -178,7 +177,7 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
struct netxbig_led_data *led_dat =
container_of(led_cdev, struct netxbig_led_data, cdev);
enum netxbig_led_mode mode;
- int mode_val, bright_val;
+ int mode_val;
int set_brightness = 1;
unsigned long flags;
@@ -204,12 +203,9 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
* SATA LEDs. So, change the brightness setting for a single
* SATA LED will affect all the others.
*/
- if (set_brightness) {
- bright_val = DIV_ROUND_UP(value * led_dat->bright_max,
- LED_FULL);
+ if (set_brightness)
gpio_ext_set_value(led_dat->gpio_ext,
- led_dat->bright_addr, bright_val);
- }
+ led_dat->bright_addr, value);
spin_unlock_irqrestore(&led_dat->lock, flags);
}
@@ -306,11 +302,11 @@ static int create_netxbig_led(struct platform_device *pdev,
*/
led_dat->sata = 0;
led_dat->cdev.brightness = LED_OFF;
+ led_dat->cdev.max_brightness = template->bright_max;
led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
led_dat->mode_addr = template->mode_addr;
led_dat->mode_val = template->mode_val;
led_dat->bright_addr = template->bright_addr;
- led_dat->bright_max = template->bright_max;
led_dat->timer = pdata->timer;
led_dat->num_timer = pdata->num_timer;
/*
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
2015-09-26 21:02 ` Simon Guinot
@ 2015-09-28 8:02 ` Jacek Anaszewski
-1 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-09-28 8:02 UTC (permalink / raw)
To: Simon Guinot
Cc: Bryan Wu, Richard Purdie, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds, linux-arm-kernel, devicetree
Hi Simon,
Does your device support reading the brightness currently set?
If so, it would be good to implement brightness_get op, because
AFAIR you mentioned that the firmware you are working with sets
always maximum brightness value. Having the op implemented would
allow to find this out.
On 09/26/2015 11:02 PM, Simon Guinot wrote:
> This patch sets the led_classdev max_brightness to the maximum level
> value supported by hardware. This allows to get rid of the brightness
> conversion operation (from software [0:LED_FULL] to hardware ranges) in
> brightness_set().
>
> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> ---
> drivers/leds/leds-netxbig.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
> index b166fd9f4186..4b88b93244be 100644
> --- a/drivers/leds/leds-netxbig.c
> +++ b/drivers/leds/leds-netxbig.c
> @@ -116,7 +116,6 @@ struct netxbig_led_data {
> int mode_addr;
> int *mode_val;
> int bright_addr;
> - int bright_max;
> struct netxbig_led_timer *timer;
> int num_timer;
> enum netxbig_led_mode mode;
> @@ -178,7 +177,7 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
> struct netxbig_led_data *led_dat =
> container_of(led_cdev, struct netxbig_led_data, cdev);
> enum netxbig_led_mode mode;
> - int mode_val, bright_val;
> + int mode_val;
> int set_brightness = 1;
> unsigned long flags;
>
> @@ -204,12 +203,9 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
> * SATA LEDs. So, change the brightness setting for a single
> * SATA LED will affect all the others.
> */
> - if (set_brightness) {
> - bright_val = DIV_ROUND_UP(value * led_dat->bright_max,
> - LED_FULL);
> + if (set_brightness)
> gpio_ext_set_value(led_dat->gpio_ext,
> - led_dat->bright_addr, bright_val);
> - }
> + led_dat->bright_addr, value);
>
> spin_unlock_irqrestore(&led_dat->lock, flags);
> }
> @@ -306,11 +302,11 @@ static int create_netxbig_led(struct platform_device *pdev,
> */
> led_dat->sata = 0;
> led_dat->cdev.brightness = LED_OFF;
> + led_dat->cdev.max_brightness = template->bright_max;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
> led_dat->mode_addr = template->mode_addr;
> led_dat->mode_val = template->mode_val;
> led_dat->bright_addr = template->bright_addr;
> - led_dat->bright_max = template->bright_max;
> led_dat->timer = pdata->timer;
> led_dat->num_timer = pdata->num_timer;
> /*
>
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
@ 2015-09-28 8:02 ` Jacek Anaszewski
0 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-09-28 8:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon,
Does your device support reading the brightness currently set?
If so, it would be good to implement brightness_get op, because
AFAIR you mentioned that the firmware you are working with sets
always maximum brightness value. Having the op implemented would
allow to find this out.
On 09/26/2015 11:02 PM, Simon Guinot wrote:
> This patch sets the led_classdev max_brightness to the maximum level
> value supported by hardware. This allows to get rid of the brightness
> conversion operation (from software [0:LED_FULL] to hardware ranges) in
> brightness_set().
>
> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> ---
> drivers/leds/leds-netxbig.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
> index b166fd9f4186..4b88b93244be 100644
> --- a/drivers/leds/leds-netxbig.c
> +++ b/drivers/leds/leds-netxbig.c
> @@ -116,7 +116,6 @@ struct netxbig_led_data {
> int mode_addr;
> int *mode_val;
> int bright_addr;
> - int bright_max;
> struct netxbig_led_timer *timer;
> int num_timer;
> enum netxbig_led_mode mode;
> @@ -178,7 +177,7 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
> struct netxbig_led_data *led_dat =
> container_of(led_cdev, struct netxbig_led_data, cdev);
> enum netxbig_led_mode mode;
> - int mode_val, bright_val;
> + int mode_val;
> int set_brightness = 1;
> unsigned long flags;
>
> @@ -204,12 +203,9 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
> * SATA LEDs. So, change the brightness setting for a single
> * SATA LED will affect all the others.
> */
> - if (set_brightness) {
> - bright_val = DIV_ROUND_UP(value * led_dat->bright_max,
> - LED_FULL);
> + if (set_brightness)
> gpio_ext_set_value(led_dat->gpio_ext,
> - led_dat->bright_addr, bright_val);
> - }
> + led_dat->bright_addr, value);
>
> spin_unlock_irqrestore(&led_dat->lock, flags);
> }
> @@ -306,11 +302,11 @@ static int create_netxbig_led(struct platform_device *pdev,
> */
> led_dat->sata = 0;
> led_dat->cdev.brightness = LED_OFF;
> + led_dat->cdev.max_brightness = template->bright_max;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
> led_dat->mode_addr = template->mode_addr;
> led_dat->mode_val = template->mode_val;
> led_dat->bright_addr = template->bright_addr;
> - led_dat->bright_max = template->bright_max;
> led_dat->timer = pdata->timer;
> led_dat->num_timer = pdata->num_timer;
> /*
>
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
2015-09-28 8:02 ` Jacek Anaszewski
@ 2015-09-28 9:19 ` Simon Guinot
-1 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-28 9:19 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Bryan Wu, Richard Purdie, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds, linux-arm-kernel, devicetree
[-- Attachment #1: Type: text/plain, Size: 3935 bytes --]
On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
> Hi Simon,
Hi Jacek,
>
> Does your device support reading the brightness currently set?
No it don't.
> If so, it would be good to implement brightness_get op, because
> AFAIR you mentioned that the firmware you are working with sets
> always maximum brightness value. Having the op implemented would
> allow to find this out.
I don't understand how this can help. I mean, the only issue is that at
startup the initial LED state is unknown. And the software brightness
value could be false. But once the LED is configured, the brightness
values for software and hardware are synchronized. The brightness value
is stored/cached in led_classdev and it can be retrieved by the user via
sysfs...
For my own knowledge, is there some interest in having brightness_get(),
aside of guessing the LED initial state ?
What does the embedded firmware is writing 255 or 0 into the brightness
sysfs attribute. The max_brightness value is ignored. After this patch,
writing 255 and 0 still allows to configure the LED in the same way:
maximum brightness or off. Thus, I believe there is no compatibility
issue.
But of course, I will update the firmware as well :)
Thanks,
Simon
>
> On 09/26/2015 11:02 PM, Simon Guinot wrote:
> >This patch sets the led_classdev max_brightness to the maximum level
> >value supported by hardware. This allows to get rid of the brightness
> >conversion operation (from software [0:LED_FULL] to hardware ranges) in
> >brightness_set().
> >
> >Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> >---
> > drivers/leds/leds-netxbig.c | 12 ++++--------
> > 1 file changed, 4 insertions(+), 8 deletions(-)
> >
> >diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
> >index b166fd9f4186..4b88b93244be 100644
> >--- a/drivers/leds/leds-netxbig.c
> >+++ b/drivers/leds/leds-netxbig.c
> >@@ -116,7 +116,6 @@ struct netxbig_led_data {
> > int mode_addr;
> > int *mode_val;
> > int bright_addr;
> >- int bright_max;
> > struct netxbig_led_timer *timer;
> > int num_timer;
> > enum netxbig_led_mode mode;
> >@@ -178,7 +177,7 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
> > struct netxbig_led_data *led_dat =
> > container_of(led_cdev, struct netxbig_led_data, cdev);
> > enum netxbig_led_mode mode;
> >- int mode_val, bright_val;
> >+ int mode_val;
> > int set_brightness = 1;
> > unsigned long flags;
> >
> >@@ -204,12 +203,9 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
> > * SATA LEDs. So, change the brightness setting for a single
> > * SATA LED will affect all the others.
> > */
> >- if (set_brightness) {
> >- bright_val = DIV_ROUND_UP(value * led_dat->bright_max,
> >- LED_FULL);
> >+ if (set_brightness)
> > gpio_ext_set_value(led_dat->gpio_ext,
> >- led_dat->bright_addr, bright_val);
> >- }
> >+ led_dat->bright_addr, value);
> >
> > spin_unlock_irqrestore(&led_dat->lock, flags);
> > }
> >@@ -306,11 +302,11 @@ static int create_netxbig_led(struct platform_device *pdev,
> > */
> > led_dat->sata = 0;
> > led_dat->cdev.brightness = LED_OFF;
> >+ led_dat->cdev.max_brightness = template->bright_max;
> > led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
> > led_dat->mode_addr = template->mode_addr;
> > led_dat->mode_val = template->mode_val;
> > led_dat->bright_addr = template->bright_addr;
> >- led_dat->bright_max = template->bright_max;
> > led_dat->timer = pdata->timer;
> > led_dat->num_timer = pdata->num_timer;
> > /*
> >
>
>
> --
> Best Regards,
> Jacek Anaszewski
> --
> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
@ 2015-09-28 9:19 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-28 9:19 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
> Hi Simon,
Hi Jacek,
>
> Does your device support reading the brightness currently set?
No it don't.
> If so, it would be good to implement brightness_get op, because
> AFAIR you mentioned that the firmware you are working with sets
> always maximum brightness value. Having the op implemented would
> allow to find this out.
I don't understand how this can help. I mean, the only issue is that at
startup the initial LED state is unknown. And the software brightness
value could be false. But once the LED is configured, the brightness
values for software and hardware are synchronized. The brightness value
is stored/cached in led_classdev and it can be retrieved by the user via
sysfs...
For my own knowledge, is there some interest in having brightness_get(),
aside of guessing the LED initial state ?
What does the embedded firmware is writing 255 or 0 into the brightness
sysfs attribute. The max_brightness value is ignored. After this patch,
writing 255 and 0 still allows to configure the LED in the same way:
maximum brightness or off. Thus, I believe there is no compatibility
issue.
But of course, I will update the firmware as well :)
Thanks,
Simon
>
> On 09/26/2015 11:02 PM, Simon Guinot wrote:
> >This patch sets the led_classdev max_brightness to the maximum level
> >value supported by hardware. This allows to get rid of the brightness
> >conversion operation (from software [0:LED_FULL] to hardware ranges) in
> >brightness_set().
> >
> >Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> >---
> > drivers/leds/leds-netxbig.c | 12 ++++--------
> > 1 file changed, 4 insertions(+), 8 deletions(-)
> >
> >diff --git a/drivers/leds/leds-netxbig.c b/drivers/leds/leds-netxbig.c
> >index b166fd9f4186..4b88b93244be 100644
> >--- a/drivers/leds/leds-netxbig.c
> >+++ b/drivers/leds/leds-netxbig.c
> >@@ -116,7 +116,6 @@ struct netxbig_led_data {
> > int mode_addr;
> > int *mode_val;
> > int bright_addr;
> >- int bright_max;
> > struct netxbig_led_timer *timer;
> > int num_timer;
> > enum netxbig_led_mode mode;
> >@@ -178,7 +177,7 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
> > struct netxbig_led_data *led_dat =
> > container_of(led_cdev, struct netxbig_led_data, cdev);
> > enum netxbig_led_mode mode;
> >- int mode_val, bright_val;
> >+ int mode_val;
> > int set_brightness = 1;
> > unsigned long flags;
> >
> >@@ -204,12 +203,9 @@ static void netxbig_led_set(struct led_classdev *led_cdev,
> > * SATA LEDs. So, change the brightness setting for a single
> > * SATA LED will affect all the others.
> > */
> >- if (set_brightness) {
> >- bright_val = DIV_ROUND_UP(value * led_dat->bright_max,
> >- LED_FULL);
> >+ if (set_brightness)
> > gpio_ext_set_value(led_dat->gpio_ext,
> >- led_dat->bright_addr, bright_val);
> >- }
> >+ led_dat->bright_addr, value);
> >
> > spin_unlock_irqrestore(&led_dat->lock, flags);
> > }
> >@@ -306,11 +302,11 @@ static int create_netxbig_led(struct platform_device *pdev,
> > */
> > led_dat->sata = 0;
> > led_dat->cdev.brightness = LED_OFF;
> >+ led_dat->cdev.max_brightness = template->bright_max;
> > led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
> > led_dat->mode_addr = template->mode_addr;
> > led_dat->mode_val = template->mode_val;
> > led_dat->bright_addr = template->bright_addr;
> >- led_dat->bright_max = template->bright_max;
> > led_dat->timer = pdata->timer;
> > led_dat->num_timer = pdata->num_timer;
> > /*
> >
>
>
> --
> Best Regards,
> Jacek Anaszewski
> --
> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150928/58676f37/attachment-0001.sig>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
2015-09-28 9:19 ` Simon Guinot
@ 2015-09-28 10:15 ` Jacek Anaszewski
-1 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-09-28 10:15 UTC (permalink / raw)
To: Simon Guinot
Cc: Bryan Wu, Richard Purdie, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds, linux-arm-kernel, devicetree
On 09/28/2015 11:19 AM, Simon Guinot wrote:
> On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
>> Hi Simon,
>
> Hi Jacek,
>
>>
>> Does your device support reading the brightness currently set?
>
> No it don't.
>
>> If so, it would be good to implement brightness_get op, because
>> AFAIR you mentioned that the firmware you are working with sets
>> always maximum brightness value. Having the op implemented would
>> allow to find this out.
>
> I don't understand how this can help. I mean, the only issue is that at
> startup the initial LED state is unknown. And the software brightness
> value could be false. But once the LED is configured, the brightness
> values for software and hardware are synchronized. The brightness value
> is stored/cached in led_classdev and it can be retrieved by the user via
> sysfs...
>
> For my own knowledge, is there some interest in having brightness_get(),
> aside of guessing the LED initial state ?
Some LED controllers can adjust brightness in case battery voltage level
falls below some threshold.
> What does the embedded firmware is writing 255 or 0 into the brightness
> sysfs attribute. The max_brightness value is ignored. After this patch,
> writing 255 and 0 still allows to configure the LED in the same way:
> maximum brightness or off. Thus, I believe there is no compatibility
> issue.
LED core always assures that brightness value passed to brightness_set
op does not exceed max_brightness value. So, now after executing
"echo 255 > brightness", LED core will adjust it to max_brightness
(e.g. 7) before passing to brightness_set.
In the message [1], you mentioned that "LEDs are only enabled at their
maximum level", so IIUC following is possible:
#echo 3 > "brightness"
firmware sets brightness to max_brightness from DT (e.g. 7), but
#cat brightness
#3
Is it true?
> But of course, I will update the firmware as well :)
[1] http://www.spinics.net/lists/devicetree/msg94358.html
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
@ 2015-09-28 10:15 ` Jacek Anaszewski
0 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-09-28 10:15 UTC (permalink / raw)
To: linux-arm-kernel
On 09/28/2015 11:19 AM, Simon Guinot wrote:
> On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
>> Hi Simon,
>
> Hi Jacek,
>
>>
>> Does your device support reading the brightness currently set?
>
> No it don't.
>
>> If so, it would be good to implement brightness_get op, because
>> AFAIR you mentioned that the firmware you are working with sets
>> always maximum brightness value. Having the op implemented would
>> allow to find this out.
>
> I don't understand how this can help. I mean, the only issue is that at
> startup the initial LED state is unknown. And the software brightness
> value could be false. But once the LED is configured, the brightness
> values for software and hardware are synchronized. The brightness value
> is stored/cached in led_classdev and it can be retrieved by the user via
> sysfs...
>
> For my own knowledge, is there some interest in having brightness_get(),
> aside of guessing the LED initial state ?
Some LED controllers can adjust brightness in case battery voltage level
falls below some threshold.
> What does the embedded firmware is writing 255 or 0 into the brightness
> sysfs attribute. The max_brightness value is ignored. After this patch,
> writing 255 and 0 still allows to configure the LED in the same way:
> maximum brightness or off. Thus, I believe there is no compatibility
> issue.
LED core always assures that brightness value passed to brightness_set
op does not exceed max_brightness value. So, now after executing
"echo 255 > brightness", LED core will adjust it to max_brightness
(e.g. 7) before passing to brightness_set.
In the message [1], you mentioned that "LEDs are only enabled at their
maximum level", so IIUC following is possible:
#echo 3 > "brightness"
firmware sets brightness to max_brightness from DT (e.g. 7), but
#cat brightness
#3
Is it true?
> But of course, I will update the firmware as well :)
[1] http://www.spinics.net/lists/devicetree/msg94358.html
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
2015-09-28 10:15 ` Jacek Anaszewski
@ 2015-09-28 11:50 ` Simon Guinot
-1 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-28 11:50 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Bryan Wu, Richard Purdie, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]
On Mon, Sep 28, 2015 at 12:15:22PM +0200, Jacek Anaszewski wrote:
> On 09/28/2015 11:19 AM, Simon Guinot wrote:
> >On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
> >>Hi Simon,
> >
> >Hi Jacek,
> >
> >>
> >>Does your device support reading the brightness currently set?
> >
> >No it don't.
> >
> >>If so, it would be good to implement brightness_get op, because
> >>AFAIR you mentioned that the firmware you are working with sets
> >>always maximum brightness value. Having the op implemented would
> >>allow to find this out.
> >
> >I don't understand how this can help. I mean, the only issue is that at
> >startup the initial LED state is unknown. And the software brightness
> >value could be false. But once the LED is configured, the brightness
> >values for software and hardware are synchronized. The brightness value
> >is stored/cached in led_classdev and it can be retrieved by the user via
> >sysfs...
> >
> >For my own knowledge, is there some interest in having brightness_get(),
> >aside of guessing the LED initial state ?
>
> Some LED controllers can adjust brightness in case battery voltage level
> falls below some threshold.
OK, thanks for the explanation.
>
> >What does the embedded firmware is writing 255 or 0 into the brightness
> >sysfs attribute. The max_brightness value is ignored. After this patch,
> >writing 255 and 0 still allows to configure the LED in the same way:
> >maximum brightness or off. Thus, I believe there is no compatibility
> >issue.
>
> LED core always assures that brightness value passed to brightness_set
> op does not exceed max_brightness value. So, now after executing
> "echo 255 > brightness", LED core will adjust it to max_brightness
> (e.g. 7) before passing to brightness_set.
>
> In the message [1], you mentioned that "LEDs are only enabled at their
> maximum level", so IIUC following is possible:
>
> #echo 3 > "brightness"
>
> firmware sets brightness to max_brightness from DT (e.g. 7), but
>
> #cat brightness
> #3
>
> Is it true?
Oh no sorry, it is a misunderstanding. By "LEDs are only enabled at
their maximum level", I was meaning "LEDs are only enabled at their
maximum level by the LaCie stock firmware". The firmware don't make
use of the different hardware brightness levels available. But the
feature works perfectly. If you write 3 into sysfs "brightness", then
you get the third brightness level.
OK, I understand you remark now. Sorry for not being very clear in a
first place.
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
@ 2015-09-28 11:50 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-28 11:50 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 28, 2015 at 12:15:22PM +0200, Jacek Anaszewski wrote:
> On 09/28/2015 11:19 AM, Simon Guinot wrote:
> >On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
> >>Hi Simon,
> >
> >Hi Jacek,
> >
> >>
> >>Does your device support reading the brightness currently set?
> >
> >No it don't.
> >
> >>If so, it would be good to implement brightness_get op, because
> >>AFAIR you mentioned that the firmware you are working with sets
> >>always maximum brightness value. Having the op implemented would
> >>allow to find this out.
> >
> >I don't understand how this can help. I mean, the only issue is that at
> >startup the initial LED state is unknown. And the software brightness
> >value could be false. But once the LED is configured, the brightness
> >values for software and hardware are synchronized. The brightness value
> >is stored/cached in led_classdev and it can be retrieved by the user via
> >sysfs...
> >
> >For my own knowledge, is there some interest in having brightness_get(),
> >aside of guessing the LED initial state ?
>
> Some LED controllers can adjust brightness in case battery voltage level
> falls below some threshold.
OK, thanks for the explanation.
>
> >What does the embedded firmware is writing 255 or 0 into the brightness
> >sysfs attribute. The max_brightness value is ignored. After this patch,
> >writing 255 and 0 still allows to configure the LED in the same way:
> >maximum brightness or off. Thus, I believe there is no compatibility
> >issue.
>
> LED core always assures that brightness value passed to brightness_set
> op does not exceed max_brightness value. So, now after executing
> "echo 255 > brightness", LED core will adjust it to max_brightness
> (e.g. 7) before passing to brightness_set.
>
> In the message [1], you mentioned that "LEDs are only enabled at their
> maximum level", so IIUC following is possible:
>
> #echo 3 > "brightness"
>
> firmware sets brightness to max_brightness from DT (e.g. 7), but
>
> #cat brightness
> #3
>
> Is it true?
Oh no sorry, it is a misunderstanding. By "LEDs are only enabled at
their maximum level", I was meaning "LEDs are only enabled at their
maximum level by the LaCie stock firmware". The firmware don't make
use of the different hardware brightness levels available. But the
feature works perfectly. If you write 3 into sysfs "brightness", then
you get the third brightness level.
OK, I understand you remark now. Sorry for not being very clear in a
first place.
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150928/fb5c942d/attachment.sig>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
2015-09-28 11:50 ` Simon Guinot
@ 2015-09-28 12:24 ` Jacek Anaszewski
-1 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-09-28 12:24 UTC (permalink / raw)
To: Simon Guinot
Cc: Bryan Wu, Richard Purdie, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds, linux-arm-kernel, devicetree
On 09/28/2015 01:50 PM, Simon Guinot wrote:
> On Mon, Sep 28, 2015 at 12:15:22PM +0200, Jacek Anaszewski wrote:
>> On 09/28/2015 11:19 AM, Simon Guinot wrote:
>>> On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
>>>> Hi Simon,
>>>
>>> Hi Jacek,
>>>
>>>>
>>>> Does your device support reading the brightness currently set?
>>>
>>> No it don't.
>>>
>>>> If so, it would be good to implement brightness_get op, because
>>>> AFAIR you mentioned that the firmware you are working with sets
>>>> always maximum brightness value. Having the op implemented would
>>>> allow to find this out.
>>>
>>> I don't understand how this can help. I mean, the only issue is that at
>>> startup the initial LED state is unknown. And the software brightness
>>> value could be false. But once the LED is configured, the brightness
>>> values for software and hardware are synchronized. The brightness value
>>> is stored/cached in led_classdev and it can be retrieved by the user via
>>> sysfs...
>>>
>>> For my own knowledge, is there some interest in having brightness_get(),
>>> aside of guessing the LED initial state ?
>>
>> Some LED controllers can adjust brightness in case battery voltage level
>> falls below some threshold.
>
> OK, thanks for the explanation.
>
>>
>>> What does the embedded firmware is writing 255 or 0 into the brightness
>>> sysfs attribute. The max_brightness value is ignored. After this patch,
>>> writing 255 and 0 still allows to configure the LED in the same way:
>>> maximum brightness or off. Thus, I believe there is no compatibility
>>> issue.
>>
>> LED core always assures that brightness value passed to brightness_set
>> op does not exceed max_brightness value. So, now after executing
>> "echo 255 > brightness", LED core will adjust it to max_brightness
>> (e.g. 7) before passing to brightness_set.
>>
>> In the message [1], you mentioned that "LEDs are only enabled at their
>> maximum level", so IIUC following is possible:
>>
>> #echo 3 > "brightness"
>>
>> firmware sets brightness to max_brightness from DT (e.g. 7), but
>>
>> #cat brightness
>> #3
>>
>> Is it true?
>
> Oh no sorry, it is a misunderstanding. By "LEDs are only enabled at
> their maximum level", I was meaning "LEDs are only enabled at their
> maximum level by the LaCie stock firmware". The firmware don't make
> use of the different hardware brightness levels available. But the
> feature works perfectly. If you write 3 into sysfs "brightness", then
> you get the third brightness level.
I thought that driver talks to firmware, which controls the LEDs.
From your explanation I infer that this driver replaces LaCie stock
firmware, am I right? There must be however some circuit that controls
LED brightness then.
> OK, I understand you remark now. Sorry for not being very clear in a
> first place.
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
@ 2015-09-28 12:24 ` Jacek Anaszewski
0 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-09-28 12:24 UTC (permalink / raw)
To: linux-arm-kernel
On 09/28/2015 01:50 PM, Simon Guinot wrote:
> On Mon, Sep 28, 2015 at 12:15:22PM +0200, Jacek Anaszewski wrote:
>> On 09/28/2015 11:19 AM, Simon Guinot wrote:
>>> On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
>>>> Hi Simon,
>>>
>>> Hi Jacek,
>>>
>>>>
>>>> Does your device support reading the brightness currently set?
>>>
>>> No it don't.
>>>
>>>> If so, it would be good to implement brightness_get op, because
>>>> AFAIR you mentioned that the firmware you are working with sets
>>>> always maximum brightness value. Having the op implemented would
>>>> allow to find this out.
>>>
>>> I don't understand how this can help. I mean, the only issue is that at
>>> startup the initial LED state is unknown. And the software brightness
>>> value could be false. But once the LED is configured, the brightness
>>> values for software and hardware are synchronized. The brightness value
>>> is stored/cached in led_classdev and it can be retrieved by the user via
>>> sysfs...
>>>
>>> For my own knowledge, is there some interest in having brightness_get(),
>>> aside of guessing the LED initial state ?
>>
>> Some LED controllers can adjust brightness in case battery voltage level
>> falls below some threshold.
>
> OK, thanks for the explanation.
>
>>
>>> What does the embedded firmware is writing 255 or 0 into the brightness
>>> sysfs attribute. The max_brightness value is ignored. After this patch,
>>> writing 255 and 0 still allows to configure the LED in the same way:
>>> maximum brightness or off. Thus, I believe there is no compatibility
>>> issue.
>>
>> LED core always assures that brightness value passed to brightness_set
>> op does not exceed max_brightness value. So, now after executing
>> "echo 255 > brightness", LED core will adjust it to max_brightness
>> (e.g. 7) before passing to brightness_set.
>>
>> In the message [1], you mentioned that "LEDs are only enabled at their
>> maximum level", so IIUC following is possible:
>>
>> #echo 3 > "brightness"
>>
>> firmware sets brightness to max_brightness from DT (e.g. 7), but
>>
>> #cat brightness
>> #3
>>
>> Is it true?
>
> Oh no sorry, it is a misunderstanding. By "LEDs are only enabled at
> their maximum level", I was meaning "LEDs are only enabled at their
> maximum level by the LaCie stock firmware". The firmware don't make
> use of the different hardware brightness levels available. But the
> feature works perfectly. If you write 3 into sysfs "brightness", then
> you get the third brightness level.
I thought that driver talks to firmware, which controls the LEDs.
From your explanation I infer that this driver replaces LaCie stock
firmware, am I right? There must be however some circuit that controls
LED brightness then.
> OK, I understand you remark now. Sorry for not being very clear in a
> first place.
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
2015-09-28 12:24 ` Jacek Anaszewski
@ 2015-09-28 13:25 ` Simon Guinot
-1 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-28 13:25 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Bryan Wu, Richard Purdie, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds, linux-arm-kernel, devicetree
[-- Attachment #1: Type: text/plain, Size: 4279 bytes --]
On Mon, Sep 28, 2015 at 02:24:40PM +0200, Jacek Anaszewski wrote:
> On 09/28/2015 01:50 PM, Simon Guinot wrote:
> >On Mon, Sep 28, 2015 at 12:15:22PM +0200, Jacek Anaszewski wrote:
> >>On 09/28/2015 11:19 AM, Simon Guinot wrote:
> >>>On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
> >>>>Hi Simon,
> >>>
> >>>Hi Jacek,
> >>>
> >>>>
> >>>>Does your device support reading the brightness currently set?
> >>>
> >>>No it don't.
> >>>
> >>>>If so, it would be good to implement brightness_get op, because
> >>>>AFAIR you mentioned that the firmware you are working with sets
> >>>>always maximum brightness value. Having the op implemented would
> >>>>allow to find this out.
> >>>
> >>>I don't understand how this can help. I mean, the only issue is that at
> >>>startup the initial LED state is unknown. And the software brightness
> >>>value could be false. But once the LED is configured, the brightness
> >>>values for software and hardware are synchronized. The brightness value
> >>>is stored/cached in led_classdev and it can be retrieved by the user via
> >>>sysfs...
> >>>
> >>>For my own knowledge, is there some interest in having brightness_get(),
> >>>aside of guessing the LED initial state ?
> >>
> >>Some LED controllers can adjust brightness in case battery voltage level
> >>falls below some threshold.
> >
> >OK, thanks for the explanation.
> >
> >>
> >>>What does the embedded firmware is writing 255 or 0 into the brightness
> >>>sysfs attribute. The max_brightness value is ignored. After this patch,
> >>>writing 255 and 0 still allows to configure the LED in the same way:
> >>>maximum brightness or off. Thus, I believe there is no compatibility
> >>>issue.
> >>
> >>LED core always assures that brightness value passed to brightness_set
> >>op does not exceed max_brightness value. So, now after executing
> >>"echo 255 > brightness", LED core will adjust it to max_brightness
> >>(e.g. 7) before passing to brightness_set.
> >>
> >>In the message [1], you mentioned that "LEDs are only enabled at their
> >>maximum level", so IIUC following is possible:
> >>
> >>#echo 3 > "brightness"
> >>
> >>firmware sets brightness to max_brightness from DT (e.g. 7), but
> >>
> >>#cat brightness
> >>#3
> >>
> >>Is it true?
> >
> >Oh no sorry, it is a misunderstanding. By "LEDs are only enabled at
> >their maximum level", I was meaning "LEDs are only enabled at their
> >maximum level by the LaCie stock firmware". The firmware don't make
> >use of the different hardware brightness levels available. But the
> >feature works perfectly. If you write 3 into sysfs "brightness", then
> >you get the third brightness level.
>
> I thought that driver talks to firmware, which controls the LEDs.
> From your explanation I infer that this driver replaces LaCie stock
> firmware, am I right? There must be however some circuit that controls
> LED brightness then.
OK, I think I may have managed to confuse you completely.
The LEDs are controlled by a CPLD. The leds-netxbig driver talks to the
CPLD via the gpio-ext "kind of" bus:
leds-netxbig -> gpio-ext bus -> CPLD -> LEDs
"LaCie stock firmware" don't refer to the firmware embedded in the CPLD
but to the stock LaCie Linux system running *on* the board.
"LEDs are only enabled at their maximum level by the LaCie stock
firmware" means: "In the Linux LaCie system running on the board,
userland only configures the LED brightness to 0 or 255".
It don't mean that the CPLD does some weird stuff implying that the
feature is somewhat broken. No, the feature works. Simply userland
(in the stock LaCie system aka firmware) don't use it.
Remember that your original question was:
"Doesn't specification of your device say what current value given
brightness level reflects?"
Let me rephrase my answer without using "LaCie stock firmware":
No this information is not available in the board specification. It is
probably because this feature is not used by the LaCie Linux userland.
The LED brightness is configured to off or full. Other levels are not
used. That's probably why no one took care of measuring the LED current
consumption.
Let me know if it is still unclear for you.
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
@ 2015-09-28 13:25 ` Simon Guinot
0 siblings, 0 replies; 32+ messages in thread
From: Simon Guinot @ 2015-09-28 13:25 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 28, 2015 at 02:24:40PM +0200, Jacek Anaszewski wrote:
> On 09/28/2015 01:50 PM, Simon Guinot wrote:
> >On Mon, Sep 28, 2015 at 12:15:22PM +0200, Jacek Anaszewski wrote:
> >>On 09/28/2015 11:19 AM, Simon Guinot wrote:
> >>>On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
> >>>>Hi Simon,
> >>>
> >>>Hi Jacek,
> >>>
> >>>>
> >>>>Does your device support reading the brightness currently set?
> >>>
> >>>No it don't.
> >>>
> >>>>If so, it would be good to implement brightness_get op, because
> >>>>AFAIR you mentioned that the firmware you are working with sets
> >>>>always maximum brightness value. Having the op implemented would
> >>>>allow to find this out.
> >>>
> >>>I don't understand how this can help. I mean, the only issue is that at
> >>>startup the initial LED state is unknown. And the software brightness
> >>>value could be false. But once the LED is configured, the brightness
> >>>values for software and hardware are synchronized. The brightness value
> >>>is stored/cached in led_classdev and it can be retrieved by the user via
> >>>sysfs...
> >>>
> >>>For my own knowledge, is there some interest in having brightness_get(),
> >>>aside of guessing the LED initial state ?
> >>
> >>Some LED controllers can adjust brightness in case battery voltage level
> >>falls below some threshold.
> >
> >OK, thanks for the explanation.
> >
> >>
> >>>What does the embedded firmware is writing 255 or 0 into the brightness
> >>>sysfs attribute. The max_brightness value is ignored. After this patch,
> >>>writing 255 and 0 still allows to configure the LED in the same way:
> >>>maximum brightness or off. Thus, I believe there is no compatibility
> >>>issue.
> >>
> >>LED core always assures that brightness value passed to brightness_set
> >>op does not exceed max_brightness value. So, now after executing
> >>"echo 255 > brightness", LED core will adjust it to max_brightness
> >>(e.g. 7) before passing to brightness_set.
> >>
> >>In the message [1], you mentioned that "LEDs are only enabled at their
> >>maximum level", so IIUC following is possible:
> >>
> >>#echo 3 > "brightness"
> >>
> >>firmware sets brightness to max_brightness from DT (e.g. 7), but
> >>
> >>#cat brightness
> >>#3
> >>
> >>Is it true?
> >
> >Oh no sorry, it is a misunderstanding. By "LEDs are only enabled at
> >their maximum level", I was meaning "LEDs are only enabled at their
> >maximum level by the LaCie stock firmware". The firmware don't make
> >use of the different hardware brightness levels available. But the
> >feature works perfectly. If you write 3 into sysfs "brightness", then
> >you get the third brightness level.
>
> I thought that driver talks to firmware, which controls the LEDs.
> From your explanation I infer that this driver replaces LaCie stock
> firmware, am I right? There must be however some circuit that controls
> LED brightness then.
OK, I think I may have managed to confuse you completely.
The LEDs are controlled by a CPLD. The leds-netxbig driver talks to the
CPLD via the gpio-ext "kind of" bus:
leds-netxbig -> gpio-ext bus -> CPLD -> LEDs
"LaCie stock firmware" don't refer to the firmware embedded in the CPLD
but to the stock LaCie Linux system running *on* the board.
"LEDs are only enabled at their maximum level by the LaCie stock
firmware" means: "In the Linux LaCie system running on the board,
userland only configures the LED brightness to 0 or 255".
It don't mean that the CPLD does some weird stuff implying that the
feature is somewhat broken. No, the feature works. Simply userland
(in the stock LaCie system aka firmware) don't use it.
Remember that your original question was:
"Doesn't specification of your device say what current value given
brightness level reflects?"
Let me rephrase my answer without using "LaCie stock firmware":
No this information is not available in the board specification. It is
probably because this feature is not used by the LaCie Linux userland.
The LED brightness is configured to off or full. Other levels are not
used. That's probably why no one took care of measuring the LED current
consumption.
Let me know if it is still unclear for you.
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150928/f7ba5240/attachment.sig>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
2015-09-28 13:25 ` Simon Guinot
@ 2015-09-28 13:43 ` Jacek Anaszewski
-1 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-09-28 13:43 UTC (permalink / raw)
To: Simon Guinot
Cc: Bryan Wu, Richard Purdie, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds, linux-arm-kernel, devicetree
On 09/28/2015 03:25 PM, Simon Guinot wrote:
> On Mon, Sep 28, 2015 at 02:24:40PM +0200, Jacek Anaszewski wrote:
>> On 09/28/2015 01:50 PM, Simon Guinot wrote:
>>> On Mon, Sep 28, 2015 at 12:15:22PM +0200, Jacek Anaszewski wrote:
>>>> On 09/28/2015 11:19 AM, Simon Guinot wrote:
>>>>> On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
>>>>>> Hi Simon,
>>>>>
>>>>> Hi Jacek,
>>>>>
>>>>>>
>>>>>> Does your device support reading the brightness currently set?
>>>>>
>>>>> No it don't.
>>>>>
>>>>>> If so, it would be good to implement brightness_get op, because
>>>>>> AFAIR you mentioned that the firmware you are working with sets
>>>>>> always maximum brightness value. Having the op implemented would
>>>>>> allow to find this out.
>>>>>
>>>>> I don't understand how this can help. I mean, the only issue is that at
>>>>> startup the initial LED state is unknown. And the software brightness
>>>>> value could be false. But once the LED is configured, the brightness
>>>>> values for software and hardware are synchronized. The brightness value
>>>>> is stored/cached in led_classdev and it can be retrieved by the user via
>>>>> sysfs...
>>>>>
>>>>> For my own knowledge, is there some interest in having brightness_get(),
>>>>> aside of guessing the LED initial state ?
>>>>
>>>> Some LED controllers can adjust brightness in case battery voltage level
>>>> falls below some threshold.
>>>
>>> OK, thanks for the explanation.
>>>
>>>>
>>>>> What does the embedded firmware is writing 255 or 0 into the brightness
>>>>> sysfs attribute. The max_brightness value is ignored. After this patch,
>>>>> writing 255 and 0 still allows to configure the LED in the same way:
>>>>> maximum brightness or off. Thus, I believe there is no compatibility
>>>>> issue.
>>>>
>>>> LED core always assures that brightness value passed to brightness_set
>>>> op does not exceed max_brightness value. So, now after executing
>>>> "echo 255 > brightness", LED core will adjust it to max_brightness
>>>> (e.g. 7) before passing to brightness_set.
>>>>
>>>> In the message [1], you mentioned that "LEDs are only enabled at their
>>>> maximum level", so IIUC following is possible:
>>>>
>>>> #echo 3 > "brightness"
>>>>
>>>> firmware sets brightness to max_brightness from DT (e.g. 7), but
>>>>
>>>> #cat brightness
>>>> #3
>>>>
>>>> Is it true?
>>>
>>> Oh no sorry, it is a misunderstanding. By "LEDs are only enabled at
>>> their maximum level", I was meaning "LEDs are only enabled at their
>>> maximum level by the LaCie stock firmware". The firmware don't make
>>> use of the different hardware brightness levels available. But the
>>> feature works perfectly. If you write 3 into sysfs "brightness", then
>>> you get the third brightness level.
>>
>> I thought that driver talks to firmware, which controls the LEDs.
>> From your explanation I infer that this driver replaces LaCie stock
>> firmware, am I right? There must be however some circuit that controls
>> LED brightness then.
>
> OK, I think I may have managed to confuse you completely.
>
> The LEDs are controlled by a CPLD. The leds-netxbig driver talks to the
> CPLD via the gpio-ext "kind of" bus:
>
> leds-netxbig -> gpio-ext bus -> CPLD -> LEDs
>
> "LaCie stock firmware" don't refer to the firmware embedded in the CPLD
> but to the stock LaCie Linux system running *on* the board.
>
> "LEDs are only enabled at their maximum level by the LaCie stock
> firmware" means: "In the Linux LaCie system running on the board,
> userland only configures the LED brightness to 0 or 255".
>
> It don't mean that the CPLD does some weird stuff implying that the
> feature is somewhat broken. No, the feature works. Simply userland
> (in the stock LaCie system aka firmware) don't use it.
>
> Remember that your original question was:
>
> "Doesn't specification of your device say what current value given
> brightness level reflects?"
>
> Let me rephrase my answer without using "LaCie stock firmware":
>
> No this information is not available in the board specification. It is
> probably because this feature is not used by the LaCie Linux userland.
> The LED brightness is configured to off or full. Other levels are not
> used. That's probably why no one took care of measuring the LED current
> consumption.
>
> Let me know if it is still unclear for you.
Thanks for this explanation. Now everything is clear.
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
@ 2015-09-28 13:43 ` Jacek Anaszewski
0 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-09-28 13:43 UTC (permalink / raw)
To: linux-arm-kernel
On 09/28/2015 03:25 PM, Simon Guinot wrote:
> On Mon, Sep 28, 2015 at 02:24:40PM +0200, Jacek Anaszewski wrote:
>> On 09/28/2015 01:50 PM, Simon Guinot wrote:
>>> On Mon, Sep 28, 2015 at 12:15:22PM +0200, Jacek Anaszewski wrote:
>>>> On 09/28/2015 11:19 AM, Simon Guinot wrote:
>>>>> On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
>>>>>> Hi Simon,
>>>>>
>>>>> Hi Jacek,
>>>>>
>>>>>>
>>>>>> Does your device support reading the brightness currently set?
>>>>>
>>>>> No it don't.
>>>>>
>>>>>> If so, it would be good to implement brightness_get op, because
>>>>>> AFAIR you mentioned that the firmware you are working with sets
>>>>>> always maximum brightness value. Having the op implemented would
>>>>>> allow to find this out.
>>>>>
>>>>> I don't understand how this can help. I mean, the only issue is that at
>>>>> startup the initial LED state is unknown. And the software brightness
>>>>> value could be false. But once the LED is configured, the brightness
>>>>> values for software and hardware are synchronized. The brightness value
>>>>> is stored/cached in led_classdev and it can be retrieved by the user via
>>>>> sysfs...
>>>>>
>>>>> For my own knowledge, is there some interest in having brightness_get(),
>>>>> aside of guessing the LED initial state ?
>>>>
>>>> Some LED controllers can adjust brightness in case battery voltage level
>>>> falls below some threshold.
>>>
>>> OK, thanks for the explanation.
>>>
>>>>
>>>>> What does the embedded firmware is writing 255 or 0 into the brightness
>>>>> sysfs attribute. The max_brightness value is ignored. After this patch,
>>>>> writing 255 and 0 still allows to configure the LED in the same way:
>>>>> maximum brightness or off. Thus, I believe there is no compatibility
>>>>> issue.
>>>>
>>>> LED core always assures that brightness value passed to brightness_set
>>>> op does not exceed max_brightness value. So, now after executing
>>>> "echo 255 > brightness", LED core will adjust it to max_brightness
>>>> (e.g. 7) before passing to brightness_set.
>>>>
>>>> In the message [1], you mentioned that "LEDs are only enabled at their
>>>> maximum level", so IIUC following is possible:
>>>>
>>>> #echo 3 > "brightness"
>>>>
>>>> firmware sets brightness to max_brightness from DT (e.g. 7), but
>>>>
>>>> #cat brightness
>>>> #3
>>>>
>>>> Is it true?
>>>
>>> Oh no sorry, it is a misunderstanding. By "LEDs are only enabled at
>>> their maximum level", I was meaning "LEDs are only enabled at their
>>> maximum level by the LaCie stock firmware". The firmware don't make
>>> use of the different hardware brightness levels available. But the
>>> feature works perfectly. If you write 3 into sysfs "brightness", then
>>> you get the third brightness level.
>>
>> I thought that driver talks to firmware, which controls the LEDs.
>> From your explanation I infer that this driver replaces LaCie stock
>> firmware, am I right? There must be however some circuit that controls
>> LED brightness then.
>
> OK, I think I may have managed to confuse you completely.
>
> The LEDs are controlled by a CPLD. The leds-netxbig driver talks to the
> CPLD via the gpio-ext "kind of" bus:
>
> leds-netxbig -> gpio-ext bus -> CPLD -> LEDs
>
> "LaCie stock firmware" don't refer to the firmware embedded in the CPLD
> but to the stock LaCie Linux system running *on* the board.
>
> "LEDs are only enabled at their maximum level by the LaCie stock
> firmware" means: "In the Linux LaCie system running on the board,
> userland only configures the LED brightness to 0 or 255".
>
> It don't mean that the CPLD does some weird stuff implying that the
> feature is somewhat broken. No, the feature works. Simply userland
> (in the stock LaCie system aka firmware) don't use it.
>
> Remember that your original question was:
>
> "Doesn't specification of your device say what current value given
> brightness level reflects?"
>
> Let me rephrase my answer without using "LaCie stock firmware":
>
> No this information is not available in the board specification. It is
> probably because this feature is not used by the LaCie Linux userland.
> The LED brightness is configured to off or full. Other levels are not
> used. That's probably why no one took care of measuring the LED current
> consumption.
>
> Let me know if it is still unclear for you.
Thanks for this explanation. Now everything is clear.
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v6 0/5] Add DT support for netxbig LEDs
2015-09-26 21:02 ` Simon Guinot
@ 2015-10-09 9:43 ` Jacek Anaszewski
-1 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-10-09 9:43 UTC (permalink / raw)
To: Simon Guinot
Cc: Bryan Wu, Richard Purdie, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds, linux-arm-kernel, devicetree
On 09/26/2015 11:02 PM, Simon Guinot wrote:
> Hello,
>
> This patch series adds DT support for the LEDs found on the
> Kirkwood-based LaCie boards 2Big and 5Big Network v2.
>
> Changes for v2:
> - Check timer mode value retrieved from DT.
> - In netxbig_leds_get_of_pdata, don't use unsigned long variables to get
> timer delay values from DT with function of_property_read_u32_index.
> Instead, use a temporary u32 variable. This allows to silence a static
> checker warning.
> - Make timer property optional in the binding documentation. It is now
> aligned with the driver code.
>
> Changes for v3:
> - Fix pointer usage with the temporary u32 variable while calling
> of_property_read_u32_index.
>
> Changes for v4:
> - In DT binding document netxbig-gpio-ext.txt, detail byte order for
> registers and latch mechanism for "enable-gpio".
> - In leds-netxbig.c, add some error messages.
> - In leds-netxbig.c, fix some "sizeof" style issues.
> - In leds-netxbig.c, in netxbig_leds_get_of_pdata(), move the
> of_property_read_string() calls after the error-prone checks.
> - Add some Acked-by.
>
> Changes for v5:
> - Rename DT property "bright-max" into the more common "max-brightness".
> - Make use of the "max-brightness" DT property. Instead of counting the
> data pins of the GPIO extension bus, use "max-brightness" to get the
> maximum brightness level.
> - Add a patch to convert the leds-netxbig driver to the devm_ functions.
>
> Changes for v6:
> - Add a patch to set led_classdev max_brightness in the leds-netxbig
> driver.
> - Decrement the current child node refcount with of_node_put() when an
> error happens while iterating with for_each_child_of_node().
>
> Thanks,
>
> Simon
>
> Simon Guinot (5):
> leds: netxbig: add device tree binding
> ARM: Kirkwood: add LED DT entries for netxbig boards
> ARM: mvebu: remove static LED setup for netxbig boards
> leds: netxbig: convert to use the devm_ functions
> leds: netxbig: set led_classdev max_brightness
>
> .../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
> .../devicetree/bindings/leds/leds-netxbig.txt | 92 ++++++
> arch/arm/boot/dts/kirkwood-net5big.dts | 60 ++++
> arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++
> arch/arm/mach-mvebu/Kconfig | 7 -
> arch/arm/mach-mvebu/Makefile | 1 -
> arch/arm/mach-mvebu/board.h | 21 --
> arch/arm/mach-mvebu/kirkwood.c | 4 -
> arch/arm/mach-mvebu/netxbig.c | 191 ------------
> drivers/leds/leds-netxbig.c | 336 ++++++++++++++++-----
> include/dt-bindings/leds/leds-netxbig.h | 18 ++
> .../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
> 12 files changed, 531 insertions(+), 302 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
> create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
> delete mode 100644 arch/arm/mach-mvebu/board.h
> delete mode 100644 arch/arm/mach-mvebu/netxbig.c
> create mode 100644 include/dt-bindings/leds/leds-netxbig.h
>
Since no comment regarding DT bindings has appeared for a long time,
I decided to merge the patch set without DT maintainer's ack, thanks.
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 0/5] Add DT support for netxbig LEDs
@ 2015-10-09 9:43 ` Jacek Anaszewski
0 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-10-09 9:43 UTC (permalink / raw)
To: linux-arm-kernel
On 09/26/2015 11:02 PM, Simon Guinot wrote:
> Hello,
>
> This patch series adds DT support for the LEDs found on the
> Kirkwood-based LaCie boards 2Big and 5Big Network v2.
>
> Changes for v2:
> - Check timer mode value retrieved from DT.
> - In netxbig_leds_get_of_pdata, don't use unsigned long variables to get
> timer delay values from DT with function of_property_read_u32_index.
> Instead, use a temporary u32 variable. This allows to silence a static
> checker warning.
> - Make timer property optional in the binding documentation. It is now
> aligned with the driver code.
>
> Changes for v3:
> - Fix pointer usage with the temporary u32 variable while calling
> of_property_read_u32_index.
>
> Changes for v4:
> - In DT binding document netxbig-gpio-ext.txt, detail byte order for
> registers and latch mechanism for "enable-gpio".
> - In leds-netxbig.c, add some error messages.
> - In leds-netxbig.c, fix some "sizeof" style issues.
> - In leds-netxbig.c, in netxbig_leds_get_of_pdata(), move the
> of_property_read_string() calls after the error-prone checks.
> - Add some Acked-by.
>
> Changes for v5:
> - Rename DT property "bright-max" into the more common "max-brightness".
> - Make use of the "max-brightness" DT property. Instead of counting the
> data pins of the GPIO extension bus, use "max-brightness" to get the
> maximum brightness level.
> - Add a patch to convert the leds-netxbig driver to the devm_ functions.
>
> Changes for v6:
> - Add a patch to set led_classdev max_brightness in the leds-netxbig
> driver.
> - Decrement the current child node refcount with of_node_put() when an
> error happens while iterating with for_each_child_of_node().
>
> Thanks,
>
> Simon
>
> Simon Guinot (5):
> leds: netxbig: add device tree binding
> ARM: Kirkwood: add LED DT entries for netxbig boards
> ARM: mvebu: remove static LED setup for netxbig boards
> leds: netxbig: convert to use the devm_ functions
> leds: netxbig: set led_classdev max_brightness
>
> .../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
> .../devicetree/bindings/leds/leds-netxbig.txt | 92 ++++++
> arch/arm/boot/dts/kirkwood-net5big.dts | 60 ++++
> arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++
> arch/arm/mach-mvebu/Kconfig | 7 -
> arch/arm/mach-mvebu/Makefile | 1 -
> arch/arm/mach-mvebu/board.h | 21 --
> arch/arm/mach-mvebu/kirkwood.c | 4 -
> arch/arm/mach-mvebu/netxbig.c | 191 ------------
> drivers/leds/leds-netxbig.c | 336 ++++++++++++++++-----
> include/dt-bindings/leds/leds-netxbig.h | 18 ++
> .../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
> 12 files changed, 531 insertions(+), 302 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
> create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
> delete mode 100644 arch/arm/mach-mvebu/board.h
> delete mode 100644 arch/arm/mach-mvebu/netxbig.c
> create mode 100644 include/dt-bindings/leds/leds-netxbig.h
>
Since no comment regarding DT bindings has appeared for a long time,
I decided to merge the patch set without DT maintainer's ack, thanks.
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v6 0/5] Add DT support for netxbig LEDs
2015-10-09 9:43 ` Jacek Anaszewski
@ 2015-10-15 7:16 ` Gregory CLEMENT
-1 siblings, 0 replies; 32+ messages in thread
From: Gregory CLEMENT @ 2015-10-15 7:16 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Simon Guinot, Bryan Wu, Richard Purdie, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds, linux-arm-kernel, devicetree
Hi Jacek,
On ven., oct. 09 2015, Jacek Anaszewski <j.anaszewski@samsung.com> wrote:
> On 09/26/2015 11:02 PM, Simon Guinot wrote:
>> Hello,
[..]
>>
>> Simon Guinot (5):
>> leds: netxbig: add device tree binding
>> ARM: Kirkwood: add LED DT entries for netxbig boards
>> ARM: mvebu: remove static LED setup for netxbig boards
>> leds: netxbig: convert to use the devm_ functions
>> leds: netxbig: set led_classdev max_brightness
>>
>> .../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
>> .../devicetree/bindings/leds/leds-netxbig.txt | 92 ++++++
>> arch/arm/boot/dts/kirkwood-net5big.dts | 60 ++++
>> arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++
>> arch/arm/mach-mvebu/Kconfig | 7 -
>> arch/arm/mach-mvebu/Makefile | 1 -
>> arch/arm/mach-mvebu/board.h | 21 --
>> arch/arm/mach-mvebu/kirkwood.c | 4 -
>> arch/arm/mach-mvebu/netxbig.c | 191 ------------
>> drivers/leds/leds-netxbig.c | 336 ++++++++++++++++-----
>> include/dt-bindings/leds/leds-netxbig.h | 18 ++
>> .../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
>> 12 files changed, 531 insertions(+), 302 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
>> create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
>> delete mode 100644 arch/arm/mach-mvebu/board.h
>> delete mode 100644 arch/arm/mach-mvebu/netxbig.c
>> create mode 100644 include/dt-bindings/leds/leds-netxbig.h
>>
>
> Since no comment regarding DT bindings has appeared for a long time,
> I decided to merge the patch set without DT maintainer's ack, thanks.
it is a good news that this series will be finally merged. However did
you also take the patches "ARM: Kirkwood: add LED DT entries for netxbig
boards" and "ARM: mvebu: remove static LED setup for netxbig boards" ?
Thanks,
Gregory
>
> --
> Best Regards,
> Jacek Anaszewski
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 0/5] Add DT support for netxbig LEDs
@ 2015-10-15 7:16 ` Gregory CLEMENT
0 siblings, 0 replies; 32+ messages in thread
From: Gregory CLEMENT @ 2015-10-15 7:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jacek,
On ven., oct. 09 2015, Jacek Anaszewski <j.anaszewski@samsung.com> wrote:
> On 09/26/2015 11:02 PM, Simon Guinot wrote:
>> Hello,
[..]
>>
>> Simon Guinot (5):
>> leds: netxbig: add device tree binding
>> ARM: Kirkwood: add LED DT entries for netxbig boards
>> ARM: mvebu: remove static LED setup for netxbig boards
>> leds: netxbig: convert to use the devm_ functions
>> leds: netxbig: set led_classdev max_brightness
>>
>> .../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
>> .../devicetree/bindings/leds/leds-netxbig.txt | 92 ++++++
>> arch/arm/boot/dts/kirkwood-net5big.dts | 60 ++++
>> arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++
>> arch/arm/mach-mvebu/Kconfig | 7 -
>> arch/arm/mach-mvebu/Makefile | 1 -
>> arch/arm/mach-mvebu/board.h | 21 --
>> arch/arm/mach-mvebu/kirkwood.c | 4 -
>> arch/arm/mach-mvebu/netxbig.c | 191 ------------
>> drivers/leds/leds-netxbig.c | 336 ++++++++++++++++-----
>> include/dt-bindings/leds/leds-netxbig.h | 18 ++
>> .../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
>> 12 files changed, 531 insertions(+), 302 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
>> create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
>> delete mode 100644 arch/arm/mach-mvebu/board.h
>> delete mode 100644 arch/arm/mach-mvebu/netxbig.c
>> create mode 100644 include/dt-bindings/leds/leds-netxbig.h
>>
>
> Since no comment regarding DT bindings has appeared for a long time,
> I decided to merge the patch set without DT maintainer's ack, thanks.
it is a good news that this series will be finally merged. However did
you also take the patches "ARM: Kirkwood: add LED DT entries for netxbig
boards" and "ARM: mvebu: remove static LED setup for netxbig boards" ?
Thanks,
Gregory
>
> --
> Best Regards,
> Jacek Anaszewski
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v6 0/5] Add DT support for netxbig LEDs
2015-10-15 7:16 ` Gregory CLEMENT
@ 2015-10-15 8:11 ` Jacek Anaszewski
-1 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-10-15 8:11 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Simon Guinot, Bryan Wu, Richard Purdie, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Vincent Donnefort,
Yoann Sculo, Linus Walleij, Alexandre Courbot, Rob Herring,
linux-leds, linux-arm-kernel, devicetree
Hi Gregory,
On 10/15/2015 09:16 AM, Gregory CLEMENT wrote:
> Hi Jacek,
>
> On ven., oct. 09 2015, Jacek Anaszewski <j.anaszewski@samsung.com> wrote:
>
>> On 09/26/2015 11:02 PM, Simon Guinot wrote:
>>> Hello,
>
> [..]
>>>
>>> Simon Guinot (5):
>>> leds: netxbig: add device tree binding
>>> ARM: Kirkwood: add LED DT entries for netxbig boards
>>> ARM: mvebu: remove static LED setup for netxbig boards
>>> leds: netxbig: convert to use the devm_ functions
>>> leds: netxbig: set led_classdev max_brightness
>>>
>>> .../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
>>> .../devicetree/bindings/leds/leds-netxbig.txt | 92 ++++++
>>> arch/arm/boot/dts/kirkwood-net5big.dts | 60 ++++
>>> arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++
>>> arch/arm/mach-mvebu/Kconfig | 7 -
>>> arch/arm/mach-mvebu/Makefile | 1 -
>>> arch/arm/mach-mvebu/board.h | 21 --
>>> arch/arm/mach-mvebu/kirkwood.c | 4 -
>>> arch/arm/mach-mvebu/netxbig.c | 191 ------------
>>> drivers/leds/leds-netxbig.c | 336 ++++++++++++++++-----
>>> include/dt-bindings/leds/leds-netxbig.h | 18 ++
>>> .../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
>>> 12 files changed, 531 insertions(+), 302 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
>>> create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
>>> delete mode 100644 arch/arm/mach-mvebu/board.h
>>> delete mode 100644 arch/arm/mach-mvebu/netxbig.c
>>> create mode 100644 include/dt-bindings/leds/leds-netxbig.h
>>>
>>
>> Since no comment regarding DT bindings has appeared for a long time,
>> I decided to merge the patch set without DT maintainer's ack, thanks.
>
> it is a good news that this series will be finally merged. However did
> you also take the patches "ARM: Kirkwood: add LED DT entries for netxbig
> boards" and "ARM: mvebu: remove static LED setup for netxbig boards" ?
Yes, I did:
https://git.kernel.org/cgit/linux/kernel/git/j.anaszewski/linux-leds.git/log/?h=for-next
They should appear in the next issue of linux-next.
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v6 0/5] Add DT support for netxbig LEDs
@ 2015-10-15 8:11 ` Jacek Anaszewski
0 siblings, 0 replies; 32+ messages in thread
From: Jacek Anaszewski @ 2015-10-15 8:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi Gregory,
On 10/15/2015 09:16 AM, Gregory CLEMENT wrote:
> Hi Jacek,
>
> On ven., oct. 09 2015, Jacek Anaszewski <j.anaszewski@samsung.com> wrote:
>
>> On 09/26/2015 11:02 PM, Simon Guinot wrote:
>>> Hello,
>
> [..]
>>>
>>> Simon Guinot (5):
>>> leds: netxbig: add device tree binding
>>> ARM: Kirkwood: add LED DT entries for netxbig boards
>>> ARM: mvebu: remove static LED setup for netxbig boards
>>> leds: netxbig: convert to use the devm_ functions
>>> leds: netxbig: set led_classdev max_brightness
>>>
>>> .../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 ++
>>> .../devicetree/bindings/leds/leds-netxbig.txt | 92 ++++++
>>> arch/arm/boot/dts/kirkwood-net5big.dts | 60 ++++
>>> arch/arm/boot/dts/kirkwood-netxbig.dtsi | 80 +++++
>>> arch/arm/mach-mvebu/Kconfig | 7 -
>>> arch/arm/mach-mvebu/Makefile | 1 -
>>> arch/arm/mach-mvebu/board.h | 21 --
>>> arch/arm/mach-mvebu/kirkwood.c | 4 -
>>> arch/arm/mach-mvebu/netxbig.c | 191 ------------
>>> drivers/leds/leds-netxbig.c | 336 ++++++++++++++++-----
>>> include/dt-bindings/leds/leds-netxbig.h | 18 ++
>>> .../linux/platform_data/leds-kirkwood-netxbig.h | 1 +
>>> 12 files changed, 531 insertions(+), 302 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
>>> create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
>>> delete mode 100644 arch/arm/mach-mvebu/board.h
>>> delete mode 100644 arch/arm/mach-mvebu/netxbig.c
>>> create mode 100644 include/dt-bindings/leds/leds-netxbig.h
>>>
>>
>> Since no comment regarding DT bindings has appeared for a long time,
>> I decided to merge the patch set without DT maintainer's ack, thanks.
>
> it is a good news that this series will be finally merged. However did
> you also take the patches "ARM: Kirkwood: add LED DT entries for netxbig
> boards" and "ARM: mvebu: remove static LED setup for netxbig boards" ?
Yes, I did:
https://git.kernel.org/cgit/linux/kernel/git/j.anaszewski/linux-leds.git/log/?h=for-next
They should appear in the next issue of linux-next.
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2015-10-15 8:11 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-26 21:02 [PATCH v6 0/5] Add DT support for netxbig LEDs Simon Guinot
2015-09-26 21:02 ` Simon Guinot
2015-09-26 21:02 ` [PATCH v6 1/5] leds: netxbig: add device tree binding Simon Guinot
2015-09-26 21:02 ` Simon Guinot
2015-09-26 21:02 ` [PATCH v6 2/5] ARM: Kirkwood: add LED DT entries for netxbig boards Simon Guinot
2015-09-26 21:02 ` Simon Guinot
2015-09-26 21:02 ` [PATCH v6 3/5] ARM: mvebu: remove static LED setup " Simon Guinot
2015-09-26 21:02 ` Simon Guinot
2015-09-26 21:02 ` [PATCH v6 4/5] leds: netxbig: convert to use the devm_ functions Simon Guinot
2015-09-26 21:02 ` Simon Guinot
[not found] ` <1443301358-2131-1-git-send-email-simon.guinot-jKBdWWKqtFpg9hUCZPvPmw@public.gmane.org>
2015-09-26 21:02 ` [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness Simon Guinot
2015-09-26 21:02 ` Simon Guinot
2015-09-28 8:02 ` Jacek Anaszewski
2015-09-28 8:02 ` Jacek Anaszewski
2015-09-28 9:19 ` Simon Guinot
2015-09-28 9:19 ` Simon Guinot
2015-09-28 10:15 ` Jacek Anaszewski
2015-09-28 10:15 ` Jacek Anaszewski
[not found] ` <5609133A.3050802-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-09-28 11:50 ` Simon Guinot
2015-09-28 11:50 ` Simon Guinot
2015-09-28 12:24 ` Jacek Anaszewski
2015-09-28 12:24 ` Jacek Anaszewski
2015-09-28 13:25 ` Simon Guinot
2015-09-28 13:25 ` Simon Guinot
2015-09-28 13:43 ` Jacek Anaszewski
2015-09-28 13:43 ` Jacek Anaszewski
2015-10-09 9:43 ` [PATCH v6 0/5] Add DT support for netxbig LEDs Jacek Anaszewski
2015-10-09 9:43 ` Jacek Anaszewski
2015-10-15 7:16 ` Gregory CLEMENT
2015-10-15 7:16 ` Gregory CLEMENT
2015-10-15 8:11 ` Jacek Anaszewski
2015-10-15 8:11 ` Jacek Anaszewski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.