The patch "rtc: verify a critical argument to rtc_update_irq() before
using it" introduces validation for rtc_device in the RTC core, so there
are no need to check this argument for rtc_update_irq() from the
drivers.
This patch removes such check for the existing rtc_update_irq() users.
NO_IRQ may be defined as '(unsigned int) -1' in some architectures (arm,
sh ...), and either may not be defined in some architectures (arm64) which
can enable RTC_DRV_S3C.
Also since platform_get_irq returns err-code in case of any error, we do
not need to intialize s3c_rtc_alarmno and s3c_rtc_tickno.
Adam Thomson [Thu, 3 Apr 2014 21:50:18 +0000 (14:50 -0700)]
drivers/rtc/rtc-da9055.c: remove use of regmap_irq_get_virq()
Using platform_get_irq_byname() to retrieve the IRQ number returns the
VIRQ number rather than the local IRQ number for the device. Passing that
value then into regmap_irq_get_virq() causes a failure because the
function is expecting the local IRQ number (e.g. 0, 1, 2, 3, etc).
This patch removes use of regmap_irq_get_virq() to prevent this failure
from happening
Add support for describing the PM8921/PM8058 RTC in device tree.
Additionally:
- drop support for describing the RTC using platform data,
as there are no current in tree users who do so.
- make allow_set_time a device-specific flag, instead of mucking
with the rtc_ops
Now that the parent mfd driver has been made to work again, and has been
reworked to create a regmap instance intended for its children to use,
rework the pm8xxx driver to use the regmap API for its register
accesses.
This patchset is based on Stephen Boyd's PM8921 modernization/cleanups
(http://lkml.kernel.org/g/1393441166[email protected]),
and allows for this RTC driver to be usable again.
This patch (of 6):
Before performing additional cleanups to this driver, do the easy cleanups
first.
Mika Westerberg [Thu, 3 Apr 2014 21:50:05 +0000 (14:50 -0700)]
drivers/rtc/rtc-cmos.c: fix compilation warning when !CONFIG_PM_SLEEP
CONFIG_PM will be set also if only CONFIG_PM_RUNTIME is set which causes
the compiler to emit following warning:
drivers/rtc/rtc-cmos.c:845:12: warning: =E2=80=98cmos_resume=E2=80=99 defined but not used [-Wunused-function]
Fix this by using CONFIG_PM_SLEEP instead of CONFIG_PM and removing it
from the driver pm ops as this has been taken care by
SIMPLE_DEV_PM_OPS() already.
Maxime Ripard [Thu, 3 Apr 2014 21:50:02 +0000 (14:50 -0700)]
rtc: sunxi: change compatibles
The Allwinner A10 compatibles were following a slightly different
compatible patterns than the rest of the SoCs for historical reasons.
Change the compatibles to match the other pattern in the RTC driver for
consistency.
Remove unnecessary locks when reading the time and make the read
operation until the values of day matched between reading the seconds,
it will make the mc13xxx_rtc_read_time() procedure more readable.
Additionally, patch introduced a "seconds in a day" definition.
Datasheet says: "When the VSRTC voltage drops to the range of 0.9 - 0.8V,
the RTCPORB reset signal is generated and the contents of the RTC will
be reset. <skip>. To inform the processor that the contents of the RTC
are no longer valid due to the reset, a timer reset interrupt function
is implemented with the RTCRSTI bit." This patch makes the RTC valid by
default until RTCRST interrupt occurs.
Interrupts can appear after request_irq and interrupt handlers can use
the RTC device, but currently we register RTC after IRQs. This patch
changes this order and simplify error path a bit.
Since we no longer allow building without hotplug, the
mc13xxx_rtc_remove() function is always present and we should not use
__exit_p() to refer to it.
Simon Guinot [Thu, 3 Apr 2014 21:49:55 +0000 (14:49 -0700)]
drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x chips
Add alarm support for the Microchip RTC devices MCP794xx. Note that two
programmable alarms are provided by the chip but only one is used by the
driver.
In order to allow the creation of the sysfs attribute wakealarm, this
patch moves the device_set_wakeup_capable() call above the RTC device
registration.
Xianglong Du [Thu, 3 Apr 2014 21:49:53 +0000 (14:49 -0700)]
drivers/rtc/rtc-sirfsoc.c: fix kernel panic of backing from hibernation
RTC settings will be lost if power supply is cut off after hibernation
finished, but the current "restore" function does not restore RTC related
settings, this causes rtc_read_time failure and kernel panic:
Jingoo Han [Thu, 3 Apr 2014 21:49:50 +0000 (14:49 -0700)]
rtc: rtc-jz4740: use devm_ioremap_resource()
Use devm_ioremap_resource() in order to make the code simpler, and move
'struct resource *mem' from 'struct jz4740_rtc' to jz4740_rtc_probe()
because the 'mem' variable is used only in jz4740_rtc_probe(). Also the
redundant return value check of platform_get_resource() is removed,
because the value is checked by devm_ioremap_resource().
Jingoo Han [Thu, 3 Apr 2014 21:49:49 +0000 (14:49 -0700)]
rtc: rtc-vt8500: use devm_ioremap_resource()
Use devm_ioremap_resource() in order to make the code simpler, and move
'struct resource *res' from 'struct vt8500_rtc' to vt8500_rtc_probe()
because the 'res' variable is used only in vt8500_rtc_probe().
Jingoo Han [Thu, 3 Apr 2014 21:49:48 +0000 (14:49 -0700)]
rtc: rtc-davinci: use devm_ioremap_resource()
Use devm_ioremap_resource() in order to make the code simpler, and
remove redundant return value check of platform_get_resource() because
the value is checked by devm_ioremap_resource().
Jingoo Han [Thu, 3 Apr 2014 21:49:47 +0000 (14:49 -0700)]
rtc: rtc-coh901331: use devm_ioremap_resource()
Use devm_ioremap_resource() in order to make the code simpler, and
remove redundant return value check of platform_get_resource() because
the value is checked by devm_ioremap_resource().
A commit hook for the Gerrit code review server [1] inserts change
identifiers so Gerrit can track patches through multiple revisions.
These identifiers are noise in the context of the upstream kernel.
(Many Gerrit servers are private. Even given a public instance, given
only a Change-Id, one must guess which server a change was tracked on.
Patches submitted to the Linux kernel mailing lists should be able to
stand on their own. If it's truly useful to reference code review on a
Gerrit server, a URL is a much clearer way to do so.) Thus, issue an
error when a Change-Id line is encountered before the Signed-off-by.
Joe Perches [Thu, 3 Apr 2014 21:49:28 +0000 (14:49 -0700)]
checkpatch: net and drivers/net: warn on missing blank line after variable declaration
Networking prefers this style, so warn when it's not used.
Networking uses:
void foo(int bar)
{
int baz;
code...
}
not
void foo(int bar)
{
int baz;
code...
}
There are a limited number of false positives when using macros to
declare variables like:
WARNING: networking uses a blank line after declarations
#330: FILE: net/ipv4/inet_hashtables.c:330:
+ int dif = sk->sk_bound_dev_if;
+ INET_ADDR_COOKIE(acookie, saddr, daddr)
checkpatch.pl: modify warning message for printk usage
Modify warning message when printk is used in a patch. It mentions to
use subsystem_dbg instead of netdev_dbg as the first preferred format of
logging debug messages.
Joe Perches [Thu, 3 Apr 2014 21:49:20 +0000 (14:49 -0700)]
checkpatch: ignore networking block comment style first lines in file
It's very common to have normal block comments for the initial comments
of a file description preface.
So for files in drivers/net and net/ don't emit a warning when the first
comment block in the file uses the normal block comment style and not
the networking block comment style.
Joe Perches [Thu, 3 Apr 2014 21:49:11 +0000 (14:49 -0700)]
checkpatch: add test for long udelay
Holger reported:
: The macro udelay cannot handle large values because of loss-of-precision.
:
: IMHO udelay on ARM is broken, because it also cannot work with fast
: ARM processors (where bogomips >= 3355, which is in sight now). It's
: just not broken enough that someone did something against it ... so
: the current kludge is good enough.
Until then, warn on long udelay uses.
Also fix uses of $line that should have been $herecurr.
lib/decompress_inflate.c: include appropriate header file
Include appropriate header file include/linux/decompress/inflate.h in
lib/decompress_inflate.c because it has prototype declaration of
function defined in lib/decompress_inflate.c.
Also, fix the guard around the header file
include/linux/decompress/inflate.h to use a more unique guard symbol.
This avoids conflict with the INFLATE_H defined by
zlib_inflate/inflate.h.
This eliminates the following warning in lib/decompress_inflate.c:
lib/decompress_inflate.c:35:17: warning: no previous prototype for `gunzip' [-Wmissing-prototypes]
lib/clz_ctz.c: add prototype declarations in lib/clz_ctz.c
Add prototype declarations of functions in lib/clz_ctz.c. These
functions are required by GCC builtins and hence can not be removed
despite of their unreferenced appearance in kernel source.
This eliminates the following warning in lib/clz_ctz.c:
lib/clz_ctz.c:16:12: warning: no previous prototype for `__ctzsi2' [-Wmissing-prototypes]
lib/clz_ctz.c:22:12: warning: no previous prototype for `__clzsi2' [-Wmissing-prototypes]
lib/clz_ctz.c:44:12: warning: no previous prototype for `__clzdi2' [-Wmissing-prototypes]
lib/clz_ctz.c:50:12: warning: no previous prototype for `__ctzdi2' [-Wmissing-prototypes]
Daniel Borkmann [Thu, 3 Apr 2014 21:49:08 +0000 (14:49 -0700)]
lib/random32.c: minor cleanups and kdoc fix
These are just some very minor and misc cleanups in the PRNG. In
prandom_u32() we store the result in an unsigned long which is
unnecessary as it should be u32 instead that we get from
prandom_u32_state(). prandom_bytes_state()'s comment is in kdoc format,
so change it into such as it's done everywhere else. Also, use the
normal comment style for the header comment. Last but not least for
readability, add some newlines.
Steven Rostedt [Thu, 3 Apr 2014 21:49:07 +0000 (14:49 -0700)]
lib/devres.c: fix some sparse warnings
Having a discussion about sparse warnings in the kernel, and that we
should clean them up, I decided to pick a random file to do so. This
happened to be devres.c which gives the following warnings:
CHECK lib/devres.c
lib/devres.c:83:9: warning: cast removes address space of expression
lib/devres.c:117:31: warning: incorrect type in return expression (different address spaces)
lib/devres.c:117:31: expected void [noderef] <asn:2>*
lib/devres.c:117:31: got void *
lib/devres.c:125:31: warning: incorrect type in return expression (different address spaces)
lib/devres.c:125:31: expected void [noderef] <asn:2>*
lib/devres.c:125:31: got void *
lib/devres.c:136:26: warning: incorrect type in assignment (different address spaces)
lib/devres.c:136:26: expected void [noderef] <asn:2>*[assigned] dest_ptr
lib/devres.c:136:26: got void *
lib/devres.c:226:9: warning: cast removes address space of expression
Mostly it's just the use of typecasting to void * without adding
__force, or returning ERR_PTR(-ESOMEERR) without typecasting to a
__iomem type.
I added a helper macro IOMEM_ERR_PTR() that does the typecast to make
the code a little nicer than adding ugly typecasts to the code.
Liu Ying [Thu, 3 Apr 2014 21:48:55 +0000 (14:48 -0700)]
backlight: update backlight status when necessary
We don't have to update a backlight status every time a blanking or
unblanking event comes because the backlight status may have already
been what we want. Another thought is that one backlight device may be
shared by multiple framebuffers. We don't hope blanking one of the
framebuffers may turn the backlight off for all the other framebuffers,
since they are likely being active to display something.
This patch makes the backlight status be updated only when the relevant
backlight device's use count changes from zero to one or from one to
zero.
Liu Ying [Thu, 3 Apr 2014 21:48:54 +0000 (14:48 -0700)]
backlight: update bd state & fb_blank properties when necessary
We don't have to update the state and fb_blank properties of a backlight
device every time a blanking or unblanking event comes because they may
have already been what we want. Another thought is that one backlight
device may be shared by multiple framebuffers. The backlight driver
should take the backlight device as a resource shared by all the
associated framebuffers.
This patch adds some logic to record each framebuffer's backlight usage
to determine the backlight device use count and whether the two
properties should be updated or not. To be more specific, only one
unblank operation on a certain blanked framebuffer may increase the
backlight device's use count by one, while one blank operation on a
certain unblanked framebuffer may decrease the use count by one, because
the userspace is likely to unblank an unblanked framebuffer or blank a
blanked framebuffer.
Michal Simek [Thu, 3 Apr 2014 21:48:52 +0000 (14:48 -0700)]
MAINTAINERS: microblaze: use LKML as mailing list
microblaze-uclinux mailing list is almost dead and it is just causing
troubles for non subscribers which are getting email about waiting for
moderator. Approval never happens. Move it to LKML.
MAINTAINERS: addition of Dialog Semiconductor files
Dialog Semiconductor Ltd would like to add a new section called DIALOG
SEMICONDUCTOR DRIVERS which contains a new e-mail address that can cover
all Dialog supported drivers: [email protected].
Jingoo Han [Thu, 3 Apr 2014 21:48:46 +0000 (14:48 -0700)]
MAINTAINERS: add backlight co-maintainers
Bryan Wu and Lee Jones volunteer to maintain backlight drivers and help
to setup git-tree for backlight subsystem. Thus, I add them as
backlight co-maintainers.
======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0 #2 Tainted: G O
-------------------------------------------------------
sh/1271 is trying to acquire lock:
(console_lock){+.+.+.}, at: console_cpu_notify+0x20/0x2c
but task is already holding lock:
(cpu_hotplug.lock){+.+.+.}, at: cpu_hotplug_begin+0x2c/0x58
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (cpu_hotplug.lock){+.+.+.}:
lock_acquire+0x98/0x12c
mutex_lock_nested+0x50/0x3d8
cpu_hotplug_begin+0x2c/0x58
_cpu_up+0x24/0x154
cpu_up+0x64/0x84
smp_init+0x9c/0xd4
kernel_init_freeable+0x78/0x1c8
kernel_init+0x8/0xe4
ret_from_fork+0x14/0x2c
There are three locks involved in two sequence:
a) pm suspend:
console_lock (@suspend_console())
cpu_add_remove_lock (@disable_nonboot_cpus())
cpu_hotplug.lock (@_cpu_down())
b) Plug-out CPUx:
cpu_add_remove_lock (@(cpu_down())
cpu_hotplug.lock (@_cpu_down())
console_lock (@console_cpu_notify()) => Lockdeps prints warning log.
There should be not real deadlock, as flag of console_suspended can
protect this.
Although console_suspend() releases console_sem, it doesn't tell lockdep
about it. That results in the lockdep warning about circular locking
when doing the following: enter suspend -> resume -> plug-out CPUx (echo
0 > cpux/online)
Fix the problem by telling lockdep we actually released the semaphore in
console_suspend() and acquired it again in console_resume().
Petr Mladek [Thu, 3 Apr 2014 21:48:42 +0000 (14:48 -0700)]
printk: use also the last bytes in the ring buffer
It seems that we have newer used the last byte in the ring buffer. In
fact, we have newer used the last 4 bytes because of padding.
First problem is in the check for free space. The exact number of free
bytes is enough to store the length of data.
Second problem is in the check where the ring buffer is rotated. The
left side counts the first unused index. It is unused, so it might be
the same as the size of the buffer.
Note that the first problem has to be fixed together with the second
one. Otherwise, the buffer is rotated even when there is enough space
on the end of the buffer. Then the beginning of the buffer is rewritten
and valid entries get corrupted.
projects / linux.git / log