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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The driver depends on CONFIG_OF, so it is not necessary to use
of_match_ptr() here. We remove both CONFIG_OF and of_match_ptr() here.
Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
Link: https://lore.kernel.org/r/20230808111108.24262-1-wangzhu9@huawei.com
Signed-off-by: Lee Jones <lee@kernel.org>
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230517180559.166329-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
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
.probe_new() doesn't get the i2c_device_id * parameter, so determine
that explicitly in the probe function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20221118224540.619276-281-uwe@kleine-koenig.org
When not all LED channels of the led chip are configured, the
sysfs selftest functionality gives erroneous results and tries to
test all channels of the chip.
There is a potential for LED overcurrent conditions since the
test current will be set to values from out-of-bound regions.
It is wrong to use pdata->led_config[i].led_current to skip absent
channels as led_config[] only contains the configured LED channels.
Instead of iterating over all the physical channels of the device,
loop over the available LED configurations and use led->chan_nr to
access the correct i2c registers. Keep the zero-check for the LED
current as existing users might depend on this to disable a channel.
Reported-by: Arne Staessen <a.staessen@televic.com>
Signed-off-by: Maarten Zanders <maarten.zanders@mind.be>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The value returned by an i2c driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)
So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.
Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com>
Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/*
Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5
Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio
Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860
Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b
Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes
Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power
Acked-by: Krzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Check return value of lp5xx_read and if non-zero, jump to code at end of
the function, causing lp5523_stop_all_engines to be executed before
returning the error value up the call chain. This fixes the original
commit (248b57015f35) which was reverted due to the University of Minnesota
problems.
Cc: stable <stable@vger.kernel.org>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
Link: https://lore.kernel.org/r/20210503115736.2104747-10-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 248b57015f35c94d4eae2fdd8c6febf5cd703900.
Because of recent interactions with developers from @umn.edu, all
commits from them have been recently re-reviewed to ensure if they were
correct or not.
Upon review, this commit was found to be incorrect for the reasons
below, so it must be reverted. It will be fixed up "correctly" in a
later kernel change.
The original commit does not properly unwind if there is an error
condition so it needs to be reverted at this point in time.
Cc: Kangjie Lu <kjlu@umn.edu>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: stable <stable@vger.kernel.org>
Fixes: 248b57015f35 ("leds: lp5523: fix a missing check of return value of lp55xx_read")
Link: https://lore.kernel.org/r/20210503115736.2104747-9-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
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>
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>
Based on 1 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
distributed in the hope that it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details you should have received a copy of the gnu general
public license along with this program if not write to the free
software foundation inc 51 franklin st fifth floor boston ma 02110
1301 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 246 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190530000436.674189849@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When lp55xx_read() fails, "status" is an uninitialized variable and thus
may contain random value; using it leads to undefined behaviors.
The fix inserts a check for the return value of lp55xx_read: if it
fails, returns with its error code.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Trivial fix to spelling mistakes in 'lp5523_init_program_engine'.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Several arrays are currently on-stack and instead should be made
static const.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fix typos and add the following to the scripts/spelling.txt:
momery||memory
Link: http://lkml.kernel.org/r/20170317011131.6881-1-sboyd@codeaurora.org
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
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>
This patch introduces 4 new attributes:
master_fader_leds
master_fader1
master_fader2
master_fader3
Fo example, to map channel 0,6 to master_fader1,
map channel 1,7 to master_fader2,
map channel 2,8 to master_fader3, and
map channel 3,4,5 to none
echo "123000123" > master_fader_leds
A different factor can be set to each master_fader:
echo 255 > master_fader1
echo 100 > master_fader2
echo 0 > master_fader3
Signed-off-by: Toshi Kikuchi <toshik@chromium.org>
Acked-by: Milo Kim <milo.kim@ti.com>
Tested-by: Milo Kim <milo.kim@ti.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The TI55231 appears to be fully compatible to the 5523 model from
National Semicondutor. This patch just adds DT bindings for it.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>. Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Pull LED subsystem update from Bryan Wu:
"Basically this cycle is mostly cleanup for LED subsystem"
* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
leds: s3c24xx: Remove hardware.h inclusion
leds: replace list_for_each with list_for_each_entry
leds: kirkwood: Cleanup in header files
leds: pwm: Remove a warning on non-DT platforms
leds: leds-pwm: fix duty time overflow.
leds: leds-mc13783: Remove unneeded mc13xxx_{un}lock
leds: leds-mc13783: Remove duplicate field in platform data
drivers: leds: leds-tca6507: check CONFIG_GPIOLIB whether defined for 'gpio_base'
leds: lp5523: Support LED MUX configuration on running a pattern
leds: lp5521/5523: Fix multiple engine usage bug
LEDS: tca6507 - fix up some comments.
LEDS: tca6507: add device-tree support for GPIO configuration.
LEDS: tca6507 - fix bugs in parsing of device-tree configuration.
Whenever the engine is loaded by the user-application, the operation mode is
reset first. But it has a problem in case of multiple engine used because
previous engine settings are cleared.
The driver should update not whole 8bits but each engine bit by masking.
On the other hands, whole engines should be reset when the driver is unloaded
and on initializing the LP5523 driver.
So, new functions are used for this handling - lp5521/5523_stop_all_engines().
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>
Pull trivial tree updates from Jiri Kosina:
"Usual rocket science stuff from trivial.git"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
neighbour.h: fix comment
sched: Fix warning on make htmldocs caused by wait.h
slab: struct kmem_cache is protected by slab_mutex
doc: Fix typo in USB Gadget Documentation
of/Kconfig: Spelling s/one/once/
mkregtable: Fix sscanf handling
lp5523, lp8501: comment improvements
thermal: rcar: comment spelling
treewide: fix comments and printk msgs
IXP4xx: remove '1 &&' from a condition check in ixp4xx_restart()
Documentation: update /proc/uptime field description
Documentation: Fix size parameter for snprintf
arm: fix comment header and macro name
asm-generic: uaccess: Spelling s/a ny/any/
mtd: onenand: fix comment header
doc: driver-model/platform.txt: fix a typo
drivers: fix typo in DEVTMPFS_MOUNT Kconfig help text
doc: Fix typo (acces_process_vm -> access_process_vm)
treewide: Fix typos in printk
drivers/gpu/drm/qxl/Kconfig: reformat the help text
...
It can be a problem when a pattern is loaded via the firmware interface.
LP55xx common driver has already locked the mutex in 'lp55xx_firmware_loaded()'.
So it should be deleted.
On the other hand, locks are required in store_engine_load()
on updating program memory.
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Cc: <stable@vger.kernel.org>
Add some comments that are not obvious from first look at the driver
to lp5523, fix typo in lp8501.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
'of_match_ptr' is defined in linux/of.h. Include it explicitly.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch reduces the number of programming commands.
(Count of sending commands)
Old code: 32 + program size (32 counts for clearing program memory)
New code: 32
Pattern buffer is initialized to 0 in this function.
Just update new program data and remaining buffers are filled with 0.
So it's needless to clear whole area.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>