drm/exynos: Check for NULL dereference of crtc

The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the
use of the enabled flag, which means that the code may attempt to call
win_enable on a NULL crtc. This results in the following oops on
Arndale:

[    1.673479] Unable to handle kernel NULL pointer dereference at virtual address 00000368
[    1.681500] pgd = c0004000
[    1.684154] [00000368] *pgd=00000000
[    1.687713] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[    1.693012] Modules linked in:
[    1.696045] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
3.19.0-07545-g57485fa #1907
[    1.703524] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
(....)
[    2.014803] [<c02f9cfc>] (exynos_plane_destroy) from [<c02e61b4>] (drm_mode_config_cleanup+0x168/0x20c)
[    2.024178] [<c02e61b4>] (drm_mode_config_cleanup) from [<c02f66fc>] (exynos_drm_load+0xac/0x12c)

This patch adds in a check to ensure exynos_crtc is not NULL before it
is dereferenced.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: IS_ERR() vs NULL bug

of_iomap() doesn't return error pointers, it returns NULL on error.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: remove unused files

These files are not used anymore.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

spi: trigger trace event for message-done before mesg->complete

With spidev the mesg->complete callback points to spidev_complete.
Calling this unblocks spidev_sync and so spidev_sync_write finishes. As
the struct spi_message just read is a local variable in
spidev_sync_write and recording the trace event accesses this message
the recording is better done first. The same can happen for
spidev_sync_read.

This fixes an oops observed on a 3.14-rt system with spidev activity
after

echo 1 > /sys/kernel/debug/tracing/events/spi/enable

.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

ARM: 8313/1: Use read_cpuid_ext() macro instead of inline asm

Replace inline asm statement in __get_cpu_architecture() with equivalent
macro invocation, i.e. read_cpuid_ext(CPUID_EXT_MMFR0);

As an added bonus, this squashes a potential bug, described by Paul
Walmsley in commit 067e710b9a98 ("ARM: 7801/1: prevent gcc 4.5 from
reordering extended CP15 reads above is_smp() test").

Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 8311/1: Don't use is_module_addr in setting page attributes

The set_memory_* functions currently only support module
addresses. The addresses are validated using is_module_addr.
That function is special though and relies on internal state
in the module subsystem to work properly. At the time of
module initialization and calling set_memory_*, it's too early
for is_module_addr to work properly so it always returns
false. Rather than be subject to the whims of the module state,
just bounds check against the module virtual address range.

Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 8310/1: l2c: Fix prefetch settings dt parsing

Allow prefetch settings overriding by device tree, in case
l2x0_cache_size_of_parse() returns value, prefetch tuning
properties are silently ignored. E.g. arm,double-linefill* and
arm,prefetch*.
This happens for example, when "cache-size" or "cache-sets"
properties haven't been filled in l2c dt node.

Comments from Fabrice Gasnier:

 Allow device tree to override the L2C prefetch settings, even when
 l2x0_cache_size_of_parse() fails to parse the cache geometry due to (eg)
 missing "cache-size" or "cache-sets" properties.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

pinctrl: sun4i: GPIOs configured as irq must be set to input before reading

On sun4i-a10, when GPIOs are configured as external interrupt the value for
them in the data register does not seem to get updated, so set their mux to
input (and restore afterwards) when reading the pin.

Missed edges seem to be buffered, so this does not introduce a race
condition.

I've also tested this on sun5i-a13 and sun7i-a20 and those do not seem to
be affected, the input value representation in the data register does seem
to correctly get updated to the actual pin value while in irq mode there.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

ovl: upper fs should not be R/O

After importing multi-lower layer support, users could mount a r/o
partition as the left most lowerdir instead of using it as upperdir.
And a r/o upperdir may cause an error like

overlayfs: failed to create directory ./workdir/work

during mount.

This patch check the *s_flags* of upper fs and return an error if
it is a r/o partition. The checking of *upper_mnt->mnt_sb->s_flags*
can be removed now.

This patch also remove

/* FIXME: workdir is not needed for a R/O mount */

from ovl_fill_super() because:

1) for upper fs r/o case
Setting a r/o partition as upper is prevented, no need to care about
workdir in this case.

2) for "mount overlay -o ro" with a r/w upper fs case
Users could remount overlayfs to r/w in this case, so workdir should
not be omitted.

Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

ovl: check lowerdir amount for non-upper mount

Recently multi-lower layer mount support allow upperdir and workdir
to be omitted, then cause overlayfs can be mount with only one
lowerdir directory. This action make no sense and have potential risk.

This patch check the total number of lower directories to prevent
mounting overlayfs with only one directory.

Also, an error message is added to indicate lower directories exceed
OVL_MAX_STACK limit.

Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

ovl: print error message for invalid mount options

Overlayfs should print an error message if an incorrect mount option
is caught like other filesystems.

After this patch, improper option input could be clearly known.

Reported-by: Fabian Sturm <fabian.sturm@aduu.de>
Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

drm/i915: Make sure the primary plane is enabled before reading out the fb state

We don't want to end up in a state where we track that the pipe has its
primary plane enabled when primary plane registers are programmed with
values that look possible but the plane actually disabled.

Refuse to read out the fb state when the primary plane isn't enabled.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Reference: http://mid.gmane.org/20150203191507.GA2374@crion86
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome

Revisiting commit d23b8ad8ab23 ("tc: add BPF based action") with regards
to eBPF support, I was thinking that it might be better to improve
return semantics from a BPF program invoked through BPF_PROG_RUN().

Currently, in case filter_res is 0, we overwrite the default action
opcode with TC_ACT_SHOT. A default action opcode configured through tc's
m_bpf can be: TC_ACT_RECLASSIFY, TC_ACT_PIPE, TC_ACT_SHOT, TC_ACT_UNSPEC,
TC_ACT_OK.

In cls_bpf, we have the possibility to overwrite the default class
associated with the classifier in case filter_res is _not_ 0xffffffff
(-1).

That allows us to fold multiple [e]BPF programs into a single one, where
they would otherwise need to be defined as a separate classifier with
its own classid, needlessly redoing parsing work, etc.

Similarly, we could do better in act_bpf: Since above TC_ACT* opcodes
are exported to UAPI anyway, we reuse them for return-code-to-tc-opcode
mapping, where we would allow above possibilities. Thus, like in cls_bpf,
a filter_res of 0xffffffff (-1) means that the configured _default_ action
is used. Any unkown return code from the BPF program would fail in
tcf_bpf() with TC_ACT_UNSPEC.

Should we one day want to make use of TC_ACT_STOLEN or TC_ACT_QUEUED,
which both have the same semantics, we have the option to either use
that as a default action (filter_res of 0xffffffff) or non-default BPF
return code.

All that will allow us to transparently use tcf_bpf() for both BPF
flavours.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>

KVM: nVMX: mask unrestricted_guest if disabled on L0

If EPT was enabled, unrestricted_guest was allowed in L1 regardless of
L0.  L1 triple faulted when running L2 guest that required emulation.

Another side effect was 'WARN_ON_ONCE(vmx->nested.nested_run_pending)'
in L0's dmesg:
  WARNING: CPU: 0 PID: 0 at arch/x86/kvm/vmx.c:9190 nested_vmx_vmexit+0x96e/0xb00 [kvm_intel] ()

Prevent this scenario by masking SECONDARY_EXEC_UNRESTRICTED_GUEST when
the host doesn't have it enabled.

