[media] smiapp: Only some selection targets are settable

Setting a non-settable selection target caused BUG() to be called. The check
for valid selections only takes the selection target into account, but does
not tell whether it may be set, or only get. Fix the issue by simply
returning an error to the user.

Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Cc: stable@vger.kernel.org	# for v3.10 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
i2c: omap: fix NACK and Arbitration Lost irq handling

commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
fired again. As a result, ISR keep processing transfer after it was already
complete (from the driver code point of view).

A didn't see real impacts of the 1d7afc9, but it is really bad idea to
have ISR running on user data after transfer was complete.

It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).

According to specs (if I understood correctly), in case of NACK and AL driver
must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
NACK, AL, ARDY, and XDR (Master Transmitter Mode).

All that is done down the code under the if condition:
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...

The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
no interrupts is fired after ISR informs the rest of driver what transfer
complete.

Note: instead of removing break under NACK case, we could just replace 'break'
with 'continue' and allow NACK transfer to finish using ARDY event. I found
that NACK and ARDY bits usually set together. That case confirm TI wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK

In order if someone interested in the event traces for NACK and AL cases,
I sent them to mailing list.

Tested on Beagleboard XM C.

Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
Cc: <stable@vger.kernel.org> # v3.7+
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
i2c: designware: prevent early stop on TX FIFO empty

If the Designware core is configured with IC_EMPTYFIFO_HOLD_MASTER_EN
set to zero, allowing the TX FIFO to become empty causes a STOP
condition to be generated on the I2C bus. If the transmit FIFO
threshold is set too high, an erroneous STOP condition can be
generated on long transfers - particularly where the interrupt
latency is extended.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
[media] solo6x10: fix a race in IRQ handler

The IRQs have to be acknowledged before they are serviced, otherwise some events
may be skipped. Also, acknowledging IRQs just before returning from the handler
doesn't leave enough time for the device to deassert the INTx line, and for
bridges to propagate this change. This resulted in twice the IRQ rate on ARMv6
dual core CPU.

Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>
Acked-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
Tested-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] Update MAINTAINERS for solo6x10

Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] s2255drv: fix payload size for JPG, MJPEG

length is the size of the buffer, not the payload. That's set using
vb2_set_plane_payload().

Signed-off-by: Dean Anderson <linux-dev@sensoray.com>
Cc: <stable@vger.kernel.org>      # for v3.15 and up
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] cx23885: use sg = sg_next(sg) instead of sg++

The cx23885 driver still used sg++ instead of sg = sg_next(sg). This worked with
vb1 since that filled in the sglist manually, page-by-page, but it fails with vb2
which uses core scatterlist code that can combine contiguous scatterlist entries
into one larger entry.

This bug led to the following crash as reported by Mariusz:

