summaryrefslogtreecommitdiff
path: root/drivers/leds/leds-gpio.c
AgeCommit message (Collapse)AuthorFilesLines
2013-06-21leds: leds-gpio: Let device core handle pinctrlFabio Estevam1-6/+0
Since commit ab78029 (drivers/pinctrl: grab default handles from device core) we can rely on device core for handling pinctrl, so remove devm_pinctrl_get_select_default() from the driver. Reported-by: Stephen Warren <warren@wwwdotorg.org> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-21leds: leds-gpio: remove unnecessary platform_set_drvdata()Jingoo Han1-2/+0
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-05-21leds: leds-gpio: reserve gpio before using itTimo Teräs1-4/+5
This reverts commit a99d76f (leds: leds-gpio: use gpio_request_one) and commit 2d7c22f (leds: leds-gpio: set devm_gpio_request_one() flags param correctly) which was a fix of the first one. The conversion to devm_gpio_request in commit e3b1d44c (leds: leds-gpio: use devm_gpio_request_one) is not reverted. The problem is that gpio_cansleep() and gpio_get_value_cansleep() calls can crash if the gpio is not first reserved. Incidentally this same bug existed earlier and was fixed similarly in commit d95cbe61 (leds: Fix potential leds-gpio oops). But the OOPS is real. It happens when GPIOs are provided by module which is not yet loaded. So this fixes the following BUG during my ALIX boot (3.9.2-vanilla): BUG: unable to handle kernel NULL pointer dereference at 0000004c IP: [<c11287d6>] __gpio_cansleep+0xe/0x1a *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: leds_gpio(+) via_rhine mii cs5535_mfd mfd_core geode_rng rng_core geode_aes isofs nls_utf8 nls_cp437 vfat fat ata_generic pata_amd pata_cs5536 pata_acpi libata ehci_pci ehci_hcd ohci_hcd usb_storage usbcore usb_common sd_mod scsi_mod squashfs loop Pid: 881, comm: modprobe Not tainted 3.9.2 #1-Alpine EIP: 0060:[<c11287d6>] EFLAGS: 00010282 CPU: 0 EIP is at __gpio_cansleep+0xe/0x1a EAX: 00000000 EBX: cf364018 ECX: c132b8b9 EDX: 00000000 ESI: c13993a4 EDI: c1399370 EBP: cded9dbc ESP: cded9dbc DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: 0000004c CR3: 0f0c4000 CR4: 00000090 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process modprobe (pid: 881, ti=cded8000 task=cf094aa0 task.ti=cded8000) Stack: cded9de0 d09471cb 00000000 c1399260 cf364014 00000000 c1399260 c1399254 d0949014 cded9df4 c118cd59 c1399260 d0949014 d0949014 cded9e08 c118ba47 c1399260 d0949014 c1399294 cded9e1c c118bb75 cded9e24 d0949014 00000000 Call Trace: [<d09471cb>] gpio_led_probe+0xba/0x203 [leds_gpio] [<c118cd59>] platform_drv_probe+0x26/0x48 [<c118ba47>] driver_probe_device+0x75/0x15c [<c118bb75>] __driver_attach+0x47/0x63 [<c118a727>] bus_for_each_dev+0x3c/0x66 [<c118b6f9>] driver_attach+0x14/0x16 [<c118bb2e>] ? driver_probe_device+0x15c/0x15c [<c118b3d5>] bus_add_driver+0xbd/0x1bc [<d08b4000>] ? 0xd08b3fff [<d08b4000>] ? 0xd08b3fff [<c118bffc>] driver_register+0x74/0xec [<d08b4000>] ? 0xd08b3fff [<c118c8e8>] platform_driver_register+0x38/0x3a [<d08b400d>] gpio_led_driver_init+0xd/0x1000 [leds_gpio] [<c100116c>] do_one_initcall+0x6b/0x10f [<d08b4000>] ? 0xd08b3fff [<c105e918>] load_module+0x1631/0x1907 [<c10975d6>] ? insert_vmalloc_vmlist+0x14/0x43 [<c1098d5b>] ? __vmalloc_node_range+0x13e/0x15f [<c105ec50>] sys_init_module+0x62/0x77 [<c1257888>] syscall_call+0x7/0xb EIP: [<c11287d6>] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc CR2: 000000000000004c ---[ end trace 5308fb20d2514822 ]--- Signed-off-by: Timo Teräs <timo.teras@iki.f> Cc: Sachin Kamat <sachin.kamat@linaro.org> Cc: Raphael Assenat <raph@8d.com> Cc: Trent Piepho <tpiepho@freescale.com> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Cc: Arnaud Patard <arnaud.patard@rtp-net.org> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-01-03leds: leds-gpio: set devm_gpio_request_one() flags param correctlyJavier Martinez Canillas1-2/+3
commit a99d76f leds: leds-gpio: use gpio_request_one changed the leds-gpio driver to use gpio_request_one() instead of gpio_request() + gpio_direction_output() Unfortunately, it also made a semantic change that breaks the leds-gpio driver. The gpio_request_one() flags parameter was set to: GPIOF_DIR_OUT | (led_dat->active_low ^ state) Since GPIOF_DIR_OUT is 0, the final flags value will just be the XOR'ed value of led_dat->active_low and state. This value were used to distinguish between HIGH/LOW output initial level and call gpio_direction_output() accordingly. With this new semantic gpio_request_one() will take the flags value of 1 as a configuration of input direction (GPIOF_DIR_IN) and will call gpio_direction_input() instead of gpio_direction_output(). int gpio_request_one(unsigned gpio, unsigned long flags, const char *label) { .. if (flags & GPIOF_DIR_IN) err = gpio_direction_input(gpio); else err = gpio_direction_output(gpio, (flags & GPIOF_INIT_HIGH) ? 1 : 0); .. } The right semantic is to evaluate led_dat->active_low ^ state and set the output initial level explicitly. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Reported-by: Arnaud Patard <arnaud.patard@rtp-net.org> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2012-12-16Merge branch 'for-next' of ↵Linus Torvalds1-19/+18
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED subsystem update from Bryan Wu. * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (47 commits) leds: leds-lp5521: return an error code on error in probe() leds: leds-clevo-mail: Use pr_* instead of printks leds: leds-rb532: Fix checkpatch errors leds: led-triggers: Fix checkpatch warnings leds: ledtrig-backlight: Fix checkpatch error leds: leds-wrap: Use <linux/io.h> instead of <asm/io.h> leds: leds-wm8350: Use dev_err instead of printk leds: leds-pwm: Fix checkpatch warning leds: leds-pca955x: Use dev_info instead of printk leds: leds-net48xx: Use linux/io.h instead of asm/io.h leds: leds-lt3593: Fix checkpatch warnings leds: leds-gpio: Use dev_info instead of printk leds: leds-da903x: Fix checkpatch error and warnings leds: leds-bd2802: Fix checkpatch warnings leds: leds-adp5520: Fix checkpatch warnings leds: led-class: Fix checkpatch warning leds: leds-ns2: use devm_gpio_request_one leds: leds-lt3593: use devm_gpio_request_one leds: leds-gpio: use devm_gpio_request_one leds: lp3944: Fix return value ...
2012-11-29leds: remove use of __devexitBill Pemberton1-1/+1
CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jan-Simon Moeller <jansimon.moeller@gmx.de> Acked-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-29leds: remove use of __devinitBill Pemberton1-4/+4
CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jan-Simon Moeller <jansimon.moeller@gmx.de> Acked-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-29leds: remove use of __devexit_pBill Pemberton1-1/+1
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jan-Simon Moeller <jansimon.moeller@gmx.de> Acked-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-28leds: leds-gpio: Use dev_info instead of printkSachin Kamat1-1/+1
Fixes the following checkpatch warning: WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ... FILE: leds/leds-gpio.c:105: printk(KERN_INFO "Skipping unavailable LED gpio %d (%s)\n", Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2012-11-28leds: leds-gpio: use devm_gpio_request_oneSachin Kamat1-6/+2
devm_gpio_request_one is device managed and makes error handling and cleanup simpler. Cc: Raphael Assenat <raph@8d.com> Cc: Trent Piepho <tpiepho@freescale.com> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2012-11-27leds: leds-gpio: Defer probing in case of deferred gpio probingRoland Stigge1-6/+11
This patch makes leds-gpio's probe() return -EPROBE_DEFER if any of the gpios to register are deferred themselves. This makes a change of gpio_leds_create_of()'s return value necessary: Instead of returning NULL on error, we now use ERR_PTR() error coding. Signed-off-by: Roland Stigge <stigge@antcom.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2012-11-27leds: leds-gpio: use gpio_request_oneJingoo Han1-7/+5
Using gpio_request_one can make the code simpler because it can set the direction and initial value in one shot. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2012-09-11leds: leds-gpio: adopt pinctrl supportAnilKumar Ch1-0/+7
Adopt pinctrl support to leds-gpio driver based on leds-gpio device pointer, pinctrl driver configure SoC pins to GPIO mode according to definitions provided in .dts file. Signed-off-by: AnilKumar Ch <anilkumar@ti.com> Acked-by: Marek Vasut <marex@denx.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-11leds: leds-gpio: Use of_get_child_count() helperTobias Klauser1-3/+2
Use of_get_child_count() instead of custom implementation. Signed-off-by: Tobias Klauser <klto@zhaw.ch> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-11leds: leds-gpio: Use platform_{get,set}_drvdataTobias Klauser1-2/+2
Use the wrapper functions, so we can directly pass a struct platfrom_device. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-11leds: leds-gpio: use of_match_ptr()Tobias Klauser1-2/+1
Instead of having to define the match table to NULL if CONFIG_OF isn't set, use the of_match_ptr() macro which will do this for us. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24leds: Use devm_kzalloc in leds-gpio.c fileSachin Kamat1-6/+5
devm_kzalloc() makes cleanup simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-03-24drivers/leds/leds-gpio.c: use linux/gpio.h rather than asm/gpio.hMark Brown1-2/+1
Direct usage of the asm include has long been deprecated by the introduction of gpiolib. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.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-01-11leds: convert led platform drivers to module_platform_driverAxel Lin1-14/+2
Factor out some boilerplate code for platform driver registration into module_platform_driver. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Haojian Zhuang <hzhuang1@marvell.com> [led-88pm860x.c] Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Michael Hennerich <hennerich@blackfin.uclinux.org> Cc: Mike Rapoport <mike@compulab.co.il> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-11-07Merge branch 'modsplit-Oct31_2011' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux * 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits) Revert "tracing: Include module.h in define_trace.h" irq: don't put module.h into irq.h for tracking irqgen modules. bluetooth: macroize two small inlines to avoid module.h ip_vs.h: fix implicit use of module_get/module_put from module.h nf_conntrack.h: fix up fallout from implicit moduleparam.h presence include: replace linux/module.h with "struct module" wherever possible include: convert various register fcns to macros to avoid include chaining crypto.h: remove unused crypto_tfm_alg_modname() inline uwb.h: fix implicit use of asm/page.h for PAGE_SIZE pm_runtime.h: explicitly requires notifier.h linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h miscdevice.h: fix up implicit use of lists and types stop_machine.h: fix implicit use of smp.h for smp_processor_id of: fix implicit use of errno.h in include/linux/of.h of_platform.h: delete needless include <linux/module.h> acpi: remove module.h include from platform/aclinux.h miscdevice.h: delete unnecessary inclusion of module.h device_cgroup.h: delete needless include <linux/module.h> net: sch_generic remove redundant use of <linux/module.h> net: inet_timewait_sock doesnt need <linux/module.h> ... Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in - drivers/media/dvb/frontends/dibx000_common.c - drivers/media/video/{mt9m111.c,ov6650.c} - drivers/mfd/ab3550-core.c - include/linux/dmaengine.h
2011-11-01drivers/leds/leds-gpio.c: use gpio_get_value_cansleep() when initializingDavid Daney1-1/+1
I get the following warning: ------------[ cut here ]------------ WARNING: at drivers/gpio/gpiolib.c:1559 __gpio_get_value+0x90/0x98() Modules linked in: Call Trace: [<ffffffff81440950>] dump_stack+0x8/0x34 [<ffffffff81141478>] warn_slowpath_common+0x78/0xa0 [<ffffffff812f0958>] __gpio_get_value+0x90/0x98 [<ffffffff81434f04>] create_gpio_led+0xdc/0x194 [<ffffffff8143524c>] gpio_led_probe+0x290/0x36c [<ffffffff8130e8b0>] driver_probe_device+0x78/0x1b0 [<ffffffff8130eaa8>] __driver_attach+0xc0/0xc8 [<ffffffff8130d7ac>] bus_for_each_dev+0x64/0xb0 [<ffffffff8130e130>] bus_add_driver+0x1c8/0x2a8 [<ffffffff8130f100>] driver_register+0x90/0x180 [<ffffffff81100438>] do_one_initcall+0x38/0x160 ---[ end trace ee38723fbefcd65c ]--- My GPIOs are on an I2C port expander, so we must use the *_cansleep() variant of the GPIO functions. This is was not being done in create_gpio_led(). We can change gpio_get_value() to gpio_get_value_cansleep() because it is only called from the platform_driver probe function, which is a context where we can sleep. Only tested on my gpio_cansleep() system, but it seems safe for all systems. Signed-off-by: David Daney <david.daney@cavium.com> Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by: Trent Piepho <tpiepho@gmail.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-11-01drivers/leds: Add module.h to files using it implicitlyPaul Gortmaker1-0/+1
A pending cleanup will mean that module.h won't be implicitly everywhere anymore. Make sure the modular drivers in the leds dir are actually calling out for <module.h> explicitly in advance. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-03leds: remove config option LEDS_GPIO_PLATFORM from KconfigShawn Guo1-3/+3
Since the commit a314c5c0040aab51ebb1ecfd37a9198a91962243 (leds/leds-gpio: merge platform_driver with of_platform_driver), the config option LEDS_GPIO_PLATFORM becomes useless, so remove it. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> [grant.likely: also remove LEDS_GPIO_OF for same reason] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-02-28leds/leds-gpio: merge platform_driver with of_platform_driverGrant Likely1-127/+87
Both interfaces can be driven with the same driver, and of_platform_driver is getting removed. This patch merges the two driver registrations. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2010-11-12drivers/leds/leds-gpio.c: properly initialize return valueDavidlohr Bueso1-1/+1
In the event that none of the configs are set (CONFIG_LEDS_GPIO_PLATFORM, CONFIG_LEDS_GPIO_OF, CONFIG_LEDS_GPIO_PLATFORM), we will return a bogus value when initializing the module. Signed-off-by: Davidlohr Bueso <dave@gnu.org> Acked-by: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-06of/device: Replace struct of_device with struct platform_deviceGrant Likely1-2/+2
of_device is just an alias for platform_device, so remove it entirely. Also replace to_of_device() with to_platform_device() and update comment blocks. This patch was initially generated from the following semantic patch, and then edited by hand to pick up the bits that coccinelle didn't catch. @@ @@ -struct of_device +struct platform_device Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Reviewed-by: David S. Miller <davem@davemloft.net>
2010-05-28leds: Fix leds-gpio openfirmware compile issueRichard Purdie1-1/+0
Fix a compile issue when openfirmware is enabled from commit 2146325df2c2640059a9e064890c30c6e259b458. Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-26leds: leds-gpio: Change blink_set callback to be able to turn off blinkingBenjamin Herrenschmidt1-7/+24
The leds-gpio blink_set() callback follows the same prototype as the main leds subsystem blink_set() one. The problem is that to stop blink, normally, a leds driver does it in the brightness_set() callback when asked to set a new fixed value. However, with leds-gpio, the platform has no hook to do so, as this later callback results in a standard GPIO manipulation. This changes the leds-gpio specific callback to take a new argument that indicates whether the LED should be blinking or not and in what state it should be set if not. We also update the dns323 platform which seems to be the only user of this so far. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-22of: Remove duplicate fields from of_platform_driverGrant Likely1-1/+1
.name, .match_table and .owner are duplicated in both of_platform_driver and device_driver. This patch is a removes the extra copies from struct of_platform_driver and converts all users to the device_driver members. This patch is a pretty mechanical change. The usage model doesn't change and if any drivers have been missed, or if anything has been fixed up incorrectly, then it will fail with a compile time error, and the fixup will be trivial. This patch looks big and scary because it touches so many files, but it should be pretty safe. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Sean MacLennan <smaclennan@pikatech.com>
2010-05-19of: Always use 'struct device.of_node' to get device node pointer.Grant Likely1-1/+1
The following structure elements duplicate the information in 'struct device.of_node' and so are being eliminated. This patch makes all readers of these elements use device.of_node instead. (struct of_device *)->node (struct dev_archdata *)->prom_node (sparc) (struct dev_archdata *)->of_node (powerpc & microblaze) Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo1-0/+1
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-16leds-gpio: fix default state handling on OF platformsAnton Vorontsov1-2/+1
The driver wrongly sets default state for LEDs that don't specify default-state property. Currently the driver handles default state this way: memset(&led, 0, sizeof(led)); for_each_child_of_node(np, child) { state = of_get_property(child, "default-state", NULL); if (state) { if (!strcmp(state, "keep")) led.default_state = LEDS_GPIO_DEFSTATE_KEEP; ... } ret = create_gpio_led(&led, ...); } Which means that all LEDs that do not specify default-state will inherit the last value of the default-state property, which is wrong. This patch fixes the issue by moving LED's template initialization into the loop body. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-11-16leds-gpio: fix possible crash on OF device unbindingDmitry Eremin-Solenikov1-0/+2
If there are leds present in the OF tree, but the GPIOs for (some) of them are unavailable, led_data doesn't get populated with correct devices. Then, on device unbinding, one can crash the kernel. Workaround this by setting led->gpio to invalid value early. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-09-07leds: gpio-leds: fix typographics faultMichal Simek1-1/+1
[akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-23leds: Add options to have GPIO LEDs start on or keep their stateTrent Piepho1-3/+17
There already is a "default-on" trigger but there are problems with it. For one, it's a inefficient way to do it and requires led trigger support to be compiled in. But the real reason is that is produces a glitch on the LED. The GPIO is allocate with the LED *off*, then *later* when the trigger runs it is turned back on. If the LED was already on via the GPIO's reset default or action of the firmware, this produces a glitch where the LED goes from on to off to on. While normally this is fast enough that it wouldn't be noticeable to a human observer, there are still serious problems. One is that there may be something else on the GPIO line, like a hardware alarm or watchdog, that is fast enough to notice the glitch. Another is that the kernel may panic before the LED is turned back on, thus hanging with the LED in the wrong state. This is not just speculation, but actually happened to me with an embedded system that has an LED which should turn off when the kernel finishes booting, which was left in the incorrect state due to a bug in the OF LED binding code. We also let GPIO LEDs get their initial value from whatever the current state of the GPIO line is. On some systems the LEDs are put into some state by the firmware or hardware before Linux boots, and it is desired to have them keep this state which is otherwise unknown to Linux. This requires that the underlying GPIO driver support reading the value of output GPIOs. Some drivers support this and some do not. The platform device binding gains a field in the platform data "default_state" that controls this. There are three constants defined to select from on, off, or keeping the current state. The OpenFirmware binding uses a property named "default-state" that can be set to "on", "off", or "keep". The default if the property isn't present is off. Signed-off-by: Trent Piepho <xyzzy@speakeasy.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Sean MacLennan <smaclennan@pikatech.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-23leds: leds-gpio - fix a section mismatchZhenwen Xu1-1/+1
WARNING: drivers/leds/leds-gpio.o(.text+0x153): Section mismatch in reference from the function gpio_led_probe() to the function .devinit.text:create_gpio_led() The function gpio_led_probe() references the function __devinit create_gpio_led(). This is often because gpio_led_probe lacks a __devinit annotation or the annotation of create_gpio_led is wrong. Signed-off-by: Zhenwen Xu <helight.xu@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-08leds: just ignore invalid GPIOs in leds-gpioDavid Brownell1-1/+1
Fix build problems with leds-gpio: CC drivers/leds/leds-gpio.o drivers/leds/leds-gpio.c: In function 'create_gpio_led': drivers/leds/leds-gpio.c:85: warning: 'return' with no value, in function returning non-void Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-06leds: just ignore invalid GPIOs in leds-gpioDavid Brownell1-0/+9
Sometimes it's awkward to make sure that the array in the platform_data handed to the leds-gpio driver has only valid data ... some leds may not be always available, and coping with that currently requires patching or rebuilding the array. This patch fixes that by making it be OK to pass an invalid GPIO (such as "-EINVAL") ... such table entries are skipped. [rpurdie@linux.intel.com: adjusted to apply against other led tree changes] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Tested-by: Diego Dompe <diego.dompe@ridgerun.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-06leds: Add suspend/resume state flags to leds-gpioRichard Purdie1-1/+2
Add an option to preserve LED state when suspending/resuming to the LED gpio driver. Based on a suggestion from Robert Jarzmik. Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-06leds: Fix leds-gpio driver multiple module_init/exit usageRichard Purdie1-19/+27
You can't have multiple module_init()/module_exit calls so resort to messy ifdefs potentially pending some code refactoring. Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-06leds: Add openfirmware platform device supportTrent Piepho1-43/+162
Add bindings to support LEDs defined as of_platform devices in addition to the existing bindings for platform devices. New options in Kconfig allow the platform binding code and/or the of_platform code to be turned on. The of_platform code is of course only available on archs that have OF support. The existing probe and remove methods are refactored to use new functions create_gpio_led(), to create and register one led, and delete_gpio_led(), to unregister and free one led. The new probe and remove methods for the of_platform driver can then share most of the common probe and remove code with the platform driver. The suspend and resume methods aren't shared, but they are very short. The actual led driving code is the same for LEDs created by either binding. The OF bindings are based on patch by Anton Vorontsov <avorontsov@ru.mvista.com>. They have been extended to allow multiple LEDs per device. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Sean MacLennan <smaclennan@pikatech.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-08leds: Add suspend/resume to the core classRichard Purdie1-35/+1
Add suspend/resume to the core class and remove all the now unneeded code from various drivers. Originally the class code couldn't support suspend/resume but since class_device can there is no reason for each driver doing its own suspend/resume anymore.
2008-04-25leds: enable support for blink_set() platform hook in leds-gpioHerbert Valerio Riedel1-0/+15
Enhance leds-gpio to provide hardware-based led flashing by passing through the blink_set() call to a optionally set platform-specific function pointer. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-04-16leds: fix platform driver hotplug/coldplugKay Sievers1-0/+1
Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform modalias is prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable platform LED drivers, to re-enable auto loading. [dbrownell@users.sourceforge.net: more drivers, registration fixes] Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-01leds: Remove incorrect use of preempt_count() from leds-gpioDavid Brownell1-6/+6
It appears that we can't just check to see if we're in a task context ... so instead of trying that, just make the relevant leds always schedule a little worklet. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-04-01leds: Fix potential leds-gpio oopsUwe Kleine-König1-4/+4
Call gpio_cansleep only after gpio_request succeeded avoiding an oops. Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-02-07leds: Fix led-gpio active_low default brightnessRaphael Assenat1-1/+1
When gpio_direction_output() is called, led_dat->active_low is used as default value. This means that the led will always be off by default. cdev.brightness should really have been set to LED_OFF unconditionally to reflect this behavior. Signed-off-by: Raphael Assenat <raph@8d.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-11-06leds: bugfixes for leds-gpioDavid Brownell1-9/+11
Three bugfixes to the leds-gpio driver, plus minor whitespace tweaks: - Do the INIT_WORK() before registering each LED, so if its trigger becomes immediately active it can schedule work without oopsing.. - Use normal registration, not platform_driver_probe(), so that devices appearing "late" (hotplug type) can still be bound. - Mark the driver remove code as "__devexit", preventing oopses when the underlying device is removed. These issues came up when using this driver with some GPIO expanders living on serial busses, which act unlike "normal" platform devices: they can appear and vanish along with the serial bus driver. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-07-16leds: Teach leds-gpio to handle timer-unsafe GPIOsDavid Brownell1-1/+26
Teach the new leds-gpio driver that some GPIOs can't be accessed from timer callbacks ... which is how all today's standard triggers use them. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-07-16leds: Add generic GPIO LED driverRaphael Assenat1-0/+174
This patch adds support for GPIO connected leds via the new GPIO framework. Information about leds (gpio, polarity, name, default trigger) is passed to the driver via platform_data. Signed-off-by: Raphael Assenat <raph@8d.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>