Fixes: 78051e3b7e35 ("KVM: nVMX: Disable unrestricted mode if ept=0")
Cc: stable@vger.kernel.org
Tested-By: Kashyap Chamarthy <kchamart@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>

pinctrl: at91: move lock/unlock_as_irq calls into request/release

The gpiochip_lock_as_irq call can fail and return an error,
while the irq_startup is not expected to fail (returns an
unsigned int which is not checked by irq core code).

irq_request/release_resources functions have been created
to address this problem.

Move gpiochip_lock/unlock_as_irq calls into
irq_request/release_resources functions to prevent using a
gpio as an irq if the gpiochip_lock_as_irq call failed.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

rtc: at91rm9200: double locking bug in at91_rtc_interrupt()

There is a typo here so we deadlock.

Fixes: dd1f1f391dd7 ('rtc: at91rm9200: rework wakeup and interrupt handling')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: David Dueck <davidcdueck@googlemail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Btrfs: fix outstanding_extents accounting in DIO

We are keeping track of how many extents we need to reserve properly based on
the amount we want to write, but we were still incrementing outstanding_extents
if we wrote less than what we requested.  This isn't quite right since we will
be limited to our max extent size.  So instead lets do something horrible!  Keep
track of how many outstanding_extents we reserved, and decrement each time we
allocate an extent.  If we use our entire reserve make sure to jack up
outstanding_extents on the inode so the accounting works out properly.  Thanks,

Reported-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>

Btrfs: add sanity test for outstanding_extents accounting

I introduced a regression wrt outstanding_extents accounting.  These are tricky
areas that aren't easily covered by xfstests as we could change MAX_EXTENT_SIZE
at any time.  So add sanity tests to cover the various conditions that are
tricky in order to make sure we don't introduce regressions in the future.
Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:
 "Misc fixes from all around the place:

   - a KASLR related revert where we ran out of time to get a fix - this
     represents a substantial portion of the diffstat,

   - two FPU fixes,

   - two x86 platform fixes: an ACPI reduced-hw fix and a NumaChip fix,

   - an entry code fix,

   - and a VDSO build fix"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  Revert "x86/mm/ASLR: Propagate base load address calculation"
  x86/fpu: Drop_fpu() should not assume that tsk equals current
  x86/fpu: Avoid math_state_restore() without used_math() in __restore_xstate_sig()
  x86/apic/numachip: Fix sibling map with NumaChip
  x86/platform, acpi: Bypass legacy PIC and PIT in ACPI hardware reduced mode
  x86/asm/entry/32: Fix user_mode() misuses
  x86/vdso: Fix the build on GCC5

Btrfs: just free dummy extent buffers

If we fail during our sanity tests we could get NULL deref's because we unload
the module before the dummy extent buffers are free'd via RCU.  So check for
this case and just free the things directly.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>

Btrfs: account merges/splits properly

My fix

Btrfs: fix merge delalloc logic

only fixed half of the problems, it didn't fix the case where we have two large
extents on either side and then join them together with a new small extent.  We
need to instead keep track of how many extents we have accounted for with each
side of the new extent, and then see how many extents we need for the new large
extent.  If they match then we know we need to keep our reservation, otherwise
we need to drop our reservation.  This shows up with a case like this

[BTRFS_MAX_EXTENT_SIZE+4K][4K HOLE][BTRFS_MAX_EXTENT_SIZE+4K]

Previously the logic would have said that the number extents required for the
new size (3) is larger than the number of extents required for the largest side
(2) therefore we need to keep our reservation.  But this isn't the case, since
both sides require a reservation of 2 which leads to 4 for the whole range
currently reserved, but we only need 3, so we need to drop one of the
reservations.  The same problem existed for splits, we'd think we only need 3
extents when creating the hole but in reality we need 4.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>

Merge branches 'perf-urgent-for-linus' and 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull perf and timer fixes from Ingo Molnar:
 "Two small perf fixes:
   - kernel side context leak fix
   - tooling crash fix

  And two clocksource driver fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf: Fix context leak in put_event()
  perf annotate: Fix fallback to unparsed disassembler line

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clockevents: sun5i: Fix setup_irq init sequence
  clocksource: efm32: Fix a NULL pointer dereference

HID: wacom: check for wacom->shared before following the pointer

486b908 (HID: wacom: do not send pen events before touch is up/forced out)
introduces a kernel oops when plugging a tablet without touch.

wacom->shared is null for these devices so this leads to a null pointer
exception.

Change the condition to make it clear that what we need is wacom->shared
not NULL.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

The commit breaks the legacy platforms, ie. these not using device-tree,
and setting up the interrupt resources with a flag to activate edge
detection. The issue was found on the zylonite platform.

The reason is that zylonite uses platform resources to pass the interrupt number
and the irq flags (here IORESOURCE_IRQ_HIGHEDGE). It expects the driver to
request the irq with these flags, which in turn setups the irq as high edge
triggered.

After the patch, this was supposed to be taken care of with :
  irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq));

But irq_resflags is 0 for legacy platforms, while for example in
arch/arm/mach-pxa/zylonite.c, in struct resource smc91x_resources[] the
irq flag is specified. This breaks zylonite because the interrupt is not
setup as triggered, and hardware doesn't provide interrupts.

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>

inet: Clean up inet_csk_wait_for_connect() vs. might_sleep()

I got the following trace with current net-next kernel :