[20712.990258] BUG: Bad page state in process vb2-cx23885[0]  pfn:2ca34
[20712.990265] page:ffffea00009c3b60 count:-1 mapcount:0 mapping:          (null) index:0x0
[20712.990266] flags: 0x4000000000000000()
[20712.990268] page dumped because: nonzero _count
[20712.990269] Modules linked in: tun binfmt_misc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_mark xt_REDIRECT xt_limit xt_conntrack xt_nat xt_tcpudp iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables sit ip_tunnel nvidia(PO) stb6100 stv090x cx88_dvb videobuf_dvb cx88_vp3054_i2c tuner kvm_amd kvm cx8802 k10temp cx8800 cx88xx btcx_risc videobuf_dma_sg videobuf_core usb_storage ds2490 usbhid ftdi_sio cx23885 tveeprom cx2341x videobuf2_dvb videobuf2_core videobuf2_dma_sg videobuf2_memops asus_atk0110 snd_emu10k1 snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd w1_therm wire ipv6
[20712.990301] CPU: 2 PID: 26942 Comm: vb2-cx23885[0] Tainted: P    B   W  O   3.18.0-rc5-00001-gb3652d1 #2
[20712.990303] Hardware name: System manufacturer System Product Name/M4A785TD-V EVO, BIOS 2105    07/23/2010
[20712.990305]  ffffffff81765734 ffff880137683a78 ffffffff815b6b32 0000000000000006
[20712.990307]  ffffea00009c3b60 ffff880137683aa8 ffffffff8108ec27 ffffffff81765712
[20712.990309]  ffffffff8189c840 0000000000000246 ffffea00009c3b60 ffff880137683b78
[20712.990312] Call Trace:
[20712.990317]  [<ffffffff815b6b32>] dump_stack+0x46/0x58
[20712.990321]  [<ffffffff8108ec27>] bad_page+0xe9/0x107
[20712.990323]  [<ffffffff810912ca>] get_page_from_freelist+0x3b2/0x505
[20712.990326]  [<ffffffff8109150a>] __alloc_pages_nodemask+0xed/0x65f
[20712.990330]  [<ffffffff81047a52>] ? ttwu_do_activate.constprop.78+0x57/0x5c
[20712.990332]  [<ffffffff81049ff3>] ? try_to_wake_up+0x21b/0x22d
[20712.990336]  [<ffffffff810070f4>] dma_generic_alloc_coherent+0x6e/0xf5
[20712.990339]  [<ffffffff810261a9>] gart_alloc_coherent+0x105/0x114
[20712.990341]  [<ffffffff81025963>] ? flush_gart+0x39/0x3d
[20712.990343]  [<ffffffff810260a4>] ? gart_map_sg+0x3a0/0x3a0
[20712.990349]  [<ffffffffa0141a1e>] cx23885_risc_databuffer+0xa7/0x133 [cx23885]
[20712.990354]  [<ffffffffa0142764>] cx23885_buf_prepare+0x121/0x134 [cx23885]
[20712.990359]  [<ffffffffa0144210>] buffer_prepare+0x14/0x16 [cx23885]
[20712.990363]  [<ffffffffa011f101>] __buf_prepare+0x190/0x279 [videobuf2_core]
[20712.990366]  [<ffffffffa011d906>] ? vb2_queue_or_prepare_buf+0xb8/0xc0 [videobuf2_core]
[20712.990369]  [<ffffffffa011f34b>] vb2_internal_qbuf+0x51/0x1e5 [videobuf2_core]
[20712.990372]  [<ffffffffa0120537>] vb2_thread+0x199/0x1f6 [videobuf2_core]
[20712.990376]  [<ffffffffa012039e>] ? vb2_fop_write+0xdf/0xdf [videobuf2_core]
[20712.990379]  [<ffffffff81043e61>] kthread+0xdf/0xe7
[20712.990381]  [<ffffffff81043d82>] ? kthread_create_on_node+0x16d/0x16d
[20712.990384]  [<ffffffff815bd46c>] ret_from_fork+0x7c/0xb0
[20712.990386]  [<ffffffff81043d82>] ? kthread_create_on_node+0x16d/0x16d

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Mariusz Bialonczyk <manio@skyboo.net>
Tested-by: Mariusz Bialonczyk <manio@skyboo.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
MAINTAINERS: Update mchehab's addresses

I'm using the new Open Source Group address for my upstream work.
While the other email is still valid, it is better for me to receive
patches via the new address.

So, replace it everywhere inside MAINTAINERS.

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] rc-core: fix toggle handling in the rc6 decoder

The toggle bit shouldn't be cleared before the toggle value is calculated.

This should probably go into 3.17.x as well.

Fixes: 120703f9eb32 ([media] rc-core: document the protocol type)

Cc: stable@vger.kernel.org # For v3.17
Tested-by: Stephan Raue <mailinglists@openelec.tv>
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
i2c: omap: fix i207 errata handling

commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR
and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
Set) get handled. 6d9939f6514 code doesn't correspond to workaround provided by
errata.

According to errata ISR must filter out spurious RDR before data read not after.
ISR must read RXSTAT to get number of bytes available to read. Because RDR
could be set while there could no data in the receive FIFO.

Restored pre 6d9939f6514 way of handling errata.

Found by code review. Real impact haven't seen.
Tested on Beagleboard XM C.

Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY
Tested-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
x86: Use $(OBJDUMP) instead of plain objdump

commit e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd'
broke the cross compile of x86. It added a objdump invocation, which
invokes the host native objdump and ignores an active cross tool
chain.

Use $(OBJDUMP) instead which takes the CROSS_COMPILE prefix into
account.

[ tglx: Massage changelog and use $(OBJDUMP) ]

Fixes: e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd'
Signed-off-by: Chris Clayton <chris2553@googlemail.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Junjie Mao <eternal.n08@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/54705C8E.1080400@googlemail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap

