A common operation for a clock signal generator is to shift the phase of
that signal. This patch introduces a new function to the clk.h API to
dynamically adjust the phase of a clock signal. Additionally this patch
introduces support for the new function in the common clock framework
via the .set_phase call back in struct clk_ops.
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
The third argument of fuse_get_user_pages() "nbytesp" refers to the number of
bytes a caller asked to pack into fuse request. This value may be lesser
than capacity of fuse request or iov_iter. So fuse_get_user_pages() must
ensure that *nbytesp won't grow.
Now, when helper iov_iter_get_pages() performs all hard work of extracting
pages from iov_iter, it can be done by passing properly calculated
"maxsize" to the helper.
The other caller of iov_iter_get_pages() (dio_refill_pages()) doesn't need
this capability, so pass LONG_MAX as the maxsize argument here.
Fixes: c9c37e2e63 ("fuse: switch to iov_iter_get_pages()")
Reported-by: Werner Baumann <werner.baumann@onlinehome.de>
Tested-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
The added gpio-gate-clock is a basic clock that can be enabled and
disabled trough a gpio output. The DT binding document for the clock
is also added. For EPROBE_DEFER handling the registering of the clock
has to be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
csum_partial() is a generic function which is not optimised for small fixed
length calculations, and its use requires to store "from" and "to" values in
memory while we already have them available in registers. This also has impact,
especially on RISC processors. In the same spirit as the change done by
Eric Dumazet on csum_replace2(), this patch rewrites inet_proto_csum_replace4()
taking into account RFC1624.
I spotted during a NATted tcp transfert that csum_partial() is one of top 5
consuming functions (around 8%), and the second user of csum_partial() is
inet_proto_csum_replace4().
I have proposed the same modification to inet_proto_csum_replace4() in another
patch.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
While profiling TCP stack, I noticed one useless atomic operation
in tcp_sendmsg(), caused by skb_header_release().
It turns out all current skb_header_release() users have a fresh skb,
that no other user can see, so we can avoid one atomic operation.
Introduce __skb_header_release() to clearly document this.
This gave me a 1.5 % improvement on TCP_RR workload.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John W. Linville says:
====================
pull request: wireless-next 2014-09-22
Please pull this batch of updates intended for the 3.18 stream...
For the mac80211 bits, Johannes says:
"This time, I have some rate minstrel improvements, support for a very
small feature from CCX that Steinar reverse-engineered, dynamic ACK
timeout support, a number of changes for TDLS, early support for radio
resource measurement and many fixes. Also, I'm changing a number of
places to clear key memory when it's freed and Intel claims copyright
for code they developed."
For the bluetooth bits, Johan says:
"Here are some more patches intended for 3.18. Most of them are cleanups
or fixes for SMP. The only exception is a fix for BR/EDR L2CAP fixed
channels which should now work better together with the L2CAP
information request procedure."
For the iwlwifi bits, Emmanuel says:
"I fix here dvm which was broken by my last pull request. Arik
continues to work on TDLS and Luca solved a few issues in CT-Kill. Eyal
keeps digging into rate scaling code, more to come soon. Besides this,
nothing really special here."
Beyond that, there are the usual big batches of updates to ath9k, b43,
mwifiex, and wil6210 as well as a handful of other bits here and there.
Also, rtlwifi gets some btcoexist attention from Larry.
Please let me know if there are problems!
====================
Had to adjust the wil6210 code to comply with Joe Perches's recent
change in net-next to make the netdev_*() routines return void instead
of 'int'.
Signed-off-by: David S. Miller <davem@davemloft.net>
No caller or macro uses the return value so make all
the functions return void.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds verifier core which simulates execution of every insn and
records the state of registers and program stack. Every branch instruction seen
during simulation is pushed into state stack. When verifier reaches BPF_EXIT,
it pops the state from the stack and continues until it reaches BPF_EXIT again.
For program:
1: bpf_mov r1, xxx
2: if (r1 == 0) goto 5
3: bpf_mov r0, 1
4: goto 6
5: bpf_mov r0, 2
6: bpf_exit
The verifier will walk insns: 1, 2, 3, 4, 6
then it will pop the state recorded at insn#2 and will continue: 5, 6
This way it walks all possible paths through the program and checks all
possible values of registers. While doing so, it checks for:
- invalid instructions
- uninitialized register access
- uninitialized stack access
- misaligned stack access
- out of range stack access
- invalid calling convention
- instruction encoding is not using reserved fields
Kernel subsystem configures the verifier with two callbacks:
- bool (*is_valid_access)(int off, int size, enum bpf_access_type type);
that provides information to the verifer which fields of 'ctx'
are accessible (remember 'ctx' is the first argument to eBPF program)
- const struct bpf_func_proto *(*get_func_proto)(enum bpf_func_id func_id);
returns argument constraints of kernel helper functions that eBPF program
may call, so that verifier can checks that R1-R5 types match the prototype
More details in Documentation/networking/filter.txt and in kernel/bpf/verifier.c
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
eBPF programs passed from userspace are using pseudo BPF_LD_IMM64 instructions
to refer to process-local map_fd. Scan the program for such instructions and
if FDs are valid, convert them to 'struct bpf_map' pointers which will be used
by verifier to check access to maps in bpf_map_lookup/update() calls.
If program passes verifier, convert pseudo BPF_LD_IMM64 into generic by dropping
BPF_PSEUDO_MAP_FD flag.
Note that eBPF interpreter is generic and knows nothing about pseudo insns.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
add optional attributes for BPF_PROG_LOAD syscall:
union bpf_attr {
struct {
...
__u32 log_level; /* verbosity level of eBPF verifier */
__u32 log_size; /* size of user buffer */
__aligned_u64 log_buf; /* user supplied 'char *buffer' */
};
};
when log_level > 0 the verifier will return its verification log in the user
supplied buffer 'log_buf' which can be used by program author to analyze why
verifier rejected given program.
'Understanding eBPF verifier messages' section of Documentation/networking/filter.txt
provides several examples of these messages, like the program:
BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
BPF_LD_MAP_FD(BPF_REG_1, 0),
BPF_CALL_FUNC(BPF_FUNC_map_lookup_elem),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1),
BPF_ST_MEM(BPF_DW, BPF_REG_0, 4, 0),
BPF_EXIT_INSN(),
will be rejected with the following multi-line message in log_buf:
0: (7a) *(u64 *)(r10 -8) = 0
1: (bf) r2 = r10
2: (07) r2 += -8
3: (b7) r1 = 0
4: (85) call 1
5: (15) if r0 == 0x0 goto pc+1
R0=map_ptr R10=fp
6: (7a) *(u64 *)(r0 +4) = 0
misaligned access off 4 size 8
The format of the output can change at any time as verifier evolves.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
this patch adds all of eBPF verfier documentation and empty bpf_check()
The end goal for the verifier is to statically check safety of the program.
Verifier will catch:
- loops
- out of range jumps
- unreachable instructions
- invalid instructions
- uninitialized register access
- uninitialized stack access
- misaligned stack access
- out of range stack access
- invalid calling convention
More details in Documentation/networking/filter.txt
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
eBPF programs are similar to kernel modules. They are loaded by the user
process and automatically unloaded when process exits. Each eBPF program is
a safe run-to-completion set of instructions. eBPF verifier statically
determines that the program terminates and is safe to execute.
The following syscall wrapper can be used to load the program:
int bpf_prog_load(enum bpf_prog_type prog_type,
const struct bpf_insn *insns, int insn_cnt,
const char *license)
{
union bpf_attr attr = {
.prog_type = prog_type,
.insns = ptr_to_u64(insns),
.insn_cnt = insn_cnt,
.license = ptr_to_u64(license),
};
return bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
}
where 'insns' is an array of eBPF instructions and 'license' is a string
that must be GPL compatible to call helper functions marked gpl_only
Upon succesful load the syscall returns prog_fd.
Use close(prog_fd) to unload the program.
User space tests and examples follow in the later patches
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
'maps' is a generic storage of different types for sharing data between kernel
and userspace.
The maps are accessed from user space via BPF syscall, which has commands:
- create a map with given type and attributes
fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size)
returns fd or negative error
- lookup key in a given map referenced by fd
err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero and stores found elem into value or negative error
- create or update key/value pair in a given map
err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero or negative error
- find and delete element by key in a given map
err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key
- iterate map elements (based on input key return next_key)
err = bpf(BPF_MAP_GET_NEXT_KEY, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->next_key
- close(fd) deletes the map
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
done as separate commit to ease conflict resolution
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
BPF syscall is a multiplexor for a range of different operations on eBPF.
This patch introduces syscall with single command to create a map.
Next patch adds commands to access maps.
'maps' is a generic storage of different types for sharing data between kernel
and userspace.
Userspace example:
/* this syscall wrapper creates a map with given type and attributes
* and returns map_fd on success.
* use close(map_fd) to delete the map
*/
int bpf_create_map(enum bpf_map_type map_type, int key_size,
int value_size, int max_entries)
{
union bpf_attr attr = {
.map_type = map_type,
.key_size = key_size,
.value_size = value_size,
.max_entries = max_entries
};
return bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
}
'union bpf_attr' is backwards compatible with future extensions.
More details in Documentation/networking/filter.txt and in manpage
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
openrisc:defconfig fails to build in next-20140926 with the following error.
In file included from arch/openrisc/kernel/signal.c:31:0:
./arch/openrisc/include/asm/syscall.h: In function 'syscall_get_arch':
./arch/openrisc/include/asm/syscall.h:77:9: error: 'EM_OPENRISC' undeclared
Fix by moving EM_OPENRISC to include/uapi/linux/elf-em.h.
Fixes: ce5d112827 ("ARCH: AUDIT: implement syscall_get_arch for all arches")
Cc: Eric Paris <eparis@redhat.com>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Eric Paris <eparis@redhat.com>
This is the NFC pull request for 3.18.
We've had major updates for TI and ST Microelectronics drivers:
For TI's trf7970a driver:
- Target mode support for trf7970a
- Suspend/resume support for trf7970a
- DT properties additions to handle different quirks
- A bunch of fixes for smartphone IOP related issues
For ST Microelectronics' ST21NFCA and ST21NFCB drivers:
- ISO15693 support for st21nfcb
- checkpatch and sparse related warning fixes
- Code cleanups and a few minor fixes
Finally, Marvell add ISO15693 support to the NCI stack, together with a
couple of NCI fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUIg4oAAoJEIqAPN1PVmxKg+kP/RPrgH6LA1tFubIwKR2+sGQ7
g/W2J3AE8QASZkErkpXRNCt2D/SPWEKBY/qscwz+BtcWg76taIIaGTvVUNtxSaW3
gS4hG6V1UlANWv3KFfaOKmzjEOO/SPNtkFAyI0cTOaGyUqG4o9BgBZpn1rYO16MD
ZkSC39MpjMoXB9BbsfQngoUEoWc3tZNMmRzk4IVTwE/wXuQvZxmFQXEAiZ+pnYle
NQfugaGMz0526rLG3QnrpkUakFb81iQwtONpbx6i8KW/Klkc6TN/ek6J9ecU8t5z
tdHOViZWRmA1VwMGBHwpq8F2o/ATH6GeivTgqrQjcjGNhCUUT1Ulzve2UxGEMWi6
ncjKY/GxUrYaMMtRvLv+/knrfbWtd+EnWOav07jgNrrA0tvgBNQvEKKHPoWykDVN
QKpxu3YoNxrsR/LJMS+Zjj0IIM1Y+9DTOkLXzxJ5Hvht8rOl5heYGh2DICOpWsbQ
ejrQicJOJvN5vqu+Sgcqq4msyTEdbs2LfRDrW1VC9A6ILI+KzYg2laTFGMnhZ5qn
TgsYIDdONS2iGUulFHylGHI7ANtUg/mhklLUccY1HQYyiAM1NQUtzq1tAz6yLoIH
l8iIiyzJSBWW57nWhyrULEbzHgPE+bHIjO4T+UUOxMgquYa4V11S1uP0OfWfZogR
xS24GlobS2oXHMQqh0fA
=d/C+
-----END PGP SIGNATURE-----
Merge tag 'nfc-next-3.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next
Samuel Ortiz <sameo@linux.intel.com> says:
"NFC: 3.18 pull request
This is the NFC pull request for 3.18.
We've had major updates for TI and ST Microelectronics drivers:
For TI's trf7970a driver:
- Target mode support for trf7970a
- Suspend/resume support for trf7970a
- DT properties additions to handle different quirks
- A bunch of fixes for smartphone IOP related issues
For ST Microelectronics' ST21NFCA and ST21NFCB drivers:
- ISO15693 support for st21nfcb
- checkpatch and sparse related warning fixes
- Code cleanups and a few minor fixes
Finally, Marvell add ISO15693 support to the NCI stack, together with a
couple of NCI fixes."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jesper reported that br_netfilter always registers the hooks since
this is part of the bridge core. This harms performance for people that
don't need this.
This patch modularizes br_netfilter so it can be rmmod'ed, thus,
the hooks can be unregistered. I think the bridge netfilter should have
been a separated module since the beginning, Patrick agreed on that.
Note that this is breaking compatibility for users that expect that
bridge netfilter is going to be available after explicitly 'modprobe
bridge' or via automatic load through brctl.
However, the damage can be easily undone by modprobing br_netfilter.
The bridge core also spots a message to provide a clue to people that
didn't notice that this has been deprecated.
On top of that, the plan is that nftables will not rely on this software
layer, but integrate the connection tracking into the bridge layer to
enable stateful filtering and NAT, which is was bridge netfilter users
seem to require.
This patch still keeps the fake_dst_ops in the bridge core, since this
is required by when the bridge port is initialized. So we can safely
modprobe/rmmod br_netfilter anytime.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Florian Westphal <fw@strlen.de>
Move nf_bridge_copy_header() as static inline in netfilter_bridge.h
header file. This patch prepares the modularization of the br_netfilter
code.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
While comparing the OMAP-serial and the 8250 part of this I noticed that
the latter does not use run time-pm. Here are the pieces. It is
basically a get before first register access and a last_busy + put after
last access. This has to be enabled from userland _and_ UART_CAP_RPM is
required for this.
The runtime PM can usually work transparently in the background however
there is one exception to this: After serial8250_tx_chars() completes
there still may be unsent bytes in the FIFO (depending on CPU speed vs
baud rate + flow control). Even if the TTY-buffer is empty we do not
want RPM to disable the device because it won't send the remaining
bytes. Instead we leave serial8250_tx_chars() with RPM enabled and wait
for the FIFO empty interrupt. Once we enter serial8250_tx_chars() with
an empty buffer we know that the FIFO is empty and since we are not going
to send anything, we can disable the device.
That xchg() is to ensure that serial8250_tx_chars() can be called
multiple times and only the first invocation will actually invoke the
runtime PM function. So that the last invocation of __stop_tx() will
disable runtime pm.
NOTE: do not enable RPM on the device unless you know what you do! If
the device goes idle, it won't be woken up by incomming RX data _unless_
there is a wakeup irq configured which is usually the RX pin configure
for wakeup via the reset module. The RX activity will then wake up the
device from idle. However the first character is garbage and lost. The
following bytes will be received once the device is up in time. On the
beagle board xm (omap3) it takes approx 13ms from the first wakeup byte
until the first byte that is received properly if the device was in
core-off.
v5…v8:
- drop RPM from serial8250_set_mctrl() it will be used in
restore path which already has RPM active and holds
dev->power.lock
v4…v5:
- add a wrapper around rpm function and introduce UART_CAP_RPM
to ensure RPM put is invoked after the TX FIFO is empty.
v3…v4:
- added runtime to the console code
- removed device_may_wakeup() from serial8250_set_sleep()
Cc: mika.westerberg@linux.intel.com
Reviewed-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The OMAP UART provides support for HW assisted flow control. What is
missing is the support to throttle / unthrottle callbacks which are used
by the omap-serial driver at the moment.
This patch adds the callbacks. It should be safe to add them since they
are only invoked from the serial_core (uart_throttle()) if the feature
flags are set.
Reviewed-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull scheduler fixes from Ingo Molnar:
"A CONFIG_STACK_GROWSUP=y fix, and a hotplug llc CPU mask fix"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched: Fix unreleased llc_shared_mask bit during CPU hotplug
sched: Fix end_of_stack() and location of stack canary for architectures using CONFIG_STACK_GROWSUP
This is detected with:
gcc-4.8.3-7.fc20.x86_64
sparse-0.5.0-3.fc20.x86_64
drivers/media/v4l2-core/v4l2-dv-timings.c:34:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:35:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:36:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:37:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:38:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:39:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:40:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:41:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:42:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:43:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:44:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:45:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:46:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:47:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:48:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:49:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:50:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:51:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:52:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:53:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:54:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:55:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:56:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:57:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:58:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:59:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:60:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:61:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:62:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:63:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:64:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:65:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:66:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:67:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:68:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:69:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:70:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:71:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:72:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:73:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:74:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:75:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:76:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:77:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:78:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:79:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:80:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:81:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:82:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:83:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:84:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:85:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:86:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:87:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:88:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:89:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:90:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:91:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:92:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:93:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:94:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:95:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:96:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:97:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:98:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:99:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c💯9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:101:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:102:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:103:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:104:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:105:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:106:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:107:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:108:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:109:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:110:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:111:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:112:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:113:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:114:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:115:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:116:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:117:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:118:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:119:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:120:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:121:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:122:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:123:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:124:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:125:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:126:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:127:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:128:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:129:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:130:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:131:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:132:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:133:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:134:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:135:9: error: too many errors
drivers/media/usb/hdpvr/hdpvr-video.c:42:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:43:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:44:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:45:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:46:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:47:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:48:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:49:9: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:484:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:485:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:486:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:487:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:488:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:489:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:490:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:491:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:492:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:493:18: error: unknown field name in initializer
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
If an MFD device is backed by ACPI namespace, we should allow subdevice
drivers to access their corresponding ACPI companion devices through normal
means (e.g using ACPI_COMPANION()).
This patch adds such support to the MFD core. If the MFD parent device
does not specify any ACPI _HID/_CID for the child device, the child
device will share the parent ACPI companion device. Otherwise the child
device will be assigned with the corresponding ACPI companion, if found
in the namespace below the parent.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The logic in AFE_Pen_Ctrl bitmask in the CTRL register is different for five
wire versus four or eight wire touschscreens. This patch should fix this for
five-wire touch screens. There should be no change needed here for four and
eight wire tousch screens.
Signed-off-by: Jeff Lance <j-lance1@ti.com>
[bigeasy: keep the change mfd only]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Allow regmap to provide debugfs access to the register map by telling it
what registers are valid.
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This adds driver to support HiSilicon Hi6421 PMIC. Hi6421 includes multi-
functions, such as regulators, codec, ADCs, Coulomb counter, etc.
This driver includes core APIs _only_.
Drivers for individul components, like voltage regulators, are
implemented in corresponding driver directories and files.
Registers in Hi6421 are memory mapped, so using regmap-mmio API.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This patch adds the PCI id for Intel Quark ILB.
It will be used for GPIO and Multifunction device driver.
Signed-off-by: Josef Ahmad <josef.ahmad@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The RK808 chip is a power management IC for multimedia and handheld
devices. It contains the following components:
- Regulators
- RTC
- Clkout
The RK808 core driver is registered as a platform driver and provides
communication through I2C with the host device for the different
components.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Zhang Qing <zhangqing@rock-chips.com>
Tested-by: Heiko <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Add device tree bindings documentation and a header file
for rockchip's RK808 pmic.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Zhang Qing <zhangqing@rock-chips.com>
Tested-by: Heiko <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Current code init regmap with &da9052_regmap_config for both da9052-spi and
da9052-i2c drivers. da9052-spi sets the read_flag_mask.
The same setting may be applied for da9052-i2c if da9052-spi driver is loaded
first because they actually use the same regmap_config setting.
Fix this issue by using a local variable for regmap_config in da9052-spi driver,
so the settings in spi driver won't impact the settings in i2c driver.
Also makes da9052_regmap_config const to avoid similar issue.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Some arizona devices have a second asynchronous sample rate, add the
registers necessary to support this.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Ricoh RN5T618 is a power management IC which integrates 3 step-down
DCDC converters, 7 low-dropout regulators, a Li-ion battery charger,
fuel gauge, ADC, GPIOs and a watchdog timer.
This commit adds a MFD core driver to support the I2C communication
with the device.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The include guard doesn't work as intended due to the transposition
typo DAVINCI -> DAVINIC.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The header file include/linux/mfd/ti_ssp.h does not seem to be used
anywhere. It was orphaned by 3033ee62 "mfd: Remove obsolete ti-ssp
driver". Remove it.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This patch improves support for the flash cell of
max77693 mfd by adding relevant of_compatible field
and a structure for caching related platform data.
Added are also FLASH registers related macro definitions.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
According to the MAX77693 documentation the name of
the register is FLASH_STATUS.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
During init the core checks if the wm5102 has finished starting by reading
register 0x19 and looking at the value. This read always fails since this
is not a readable register, mark it as being one. While we're at it provide
a constant for the register name (as supplied by Charles Keepax).
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Calling strncpy with a maximum size argument of 32 bytes on destination
array kim_gdata->dev_name of size 32 bytes might leave the destination
string unterminated.
Cc: gregkh@linuxfoundation.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Various drivers implement architecture and/or device specific means to
restart (reset) the system. Various mechanisms have been implemented to
support those schemes. The best known mechanism is arm_pm_restart, which
is a function pointer to be set either from platform specific code or from
drivers. Another mechanism is to use hardware watchdogs to issue a reset;
this mechanism is used if there is no other method available to reset a
board or system. Two examples are alim7101_wdt, which currently uses the
reboot notifier to trigger a reset, and moxart_wdt, which registers the
arm_pm_restart function.
The existing mechanisms have a number of drawbacks. Typically only one
scheme to restart the system is supported (at least if arm_pm_restart is
used). At least in theory there can be multiple means to restart the
system, some of which may be less desirable (for example one mechanism may
only reset the CPU, while another may reset the entire system). Using
arm_pm_restart can also be racy if the function pointer is set from a
driver, as the driver may be in the process of being unloaded when
arm_pm_restart is called. Using the reboot notifier is always racy, as it
is unknown if and when other functions using the reboot notifier have
completed execution by the time the watchdog fires.
Introduce a system restart handler call chain to solve the described
problems. This call chain is expected to be executed from the
architecture specific machine_restart() function. Drivers providing
system restart functionality (such as the watchdog drivers mentioned
above) are expected to register with this call chain. By using the
priority field in the notifier block, callers can control restart handler
execution sequence and thus ensure that the restart handler with the
optimal restart capabilities for a given system is called first.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jonas Jensen <jonas.jensen@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The send_check logic was only interesting in cases of TCP offload and
UDP UFO where the checksum needed to be initialized to the pseudo
header checksum. Now we've moved that logic into the related
gso_segment functions so gso_send_check is no longer needed.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If CONFIG_COMMON_CLK is selected then __clk_get and __clk_put are
defined in drivers/clk/clk.c and declared in include/linux/clkdev.h.
Sylwester's series[0] to properly support clk_{get,put} in the common
clock framework made changes to the asm-specific clkdev.h headers, but
not the asm-generic version. Tomeu's recent changes[1] to introduce a
provider/consumer split in the clock framework uncovered this problem,
causing the following build error on any architecture using the
asm-generic clkdev.h (e.g. x86 architecture and the ACPI LPSS driver):
In file included from drivers/acpi/acpi_lpss.c:15:0:
include/linux/clkdev.h:59:5: error: conflicting types for ‘__clk_get’
int __clk_get(struct clk_core *clk);
^
In file included from arch/x86/include/generated/asm/clkdev.h:1:0,
from include/linux/clkdev.h:15,
from drivers/acpi/acpi_lpss.c:15:
include/asm-generic/clkdev.h:20:19: note: previous definition of ‘__clk_get’ was here
static inline int __clk_get(struct clk *clk) { return 1; }
^
Fixed by only declarating __clk_get and __clk_put when
CONFIG_COMMON_CLK is set.
[0] http://lkml.kernel.org/r/<1386177127-2894-5-git-send-email-s.nawrocki@samsung.com>
[1] http://lkml.kernel.org/r/<1409758148-20104-1-git-send-email-tomeu.vizoso@collabora.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
- Revert of a recent hibernation core commit that introduced
a NULL pointer dereference during resume for at least one user
(Rafael J Wysocki).
- Fix for the ACPI LPSS (Low-Power Subsystem) driver to disable
asynchronous PM callback execution for LPSS devices during system
suspend/resume (introduced in 3.16) which turns out to break
ordering expectations on some systems. From Fu Zhonghui.
- cpufreq core fix related to the handling of sysfs nodes during
system suspend/resume that has been broken for intel_pstate
since 3.15 from Lan Tianyu.
- Restore the generation of "online" uevents for ACPI container
devices that was removed in 3.14, but some user space utilities
turn out to need them (Rafael J Wysocki).
- The cpufreq core fails to release a lock in an error code path
after changes made in 3.14. Fix from Prarit Bhargava.
- ACPICA and ACPI/GPIO fixes to make the handling of ACPI GPIO
operation regions (which means AML using GPIOs) work correctly
in all cases from Bob Moore and Srinivas Pandruvada.
- Fix for a wrong sign of the ACPI core's create_modalias() return
value in case of an error from Mika Westerberg.
- ACPI backlight blacklist entry for ThinkPad X201s from Aaron Lu.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJUJJGgAAoJEILEb/54YlRxt3kP/19OjVjGK/lFKJk4LCmQ77k5
6DDF7/clNJmYBkKBXGdyqqRVdDUXjRuHS1Yd78zWMmwdLtdOcyI+wBjG1w0mMU7o
vAYvXkIks9fCeKBRHSlqdtQROFf3+bxothKD8JGTONA5z4Fih40fqsnuSW8G7uJs
iTEQQK7L2uPJ+w1OnltwN6eNgzN5KqfxgxI+L6DhEMRjWXRHuhfRZorVIjvz+ALV
Fjm8shhjnhQKzS2zuv5PZ5gGM7zZBH7hy7kd4aDYsbppOLAB2pMOwVs0sgC1Xcbv
teyWkyzmhix2Z1bX9wwia5FfMgbnY2leejJN7mukKzHz8CQ1vxS98Sji2uviIAej
Ctp6GKjuemGvjryjbkstD6r3KYS8CuWAL++YwlamqSa0eWBuM+aD9YqGj4i6ntbU
8BFT5KXauOIsA5U51zC8wNUDHoTgBcvoN99zNIM1jIF81M7wuQrXUzJLXBStuSlR
/bDpExwxHt7I6MeUfRTjg37ApVNRAiStw32+DfsKAj4HLsqTkGs1879Paxf30T0f
Z2SlYr5Jeusu5u9DNhk7MG21A+m46R0jjLd1OKBbf2mrtfQfdKCo6szGR7vjEMZC
aGIlwtIA4iS4MN3UAyqOW3SxIPT2SxqPXzG/z27hRN5MUsGNWiClzcUsaaHoHmpp
GlbY/BvDYfur4NBeCSli
=SzQq
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
"These are regression fixes (ACPI hotplug, cpufreq, hibernation, ACPI
LPSS driver), fixes for stuff that never worked correctly (ACPI GPIO
support in some cases and a wrong sign of an error code in the ACPI
core in one place), and one blacklist item for ACPI backlight
handling.
Specifics:
- Revert of a recent hibernation core commit that introduced a NULL
pointer dereference during resume for at least one user (Rafael J
Wysocki).
- Fix for the ACPI LPSS (Low-Power Subsystem) driver to disable
asynchronous PM callback execution for LPSS devices during system
suspend/resume (introduced in 3.16) which turns out to break
ordering expectations on some systems. From Fu Zhonghui.
- cpufreq core fix related to the handling of sysfs nodes during
system suspend/resume that has been broken for intel_pstate since
3.15 from Lan Tianyu.
- Restore the generation of "online" uevents for ACPI container
devices that was removed in 3.14, but some user space utilities
turn out to need them (Rafael J Wysocki).
- The cpufreq core fails to release a lock in an error code path
after changes made in 3.14. Fix from Prarit Bhargava.
- ACPICA and ACPI/GPIO fixes to make the handling of ACPI GPIO
operation regions (which means AML using GPIOs) work correctly in
all cases from Bob Moore and Srinivas Pandruvada.
- Fix for a wrong sign of the ACPI core's create_modalias() return
value in case of an error from Mika Westerberg.
- ACPI backlight blacklist entry for ThinkPad X201s from Aaron Lu"
* tag 'pm+acpi-3.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()"
gpio / ACPI: Use pin index and bit length
ACPICA: Update to GPIO region handler interface.
ACPI / platform / LPSS: disable async suspend/resume of LPSS devices
cpufreq: release policy->rwsem on error
cpufreq: fix cpufreq suspend/resume for intel_pstate
ACPI / scan: Correct error return value of create_modalias()
ACPI / video: disable native backlight for ThinkPad X201s
ACPI / hotplug: Generate online uevents for ACPI containers
- introduction of the new SAMA5D4 SoC and associated Evaluation Kit
- low level soc detection and early printk code
- taking advantage of this, documentation of all AT91 SoC DT strings
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJUIB6OAAoJEAf03oE53VmQL+IIALNg2XPS49u2Y6VMjL3srFLt
7CUdNoGB7GJKoGrIXPSyAhJLkRlWREgRsEk/RSYqfBpyBZV4PIx9R6dIz1L+VxGU
9neXLkZGrYNzN8qJPz82+ARuCXdCF13N8ClVfXkNDhwbDnlbZgTkh4hNV118mKLt
+PF0d3w354ujieUD7D0pOcdRlny487qMNjtc/0U4P+H2sp2EtL0PpFHicn79InPT
V36PpFtUMEgbw2wQPNtlFkjQWstyZ7WJJGUbIX/2P3PASCwKsgrbmkvDvmfp5tUT
FdclJwJnxgcpni2fDvbz8Vq04i3hixl2Olm8tAvIXOI/hdVcurvZSfweJ5BrfDk=
=fMfO
-----END PGP SIGNATURE-----
Merge tag 'at91-soc2' of git://github.com/at91linux/linux-at91 into next/soc
Pull "Second SoC batch for 3.18" from Nicolas Ferre:
- introduction of the new SAMA5D4 SoC and associated Evaluation Kit
- low level soc detection and early printk code
- taking advantage of this, documentation of all AT91 SoC DT strings
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'at91-soc2' of git://github.com/at91linux/linux-at91:
ARM: at91: document Atmel SMART compatibles
ARM: at91: add sama5d4 support to sama5_defconfig
ARM: at91: dt: add device tree file for SAMA5D4ek board
ARM: at91: dt: add device tree file for SAMA5D4 SoC
ARM: at91: SAMA5D4 SoC detection code and low level routines
ARM: at91: introduce basic SAMA5D4 support
clk: at91: add a driver for the h32mx clock
- Remove unused pieces of the legacy DMA API as we're moving to
dmaengine API
- Search and replace to standardize on pr_warn instead of pr_warning
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUGzmvAAoJEBvUPslcq6Vz53kQAOAS6Rxp03mmjflegqkVzech
JUPBfGQHVwcpbYQU53+ZCt2Bfg0iaD6xL2BtBfS8tsaePDwqT6kVFrDBqWuIiT6S
Taq2NUzqAhdgva74a6VAh0VSpPK4ui3cdXRoXvMfZRvOtR8bbfAprAWYyWipy2RM
4y07a9dcd1SalcWDJttfXxBV7ImqXPf1e6dRtxYRBBshoNJ46/nk8nS9HblaoJbJ
L3FdmOw7x5jG1nSO4dmhsGzg0PmfjKJwe+rGYPVLuEPil6Sc0VDJxGF8ZyAyK+/K
r8ZvIdbWLiJ6ga/ehMNaZaz6sOsSPRAWWSTOOGUlJvBUiOgHH8P+/Y/3fCkcjTlT
Rg15sij0aBVQJNGNEif9xd19f1tnlthSnjIt593YnqElCN50lnNDBt+bVICTlszd
sXbPZtO8vZ0PHEDshBpWvjyPKyN1CrRTVHtGJXZr/zNWoK2Y1NvsdOYR36AlQugW
WhA5hklyJnRpdbiU84fBon9pbowAOIMcLctBqpK5RyqyC+vVgopcaoMWl9F1XW/r
cAcGVm/zAWfWm01XeuJu1R6DOdLxUvi0Sn7UrXcsPwEYR2pp0NdQQUmNEX3Ko9cW
rIO7emEqQvUdY/K+wa5HzhVMHk5VuBIUb8nT30KjOCEGOB7QhEb/6ly6D0pxLFJ0
RtC70hvqxGWawiNpGadr
=ZNTi
-----END PGP SIGNATURE-----
Merge tag 'cleanup-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup
Pull "Clean-up for omaps for v3.18 merge window" from Tony Lindgren:
- Remove unused pieces of the legacy DMA API as we're moving to
dmaengine API
- Search and replace to standardize on pr_warn instead of pr_warning
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'cleanup-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
arm: mach-omap2: Convert pr_warning to pr_warn
ARM: OMAP: Remove unused pieces of legacy DMA API
Pull i2c fixes from Wolfram Sang:
"This is probably not the kind of pull request you want to see that
late in the cycle. Yet, the ACPI refactorization was problematic
again and caused another two issues which need fixing. My holidays
with limited internet (plus travelling) and the developer's illness
didn't help either :(
The details:
- ACPI code was refactored out into a seperate file and as a
side-effect, the i2c-core module got renamed. Jean Delvare
rightfully complained about the rename being problematic for
distributions. So, Mika and I thought the least problematic way to
deal with it is to move all the code back into the main i2c core
source file. This is mainly a huge code move with some #ifdeffery
applied. No functional code changes. Our personal tests and the
testbots did not find problems. (I was thinking about reverting,
too, yet that would also have ~800 lines changed)
- The new ACPI code also had a NULL pointer exception, thanks to
Peter for finding and fixing it.
- Mikko fixed a locking problem by decoupling clock_prepare and
clock_enable.
- Addy learnt that the datasheet was wrong and reimplemented the
frequency setup according to the new algorithm.
- Fan fixed an off-by-one error when copying data
- Janusz fixed a copy'n'paste bug which gave a wrong error message
- Sergei made sure that "don't touch" bits are not accessed"
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: acpi: Fix NULL Pointer dereference
i2c: move acpi code back into the core
i2c: rk3x: fix divisor calculation for SCL frequency
i2c: mxs: fix error message in pio transfer
i2c: ismt: use correct length when copy buffer
i2c: rcar: fix RCAR_IRQ_ACK_{RECV|SEND}
i2c: tegra: Move clk_prepare/clk_set_rate to probe
