Jingoo Han [Wed, 3 Jul 2013 22:07:47 +0000 (15:07 -0700)]
drivers/rtc/rtc-mpc5121.c: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
This chip has a control register and can prevent altering saved clock.
Without this patch we could have:
(arm)root@pac14:~# date
Tue May 21 03:08:27 MSK 2013
(arm)root@pac14:~# /etc/init.d/hwclock.sh show
Tue May 21 11:13:58 2013 -0.067322 seconds
(arm)root@pac14:~# /etc/init.d/hwclock.sh stop
[info] Saving the system clock.
[info] Hardware Clock updated to Tue May 21 03:09:01 MSK 2013.
(arm)root@pac14:~# /etc/init.d/hwclock.sh show
Tue May 21 11:14:15 2013 -0.624272 seconds
The patch enables write access to rtc before the driver tries to write
time and re-disables when time data is written.
drivers/rtc/rtc-ab8500.c: add second resolution to rtc driver
Android expects the RTC to have second resolution. On ab8540 cut2 RTC
block has a new register which allows setting seconds for wakeup alarms.
Existing registers (minutes hi, mid and low) have seen their offsets
changed. Here is the new mapping:
* AlarmSec (A) 0x22
* AlarmMinLow (M) from 0x8 to 0x23
* AlarmMinMid (M) from 0x9 to 0x24
* AlarmMinHigh (M) from 0xA to 0x25
Jingoo Han [Wed, 3 Jul 2013 22:07:13 +0000 (15:07 -0700)]
rtc: rtc-rc5t583: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Jingoo Han [Wed, 3 Jul 2013 22:07:12 +0000 (15:07 -0700)]
rtc: rtc-coh901331: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
rtc: add ability to push out an existing wakealarm using sysfs
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
rtc: rtc-hid-sensor-time: allow full years (16bit) in HID reports
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).
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
The driver core clears the driver data to NULL after device_release or
on probe failure, since commit 0998d063100 ("device-core: Ensure drvdata
= NULL when no driver is bound"). Thus, it is not needed to manually
clear the device driver data to NULL.
projects / linux.git / log