| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix the error handling for the led-max-microamp property.
Need to check if the property is present and then if it is
retrieve the setting and its max boundary
Reported-by: Pavel Machek <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Error was detected by PVS-Studio:
V522 Dereferencing of the null pointer 'led_cdev->trigger' might take place.
Fixes: 2282e125a406 ("leds: triggers: let struct led_trigger::activate() return an error code")
Signed-off-by: Oleh Kravchenko <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Move the static keyword to the front of declaration of ramp_table,
and resolve the following compiler warning that can be seen when
building with warnings enabled (W=1):
drivers/leds/leds-ti-lmu-common.c:14:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
Signed-off-by: Krzysztof Wilczynski <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Move the static keyword to the front of declarations ramp_table,
als_avrg_table and als_imp_table, and resolve the following
compiler warnings that can be seen when building with warnings
enabled (W=1):
drivers/leds/leds-lm3532.c:209:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
drivers/leds/leds-lm3532.c:266:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
drivers/leds/leds-lm3532.c:281:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
Signed-off-by: Krzysztof Wilczynski <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Allow all valid GPIOs to be used in the driver.
Fixes: 17354bfe8527 ("leds: Add gpio-led trigger")
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
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 led_pwm_priv {
...
struct led_pwm_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_pwm_leds_priv(int num_leds)
{
return sizeof(struct led_pwm_priv) +
(sizeof(struct led_pwm_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 <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
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 <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Fix the coccinelle issues found in the TI LMU common code
drivers/leds/leds-ti-lmu-common.c:97:20-29: WARNING: Unsigned expression compared with zero: ramp_down < 0
drivers/leds/leds-ti-lmu-common.c:97:5-12: WARNING: Unsigned expression compared with zero: ramp_up < 0
Fixes: 3fce8e1eb994 ("leds: TI LMU: Add common code for TI LMU devices")
Signed-off-by: Dan Murphy <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
We may currently get unpaired regulator calls when configuring the LED
brightness via sysfs in case of regulator calls producing errors. Let's
fix this by maintaining local state for enabled.
Signed-off-by: Tony Lindgren <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
We have a MFD driver compiled as module instantiating this driver. When
unloading that module, those LED devices are not removed, which produces
conflicts, when that module is inserted again.
Signed-off-by: Alexander Dahl <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
If in the certain driver the LED is optional, and it's a majority of them,
the call of led_classdev_unregister() still requires some additional
checks.
The usual pattern on unregistering is to check for NULL, but we also check
for IS_ERR() in case device_create_with_groups() fails.
The change will reduce a burden in a lot of drivers to repeatedly check
for above conditions.
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Allow the full scale current to be configured at init.
Valid rangles are 5mA->29.8mA.
Signed-off-by: Dan Murphy <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Fixed misspelled words, added error check during probe
on the init of the registers, and fixed ALS/I2C control
mode.
Fixes: bc1b8492c764 ("leds: lm3532: Introduce the lm3532 LED driver")
Reported-by: Pavel Machek <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Change the define name of the full scale current registers.
Signed-off-by: Dan Murphy <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Fix the brightness control for I2C mode. Instead of
changing the full scale current register update the ALS target
register for the appropriate banks.
In addition clean up some code errors and random misspellings found
during coding.
Tested on Droid4 as well as LM3532 EVM connected to a BeagleBoneBlack
Fixes: bc1b8492c764 ("leds: lm3532: Introduce the lm3532 LED driver")
Reported-by: Pavel Machek <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
There is no need to be stuck with OF node when we may use agnostic
firmware node instead.
It allows users to get property if needed independently of provider.
Note, some OF parts are left because %pfw [1] is in progress.
[1]: https://lore.kernel.org/patchwork/cover/1054863/
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Switch the max77650 from OF to the fwnode property API.
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
In led_trigger_set(), 'event' is allocated in kasprintf(). However, it is
not deallocated in the following execution if the label 'err_activate' or
'err_add_groups' is entered, leading to memory leaks. To fix this issue,
free 'event' before returning the error.
Fixes: 52c47742f79d ("leds: triggers: send uevent when changing triggers")
Signed-off-by: Wenwen Wang <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
This LED chip provides a GPIO driver, so include
<linux/gpio/driver.h> rather than the legacy header
<linux/gpio.h>.
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Generic Device Lookup Helpers
Persistent tag for others to pull this branch from
Based on patch series from Suzuki K Poulose <[email protected]>
with Subject: [PATCH v3 0/7] drivers: Add generic device lookup helpers
Signed-off-by: Greg Kroah-Hartman <[email protected]>
* tag 'generic_lookup_helpers':
platform: Add platform_find_device_by_driver() helper
drivers: Add generic helper to match any device
drivers: Introduce device lookup variants by ACPI_COMPANION device
drivers: Introduce device lookup variants by device type
drivers: Introduce device lookup variants by fwnode
drivers: Introduce device lookup variants by of_node
drivers: Introduce device lookup variants by name
|
|
Add a helper to match the device name for device lookup. Also
reuse this generic exported helper for the existing bus_find_device_by_name().
and add similar variants for driver/class.
Cc: Alessandro Zummo <[email protected]>
Cc: Alexander Aring <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Dan Murphy <[email protected]>
Cc: Harald Freudenberger <[email protected]>
Cc: Heiko Carstens <[email protected]>
Cc: Jacek Anaszewski <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Maxime Coquelin <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Peter Oberparleiter <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Stefan Schmidt <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Signed-off-by: Suzuki K Poulose <[email protected]>
Reviewed-by: Heikki Krogerus <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
The variable gpio_ext_np in the function netxbig_leds_get_of_pdata takes
the value returned by of_parse_phandle; hence, it must be put in order
to prevent a memory leak. Add an of_node_put for gpio_ext_np before a
return statement, and move a pre-existing of_node_put statement to right
after the last usage of this variable.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Since commit ebc278f15759 ("ARM: mvebu: remove static LED setup for
netxbig boards"), no one in upstream passes in the platform data to
this driver.
Squash leds-kirkwood-netxbig.h into the driver, and remove the legacy
board-file support.
Link: https://lkml.org/lkml/2019/7/20/83
Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Use fwnode_property_count_uXX() directly, that makes code neater.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Dan Murphy <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Use fwnode_property_count_uXX() directly, that makes code neater.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Dan Murphy <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Use fwnode_property_count_uXX() directly, that makes code neater.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Dan Murphy <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <[email protected]>
Cc: Simon Shields <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <[email protected]>
Cc: Linus Walleij <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
After switching to new led_classdev_register_ext() the validity
of struct led_classdev's name property is no longer guaranteed,
and therefore rely on struct device's kobj.name instead.
Signed-off-by: Jacek Anaszewski <[email protected]>
Cc: Sakari Ailus <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
After switching to new led_classdev_register_ext() the validity
of struct led_classdev's name property is no longer guaranteed,
and therefore rely on struct device's kobj.name instead.
Signed-off-by: Jacek Anaszewski <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
At this occassion remove initialization of struct led_classdev's
dev->of_node property in the driver, since now it will be taken from
fwnode assigned to struct led_init_data and passed to the new
devm_led_classdev_register_ext() API.
Signed-off-by: Jacek Anaszewski <[email protected]>
Cc: Oleh Kravchenko <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <[email protected]>
Tested-by: Dan Murphy <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
At this occassion remove initialization of struct led_classdev's
dev->of_node property in the driver, since now it will be taken from
fwnode assigned to struct led_init_data and passed to the new
devm_led_classdev_register_ext() API.
Signed-off-by: Jacek Anaszewski <[email protected]>
Tested-by: Dan Murphy <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
While at it, avoid iterating through available child of nodes
in favor of obtaining single expected child node using single
call to of_get_next_available_child().
Signed-off-by: Jacek Anaszewski <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Tested-by: Dan Murphy <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <[email protected]>
Cc: Daniel Mack <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <[email protected]>
Reviewed-by: Baolin Wang <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Add generic support for composing LED class device name. The newly
introduced led_compose_name() function composes device name according
to either <color:function> or <devicename:color:function> pattern,
depending on the configuration of initialization data.
Backward compatibility with in-driver hard-coded LED class device
names is assured thanks to the default_label and devicename properties
of newly introduced struct led_init_data.
In case none of the aforementioned properties was found, then, for OF
nodes, the node name is adopted for LED class device name.
At the occassion of amending the Documentation/leds/leds-class.txt
unify spelling: colour -> color.
Alongside these changes added is a new tool - tools/leds/get_led_device_info.sh.
The tool allows retrieving details of a LED class device's parent device,
which proves that using vendor or product name for devicename part
of LED name doesn't convey any added value since that information had been
already available in sysfs. The script performs also basic validation
of a LED class device name.
Signed-off-by: Jacek Anaszewski <[email protected]>
Cc: Baolin Wang <[email protected]>
Cc: Dan Murphy <[email protected]>
Cc: Daniel Mack <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Oleh Kravchenko <[email protected]>
Cc: Sakari Ailus <[email protected]>
Cc: Simon Shields <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
Replace of_led_classdev_register() with led_classdev_register_ext(), which
accepts easily extendable struct led_init_data, instead of the fixed
struct device_node argument. The latter can be now passed in an fwnode
property of the struct led_init_data.
The modification is driven by the need for passing additional arguments
required for the forthcoming generic mechanism for composing LED names.
Currently the LED name is conveyed in the "name" char pointer property of
the struct led_classdev. This is redundant since LED class device name
is accessible throughout the whole LED class device life time via
associated struct device's kobj->name property.
The change will not break any existing clients since the patch alters
also existing led_classdev{_flash}_register() macro wrappers, that pass
NULL in place of init_data, which leads to using legacy name
initialization path basing on the struct led_classdev's "name" property.
Three existing users of devm_of_led_classdev_registers() are modified
to use devm_led_classdev_register(), which will not impact their
operation since they in fact didn't need to pass struct device_node on
registration from the beginning.
Signed-off-by: Jacek Anaszewski <[email protected]>
Cc: Baolin Wang <[email protected]>
Cc: Dan Murphy <[email protected]>
Cc: Daniel Mack <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Oleh Kravchenko <[email protected]>
Cc: Sakari Ailus <[email protected]>
Cc: Simon Shields <[email protected]>
Acked-by: Pavel Machek <[email protected]>
|
|
We have a dedicated pointer for that, so use it. Much easier to read and
less computation involved.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Define pr_fmt() macro for prefixing the module name to all
pr_*() outputs, in order to increase log message clarity.
Signed-off-by: Enrico Weigelt <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
The current error message on failed probing tends to be a bit
misleading. Fix it to tell exactly that an APU v1 was not found.
Signed-off-by: Enrico Weigelt <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
As this driver now only supports the APU1 boards, we don't need
to handle profiles anymore and just can use the only one global
array directly.
Signed-off-by: Enrico Weigelt <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
As this driver now only supports the APU1 boards, we don't need
to handle different io sizes anymore.
Signed-off-by: Enrico Weigelt <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
As this driver now only supports the APU1 boards, we don't need
to differenciate between board types anymore. Therefore optimize
away the now obsolete code.
Signed-off-by: Enrico Weigelt <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
This driver only supports gpio-attached LEDs on apu1/2/3 boards,
but neither gpio's themselves, nor other gpio-attached devices
(eg. front button).
For apu2+ a newer, more complete driver exists, based on a generic
driver for the AMD SOCs gpio-controller, supporting LEDs as well
other devices. Therefore these boards don't need legacy support
from this driver anymore.
Both drivers claim the same device, so only one driver may exist
in a system, putting distros in the position to decide between
either apu2+ keys or apu1 led support.
Therefore drop the apu2+ led support from the old driver, solve
the conflict and reduce unnecessary code.
Signed-off-by: Enrico Weigelt <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
There is a typo in KTD2962_MM_MIN_CURR_THRESHOLD_SCALE. 6 and 9 are
switched in 2962.
Define and use KTD2692_MM_MIN_CURR_THRESHOLD_SCALE instead.
Signed-off-by: Christophe JAILLET <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
All this file is about an30259a, including the reference to the datasheet
at the top of the file.
So change the 2 places where an32059a is used instead.
Signed-off-by: Christophe JAILLET <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Firmware files are in ASCII, using 2 hex characters per byte. The
maximum length of a firmware string is therefore
16 (commands) * 2 (bytes per command) * 2 (characters per byte) = 64
Fixes: ff45262a85db ("leds: add new LP5562 LED driver")
Signed-off-by: Nick Stoughton <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence create a new label, err_node_put, that puts
the previous node before returning the required value. Edit the mid-loop
return sites to instead go to this new label.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|
|
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak.
Hence create a new label, err_node_put, which puts the previous node and
returns variable rv. Modify the mid-loop return statements to instead
store the return value in rv and jump to err_node_put.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <[email protected]>
Reviewed-by: Dan Murphy <[email protected]>
Acked-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
|