[14723.885290] WARNING: CPU: 26 PID: 22658 at kernel/sched/core.c:7285 __might_sleep+0x89/0xa0()
[14723.885325] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff810e8734>] prepare_to_wait_exclusive+0x34/0xa0
[14723.885355] CPU: 26 PID: 22658 Comm: netserver Not tainted 4.0.0-dbg-DEV #1379
[14723.885359]  ffffffff81a223a8 ffff881fae9e7ca8 ffffffff81650b5d 0000000000000001
[14723.885364]  ffff881fae9e7cf8 ffff881fae9e7ce8 ffffffff810a72e7 0000000000000000
[14723.885367]  ffffffff81a57620 000000000000093a 0000000000000000 ffff881fae9e7e64
[14723.885371] Call Trace:
[14723.885377]  [<ffffffff81650b5d>] dump_stack+0x4c/0x65
[14723.885382]  [<ffffffff810a72e7>] warn_slowpath_common+0x97/0xe0
[14723.885386]  [<ffffffff810a73e6>] warn_slowpath_fmt+0x46/0x50
[14723.885390]  [<ffffffff810f4c5d>] ? trace_hardirqs_on_caller+0x10d/0x1d0
[14723.885393]  [<ffffffff810e8734>] ? prepare_to_wait_exclusive+0x34/0xa0
[14723.885396]  [<ffffffff810e8734>] ? prepare_to_wait_exclusive+0x34/0xa0
[14723.885399]  [<ffffffff810ccdc9>] __might_sleep+0x89/0xa0
[14723.885403]  [<ffffffff81581846>] lock_sock_nested+0x36/0xb0
[14723.885406]  [<ffffffff815829a3>] ? release_sock+0x173/0x1c0
[14723.885411]  [<ffffffff815ea1f7>] inet_csk_accept+0x157/0x2a0
[14723.885415]  [<ffffffff810e8900>] ? abort_exclusive_wait+0xc0/0xc0
[14723.885419]  [<ffffffff8161b96d>] inet_accept+0x2d/0x150
[14723.885424]  [<ffffffff8157db6f>] SYSC_accept4+0xff/0x210
[14723.885428]  [<ffffffff8165a451>] ? retint_swapgs+0xe/0x44
[14723.885431]  [<ffffffff810f4c5d>] ? trace_hardirqs_on_caller+0x10d/0x1d0
[14723.885437]  [<ffffffff81369c0e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[14723.885441]  [<ffffffff8157ef40>] SyS_accept+0x10/0x20
[14723.885444]  [<ffffffff81659872>] system_call_fastpath+0x12/0x17
[14723.885447] ---[ end trace ff74cd83355b1873 ]---

In commit 26cabd31259ba43f68026ce3f62b78094124333f
Peter added a sched_annotate_sleep() in sk_wait_event()

Is the following patch needed as well ?

Alternative would be to use sk_wait_event() from inet_csk_wait_for_connect()

Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

ip6_tunnel: fix error code when tunnel exists

After commit 2b0bb01b6edb, the kernel returns -ENOBUFS when user tries to add
an existing tunnel with ioctl API:
$ ip -6 tunnel add ip6tnl1 mode ip6ip6 dev eth1
add tunnel "ip6tnl0" failed: No buffer space available

It's confusing, the right error is EEXIST.

This patch also change a bit the code returned:
 - ENOBUFS -> ENOMEM
 - ENOENT -> ENODEV

Fixes: 2b0bb01b6edb ("ip6_tunnel: Return an error when adding an existing tunnel.")
CC: Steffen Klassert <steffen.klassert@secunet.com>
Reported-by: Pierre Cheynier <me@pierre-cheynier.net>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netdevice.h: fix ndo_bridge_* comments

The argument 'flags' was missing in ndo_bridge_setlink().
ndo_bridge_dellink() was missing.

Fixes: 407af3299ef1 ("bridge: Add netlink interface to configure vlans on bridge ports")
Fixes: add511b38266 ("bridge: add flags argument to ndo_bridge_setlink and ndo_bridge_dellink")
CC: Vlad Yasevich <vyasevic@redhat.com>
CC: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'regulator-fix-v4.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

Pull regulator fixes from Mark Brown:
 "The two main fixes here from Javier and Doug both fix issues seen on
  the Exynos-based ARM Chromebooks with reference counting of GPIO
  regulators over system suspend.  The GPIO enable code didn't properly
  take account of this case (a full analysis is in Doug's commit log).

  This is fixed by both fixing the reference counting directly and by
  making the resume code skip enables it doesn't need to do.  We could
  skip the change in the resume code but it's a very simple change and
  adds extra robustness against problems in other drivers"

* tag 'regulator-fix-v4.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: tps65910: Add missing #include <linux/of.h>
  regulator: core: Fix enable GPIO reference counting
  regulator: Only enable disabled regulators on resume

ARM: OMAP: dmtimer: disable pm runtime on remove

Disable the pm_runtime of the device upon remove. This is
added to balance the pm_runtime_enable() invoked in the probe.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure

The current OMAP dmtimer probe does not check for the return
status of pm_runtime_get_sync() before initializing the timer
registers. Any timer with missing hwmod data would return a
failure here, and the access of registers without enabling the
clocks for the timer would trigger a l3_noc interrupt and a
kernel boot hang. Add proper checking so that the probe would
return a failure graciously without hanging the kernel boot.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge tag 'regmap-v4.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

Pull regmap fixes from Mark Brown:
 "A few things here:

   - a change from Lars to fix insertion of cache values at the start of
     rather than end of a rbtree block.  This hadn't been noticed before
     since almost everything lists registers in ascending order.

   - a fix from Takashi for spurious warnings during cache sync with
     read once registers, a problem which can be very noticeable on
     devices that it affects.

   - a fix from Valentin for a tighening of the oneshot IRQ request
     interface which would have broken affected devices"

* tag 'regmap-v4.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: regcache-rbtree: Fix present bitmap resize
  regmap: Skip read-only registers in regcache_sync()
  regmap-irq: set IRQF_ONESHOT flag to ensure IRQ request

Merge tag 'virtio-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux

Pull virtio fixes from Rusty Russell:
 "Not entirely surprising: the ongoing QEMU work on virtio 1.0 has
  revealed more minor issues with our virtio 1.0 drivers just introduced
  in the kernel.

  (I would normally use my fixes branch for this, but there were a batch
  of them...)"

* tag 'virtio-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  virtio_mmio: fix access width for mmio
  uapi/virtio_scsi: allow overriding CDB/SENSE size
  virtio_mmio: generation support
  virtio_rpmsg: set DRIVER_OK before using device
  9p/trans_virtio: fix hot-unplug
  virtio-balloon: do not call blocking ops when !TASK_RUNNING
  virtio_blk: fix comment for virtio 1.0
  virtio_blk: typo fix
  virtio_balloon: set DRIVER_OK before using device
  virtio_console: avoid config access from irq
  virtio_console: init work unconditionally

Merge git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull kvm fixes from Marcelo Tosatti:
 "KVM bug fixes (ARM and x86)"

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  arm/arm64: KVM: Keep elrsr/aisr in sync with software model
  KVM: VMX: Set msr bitmap correctly if vcpu is in guest mode
  arm/arm64: KVM: fix missing unlock on error in kvm_vgic_create()
  kvm: x86: i8259: return initialized data on invalid-size read
  arm64: KVM: Fix outdated comment about VTCR_EL2.PS
  arm64: KVM: Do not use pgd_index to index stage-2 pgd
  arm64: KVM: Fix stage-2 PGD allocation to have per-page refcounting
  kvm: move advertising of KVM_CAP_IRQFD to common code

pagemap: do not leak physical addresses to non-privileged userspace

As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.

This disallows anybody without CAP_SYS_ADMIN to read the pagemap.

[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

[ Eventually we might want to do anything more finegrained, but for now
  this is the simple model.   - Linus ]

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mark Seaborn <mseaborn@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

fs: add dirtytime_expire_seconds sysctl

Add a tuning knob so we can adjust the dirtytime expiration timeout,
which is very useful for testing lazytime.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>

fs: make sure the timestamps for lazytime inodes eventually get written

Jan Kara pointed out that if there is an inode which is constantly
getting dirtied with I_DIRTY_PAGES, an inode with an updated timestamp
will never be written since inode->dirtied_when is constantly getting
updated.  We fix this by adding an extra field to the inode,
dirtied_time_when, so inodes with a stale dirtytime can get detected
and handled.

In addition, if we have a dirtytime inode caused by an atime update,
and there is no write activity on the file system, we need to have a
secondary system to make sure these inodes get written out.  We do
this by setting up a second delayed work structure which wakes up the
CPU much more rarely compared to writeback_expire_centisecs.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>

Merge tag 'asoc-fix-v4.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v4.0

As well as the usual collection of driver specific fixes there's a few
more generic things:

 - Lots of fixes from Takashi for drivers using the wrong field in the
   control union to communicate with userspace, leading to potential
   errors on 64 bit systems.
 - A fix from Lars for locking of the lists of devices we maintain,
   mostly only likely to trigger during device probe and removal.

Btrfs: prepare block group cache before writing

Writing the block group cache will modify the extent tree quite a bit because it
truncates the old space cache and pre-allocates new stuff.  To try and cut down
on the churn lets do the setup dance first, then later on hopefully we can avoid
looping with newly dirtied roots.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>

netfilter: nf_tables: allow to change chain policy without hook if it exists

If there's an existing base chain, we have to allow to change the
default policy without indicating the hook information.

However, if the chain doesn't exists, we have to enforce the presence of
the hook attribute.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

regulator: palmas: Correct TPS659038 register definition for REGEN2

The register offset for REGEN2_CTRL in different for TPS659038 chip as when
compared with other Palmas family PMICs. In the case of TPS659038 the wrong
offset pointed to PLLEN_CTRL and was causing a hang. Correcting the same.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

livepatch: Fix subtle race with coming and going modules

There is a notifier that handles live patches for coming and going modules.
It takes klp_mutex lock to avoid races with coming and going patches but
it does not keep the lock all the time. Therefore the following races are
possible:

  1. The notifier is called sometime in STATE_MODULE_COMING. The module
     is visible by find_module() in this state all the time. It means that
     new patch can be registered and enabled even before the notifier is
     called. It might create wrong order of stacked patches, see below
     for an example.

   2. New patch could still see the module in the GOING state even after
      the notifier has been called. It will try to initialize the related
      object structures but the module could disappear at any time. There
      will stay mess in the structures. It might even cause an invalid
      memory access.

This patch solves the problem by adding a boolean variable into struct module.
The value is true after the coming and before the going handler is called.
New patches need to be applied when the value is true and they need to ignore
the module when the value is false.

Note that we need to know state of all modules on the system. The races are
related to new patches. Therefore we do not know what modules will get
patched.

Also note that we could not simply ignore going modules. The code from the
module could be called even in the GOING state until mod->exit() finishes.
If we start supporting patches with semantic changes between function
calls, we need to apply new patches to any still usable code.
See below for an example.

Finally note that the patch solves only the situation when a new patch is
registered. There are no such problems when the patch is being removed.
It does not matter who disable the patch first, whether the normal
disable_patch() or the module notifier. There is nothing to do
once the patch is disabled.

Alternative solutions:
======================

+ reject new patches when a patched module is coming or going; this is ugly

+ wait with adding new patch until the module leaves the COMING and GOING
  states; this might be dangerous and complicated; we would need to release
  kgr_lock in the middle of the patch registration to avoid a deadlock
  with the coming and going handlers; also we might need a waitqueue for
  each module which seems to be even bigger overhead than the boolean

+ stop modules from entering COMING and GOING states; wait until modules
  leave these states when they are already there; looks complicated; we would
  need to ignore the module that asked to stop the others to avoid a deadlock;
  also it is unclear what to do when two modules asked to stop others and
  both are in COMING state (situation when two new patches are applied)

+ always register/enable new patches and fix up the potential mess (registered
  patches order) in klp_module_init(); this is nasty and prone to regressions
  in the future development

+ add another MODULE_STATE where the kallsyms are visible but the module is not
  used yet; this looks too complex; the module states are checked on "many"
  locations

Example of patch stacking breakage:
===================================

The notifier could _not_ _simply_ ignore already initialized module objects.
For example, let's have three patches (P1, P2, P3) for functions a() and b()
where a() is from vmcore and b() is from a module M. Something like:

a() b()
P1 a1() b1()
P2 a2() b2()
P3 a3() b3(3)

If you load the module M after all patches are registered and enabled.
The ftrace ops for function a() and b() has listed the functions in this
order:

ops_a->func_stack -> list(a3,a2,a1)
ops_b->func_stack -> list(b3,b2,b1)

, so the pointer to b3() is the first and will be used.

Then you might have the following scenario. Let's start with state when patches
P1 and P2 are registered and enabled but the module M is not loaded. Then ftrace
ops for b() does not exist. Then we get into the following race:

CPU0 CPU1

load_module(M)

  complete_formation()

  mod->state = MODULE_STATE_COMING;
  mutex_unlock(&module_mutex);

klp_register_patch(P3);
klp_enable_patch(P3);

# STATE 1

  klp_module_notify(M)
    klp_module_notify_coming(P1);
    klp_module_notify_coming(P2);
    klp_module_notify_coming(P3);

# STATE 2

The ftrace ops for a() and b() then looks:

  STATE1:

ops_a->func_stack -> list(a3,a2,a1);
ops_b->func_stack -> list(b3);

  STATE2:
ops_a->func_stack -> list(a3,a2,a1);
ops_b->func_stack -> list(b2,b1,b3);

therefore, b2() is used for the module but a3() is used for vmcore
because they were the last added.

Example of the race with going modules:
=======================================

CPU0 CPU1

delete_module()  #SYSCALL

   try_stop_module()
     mod->state = MODULE_STATE_GOING;

   mutex_unlock(&module_mutex);

klp_register_patch()
klp_enable_patch()

#save place to switch universe

b()     # from module that is going
  a()   # from core (patched)

   mod->exit();

Note that the function b() can be called until we call mod->exit().

If we do not apply patch against b() because it is in MODULE_STATE_GOING,
it will call patched a() with modified semantic and things might get wrong.

[jpoimboe@redhat.com: use one boolean instead of two]
Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

virtio_mmio: fix access width for mmio

Going over the virtio mmio code, I noticed that it doesn't correctly
access modern device config values using "natural" accessors: it uses
readb to get/set them byte by byte, while the virtio 1.0 spec explicitly states:

4.2.2.2 Driver Requirements: MMIO Device Register Layout

...

The driver MUST only use 32 bit wide and aligned reads and writes to
access the control registers described in table 4.1.
For the device-specific configuration space, the driver MUST use
8 bit wide accesses for 8 bit wide fields, 16 bit wide and aligned
accesses for 16 bit wide fields and 32 bit wide and aligned accesses for
32 and 64 bit wide fields.

Borrow code from virtio_pci_modern to do this correctly.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Merge branch 'linux-4.0' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

nouveau fixes, and gm206 modesetting enables.

* 'linux-4.0' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau/bios: fix i2c table parsing for dcb 4.1
  drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204)
  drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian switch
  drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addresses
  drm/nouveau/fifo/nv04: remove the loop from the interrupt handler

drm/nouveau/bios: fix i2c table parsing for dcb 4.1

Code before looked only at bit 31 to decide if a port is unused.
However dcb 4.1 spec says 0x1F in bits 31-27 and 26-22 means unused.

This fixed hdmi monitor detection on GM206.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204)

Enough to get VGA monitor on DVI-I output have output.
HDMI output not yet working

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian switch

fdo#88868

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addresses

fdo#83992

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/nv04: remove the loop from the interrupt handler

Complete bong hit (and not the last...), the hardware will reassert the
interrupt to PMC if it's necessary.

Also potentially harmful in the face of interrupts such as the non-stall
interrupt, which remain active in NV_PFIFO_INTR even when we don't care
about servicing it.

It appears (hopefully, fdo#87244), that under certain loads, the methods
may pass quickly enough to hit the "100 spins and kill PFIFO" thing that
we had going on.  Not ideal ;)

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Merge tag 'kvm-arm-fixes-4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm

Fixes for KVM/ARM for 4.0-rc5.

Fixes page refcounting issues in our Stage-2 page table management code,
fixes a missing unlock in a gicv3 error path, and fixes a race that can
cause lost interrupts if signals are pending just prior to entering the
guest.

ARM: OMAP2+: Fix socbus family info for AM33xx devices

The family information in the soc-bus data is currently
not classified properly for AM33xx devices, and a read
of /sys/bus/soc/devices/soc0/family currently shows
"Unknown". Fix the same.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: dts: omap3: Add missing dmas for crypto

This patch adds missing dma DTS definitions for omap aes and sham drivers.
Without it kernel drivers do not work for device tree based booting
while it works for legacy booting on general purpose SoCs.

Note that further changes are still needed for high secure SoCs. But since
that never worked in legacy boot mode either, those will be sent separately.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>

drm/radeon: Changing number of compute pipe lines

The current CP firmware can handle Usermode Queues only on MEC1.
To reflect this firmware change, this commit reduces number of compute pipelines
to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd).

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Cc: stable@vger.kernel.org

