11 Jan, 2012
1 commit
-
Factor out some boilerplate code for platform driver registration into
module_platform_driver.Signed-off-by: Axel Lin
Acked-by: Haojian Zhuang [led-88pm860x.c]
Acked-by: Mark Brown
Cc: Richard Purdie
Cc: Michael Hennerich
Cc: Mike Rapoport
Cc: Guennadi Liakhovetski
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Nov, 2011
1 commit
-
* '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
acpi: remove module.h include from platform/aclinux.h
miscdevice.h: delete unnecessary inclusion of module.h
device_cgroup.h: delete needless include
net: sch_generic remove redundant use of
net: inet_timewait_sock doesnt need
...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
01 Nov, 2011
2 commits
-
I get the following warning:
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:1559 __gpio_get_value+0x90/0x98()
Modules linked in:
Call Trace:
[] dump_stack+0x8/0x34
[] warn_slowpath_common+0x78/0xa0
[] __gpio_get_value+0x90/0x98
[] create_gpio_led+0xdc/0x194
[] gpio_led_probe+0x290/0x36c
[] driver_probe_device+0x78/0x1b0
[] __driver_attach+0xc0/0xc8
[] bus_for_each_dev+0x64/0xb0
[] bus_add_driver+0x1c8/0x2a8
[] driver_register+0x90/0x180
[] 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
Cc: Richard Purdie
Acked-by: Trent Piepho
Cc: Grant Likely
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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 explicitly in advance.Signed-off-by: Paul Gortmaker
04 Jun, 2011
1 commit
-
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
[grant.likely: also remove LEDS_GPIO_OF for same reason]
Signed-off-by: Grant Likely
28 Feb, 2011
1 commit
-
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
12 Nov, 2010
1 commit
-
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
Acked-by: Richard Purdie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Aug, 2010
1 commit
-
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_deviceSigned-off-by: Grant Likely
Reviewed-by: David S. Miller
28 May, 2010
1 commit
-
Fix a compile issue when openfirmware is enabled from commit
2146325df2c2640059a9e064890c30c6e259b458.Signed-off-by: Richard Purdie
26 May, 2010
1 commit
-
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
Signed-off-by: Richard Purdie
22 May, 2010
1 commit
-
.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
Acked-by: Sean MacLennan
19 May, 2010
1 commit
-
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
30 Mar, 2010
1 commit
-
…it 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 allmodconfig8. 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>
17 Mar, 2010
1 commit
-
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
Signed-off-by: Andrew Morton
Signed-off-by: Richard Purdie
16 Nov, 2009
1 commit
-
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
Signed-off-by: Richard Purdie
07 Sep, 2009
1 commit
-
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Michal Simek
Signed-off-by: Andrew Morton
Signed-off-by: Richard Purdie
24 Jun, 2009
2 commits
-
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
Acked-by: Grant Likely
Acked-by: Wolfram Sang
Acked-by: Sean MacLennan
Signed-off-by: Richard Purdie -
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
Signed-off-by: Andrew Morton
Signed-off-by: Richard Purdie
08 Apr, 2009
1 commit
-
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-voidSigned-off-by: David Brownell
Signed-off-by: Richard Purdie
06 Apr, 2009
4 commits
-
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
Tested-by: Diego Dompe
Signed-off-by: Richard Purdie -
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
Signed-off-by: Richard Purdie -
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
-
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
. They have been extended to allow multiple LEDs
per device.Signed-off-by: Trent Piepho
Acked-by: Grant Likely
Acked-by: Sean MacLennan
Signed-off-by: Richard Purdie
09 Jan, 2009
1 commit
-
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.
25 Apr, 2008
1 commit
-
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
Signed-off-by: Richard Purdie
16 Apr, 2008
1 commit
-
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
Signed-off-by: David Brownell
Acked-by: Richard Purdie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Apr, 2008
2 commits
-
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
Signed-off-by: Richard Purdie -
Call gpio_cansleep only after gpio_request succeeded avoiding an
oops.Signed-off-by: Uwe Kleine-König
Acked-by: David Brownell
Signed-off-by: Richard Purdie
07 Feb, 2008
1 commit
-
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
Signed-off-by: Richard Purdie
06 Nov, 2007
1 commit
-
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
Signed-off-by: Richard Purdie
16 Jul, 2007
2 commits
-
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
Signed-off-by: Richard Purdie -
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
Signed-off-by: Richard Purdie