Fix potential ERR_PTR(0).
Signed-off-by: Marek Behún <kabel@kernel.org>
Fixes: d78b10f5713d9 ("leds: tca6507: use fwnode API instead of OF")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Convert to use fwnode API instead of OF. It is more generic and if
someone wants to use this driver without device-tree yet still, they
will be able to via swnode fwnodes.
Remove the gpio setup function from platdata.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: NeilBrown <neilb@suse.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The only in-tree usage of this driver is via device-tree. No on else
includes linux/leds-tca6507.h, so absorb the definition of platdata
structure.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: NeilBrown <neilb@suse.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This driver uses extended LED registration, so we do not need to parse
the `label` DT property on our own.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Now that the potential use-after-free issue is resolved we can use
devres for LED registration in this driver.
By using devres version of LED registering function we can remove the
.remove method from this driver.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Instead of registering LED under the MFD device, this driver sets the
parent of the LED it is registering to the parent of the MFD device (the
I2C client device).
Because of this we cannot use devres for LED registration, since it can
result in use-after-free, see commit
a0972fff09 ("leds: lm36274: fix use-after-free on unbind").
The only other in-tree driver that also registers under the MFD device
(drivers/regulator/lm363x-regulator.c) sets the parent to the MFD
device.
Set the parent of this LED to the MFD device, instead of the I2C client
device.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
These settings are not parsed from DT and therefore semantically should
not be set in function with a name lm36274_parse_dt.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
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.
Previously if the `label` DT property was not present, the code composed
name for the LED in the form
"parent_name::"
For backwards compatibility we therefore set
init_data->default_label = ":";
so that the LED will not get a different name if `label` property is not
present, nor are `color` and `function`.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Do not use device_for_each_child_node. Since this driver works only with
once child node present, use device_get_next_child_node instead.
This also saves one level of indentation.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Rename this variable so that it is easier to read and easier to write in
80 columns. Also rename variable of this type in lm36274_brightness_set
from led to chip, to be consistent.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Acer Iconia Tab A500 is an Android tablet device which has two LEDs
embedded into the Power Button. Orange LED indicates "battery charging"
status and white LED indicates "wake-up/charge-done" status. The new LED
driver provides control over both LEDs to userspace.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
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: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
No need to use variable found, we can determine whether the mode was
found by comparing iterator variable to its limit.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Register each LED immediately after parsing OF properties. This
simplifies the driver.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Use helper variable dev instead of always writing &pdev->dev.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Return directly instead of setting result and breaking.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Rename variable led_dat to led in various functions.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This drivers leaks GPIO descriptors on driver removal. Use devres API
function devm_gpiod_get_from_of_node instead of gpiod_get_from_of_node
to avoid this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Not-for-stable
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Move parsing of DT properties of one LED into separate function. This
saves indentation level and is nicer to read.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Move forward from platform data to device tree only.
Since commit c7896490dd ("leds: ns2: Absorb platform data") the
platform data structure is absorbed into the driver, because nothing
else in the source tree uses it. Since nobody complained and all usage
of this driver is via device tree, change the code to work with device
tree only. As Linus Walleij wrote, the device tree should be the
preferred way forward anyway.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Since .remove method is not needed now that we use devres, there is no
need to remember the number of LEDs in struct ns2_led_priv. Alloc simple
array of ns2_led_data structs.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using devres version of LED registering function we can remove the
.remove method from this driver. The probe method also gets simpler.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
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>
We can return the last ret value.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Use helper variable dev instead of always writing &pdev->dev.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
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: Linus Walleij <linus.walleij@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Use helper variable dev instead of always writing &pdev->dev.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: John Crispin <john@phrozen.org>
Cc: Ryder Lee <ryder.lee@mediatek.com>
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.
Since init_data is passed with fwnode handle, we do not need to set
the of_node member of the newly created LED classdev.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: John Crispin <john@phrozen.org>
Cc: Ryder Lee <ryder.lee@mediatek.com>
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.
Previously if the `label` DT property was not present, the code composed
name for the LED in the form
"max77650::"
For backwards compatibility we therefore set
init_data->default_label = ":";
so that the LED will not get a different name if `label` property is not
present.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Use helper variable dev instead of always writing &client->dev, or
&priv->client->dev, or even &led->priv->client->dev.
With one more line moved reverse christmas tree is also achieved.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
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.
Previously if the `label` DT property was not present, the code composed
name for the LED in the form
"parent_name::"
For backwards compatibility we therefore set
init_data->default_label = ":";
so that the LED will not get a different name if `label` property is not
present.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Dan Murphy <dmurphy@ti.com>
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: Álvaro Fernández Rojas <noltari@gmail.com>
Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: Jaedon Shin <jaedon.shin@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
These two drivers do not provide remove method and use devres for
allocation of other resources, yet they use led_classdev_register
instead of the devres variant, devm_led_classdev_register.
Fix this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Álvaro Fernández Rojas <noltari@gmail.com>
Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: Jaedon Shin <jaedon.shin@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Cc: stable@kernel.org
Fix OF node leaks by calling of_node_put in
for_each_available_child_of_node when the cycle breaks or returns.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Nikita Travkin <nikitos.tr@gmail.com>
Cc: Milo Kim <milo.kim@ti.com>
Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Not-for-stable: untested, theoretical, insignificant leaks
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 devm_led_classdev_register_ext is given init_data with fwnode set,
so the LED core sets .of_node of the new LED classdev correctly.
Do not rewrite this value to parent of_node.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Daniel Mack <daniel@caiaq.de>
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>
This driver can be compiled on other platforms with small change if
COMPILE_TEST=y.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
These drivers can be compiled without modification when COMPILE_TEST=y:
cobalt-qube, cobalt-raq, netxbig, ns2 and s3c24xx
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
If LEDs are configured through device tree and the property 'label' is
omitted, the label is supposed to be generated from the properties
'function' and 'color' if present. While this works fine for e.g. the
'leds-gpio' driver, it did not for 'leds-pwm'.
The reason is, you get this label naming magic only if you add a LED
device through 'devm_led_classdev_register_ext()' and pass a pointer to
the current device tree node.
For the following node from dts the LED appeared as 'led-5' in sysfs
before and as 'red:debug' after this change.
pwm_leds {
compatible = "pwm-leds";
led-5 {
function = LED_FUNCTION_DEBUG;
color = <LED_COLOR_ID_RED>;
pwms = <&pwm0 2 10000000 0>;
max-brightness = <127>;
linux,default-trigger = "heartbeat";
panic-indicator;
};
};
Signed-off-by: Alexander Dahl <post@lespocky.de>
Cc: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
generate a 5ms low pulse on shutdown pin when startup, then the chip
becomes more stable in the complex EM environment.
Signed-off-by: Grant Feng <von81@163.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Introduce the LP5036/30/24/18/12/9 RGB LED driver.
The difference in these parts are the number of
LED outputs where the:
LP5036 can control 36 LEDs
LP5030 can control 30 LEDs
LP5024 can control 24 LEDs
LP5018 can control 18 LEDs
LP5012 can control 12 LEDs
LP5009 can control 9 LEDs
The device has the ability to group LED outputs into control banks
so that multiple LED banks can be controlled with the same mixing and
brightness. Or the LED outputs can also be controlled independently.
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
With these kernel configs:
CONFIG_LEDS_CLASS=m
# CONFIG_LEDS_CLASS_MULTICOLOR is not set
CONFIG_LEDS_LP55XX_COMMON=y
CONFIG_LEDS_LP5521=m
CONFIG_LEDS_LP5562=m
leds-lp55xx-common.c has a build error because it is builtin and
calls an interface that is built as a loadable module (due to
LEDS_CLASS=m). By making LEDS_LP55XX_COMMON depend on LEDS_CLASS,
this config combination cannot happen, thus preventing the build error.
ld: drivers/leds/leds-lp55xx-common.o: in function `lp55xx_register_leds':
leds-lp55xx-common.c:(.text+0xc5f): undefined reference to `devm_led_classdev_register_ext'
Fixes: 33b3a561f4 ("leds: support new LP8501 device - another LP55xx common")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Milo Kim <milo.kim@ti.com>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Pavel Machek <pavel@ucw.cz>
IBM created an implementation of the PCA9552 on a PIC16F
microcontroller. The I2C device addresses are different from the
hardware PCA9552, so add a new compatible string and associated
platform data to be able to probe this device.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Vishwanatha Subbanna <vishwa@linux.vnet.ibm.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
clang static analysis reports this problem
leds-mt6323.c:275:12: warning: Division by zero
duty_hw = MT6323_CAL_HW_DUTY(*delay_on, period);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is because period can be 0.
period = *delay_on + *delay_off;
There is a later check that *delay_on/off are valid.
if (!*delay_on && !*delay_off) {
*delay_on = 500;
*delay_off = 500;
}
Setting the delay_on/off means period needs to be recalculated
anyway. So move the period statements after this check.
Fixes: 216ec6cc4c ("leds: Add LED support for MT6323 PMIC")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The driver includes machine header for GPIO registers but actually does
not use them.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Okay, so... this one is interesting. RGB LEDs are very common, and we
need to have some kind of support for them. Multicolor is for
arbitrary set of LEDs in one package, RGB is for LEDs that can produce
full range of colors. We do not have real multicolor LED that is not
RGB in the pipeline, so that one is disabled for now.
You can expect this saga to continue with next pull requests.
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCXyskqQAKCRAw5/Bqldv6
8ge0AJ9JRTa/0Xkl7JuKUpC93jAnvjpK+ACgsDijb77H5zmtwC8xa0kXiDsbh3E=
=aSJX
-----END PGP SIGNATURE-----
Merge tag 'leds-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds
Pull LED updates from Pavel Machek:
"Okay, so... this one is interesting. RGB LEDs are very common, and we
need to have some kind of support for them. Multicolor is for
arbitrary set of LEDs in one package, RGB is for LEDs that can produce
full range of colors. We do not have real multicolor LED that is not
RGB in the pipeline, so that one is disabled for now.
You can expect this saga to continue with next pull requests"
* tag 'leds-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (37 commits)
MAINTAINERS: Remove myself as LED subsystem maintainer
leds: disallow /sys/class/leds/*:multi:* for now
leds: add RGB color option, as that is different from multicolor.
Make LEDS_LP55XX_COMMON depend on I2C to fix build errors:
Documentation: ABI: leds-turris-omnia: document sysfs attribute
leds: initial support for Turris Omnia LEDs
dt-bindings: leds: add cznic,turris-omnia-leds binding
leds: pattern trigger -- check pattern for validity
leds: Replace HTTP links with HTTPS ones
leds: trigger: add support for LED-private device triggers
leds: lp5521: Add multicolor framework multicolor brightness support
leds: lp5523: Update the lp5523 code to add multicolor brightness function
leds: lp55xx: Add multicolor framework support to lp55xx
leds: lp55xx: Convert LED class registration to devm_*
dt-bindings: leds: Convert leds-lp55xx to yaml
leds: multicolor: Introduce a multicolor class definition
leds: Add multicolor ID to the color ID list
dt: bindings: Add multicolor class dt bindings documention
leds: lp5523: Fix various formatting issues in the code
leds: lp55xx: Fix file permissions to use DEVICE_ATTR macros
...
All the LEDs in the queue are RGB, so they should not use multi for
their color.
Make sure we don't add such LED by mistake (and make it part of ABI).
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Multicolor is a bit too abstract. Yes, we can have
Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are
RGB, and not even RGB-White or RGB-Yellow variants emerged.
Multicolor is not a good fit for RGB LED. It does not really know
about LED color. In particular, there's no way to make LED "white".
Userspace is interested in knowing "this LED can produce arbitrary
color", which not all multicolor LEDs can.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
leds-lp55xx-common.c:(.text+0x9d): undefined reference to `i2c_smbus_read_byte_data'
leds-lp55xx-common.c:(.text+0x8fc): undefined reference to `i2c_smbus_write_byte_data'
These errors happened when I2C=m and LEDS_LP55XX_COMMON=y, so
prevent that from being possible.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: linux-leds@vger.kernel.org
Cc: Milo Kim <milo.kim@ti.com>
Cc: Mathias Nyman <mathias.nyman@nokia.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This adds basic support for LEDs on the front side of CZ.NIC's Turris
Omnia router.
There are 12 RGB LEDs. The controller supports HW triggering mode for
the LEDs, but this driver does not support it yet, and sets all the LEDs
defined in device-tree into SW mode upon probe.
This driver uses the multicolor LED framework.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Some LED controllers may come with an internal HW triggering mechanism
for the LED and the ability to switch between SW control and the
internal HW control. This includes most PHYs, various ethernet switches,
the Turris Omnia LED controller or AXP20X PMIC.
This adds support for registering such triggers.
This code is based on work by Pavel Machek <pavel@ucw.cz> and
Ondřej Jirman <megous@megous.com>.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Add the multicolor brightness call back to support the multicolor
framework. This function allows setting the brightness across
grouped LED channels in a single call.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Add the multicolor brightness call back to support the multicolor
framework. This call back allows setting brightness on grouped channels
in a single function.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Add multicolor framework support for the lp55xx family.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Convert the LED class registration calls to the LED devm_*
registration calls.
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Introduce a multicolor class that groups colored LEDs
within a LED node.
The multicolor class groups monochrome LEDs and allows controlling two
aspects of the final combined color: hue and lightness. The former is
controlled via the intensity file and the latter is controlled
via brightness file.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
[squashed leds: multicolor: Fix camel case in documentation in]
Add a new color ID that is declared as MULTICOLOR as with the
multicolor framework declaring a definitive color is not accurate
as the node can contain multiple colors.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Fix checkpatch errors and warnings for the LP5523.c device
driver.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Fix the checkpatch warnings for the use of the file permission macros.
In converting the file permissions to the DEVICE_ATTR_XX macros the
call back function names needed to be updated within the code.
This means that the lp55xx_ needed to be dropped in the name to keep in
harmony with the ABI documentation.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes. Also, remove unnecessary
function sizeof_gpio_leds_priv().
This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes. Also, remove unnecessary
function sizeof_ns2_led_priv().
This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The leds-gpio driver mixes up the legacy GPIO flags with the
GPIO descriptor flags and passes a legacy flag to
devm_gpiod_get_index().
Fix this by replacing the flags variable with the strict
descriptor flag.
Fixes: 45d4c6de4e ("leds: gpio: Try to lookup gpiod from device")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon
system suspend.
led_set_brightness_nopm() uses schedule_work() to set LED brightness.
However, there's no guarantee that the scheduled work gets executed
because no one flushes the work.
So flush the scheduled work to make sure LED gets turned off.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fixes: 81fe8e5b73 ("leds: core: Add led_set_brightness_nosleep{nopm} functions")
Signed-off-by: Pavel Machek <pavel@ucw.cz>
If the GPIO has not been configured yet, writing to inverted will raise
a kernel warning.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This driver provides a GPIO chip, so include <linux/gpio/driver.h>
and not the legacy <linux/gpio.h> header.
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Matt Spinler <mspinler@linux.vnet.ibm.com>
Cc: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The LP55xx driver is already using the of_gpio() functions to
pick a global GPIO number for "enable" from the device tree and
request the line. Simplify it by just using a GPIO descriptor.
Make sure to keep the enable GPIO line optional, change the
naming from "lp5523_enable" to "LP55xx enable" to reflect that
this is used on all LP55xx LED drivers.
Cc: Milo Kim <milo.kim@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This converts the s3c24xx LED driver to use GPIO descriptors
and also modify all board files to account for these changes
by registering the appropriate GPIO tables for each board.
The driver was using a custom flag to indicate open drain
(tristate) but this can be handled by standard descriptor
machine tables.
The driver was setting non-pull-up for the pin using the custom
S3C24xx GPIO API, but this is a custom pin control system used
by the S3C24xx and no generic GPIO function, so this has simply
been pushed back into the respective board files.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Right now the driver uses only 3 LED modes:
0: On
1: HW Blinking (Interval 1)
3: Off
However, the controller supports a second HW blinking interval, which results
in 4 possible LED modes:
0: On
1: HW Blinking (Interval 1)
2: HW Blinking (Interval 2)
3: Off
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Drop the pointless and needlessly confusing casts of struct-device
pointers.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: 8d3b6a4001 ("leds: wm831x-status: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot use devres so that
deregistration ends up being tied to the parent device, something which
leads to use-after-free on driver unbind when the class device is
released while still being registered.
Fixes: 11e1bbc116 ("leds: lm36274: Introduce the TI LM36274 LED driver")
Cc: stable <stable@vger.kernel.org> # 5.3
Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: 50154e29e5 ("leds: lm3533: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: eed16255d6 ("leds: da903x: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: 375446df95 ("leds: 88pm860x: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
clang points out that doing arithmetic between diffent enums is usually
a mistake:
drivers/leds/leds-lm355x.c:167:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
reg_val = pdata->pin_tx2 | pdata->ntc_pin;
~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
drivers/leds/leds-lm355x.c:178:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
reg_val = pdata->pin_tx2 | pdata->ntc_pin | pdata->pass_mode;
~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
In this driver, it is intentional, so add a cast to hide the false-positive
warning. It appears to be the only instance of this warning at the moment.
Fixes: b98d13c725 ("leds: Add new LED driver for lm355x chips")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
New drivers: aw2013, sgm3140, some fixes. Nothing much to see here,
next release should be more interesting.
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCXtjlggAKCRAw5/Bqldv6
8mi4AJ9sFTwt9zcnIB3dZcD+C9J/GtCU7ACgwlN9UsQ1qvpEG1xE0mSgLlPvebQ=
=HymN
-----END PGP SIGNATURE-----
Merge tag 'leds-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds
Pull LED updates from Pavel Machek:
"New drivers: aw2013, sgm3140, some fixes
Nothing much to see here, next release should be more interesting"
* tag 'leds-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds:
leds: add aw2013 driver
dt-bindings: leds: Add binding for aw2013
leds: trigger: remove redundant assignment to variable ret
leds: netxbig: Convert to use GPIO descriptors
leds: add sgm3140 driver
dt-bindings: leds: Add binding for sgm3140
leds: ariel: Add driver for status LEDs on Dell Wyse 3020
leds: pwm: check result of led_pwm_set() in led_pwm_add()
leds: tlc591xxt: hide error on EPROBE_DEFER
leds: tca6507: Include the right header
leds: lt3593: Drop surplus include
leds: lp3952: Include the right header
leds: lm355x: Drop surplus include
This commit adds support for AWINIC AW2013 3-channel LED driver.
The chip supports 3 PWM channels and is controlled with I2C.
Signed-off-by: Nikita Travkin <nikitos.tr@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The variable ret is being assigned with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This converts the NetXbig LED driver to use GPIO descriptors
instead of using the legacy interfaces in <linux/of_gpio.h>
and <linux/gpio.h> to iteratively parse the device tree for
global GPIO numbers.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Add a driver for the SGMICRO SGM3140 Buck/Boost Charge Pump LED driver.
This device is controlled by two GPIO pins, one for enabling and the
second one for switching between torch and flash mode.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This adds support for controlling the LEDs attached to the Embedded
Controller on a Dell Wyse 3020 "Ariel" board.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
led_pwm_set() now returns an error when setting the PWM fails.
Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
If devm_led_classdev_register_ext() fails with EPROBE_DEFER, we get:
tlc591xx 0-0040: couldn't register LED (null)
Only print the error if the error is something else than EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The TCA6507 optionally presents a GPIO controller, so include
<linux/gpio/driver.h> instead of the legacy <linux/gpio.h>.
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Marek Behún