drm/amdkfd: Fix SDMA queue init. in non-HWS mode

This patch fixes the SDMA queue initialization, when running in non-HWS mode.

The first fix is to move the initialization of SDMA VM parameters before the
initialization of the SDMA MQD.

The second fix is to load the MQD to an HQD after the initialization of the MQD.

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdkfd: destroy mqd when destroying kernel queue

This patch adds a missing destruction of mqd, when destroying a kernel queue.
Without the destruction, there is a memory leakage when repeatedly creating and
destroying kernel queues.

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

bnx2x: fix encapsulation features on 57710/57711

E1x chips (57710, 57711(E)) have no support for encapsulation
offload. bnx2x incorrectly advertises the support as available.

Setting of those features is conditional on "!CHIP_IS_E1x(bp)", but
the bp struct is not initialized yet at this point and consequently
any chip passes the check.
The check must use the "chip_is_e1x" local variable instead to work
correctly.

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

LZ4 : fix the data abort issue

If the part of the compression data are corrupted, or the compression
data is totally fake, the memory access over the limit is possible.

This is the log from my system usning lz4 decompression.
   [6502]data abort, halting
   [6503]r0  0x00000000 r1  0x00000000 r2  0xdcea0ffc r3  0xdcea0ffc
   [6509]r4  0xb9ab0bfd r5  0xdcea0ffc r6  0xdcea0ff8 r7  0xdce80000
   [6515]r8  0x00000000 r9  0x00000000 r10 0x00000000 r11 0xb9a98000
   [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc  0x820149bc
   [6528]spsr 0x400001f3
and the memory addresses of some variables at the moment are
    ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000

As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory
over @oend.

Signed-off-by: JeHyeon Yeon <tom.yeon@windriver.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kernfs: handle poll correctly on 'direct_read' files.

Kernfs supports two styles of read: direct_read and seqfile_read.

The latter supports 'poll' correctly thanks to the update of
'->event' in kernfs_seq_show.
The former does not as '->event' is never updated on a read.

So add an appropriate update in kernfs_file_direct_read().

This was noticed because some 'md' sysfs attributes were
recently changed to use direct reads.

Reported-by: Prakash Punnoor <prakash@punnoor.de>
Reported-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Fixes: 750f199ee8b578062341e6ddfe36c59ac8ff2dcb
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'mac80211-for-davem-2015-03-16' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211

Johannes Berg says:

====================
Here are a few fixes that I'd like to still get in:
 * disable U-APSD for better interoperability, from Michal Kazior
 * drop unencrypted frames in mesh forwarding, from Bob Copeland
 * treat non-QoS/WMM HT stations as non-HT, to fix confusion when
   they connect and then get QoS packets anyway due to HT
 * fix counting interfaces for combination checks, otherwise the
   interface combinations aren't properly enforced (from Andrei)
 * fix pure ECSA by reacting to the IE change
 * ignore erroneous (E)CSA to the current channel which sometimes
   happens due to AP/GO bugs
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec

Steffen Klassert says:

====================
pull request (net): ipsec 2015-03-16

1) Fix the network header offset in _decode_session6
   when multiple IPv6 extension headers are present.
   From Hajime Tazaki.

