- 03 Jul, 2013 40 commits
-
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Wei Yongjun authored
Fix to return -EBUSY in the platform irq get error handling case instead of 0, as done elsewhere in this function. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Bernie Thompson authored
This adds the ability for the rtc sysfs code to handle += characters at the beginning of a wakealarm setting string. This will allow the user to attempt to push out an existing wakealarm by a provided amount. In the case that the += characters are provided but the alarm is not active -EINVAL is returned. his is useful, at least for my purposes in suspend/resume testing. The basic test goes something like: 1. Set a wake alarm from userspace 5 seconds in the future 2. Start the suspend process (echo mem > /sys/power/state) 3. After ~2.5 seconds if userspace is still running (using another thread to check this), move the wake alarm 5 more seconds If the "move" involves an unset of the wakealarm then there's a period of time where the system is midway through suspending but has no wake alarm. It will get stuck. We'd rather not remove the "move" since the idea is to avoid a cancelled suspend when the alarm fires _during_ suspend. It is difficult for the test to tell the difference between a suspend that was cancelled because the alarm fired too early and a suspend that was Signed-off-by:
Bernie Thompson <bhthompson@chromium.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Doug Anderson <dianders@chromium.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
Alexander Holler authored
There is no real reason to not support 16 or 32 bit values too. Signed-off-by:
Alexander Holler <holler@ahsoftware.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Jonathan Cameron <jic23@cam.ac.uk> Cc: Jiri Kosina <jkosina@suse.cz> Cc: John Stultz <john.stultz@linaro.org> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Alexander Holler authored
The draft for HID-sensors (HUTRR39) currently doesn't define the range for the attribute year. Asking one of the authors revealed that full years (e.g. 2013 instead of just 13) were meant. So we now allow both, 8 bit and 16 bit values for the attribute year and assuming full years when the value is 16 bits wide. We will still support 8 bit values until the specification gets final (and maybe defines a way to set the time too). Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
Milo Kim <milo.kim@ti.com> Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Sachin Kamat authored
After the switch to devm_ functions and the removal of rtc_device_unregister(), the 'remove' function does not do anything. Delete it. Signed-off-by:
-
Axel Lin authored
In the disable AIE irq code path, current code passes "1" to enable parameter of rv3029c2_rtc_i2c_alarm_set_irq(). Thus it does not disable AIE irq. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Heiko Schocher <hs@denx.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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:
Guan Xuetao <gxt@mprc.pku.edu.cn> Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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:
Tony Prisk <linux@prisktech.co.nz> Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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 authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 ("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:
Wan Zongshun <mcuos.com@gmail.com> Signed-off-by:
-
