Do the parsing of `linux,default-trigger` DT property to LED core.
Currently it is done in many different drivers and the code is repeated.
This patch removes the parsing from 23 drivers:
an30259a, aw2013, bcm6328, bcm6358, cr0014114, el15203000, gpio,
is31fl32xx, lm3532, lm36274, lm3692x, lm3697, lp50xx, lp8860, lt3593,
max77650, mt6323, ns2, pm8058, pwm, syscon, tlc591xx and turris-omnia.
There is one driver in drivers/input which parses this property on it's
own. I shall send a separate patch there after this is applied.
There are still 8 drivers that parse this property on their own because
they do not pass the led_init_data structure to the registering
function. I will try to refactor those in the future.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: David Rivshin <drivshin@allworx.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Various drivers count and iterate over OF children nodes via
of_get_child_count and for_each_child_of_node. Instead they should use
of_get_available_child_count and for_each_available_child_of_node, so
that if a given node has the `status` property set to `disabled`, the
child will be ignored.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Andrey Utkin <andrey_utkin@fastmail.com>
Cc: Baolin Wang <baolin.wang7@gmail.com>
Cc: Baolin Wang <baolin.wang@linaro.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Christian Mauderer <oss@c-mauderer.de>
Cc: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: David Rivshin <drivshin@allworx.com>
Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Milo Kim <milo.kim@ti.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Nikita Travkin <nikitos.tr@gmail.com>
Cc: Orson Zhai <orsonzhai@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Philippe Retornaz <philippe.retornaz@epfl.ch>
Cc: Riku Voipio <riku.voipio@iki.fi>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Simon Shields <simon@lineageos.org>
Cc: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Cc: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The dev_of_node function should be preferred.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Orson Zhai <orsonzhai@gmail.com>
Cc: Baolin Wang <baolin.wang7@gmail.com>
Cc: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Riku Voipio <riku.voipio@iki.fi>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Simply use device_get_match_data instead of matching against the match
table again.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: David Rivshin <drivshin@allworx.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Christian Mauderer <oss@c-mauderer.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct is31fl32xx_priv {
...
struct is31fl32xx_led_data leds[0];
};
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.
So, replace the following function:
static inline size_t sizeof_is31fl32xx_priv(int num_leds)
{
return sizeof(struct is31fl32xx_priv) +
(sizeof(struct is31fl32xx_led_data) * num_leds);
}
with:
struct_size(priv, leds, count)
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Otherwise the driver module will not be automatically probed.
Fixes: 9d7cffaf99 ("leds: Add driver for the ISSI IS31FL32xx family of LED controllers")
Fixes: e0442d7def ("leds: Add SN3218 and SN3216 support to the IS31FL32XX driver")
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: David Rivshin <drivshin@allworx.com>
Acked-by: David Rivshin <drivshin@allworx.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: David Rivshin <drivshin@allworx.com>
Acked-by: David Rivshin <drivshin@allworx.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Si-En Technology was acquired by ISSI in 2011, and it appears that
the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
Add the "si-en,sn3218" and "si-en,sn3216" compatible strings into the
IS31FL32XX driver as aliases for the issi equivalents, and update
binding documentation.
Datasheets:
IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf
SN3218: http://www.si-en.com/uploadpdf/s2011517171720.pdf
IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf
SN3216: http://www.si-en.com/uploadpdf/SN3216201152410148.pdf
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The IS31FL32xx family of LED controllers are I2C devices with multiple
constant-current channels, each with independent 256-level PWM control.
Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml
This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
(TI am335x) platform.
The programming paradigm of these devices is similar in the following
ways:
- All registers are 8 bit
- All LED control registers are write-only
- Each LED channel has a PWM register (0-255)
- PWM register writes are shadowed until an Update register is poked
- All have a concept of Software Shutdown, which disables output
However, there are some differences in devices:
- 3236/3235 have a separate Control register for each LED,
(3218/3216 pack the enable bits into fewer registers)
- 3236/3235 have a per-channel current divisor setting
- 3236/3235 have a Global Control register that can turn off all LEDs
- 3216 is unique in a number of ways
- OUT9-OUT16 can be configured as GPIOs instead of LED controls
- LEDs can be programmed with an 8-frame animation, with
programmable delay between frames
- LEDs can be modulated by an input audio signal
- Max output current can be adjusted from 1/4 to 2x globally
- Has a Configuration register instead of a Shutdown register
This driver currently only supports the base PWM control function
of these devices. The following features of these devices are not
implemented, although it should be possible to add them in the future:
- All devices are capable of going into a lower-power "software
shutdown" mode.
- The is31fl3236 and is31fl3235 can reduce the max output current
per-channel with a divisor of 1, 2, 3, or 4.
- The is31fl3216 can use some LED channels as GPIOs instead.
- The is31fl3216 can animate LEDs in hardware.
- The is31fl3216 can modulate LEDs according to an audio input.
- The is31fl3216 can reduce/increase max output current globally.
Signed-off-by: David Rivshin <drivshin@allworx.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Marek Behún