2) Fix an interfamily tunnel crash. We set outer mode
   protocol too early and may dispatch to the wrong
   address family. Move the setting of the outer mode
   protocol behind the last accessing of the inner mode
   to fix the crash.

3) Most callers of xfrm_lookup() expect that dst_orig
   is released on error. But xfrm_lookup_route() may
   need dst_orig to handle certain error cases. So
   introduce a flag that tells what should be done in
   case of error. From Huaibin Wang.

Please pull or let me know if there are problems.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

dmaengine: dw: append MODULE_ALIAS for platform driver

The commit 9cade1a46c77 (dma: dw: split driver to library part and platform
code) introduced a separate platform driver but missed to add a
MODULE_ALIAS("platform:dw_dmac"); to that module.

The patch adds this to get driver loaded automatically if platform device is
registered.

Reported-by: "Blin, Jerome" <jerome.blin@intel.com>
Fixes: 9cade1a46c77 (dma: dw: split driver to library part and platform code)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>

Revert "Input: synaptics - use dmax in input_mt_assign_slots"

This reverts commit 6ab17a8484f03c188a93713369912f1545eb26e9 since it,
according to Benjamin, causes issues with slot assignment:

E: 15.669119 0000 0000 0000     # ------------ SYN_REPORT (0) ----------
E: 15.954242 0003 002f 0000     # EV_ABS / ABS_MT_SLOT          0
E: 15.954242 0003 0039 0505     # EV_ABS / ABS_MT_TRACKING_ID   505
E: 15.954242 0003 0035 3851     # EV_ABS / ABS_MT_POSITION_X    3851
E: 15.954242 0003 0036 4076     # EV_ABS / ABS_MT_POSITION_Y    4076
E: 15.954242 0003 003a 0034     # EV_ABS / ABS_MT_PRESSURE      34
E: 15.954242 0001 014a 0001     # EV_KEY / BTN_TOUCH            1
E: 15.954242 0003 0000 3851     # EV_ABS / ABS_X                3851
E: 15.954242 0003 0001 4076     # EV_ABS / ABS_Y                4076
E: 15.954242 0003 0018 0034     # EV_ABS / ABS_PRESSURE         34
E: 15.954242 0001 0145 0001     # EV_KEY / BTN_TOOL_FINGER      1
E: 15.954242 0000 0000 0000     # ------------ SYN_REPORT (0) ----------
... (bunch of regular events)...
E: 16.020614 0000 0000 0000     # ------------ SYN_REPORT (0) ----------
E: 16.043601 0003 0035 3873     # EV_ABS / ABS_MT_POSITION_X    3873
E: 16.043601 0003 0036 3903     # EV_ABS / ABS_MT_POSITION_Y    3903
E: 16.043601 0003 003a 0050     # EV_ABS / ABS_MT_PRESSURE      50
E: 16.043601 0003 0035 3032     # EV_ABS / ABS_MT_POSITION_X    3032
E: 16.043601 0003 0036 3832     # EV_ABS / ABS_MT_POSITION_Y    3832
E: 16.043601 0003 003a 0044     # EV_ABS / ABS_MT_PRESSURE      44
E: 16.043601 0003 0000 3032     # EV_ABS / ABS_X                3032
E: 16.043601 0003 0001 3832     # EV_ABS / ABS_Y                3832
E: 16.043601 0003 0018 0044     # EV_ABS / ABS_PRESSURE         44
E: 16.043601 0001 0145 0000     # EV_KEY / BTN_TOOL_FINGER      0
E: 16.043601 0001 014d 0001     # EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 16.043601 0000 0000 0000     # ------------ SYN_REPORT (0) ----------
E: 16.068837 0003 002f 0001     # EV_ABS / ABS_MT_SLOT          1
E: 16.068837 0003 0039 0506     # EV_ABS / ABS_MT_TRACKING_ID   506
E: 16.068837 0003 0035 3912     # EV_ABS / ABS_MT_POSITION_X    3912
E: 16.068837 0003 0036 3743     # EV_ABS / ABS_MT_POSITION_Y    3743
E: 16.068837 0003 003a 0056     # EV_ABS / ABS_MT_PRESSURE      56
E: 16.068837 0003 002f 0000     # EV_ABS / ABS_MT_SLOT          0
E: 16.068837 0003 0035 3026     # EV_ABS / ABS_MT_POSITION_X    3026
E: 16.068837 0003 0036 3708     # EV_ABS / ABS_MT_POSITION_Y    3708
E: 16.068837 0003 003a 0052     # EV_ABS / ABS_MT_PRESSURE      52
E: 16.068837 0003 0000 3026     # EV_ABS / ABS_X                3026
E: 16.068837 0003 0001 3708     # EV_ABS / ABS_Y                3708
E: 16.068837 0003 0018 0052     # EV_ABS / ABS_PRESSURE         52
E: 16.068837 0000 0000 0000     # ------------ SYN_REPORT (0) ----------

