Update the license header to the current
SPDX licensing format.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Variable mode is assigned to pdata->led_pdata->mode[led->id] and yet
is not being used when calling function max8997_led_set_mode. Fix
this by using mode when calling max8997_led_set_mode.
Cleans up clang warning:
warning: variable 'mode' set but not used [-Wunused-but-set-variable]
Fixes: 8584cb82f1 ("leds: Add suuport for MAX8997-LED driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Update the email address in the module information and in the comments
and in the module information, and drop the existing boilerplate in
favor of a SPDX header.
Also sync the module license information with the header.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The binding details are described in an earlier commit that adds the
documentation.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Clean up the code a bit and transition over to the gpiod based interface.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
In preparation to DT probe functionality, merge create_lt3593_led() into
its only call-site. The DT based setup code will be quite different, so this
internal helper function is of no help.
This also changes the way the driver works by only handling one entry inside
'struct gpio_led_platform_data'. If multiple devices of the same type are
found in a design, there should be a platform device for each of them. The
only mainline user of this driver is not affected by this change.
Last, use devm_led_classdev_register() instead of
led_classdev_register(), so the driver's remove callback can go away.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
All the triggers are defined in a big if LEDS_TRIGGERS...endif block.
So there is no need to let each driver depend on LEDS_TRIGGERS explicitly
once more.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
PC Engines apu3 is an improved version of the apu2, using the same SoC
and almost everything else.
This patch reuses as much as possible from the apu2 definitions, to
avoid redundancy.
Signed-off-by: Raffaello D. Di Napoli <rafdev@dinapo.li>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
get_monotonic_boottime() is deprecated, so let's convert this to
the simpler ktime_get_boot_ns().
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED driver can be configured with a strobe
timer to execute a strobe flash. The IR LED
brightness is controlled via the torch brightness
register.
The data sheet for each the LM36010 and LM36011
LED drivers can be found here:
http://www.ti.com/product/LM36010http://www.ti.com/product/LM36011
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
In case of error, the function dev_get_regmap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Fixes: e081c49e30 ("leds: Add Spreadtrum SC27xx breathing light controller driver")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
This patch adds Spreadtrum SC27xx PMIC series breathing light controller
driver, which can support 3 LEDs. Each LED can work at normal PWM mode
and breathing mode.
Signed-off-by: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Use sysfs_match_string() helper instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
This patch adds a LED class driver for the RGB LEDs found on
the Crane Merchandising System CR0014114 LEDs board.
Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
BIOS on APU board doesn't expose board_name property, and thus
we have to rely on the product_name instead.
Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
This adds two new disk triggers for triggering on reads
and writes respectively, named "disk-read" and "disk-write".
The use case comes from working on the D-Link DNS-313 NAS
box. This features an RGB LED for disk activity. with
these two triggers I can couple the green LED to read
activity and the red LED to write activity, which gives
the appropriate user feedback about what is happening
on the disk. When tested it gave exactly the feedback
desired.
The in-kernel interface is simply changed to pass a bool
indicating if the activity is write activity and update
each trigger (and the composite "disk-activity" trigger)
depending on what is passed in.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
PC Engines "legacy" coreboot 4.0.8 changed the product/board name
from "APU2" to "apu2".
PC Engines "mainline" coreboot uses, instead, "PC Engines apu2" as
product/board name.
This commit adds the 2 variants ("apu2" and "PC Engines apu2") of
product/board name to be compatible with all the APU2 BIOSes.
Fixes: 3faee9423c ("leds: Add driver for PC Engines APU/APU2 LEDs")
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Driver obtains LED devices according to system configuration and creates
devices in form: "devicename:color:function", like
The full path is to be:
/sys/class/leds/mlxreg\:status\:amber/brightness
After timer trigger activation:
echo timer > /sys/class/leds/mlxreg\:status\:amber/trigger
Attributes for LED blinking will appaer in sysfs infrastructure:
/sys/class/leds/mlxreg\:status\:amber/delay_off
/sys/class/leds/mlxreg\:status\:amber/delay_on
LED setting is controlled through the on-board programmable devices,
which exports its register map. This device could be attached to any
bus type, for which register mapping is supported.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
It fixes grammatical errors in Kconfig file for LEDS_SYSCON,
LEDS_MLXCPLD, LEDS_MC13783, LEDS_NETXBIG.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Clarify which controllers are supported by which driver.
Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
It makes leds-mlxcpld available for 32 bit architecture.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reported-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:
for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
done
with de-mangling cleanups yet to come.
NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do. But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.
The next patch from Al will sort out the final differences, and we
should be all done.
Scripted-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJab5E9AAoJEL1qUBy3i3wmzKMP/jnbwjCGSfxNHysbVBzAEBsz
ceNOsn+1BVu1iLDblUam6rACnKLGNsM+zgMvnHpzAyzSKK9FC2vTqgig2UT4h1Fy
8NcilKTSyNNEkOm7hcuLEWcS//B6fZOvevei6if9cXNic9/t+jI58qFGe03PJk/e
ryx5c0qMrePafMeu1OotzzhR312Pls2VqxAjH7yqHLRkB1lRHne9smya+L1jUuhL
Hn6CilkMbb6FGuCz+3C1fixcrRcezyNPb9VKrISwQDGz9gRuU772eyfbshNYeGAe
KBCn/VuEUX0xoGMdmzKkADjv8ztohqQ59OVluTQirP/gzHgYAUOVhnJM4nQhmTvF
4Txzu1NySQW8CFAiPDz4CUswmi3VWKBSqOs8KH64B95V/0QEz4Blu/EO6wzPwS6U
wGLVtdVM3gWg6V1BLJ4w6o0dCAtBwvfBgvPoe9DvdUiffg0rYdL3g1WgjW/18Stn
ZekWzysSfHY6Ayll/yGrnkTvrtu5+dWjxTnhuijfkcLhNXXy0M2s6iODkxjf4VU8
qmUSWaBcIpUeJclaJyVKwpBDB8oFkz1Qsbap0ctnIPD1355g2zaoUOJKe/WF+Ob4
SgMYI+zZLMWjoX8aCTRmSJO2hur+jiML4zov3Qh+29GMCnAKrieFavhxJ6h1JrrL
d7vhnoQfMZzCAoJ2HNLK
=TqNv
-----END PGP SIGNATURE-----
Merge tag 'leds_for_4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
Pull LED updates from Jacek Anaszewski:
"New LED class driver:
- introduce LM3692x dual string driver
New LED trigger:
- introduce a NETDEV trigger
leds-lp8860:
- various fixes to align with LED framework
- add regulator enable during init
- DT support related improvements
Minor fixes and cleanups to the LED class drivers:
- leds-pwm
- ledtrig-activity
- leds-blinkm
- leds-as3645a
- ledtrig-transient"
* tag 'leds_for_4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
leds: ledtrig-transient: Add SPDX license identifiers
leds: lp8860: Various fixes to align with LED framework
leds: lp8860: Add DT parsing to retrieve the trigger node
dt: bindings: lp8860: Add trigger binding to the lp8860
leds: lp8860: Update the dt parsing for LED labeling
dt: bindings: lp8860: Update DT label binding
dt: bindings: lp8860: Update bindings for lp8860
leds: as3645a: Fix line over 80 characters
leds: as3645a: Fix quoted string split warning
leds: lm3692x: Introduce LM3692x dual string driver
dt: bindings: lm3692x: Add bindings for lm3692x LED driver
leds: trigger: Introduce a NETDEV trigger
leds: blinkm: avoid uninitialized data use
ledtrig-activity: Grammar s/a immediate/an immediate/
leds: pwm: Remove unneeded header file
leds: lp8860: Add regulator enable during init
leds: lp8860: Fix linuxdoc format for structure
Pull poll annotations from Al Viro:
"This introduces a __bitwise type for POLL### bitmap, and propagates
the annotations through the tree. Most of that stuff is as simple as
'make ->poll() instances return __poll_t and do the same to local
variables used to hold the future return value'.
Some of the obvious brainos found in process are fixed (e.g. POLLIN
misspelled as POLL_IN). At that point the amount of sparse warnings is
low and most of them are for genuine bugs - e.g. ->poll() instance
deciding to return -EINVAL instead of a bitmap. I hadn't touched those
in this series - it's large enough as it is.
Another problem it has caught was eventpoll() ABI mess; select.c and
eventpoll.c assumed that corresponding POLL### and EPOLL### were
equal. That's true for some, but not all of them - EPOLL### are
arch-independent, but POLL### are not.
The last commit in this series separates userland POLL### values from
the (now arch-independent) kernel-side ones, converting between them
in the few places where they are copied to/from userland. AFAICS, this
is the least disruptive fix preserving poll(2) ABI and making epoll()
work on all architectures.
As it is, it's simply broken on sparc - try to give it EPOLLWRNORM and
it will trigger only on what would've triggered EPOLLWRBAND on other
architectures. EPOLLWRBAND and EPOLLRDHUP, OTOH, are never triggered
at all on sparc. With this patch they should work consistently on all
architectures"
* 'misc.poll' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (37 commits)
make kernel-side POLL... arch-independent
eventpoll: no need to mask the result of epi_item_poll() again
eventpoll: constify struct epoll_event pointers
debugging printk in sg_poll() uses %x to print POLL... bitmap
annotate poll(2) guts
9p: untangle ->poll() mess
->si_band gets POLL... bitmap stored into a user-visible long field
ring_buffer_poll_wait() return value used as return value of ->poll()
the rest of drivers/*: annotate ->poll() instances
media: annotate ->poll() instances
fs: annotate ->poll() instances
ipc, kernel, mm: annotate ->poll() instances
net: annotate ->poll() instances
apparmor: annotate ->poll() instances
tomoyo: annotate ->poll() instances
sound: annotate ->poll() instances
acpi: annotate ->poll() instances
crypto: annotate ->poll() instances
block: annotate ->poll() instances
x86: annotate ->poll() instances
...
Replace GPL license statements with SPDX GPL-2.0 license identifiers
and correct the module license to GPLv2.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Update the driver to conform with the LED framework:
- use devm_led_classdev_register
- destroy mutex on exit
- remove dependency on CONFIG_OF in the driver and move
to the Kconfig
- update the MODULE_LICENSE to GPL v2
- remove setting of MAX brightness as the LED framework
does this.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Add the ability to parse the DT and set the default
trigger mode for the LED.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Update the DT parsing for the label node so that
the label is retrieved from the device child as
opposed to being part of the parent.
This will align this driver with the LED
binding documentation
Documentation/devicetree/bindings/leds/common.txt
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fix the warning for line over 80 characters.
WARNING: line over 80 characters
363: FILE: drivers/leds/leds-as3645a.c:363:
flash->flash_current = as3645a_current_to_reg(flash, true, brightness_ua);
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Introducing the LM3692x Dual-String white LED driver.
Data sheet is located
http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
This commit introduces a NETDEV trigger for named device
activity. Available triggers are link, rx, and tx.
Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
gcc-8 reports missing error handling in blinkm_detect, when blinkm()
fails, tmpargs[] is uninitialized:
drivers/leds/leds-blinkm.c: In function 'blinkm_detect':
drivers/leds/leds-blinkm.c:555:6: error: 'tmpargs' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This adds a missing error checks.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fixes: 7df4f9a9f0 ("leds: ledtrig-activity: Add a system activity LED trigger")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
There is nothing provided by <linux/fb.h> that is used here,
so remove this unneeded header file.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Add the regulator enable call during initialization.
If init fails then disable the regulator.
Also during init the gpio gets set low even
on a passing case so add if everything passes
then return.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fix the linuxdoc format defining the lp8860 structure.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Commit 2b83ff96f5 ("led: core: Fix brightness setting when setting delay_off=0")
replaced del_timer_sync(&led_cdev->blink_timer) with led_stop_software_blink()
in led_blink_set(), which additionally clears LED_BLINK_SW flag as well as
zeroes blink_delay_on and blink_delay_off properties of the struct led_classdev.
Cleansing of the latter ones wasn't required to fix the original issue but
wasn't considered harmful. It nonetheless turned out to be so in case when
pointer to one or both props is passed to led_blink_set() like in the
ledtrig-timer.c. In such cases zeroes are passed later in delay_on and/or
delay_off arguments to led_blink_setup(), which results either in stopping
the software blinking or setting blinking frequency always to 1Hz.
Avoid using led_stop_software_blink() and add a single call required
to clear LED_BLINK_SW flag, which was the only needed modification to
fix the original issue.
Fixes 2b83ff96f5 ("led: core: Fix brightness setting when setting delay_off=0")
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
With the current code, the following sequence won't work :
echo timer > trigger
echo 0 > delay_off
* at this point we call
** led_delay_off_store
** led_blink_set
*** stop timer
** led_blink_setup
** led_set_software_blink
*** if !delay_on, led off
*** if !delay_off, set led_set_brightness_nosleep <--- LED_BLINK_SW is set but timer is stop
*** otherwise start timer/set LED_BLINK_SW flag
echo xxx > brightness
* led_set_brightness
** if LED_BLINK_SW
*** if brightness=0, led off
*** else apply brightness if next timer <--- timer is stop, and will never apply new setting
** otherwise set led_set_brightness_nosleep
To fix that, when we delete the timer, we should clear LED_BLINK_SW.
Cc: linux-leds@vger.kernel.org
Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The pointer returned by of_device_get_match_data() doesn't have the same
size as u32 on 64-bit architectures, causing a compile warning when
compile-testing the driver on such platform.
Cast the return value of of_device_get_match_data() to unsigned long and
then to u32 to silence this warning.
Fixes: 7f866986e7 ("leds: add PM8058 LEDs driver")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJaC1RFAAoJEL1qUBy3i3wm2+sP/0vzsOFyu57V9Af4f7VCRrml
fZfk83u+/pCafnRrC7ttnNkrZplQ2t675Plpfr6cs8iIFU91IwLw83MeuVkr8wCB
3Cm+VElq/RBke36ZUaJGvrathSVmhmYc/cZk2rCfiozlOSUbByy/RGJJKmvV5ydA
sdVS4V7WtcZrDgiJtCY9ci5/OUpjl+BuAh9m4b2n3+fnhSRJTnMR2Xz35HLNOO/c
TE8AJtedehjiiy3zYv9QHy5EQJ1OJVTVN4lhhsKhYb5FfWvNdwWrkLeT6uSFWZ0l
UTx/cvTb0CxYUijr2RgutkQ1hW/+/VumcW1HK0st+Nj1ODuZ2u6VQ0NkTAjCRBPP
v/QZo2t4UrVfymjR1e67oW1c7ljEy3DVpIU2IfJA27c9OfGoAOlH653C7WVZFjyc
IBSbalMnpwINxX3fDlavl92P1iGEL0x9711dY/SUqxMA1qmejxHERR0jJB1EdY2I
6I4APnXSOGQBjgPH3AIFcqMYcmTV6NucQsS48OPY5WGt+BzDxJL7XC3Xh3hdRNPt
c/pv2x2YOWjnpYUjGJnCcmilrIbTUyahhLIS+zuvykHpo5rYt1jmpPYqTEZibWJy
iINAaOnxELkRGXJP4CX1QG/t64pazLuC3d/WF5GA3+AMIUpzNrmhDrRBySEsSQez
1aquAvFavNywtLZ43bVv
=T2rn
-----END PGP SIGNATURE-----
Merge tag 'leds_for_4.15rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
Pull LED updates from Jacek Anaszewski:
"New LED class driver:
- add a driver for PC Engines APU/APU2 LEDs
New LED trigger:
- add a system activity LED trigger
LED core improvements:
- replace flags bit shift with BIT() macros
Convert timers to use timer_setup() in:
- led-core
- ledtrig-activity
- ledtrig-heartbeat
- ledtrig-transient
LED class drivers fixes:
- lp55xx: fix spelling mistake: 'cound' -> 'could'
- tca6507: Remove unnecessary reg check
- pca955x: Don't invert requested value in pca955x_gpio_set_value()
LED documentation improvements:
- update 00-INDEX file"
* tag 'leds_for_4.15rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
leds: Add driver for PC Engines APU/APU2 LEDs
leds: lp55xx: fix spelling mistake: 'cound' -> 'could'
leds: Convert timers to use timer_setup()
Documentation: leds: Update 00-INDEX file
leds: tca6507: Remove unnecessary reg check
leds: ledtrig-heartbeat: Convert timers to use timer_setup()
leds: Replace flags bit shift with BIT() macros
leds: pca955x: Don't invert requested value in pca955x_gpio_set_value()
leds: ledtrig-activity: Add a system activity LED trigger
This patch implements the driver to support the front panel LEDs
for PC Engines APU and APU2 boards.
Signed-off-by: Alan Mizrahi <alan@mizrahi.com.ve>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Willy Tarreau <w@1wt.eu>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Variable reg is unsigned so checking whether it is less than zero is not
necessary.
Signed-off-by: Christos Gkekas <chris.gekas@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Instead of using .data directly, convert to from_timer. Since the
trigger_data is allocated separately, the led_cdev must be explicitly
tracked for the callback.
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Zhang Bo <bo.zhang@nxp.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: linux-leds@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The PCA9552 lines can be used either for driving LEDs or as GPIOs. The
manual states that for LEDs, the operation is open-drain:
The LSn LED select registers determine the source of the LED data.
00 = output is set LOW (LED on)
01 = output is set high-impedance (LED off; default)
10 = output blinks at PWM0 rate
11 = output blinks at PWM1 rate
For GPIOs it suggests a pull-up so that the open-case drives the line
high:
For use as output, connect external pull-up resistor to the pin
and size it according to the DC recommended operating
characteristics. LED output pin is HIGH when the output is
programmed as high-impedance, and LOW when the output is
programmed LOW through the ‘LED selector’ register. The output
can be pulse-width controlled when PWM0 or PWM1 are used.
Now, I have a hardware design that uses the LED controller to control
LEDs. However, for $reasons, we're using the leds-gpio driver to drive
the them. The reasons are here are a tangent but lead to the discovery
of the inversion, which manifested as the LEDs being set to full
brightness at boot when we expected them to be off.
As we're driving the LEDs through leds-gpio, this means wending our way
through the gpiochip abstractions. So with that in mind we need to
describe an active-low GPIO configuration to drive the LEDs as though
they were GPIOs.
The set() gpiochip callback in leds-pca955x does the following:
...
if (val)
pca955x_led_set(&led->led_cdev, LED_FULL);
else
pca955x_led_set(&led->led_cdev, LED_OFF);
...
Where LED_FULL = 255. pca955x_led_set() in turn does:
...
switch (value) {
case LED_FULL:
ls = pca955x_ledsel(ls, ls_led, PCA955X_LS_LED_ON);
break;
...
Where PCA955X_LS_LED_ON is defined as:
#define PCA955X_LS_LED_ON 0x0 /* Output LOW */
So here we have some type confusion: We've crossed domains from GPIO
behaviour to LED behaviour without accounting for possible inversions
in the process.
Stepping back to leds-gpio for a moment, during probe() we call
create_gpio_led(), which eventually executes:
if (template->default_state == LEDS_GPIO_DEFSTATE_KEEP) {
state = gpiod_get_value_cansleep(led_dat->gpiod);
if (state < 0)
return state;
} else {
state = (template->default_state == LEDS_GPIO_DEFSTATE_ON);
}
...
ret = gpiod_direction_output(led_dat->gpiod, state);
In the devicetree the GPIO is annotated as active-low, and
gpiod_get_value_cansleep() handles this for us:
int gpiod_get_value_cansleep(const struct gpio_desc *desc)
{
int value;
might_sleep_if(extra_checks);
VALIDATE_DESC(desc);
value = _gpiod_get_raw_value(desc);
if (value < 0)
return value;
if (test_bit(FLAG_ACTIVE_LOW, &desc->flags))
value = !value;
return value;
}
_gpiod_get_raw_value() in turn calls through the get() callback for the
gpiochip implementation, so returning to our get() implementation in
leds-pca955x we find we extract the raw value from hardware:
static int pca955x_gpio_get_value(struct gpio_chip *gc, unsigned int offset)
{
struct pca955x *pca955x = gpiochip_get_data(gc);
struct pca955x_led *led = &pca955x->leds[offset];
u8 reg = pca955x_read_input(pca955x->client, led->led_num / 8);
return !!(reg & (1 << (led->led_num % 8)));
}
This behaviour is not symmetric with that of set(), where the val is
inverted by the driver.
Closing the loop on the GPIO_ACTIVE_LOW inversions,
gpiod_direction_output(), like gpiod_get_value_cansleep(), handles it
for us:
int gpiod_direction_output(struct gpio_desc *desc, int value)
{
VALIDATE_DESC(desc);
if (test_bit(FLAG_ACTIVE_LOW, &desc->flags))
value = !value;
else
value = !!value;
return _gpiod_direction_output_raw(desc, value);
}
All-in-all, with a value of 'keep' for default-state property in a
leds-gpio child node, the current state of the hardware will in-fact be
inverted; precisely the opposite of what was intended.
Rework leds-pca955x so that we avoid the incorrect inversion and clarify
the semantics with respect to GPIO.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Joel Stanley <joel@jms.id.au>
Tested-by: Matt Spinler <mspinler@linux.vnet.ibm.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The "activity" trigger was inspired by the heartbeat one, but aims at
providing instant indication of the immediate CPU usage. Under idle
condition, it flashes 10ms every second. At 100% usage, it flashes
90ms every 100ms. The blinking frequency increases from 1 to 10 Hz
until either the load is high enough to saturate one CPU core or 50%
load is reached on a single-core system. Then past this point only the
duty cycle increases from 10 to 90%.
This results in a very visible activity reporting allowing one to
immediately tell whether a machine is under load or not, making it
quite suitable to be used in clusters.
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The indicator LED was registered in probe but was not removed in driver
remove callback. Fix this.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Use integer numbers for LEDs, 0 is the flash and 1 is the indicator.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
DT bindings document the property "ams,input-max-microamp" that limits the
chip's maximum input current. The driver and the DTS however used
"peak-current-limit" property. Fix this by using the property documented
in DT binding documentation.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
... and __initconst if applicable.
Based on similar work for an older kernel in the Grsecurity patch.
[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJZsZswAAoJEL1qUBy3i3wm2cwQANp9Hufui0BYxD7X9bB3sBvX
LJ2lbwQlZ93gmQo176fvE22wYw90wmf4CG12pdx8CB4TIBOuaEl1EUptaIxHjBkP
+MOmiGxT0YZgUDmSo+sCL+LHEDWU8gcs8MI5ZkAxgALUb0kYiQySH5UlCJJOJIJv
ww1A4K1bo6VONli+y8ZDa3eKgkArg1/pXYl2VejNMSkr88fyzf35fOKD44lMUGos
5KFVWdPMnz1OuVbh199x9vAPZygb4PNzJL1Tf2ntklBfU3mX+582e6uvIPqh4Tuy
D5ZianpBNtA0IBV4G0UE+n/9rOy9oAr34+Tq9Gv0BRLlQXsC8FMEM5xcCDd1kFCI
L6FeiGc1YnEtJpUVEhcWzmpww2EBBRKIB9lJK5c8VUlWf/yZME72Al5R8c7uffcE
hc78eUVwM2fHNmBhmCmK49flC67/LMzHMiaEQ/lSGtGnd8ratclshFuooiPzsJN/
MSTX2B3yxWvBjwmZMNixY6WasduKKJs4K5xHnHJzyLt0mvClLiwgOvi1Dks0t+Ko
imE6cdU3LCUeJJb4I9SgHTTjp33CTqq5ZBhbFsgqjNsfj4o/6GmnWxvSZ4ywqJMW
HwU4iyBKlx2AVfhzIPozuoE67+HJyRYIexsUZi4vt0Pw2qHxwp1RvH+BMQbXGLLg
rJ/H9ef5BAPRkPWxe1HM
=E1ff
-----END PGP SIGNATURE-----
Merge tag 'leds_for_4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
Pull LED updates from Jacek Anaszewski:
"LED class drivers improvements:
leds-pca955x:
- add Device Tree support and bindings
- use devm_led_classdev_register()
- add GPIO support
- prevent crippled LED class device name
- check for I2C errors
leds-gpio:
- add optional retain-state-shutdown DT property
- allow LED to retain state at shutdown
leds-tlc591xx:
- merge conditional tests
- add missing of_node_put
leds-powernv:
- delete an error message for a failed memory allocation in
powernv_led_create()
leds-is31fl32xx.c
- convert to using custom %pOF printf format specifier
Constify attribute_group structures in:
- leds-blinkm
- leds-lm3533
Make several arrays static const in:
- leds-aat1290
- leds-lp5521
- leds-lp5562
- leds-lp8501"
* tag 'leds_for_4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
leds: pca955x: check for I2C errors
leds: gpio: Allow LED to retain state at shutdown
dt-bindings: leds: gpio: Add optional retain-state-shutdown property
leds: powernv: Delete an error message for a failed memory allocation in powernv_led_create()
leds: lp8501: make several arrays static const
leds: lp5562: make several arrays static const
leds: lp5521: make several arrays static const
leds: aat1290: make array max_mm_current_percent static const
leds: pca955x: Prevent crippled LED device name
leds: lm3533: constify attribute_group structure
dt-bindings: leds: add pca955x
leds: pca955x: add GPIO support
leds: pca955x: use devm_led_classdev_register
leds: pca955x: add device tree support
leds: Convert to using %pOF instead of full_name
leds: blinkm: constify attribute_group structures.
leds: tlc591xx: add missing of_node_put
leds: tlc591xx: merge conditional tests
We get a link error when V4L2_FLASH_LED_CLASS=m and AS3645A is built-in:
drivers/leds/leds-as3645a.o: In function `as3645a_v4l2_setup':
leds-as3645a.c:(.text+0x258): undefined reference to `v4l2_flash_init'
leds-as3645a.c:(.text+0x284): undefined reference to `v4l2_flash_indicator_init'
leds-as3645a.c:(.text+0x2a4): undefined reference to `v4l2_flash_release'
drivers/leds/leds-as3645a.o: In function `as3645a_remove':
leds-as3645a.c:(.text+0x784): undefined reference to `v4l2_flash_release'
This adds the same Kconfig dependency that the other V4L2 flash
drivers in drivers/leds use, to avoid that broken configuration.
Fixes: a56ba8fbcb ("media: leds: as3645a: Add LED flash class driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This should also allow probing to fail when a pca955x chip is not
found on a I2C bus.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
In some systems, such as Baseboard Management Controllers (BMCs), we
want to retain the state of LEDs across a reboot of the BMC (whilst the
host remains up). Implement support for the retain-state-shutdown
devicetree property in leds-gpio.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Brandon Wyman <bjwyman@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Don't populate the arrays on the stack, instead make them static const.
Makes the object code smaller by 50 bytes:
Before:
text data bss dec hex filename
5058 1552 64 6674 1a12 drivers/leds/leds-lp8501.o
After:
text data bss dec hex filename
4788 1776 64 6628 19e4 drivers/leds/leds-lp8501.o
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Don't populate the arrays on the stack, instead make them static const.
Makes the object code smaller by over 150 bytes:
Before:
text data bss dec hex filename
7725 2448 64 10237 27fd drivers/leds/leds-lp5562.o
After:
text data bss dec hex filename
7184 2832 64 10080 2760 drivers/leds/leds-lp5562.o
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Don't populate the arrays on the stack, instead make them static const.
Makes the object code smaller by over 120 bytes:
Before:
text data bss dec hex filename
8999 4176 64 13239 33b7 drivers/leds/leds-lp5521.o
After:
text data bss dec hex filename
8554 4496 64 13114 333a drivers/leds/leds-lp5521.o
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Don't populate the array max_mm_current_percent on the stack, instead
make it static const. Makes the object code smaller by over 280 bytes:
Before:
text data bss dec hex filename
7225 1936 64 9225 2409 ./drivers/leds/leds-aat1290.o
After:
text data bss dec hex filename
6847 2032 64 8943 22ef ./drivers/leds/leds-aat1290.o`
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
In case platform data provided empty LED name string the resulting
LED class device name would be crippled. Use corresponding LED chip
bit in place of "function" segment of LED class device name then to
make the LEDs at least distinguishable.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Reported-by: Colin King <colin.king@canonical.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Suggested-by: Nate Case <ncase@xes-inc.com>
Functions working with attribute_groups provided by <linux/device.h>
work with const attribute_group. These attribute_group structures do not
change at runtime so mark them as const.
File size before:
text data bss dec hex filename
8272 4608 64 12944 3290 drivers/leds/leds-lm3533.o
File size after:
text data bss dec hex filename
8368 4512 64 12944 3290 drivers/leds/leds-lm3533.o
This change was made with the help of Coccinelle.
Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Add a LED flash class driver for the as3654a flash controller. A V4L2 flash
driver for it already exists (drivers/media/i2c/as3645a.c), and this driver
is based on that.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The V4L2 flash interface allows controlling multiple LEDs through a single
sub-devices if, and only if, these LEDs are of different types. This
approach scales badly for flash controllers that drive multiple flash LEDs
or for LED specific associations. Essentially, the original assumption of a
LED driver chip that drives a single flash LED and an indicator LED is no
longer valid.
Address the matter by registering one sub-device per LED.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com> (for greybus/light)
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The PCA955x family of chips are I2C LED blinkers whose pins not used
to control LEDs can be used as general purpose I/Os (GPIOs).
The following adds such a support by defining different operation
modes for the pins (See bindings documentation for more details). The
pca955x driver is then extended with a gpio_chip when some of pins are
operating as GPIOs. The default operating mode is to behave as a LED.
The GPIO support is conditioned by CONFIG_LEDS_PCA955X_GPIO.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
This lets us remove the loop doing the cleanup in case of failure and
also the remove handler of the i2c_driver.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
It will be used in a following patch to define different operation
modes for each pin.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
for_each_child_of_node performs an of_node_get on each iteration, so a
return from the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
local idexpression n;
expression e,e1;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(e1,n) {
...
(
of_node_put(n);
|
e = n
|
return n;
|
+ of_node_put(n);
? return ...;
)
...
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Merge conditionals that have the same then branch, to prepare for extending
that branch with of_node_put.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJZXUGpAAoJEL1qUBy3i3wmBdgP/jhpBsA9D+W4grLEzbTSTWSV
GKm19egbgujyLWkTecs1ICtuPYQFI90xV2HqmoSsXa9BEZHErB7zbubBzPEqS4RW
ghsqweaLllOe6LtHs/ZvgvTGILaivpvK1R9qawaqJi6Cmg0VZvG8ApQNNpQD6bnj
YCknKetLK+pdcjVCTaG7hyf+Ess7ASrwiWwIBiU26K+X6p7YpilxT5AylYWH6erl
s+Lr3U0As86Fj+/ELOgmYBMTO1phZ7r1FSR/sa7RTlfgEgJQxmgagCfAvPGH92K3
gK0UKKKirzfU08nUliHeHqn1K9ZaTKS15bbRNHpzl3/be/oLCuN3kB/Y/ZWtPgOc
pEaCkWn2+4TeChlznyEmmTAeJgKLOBlt8ffSlz+wWNNL9wjG/LVm0Gq/eO49rWsG
fJVbAT/lnWQ5dVEXlzQbw4uKU8DZDpjChjkv7shLMcValUtysnJ/w3edl5Czyx0y
s2ckFmWnmQwTd+//PoJYnfdywPc3NfpsJD2j2VrEc0unsodAszwrdHdFVmsSgAJY
u6cbrrxWYakXUcV/6gKVybhdMpNsV4f2KDthxrZmN3JGetQU/zoNsMBrNJu30l3d
Iifry+UlYNHoozITKyk1+J3atEF6YzMIhuJTP1ifN07tvo5WaSESPFuoJdxLFlyt
4OZcjjWj+CGqZ6+RSUya
=5JLc
-----END PGP SIGNATURE-----
Merge tag 'leds_for_4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
Pull LED updates from Jacek Anaszewski:
"This time we're removing more than adding:
Removed drivers:
leds-versatile:
- all users of the Versatile LED driver are deleted and replaced
with the very generic leds-syscon
leds-sead3:
- SEAD3 is using the generic leds-syscon & regmap based
register-bit-led driver
LED class drivers improvements:
ledtrig-gpio:
- use threaded IRQ, which both simplifies the code because we can
drop the workqueue indirection, and it enables using the trigger
for GPIOs that work with threaded IRQs themselves
- refresh LED state after GPIO change since the new GPIO may have
a different state than the old one
leds-lp55xx:
- make various arrays static const
leds-pca963x:
- add bindings to invert polarity"
* tag 'leds_for_4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
leds: lp55xx: make various arrays static const
leds: Remove SEAD-3 driver
leds: trigger: gpio: Use threaded IRQ
leds: trigger: gpio: Refresh LED state after GPIO change
leds: Delete obsolete Versatile driver
leds: pca963x: Add bindings to invert polarity
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>
-----BEGIN PGP SIGNATURE-----
iQEbBAABAgAGBQJZR92EAAoJEHm+PkMAQRiGT1oH+KW2FLrRaYxtut+KyGA6l7tc
R/hFx1n9BibkjXeqD+y6/4SjRTe6/pT8Zkihv3/19eZ5algUWeQa0Hm+/455sl58
IdIXx/pzuCO3kqR3//fP9ZFD657GNDsuQ0fYnZESItFwiWQtO1TNfZD6KQjkqBdI
L3MVhDUVBZA2ZtPwC4ERei5/sToV9woykKoJ/A3+OkWjgX6w4SBimqgkSEFk4uE8
xS0pycyDZci93rJlECi1UueewdODTKSmhwdC80qvGEiYXzsC6UFtaF0Fj66XO1AL
UMjxqI/gkm5ZuCIjRsmPmJjgL5q1RT6UX/qtw9yn71XTmcgMiPW2/DF/v/OaTg==
=XbW2
-----END PGP SIGNATURE-----
Merge tag 'v4.12-rc6' into patchwork
Linux 4.12-rc6
* tag 'v4.12-rc6': (813 commits)
Linux 4.12-rc6
mm: larger stack guard gap, between vmas
virtio_balloon: disable VIOMMU support
mm: correct the comment when reclaimed pages exceed the scanned pages
userfaultfd: shmem: handle coredumping in handle_userfault()
mm: numa: avoid waiting on freed migrated pages
swap: cond_resched in swap_cgroup_prepare()
mm/memory-failure.c: use compound_head() flags for huge pages
perf unwind: Report module before querying isactivation in dwfl unwind
fs: pass on flags in compat_writev
objtool: Add fortify_panic as __noreturn function
powerpc/debug: Add missing warn flag to WARN_ON's non-builtin path
USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
drm: mxsfb_crtc: Reset the eLCDIF controller
drm/mgag200: Fix to always set HiPri for G200e4 V2
i2c: ismt: fix wrong device address when unmap the data buffer
i2c: rcar: use correct length when unmapping DMA
powerpc/xive: Fix offset for store EOI MMIOs
drm/tegra: Correct idr_alloc() minimum id
drm/tegra: Fix lockup on a use of staging API
...
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
SEAD3 is using the generic syscon & regmap based register-bit-led
driver as of commit c764583f40 ("MIPS: SEAD3: Use register-bit-led
driver via DT for LEDs") merged in the v4.9 cycle. As such the custom
SEAD-3 LED driver is now unused, so remove it.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJZRQjNAAoJEL1qUBy3i3wmgt4P+wfkMgfBnpiCtp7aoRtvRo8o
Ar+SR0iwcG5T8jM/Q74H2K//lKdjXtsGVrtXHeUTmhzLluw+cfnycgPo0oK9iHtR
CowneQJhj3FvPos63wzPnea0+Sg8ZBbegR6Bp+Au+IrH+svX4BO48BuSdwXHBzsa
jFU6TgvR1YGltpsn4IKzTyY1uRlyMYV6CahadqqibpaWxw301Hm2RxzPPwV50h0T
2PXLYR28L/2G5f6bvI/qp+2m1haKE2c/4kSRXX0BetkE/zifAVCuOBxo505ztDZd
KZ/SZ0uZ5xR8O0/I28udoNv37wXePoXeOs+ycpHcgG2NUDLbVmWLVVUWQVYPY6Hu
71q0piW9LulSZxhDivEIiJk7lhQ/khq6M1WeABxYHI6X4BNFNnHykgnesEULL17I
B4+Hb4rALIFjh0KrJfCGL/Y4Pne0MGP/YFGPBFAYGBqC/yzZ32xs3lgcu9H0sSnV
mWedN+CbfX74AjAl16KGC/m1fxGRTHWPSN6QCrjzcPGXDN0Zx1NtkTk6HwhjIiRB
QeFxQB13ucQZaGiAG1N0pj2Qe1+Tjla03rJ4HL+IuNTxtaVX01/XaOahUWrZHWdg
H6FkrinOKuUJRQ/tsQRSPxpaOlGkdGEqGyTR3/S/8yoxU695lKV9HmVLBOVyqHwz
faKVeNd3MAA09o/RpN9N
=GOju
-----END PGP SIGNATURE-----
Merge tag 'led_fixes_for_4.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
Pull LED fixes from Jacek Anaszewski:
"Two LED fixes:
- fix signal source assignment for leds-bcm6328
- revert patch that intended to fix LED behavior on suspend but it
had a side effect preventing suspend at all due to uevent being
sent on trigger removal"
* tag 'led_fixes_for_4.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
Revert "leds: handle suspend/resume in heartbeat trigger"
leds: bcm6328: fix signal source assignment for leds 4 to 7
This reverts commit 5ab92a7cb8.
System cannot enter suspend mode because of heartbeat led trigger.
In autosleep_wq, try_to_suspend function will try to enter suspend
mode in specific period. it will get wakeup_count then call pm_notifier
chain callback function and freeze processes.
Heartbeat_pm_notifier is called and it call led_trigger_unregister to
change the trigger of led device to none. It will send uevent message
and the wakeup source count changed. As wakeup_count changed, suspend
will abort.
Fixes: 5ab92a7cb8 ("leds: handle suspend/resume in heartbeat trigger")
Signed-off-by: Zhang Bo <bo.zhang@nxp.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Each nibble represents 4 LEDs, and in case of the higher register, bit 0
represents LED 4, so we need to use modulus for the LED number as well.
Fixes: fd7b025a23 ("leds: add BCM6328 LED driver")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Acked-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJZNnBiAAoJEAhfPr2O5OEV9bwP/1bus9tAw3AT+HxRSIaFFX8+
DMDmJ6nZ4WQJ4fI04tKkUjpl+G2ImDGshdGgLht/YpaJRd6KgPqV+zWrAVX5/0e1
mLyhjaALuk5M//JbkxEP95SWBOZ6SCIWlV/5oQRTNI86kO0gISxoCAsbumKlSSUC
qTFmbmPp9siFpS43eZjVcgYIbwFx75qvLTc1+JRvxa2VhtMB5d4xYnXSpxlCvduj
NN14KiphBgCOvyMQsi4q3H6ma8EL0sEtaukqPzXOnz6GGAIUUbDA23APM5H0LIIZ
kYhO9ooez4dz1094ex1zSS/uQq2ogCTv7ShQseddNbHhOFG7Aq30AXLMEWeHaNp1
fFb28CY3CBpNaYfjePbqIs8KKg3JxmJGmCGgW65p40UGUo1Itbpci5MqN8BjQAI8
Ks1rf+V4iYQTr4QmQJQqCyJCljrsQbGMKZ9I67pmqfbqDunlH43Zr88DEWPv3rbW
qac6U1vh108UHE/1KRZFjzvo31ToP+f+AwyVTXVeIi6vba2gvC8ASCJnZ/nGtO74
Eb/GR0DtqvYGE6sXohbMywZ+8wRR6CdRVDC4YotQwaoghwnH10WPLg3JahECVMu7
MbDtVvUHjbJ18cqwCW+J01gcuQxH/8Lx07T9T+pUFFanPBT7phPiQ/UAEPL1e3XO
e4nFwX9h78wISBdy8Yx7
=+jBV
-----END PGP SIGNATURE-----
Merge tag 'media/v4.12-2' into patchwork
media fixes for v4.12-rc4
* tag 'media/v4.12-2': (598 commits)
[media] rc-core: race condition during ir_raw_event_register()
[media] cec: drop MEDIA_CEC_DEBUG
[media] cec: rename MEDIA_CEC_NOTIFIER to CEC_NOTIFIER
[media] cec: select CEC_CORE instead of depend on it
[media] rainshadow-cec: ensure exit_loop is intialized
[media] atomisp: don't treat warnings as errors
Linux 4.12-rc3
x86/ftrace: Make sure that ftrace trampolines are not RWX
x86/mm/ftrace: Do not bug in early boot on irqs_disabled in cpu_flush_range()
selftests/ftrace: Add a testcase for many kprobe events
kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
ftrace: Fix memory leak in ftrace_graph_release()
ipv4: add reference counting to metrics
net: ethernet: ax88796: don't call free_irq without request_irq first
ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets
sctp: fix ICMP processing if skb is non-linear
net: llc: add lock_sock in llc_ui_bind to avoid a race condition
PCI/msi: fix the pci_alloc_irq_vectors_affinity stub
blk-mq: Only register debugfs attributes for blk-mq queues
x86/timers: Move simple_udelay_calibration past init_hypervisor_platform
...
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Pass the more generic fwnode_handle to the init function than the
device_node.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This both simplifies the code because we can drop the workqueue
indirection, and it enables using the trigger for GPIOs that work with
threaded IRQs themselves.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The new GPIO may have a different state than the old one.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The driver checks an incorrect flag of functionality of adapter.
When a driver requires i2c_smbus_read_byte_data and
i2c_smbus_write_byte_data, it should check I2C_FUNC_SMBUS_BYTE_DATA
instead I2C_FUNC_I2C.
This patch fixes the problem.
Signed-off-by: Tin Huynh <tnhuynh@apm.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
All users of the Versatile LED driver are deleted and replaced
with the very generic leds-syscon. Delete the old driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Add a new DT property, nxp,inverted-out, to invert the polarity
of the output.
Tested on PCA9634.
Signed-off-by: Anders Darander <anders@chargestorm.se>
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>
This patch extends the device tree support for the pca9532 by adding
the leds 'default-state' property.
Signed-off-by: Felix Brack <fb@ltec.ch>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Motorola CPCAP is a PMIC (power management integrated circuit) found
in multiple smartphones. This driver adds support for the chip's LED
controllers. This introduces support for all controllers used by the
Droid 4. According to Motorola's driver (no datasheets available)
there a couple of more LED controllers. I did not add support for
them, since I cannot verify that they work with my modifications.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Instead of unusual "if (!ret)" use "if (ret)" in lp3952_get_label().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
In ACPI world any ID should be carefully chosen and registered
officially. The discussion [1] as I read it gets to wilful assignment
an ID for non-existing real DSDT example.
Rafael already told [2] how this device would be enumerated using
compatible string. To be more precise look at the possible DSDT excerpt
below:
Device (LDX0) {
Name (_HID, "PRP0001")
Name (_DDN, "TI LP3952 compatible led driver")
...
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ti,lp3952"},
...
}
})
Based on above, remove non-official ACPI IDs and enumeration from the
driver.
Note: currently driver has no compatible strings at all, to make above
working one should add at least one.
[1] https://e2e.ti.com/support/power_management/led_driver/f/192/t/524926
[2] https://www.spinics.net/lists/linux-acpi/msg67125.html
Cc: Tony Makkiel <tony.makkiel@daqri.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
It should be ">= MT6323_MAX_LEDS" instead of ">". Also "reg" is a u32
so it can't be negative and we can remove the test for negative values.
Fixes: 216ec6cc4c ("leds: Add LED support for MT6323 PMIC")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
MT6323 PMIC is a multi-function device that includes LED function.
It allows attaching up to 4 LEDs which can either be on, off or dimmed
and/or blinked with the controller.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
In leds-gpio we support LEDs specified in DT so we should use
(devm_)of_led_classdev_register. This allows passing DT node as argument
for use by the LED subsystem.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
These new functions allow passing an additional device_node argument
that will be internally set for created LED device. Thanks to this LED
core code and triggers will be able to access DT node for reading extra
info.
The easiest solution for achieving this was reworking old functions to
more generic ones & adding simple defines for API compatibility.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The dell-led driver handles a specific WMI GUID present on some Dell
laptops and as such it belongs in the x86 platform driver subsystem.
Source code is moved along with the relevant Kconfig and Makefile
entries, with some minor modifications:
- Kconfig option is renamed from CONFIG_LEDS_DELL_NETBOOKS to
CONFIG_DELL_WMI_LED,
- the X86 Kconfig dependency is removed as the whole
drivers/platform/x86 menu depends on it, so there is no need to
duplicate it,
- the name of the module's source file is removed from the header
comment to avoid the need to update it in the future.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Tested-by: Alex Hung <alex.hung@canonical.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
With dell_micmute_led_set() moved to drivers/platform/x86/dell-laptop.c,
all remnants of the mic mute LED handling code can be removed from
drivers/leds/dell-led.c, restoring it back to the state it was in before
commit db6d8cc007 ("dell-led: add mic mute led interface").
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Tested-by: Alex Hung <alex.hung@canonical.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To ensure all users of dell-smbios are in drivers/platform/x86, move the
dell_micmute_led_set() method from drivers/leds/dell-led.c to
drivers/platform/x86/dell-laptop.c.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Tested-by: Alex Hung <alex.hung@canonical.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The dell_app_wmi_led_set() method introduced in commit db6d8cc007
("dell-led: add mic mute led interface") was implemented as an easily
extensible entry point for other modules to set the state of various
LEDs. However, almost three years later it is still only used to
control the mic mute LED, so it will be replaced with direct calls to
dell_micmute_led_set().
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Tested-by: Alex Hung <alex.hung@canonical.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
As dell_micmute_led_set() no longer uses the dell_wmi_perform_query()
method, which was removed in commit 0c41a08e13 ("dell-led: use
dell_smbios_send_request() for performing SMBIOS calls"), the
DELL_APP_GUID check is redundant and thus can be safely removed.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Tested-by: Alex Hung <alex.hung@canonical.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Currently there is one CPU led trigger per cpu ('cpu0', 'cpu1', ...)
This patch adds a new trigger, 'cpu', with brightness proportional to
the number of active CPUs.
If multiple brightness levels aren't supported on the LED,
it effectively indicates if there is any CPU active.
This is particularly useful on tiny linux boards with more CPU cores than LED pins.
Signed-off-by: Paulo Costa <me@paulo.costa.nom.br>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
We are going to split <linux/sched/loadavg.h> out of <linux/sched.h>, which
will have to be picked up from a couple of .c files.
Create a trivial placeholder <linux/sched/topology.h> file that just
maps to <linux/sched.h> to make this patch obviously correct and
bisectable.
Include the new header in the files that are going to need it.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This set contains mostly fixes to existing drivers as well as cleanup of
code that's not been in active use for a while.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAli1+XgZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoX8LD/4l8MeOgKo+uWsfX7tY1kQ/
gWitT/g+jCl3kXYtmcDTaLbEnNr0b5tGahmYC7rnCLhoq6Sp1VXjm6LChuoIUrMF
r53IlUEEgHhClfCK/vqrp/kZoFndmtLZN2V6K8gpM730nNLYAwH6FhGmUFYp47Sm
Xfdl5PwuSVDNnrBehjXPuAqUpFTp8lzrZsRkFrbX5a6TJ7hjn0TwNdovdGa6pV7k
0LXKBfSGTRS2BxDmAFqXItC2USG7v3WRCDc4jCtykNLyQKU1yCA+AYwgR9+1jj8o
1I07gjbZ+Fp8hzcQw/88MdodtS1xGV75WquhYLYWTgbneEWAcRVM47wklvL5gm7O
70lIAvOveSFGjFoWnB9YACkOoZIxDINLhWwBD0Ytfpu/gaj3VsP/WrdMu6dk5kWq
va4XHCS+dObT3o4fRkxQsQJVhAJmg4000Mupg4DOgaigd1PmFLFjBsmHua4+Ssf5
c+y+SVAg8+c3jqA9mHxPJAJesJ41fXBQCB1Xy8pDOe8iK9fBiZjkq2ssiDerN0kI
Sc4+hZHaGRhJqZUItvKJvNhdvrPkzQsRjrZgVLW/bDEXek3SXEmBAFsuZnr6w4BZ
TVVxTNzg+h4obJZEay/P6oWO6KDfF/RyTK0CUHj/ORHxbqUViiwlSJkTVgp7Etd6
mJj0xObBIwUGnSYvqGcShA==
=J9q4
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This set contains mostly fixes to existing drivers as well as cleanup
of code that's not been in active use for a while"
* tag 'pwm/for-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (27 commits)
acpi: lpss: call pwm_add_table() for BSW PWM device
pwm: Try to load modules during pwm_get()
pwm: Don't hold pwm_lookup_lock longer than necessary
pwm: Make the PWM_POLARITY flag in DTB optional
pwm: Print error messages with pr_err() instead of pr_debug()
pwm: imx: Add polarity inversion support to i.MX's PWMv2
pwm: imx: doc: Update imx-pwm.txt documentation entry
pwm: imx: Remove redundant i.MX PWMv2 code
pwm: imx: Provide atomic PWM support for i.MX PWMv2
pwm: imx: Move PWMv2 wait for fifo slot code to a separate function
pwm: imx: Move PWMv2 software reset code to a separate function
pwm: imx: Rewrite v1 code to facilitate switch to atomic PWM
pwm: imx: Add separate set of PWM ops for v1 and v2
pwm: imx: Remove ipg clock and enable per clock when required
pwm: lpss: Add Intel Gemini Lake PCI ID
pwm: lpss: Do not export board infos for different PWM types
pwm: lpss: Avoid reconfiguring while UPDATE bit is still enabled
pwm: lpss: Switch to new atomic API
pwm: lpss: Allow duty cycle to be 0
pwm: lpss: Avoid potential overflow of base_unit
...
Core changes:
- Augment fwnode_get_named_gpiod() to configure the GPIO pin
immediately after requesting it like all other APIs do.
This is a treewide change also updating all users.
- Pass a GPIO label down to gpiod_request() from
fwnode_get_named_gpiod(). This makes debugfs and the userspace
ABI correctly reflect the current in-kernel consumer of a pin
taken using this abstraction. This is a treewide change also
updating all users.
- Rename devm_get_gpiod_from_child() to
devm_fwnode_get_gpiod_from_child() to reflect the fact that this
function is operating on a fwnode object. This is a treewide
change also updating all users.
- Make it possible to take multiple GPIOs in a single hog of device
tree hogs.
- The refactorings switching GPIO chips to use the .set_config()
callback using standard pin control properties and providing
a backend into the pin control subsystem that were also merged
into the pin control tree naturally appear here too.
Testing instrumentation:
- A whole slew of cleanups and improvements to the mockup GPIO
driver. We now have an extended userspace test exercising the
subsystem, and we can inject interrupts etc from userspace
to fully test the core GPIO functionality.
New drivers:
- New driver for the Cortina Systems Gemini GPIO controller.
- New driver for the Exar XR17V352/354/358 chips.
- New driver for the ACCES PCI-IDIO-16 PCI GPIO card.
Driver changes:
- RCAR: set the irqchip parent device, add fine-grained runtime
PM support.
- pca953x: support optional RESET control line on the chip.
- DaVinci: cleanups and simplifications. Add support for multiple
instances.
- .set_multiple() and naming of lines on more or less all of the
ISA/PCI GPIO controllers.
- mcp23s08: refactored to use regmap as a first step to further
rewrites and modernizations.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJYrqvqAAoJEEEQszewGV1zoHsP/i1iZBEywR9+yIx/p2/F2mJu
nriuYFlp0V3FjHQAQ//YCA9+Catri+ZqT5l+BmG/EYdqqikHbziTyS0YArlfrMHv
OOBfDmfftexvRI/jQAl+X/nIW531ZjYo6ZApFy/2TirTwfkI7DIMi6ujm09fcG5D
BgCT1KuszbVtyrmhrQvbeEdVKw0qLAgwnn5eOOCQE4KuDB3s7eyal0rJaDEXhpMF
kH/y6eySs4FChEhAEmCkM6205F5T4c2YFjL1bo5Fkh/WPrVPaKI0Ny16qbaDWU9K
W9RaJUzf92KIW0MgcRl+r8Lxn+GekN6/jvrxddQ/Ajs/Dkh5r2JCrm7RIC9tBPcJ
VbLfjL+cMehlSEu9eyxRQcAIeuUYCqkN8ghuVoj9xt/tDtNYsQIcJZtfW1yjmONq
mFsd5KhfBFgspQkwF4IX3hthaqj8MH4zefQdWzAGPZMGEA1rrx2kVSEdZD3EV4VN
84qt5Cx9hLllafthJOGjEIZFCjPIpbMRwTQ+fmc+1IB1DgN8Kc5E1FMssKbUEoOK
2eLquLvd7iNDMidTjoi87YAisW9qnrPeRDywsqeXdQf7fzpB97gX4MQfJ5fJWEYr
3uHCfu2u4J4cff9ygg8c4ut7ePEjz+ld/sBh9EHicbbryR4I5ZG7Ne1aQhsmb2M5
dHZSRfQYEQ4Nl7cMJQuh
=O81I
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for the v4.11 cycle
Core changes:
- Augment fwnode_get_named_gpiod() to configure the GPIO pin
immediately after requesting it like all other APIs do. This is a
treewide change also updating all users.
- Pass a GPIO label down to gpiod_request() from
fwnode_get_named_gpiod(). This makes debugfs and the userspace ABI
correctly reflect the current in-kernel consumer of a pin taken
using this abstraction. This is a treewide change also updating all
users.
- Rename devm_get_gpiod_from_child() to
devm_fwnode_get_gpiod_from_child() to reflect the fact that this
function is operating on a fwnode object. This is a treewide change
also updating all users.
- Make it possible to take multiple GPIOs in a single hog of device
tree hogs.
- The refactorings switching GPIO chips to use the .set_config()
callback using standard pin control properties and providing a
backend into the pin control subsystem that were also merged into
the pin control tree naturally appear here too.
Testing instrumentation:
- A whole slew of cleanups and improvements to the mockup GPIO
driver. We now have an extended userspace test exercising the
subsystem, and we can inject interrupts etc from userspace to fully
test the core GPIO functionality.
New drivers:
- New driver for the Cortina Systems Gemini GPIO controller.
- New driver for the Exar XR17V352/354/358 chips.
- New driver for the ACCES PCI-IDIO-16 PCI GPIO card.
Driver changes:
- RCAR: set the irqchip parent device, add fine-grained runtime PM
support.
- pca953x: support optional RESET control line on the chip.
- DaVinci: cleanups and simplifications. Add support for multiple
instances.
- .set_multiple() and naming of lines on more or less all of the
ISA/PCI GPIO controllers.
- mcp23s08: refactored to use regmap as a first step to further
rewrites and modernizations"
* tag 'gpio-v4.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (61 commits)
gpio: reintroduce devm_get_gpiod_from_child()
gpio: pci-idio-16: Fix PCI BAR index
gpio: pci-idio-16: Fix PCI device ID code
gpio: mockup: implement event injecting over debugfs
gpio: mockup: add a dummy irqchip
gpio: mockup: implement naming the lines
gpio: mockup: code shrink
gpio: mockup: readability tweaks
gpio: Add GPIO support for the ACCES PCI-IDIO-16
gpio: Add the devm_fwnode_get_index_gpiod_from_child() helper
gpio: Rename devm_get_gpiod_from_child()
gpio: mcp23s08: Select REGMAP/REGMAP_I2C to fix build error
gpio: ws16c48: Add support for GPIO names
gpio: gpio-mm: Add support for GPIO names
gpio: 104-idio-16: Add support for GPIO names
gpio: 104-idi-48: Add support for GPIO names
gpio: 104-dio-48e: Add support for GPIO names
gpio: ws16c48: Remove unnecessary driver_data set
gpio: gpio-mm: Remove unnecessary driver_data set
gpio: 104-idio-16: Remove unnecessary driver_data set
...
LED class heartbeat trigger allowed only for blinking with max_brightness
value. This patch adds more flexibility by exploiting part of LED core
software blink infrastructure.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Rename devm_get_gpiod_from_child() into
devm_fwnode_get_gpiod_from_child() to reflect the fact that this
function is operating on a fwnode object.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some LEDs may have their brightness level changed autonomously
(outside of kernel control) by hardware / firmware. This commit
adds support for an optional brightness_hw_changed attribute to
signal such changes to userspace (if a driver can detect them):
What: /sys/class/leds/<led>/brightness_hw_changed
Date: January 2017
KernelVersion: 4.11
Description:
Last hardware set brightness level for this LED. Some LEDs
may be changed autonomously by hardware/firmware. Only LEDs
where this happens and the driver can detect this, will
have this file.
This file supports poll() to detect when the hardware
changes the brightness.
Reading this file will return the last brightness level set
by the hardware, this may be different from the current
brightness.
Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to
their flags field and call led_classdev_notify_brightness_hw_changed()
with the hardware set brightness when they detect a hardware / firmware
triggered brightness change.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
gcc gets confused about the control flow in ktd2692_parse_dt(), causing
it to warn about what seems like a potential bug:
drivers/leds/leds-ktd2692.c: In function 'ktd2692_probe':
drivers/leds/leds-ktd2692.c:244:15: error: '*((void *)&led_cfg+8)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/leds/leds-ktd2692.c:225:7: error: 'led_cfg.flash_max_microamp' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/leds/leds-ktd2692.c:232:3: error: 'led_cfg.movie_max_microamp' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The code is fine, and slightly reworking it in an equivalent way lets
gcc figure that out too, which gets rid of the warning.
Fixes: 77e7915b15 ("leds: ktd2692: Add missing of_node_put")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Currently all users of fwnode_get_named_gpiod() have no way to
specify a label for the GPIO. So GPIOs listed in debugfs are shown
with label "?". With this change a proper label is used.
Also adjust all users so they can pass a label, properly retrieved
from device tree properties.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Make fwnode_get_named_gpiod() consistent with the rest of
gpiod_get() like API, i.e. configure GPIO pin immediately after
request.
Besides obvious clean up it will help to configure pins based
on firmware provided resources.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
PWM devices have all been marked as "might sleep" since v4.5. It no
longer makes sense to keep the alternative code paths around because
it is effectively dead code.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When the state names got added a script was used to add the extra argument
to the calls. The script basically converted the state constant to a
string, but the cleanup to convert these strings into meaningful ones did
not happen.
Replace all the useless strings with 'subsys/xxx/yyy:state' strings which
are used in all the other places already.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20161221192112.085444152@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This patch enables ACPI support for leds-pca955x driver.
Signed-off-by: Tin Huynh <tnhuynh@apm.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/leds//leds-netxbig.ko | grep alias
alias: platform:leds-netxbig
After this patch:
$ modinfo drivers/leds//leds-netxbig.ko | grep alias
alias: platform:leds-netxbig
alias: of:N*T*Clacie,netxbig-ledsC*
alias: of:N*T*Clacie,netxbig-leds
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This patch enables ACPI support for leds-pca963x driver.
Signed-off-by: Tin Huynh <tnhuynh@apm.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
All 3 of led_timer_func, led_set_brightness and led_set_software_blink
set blink_brightness. If led_timer_func or led_set_software_blink race
with led_set_brightness they may end up overwriting the new
blink_brightness. The new atomic work_flags does not protect against
this as it just protects the flags and not blink_brightness.
This commit introduces a new new_blink_brightness value which gets
set by led_set_brightness and read by led_timer_func on LED on, fixing
this.
Dealing with the new brightness at LED on time, makes the new
brightness apply sooner, which also fixes a led_set_brightness which
happens while a oneshot blink which ends in LED on is running not
getting applied.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
All the LED_BLINK* flags are accessed read-modify-write from e.g.
led_set_brightness and led_blink_set_oneshot while both
set_brightness_work and the blink_timer may be running.
If these race then the modify step done by one of them may be lost,
switch the LED_BLINK* flags to a new atomic work_flags bit-field
to avoid this race.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Add the driver to support User LEDs on PXI Embedded Controller.
Signed-off-by: Hui Chun Ong <hui.chun.ong@ni.com>
Signed-off-by: Brad Mouring <brad.mouring@ni.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Verify that vendor is Mellanox as the first step of initialization.
If it is not - return ENODEV.
Change module license from "GPL v2" to "Dual BSD/GPL".
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Allow chip to enter low power state when no LEDs are being lit or in
blink mode.
Cc: Peter Meerwald <p.meerwald@bct-electronic.com>,
Cc: Ricardo Ribalda <ricardo.ribalda@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The value for a led's default_trigger should come from platform data
instead of data (which is always 0).
Signed-off-by: Felix Brack <fb@ltec.ch>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
PCA9632TK part seems to incorrectly blink at ~1.3x of the programmed
rate. This patchset add a nxp,period-scale devicetree property to
adjust for this misconfiguration.
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
If the driver is built as a module, I2C module alias information is not
filled so the module won't be autoloaded if the device isn't registered
over ACPI. Export the I2C device table alias with MODULE_DEVICE_TABLE()
macro so the information is exported in the module.
Before this patch:
$ modinfo drivers/leds/leds-lp3952.ko | grep alias
alias: acpi*:TXNW3952:*
After this patch:
$ modinfo drivers/leds/leds-lp3952.ko | grep alias
alias: i2c:lp3952
alias: acpi*:TXNW3952:*
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Fix the register access shift argument calculation introduced with
commit a59ce6584d ("leds: leds-mc13783: Add MC34708 LED support")
and re-enable access to the "keypad" led for MC13892 MFC devices.
Signed-off-by: Alexander Kurz <akurz@blala.de>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Use a macro instead of hard-coding the max device node name size. The
uleds driver introduced a macro for this value, so using it.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This driver creates a userspace leds driver similar to uinput.
New LEDs are created by opening /dev/uleds and writing a uleds_user_dev
struct. A new LED class device is registered with the name given in the
struct. Reading will return a single byte that is the current brightness.
The poll() syscall is also supported. It will be triggered whenever the
brightness changes. Closing the file handle to /dev/uleds will remove
the leds class device.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The Kconfig and file naming for the PM8xxx driver is totally
confusing:
- Kconfig options MFD_PM8XXX and MFD_PM8921_CORE, some in-kernel
users depending on or selecting either at random.
- A driver file named pm8921-core.c even if it is indeed
used by the whole PM8xxx family of chips.
- An irqchip named pm8xxx since it was (I guess) realized that
the driver was generic for all pm8xxx PMICs.
As I may want to add support for PM8901 this is starting to get
really messy. Fix this situation by:
- Remove the MFD_PM8921_CORE symbol and rely solely on MFD_PM8XXX
and convert all users, including LEDs Kconfig and ARM defconfigs
for qcom and multi_v7 to use that single symbol.
- Renaming the driver to qcom-pm8xxx.c to fit along the two
other qcom* prefixed drivers.
- Rename functions withing the driver from 8921 to 8xxx to
indicate it is generic.
- Just drop the =m config from the pxa_defconfig, I have no clue
why it is even there, it is not a Qualcomm platform. (Possibly
older Kconfig noise from saveconfig.)
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
If led_trigger_set() is called with "trig" argument set to NULL, and there
is no trigger to remove then the function should return immediately so
as to avoid doing unnecessary allocation and sending uevent.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Reported-by: Daniel Romell <daro@hms.se>
Acked-by Daniel Romell <daro@hms.se>
Simplify the error handling and add a missing call to fwnode_handle_put
when checking led.name.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Using the managed version of led_classdev_register allows to
significantly simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Checking for the presence of the property first isn't strictly needed
as we can react on the return code of fwnode_property_read_string.
Also, even if the presence of a property "label" was checked,
reading a string value for it theoretically still can fail and
this case isn't handled.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Definition of np can be moved into the loop as well to simplify
the code a little.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Add a helper for the container_of as it's used more than once.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
gpiod_get_value_cansleep returns 0, 1, or an error code.
So far errors are not handled and treated the same as 1.
Change this to bail out if an error code is returned and
remove the double negation.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Introduce a typedef gpio_blink_set_t to improve readability of the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This makes it possible to create a set of LEDs for Mellanox systems:
"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410",
"msb7800", "msn2740", "msn2100".
Driver obtains LED devices according to system configuration, provided
through system DMI data, like mlxcpld:fan1:green, mlxcpld:fan1:red and
creates devices in form: "devicename:colour:function".
LED setting is controlled through on board CPLD Lattice device.
For setting particular LED off, solid, blink:
echo 0 > /sys/class/leds/mlxcpld\:status\:green/brightness
echo 1 > /sys/class/leds/mlxcpld\:status\:green/brightness
echo timer > /sys/class/leds/mlxcpld\:status\:green/trigger
On module probing all LEDs are set green, on removing - off.
Last setting overwrites previous, f.e. sequence for
changing LED from green - red - green:
echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness
echo 1 > /sys/class/leds/mlxcpld\:psu\:red/brightness
echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness
Note: LEDs cannot be turned on/off simultaneously.
The Kconfig currently controlling compilation of this code is:
drivers/leds/Kconfig:config LEDS_MLXCPLD
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This adds a driver for the six PM8058 LEDs, three ordinary LEDs,
two "flash" LEDs and one "keypad" LED.
The "keypad" and "flash" LEDs are not really hard-wired to these
usecases: for example on the APQ8060 Dragonboard, the "keypad"
LED is instead used to drive an IR LED used for the proximity
sensor. The "flash" LEDs are just ordinary high-current LED
drivers.
Cc: linux-arm-msm@vger.kernel.org
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Per the documentation, use scnprintf instead of sprintf to ensure there
is never more than PAGE_SIZE bytes of trigger names put into the
buffer.
Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
Signed-off-by: Zach Brown <zach.brown@ni.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The Kconfig currently controlling compilation of this code is:
drivers/leds/trigger/Kconfig:menuconfig LEDS_TRIGGERS
drivers/leds/trigger/Kconfig: bool "LED Trigger support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
We don't replace module.h with init.h since the file doesn't need that.
However it does use EXPORT_SYMBOL, so we add the export.h header.
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This is a driver for the Integrated Silicon Solution Inc. LED driver
chips series IS31FL319x. They can drive 1, 3, 6 or up to 9
LEDs.
Each LED is individually controllable in brightness (through pwm)
in 256 steps so that RGB LEDs can show any of ca. 16 Mio colors.
The maximum current of the LEDs can be programmed and limited to
5 .. 40mA through a device tree property.
The chip is connected through I2C and can have one of 4 addresses
in the range 0x64 .. 0x67 depending on how the AD pin is connected. The
address is defined by the reg property as usual.
The chip also has a shutdown input which could be connected to a GPIO,
but this driver uses software shutdown if all LEDs are inactivated.
The chip also has breathing and audio features which are not fully
supported by this driver.
Tested-on: OMAP5 based Pyra handheld prototype.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Andrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
