- 05 Oct, 2012 40 commits
-
-
Sachin Kamat authored
Return the value returned by platform_get_irq() instead of -ENOENT; Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
David Fries authored
Without this patch /sys/class/rtc/$CONFIG_RTC_HCTOSYS_DEVICE/hctosys contains a 1 (meaning "This rtc was used to initialize the system clock") even if setting the time by do_settimeofday() at bootup failed. The RTC can also be used to set the clock on resume, if it did 1, otherwise 0. Previously there was no indication if the RTC was used to set the clock in resume. This uses only CONFIG_RTC_HCTOSYS_DEVICE for conditional compilation instead of it and CONFIG_RTC_HCTOSYS to be more consistent. rtc_hctosys_ret was moved to class.c so class.c no longer depends on hctosys.c. [sfr@canb.auug.org.au: fix build] Signed-off-by:
David Fries <David@Fries.net> Cc: Matthew Garrett <mjg@redhat.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Fabio Estevam authored
Converting to module_platform_driver can make the code smaller and cleaner. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Fabio Estevam authored
i.mx drivers should use clk_prepare_enable/clk_disable_unprepare() in order to avoid clk warnings. While at it, convert to devm_clk_get() since other devm_ functions are used in this driver and it can also save some clk_put() calls. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Julia Lawall authored
clk_prepare_enable and clk_disable_unprepare combine clk_prepare and clk_enable, and clk_disable and clk_unprepare. They make the code more concise, and ensure that clk_unprepare is called when clk_enable fails. A simplified version of the semantic patch that introduces calls to these functions is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e; @@ - clk_prepare(e); - clk_enable(e); + clk_prepare_enable(e); @@ expression e; @@ - clk_disable(e); - clk_unprepare(e); + clk_disable_unprepare(e); // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Venu Byravarasu authored
Add an RTC driver for the RTC device on Ricoh MFD Rc5t583. Ricoh RTC has 3 types of alarms. The current patch adds support for the Y-Alarm of RC5t583 RTC. Signed-off-by:
Venu Byravarasu <vbyravarasu@nvidia.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Lars-Peter Clausen authored
There are several comparisons of a unsigned int to less than zero int spear RTC driver. Such a check will always be true. In all these cases a signed int is assigned to the unsigned variable, which is checked, before. So the right fix is to make the checked variable signed as well. In one case the check can be dropped completely, because all it does it returns 'err' if 'err' is less than zero, otherwise it returns 0. Since in this particular case 'err' is always either 0 or less this is the same as just returning 'err'. The issue has been found using the following coccinelle semantic patch: //<smpl> @@ type T; unsigned T i; @@ ( *i < 0 | *i >= 0 ) //</smpl> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Cc: Viresh Kumar <viresh.kumar@st.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Lars-Peter Clausen authored
The irq field of the jz4740_irc struct is unsigned. Yet we assign the result of platform_get_irq() to it. platform_get_irq() may return a negative error code and the code checks for this condition by checking if 'irq' is less than zero. But since 'irq' is unsigned this test will always be false. Fix it by making 'irq' signed. The issue was found using the following coccinelle semantic patch: //<smpl> @@ type T; unsigned T i; @@ ( *i < 0 | *i >= 0 ) //</smpl> Signed-off-by:
-
Venu Byravarasu authored
Remove "depends on RTC_CLASS = y" for multiple Kconfig definitions, as all of them are already placed under "if RTC_CLASS". Signed-off-by:
-
Stephen Warren authored
The MAX8907 is an I2C-based power-management IC containing voltage regulators, a reset controller, a real-time clock, and a touch-screen controller. The driver is based on an original by or fixed by: * Tom Cherry * Prashant Gaikwad * Joseph Yoon During upstreaming, I (swarren): * Converted to regmap. * Fixed handling of RTC_HOUR register containing 12. * Fixed handling of RTC_WEEKDAY register. * General cleanup. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Cc: Tom Cherry <tcherry@nvidia.com> Cc: Prashant Gaikwad <pgaikwad@nvidia.com> Cc: Joseph Yoon <tyoon@nvidia.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Venu Byravarasu authored
TPS65910 PMIC is a MFD with RTC as one of the device. Adding RTC driver for supporting RTC device present inside TPS65910 PMIC. Only support for RTC alarm is implemented as part of this patch. Signed-off-by:
-
Devendra Naga authored
This driver does seems to do only platform_driver_register in the init function and platform_driver_unregister in the exit function, so replace all this code including the module_init and module_exit with module_platform_driver macro... Signed-off-by:
Devendra Naga <develkernel412222@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Vincent Palatin authored
When calling rtc_device_unregister, we are not freeing the id used by the driver. So when doing a unload/load cycle for a RTC driver (e.g. rmmod rtc_cmos && modprobe rtc_cmos), its id is incremented by one. As a consequence, we no longer have neither an rtc0 driver nor a /proc/driver/rtc (as it only exists for the first driver). Signed-off-by:
Vincent Palatin <vpalatin@chromium.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Shawn Guo authored
Add an RTC driver for Freescale Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Kim Phillips <kim.phillips@freescale.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Sven Schnelle authored
[akpm@linux-foundation.org: fix warning] Signed-off-by:
Sven Schnelle <svens@stackframe.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Kim, Milo authored
To get time information via /proc/driver/rtc, only the first device (rtc0) is used. If the rtcN (eg. rtc1 or rtc2) is used for the system clock, there is no way to get information of rtcN via /proc/driver/rtc. With this patch, the time data can be retrieved from the system clock RTC. If the RTC_HCTOSYS_DEVICE is not defined, then rtc0 is used by default. Signed-off-by:
Milo(Woogyom) Kim <milo.kim@ti.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Ben Gardner authored
The ISL1218 chip is identical to the ISL1208, except that it has 6 additional user-storage registers. This patch does not enable access to those additional registers, but only adds the chip name to the list. Signed-off-by:
Ben Gardner <gardner.ben@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Alan Cox authored
load_elf_interp() has interp_map_addr carefully described as "uninitialized_var" and marked so as to avoid a warning. However if you trace the code it is passed into load_elf_interp and then this value is checked against NULL. As this return value isn't used this is actually safe but it freaks various analysis tools that see un-initialized memory addresses being read before their value is ever defined. Set it to NULL as a matter of programming good taste if nothing else Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Paton J. Lewis authored
Enhanced epoll_ctl to support EPOLL_CTL_DISABLE, which disables an epoll item. If epoll_ctl doesn't return -EBUSY in this case, it is then safe to delete the epoll item in a multi-threaded environment. Also added a new test_epoll self- test app to both demonstrate the need for this feature and test it. Signed-off-by:
Paton J. Lewis <palewis@adobe.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jason Baron <jbaron@redhat.com> Cc: Paul Holland <pholland@adobe.com> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by:
-
Kees Cook authored
Fix macro name in checkpatch: s/PARAM/PARM/. Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
The block comment style in net/ and drivers/net is non-standard. Document it. Signed-off-by:
Joe Perches <joe@perches.com> Cc: "Allan, Bruce W" <bruce.w.allan@intel.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Joe Perches authored
In an effort to get fewer checkpatch reviewer corrections, add a networking specific style test for the preferred networking comment style. /* The preferred style for block comments in * drivers/net/... and net/... is like this */ These tests are only used in net/ and drivers/net/ Tested with: $ cat drivers/net/t.c /* foo */ /* * foo */ /* foo */ /* foo * bar */ $ ./scripts/checkpatch.pl -f drivers/net/t.c WARNING: networking block comments don't use an empty /* line, use /* Comment... #4: FILE: net/t.c:4: + +/* WARNING: networking block comments put the trailing */ on a separate line #12: FILE: net/t.c:12: + * bar */ total: 0 errors, 2 warnings, 12 lines checked Signed-off-by:
-
Joe Perches authored
Direct conversion of printk(KERN_<LEVEL>... to pr_<level> isn't the preferred conversion when a struct net_device or struct device is available. Hint that using netdev_<level> or dev_<level> is preferred to using pr_<level>. Add netdev_dbg and dev_dbg variants too. Miscellaneous whitespace neatening of a misplaced close brace. Signed-off-by:
-
Pasi Savanainen authored
Check that a commit log doesn't contain UTF-8 when a mail header explicitly defines a different charset, like 'Content-Type: text/plain; charset="us-ascii"' Signed-off-by:
Pasi Savanainen <pasi.savanainen@nixu.com> Cc: Joe Perches <joe@perches.com> Cc: Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
Tejun Heo authored
SG mapping iterator w/ SG_MITER_ATOMIC set required IRQ disabled because it originally used KM_BIO_SRC_IRQ to allow use from IRQ handlers. kmap_atomic() has long been updated to handle stacking atomic mapping requests on per-cpu basis and only requires not sleeping while mapped. Update sg_mapping_iter such that atomic iterators only require disabling preemption instead of disabling IRQ. While at it, convert wte weird @ARG@ notations to @ARG in the comment of sg_miter_start(). Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by:
-
Borislav Petkov authored
They show up in dmesg [ 4.041094] start plist test [ 4.045804] end plist test without a lot of meaning so hide them behind debug loglevel. Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Jan Beulich authored
Xen's pciback points out a couple of deficiencies with vsscanf()'s standard conformance: - Trailing character matching cannot be checked by the caller: With a format string of "(%x:%x.%x) %n" absence of the closing parenthesis cannot be checked, as input of "(00:00.0)" doesn't cause the %n to be evaluated (because of the code not skipping white space before the trailing %n). - The parameter corresponding to a trailing %n could get filled even if there was a matching error: With a format string of "(%x:%x.%x)%n", input of "(00:00.0]" would still fill the respective variable pointed to (and hence again make the mismatch non-detectable by the caller). This patch aims at fixing those, but leaves other non-conforming aspects of it untouched, among them these possibly relevant ones: - improper handling of the assignment suppression character '*' (blindly discarding all succeeding non-white space from the format and input strings), - not honoring conversion specifiers for %n, - not recognizing the C99 conversion specifier 't' (recognized by vsprintf()). Signed-off-by:
Jan Beulich <jbeulich@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Vikram Mulukutla authored
The logic in do_raw_spin_lock() attempts to acquire a spinlock by invoking arch_spin_trylock() in a loop with a delay between each attempt. Now consider the following situation in a 2 CPU system: 1. CPU-0 continually acquires and releases a spinlock in a tight loop; it stays in this loop until some condition X is satisfied. X can only be satisfied by another CPU. 2. CPU-1 tries to acquire the same spinlock, in an attempt to satisfy the aforementioned condition X. However, it never sees the unlocked value of the lock because the debug spinlock code uses trylock instead of just lock; it checks at all the wrong moments - whenever CPU-0 has locked the lock. Now in the absence of debug spinlocks, the architecture specific spinlock code can correctly allow CPU-1 to wait in a "queue" (e.g., ticket spinlocks), ensuring that it acquires the lock at some point. However, with the debug spinlock code, livelock can easily occur due to the use of try_lock, which obviously cannot put the CPU in that "queue". This queueing mechanism is implemented in both x86 and ARM spinlock code. Note that the situation mentioned above is not hypothetical. A real problem was encountered where CPU-0 was running hrtimer_cancel with interrupts disabled, and CPU-1 was attempting to run the hrtimer that CPU-0 was trying to cancel. Address this by actually attempting arch_spin_lock once it is suspected that there is a spinlock lockup. If we're in a situation that is described above, the arch_spin_lock should succeed; otherwise other timeout mechanisms (e.g., watchdog) should alert the system of a lockup. Therefore, if there is a genuine system problem and the spinlock can't be acquired, the end result (irrespective of this change being present) is the same. If there is a livelock caused by the debug code, this change will allow the lock to be acquired, depending on the implementation of the lower level arch specific spinlock code. [akpm@linux-foundation.org: tweak comment] Signed-off-by:
Vikram Mulukutla <markivx@codeaurora.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Benjamin Gaignard authored
Premit use of another algorithm than the default first-fit one. For example a custom algorithm could be used to manage alignment requirements. As I can't predict all the possible requirements/needs for all allocation uses cases, I add a "free" field 'void *data' to pass any needed information to the allocation function. For example 'data' could be used to handle a structure where you store the alignment, the expected memory bank, the requester device, or any information that could influence the allocation algorithm. An usage example may look like this: struct my_pool_constraints { int align; int bank; ... }; unsigned long my_custom_algo(unsigned long *map, unsigned long size, unsigned long start, unsigned int nr, void *data) { struct my_pool_constraints *constraints = data; ... deal with allocation contraints ... return the index in bitmap where perform the allocation } void create_my_pool() { struct my_pool_constraints c; struct gen_pool *pool = gen_pool_create(...); gen_pool_add(pool, ...); gen_pool_set_algo(pool, my_custom_algo, &c); } Add of best-fit algorithm function: most of the time best-fit is slower then first-fit but memory fragmentation is lower. The random buffer allocation/free tests don't show any arithmetic relation between the allocation time and fragmentation but the best-fit algorithm is sometime able to perform the allocation when the first-fit can't. This new algorithm help to remove static allocations on ESRAM, a small but fast on-chip RAM of few KB, used for high-performance uses cases like DMA linked lists, graphic accelerators, encoders/decoders. On the Ux500 (in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of static allocations becomes unmaintainable: cd arch/arm/mach-ux500 && grep -r ESRAM . ./include/mach/db8500-regs.h:/* Base address and bank offsets for ESRAM */ ./include/mach/db8500-regs.h:#define U8500_ESRAM_BASE 0x40000000 ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK_SIZE 0x00020000 ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK0 U8500_ESRAM_BASE ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK1 (U8500_ESRAM_BASE + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK2 (U8500_ESRAM_BANK1 + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK3 (U8500_ESRAM_BANK2 + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK4 (U8500_ESRAM_BANK3 + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_DMA_LCPA_OFFSET 0x10000 ./include/mach/db8500-regs.h:#define U8500_DMA_LCPA_BASE (U8500_ESRAM_BANK0 + U8500_ESRAM_DMA_LCPA_OFFSET) ./include/mach/db8500-regs.h:#define U8500_DMA_LCLA_BASE U8500_ESRAM_BANK4 I want to use genalloc to do dynamic allocations but I need to be able to fine tune the allocation algorithm. I my case best-fit algorithm give better results than first-fit, but it will not be true for every use case. Signed-off-by:Benjamin Gaignard <benjamin.gaignard@stericsson.com> Cc: Huang Ying <ying.huang@intel.com> Signed-off-by:
-
Davidlohr Bueso authored
Account for all properties when a and/or b are 0: gcd(0, 0) = 0 gcd(a, 0) = a gcd(0, b) = b Fixes no known problems in current kernels. Signed-off-by:
Davidlohr Bueso <dave@gnu.org> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jan Beulich authored
The main option should not appear in the resulting .config when the dependencies aren't met (i.e. use "depends on" rather than directly setting the default from the combined dependency values). The sub-options should depend on the main option rather than a more generic higher level one. Signed-off-by:
Don Zickus <dzickus@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Alex Elder authored
The result of converting an integer value to another signed integer type that's unable to represent the original value is implementation defined. (See notes in section 6.3.1.3 of the C standard.) In match_number(), the result of simple_strtol() (which returns type long) is assigned to a value of type int. Instead, handle the result of simple_strtol() in a well-defined way, and return -ERANGE if the result won't fit in the int variable used to hold the parsed result. No current callers pay attention to the particular error value returned, so this additional return code shouldn't do any harm. [akpm@linux-foundation.org: coding-style tweaks] Signed-off-by:
Alex Elder <elder@inktank.com> Cc: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Fengguang Wu authored
To avoid name conflicts: drivers/video/riva/fbdev.c:281:9: sparse: preprocessor token MAX_LEVEL redefined While at it, also make the other names more consistent and add parentheses. [akpm@linux-foundation.org: repair fallout] [sfr@canb.auug.org.au: IB/mlx4: fix for MAX_ID_MASK to MAX_IDR_MASK name change] Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at> Cc: walter harms <wharms@bfs.de> Cc: Glauber Costa <glommer@parallels.com> Signed-off-by:
-
Takuya Yoshikawa authored
Now that we have defined generic set_bit_le() we do not need to use test_and_set_bit_le() for atomically setting a bit. Signed-off-by:
Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp> Cc: Avi Kivity <avi@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Takuya Yoshikawa authored
Needed to replace test_and_set_bit_le() in virt/kvm/kvm_main.c which is being used for this missing function. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Avi Kivity <avi@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Takuya Yoshikawa authored
Needed to replace test_and_set_bit_le() in virt/kvm/kvm_main.c which is being used for this missing function. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Avi Kivity <avi@redhat.com> Signed-off-by:
-
Takuya Yoshikawa authored
To introduce generic set_bit_le() later, we remove our own definition and use a proper non-atomic bitops function: __set_bit_le(). Signed-off-by:
Grant Grundler <grundler@parisc-linux.org> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Ben Hutchings authored
There are now standard functions for dealing with little-endian bit arrays, so use them instead of our own implementations. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
-
Jingoo Han authored
This patch adds the of_match_table to platform-lcd driver to be probed when platform-lcd device node is found in the device tree. [akpm@linux-foundation.org: include of.h] Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Julia Lawall authored
devm_kfree should not have to be explicitly used. The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x,d; @@ x = devm_kzalloc(...) ... ?-devm_kfree(d,x); // </smpl> Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by:
-