Slot 0 and 1 gets inverted in the second report above, which
introduces a cursor jump. The problem is that this cursor jump is
often enough to leave the current widget, and X sends the
scrolling events to whoever is now under the cursor.

Reported-by: Benjamin Tissoires <btissoir@redhat.com>
Reported-by: Hans de Goede <hdegoede@redhat.com>

Merge branch 'synaptics' into for-linus

Bring in changes needed to properly handle Lenovo 2015 lineup.

Merge tag 'v4.0-rockchip-armfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes

Pull "ARM: rockchip: small fixes for 4.0-rc" from Heiko Stuebner:

Adding a default-disabled state to the new gmac node and an
update to the MAINTAINERS entry adding a rockchip regexp entry.

* tag 'v4.0-rockchip-armfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
  ARM: dts: rockchip: disable gmac by default in rk3288.dtsi
  MAINTAINERS: add rockchip regexp to the ARM/Rockchip entry

ALSA: hda - Treat stereo-to-mono mix properly

The commit [ef403edb7558: ALSA: hda - Don't access stereo amps for
mono channel widgets] fixed the handling of mono widgets in general,
but it still misses an exceptional case: namely, a mono mixer widget
taking a single stereo input.  In this case, it has stereo volumes
although it's a mono widget, and thus we have to take care of both
left and right input channels, as stated in HD-audio spec ("7.1.3
Widget Interconnection Rules").

This patch covers this missing piece by adding proper checks of stereo
amps in both the generic parser and the proc output codes.

Reported-by: Raymond Yau <superquad.vortex2@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge remote-tracking branches 'asoc/fix/sgtl5000' and 'asoc/fix/sn95031' into asoc-linus

Merge remote-tracking branches 'asoc/fix/ak4671', 'asoc/fix/control', 'asoc/fix/da732x', 'asoc/fix/fsl-ssi', 'asoc/fix/lock' and 'asoc/fix/rt286' into asoc-linus

Merge remote-tracking branch 'asoc/fix/intel' into asoc-linus

Merge remote-tracking branches 'regulator/fix/gpio-enable' and 'regulator/fix/tps65910' into regulator-linus

regulator: tps65910: Add missing #include <linux/of.h>

drivers/regulator/tps65910-regulator.c: In function ‘tps65910_parse_dt_reg_data’:
drivers/regulator/tps65910-regulator.c:1018: error: implicit declaration of function ‘of_get_child_by_name’
drivers/regulator/tps65910-regulator.c:1018: warning: assignment makes pointer from integer without a cast
drivers/regulator/tps65910-regulator.c:1034: error: implicit declaration of function ‘of_node_put’
drivers/regulator/tps65910-regulator.c:1056: error: implicit declaration of function ‘of_property_read_u32’

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

dmaengine: imx-sdma: switch to dynamic context mode after script loaded

Below comments got from Page4724 of Reference Manual of i.mx6q:
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf

--"Static context mode should be used for the first channel called
after reset to ensure that the all context RAM for that channel is
initialized during the context SAVE phase when the channel is
done or yields. Subsequent calls to the same channel or
different channels may use any of the dynamic context modes.
This will ensure that all context locations for the bootload
channel are initialized, and prevent undefined values in context
RAM from being loaded during the context restore if the
channel is re-started later"

Unfortunately, the rule was broken by commit(5b28aa319bba96987316425a1131813d87cbab35)
.This patch just take them back.

Signed-off-by: Robin Gong <b38343@freescale.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>

Revert "x86/mm/ASLR: Propagate base load address calculation"

This reverts commit:

  f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")

The main reason for the revert is that the new boot flag does not work
at all currently, and in order to make this work, we need non-trivial
changes to the x86 boot code which we didn't manage to get done in
time for merging.

And even if we did, they would've been too risky so instead of
rushing things and break booting 4.1 on boxes left and right, we
will be very strict and conservative and will take our time with
this to fix and test it properly.

Reported-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: H. Peter Anvin <hpa@linux.intel.com
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Junjie Mao <eternal.n08@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/20150316100628.GD22995@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>

drm/i915: Ensure plane->state->fb stays in sync with plane->fb

plane->state->fb and plane->fb should always reference the same FB so
that atomic and legacy codepaths have the same view of display state.
However, there are some places in kernel code that directly set
plane->fb and neglect to update plane->state->fb. If we never do a
successful update through the atomic pipeline, the RmFB cleanup code
will look at the plane->state->fb pointer, which has never actually
been set to a legitimate value, and try to clean it up, leading to
BUG's.

Add a quick helper function to synchronize plane->state->fb with
plane->fb and call it everywhere the driver tries to manually set
plane->fb outside of the atomic pipeline. In this function, use
drm_atomic_set_fb_for_plane instead of writing plane->state->fb
directly to keep the reference count right.

This is modified from Matt Roper's patch to drm-intel-nightly with
commit id

commit afd65eb4cc0578a9c07d621acdb8a570e2782bf7
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Tue Feb 3 13:10:04 2015 -0800

    drm/i915: Ensure plane->state->fb stays in sync with plane->fb

However this bug exists in mainline kernel too, so I created this to fix
it in mainline kernel.

A minor change is to use drm_atomic_set_fb_for_plane instead of update
reference count manually.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93711
Signed-off-by: Xi Ruoyao <xry111@outlook.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
[Jani: included the patch notes in the commit message]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

mac80211: ignore CSA to same channel

If the AP is confused and starts doing a CSA to the same channel,
just ignore that request instead of trying to act it out since it
was likely sent in error anyway.

In the case of the bug I was investigating the GO was misbehaving
and sending out a beacon with CSA IEs still included after having
actually done the channel switch.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

nl80211: ignore HT/VHT capabilities without QoS/WMM

As HT/VHT depend heavily on QoS/WMM, it's not a good idea to
let userspace add clients that have HT/VHT but not QoS/WMM.
Since it does so in certain cases we've observed (client is
using HT IEs but not QoS/WMM) just ignore the HT/VHT info at
this point and don't pass it down to the drivers which might
unconditionally use it.

Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: ask for ECSA IE to be considered for beacon parse CRC

