summaryrefslogtreecommitdiff
path: root/Documentation/leds
AgeCommit message (Collapse)Author
2017-10-23Documentation: leds: Update 00-INDEX fileJacek Anaszewski
Add missing entries for the following documentation files: - leds-class-flash.txt - leds-lm3556.txt - leds-mlxcpld.txt - ledtrig-usbport.txt - uleds.txt Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz>
2017-03-17Documentaion: leds: leds-lp55xx.txt: Fix typosTamara Diaconita
Fix spelling mistakes in leds-lp55xx.txt file to make documentation clear. Signed-off-by: Tamara Diaconita <diaconita.tamara@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2017-01-29leds: class: Add new optional brightness_hw_changed attributeHans de Goede
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>
2016-11-22leds/leds-lp5523.txt: make documentation match realityPavel Machek
Files are visible all the time, so remove incorrect notes. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: Introduce userspace LED class driverDavid Lechner
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>
2016-10-04Merge branch 'for-next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED driver updates from Jacek Anaszewski: "Three new LED class drivers and some minor fixes and improvementes to the leds-gpio driver, LED Trigger core and documentation" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: leds: triggers: Check return value of kobject_uevent_env() leds: triggers: Return from led_trigger_set() if there is nothing to do leds: gpio: fix and simplify error handling in gpio_leds_create leds: gpio: switch to managed version of led_classdev_register leds: gpio: fix and simplify reading property "label" leds: gpio: simplify gpio_leds_create leds: gpio: add helper cdev_to_gpio_led_data leds: gpio: fix an unhandled error case in create_gpio_led leds: gpio: introduce gpio_blink_set_t leds: add driver for Mellanox systems LEDs Documentation: move oneshot trigger attributes documentation to ABI leds: centralize definition of "default-state" property leds: add PM8058 LEDs driver leds: pm8058: add device tree bindings leds: do not overflow sysfs buffer in led_trigger_show leds: make triggers explicitly non-modular DT: leds: Add bindings for ISSI is31fl319x leds: is31fl319x: 1/3/6/9-channel light effect led driver
2016-09-27usb: core: Introduce a USB port LED triggerRafał Miłecki
This commit adds a new trigger responsible for turning on LED when USB device gets connected to the selected USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1). There was a long discussion on design of this driver. Its current state is a result of picking them most adjustable solution as others couldn't handle all cases. 1) It wasn't possible for the driver to register separated trigger for each USB port. Some physical USB ports are handled by more than one controller and so by more than one USB port. E.g. USB 2.0 physical port may be handled by OHCI's port and EHCI's port. It's also not possible to assign more than 1 trigger to a single LED and implementing such feature would be tricky due to syncing triggers and sysfs conflicts with old triggers. 2) Another idea was to register trigger per USB hub. This wouldn't allow handling devices with multiple USB LEDs and controllers (hubs) controlling more than 1 physical port. It's common for hubs to have few ports and each may have its own LED. This final trigger is highly flexible. It allows selecting any USB ports for any LED. It was also modified (comparing to the initial version) to allow choosing ports rather than having user /guess/ proper names. It was successfully tested on SmartRG SR400ac which has 3 USB LEDs, 2 physical ports and 3 controllers. It was noted USB subsystem already has usb-gadget and usb-host triggers but they are pretty trivial ones. They indicate activity only and can't have ports specified. In future it may be good idea to consider adding activity support to usbport as well. This should allow switching to this more generic driver and maybe marking old ones as obsolete. This can be implemented with another sysfs file for setting mode. The default mode wouldn't change so there won't be ABI breakage and so such feature can be safely implemented later. There was also an idea of supporting other devices (PCI, SDIO, etc.) but as this driver already contains some USB specific code (and will get more) these should be probably separated drivers (triggers). Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-15leds: add driver for Mellanox systems LEDsVadim Pasternak
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>
2016-08-29Documentation: move oneshot trigger attributes documentation to ABIRafał Miłecki
Documentation of sysfs interface should be in ABI in the first place. This moves relevant part of documentation and mentions where to look for it. Fix trivial typos whilst we are at it. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-06-27leds: documentation: 'ide-disk' to 'disk-activity'Stephan Linz
Signed-off-by: Stephan Linz <linz@li-pro.net> Cc: Joseph Jezak <josejx@gentoo.org> Cc: Jörg Sommer <joerg@alea.gnuu.de> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-06-08leds: core: Fix brightness setting upon hardware blinking enabledTony Makkiel
Commit 76931edd54f8 ("leds: fix brightness changing when software blinking is active") changed the semantics of led_set_brightness() which according to the documentation should disable blinking upon any brightness setting. Moreover it made it different for soft blink case, where it was possible to change blink brightness, and for hardware blink case, where setting any brightness greater than 0 was ignored. While the change itself is against the documentation claims, it was driven also by the fact that timer trigger remained active after turning blinking off. Fixing that would have required major refactoring in the led-core, led-class, and led-triggers because of cyclic dependencies. Finally, it has been decided that allowing for brightness change during blinking is beneficial as it can be accomplished without disturbing blink rhythm. The change in brightness setting semantics will not affect existing LED class drivers that implement blink_set op thanks to the LED_BLINK_SW flag introduced by this patch. The flag state will be from now on checked in led_set_brightness() which will allow to distinguish between software and hardware blink mode. In the latter case the control will be passed directly to the drivers which apply their semantics on brightness set, which is disable the blinking in case of most such drivers. New drivers will apply new semantics and just change the brightness while hardware blinking is on, if possible. The issue was smuggled by subsequent LED core improvements, which modified the code that originally introduced the problem. Fixes: f1e80c07416a ("leds: core: Add two new LED_BLINK_ flags") Signed-off-by: Tony Makkiel <tony.makkiel@daqri.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-01-04Documentation: leds: Add description of brightness setting APIJacek Anaszewski
This patch adds description of the LED subsystem API for setting an LED brightness. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2015-07-01Merge branch 'for-next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED subsystem updates from Bryan Wu: "In this cycle, we finished to merge patches for LED Flash class driver. Other than that we have some bug fixes and new drivers for LED controllers" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (33 commits) leds:lp55xx: fix firmware loading error leds: fix max77693-led build errors leds: fix aat1290 build errors leds: aat1290: pass flags parameter to devm_gpiod_get leds: ktd2692: pass flags parameter to devm_gpiod_get drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c leds: aat1290: add support for V4L2 Flash sub-device DT: aat1290: Document handling external strobe sources leds: max77693: add support for V4L2 Flash sub-device media: Add registration helpers for V4L2 flash sub-devices v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it Documentation: leds: Add description of v4l2-flash sub-device leds: add BCM6358 LED driver leds: add DT binding for BCM6358 LED controller leds: fix brightness changing when software blinking is active Documentation: leds-lp5523: describe master fader attributes leds: lp5523: add master_fader support leds: leds-gpio: Allow compile test if !GPIOLIB leds: leds-gpio: Add missing #include <linux/of.h> gpiolib: Add missing dummies for the unified device properties interface ...
2015-06-24Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input subsystem updates from Dmitry Torokhov: "Thanks to Samuel Thibault input device (keyboard) LEDs are no longer hardwired within the input core but use LED subsystem and so allow use of different triggers; Hans de Goede did a large update for the ALPS touchpad driver; we have new TI drv2665 haptics driver and DA9063 OnKey driver, and host of other drivers got various fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (55 commits) Input: pixcir_i2c_ts - fix receive error MAINTAINERS: remove non existent input mt git tree Input: improve usage of gpiod API tty/vt/keyboard: define LED triggers for VT keyboard lock states tty/vt/keyboard: define LED triggers for VT LED states Input: export LEDs as class devices in sysfs Input: cyttsp4 - use swap() in cyttsp4_get_touch() Input: goodix - do not explicitly set evbits in input device Input: goodix - export id and version read from device Input: goodix - fix variable length array warning Input: goodix - fix alignment issues Input: add OnKey driver for DA9063 MFD part Input: elan_i2c - add product IDs FW names Input: elan_i2c - add support for multi IC type and iap format Input: focaltech - report finger width to userspace tty: remove platform_sysrq_reset_seq Input: synaptics_i2c - use proper boolean values Input: psmouse - use true instead of 1 for boolean values Input: cyapa - fix a few typos in comments Input: stmpe-ts - enforce device tree only mode ...
2015-06-11Input: export LEDs as class devices in sysfsSamuel Thibault
This change creates a new input handler called "leds" that exports LEDs on input devices as standard LED class devices in sysfs and allows controlling their state via sysfs or via any of the standard LED triggers. This allows to re-purpose and reassign LDEs on the keyboards to represent states other than the standard keyboard states (CapsLock, NumLock, etc). The old API of controlling input LEDs by writing into /dev/input/eventX devices is still present and will take precedence over accessing via LEDs subsystem (i.e. it may override state set by a trigger). If input device is "grabbed" then requests coming through LED subsystem will be ignored. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2015-06-10Documentation: leds: Add description of v4l2-flash sub-deviceJacek Anaszewski
This patch extends LED Flash class documention by the description of interactions with v4l2-flash sub-device. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-05-25Documentation: leds-lp5523: describe master fader attributesToshi Kikuchi
Add the usage of the new attributes for master faders. Signed-off-by: Toshi Kikuchi <toshik@chromium.org> Acked-by: Milo Kim <milo.kim@ti.com> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-03-09Documentation: leds: Add description of LED Flash class extensionJacek Anaszewski
The documentation being added contains overall description of the LED Flash Class and the related sysfs attributes. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-02-10Documentation/: update 00-INDEX filesHenrik Austad
Some of the 00-INDEX files are somewhat outdated and some folders does not contain 00-INDEX at all. Only outdated (with the notably exception of spi) indexes are touched here, the 169 folders without 00-INDEX has not been touched. New 00-INDEX - spi/* was added in a series of commits dating back to 2006 Added files (missing in (*/)00-INDEX) - dmatest.txt was added by commit 851b7e16a07d ("dmatest: run test via debugfs") - this_cpu_ops.txt was added by commit a1b2a555d637 ("percpu: add documentation on this_cpu operations") - ww-mutex-design.txt was added by commit 040a0a371005 ("mutex: Add support for wound/wait style locks") - bcache.txt was added by commit cafe56359144 ("bcache: A block layer cache") - kernel-per-CPU-kthreads.txt was added by commit 49717cb40410 ("kthread: Document ways of reducing OS jitter due to per-CPU kthreads") - phy.txt was added by commit ff764963479a ("drivers: phy: add generic PHY framework") - block/null_blk was added by commit 12f8f4fc0314 ("null_blk: documentation") - module-signing.txt was added by commit 3cafea307642 ("Add Documentation/module-signing.txt file") - assoc_array.txt was added by commit 3cb989501c26 ("Add a generic associative array implementation.") - arm/IXP4xx was part of the initial repo - arm/cluster-pm-race-avoidance.txt was added by commit 7fe31d28e839 ("ARM: mcpm: introduce helpers for platform coherency exit/setup") - arm/firmware.txt was added by commit 7366b92a77fc ("ARM: Add interface for registering and calling firmware-specific operations") - arm/kernel_mode_neon.txt was added by commit 2afd0a05241d ("ARM: 7825/1: document the use of NEON in kernel mode") - arm/tcm.txt was added by commit bc581770cfdd ("ARM: 5580/2: ARM TCM (Tightly-Coupled Memory) support v3") - arm/vlocks.txt was added by commit 9762f12d3e05 ("ARM: mcpm: Add baremetal voting mutexes") - blackfin/gptimers-example.c, Makefile was added by commit 4b60779d5ea7 ("Blackfin: add an example showing how to use the gptimers API") - devicetree/usage-model.txt was added by commit 31134efc681a ("dt: Linux DT usage model documentation") - fb/api.txt was added by commit fb21c2f42879 ("fbdev: Add FOURCC-based format configuration API") - fb/sm501.txt was added by commit e6a049807105 ("video, sm501: add edid and commandline support") - fb/udlfb.txt was added by commit 96f8d864afd6 ("fbdev: move udlfb out of staging.") - filesystems/Makefile was added by commit 1e0051ae48a2 ("Documentation/fs/: split txt and source files") - filesystems/nfs/nfsd-admin-interfaces.txt was added by commit 8a4c6e19cfed ("nfsd: document kernel interfaces for nfsd configuration") - ide/warm-plug-howto.txt was added by commit f74c91413ec6 ("ide: add warm-plug support for IDE devices (take 2)") - laptops/Makefile was added by commit d49129accc21 ("Documentation/laptop/: split txt and source files") - leds/leds-blinkm.txt was added by commit b54cf35a7f65 ("LEDS: add BlinkM RGB LED driver, documentation and update MAINTAINERS") - leds/ledtrig-oneshot.txt was added by commit 5e417281cde2 ("leds: add oneshot trigger") - leds/ledtrig-transient.txt was added by commit 44e1e9f8e705 ("leds: add new transient trigger for one shot timer activation") - m68k/README.buddha was part of the initial repo - networking/LICENSE.(qla3xxx|qlcnic|qlge) was added by commits 40839129f779, c4e84bde1d59, 5a4faa873782 - networking/Makefile was added by commit 3794f3e812ef ("docsrc: build Documentation/ sources") - networking/i40evf.txt was added by commit 105bf2fe6b32 ("i40evf: add driver to kernel build system") - networking/ipsec.txt was added by commit b3c6efbc36e2 ("xfrm: Add file to document IPsec corner case") - networking/mac80211-auth-assoc-deauth.txt was added by commit 3cd7920a2be8 ("mac80211: add auth/assoc/deauth flow diagram") - networking/netlink_mmap.txt was added by commit 5683264c3981 ("netlink: add documentation for memory mapped I/O") - networking/nf_conntrack-sysctl.txt was added by commit c9f9e0e1597f ("netfilter: doc: add nf_conntrack sysctl api documentation") lan) - networking/team.txt was added by commit 3d249d4ca7d0 ("net: introduce ethernet teaming device") - networking/vxlan.txt was added by commit d342894c5d2f ("vxlan: virtual extensible lan") - power/runtime_pm.txt was added by commit 5e928f77a09a ("PM: Introduce core framework for run-time PM of I/O devices (rev. 17)") - power/charger-manager.txt was added by commit 3bb3dbbd56ea ("power_supply: Add initial Charger-Manager driver") - RCU/lockdep-splat.txt was added by commit d7bd2d68aa2e ("rcu: Document interpretation of RCU-lockdep splats") - s390/kvm.txt was added by 5ecee4b (KVM: s390: API documentation) - s390/qeth.txt was added by commit b4d72c08b358 ("qeth: bridgeport support - basic control") - scheduler/sched-bwc.txt was added by commit 88ebc08ea9f7 ("sched: Add documentation for bandwidth control") - scsi/advansys.txt was added by commit 4bd6d7f35661 ("[SCSI] advansys: Move documentation to Documentation/scsi") - scsi/bfa.txt was added by commit 1ec90174bdb4 ("[SCSI] bfa: add readme file") - scsi/bnx2fc.txt was added by commit 12b8fc10eaf4 ("[SCSI] bnx2fc: Add driver documentation") - scsi/cxgb3i.txt was added by commit c3673464ebc0 ("[SCSI] cxgb3i: Add cxgb3i iSCSI driver.") - scsi/hpsa.txt was added by commit 992ebcf14f3c ("[SCSI] hpsa: Add hpsa.txt to Documentation/scsi") - scsi/link_power_management_policy.txt was added by commit ca77329fb713 ("[libata] Link power management infrastructure") - scsi/osd.txt was added by commit 78e0c621deca ("[SCSI] osd: Documentation for OSD library") - scsi/scsi-parameter.txt was created/moved by commit 163475fb111c ("Documentation: move SCSI parameters to their own text file") - serial/driver was part of the initial repo - serial/n_gsm.txt was added by commit 323e84122ec6 ("n_gsm: add a documentation") - timers/Makefile was added by commit 3794f3e812ef ("docsrc: build Documentation/ sources") - virt/kvm/s390.txt was added by commit d9101fca3d57 ("KVM: s390: diagnose call documentation") - vm/split_page_table_lock was added by commit 49076ec2ccaf ("mm: dynamically allocate page->ptl if it cannot be embedded to struct page") - w1/slaves/w1_ds28e04 was added by commit fbf7f7b4e2ae ("w1: Add 1-wire slave device driver for DS28E04-100") - w1/masters/omap-hdq was added by commit e0a29382c6f5 ("hdq: documentation for OMAP HDQ") - x86/early-microcode.txt was added by commit 0d91ea86a895 ("x86, doc: Documentation for early microcode loading") - x86/earlyprintk.txt was added by commit a1aade478862 ("x86/doc: mini-howto for using earlyprintk=dbgp") - x86/entry_64.txt was added by commit 8b4777a4b50c ("x86-64: Document some of entry_64.S") - x86/pat.txt was added by commit d27554d874c7 ("x86: PAT documentation") Moved files - arm/kernel_user_helpers.txt was moved out of arch/arm/kernel by commit 37b8304642c7 ("ARM: kuser: move interface documentation out of the source code") - efi-stub.txt was moved out of x86/ and down into Documentation/ in commit 4172fe2f8a47 ("EFI stub documentation updates") - laptops/hpfall.c was moved out of hwmon/ and into laptops/ in commit efcfed9bad88 ("Move hp_accel to drivers/platform/x86") - commit 5616c23ad9cd ("x86: doc: move x86-generic documentation from Doc/x86/i386"): * x86/usb-legacy-support.txt * x86/boot.txt * x86/zero_page.txt - power/video_extension.txt was moved to acpi in commit 70e66e4df191 ("ACPI / video: move video_extension.txt to Documentation/acpi") Removed files (left in 00-INDEX) - memory.txt was removed by commit 00ea8990aadf ("memory.txt: remove stray information") - gpio.txt was moved to gpio/ in commit fd8e198cfcaa ("Documentation: gpiolib: document new interface") - networking/DLINK.txt was removed by commit 168e06ae26dd ("drivers/net: delete old parallel port de600/de620 drivers") - serial/hayes-esp.txt was removed by commit f53a2ade0bb9 ("tty: esp: remove broken driver") - s390/TAPE was removed by commit 9e280f669308 ("[S390] remove tape block docu") - vm/locking was removed by commit 57ea8171d2bc ("mm: documentation: remove hopelessly out-of-date locking doc") - laptops/acer-wmi.txt was remvoed by commit 020036678e81 ("acer-wmi: Delete out-of-date documentation") Typos/misc issues - rpc-server-gss.txt was added as knfsd-rpcgss.txt in commit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server RPCGSS authentication.") - commit b88cf73d9278 ("net: add missing entries to Documentation/networking/00-INDEX") * generic-hdlc.txt was added as generic_hdlc.txt * spider_net.txt was added as spider-net.txt - w1/master/mxc-w1 was added as mxc_w1 by commit a5fd9139f74c ("w1: add 1-wire master driver for i.MX27 / i.MX31") - s390/zfcpdump.txt was added as zfcpdump by commit 6920c12a407e ("[S390] Add Documentation/s390/00-INDEX.") Signed-off-by: Henrik Austad <henrik@austad.us> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> [rcu bits] Acked-by: Rob Landley <rob@landley.net> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Mark Brown <broonie@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Gleb Natapov <gleb@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Len Brown <len.brown@intel.com> Cc: James Bottomley <JBottomley@parallels.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-01-27leds: lp5523: Support LED MUX configuration on running a patternMilo Kim
There are two ways to run a pattern in LP5523. One is using legacy sysfs files such as 'enginex_mode','enginex_load' and 'enginex_leds'. ('x' is from 1 to 3). Among them, 'enginex_leds' are used for selecting specific LED channel MUX. (MUX means which LEDs are used for running a pattern from LED 1 to 9.) The other way is using the firmware interface. In this mode, the default LED MUX strings are used. In other words, LED MUX is not configurable on the fly. This patch enables dynamic LED MUX configuration when the firmware is loaded. By accessing the sysfs file 'enginex_leds', the LED channels can be configured. To synchronize the operation mode, each engine mode should be set to 'LOAD'. The documentation is updated as well. Cc: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26Documentation: leds-lp5521,lp5523: update device attribute informationMilo Kim
Now, all legacy application interfaces are restored. Each driver documentation is updated. 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>
2013-08-26Documentation: leds: Fix a typoSachin Kamat
__initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Fix the example. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: support new LP8501 device - another LP55xx commonKim, Milo
LP8501 can drive up to 9 channels like LP5523. LEDs can be controlled directly via the I2C and programmable engines are supported. LP55xx common driver LP8501 is one of LP55xx family device, so LP55xx common code are used. Chip specific data is defined in the structure, 'lp55xx_device_config'. Differences between LP8501 and LP5523 Different register layout for LED output control and others. LP8501 specific feature for separate output power selection. LP8501 doesn't support external clock detection. Different programming engine data. LP8501 specific feature - output power selection Output channels are selected by power selection - Vout or Vdd. Separate power for VDD1-6 and VDD7-9 are available. It is configurable in the platform data. To support this feature, LP55xx DT structure and header are changed. Device tree binding is updated as well. LED pattern data Example pattern data is updated in the driver documentation. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-04-01leds: lp55xx: configure the clock detectionKim, Milo
Now LP55xx provides automatic clock detection API, lp55xx_is_extclk_used(). The clock configuration can be done by the driver itself. (a) Concept The default value is set by each driver with clock selection. The internal clock selection bit is updated in case that the external clock is not detected or clock rate is not 32KHz. (b) Change on LP55xx platform data The clock configuration is done automatically, so no need to define 'update_config' in the platform side. Correlated information are removed in the documentations and header. (c) Definitions moved from header to driver files CONFIG register values are moved each driver, LP5521 and LP5562. Not necessary definitions are removed also. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-04-01leds: add new LP5562 LED driverKim, Milo
LP5562 can drive up to 4 channels, RGB and White. LEDs can be controlled directly via the led class control interface. LP55xx common driver LP5562 is one of LP55xx family device, so LP55xx common code are used. On the other hand, chip specific configuration is defined in the structure 'lp55xx_device_config' LED pattern data LP5562 has also internal program memory which is used for running various LED patterns. LP5562 driver supports the firmware interface and the predefined pattern data as well. LP5562 device attributes: 'led_pattern' and 'engine_mux' A 'led_pattern' is an index code which runs the predefined pattern data. And 'engine_mux' is updated with the firmware interface is activated. Detailed description has been updated in the documentation files, 'leds-lp55xx.txt' and 'leds-lp5562.txt'. Changes on the header file LP5562 configurable definitions are added. Pattern RGB data is fixed as constant value. (No side effect on other devices, LP5521 or LP5523.) (cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan Carpenter <dan.carpenter@oracle.com>) Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-06Documentation: leds: update LP55xx family devicesMilo(Woogyom) Kim
Update changed platform data information. Add leds-lp55xx.txt which includes the firmware interface description. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2012-09-11leds-lp5523: add channel name in the platform dataKim, Milo
The name of each led channel is configurable. If the name is NULL, just use the channel id for making the channel name Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24LEDS: add BlinkM RGB LED driver, documentation and update MAINTAINERSJan-Simon Möller
Add driver for BlinkM device to drivers/leds/. Add entry to MAINTAINERS file. Add documentation in Documentation/leds/. A BlinkM is a RGB LED controlled through I2C. This driver implements an interface to the LED framework and another sysfs group to access the internal options of the BlinkM. rev6: Use module_i2c_driver(). rev5: Removed own workqueue in favor of events wq. rev4: Fixed comments by Bryan Wu. rev3: Fixed issues found by Jonathan Neuschäfer. (bryan.wu@canonical.com: remove 2 trailing whitespace) Signed-off-by: Jan-Simon Möller <jansimon.moeller@gmx.de> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24leds: Add LED driver for lm3556 chipG.Shark Jeong
LM3556 : The LM3556 is a 4 MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. Datasheet: www.national.com/ds/LM/LM3556.pdf Tested on OMAP4430 (bryan.wu@canonical.com: use module_i2c_driver() rather than lm3556_init/lm3556_exit for code simplicity; fixed some typo pointed out by Rob Landley) Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Reviewed-by: Axel Lin <axel.lin@gmail.com> Reviewed-by: Kim, Milo <Milo.Kim@ti.com> Acked-by: Rob Landley <rob@landley.net> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24leds: add oneshot triggerFabio Baltieri
Add oneshot trigger to blink a led with configurale parameters via sysfs. Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com> Cc: Shuah Khan <shuahkhan@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-05-29leds: add new transient trigger for one shot timer activationShuah Khan
The leds timer trigger does not currently have an interface to activate a one shot timer. The current support allows for setting two timers, one for specifying how long a state to be on, and the second for how long the state to be off. The delay_on value specifies the time period an LED should stay in on state, followed by a delay_off value that specifies how long the LED should stay in off state. The on and off cycle repeats until the trigger gets deactivated. There is no provision for one time activation to implement features that require an on or off state to be held just once and then stay in the original state forever. Without one shot timer interface, user space can still use timer trigger to set a timer to hold a state, however when user space application crashes or goes away without deactivating the timer, the hardware will be left in that state permanently. As a specific example of this use-case, let's look at vibrate feature on phones. Vibrate function on phones is implemented using PWM pins on SoC or PMIC. There is a need to activate one shot timer to control the vibrate feature, to prevent user space crashes leaving the phone in vibrate mode permanently causing the battery to drain. This trigger exports three properties, activate, state, and duration When transient trigger is activated these properties are set to default values. - duration allows setting timer value in msecs. The initial value is 0. - activate allows activating and deactivating the timer specified by duration as needed. The initial and default value is 0. This will allow duration to be set after trigger activation. - state allows user to specify a transient state to be held for the specified duration. Signed-off-by: Shuah Khan <shuahkhan@gmail.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: NeilBrown <neilb@suse.de> Cc: Bryan Wu <bryan.wu@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-23drivers/leds/leds-lp5521.c: support led pattern dataKim, Milo
The lp5521 has autonomous operation mode without external control. Using lp5521_platform_data, various led patterns can be configurable. For supporting this feature, new functions and device attribute are added. Structure of lp5521_led_pattern: 3 channels are supported - red, green and blue. Pattern(s) of each channel and numbers of pattern(s) are defined in the pla= tform data. Pattern data are hexa codes which include pattern commands such like set pwm, wait, ramp up/down, branch and so on. Pattern mode functions: * lp5521_clear_program_memory Before running new led pattern, program memory should be cleared. * lp5521_write_program_memory Pattern data updated in the program memory via the i2c. * lp5521_get_pattern Get pattern from predefined in the platform data. * lp5521_run_led_pattern Stop current pattern or run new pattern. Transition time is required between different operation mode. Device attribute - 'led_pattern': To load specific led pattern, new device attribute is added. When the lp5521 driver is unloaded, stop current led pattern mode. Documentation updated : description about how to define the led patterns and example. [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Arun MURTHY <arun.murthy@stericsson.com> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-23drivers/leds/leds-lp5521.c: add 'update_config' in the lp5521_platform_dataKim, Milo
The value of CONFIG register(Addr 08h) is configurable. For supporting this feature, update_config is added in the platform data. If 'update_config' is not defined, the default value is 'LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT'. To define CONFIG register in the platform data, the bit definitions were mo= ved to the header file. Documentation updated : description about 'update_config' and example. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Arun MURTHY <arun.murthy@stericsson.com> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-23drivers/leds/leds-lp5521.c: add 'name' in the lp5521_led_configKim, Milo
The name of each led channel can be configurable. For the compatibility, the name is set to default value(xx:channelN) when 'name' is not defined. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Arun MURTHY <arun.murthy@stericsson.com> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-11-04Documentation: fix leds-class.txt duplicated wordBryan Wu
Fix a typo (duplicated word) in Documentation/leds/leds-class.txt Signed-off-by: Bryan Wu <bryan.wu@canonical.com> Acked-by: Richard Purdie <rchard.purdie@linuxfoundation.org> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-04-04Documentation: consolidate leds files to leds/ subdirAntonio Ospite
leds: move leds-class documentation under the leds/ subdir. Add also a leds/00-INDEX file describing the files under leds/ Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-12Documentation: led drivers lp5521 and lp5523Samu Onkalo
Create sub directory Documentation/leds and add short documentation for LP5521 and LP5523 drivers. Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>