summaryrefslogtreecommitdiff
path: root/drivers/leds/leds-lp55xx-common.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* leds: leds-lp55xx: Convert mutex lock/unlock to guard APIChristian Marangi2024-07-111-55/+40
| | | | | | | | | | | Convert any entry of mutex lock/unlock to guard API and simplify code. With the use of guard API, handling for selttest functions can be greatly simplified. Suggested-by: Markus Elfring <Markus.Elfring@web.de> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626221520.2846-3-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Support ENGINE program up to 128 bytesChristian Marangi2024-06-261-12/+42
| | | | | | | | | | | | | Some LED chip supports up to 16 pages and with some magic they can be divided in 4 page for each ENGINE + 1 for each MUX. Following this we can support bigger programs up to 128 bytes. Rework the update_program_memory function to support program of multiple pages instead of hardcoding it to one page per programs. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-19-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize sysfs master_faderChristian Marangi2024-06-261-0/+113
| | | | | | | | | | Generalize sysfs master_fader since their implementation is the same across some lp55xx based LED driver. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-18-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize sysfs engine_ledsChristian Marangi2024-06-261-0/+109
| | | | | | | | | | | | Generalize sysfs engine_leds since their implementation is the same across some lp55xx based LED driver. While at it simplify the implementation for show_engine_leds. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-17-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize sysfs engine_load and engine_modeChristian Marangi2024-06-261-6/+77
| | | | | | | | | | Generalize sysfs engine_load and engine_mode since their implementation is the same acrosso some lp55xx based LED driver. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-16-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize stop_engine functionChristian Marangi2024-06-261-0/+13
| | | | | | | | | | Generalize stop_engine function as the implementation is the same for most of the lp55xx based LED driver. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-15-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize turn_off_channels functionChristian Marangi2024-06-261-0/+10
| | | | | | | | | | Generalize turn_off_channels function as the implementation is the same for most of the lp55xx based LED driver. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-14-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize set_led_current functionChristian Marangi2024-06-261-0/+11
| | | | | | | | | | Generalize set_led_current function as the implementation is the same for most of the lp55xx based LED driver. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-13-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize multicolor_brightness functionChristian Marangi2024-06-261-0/+21
| | | | | | | | | | Generalize multicolor_brightness function as the implementation is the same for most of the lp55xx based LED driver. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-12-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize led_brightness functionChristian Marangi2024-06-261-0/+14
| | | | | | | | | | | | | Generalize led_brightness function as the implementation is the same for most of the lp55xx based LED driver. Introduce a new option in device_config, reg_led_pwm_base since the reg value is not the same for every LED chip. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-11-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize firmware_loaded functionChristian Marangi2024-06-261-0/+25
| | | | | | | | | | Generalize firmware_loaded function as lp55xx based LED driver all share the same logic. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-10-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize update_program_memory functionChristian Marangi2024-06-261-0/+57
| | | | | | | | | | | | | | | | | | | | LED Driver based on lp55xx all use the same logic to write memory in SMEM. The only difference is that legacy chip doesn't support pages and have the engine regs one after another. To handle this apply the same logic used for load_engine also for update_program_memory. Introduce a new config in device_config, base_prog. For LED chip that doesn't support pages, offset this values of 32 for each engine. Update all lp55xx based LED driver to use this new function and define all the required bits. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-9-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize run_engine functionChristian Marangi2024-06-261-0/+43
| | | | | | | | | | | | | | | Generalize run_engine function for lp55xx based LED driver. The logic is similar to every LED driver, rework it with more macro magic and account for LED model that might have OP MODE and EXEC at base offset in the reg. Update any lp55xx based LED driver to use this generalized function and declare required bits. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-8-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize load_engine_and_select_page functionChristian Marangi2024-06-261-0/+10
| | | | | | | | | | | | | | | | | | | | Generalize load_engine_and_select_page by reworking the implementation and making it part of the generic load_engine function. Add a new option in device_config, pages_per_engine used to define pages assigned to each engine. With this option set, it's assumed LED chip supports pages and load_engine will correctly setup the write page. An equal amount of pages is assigned to each engine and they are assigned from page 0. Update any lp55xx based LED driver to define the option and use the new function. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-7-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize load_engine functionChristian Marangi2024-06-261-1/+32
| | | | | | | | | | | | | | LED driver based on lp55xx have all a very similar implementation for load_engine function. Move the function to lp55xx-common and rework the define to be more dynamic instead of having to declare a temp array for them. Engine mask are the same for every LED based on lp55xx. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-6-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize probe/remove functionsChristian Marangi2024-06-261-36/+105
| | | | | | | | | | | | | | | | | | | Now that stop_all_engine is generalized, probe and remove function are the same across every lp55xx based LED driver and can be generalized. To permit to use a common probe, make use of the OF match_data and i2c driver_data value to store the device_config struct specific for the LED. Also drop the now unused exported symbol in lp55xx-common and make them static. Update any lp55xx based LED driver to use the new generic probe/remove. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-5-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: leds-lp55xx: Generalize stop_all_engine OPChristian Marangi2024-06-261-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In all the lp55xx based driver, we have a similar implementation of the stop_all_engine function with the only difference of the required sleep for the OP MODE change. The main difference is legacy LEDs require a min of 152 us while new one use a generic 1-2ms. The new one use a 1-2ms sleep as suggested in the datasheet IN ALTERNATIVE to a much more robust approach by using the newly introduced ENGINE_BUSY bit in the STATUS reg. To better handle sleep after OP MODE change, add support for polling the ENGINE_BUSY bit and use the legacy sleep for old LEDs. With this change, stop_all_engine can be generalized and moved to lp55xx-common. To make more clear the double usage of lp55xx_reg, define a union for additional scope of mask and shift. Update all lp55xx based driver to use the new generalized function and define the required bits in the device_config struct. Suggested-by: Lee Jones <lee@kernel.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-4-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: lp55xx: Use gpiod_set_value_cansleep()Stefan Eichenberger2023-11-011-2/+2
| | | | | | | | | | | | Use gpiod_set_value_cansleep in the init_device function. Without this change, the driver may print a warning if the LP55xx enable pin is connected to a GPIO chip which can sleep (e.g. a GPIO expander): WARNING: CPU: 0 PID: 2719 at drivers/gpio/gpiolib.c:3051 gpiod_set_value+0x64/0xbc Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Link: https://lore.kernel.org/r/20230918143238.75600-1-eichest@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: lp55xx: Configure internal charge pumpMaarten Zanders2023-05-251-0/+9
| | | | | | | | | | | | | | | | | The LP55xx range of devices have an internal charge pump which can (automatically) increase the output voltage towards the LED's, boosting the output voltage to 4.5V. Implement this option from the devicetree. When the setting is not present it will operate in automatic mode as before. Tested on LP55231. Datasheet analysis shows that LP5521, LP5523 and LP8501 are identical in topology and are modified in the same way. Signed-off-by: Maarten Zanders <maarten.zanders@mind.be> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230421075305.37597-3-maarten.zanders@mind.be
* leds: use sysfs_emit() to instead of scnprintf()ye xingchen2022-12-071-2/+2
| | | | | | | Replace the open-code with sysfs_emit() to simplify the code. Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: lp55xx: remove variable jColin Ian King2022-10-211-2/+1
| | | | | | | | The variable j being incremented but it is never referenced, it is redundant and can be removed. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: lp55xx: initialise output direction from dtsMerlijn Wajer2022-01-121-1/+3
| | | | | | | | | | | | | | | Commit a5d3d1adc95f ("leds: lp55xx: Initialize enable GPIO direction to output") attempts to fix this, but the fix did not work since at least for the Nokia N900 the value needs to be set to HIGH, per the device tree. So rather than hardcoding the value to a potentially invalid value for some devices, let's set direction in lp55xx_init_device. Fixes: a5d3d1adc95f ("leds: lp55xx: Initialize enable GPIO direction to output") Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") Fixes: ac219bf3c9bd ("leds: lp55xx: Convert to use GPIO descriptors") Signed-off-by: Merlijn Wajer <merlijn@wizzup.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: lp55xx: Initialize enable GPIO direction to outputDoug Zobel2021-06-231-1/+1
| | | | | | | | | | | The "Convert to use GPIO descriptors" commit changed the initialization of the enable GPIO from GPIOF_DIR_OUT to GPIOD_ASIS. This breaks systems where the GPIO does not default to output. Changing the enable initialization to GPIOD_OUT_LOW. Signed-off-by: Doug Zobel <dougdev334@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: various: fix OF node leaksMarek Behún2020-09-261-2/+6
| | | | | | | | | | | | 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
* leds: various: use only available OF childrenMarek Behún2020-09-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* leds: add RGB color option, as that is different from multicolor.Pavel Machek2020-08-031-1/+1
| | | | | | | | | | | | | | 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: Add multicolor framework support to lp55xxDan Murphy2020-07-221-22/+155
| | | | | | | | | 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>
* leds: lp55xx: Convert LED class registration to devm_*Dan Murphy2020-07-221-14/+1
| | | | | | | | | | 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>
* leds: lp55xx: Fix file permissions to use DEVICE_ATTR macrosDan Murphy2020-07-151-12/+10
| | | | | | | | | | | | | | | 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>
* leds: lp55xx: Convert to use GPIO descriptorsLinus Walleij2020-07-121-16/+11
| | | | | | | | | | | | | | 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>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner2019-06-191-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* leds: lp55xx: fix null deref on firmware load failureMichal Kazior2019-02-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | I've stumbled upon a kernel crash and the logs pointed me towards the lp5562 driver: > <4>[306013.841294] lp5562 0-0030: Direct firmware load for lp5562 failed with error -2 > <4>[306013.894990] lp5562 0-0030: Falling back to user helper > ... > <3>[306073.924886] lp5562 0-0030: firmware request failed > <1>[306073.939456] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > <4>[306074.251011] PC is at _raw_spin_lock+0x1c/0x58 > <4>[306074.255539] LR is at release_firmware+0x6c/0x138 > ... After taking a look I noticed firmware_release() could be called with either NULL or a dangling pointer. Fixes: 10c06d178df11 ("leds-lp55xx: support firmware interface") Signed-off-by: Michal Kazior <michal@plume.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* treewide: devm_kzalloc() -> devm_kcalloc()Kees Cook2018-06-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The devm_kzalloc() function has a 2-factor argument form, devm_kcalloc(). This patch replaces cases of: devm_kzalloc(handle, a * b, gfp) with: devm_kcalloc(handle, a * b, gfp) as well as handling cases of: devm_kzalloc(handle, a * b * c, gfp) with: devm_kzalloc(handle, array3_size(a, b, c), gfp) as it's slightly less ugly than: devm_kcalloc(handle, array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: devm_kzalloc(handle, 4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. Some manual whitespace fixes were needed in this patch, as Coccinelle really liked to write "=devm_kcalloc..." instead of "= devm_kcalloc...". The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ expression HANDLE; type TYPE; expression THING, E; @@ ( devm_kzalloc(HANDLE, - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | devm_kzalloc(HANDLE, - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression HANDLE; expression COUNT; typedef u8; typedef __u8; @@ ( devm_kzalloc(HANDLE, - sizeof(u8) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(__u8) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(char) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(unsigned char) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(u8) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(__u8) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(char) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ expression HANDLE; type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ expression HANDLE; identifier SIZE, COUNT; @@ - devm_kzalloc + devm_kcalloc (HANDLE, - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression HANDLE; expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( devm_kzalloc(HANDLE, - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression HANDLE; expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ expression HANDLE; identifier STRIDE, SIZE, COUNT; @@ ( devm_kzalloc(HANDLE, - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression HANDLE; expression E1, E2, E3; constant C1, C2, C3; @@ ( devm_kzalloc(HANDLE, C1 * C2 * C3, ...) | devm_kzalloc(HANDLE, - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression HANDLE; expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( devm_kzalloc(HANDLE, sizeof(THING) * C2, ...) | devm_kzalloc(HANDLE, sizeof(TYPE) * C2, ...) | devm_kzalloc(HANDLE, C1 * C2 * C3, ...) | devm_kzalloc(HANDLE, C1 * C2, ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - (E1) * E2 + E1, E2 , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - (E1) * (E2) + E1, E2 , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - E1 * E2 + E1, E2 , ...) ) Signed-off-by: Kees Cook <keescook@chromium.org>
* leds: lp55xx: Remove work queueAndrew Lunn2016-01-041-7/+5
| | | | | | | | | Now the core implements the work queue, remove it from the drivers, and switch to using brightness_set_blocking op. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Cc: Milo Kim <milo.kim@ti.com>
* leds:lp55xx: use the private data instead of updating I2C device platform dataMilo Kim2015-08-281-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, lp55xx_of_populate_pdata() allocates lp55xx_platform_data if it's null. And it parses the DT and copies values into the 'client->dev.platform_data'. This may have architectural issue. Platform data is configurable through the DT or I2C board info inside the platform area. However, lp55xx common driver changes this configuration when it is loaded. So 'client->dev.platform_data' is not null anymore. Eventually, the driver initialization is not identical when it's unloaded and loaded again. The lp55xx common driver should use the private data, 'lp55xx_chip->pdata' instead of changing the original platform data. So, lp55xx_of_populate_pdata() is modified as follows. * Do not update 'dev->platform_data'. Return the pointer of new allocated lp55xx_platform_data. Then the driver points it to private data, 'lp55xx_chip->pdata'. * Each lp55xx driver checks the pointer and handles an error case. Then, original platform data configuration will be kept regardless of loading or unloading the driver. The driver allocates the memory and copies them from the DT if it's NULL. After the driver is loaded again, 'client->dev.platform_data' is same as initial load, so the driver is initialized identically. Cc: Toshi Kikuchi <toshik@chromium.org> Cc: linux-leds@vger.kernel.org Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds:lp55xx: fix firmware loading errorMilo Kim2015-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LP55xx driver uses not firmware file but raw data to load program through the firmware interface.(Documents/leds/leds-lp55xx.txt) For example, here is how to run blinking green channel pattern. (The second engine is seleted and MUX is mapped to 'RGB' mode) echo 2 > /sys/bus/i2c/devices/xxxx/select_engine echo "RGB" > /sys/bus/i2c/devices/xxxx/engine_mux echo 1 > /sys/class/firmware/lp5562/loading echo "4000600040FF6000" > /sys/class/firmware/lp5562/data echo 0 > /sys/class/firmware/lp5562/loading echo 1 > /sys/bus/i2c/devices/xxxx/run_engine However, '/sys/class/firmware/<device name>' is not created after the firmware loader user helper was introduced. This feature is used in the case below. As soon as the firmware download is requested by the driver, firmware class subsystem tries to find the binary file. If it gets failed, then it just falls back to user helper to load raw data manually. Here, you can see the device file under /sys/class/firmware/. To make it happen, LP55xx driver requires two configurations. 1. Enable CONFIG_FW_LOADER_USER_HELPER_FALLBACK in Kconfig 2. Set option, 'FW_OPT_USERHELPER' on requesting the firmware data. It means the second option should be 'false' in request_firmware_nowait(). This option enables to load firmware data manually by calling fw_load_from_user_helper(). Cc: linux-leds@vger.kernel.org Signed-off-by: Milo Kim <milo.kim@ti.com> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: lp55xx-common: fix attribute-creation raceJohan Hovold2014-06-271-19/+3
| | | | | | | | Use the attribute groups of the led-class to create the LED attributes during probe in order to avoid racing with userspace. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: lp55xx-common: fix sysfs entry leakJohan Hovold2014-06-271-0/+2
| | | | | | | Make sure the sysfs group is removed when the LEDs are unregistered. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: lp5523: Support LED MUX configuration on running a patternMilo Kim2014-01-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | There are two ways to run a pattern in LP5523. One is using legacy sysfs files such as 'enginex_mode','enginex_load' and 'enginex_leds'. ('x' is from 1 to 3). Among them, 'enginex_leds' are used for selecting specific LED channel MUX. (MUX means which LEDs are used for running a pattern from LED 1 to 9.) The other way is using the firmware interface. In this mode, the default LED MUX strings are used. In other words, LED MUX is not configurable on the fly. This patch enables dynamic LED MUX configuration when the firmware is loaded. By accessing the sysfs file 'enginex_leds', the LED channels can be configured. To synchronize the operation mode, each engine mode should be set to 'LOAD'. The documentation is updated as well. Cc: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: lp55xx: handle enable pin in driverSebastian Reichel2013-10-251-12/+13
| | | | | | | | | | | | | This patch moves the handling of the chip's enable pin from the board code into the driver. It also updates all board-code files using the driver to incorporate this change. This is needed for device tree support of the enable pin. Signed-off-by: Sebastian Reichel <sre@debian.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: lp55xx: enable setting default triggerLinus Walleij2013-10-221-0/+3
| | | | | | | | | | | | This enables setting a default trigger on an LP55xx channel, either from platform data or device tree. This mechanism is identical to the mechanism for GPIO LEDs and references the common LEDs device tree bindings. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Milo Kim <milo.kim@ti.com> Acked-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: support new LP8501 device - another LP55xx commonKim, Milo2013-08-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | LP8501 can drive up to 9 channels like LP5523. LEDs can be controlled directly via the I2C and programmable engines are supported. LP55xx common driver LP8501 is one of LP55xx family device, so LP55xx common code are used. Chip specific data is defined in the structure, 'lp55xx_device_config'. Differences between LP8501 and LP5523 Different register layout for LED output control and others. LP8501 specific feature for separate output power selection. LP8501 doesn't support external clock detection. Different programming engine data. LP8501 specific feature - output power selection Output channels are selected by power selection - Vout or Vdd. Separate power for VDD1-6 and VDD7-9 are available. It is configurable in the platform data. To support this feature, LP55xx DT structure and header are changed. Device tree binding is updated as well. LED pattern data Example pattern data is updated in the driver documentation. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: lp55xx: support dynamic channel settings in the device tree structureKim, Milo2013-06-201-35/+26
| | | | | | | | | | | | | | | | | | | Currently, the LP55xx DT structure supports max 3 channels. However, LP5523 has max 9 channels and LP5562 has 4 channels. To enhance this constraint, the DT structure has been changed. (a) Use the child node for various channel settings instead of fixed array (b) Remove 'num_channel' property. This value can be retrieved by counting the children node. (c) 'chan-name' property supported (d) Documentation updates for LP5521 and LP5523 (cooloney@gmail.com: fix a coding style issue in leds-lp55xx.txt) Cc: Gabriel Fernandez <gabriel.fernandez@stericsson.com> Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: lp55xx: add support for Device Tree bindingsLinus Walleij2013-06-201-0/+54
| | | | | | | | | | | | | This patch allows the lp5521 driver to be successfully probed and initialised when Device Tree support is enabled. Based on a patch by Gabriel Fernandez, rewritten in accordance with review feedback. Cc: Gabriel Fernandez <gabriel.fernandez@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: lp55xx: use common clock framework when external clock is usedKim, Milo2013-04-011-0/+36
| | | | | | | | | | | | | | | | Program execution is timed with 32768Hz clock in the LP55xx family devices. To run LED functionalities, LP55xx devices provide two options. One is using internal clock. The other is using external clock. This patch enables external clock detection automatically. If external clock is not detected, then the internal clock will be used in the LP55xx driver. Valid clock rate is 32768Hz in LP55xx devices. This new API is used in each LP55xx driver like LP5521 and LP5562. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: lp55xx: fix the sysfs read operationKim, Milo2013-04-011-2/+2
| | | | | | | | | According to a sysfs documentation(Documentation/filesystem/sysfs.txt), scnprintf() should be used in a read operation method. It guarantees safe buffer size(PAGE_SIZE) which is allocated by the sysfs. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: add new LP5562 LED driverKim, Milo2013-04-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LP5562 can drive up to 4 channels, RGB and White. LEDs can be controlled directly via the led class control interface. LP55xx common driver LP5562 is one of LP55xx family device, so LP55xx common code are used. On the other hand, chip specific configuration is defined in the structure 'lp55xx_device_config' LED pattern data LP5562 has also internal program memory which is used for running various LED patterns. LP5562 driver supports the firmware interface and the predefined pattern data as well. LP5562 device attributes: 'led_pattern' and 'engine_mux' A 'led_pattern' is an index code which runs the predefined pattern data. And 'engine_mux' is updated with the firmware interface is activated. Detailed description has been updated in the documentation files, 'leds-lp55xx.txt' and 'leds-lp5562.txt'. Changes on the header file LP5562 configurable definitions are added. Pattern RGB data is fixed as constant value. (No side effect on other devices, LP5521 or LP5523.) (cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan Carpenter <dan.carpenter@oracle.com>) Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds-lp55xx: fix problem on removing LED attributesMilo(Woogyom) Kim2013-02-061-3/+0
| | | | | | | | | | | LP55XX common device attributes, 'led_current' and 'max_current' are created while loading the driver. Those are LED device attributes which are removed automatically on releasing led class devices - led_classdev_unregister(). Therefore, this duplicate code should be removed. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds-lp55xx: add new function for removing device attribtuesMilo(Woogyom) Kim2013-02-061-0/+12
| | | | | | | | lp55xx_unregister_sysfs() is used for removing lp55xx device attributes. Chip specific and engine attributes are removed on unloading the driver. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds-lp55xx: support device specific attributesMilo(Woogyom) Kim2013-02-061-1/+12
| | | | | | | | | To support device specific attributes, new common driver function is added. Eventually those are created on registering the sysfs with common dev attrs. Furthermore, this patch makes adding device attributes simple in each driver. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-22 05:36:42 +0000