memblock_is_region_reserved() returns true in the case of a partial
overlap, meaning that the current code fails to reserve the
non-overlapping portion.

This call was introduced as part of d1552ce449eb "of/fdt: move
memreserve and dtb memory reservations into core" which went into
v3.16.

I observed this causing a Midway system with a buggy fdt (the header
declares itself to be larger than it really is) failing to boot
because the over-inflated size of the fdt was causing it to seem to
run into the swapper_pg_dir region, meaning the DT wasn't reserved.
The symptoms were failing to find an disks or network and failing to
boot.

However given the ambiguity of whether things like the initrd are
covered by /memreserve/ and similar I think it is best to also
register the region rather than just ignoring it.

Since memblock_reserve() handles overlaps just fine lets just warn and
carry on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: stable@vger.kernel.org # v3.16+
ACPI / video: update condition to check if device is in _DOD list

Commit 0b8db271f159 ("ACPI / video: check _DOD list when creating
backlight devices") checks if the video device is in the bind devices
list to decide if we should create backlight device for it, that causes
problem for one Dell Latitude E6410, where none of the video output
devices are properly bound due to the way how we did the comparing
between its _ADR and the _DOD's values. Solve this problem by comparing
the lower 12 bits of both the device's _ADR and the _DOD's values instead
of relying on bind result.

Fixes: 0b8db271f159 ("ACPI / video: check _DOD list when creating backlight devices")
Reported-and-tested-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
x86, microcode: Limit the microcode reloading to 64-bit for now

First, there was this: https://bugzilla.kernel.org/show_bug.cgi?id=88001

The problem there was that microcode patches are not being reapplied
after suspend-to-ram. It was important to reapply them, though, because
of for example Haswell's TSX erratum which disabled TSX instructions
with a microcode patch.

A simple fix was fb86b97300d9 ("x86, microcode: Update BSPs microcode
on resume") but, as it is often the case, simple fixes are too
simple. This one causes 32-bit resume to fail:

https://bugzilla.kernel.org/show_bug.cgi?id=88391

Properly fixing this would require more involved changes for which it
is too late now, right before the merge window. Thus, limit this to
64-bit only temporarily.

Signed-off-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/1417353999-32236-1-git-send-email-bp@alien8.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
PCI: tegra: Use physical range for I/O mapping

Commit 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO
resources") changed how I/O resources are parsed from DT.  Rather than
containing the physical address of the I/O region, the addresses will now
be in I/O address space.

On Tegra the union of all ranges is used to expose a top-level memory-
mapped resource for the PCI host bridge.  This helps to make /proc/iomem
more readable.

Combining both of the above, the union would now include the I/O space
region.  This causes a regression on Tegra20, where the physical base
address of the PCIe controller (and therefore of the union) is located at
physical address 0x80000000.  Since I/O space starts at 0, the union will
now include all of system RAM which starts at 0x00000000.

This commit fixes this by keeping two copies of the I/O range: one that
represents the range in the CPU's physical address space, the other for the
range in the I/O address space.  This allows the translation setup within
the driver to reuse the physical addresses.  The code registering the I/O
region with the PCI core uses both ranges to establish the mapping.

Fixes: 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO resources")
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it

Closes a very unlikely race that can occur if another NonStallInterrupt
method passes between checking fences and acking the previous interrupt.

With this change, the interrupt will re-fire under such conditions.

Tested-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau: prevent stale fence->channel pointers, and protect with rcu

Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/gf116: remove copy1 engine

Indications are that no GF116's actually have a copy engine there, but
actually have the decompression engine. This engine can be made to do
copies, but that should be done separately.

Unclear why this didn't turn up on all GF116's, but perhaps the
non-mobile ones came with enough VRAM to not trigger ttm migrations in
test scenarios.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=85465
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59168
Cc: stable@vger.kernel.org
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Merge branch 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

Just a couple of fixes for the fallout from the fence rework.

* 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau/gf116: remove copy1 engine
  drm/nouveau: prevent stale fence->channel pointers, and protect with rcu
  drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it
nouveau: move the hotplug ignore to correct place.

Introduced in b440bde74f, however it was added to
the wrong function in nouveau.

https://bugzilla.kernel.org/show_bug.cgi?id=86011
Cc: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org  # v3.15+
Signed-off-by: Dave Airlie <airlied@redhat.com>