drm/omap: Fix crash when using LCD3 overlay manager

The channel_names list didn't have a string populated for LCD3 manager, this
results in a crash when the display's output is connected to LCD3. Add an entry
for LCD3.

Reported-by: Somnath Mukherjee <somnath@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
drm/omap: Use old_fb to synchronize between successive page flips

omap_crtc->old_fb is used to check whether the previous page flip has completed
or not. However, it's never initialized to anything, so it's always NULL. This
results in the check to always succeed, and the page_flip to proceed.

Initialize old_fb to the fb that we intend to flip to through page_flip, and
therefore prevent a future page flip to proceed if the last one didn't
complete.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
drm/omap: protect omap_crtc's event with event_lock spinlock

The vblank_cb callback and the page_flip ioctl can occur together in different
CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when
sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb.

Use the same spinlock in page_flip, to make sure the above omap_crtc parameters
are configured sequentially.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
iommu/arm-smmu: Return 0 on unmap failure

The IOMMU core expects the unmap operation to return the number of bytes
that have been unmapped or 0 on failure, a negative return value being
treated like a number of bytes.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
iommu/arm-smmu: fix panic in arm_smmu_alloc_init_pte

kernel panic happened when iommu_unmap a buffer larger than 2MB,
more than expected pmd entries got “invalidated”, due to a wrong range
passed to arm_smmu_alloc_init_pte. it was likely a typo, now we fix
it, passing the correct "end" address to arm_smmu_alloc_init_pte.

Signed-off-by: Bin Wang <binw@marvell.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
perf tools: Fix double free in perf test 21 (code-reading.c)

perf_evlist__delete() deletes attached cpu and thread maps
but the test is still using them, so remove them from the
evlist before deleting it.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Link: http://lkml.kernel.org/r/53465E3E.8070201@intel.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
perf tools: Instead of redirecting flex output, use -o

This gives us a real filename instead of having '<stdout>' show up all
over the place when debugging.

Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/1396652539-2416-1-git-send-email-cody@linux.vnet.ibm.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
ASoC: tlv320aic3x: fix shared reset pin for DT

Currently the second tlv320aic3x instance fails to
be probed from DT if the reset pin is shared with
the first one.

This patch fixes it by moving the list add of the
reset pin into the i2c_probe method.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
pata_samsung_cf: fix ata_host_activate() failure handling

Add missing clk_disable() call to ata_host_activate() failure path.

Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
ASoC: alc5623: Fix regmap endianness

Commit 0cd257bf9b9b0cbb4fa1a5c988a232506997867c, "ASoC: alc5623:
Convert to direct regmap API usage" broke probing of the codec,
because of wrong endinness of the ID and codec version read from the
device. Fix this by removing the existing flipping of the endiannes,
and extracting the codec type byte from the word from the regmap.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Mark Brown <broonie@linaro.org>
drm/omap: fix the handling of fb ref counts

With the recent primary-plane changes for drm, the primary plane's
framebuffer needs to be ref counted the same way as for
non-primary-planes. This was not done by the omapdrm driver, which
caused the ref count to drop to 0 too early, causing problems.

This patch moves the fb unref and ref from omap_plane_update to
omap_plane_mode_set. This way the fb refs are updated for both primary
and non-primary cases, as omap_plane_update calls omap_plane_mode_set.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
x86/xen: Fix 32-bit PV guests's usage of kernel_stack