When a beacon from the AP contains only the ECSA IE, and not a CSA IE
as well, this ECSA IE is not considered for calculating the CRC and
the beacon might be dropped as not being interesting. This is clearly
wrong, it should be handled and the channel switch should be executed.

Fix this by including the ECSA IE ID in the bitmap of interesting IEs.

Reported-by: Gil Tribush <gil.tribush@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: count interfaces correctly for combination checks

Since moving the interface combination checks to mac80211, it's
broken because it now only considers interfaces with an assigned
channel context, so for example any interface that isn't active
can still be up, which is clearly an issue; also, in particular
P2P-Device wdevs are an issue since they never have a chanctx.

Fix this by counting running interfaces instead the ones with a
channel context assigned.

Cc: stable@vger.kernel.org [3.16+]
Fixes: 73de86a38962b ("cfg80211/mac80211: move interface counting for combination check to mac80211")
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
[rewrite commit message, dig out the commit it fixes]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

nios2: mm: do not invoke OOM killer on kernel fault OOM

Follow commit 871341023c771ad.

Kernel faults are expected to handle OOM conditions gracefully (gup,
uaccess etc.), so they should never invoke the OOM killer.  Reserve
this for faults triggered in user context when it is the only option.

Signed-off-by: Ley Foon Tan <lftan@altera.com>

ath9k: disable TPC support again (for now)

TPC support has been observed to cause some tx power fluctuations on
some devices with at least AR934x and AR938x chips.
Disable it for now until the bugs have been found and fixed

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath9k: fix tracking of enabled AP beacons

sc->nbcnvifs tracks assigned beacon slots, not enabled beacons.
Therefore, it cannot be used to decide if cur_conf->enable_beacon (bool)
should be updated, or if beacons have been enabled already.
With the current code (depending on the order of calls), beacons often
do not get enabled in an AP+STA setup.
To fix tracking of enabled beacons, convert cur_conf->enable_beacon to a
bitmask of enabled beacon slots.

Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

isdn: icn: use strlcpy() when parsing setup options

If you pass an invalid string here then you probably deserve the memory
corruption, but it annoys static analysis tools so lets fix it.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

nios2: Remove ucontext.h from exported arch headers

Commit 92d5dd8cd6e2 ("nios2: update pt_regs") removed the nios2 specific
ucontext.h, replacing it with the version from asm-generic. Thus it's no
longer necessary to include ucontext.h in exported headers.

Cc: Chung-Ling Tang <cltang@codesourcery.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Ley Foon Tan <lftan@altera.com>

rxrpc: bogus MSG_PEEK test in rxrpc_recvmsg()

[I would really like an ACK on that one from dhowells; it appears to be
quite straightforward, but...]

MSG_PEEK isn't passed to ->recvmsg() via msg->msg_flags; as the matter of
fact, neither the kernel users of rxrpc, nor the syscalls ever set that bit
in there.  It gets passed via flags; in fact, another such check in the same
function is done correctly - as flags & MSG_PEEK.

It had been that way (effectively disabled) for 8 years, though, so the patch
needs beating up - that case had never been tested.  If it is correct, it's
-stable fodder.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

caif: fix MSG_OOB test in caif_seqpkt_recvmsg()

