- 23 Mar, 2012 40 commits
-
-
Srinidhi KASAGAR authored
Fix it by assigning the lp5521_read return value. Signed-off-by:
srinidhi kasagar <srinidhi.kasagar@stericsson.com> Cc: Milo(Woogyom) Kim <milo.kim@ti.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Arun MURTHY <arun.murthy@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>
-
Kim, Milo authored
For better readability, values of LP5521_REG_ENABLE register were redefined= . Additional definitions: LP5521_ENABLE_DEFAULT and LP5521_ENABLE_RUN_PROGRAM= . Use definition rather than hard code value. : 0x3F -> 'LP5521_CMD_DIRECT' 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:
-
Kim, Milo authored
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:
-
Kim, Milo authored
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:
-
Kim, Milo authored
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:
-
Wolfram Sang authored
A few new i2c-drivers came into the kernel which clear the clientdata-pointer on exit or error. This is obsolete meanwhile, the core will do it. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Cc: NeilBrown <neilb@suse.de> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by:
-
Dan Carpenter authored
Just a small tidy-up. 1) There is a NULL dereference if the tca allocation fails. 2) The call to cancel_work_sync() isn't needed because we haven't scheduled any work. 3) The call to i2c_set_clientdata() isn't needed because the core handles that automatically if probe() fails. 4) I added some curly braces for style reasons. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Masanari Iida authored
"reseting" -> "resetting" Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Akinobu Mita authored
Use for_each_clear_bit() to iterate over all the cleared bit in a memory region. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Akinobu Mita authored
Use for_each_clear_bit() to iterate over all the cleared bit in a memory region. Signed-off-by:
-
Akinobu Mita authored
Use for_each_clear_bit() to iterate over all the cleared bit in a memory region. Signed-off-by:
-
Akinobu Mita authored
Use for_each_clear_bit() to iterate over all the cleared bit in a memory region. Signed-off-by:
-
Akinobu Mita authored
Introduce for_each_clear_bit() and for_each_clear_bit_from(). They are similar to for_each_set_bit() and list_for_each_set_bit_from(), but they iterate over all the cleared bits in a memory region. Signed-off-by:
-
Akinobu Mita authored
Remove for_each_set_bit_cont() after confirming that no one uses for_each_set_bit_cont() anymore. [sfr@canb.auug.org.au: regmap: cope with bitops API change] Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Robert Richter <robert.richter@amd.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Akinobu Mita authored
This renames for_each_set_bit_cont() to for_each_set_bit_from() because it is analogous to list_for_each_entry_from() in list.h rather than list_for_each_entry_continue(). This doesn't remove for_each_set_bit_cont() for now. Signed-off-by:
-
Randy Dunlap authored
Fix build error when GPIO_CS5535 is not enabled: drivers/built-in.o: In function `ot200_backlight_probe': ot200_bl.c:(.text+0x205bf): undefined reference to `cs5535_gpio_set' ot200_bl.c:(.text+0x205d1): undefined reference to `cs5535_gpio_set' Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Jingoo Han authored
Instead of using legacy suspend/resume methods, using newer dev_pm_ops structure allows better control over power management. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Grazvydas Ignotas authored
Add support for pandora (openpandora.org) backlight. It might look like all this could be done using pwm_bl.c instead, but there is a need of special programming sequence when turning on the LED driver chip or else it will misbehave. Doing this using pwm_bl.c would require to use some register programming and pwm functions from platform code, and ARM maintainers are allergic to driver-like code in /arch/arm nowadays. The PMIC PWM driver is currently missing too, so pwm_bl.c can't be used anyway. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Christian Gmeiner authored
Add backlight driver for Bachmann's ot200 visualisation device. The driver uses MFGPT 7 of CS5535 silicon to regulate the backlight. [akpm@linux-foundation.org: remove redundant test of `brightness'] Signed-off-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Andres Salomon <dilinger@queued.net> Signed-off-by:
-
Kim, Milo authored
THis driver supports TI LP8550/LP8551/LP8552/LP8553/LP8556 backlight devices. The brightness can be controlled by the I2C or PWM input. The lp855x driver provides both modes. For the PWM control, pwm-specific functions can be defined in the platform data. And some information can be read via the sysfs(lp855x device attributes). For details, please refer to Documentation/backlight/lp855x-driver.txt. [axel.lin@gmail.com: add missing mutex_unlock in lp855x_read_byte() error path] [axel.lin@gmail.com: check platform data in lp855x_probe()] [axel.lin@gmail.com: small cleanups] [dan.carpenter@oracle.com: silence a compiler warning] [axel.lin@gmail.com: use id->driver_data to differentiate lp855x chips] [akpm@linux-foundation.org: simplify boolean return expression] Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
-
Julia Lawall authored
The various devm_ functions allocate memory that is released when a driver detaches. This patch uses these functions for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Cc: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
-
Julia Lawall authored
The various devm_ functions allocate memory that is released when a driver detaches. This patch uses these functions for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by:
-
Julia Lawall authored
The various devm_ functions allocate memory that is released when a driver detaches. This patch uses these functions for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
-
Axel Lin authored
Factor out some boilerplate code for spi driver registration into module_spi_driver. Signed-off-by:
Alberto Panizzo <alberto@amarulasolutions.com> Cc: Donghwa Lee <dh09.lee@samsung.com> Acked-by:
Marek Vasut <marek.vasut@gmail.com> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: InKi Dae <inki.dae@samsung.com> Cc: Dmitry Baryshkov <dbaryshkov@gmail.com> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Axel Lin authored
Factor out some boilerplate code for i2c driver registration into module_i2c_driver. Signed-off-by:
-
Wanlong Gao authored
The maintainership of LTP is out of date, so update it. Signed-off-by:
Wanlong Gao <gaowanlong@cn.fujitsu.com> Signed-off-by:
Cyril Hrubis <chrubis@suse.cz> Signed-off-by:
Caspar Zhang <caspar@casparzhang.com> Reviewed-by:
Rishikesh K Rajak <rishikesh.rajak@hp.com> Acked-by:
Subrata Modak <tosubrata@gmail.com> Signed-off-by:
-
Joe Perches authored
Russell King seems to be maintaining these. Might as well mark them with the appropriate S: entry Signed-off-by:
Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by:
-
Joe Perches authored
Add missing S: status line to ALPHA. Signed-off-by:
-
Joe Perches authored
Update the various git urls for name changes from 2.6. Signed-off-by:
Jesper Juhl <jj@chaosbits.net> Signed-off-by:
-
Joe Perches authored
The MCA section included a file referring to Machine Check rather than Microchannel. Rename the section to spell out Microchannel and drop the bad file reference. Reported-by:
Greg Pearson <greg.pearson@hp.com> Signed-off-by:
-
Richard Weinberger authored
Currently get_maintainer.pl reports moderated lists as open, which is just wrong. Signed-off-by:
Richard Weinberger <richard@nod.at> Acked-by:
-
Joe Perches authored
When an "S:" status line is unavailable, use a default "unknown" role. Signed-off-by:
-
Andrew Morton authored
Revelation from Peter. Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Don Zickus <dzickus@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@tglx.de> Signed-off-by:
-
Andrew Morton authored
It fixes some 80-col wordwrappings and adds some consistency. Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Michal Hocko authored
If the system is loaded while hotplugging a CPU we might end up with a bogus hardlockup detection. This has been seen during LTP pounder test executed in parallel with hotplug test. The main problem is that enable_watchdog (called when CPU is brought up) registers perf event which periodically checks per-cpu counter (hrtimer_interrupts), updated from a hrtimer callback, but the hrtimer is fired from the kernel thread. This means that while we already do check for the hard lockup the kernel thread might be sitting on the runqueue with zillions of tasks so there is nobody to update the value we rely on and so we KABOOM. Let's fix this by boosting the watchdog thread priority before we wake it up rather than when it's already running. This still doesn't handle a case where we have the same amount of high prio FIFO tasks but that doesn't seem to be common. The current implementation doesn't handle that case anyway so this is not worse at least. Unfortunately, we cannot start perf counter from the watchdog thread because we could miss a real lock up and also we cannot start the hrtimer watchdog_enable because we there is no way (at least I don't know any) to start a hrtimer from a different CPU. [dzickus@redhat.com: fix compile issue with param] Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Reviewed-by:
Mandeep Singh Baines <msb@chromium.org> Signed-off-by:
Michal Hocko <mhocko@suse.cz> Signed-off-by:
Don Zickus <dzickus@redhat.com> Signed-off-by:
-
Denys Vlasenko authored
I just received another user's pleas for help when their init mysteriously died. I again explained that they need to check whether it died because of bad instruction, a segv, or something else. Which was an annoying detour into writing a trivial C program to spawn his init and print its exit code: http://lists.busybox.net/pipermail/busybox/2012-January/077172.html I hear you saying "just test it under /bin/sh". Well, the crashing init _was_ /bin/sh. Which prompted me to make kernel do this first step automatically. We can print exit code, which makes it possible to see that death was from e.g. SIGILL without writing test programs. [akpm@linux-foundation.org: add 0x to hex number output] Signed-off-by:
Denys Vlasenko <vda.linux@googlemail.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Lennart Poettering authored
Userspace service managers/supervisors need to track their started services. Many services daemonize by double-forking and get implicitly re-parented to PID 1. The service manager will no longer be able to receive the SIGCHLD signals for them, and is no longer in charge of reaping the children with wait(). All information about the children is lost at the moment PID 1 cleans up the re-parented processes. With this prctl, a service manager process can mark itself as a sort of 'sub-init', able to stay as the parent for all orphaned processes created by the started services. All SIGCHLD signals will be delivered to the service manager. Receiving SIGCHLD and doing wait() is in cases of a service-manager much preferred over any possible asynchronous notification about specific PIDs, because the service manager has full access to the child process data in /proc and the PID can not be re-used until the wait(), the service-manager itself is in charge of, has happened. As a side effect, the relevant parent PID information does not get lost by a double-fork, which results in a more elaborate process tree and 'ps' output: before: # ps afx 253 ? Ss 0:00 /bin/dbus-daemon --system --nofork 294 ? Sl 0:00 /usr/libexec/polkit-1/polkitd 328 ? S 0:00 /usr/sbin/modem-manager 608 ? Sl 0:00 /usr/libexec/colord 658 ? Sl 0:00 /usr/libexec/upowerd 819 ? Sl 0:00 /usr/libexec/imsettings-daemon 916 ? Sl 0:00 /usr/libexec/udisks-daemon 917 ? S 0:00 \_ udisks-daemon: not polling any devices after: # ps afx 294 ? Ss 0:00 /bin/dbus-daemon --system --nofork 426 ? Sl 0:00 \_ /usr/libexec/polkit-1/polkitd 449 ? S 0:00 \_ /usr/sbin/modem-manager 635 ? Sl 0:00 \_ /usr/libexec/colord 705 ? Sl 0:00 \_ /usr/libexec/upowerd 959 ? Sl 0:00 \_ /usr/libexec/udisks-daemon 960 ? S 0:00 | \_ udisks-daemon: not polling any devices 977 ? Sl 0:00 \_ /usr/libexec/packagekitd This prctl is orthogonal to PID namespaces. PID namespaces are isolated from each other, while a service management process usually requires the services to live in the same namespace, to be able to talk to each other. Users of this will be the systemd per-user instance, which provides init-like functionality for the user's login session and D-Bus, which activates bus services on-demand. Both need init-like capabilities to be able to properly keep track of the services they start. Many thanks to Oleg for several rounds of review and insights. [akpm@linux-foundation.org: fix comment layout and spelling] [akpm@linux-foundation.org: add lengthy code comment from Oleg] Reviewed-by:
Lennart Poettering <lennart@poettering.net> Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Acked-by:
Valdis Kletnieks <Valdis.Kletnieks@vt.edu> Signed-off-by:
-
Uwe Kleine-König authored
In the statement j->caplist[j->caps].handle = j->caps++; there is no sequence point between the usage of j->caps on the LHS of the assignment and the incrementation on its RHS. So it's not defined in Standard C if j->caps is already incremented when used on the LHS even though the postfix ++ operator is used. To properly fix that the incrementation has to be done in a separate expression. This fixes: drivers/telephony/ixj.c: In function `add_caps': drivers/telephony/ixj.c:5930:38: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:5950:38: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:5954:38: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:5965:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:5976:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:5988:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:5998:38: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6003:38: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6008:38: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6013:38: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6019:38: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6026:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6031:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6036:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6041:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6049:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6057:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6065:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] drivers/telephony/ixj.c:6071:39: warning: operation on `j->caps' may be undefined [-Wsequence-point] Signed-off-by:
Uwe Kleine-König <uwe@kleine-koenig.org> Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
H Hartley Sweeten authored
Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Arun Sharma <asharma@fb.com> Signed-off-by:
-
Javi Merino authored
Commit 33bf5610 ("feature removal of io_remap_page_range()") removed io_remap_page_range(), but it is still included in some arch header files. It has no in-tree users. Signed-off-by:
Javi Merino <javi.merino@arm.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Aurelien Jacquiot <a-jacquiot@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Jonas Bonn <jonas@southpole.se> Cc: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
