- 14 Oct, 2014 40 commits
-
-
Fabian Frederick authored
sys_tz is already declared extern struct in include/linux/time.h Signed-off-by:
Fabian Frederick <fabf@skynet.be> Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Fabian Frederick authored
Merge conditional unlock/lock in the same condition to avoid sparse warning: fs/reiserfs/journal.c:703:36: warning: context imbalance in 'add_to_chunk' - unexpected unlock Signed-off-by:
-
Fabian Frederick authored
ucg is defined and set in ufs_bitmap_search but never used. Signed-off-by:
-
Fabian Frederick authored
sys_tz is already declared in include/linux/time.h Signed-off-by:
-
Andreas Rohner authored
Support for fdatasync() has been implemented in NILFS2 for a long time, but whenever the corresponding inode is dirty the implementation falls back to a full-flegded sync(). Since every write operation has to update the modification time of the file, the inode will almost always be dirty and fdatasync() will fall back to sync() most of the time. But this fallback is only necessary for a change of the file size and not for a change of the various timestamps. This patch adds a new flag NILFS_I_INODE_SYNC to differentiate between those two situations. * If it is set the file size was changed and a full sync is necessary. * If it is not set then only the timestamps were updated and fdatasync() can go ahead. There is already a similar flag I_DIRTY_DATASYNC on the VFS layer with the exact same semantics. Unfortunately it cannot be used directly, because NILFS2 doesn't implement write_inode() and doesn't clear the VFS flags when inodes are written out. So the VFS writeback thread can clear I_DIRTY_DATASYNC at any time without notifying NILFS2. So I_DIRTY_DATASYNC has to be mapped onto NILFS_I_INODE_SYNC in nilfs_update_inode(). Signed-off-by:
Andreas Rohner <andreas.rohner@gmx.net> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by:
-
Andreas Rohner authored
Under normal circumstances nilfs_sync_fs() writes out the super block, which causes a flush of the underlying block device. But this depends on the THE_NILFS_SB_DIRTY flag, which is only set if the pointer to the last segment crosses a segment boundary. So if only a small amount of data is written before the call to nilfs_sync_fs(), no flush of the block device occurs. In the above case an additional call to blkdev_issue_flush() is needed. To prevent unnecessary overhead, the new flag nilfs->ns_flushed_device is introduced, which is cleared whenever new logs are written and set whenever the block device is flushed. For convenience the function nilfs_flush_device() is added, which contains the above logic. Signed-off-by:
-
Himangi Saraogi authored
The Linux kernel coding style guidelines suggest not using typedefs for structure types. This patch gets rid of the typedef for befs_btree_node. The following Coccinelle semantic patch detects the case. @tn1@ type td; @@ typedef struct { ... } td; @script:python tf@ td << tn1.td; tdres; @@ coccinelle.tdres = td; @@ type tn1.td; identifier tf.tdres; @@ -typedef struct + tdres { ... } -td ; @@ type tn1.td; identifier tf.tdres; @@ -td + struct tdres Signed-off-by:Himangi Saraogi <himangi774@gmail.com> Acked-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
-
Daniel Glöckner authored
Commit b5ada460 ("drivers/rtc/rtc-cmos.c: fix compilation warning when !CONFIG_PM_SLEEP") broke wakeup from S5 by making cmos_poweroff a nop unless CONFIG_PM_SLEEP was defined. Fix this by restricting the #ifdef to cmos_resume and restoring the old dependency on CONFIG_PM for cmos_suspend and cmos_poweroff. Signed-off-by:
Daniel Glöckner <daniel-gl@gmx.net> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Chen Gang authored
Some drivers need 'devm_ioremap_resource' or 'devm_ioremap' which need HAS_IOMEM, so let them depend on it. The related error (with allmodconfig under score): MODPOST 1365 modules ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-xgene.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-stk17ta8.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1742.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1553.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1511.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1286.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-rp5c01.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-msm6242.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t59.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t35.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-bq4802.ko] undefined! Signed-off-by:Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
Instead of pushing each byte let's reduce stack usage by using %*ph specifier. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
As pointed out by Sergei Shtylyov, the pcf8563_irq function contains a bug in the error handling: an interrupt handler is not supposed to return an errno value but an 'enum irqreturn'. Let's fix this by returning IRQ_NONE in case of a communication error. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Arnd Bergmann authored
gcc-4.9 found a potential condition under which the 'pending' variable may be used uninitialized: drivers/rtc/rtc-pcf8563.c: In function 'pcf8563_irq': drivers/rtc/rtc-pcf8563.c:173:5: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] This is because in the pcf8563_get_alarm_mode() function, we check any nonzero return of pcf8563_read_block_data, but in the irq function we only check for negative values, so a possible positive value does not get detected if the compiler chooses not to inline the entire call chain. Checking for any non-zero value in the interrupt handler as well is just as correct and lets the compiler know what we are doing, without needing a bogus initialization. Signed-off-by:
-
Javier Martinez Canillas authored
The MAX7802 PMIC has a Real-Time-Clock (RTC) with two alarms. This patch adds support for the RTC and is based on a driver added by Simon Glass to the Chrome OS kernel 3.8 tree. [akpm@linux-foundation.org: add comment clarifying ffs() use] Signed-off-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Olof Johansson <olof@lixom.net> Cc: Simon Glass <sjg@chromium.org> Signed-off-by:
-
Javier Martinez Canillas authored
max77686_rtc_calculate_wday() is used to calculate the day of the week to be filled in struct rtc_time but that function only calculates the number of bits shifted. So the ffs() function can be used to find the first bit set instead of a special function. [akpm@linux-foundation.org: add comment clarifying ffs() use] Signed-off-by:
-
Javier Martinez Canillas authored
If devm_rtc_device_register() fails a dev_err() is already reported so there is no need to do an additional dev_info(). Signed-off-by:
-
Javier Martinez Canillas authored
The max77686 mfd driver adds a regmap IRQ chip which creates an IRQ domain that is used to map the virtual RTC alarm1 interrupt. The RTC driver assumes that this will always be true since the PMIC IRQ is a required property according to the max77686 DT binding doc. If an "interrupts" property is not defined for a max77686 PMIC, then the mfd probe function will fail and the RTC platform driver will never be probed. But even when it is not possible to probe the rtc-max77686 driver without a regmap IRQ chip, it's better to explicitly check if the IRQ chip data is not NULL and gracefully fail instead of getting an OOPS. Signed-off-by:
-
Javier Martinez Canillas authored
The MAX77686 RTC chip has two features called SMPL (Sudden Momentary Power Loss) and WTSR (Watchdog Timeout and Software Resets). Support for these features seems to be implemented in the driver but compilation is disabled using a C pre-processor conditional. This code has been disabled since the driver was original merged in commit fca1dd03 ("rtc: max77686: add Maxim 77686 driver"). So, since this code has never been built, let's just remove it. Signed-off-by:
-
Doug Anderson authored
This series add support for the Real Time clock present in the Maxim 77802 Power Managment IC. The version number is quite high because it previously was part of a bigger series [0] that aimed to add support for all the devices in the max77802 PMIC. But now that the max77802 dependencies were already merged for 3.17, the series were split but I kept the version numbering. While working on the max77802 rtc support a lot of feedback was given and the issues pointed out also apply to a driver for a similar PMIC RTC (max77686). So patches 01/06 to 05/06 in the series are cleanups for the max77686 driver and patch 06/06 adds the support for the max77802 RTC. The series were tested on an Exynos5250 Snow (max77686) and Exynos5420 Peach Pit (max77802) machines. This patch (of 6): The max77686 includes an RTC that keeps power during suspend. It's convenient to be able to use it as a wakeup source. Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
-
Pavel Machek authored
BQ32000 have "trickle chargers". Introduce a device tree binding for specifying the trickle charger configuration for that. Signed-off-by:
Pavel Machek <pavel@denx.de> Reviewed-by:
Jason Cooper <jason@lakedameon.net> Cc: Matti Vaittinen <matti.vaittinen@nsn.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Pavel Machek authored
BQ32000 devices have "trickle chargers". Introduce a code to enable the charger, based on device tree. Without charger, RTC does not keep time after power off. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
-
Matti Vaittinen authored
Some DS13XX devices have "trickle chargers". Introduce a device tree binding for specifying the trickle charger configuration for ds1339. Only ds1339 dt binding is supported because this is the only chip I have. I _assume_ the code would have worked on other allready supported chips. However I cannot check the resistor values for the other chips or test them. For other chips the driver code works as earlier Eg. it does not check the dt bindings at all Signed-off-by:
Matti Vaittinen <matti.vaittinen@nsn.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Pawel Moll <pawel.moll@arm.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Pavel Machek <pavel@denx.de> Signed-off-by:
-
Matti Vaittinen authored
Some DS13XX devices have "trickle chargers". Introduce a device tree binding for the resistor and diode configuration for enabling trickle charger. Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Pawel Moll <pawel.moll@arm.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Pavel Machek <pavel@denx.de> Signed-off-by:
-
Chris Zhong authored
This is the initial version of the RK808 PMIC. This is a power management IC for multimedia products. It provides regulators that are able to supply power to processor cores and other components. The chip provides other modules including RTC, Clockout. Signed-off-by:
Chris Zhong <zyw@rock-chips.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Cc: Pawel Moll <pawel.moll@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> Cc: Samuel Ortiz <sameo@linux.intel.com> says: Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Olof Johansson <olof@lixom.net> Cc: Dmitry Torokhov <dtor@chromium.org> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Cc: Kever Yang <kever.yang@rock-chips.com> Cc: Li Zhong <zhong@linux.vnet.ibm.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Chris Zhong authored
This is the initial version of the RK808 PMIC. This is a power management IC for multimedia products. It provides regulators that are able to supply power to processor cores and other components. The chip provides other modules including RTC, Clockout. Add RTC driver for supporting RTC device present inside RK808 PMIC. [akpm@linux-foundation.org: make tm_def static] Signed-off-by:
Zhang Qing <zhangqing@rock-chips.com> Tested-by:
-
Uwe Kleine-König authored
of_device_ids (i.e. compatible strings and the respective data) are not supposed to change at runtime. All functions working with of_device_ids provided by <linux/of.h> work with const of_device_ids. This allows to mark all struct of_device_id below drivers/rtc const, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Chanwoo Choi authored
Fix wrong compatible string of Exynos3250 RTC (Real-Time Clock) dt node. The RTC of Exynos3250 must need additional source clock (XrtcXTI). Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Acked-by:
Kyungmin Park <kyungmin.park@samsung.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Chanwoo Choi authored
Add support for RTC of Exynos3250 SoC. The Exynos3250 needs source clock(32.768KHz) for RTC block. If source clock of RTC is registerd on clock list of common clk framework, Exynos RTC drvier have to control this clock. Clock list for s3c-rtc device: - rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC. - rtc_src : XrtcXTI is 32.768.kHz source clock for RTC. (XRTCXTI: Specifies a clock from 32.768 kHz crystal pad with XRTCXTI and XRTCXTO pins. RTC uses this clock as the source of a real-time clock.) Signed-off-by:
-
Chanwoo Choi authored
Add s3c_rtc_data structure to variant data according to SoC type. The s3c_rtc_data structure includes some functions to control RTC operation and specific data dependent on SoC type. Signed-off-by:
-
Chanwoo Choi authored
Remove warning message when checking codeing style with checkpatch script and reduce un-necessary i2c read operation on s3c_rtc_enable. WARNING: line over 80 characters #406: FILE: drivers/rtc/rtc-s3c.c:406: + if ((readw(info->base + S3C2410_RTCCON) & S3C2410_RTCCON_RTCEN) == 0) { WARNING: line over 80 characters #414: FILE: drivers/rtc/rtc-s3c.c:414: + if ((readw(info->base + S3C2410_RTCCON) & S3C2410_RTCCON_CNTSEL)) { WARNING: line over 80 characters #422: FILE: drivers/rtc/rtc-s3c.c:422: + if ((readw(info->base + S3C2410_RTCCON) & S3C2410_RTCCON_CLKRST)) { WARNING: Missing a blank line after declarations #451: FILE: drivers/rtc/rtc-s3c.c:451: + struct s3c_rtc_drv_data *data; + if (pdev->dev.of_node) { WARNING: Missing a blank line after declarations #453: FILE: drivers/rtc/rtc-s3c.c:453: + const struct of_device_id *match; + match = of_match_node(s3c_rtc_dt_match, pdev->dev.of_node); WARNING: DT compatible string "samsung,s3c2416-rtc" appears un-documented -- check ./Documentation/devicetree/bindings/ #650: FILE: drivers/rtc/rtc-s3c.c:650: + .compatible = "samsung,s3c2416-rtc", WARNING: DT compatible string "samsung,s3c2443-rtc" appears un-documented -- check ./Documentation/devicetree/bindings/ #653: FILE: drivers/rtc/rtc-s3c.c:653: + .compatible = "samsung,s3c2443-rtc", Signed-off-by: -
Chanwoo Choi authored
Define s3c_rtc structure including necessary variables for S3C RTC device instead of global variables. This patch improves the readability by removing global variables. Signed-off-by:
-
Julia Lawall authored
Use c99 initializers for structures. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @decl@ identifier i1,fld; type T; field list[n] fs; @@ struct i1 { fs T fld; ...}; @bad@ identifier decl.i1,i2; expression e; initializer list[decl.n] is; @@ struct i1 i2 = { is, + .fld = e - e ,...}; // </smpl> Signed-off-by:
-
NeilBrown authored
This documents autofs from the perspective of what the module actually supports rather than how automount is expected to use it. It is formatted using "markdown" and works best with Markdown.pl (markdown_py doesn't like some constructs). [rdunlap@infradead.org: copy editing] Signed-off-by:
NeilBrown <neilb@suse.de> Cc: Randy Dunlap <rdunlap@infradead.org> Acked-by:
Ian Kent <raven@themaw.net> Signed-off-by:
-
NeilBrown authored
If rcu-walk mode we don't *have* to return -EISDIR for non-mount-traps as we will simply drop into REF-walk and handling DCACHE_NEED_AUTOMOUNT dentrys the slow way. But it is better if we do when possible. In 'oz_mode', use the same condition as ref-walk: if not a mountpoint, then it must be -EISDIR. In regular mode there are most tests needed. Most of them can be performed without taking any spinlocks. If we find a directory that isn't obviously empty, and isn't mounted on, we need to call 'simple_empty()' which does take a spinlock. If this turned out to hurt performance, some other approach could be found to signal when a directory is known to be empty. Signed-off-by:
-
NeilBrown authored
->fs_lock protects AUTOFS_INF_EXPIRING. We need to be sure that once the flag is set, no new references beneath the dentry are taken. So rcu-walk currently needs to take fs_lock before checking the flag. This hurts performance. Change the expiry to a two-stage process. First set AUTOFS_INF_NO_RCU which forces any path walk into ref-walk mode, then drop the lock and call synchronize_rcu(). Once that returns we can be sure no rcu-walk is active beneath the dentry and we can check reference counts again. Now during an RCU-walk we can test AUTOFS_INF_EXPIRING without taking the lock as along as we test AUTOFS_INF_NO_RCU too. If either are set, we must abort the RCU-walk If neither are set, we know that refcounts will be tested again after we finish the RCU-walk so we are safe to continue. ->fs_lock is still taken in d_manage() to check for a non-trap directory. That will be resolved in the next patch. Signed-off-by:
-
NeilBrown authored
Have a "test" function change the value it is testing can be confusing, particularly as a future patch will be calling this function twice. So move the update for 'last_used' to avoid repeat expiry to the place where the final determination on what to expire is known. Signed-off-by:
-
NeilBrown authored
Future patch will potentially call this twice, so make it separate. Signed-off-by:
-
NeilBrown authored
This series teaches autofs about RCU-walk so that we don't drop straight into REF-walk when we hit an autofs directory, and so that we avoid spinlocks as much as possible when performing an RCU-walk. This is needed so that the benefits of the recent NFS support for RCU-walk are fully available when NFS filesystems are automounted. Patches have been carefully reviewed and tested both with test suites and in production - thanks a lot to Ian Kent for his support there. This patch (of 6): Any attempt to look up a pathname that passes though an autofs4 mount is currently forced out of RCU-walk into REF-walk. This can significantly hurt performance of many-thread work loads on many-core systems, especially if the automounted filesystem supports RCU-walk but doesn't get to benefit from it. So if autofs4_d_manage is called with rcu_walk set, only fail with -ECHILD if it is necessary to wait longer than a spinlock. Signed-off-by:
-
Fabian Frederick authored
sys_tz is already declared in include/linux/time.h Signed-off-by:
-
Rob Jones authored
Reduce boilerplate code by using __seq_open_private() instead of seq_open() in kallsyms_open(). Signed-off-by:
Rob Jones <rob.jones@codethink.co.uk> Cc: Gideon Israel Dsouza <gidisrael@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
gcc-4.9 on ARM gives us a mysterious warning about the binfmt_misc parse_command function: fs/binfmt_misc.c: In function 'parse_command.part.3': fs/binfmt_misc.c:405:7: warning: array subscript is above array bounds [-Warray-bounds] I've managed to trace this back to the ARM implementation of memset, which is called from copy_from_user in case of a fault and which does #define memset(p,v,n) \ ({ \ void *__p = (p); size_t __n = n; \ if ((__n) != 0) { \ if (__builtin_constant_p((v)) && (v) == 0) \ __memzero((__p),(__n)); \ else \ memset((__p),(v),(__n)); \ } \ (__p); \ }) Apparently gcc gets confused by the check for "size != 0" and believes that the size might be zero when it gets to the line that does "if (s[count-1] == '\n')", so it would access data outside of the array. gcc is clearly wrong here, since this condition was already checked earlier in the function and the 'size' value can not change in the meantime. Fortunately, we can work around it and get rid of the warning by rearranging the function to check for zero size after doing the copy_from_user. It is still safe to pass a zero size into copy_from_user, so it does not cause any side effects. Signed-off-by:
-