Commit 198d208df4371734ac4728f69cb585c284d20a15 ("x86: Keep
thread_info on thread stack in x86_32") made 32-bit kernels use
kernel_stack to point to thread_info. That change missed a couple of
updates needed by Xen's 32-bit PV guests:

1. kernel_stack needs to be initialized for secondary CPUs

2. GET_THREAD_INFO() now uses %fs register which may not be the
   kernel's version when executing xen_iret().

With respect to the second issue, we don't need GET_THREAD_INFO()
anymore: we used it as an intermediate step to get to per_cpu xen_vcpu
and avoid referencing %fs. Now that we are going to use %fs anyway we
may as well go directly to xen_vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
dm verity: fix biovecs hash calculation regression

Commit 003b5c5719f159f4f4bf97511c4702a0638313dd ("block: Convert drivers
to immutable biovecs") incorrectly converted biovec iteration in
dm-verity to always calculate the hash from a full biovec, but the
function only needs to calculate the hash from part of the biovec (up to
the calculated "todo" value).

Fix this issue by limiting hash input to only the requested data size.

This problem was identified using the cryptsetup regression test for
veritysetup (verity-compat-test).

Signed-off-by: Milan Broz <gmazyland@gmail.com>
Acked-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # 3.14+
irqchip: vic: Properly chain the cascaded IRQs

We are flagging the parent IRQ as chained, then we must also
make sure to call the chained_irq_[enter|exit] functions for
things to work smoothly.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: http://lkml.kernel.org/r/1397550484-7119-1-git-send-email-linus.walleij@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
xen: fix memory leak in __xen_pcibk_add_pci_dev()

It need to free dev_entry when it failed to assign to a new
slot on the virtual PCI bus.

smatch says:
 drivers/xen/xen-pciback/vpci.c:142 __xen_pcibk_add_pci_dev() warn:
possible memory leak of 'dev_entry'

Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
xen-pciback: silence an unwanted debug printk

There is a missing curly brace here so we might print some extra debug
information.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
xen/spinlock: Don't enable them unconditionally.

The git commit a945928ea2709bc0e8e8165d33aed855a0110279
('xen: Do not enable spinlocks before jump_label_init() has executed')
was added to deal with the jump machinery. Earlier the code
that turned on the jump label was only called by Xen specific
functions. But now that it had been moved to the initcall machinery
it gets called on Xen, KVM, and baremetal - ouch!. And the detection
machinery to only call it on Xen wasn't remembered in the heat
of merge window excitement.

This means that the slowpath is enabled on baremetal while it should
not be.

Reported-by: Waiman Long <waiman.long@hp.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
CC: stable@vger.kernel.org
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart.

The 'read_reply' works with 'process_msg' to read of a reply in XenBus.
'process_msg' is running from within the 'xenbus' thread. Whenever
a message shows up in XenBus it is put on a xs_state.reply_list list
and 'read_reply' picks it up.

The problem is if the backend domain or the xenstored process is killed.
In which case 'xenbus' is still awaiting - and 'read_reply' if called -
stuck forever waiting for the reply_list to have some contents.

This is normally not a problem - as the backend domain can come back
or the xenstored process can be restarted. However if the domain
is in process of being powered off/restarted/halted - there is no
point of waiting on it coming back - as we are effectively being
terminated and should not impede the progress.

This patch solves this problem by checking whether the guest is the
right domain. If it is an initial domain and hurtling towards death -
there is no point of continuing the wait. All other type of guests
continue with their behavior (as Xenstore is expected to still be
running in another domain).

Fixes-Bug: http://bugs.xenproject.org/xen/bug/8
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
xen/manage: Poweroff forcefully if user-space is not yet up.

The user can launch the guest in this sequence:

xl create -p /vm.cfg	[launch, but pause it]
xl shutdown latest	[sets control/shutdown=poweroff]
xl unpause latest
xl console latest	[and see that the guest has completely
ignored the shutdown request]

In reality the guest hasn't ignored it. It registers a watch
and gets a notification that there is value. It then calls
the shutdown_handler which ends up calling orderly_shutdown.

Unfortunately that is so early in the bootup that there
are no user-space. Which means that the orderly_shutdown fails.
But since the force flag was set to false it continues on without
reporting.

What we really want to is to use the force when we are in the
SYSTEM_BOOTING state and not use the 'force' when SYSTEM_RUNNING.

However, if we are in the running state - and the shutdown command
has been given before the user-space has been setup, there is nothing
we can do. Worst yet, we stop ignoring the 'xl shutdown' requests!

As such, the other part of this patch is to only stop ignoring
the 'xl shutdown' when we are truly in the power off sequence.

That means the user can do multiple 'xl shutdown' and we will try
to act on them instead of ignoring them.

Fixes-Bug: http://bugs.xenproject.org/xen/bug/6
Reported-by:  Alex Bligh <alex@alex.org.uk>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
ipv4: add a sock pointer to ip_queue_xmit()

ip_queue_xmit() assumes the skb it has to transmit is attached to an
inet socket. Commit 31c70d5956fc ("l2tp: keep original skb ownership")
changed l2tp to not change skb ownership and thus broke this assumption.

One fix is to add a new 'struct sock *sk' parameter to ip_queue_xmit(),
so that we do not assume skb->sk points to the socket used by l2tp
tunnel.

Fixes: 31c70d5956fc ("l2tp: keep original skb ownership")
Reported-by: Zhan Jianyu <nasa4836@gmail.com>
Tested-by: Zhan Jianyu <nasa4836@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>