It should be checking flags, not msg->msg_flags.  It's ->sendmsg()
instances that need to look for that in ->msg_flags, ->recvmsg() ones
(including the other ->recvmsg() instance in that file, as well as
unix_dgram_recvmsg() this one claims to be imitating) check in flags.
Braino had been introduced in commit dcda13 ("caif: Bugfix - use MSG_TRUNC
in receive") back in 2010, so it goes quite a while back.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

Linux 4.0-rc4

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fix from Dave Airlie:
 "An oops snuck in in an -rc3 patch, this fixes it"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  [PATCH] drm/mm: Fix support 4 GiB and larger ranges

Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux

Pull clock framework fixes from Michael Turquette:
 "The clk fixes for 4.0-rc4 comprise three themes.

  First are the usual driver fixes for new regressions since v3.19.

  Second are fixes to the common clock divider type caused by recent
  changes to how we round clock rates.  This affects many clock drivers
  that use this common code.

  Finally there are fixes for drivers that improperly compared struct
  clk pointers (drivers must not deref these pointers).  While some of
  these drivers have done this for a long time, this did not cause a
  problem until we started generating unique struct clk pointers for
  every consumer.  A new function, clk_is_match was introduced to get
  these drivers working again and they are fixed up to no longer deref
  the pointers themselves"

* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
  ASoC: kirkwood: fix struct clk pointer comparing
  ASoC: fsl_spdif: fix struct clk pointer comparing
  ARM: imx: fix struct clk pointer comparing
  clk: introduce clk_is_match
  clk: don't export static symbol
  clk: divider: fix calculation of initial best divider when rounding to closest
  clk: divider: fix selection of divider when rounding to closest
  clk: divider: fix calculation of maximal parent rate for a given divider
  clk: divider: return real rate instead of divider value
  clk: qcom: fix platform_no_drv_owner.cocci warnings
  clk: qcom: fix platform_no_drv_owner.cocci warnings
  clk: qcom: Add PLL4 vote clock
  clk: qcom: lcc-msm8960: Fix PLL rate detection
  clk: qcom: Fix slimbus n and m val offsets
  clk: ti: Fix FAPLL parent enable bit handling

[PATCH] drm/mm: Fix support 4 GiB and larger ranges

bad argument if(tmp)... in check_free_hole

fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305!

[airlied: excellent, this was my task for today].

Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl>
Reviewed-by: Chris wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC fixes from Arnd Bergmann:
 "This is a rather unpleasantly large set of bug fixes for arm-soc, Most
  of them because of cross-tree dependencies for Exynos where we should
  have figured out the right path to merge things before the merge
  window, and then the maintainer being unable to sort things out in
  time during a business trip.

  The other changes contained here are the usual collection:

  MAINTAINERS file updates
   - Gregory Clement is now a co-maintainer for the legacy Marvell EBU
     platforms
   - A MAINTAINERS entry for the Freescale Vybrid platform that was
     added last year
   - Matt Porter no longer works as a maintainer on Broadcom SoCs

  Build-time issues
   - A compile-time error for at91
   - Several minor DT fixes on at91, imx, exynos, socfpga, and omap
   - The new digicolor platform was not correctly enabled at all

  Configuration issues
   - Two defconfig fix for regressions using USB on versatile express
     and on OMAP3
   - Enabling all 8 CPUs on Allwinner/SUNxi
   - Enabling the new STiH410 platform to be usable

  Bug fixes in platform code
   - A missing barrier for socfpga
   - Fixing LPDDR1 self-refresh mode on at91
   - Fixing RTC interrupt numbers on Exynos3250
   - Fixing a cache-coherency issues in CPU power-down on Exynos5
   - Multiple small OMAP power management fixes"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (69 commits)
  MAINTAINERS: Add myself as co-maintainer to the legacy support of the mvebu SoCs
  ARM: at91: pm_slowclock: fix the compilation error
  ARM: at91/dt: fix USB high-speed clock to select UTMI
  ARM: at91/dt: fix at91 udc compatible strings
  ARM: at91/dt: declare matrix node as a syscon device
  ARM: vexpress: update CONFIG_USB_ISP1760 option
  ARM: digicolor: add the machine directory to Makefile
  ARM: STi: Add STiH410 SoC support
  MAINTAINERS: add Freescale Vybrid SoC
  MAINTAINERS: Remove self as ARM mach-bcm co-maintainer
  ARM: imx6sl-evk: set swbst_reg as vbus's parent reg
  ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg
  ARM: at91/dt: at91sam9261: fix clocks and clock-names in udc definition
  ARM: OMAP2+: Fix wl12xx on dm3730-evm with mainline u-boot
  ARM: OMAP: enable TWL4030_USB in omap2plus_defconfig
  ARM: dts: dra7x-evm: avoid possible contention while muxing on CAN lines
  ARM: dts: dra7x-evm: Don't use dcan1_rx.gpio1_15 in DCAN pinctrl
  ARM: dts: am43xx: fix SLEWCTRL_FAST pinctrl binding
  ARM: dts: am33xx: fix SLEWCTRL_FAST pinctrl binding
  ARM: dts: OMAP5: fix polling intervals for thermal zones
  ...

Merge tag 'irqchip-fixes-4.0' of git://git.infradead.org/users/jcooper/linux

Pull irqchip fixes from Jason Cooper:
 "armada-370-xp:
   - Chained per-cpu interrupts

  gic{,-v3,v3-its}"
   - Various fixes for safer operation"

* tag 'irqchip-fixes-4.0' of git://git.infradead.org/users/jcooper/linux:
  irqchip: gicv3-its: Support safe initialization
  irqchip: gicv3-its: Define macros for GITS_CTLR fields
  irqchip: gicv3-its: Add limitation to page order
  irqchip: gicv3-its: Use 64KB page as default granule
  irqchip: gicv3-its: Zero itt before handling to hardware
  irqchip: gic-v3: Fix out of bounds access to cpu_logical_map
  irqchip: gic: Fix unsafe locking reported by lockdep
  irqchip: gicv3-its: Fix unsafe locking reported by lockdep
  irqchip: gicv3-its: Iterate over PCI aliases to generate ITS configuration
  irqchip: gicv3-its: Allocate enough memory for the full range of DeviceID
  irqchip: gicv3-its: Fix ITS CPU init
  irqchip: armada-370-xp: Fix chained per-cpu interrupts

HID: tivo: enable all buttons on the TiVo Slide Pro remote

The linux kernel has supported the TiVo Slide remote control for some time, but
does not recognize the USB ID of the newer Slide Pro. This patch adds the
missing data structures so the newer remote will be recognized by the driver,
thereby allowing the TiVo, LiveTV, and Thumbs Up/Down buttons to be
mapped with a hwdb file.

Signed-off-by: Forest Wilkinson <web11.forest@tibit.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

MAINTAINERS: add entry for USB OTG FSM

Add MAINTAINER entry for USB OTG Finite State Machine

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: otg: add a_alt_hnp_support response for B device

This patch adds response to a_alt_hnp_support set feature request from legacy
A device, that is, B-device can provide a message to the user indicating that
the user needs to connect the B-device to an alternate port on the A-device.
A device sets this feature indicates to the B-device that it is connected
to an A-device port that is not capable of HNP, but that the A-device does have
an alternate port that is capable of HNP.

[Peter]
Without this patch, the OTG B device can't be enumerated on
non-HNP port at A device, see below log:
[    2.287464] usb 1-1: Dual-Role OTG device on non-HNP port
[    2.293105] usb 1-1: can't set HNP mode: -32
[    2.417422] usb 1-1: new high-speed USB device number 4 using ci_hdrc
[    2.460635] usb 1-1: Dual-Role OTG device on non-HNP port
[    2.466424] usb 1-1: can't set HNP mode: -32
[    2.587464] usb 1-1: new high-speed USB device number 5 using ci_hdrc
[    2.630649] usb 1-1: Dual-Role OTG device on non-HNP port
[    2.636436] usb 1-1: can't set HNP mode: -32
[    2.641003] usb usb1-port1: unable to enumerate USB device

Cc: stable <stable@vger.kernel.org>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Li Jun <b47624@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'for-4.0-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus

Kishon writes:

contains fixes all over drivers/phy and includes the following
*) Using phy_get_drvdata instead of dev_get_drvdata in armada375-usb2.c
*) Fixes w.r.t checking return values in regmap APIs, protecting regmap ops
   with spin lock and directly using regmap_update_bits instead of having a
   separate function to do the same in the various PHYs used in exynos.
*) check return value in platform_get_resource of hix5hd2-sata PHY
*) Removed NULL terminating entry from phys array and fix off-by-one
   valid value checking for args->args[0] in of_xlate of exynos USB PHY.
*) Fixup rockchip_usb_phy_power_on failure path
*) Fix devm_phy_match to find the correct match in phy core and also fix to
   return the correct value from PHY APIs if PM runtime is not enabled.
*) Removed redundant code in twl4030 and xgene
*) Fixed sizeof during memory allocation in miphy PHYs
*) simplify ti_pipe3_dpll_wait_lock implementation, fix missing clk_prepare
   when using old dt name and nit pick in MOUDLE_ALIAS in TI PHYs.

Merge branch 'irqchip/urgent-gic' into irqchip/urgent

bridge: reset bridge mtu after deleting an interface

On adding an interface br_add_if() sets the MTU to the min of
all the interfaces. Do the same thing on removing an interface too
in br_del_if.

Signed-off-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "Misc i915, vmwgfx and radeon fixes along with a fix for one of those
  recursive sleep mutex debug cases in the mst code"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/vmwgfx: Fix an issue with the device losing its irq line on module unload
  drm/vmwgfx: Correctly NULLify dma buffer pointer on failure
  drm/vmwgfx: Reorder device takedown somewhat
  drm/vmwgfx: Fix a couple of lock dependency violations
  drm/radeon: drop setting UPLL to sleep mode
  drm/radeon: fix wait to actually occur after the signaling callback
  drm/i915: Prevent TLB error on first execution on SNB
  drm/i915: Do both mt and gen6 style forcewake reset on ivb probe
  drm/i915: Make WAIT_IOCTL negative timeouts be indefinite again
  drm/i915: use in_interrupt() not in_irq() to check context
  drm/mst: fix recursive sleep warning on qlock
  drm: Don't assign fbs for universal cursor support to files

Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

Pull SCSI fix from James Bottomley:
 "This is a simple fix for a domain revalidation crash which has
  recently turned up in the libsas code (applies to mvsas, isc and
  aic94xx)"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  libsas: Fix Kernel Crash in smp_execute_task

ARM: dts: rockchip: disable gmac by default in rk3288.dtsi

This block should not be enabled by default or else if the kconfig is set,
it will try to load/probe even if there's no phy connected.

Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

Merge tag 'linux-can-fixes-for-4.0-20150314' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can

Marc Kleine-Budde says:

====================
Hello David, this is a pull request for net/master, consisting of two patches:

In the first patch Michal Simek enables the xilinx CAN driver for ARM64. The
second patch by Ahmed S. Darwish fixes a race condition in the tx-queue of the
kvaser_usb driver.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

MAINTAINERS: add rockchip regexp to the ARM/Rockchip entry

The regexp option is a nice way to catch even weirder paths like the current
drivers/gpu/drm/rockchip/* or others in the future.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>