Merge branch 'for-linus' of git://git./linux/kernel/git/jikos/hid

Pull HID fixes from Jiri Kosina:

 - fixes for potential memory corruption problems in magicmouse and
   picolcd drivers (the HW would have to be manufactured to be
   deliberately evil to trigger those) which were found by Steven
   Vittitoe

 - fix for false error message appearing in dmesg from logitech-dj
   driver, from Benjamin Tissoires

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
  HID: picolcd: sanity check report size in raw_event() callback
  HID: magicmouse: sanity check report size in raw_event() callback
  HID: logitech-dj: prevent false errors to be shown

spi: dw: fix kernel crash due to NULL pointer dereference

The obvious fix after the commit d9c73bb8a3a5 "spi: dw: add support for gpio
controlled chip select". This patch fixes the issue by using locally defined
temporary variable.

Fixes: d9c73bb8a3a5 (spi: dw: add support for gpio controlled chip select)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: <stable@vger.kernel.org>

Merge branch 'for-linus' of git://git./linux/kernel/git/mason/linux-btrfs

Pull btrfs fixes from Chris Mason:
 "The biggest of these comes from Liu Bo, who tracked down a hang we've
  been hitting since moving to kernel workqueues (it's a btrfs bug, not
  in the generic code).  His patch needs backporting to 3.16 and 3.15
  stable, which I'll send once this is in.

  Otherwise these are assorted fixes.  Most were integrated last week
  during KS, but I wanted to give everyone the chance to test the
  result, so I waited for rc2 to come out before sending"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: (24 commits)
  Btrfs: fix task hang under heavy compressed write
  Btrfs: fix filemap_flush call in btrfs_file_release
  Btrfs: fix crash on endio of reading corrupted block
  btrfs: fix leak in qgroup_subtree_accounting() error path
  btrfs: Use right extent length when inserting overlap extent map.
  Btrfs: clone, don't create invalid hole extent map
  Btrfs: don't monopolize a core when evicting inode
  Btrfs: fix hole detection during file fsync
  Btrfs: ensure tmpfile inode is always persisted with link count of 0
  Btrfs: race free update of commit root for ro snapshots
  Btrfs: fix regression of btrfs device replace
  Btrfs: don't consider the missing device when allocating new chunks
  Btrfs: Fix wrong device size when we are resizing the device
  Btrfs: don't write any data into a readonly device when scrub
  Btrfs: Fix the problem that the replace destroys the seed filesystem
  btrfs: Return right extent when fiemap gives unaligned offset and len.
  Btrfs: fix wrong extent mapping for DirectIO
  Btrfs: fix wrong write range for filemap_fdatawrite_range()
  Btrfs: fix wrong missing device counter decrease
  Btrfs: fix unzeroed members in fs_devices when creating a fs from seed fs
  ...

Merge tag 'trace-fixes-v3.17-rc1-2' of git://git./linux/kernel/git/rostedt/linux-trace

Pull trace buffer epoll hang fix from Steven Rostedt:
 "Josef Bacik found a bug in the ring_buffer_poll_wait() where the
  condition variable (waiters_pending) was set before being added to the
  poll queue via poll_wait().  This allowed for a small race window to
  happen where an event could come in, check the condition variable see
  it set to true, clear it, and then wake all the waiters.  But because
  the waiter set the variable before adding itself to the queue, the
  waker could have cleared the variable after it was set and then miss
  waking it up as it wasn't added to the queue yet.

  Discussing this bug, we realized that a memory barrier needed to be
  added too, for the rare case that something polls for a single trace
  event to happen (and just one, no more to come in), and miss the
  wakeup due to memory ordering.  Ideally, a memory barrier needs to be
  added on the writer side too, but as that will kill tracing
  performance and this is for a situation that tracing wasn't even
  designed for (who traces one instance of an event, use a printk
  instead!), this isn't worth adding the barrier.  But we can in the
  future add the barrier for when the buffer goes from empty to the
  first event, as that would cover this case"

* tag 'trace-fixes-v3.17-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  trace: Fix epoll hang when we race with new entries

spi: dw-pci: fix bug when regs left uninitialized

The commit 04f421e7 "spi: dw: use managed resources" changes drivers to use
managed functions, but seems wasn't properly tested in PCI case. The regs field
of struct dw_spi left uninitialized. Thus, kernel crashes when tries to access
to the SPI controller registers. This patch fixes the issue.

Fixes: 04f421e7 (spi: dw: use managed resources)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

ARM: 8130/1: cpuidle/cpuidle-big_little: fix reading cpu id part number

Commit af040ffc9ba1 ("ARM: make it easier to check the CPU part number
correctly") changed ARM_CPU_PART_X masks, and the way they are returned and
checked against. Usage of read_cpuid_part_number() is now deprecated, and
calling places updated accordingly. This actually broke cpuidle-big_little
initialization, as bl_idle_driver_init() performs a check using an hardcoded
mask on cpu_id.

Create an interface to perform the check (that is now even easier to read).
Define also a proper mask (ARM_CPU_PART_MASK) that makes this kind of checks
cleaner and helps preventing bugs in the future. Update usage accordingly.

Signed-off-by: Juri Lelli <juri.lelli@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dummy strex

On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may
falsely trigger a watchpoint exception, leading to potential data aborts
during exception return and/or livelock.

This patch resolves the issue in the following ways:

  - Replacing our uses of CLREX with a dummy STREX sequence instead (as
    we did for v6 CPUs).

  - Removing the clrex code from v7_exit_coherency_flush and derivatives,
    since this only exists as a minor performance improvement when
    non-cached exclusives are in use (Linux doesn't use these).

Benchmarking on a variety of ARM cores revealed no measurable
performance difference with this change applied, so the change is
performed unconditionally and no new Kconfig entry is added.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 8128/1: abort: don't clear the exclusive monitors

The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors
upon entry to the kernel, but this is redundant:

  - We clear the monitors on every exception return since commit
    200b812d0084 ("Clear the exclusive monitor when returning from an
    exception"), so this is not necessary to ensure the monitors are
    cleared before returning from a fault handler.

  - Any dummy STREX will target a temporary scratch area in memory, and
    may succeed or fail without corrupting useful data. Its status value
    will not be used.

  - Any other STREX in the kernel must be preceded by an LDREX, which
    will initialise the monitors consistently and will not depend on the
    earlier state of the monitors.

Therefore we have no reason to care about the initial state of the
exclusive monitors when a data abort is taken, and clearing the monitors
prior to exception return (as we already do) is sufficient.

This patch removes the redundant clearing of the exclusive monitors from
the early abort handlers.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 8127/1: module: add support for R_ARM_TARGET1 relocations

Kernel module build with GCOV profiling fails to load with the
following error:

 $ insmod test_module.ko
   test_module: unknown relocation: 38
   insmod: can't insert 'test_module.ko': invalid module format

This happens because constructor pointers in the .init_array section
have not supported R_ARM_TARGET1 relocation type.

Documentation (ELF for the ARM Architecture) says:
    "The relocation must be processed either in the same way as R_ARM_REL32 or
     as R_ARM_ABS32: a virtual platform must specify which method is used."

Since kernel expects to see absolute addresses in .init_array R_ARM_TARGET1
relocation type should be treated the same way as R_ARM_ABS32.

Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

x86: irq: Fix bug in setting IOAPIC pin attributes

Commit 15a3c7cc9154321fc3 "x86, irq: Introduce two helper functions
to support irqdomain map operation" breaks LPSS ACPI enumerated
devices.

On startup, IOAPIC driver preallocates IRQ descriptors and programs
IOAPIC pins with default level and polarity attributes for all legacy
IRQs. Later legacy IRQ users may fail to set IOAPIC pin attributes
if the requested attributes conflicts with the default IOAPIC pin
attributes. So change mp_irqdomain_map() to allow the first legacy IRQ
user to reprogram IOAPIC pin with different attributes.

Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Link: http://lkml.kernel.org/r/1409118795-17046-1-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

HID: picolcd: sanity check report size in raw_event() callback

The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that raw_data
that we hold in picolcd_pending structure are always kept within proper
bounds.

Cc: stable@vger.kernel.org
Reported-by: Steven Vittitoe <scvitti@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

HID: magicmouse: sanity check report size in raw_event() callback

The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that
magicmouse_emit_touch() gets only valid values of raw_id.

Cc: stable@vger.kernel.org
Reported-by: Steven Vittitoe <scvitti@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

ALSA: hda - Set up initial pins for Acer Aspire V5

Acer Aspire V5 doesn't set up the pins correctly at the cold boot
while the pins are corrected after the warm reboot.  This patch gives
the proper pin configs statically in the driver as a workaround.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81561
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ARM: dts: microsom-ar8035: MDIO pad must be set open drain

This patch is important for the MicroSOM implementation due to the
following details -

1. VIH of the Atheros phy is 1.7V.
2. NVCC_ENET which is the power domain of the MDIO pad is driven by the
   PHY's LDO (i.e. either 1.8v or 2.5v).
3. The MicroSOM implements an onbouard 1.6kohm pull up to 3.3v (R3000).

In the case the PHY's LDO was 1.8v then there would be only a 100mV
margin for the signal to be acknowledged as high (1.8v-1.7v).
Due to that setting the pad as an open drain will let the 1.6kohm pull
that signal high to 3.3 that assures enough margins to the PHY to be
acked as '1' logic.

Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>

tomoyo: Fix pathname calculation breakage.

Commit 7177a9c4b509 ("fs: call rename2 if exists") changed
"struct inode_operations"->rename == NULL if
"struct inode_operations"->rename2 != NULL .

TOMOYO needs to check for both ->rename and ->rename2 , or
a system on (e.g.) ext4 filesystem won't boot.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>

usb: ehci/ohci-exynos: Fix PHY getting sequence

Since we want to keep support for both older usb-phys as well as the
newer generic phys, lets first get the generic PHYs and fallback to
older USB-PHYs only when we fail to get the former.
This should fix the issue with ehci-exynos and ohci-exynos, wherein
in the absence of SAMSUNG_USB2PHY config symbol, we end up getting
the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs
are not configured properly.

Reported-by: Sachin Kamat <sachin.kamat@samsung.com>
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Jingoo Han <jg1.han@samsung.com>
Tested-by: Sachin Kamat <sachin.kamat@samsung.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1

If user specifies that USB autosuspend must be disabled by module
parameter "usbcore.autosuspend=-1" then we must prevent
autosuspend of USB hub devices as well.

commit 596d789a211d introduced in v3.8 changed the original behaivour
and stopped respecting the usbcore.autosuspend parameter for hubs.

Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0"

Cc: [3.8+] <stable@vger.kernel.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Tested-by: Michael Welling <mwelling@emacinc.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

thunderbolt: Clear hops before overwriting

Zero hops in tb_path_activate before writing a new path.

This fixes the following scenario:
 - Boot with a coldplugged device
 - Unplug device
 - Plug device back in
 - PCI hotplug fails

The hotplug operation fails because our new path matches the (now
defunct) path which was setup by the firmware for the coldplugged
device. By writing zeros before writing our path configuration we can
force thunderbolt to retrain the path.

Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'for-linus' of git://git./linux/kernel/git/s390/linux

Pull s390 updates from Martin Schwidefsky:
 - wire up the system calls seccomp, getrandom and memfd_create
 - use static system information as input to add_device_randomness
 - .. and three bug fixes

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/sclp: remove unnecessary XTABS flag
  s390/3215: fix tty output containing tabs
  s390: wire up memfd_create syscall
  s390: add system information as device randomness
  s390/kdump: Clear subchannel ID to signal non-CCW/SCSI IPL
  s390: wire up seccomp and getrandom syscalls

Documentation: this_cpu_ops.txt: Update description of this_cpu_ops

Update the description for per cpu operations to clarify use cases of
this_cpu operations and add considerations for remote access.

Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

scripts/kernel-doc: recognize __meminit

Fix scripts/kernel-doc to recognize __meminit in a function prototype
and to strip it, as done with many other attributes.

Fixes this warning:

  Warning(..//mm/page_alloc.c:2973): cannot understand function prototype: 'void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask) '

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

NFSv3: Fix another acl regression

When creating a new object on the NFS server, we should not be sending
posix setacl requests unless the preceding posix_acl_create returned a
non-trivial acl. Doing so, causes Solaris servers in particular to
return an EINVAL.

Fixes: 013cdf1088d72 (nfs: use generic posix ACL infrastructure,,,)
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1132786
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>

NFSv4: Don't clear the open state when we just did an OPEN_DOWNGRADE

If we did an OPEN_DOWNGRADE, then the right thing to do on success, is
to apply the new open mode to the struct nfs4_state. Instead, we were
unconditionally clearing the state, making it appear to our state
machinery as if we had just performed a CLOSE.

Fixes: 226056c5c312b (NFSv4: Use correct locking when updating nfs4_state...)
Cc: stable@vger.kernel.org # 3.15+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>

NFSv4: Fix problems with close in the presence of a delegation

In the presence of delegations, we can no longer assume that the
state->n_rdwr, state->n_rdonly, state->n_wronly reflect the open
stateid share mode, and so we need to calculate the initial value
for calldata->arg.fmode using the state->flags.

Reported-by: James Drews <drews@engr.wisc.edu>
Fixes: 88069f77e1ac5 (NFSv41: Fix a potential state leakage when...)
Cc: stable@vger.kernel.org # 2.6.33+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>

ARM: dts: omap54xx-clocks: Fix the l3 and l4 clock rates

Similarly to DRA7, OMAP5 has l3 and l4 clock rates incorrectly calculated.
Fixed by using proper divider clock types for the clock nodes.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

USB: sisusb: add device id for Magic Control USB video

I have a j5 create (JUA210) USB 2 video device and adding it device id
to SIS USB video gets it to work.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon: handle broken disabled rb mask gracefully (6xx/7xx) (v2)

This is a port of cedb655a3a7764c3fd946077944383c9e0e68dd4
to older asics.  Fixes a possible divide by 0 if the harvest
register is invalid.

v2: drop some additional harvest munging.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: save/restore the PD addr on suspend/resume

This fixes a problem with GPU resets and TLB flushes on SI/CIK.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

cfq-iosched: Fix wrong children_weight calculation

cfq_group_service_tree_add() is applying new_weight at the beginning of
the function via cfq_update_group_weight().
This actually allows weight to change between adding it to and subtracting
it from children_weight, and triggers WARN_ON_ONCE() in
cfq_group_service_tree_del(), or even causes oops by divide error during
vfr calculation in cfq_group_service_tree_add().

The detailed scenario is as follows:
1. Create blkio cgroups X and Y as a child of X.
   Set X's weight to 500 and perform some I/O to apply new_weight.
   This X's I/O completes before starting Y's I/O.
2. Y starts I/O and cfq_group_service_tree_add() is called with Y.
3. cfq_group_service_tree_add() walks up the tree during children_weight
   calculation and adds parent X's weight (500) to children_weight of root.
   children_weight becomes 500.
4. Set X's weight to 1000.
5. X starts I/O and cfq_group_service_tree_add() is called with X.
6. cfq_group_service_tree_add() applies its new_weight (1000).
7. I/O of Y completes and cfq_group_service_tree_del() is called with Y.
8. I/O of X completes and cfq_group_service_tree_del() is called with X.
9. cfq_group_service_tree_del() subtracts X's weight (1000) from
   children_weight of root. children_weight becomes -500.
   This triggers WARN_ON_ONCE().
10. Set X's weight to 500.
11. X starts I/O and cfq_group_service_tree_add() is called with X.
12. cfq_group_service_tree_add() applies its new_weight (500) and adds it
    to children_weight of root. children_weight becomes 0. Calcularion of
    vfr triggers oops by divide error.

weight should be updated right before adding it to children_weight.

Reported-by: Ruki Sekiya <sekiya.ruki@lab.ntt.co.jp>
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>

drm/msm: Fix missing unlock on error in msm_fbdev_create()

Add the missing unlock before return from function msm_fbdev_create()
in the error handling case.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: fix compile error for non-dt builds

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp4: request vblank during modeset

This avoids a problem seen with weston (for example) where the display
gets stuck in "black screen" if starting weston first thing after boot.
Possibly mdp5 needs something similar.  The downstream android fbdev
driver always requests DMA_E (or DMA_P) when display is active, rather
than only enabling it on-demand as the drm driver does, which I believe
has the same end result.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: avoid flood of kernel logs on faults

87e956e9 changed the fault handler to return -ENOSYS, which causes the
iommu driver to print out a huge splat.  Which wouldn't be quite so bad
if nothing ever faulted.  But seems like some EXA composite operations
generate quite a lot of (seemingly harmless) faults.  That is probably a
userspace problem, but the huge increase in verbosity from iommu fault
dumps makes things kind of unusable.

We probably should actually log *some* message (not conditional on
drm.debug).  But ratelimit it.

Signed-off-by: Rob Clark <robdclark@gmail.com>

block: fix error handling in sg_io

Before commit 2cada584b200 ("block: cleanup error handling in sg_io"),
we had ret = 0 before entering the last big if block of sg_io.

Since 2cada584b200, ret = -EFAULT, which breaks hdparm:

/dev/sda:
 setting Advanced Power Management level to 0xc8 (200)
 HDIO_DRIVE_CMD failed: Bad address
 APM_level      = 128

Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Fixes: 2cada584b200 ("block: cleanup error handling in sg_io")
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>

video: da8xx-fb: preserve display width when changing HSYNC

When looking at this driver for a client, I noticed the code that
configures the HSYNC pulse clobbers the display width in the same
register.  It only preserves the MS part of the width in bit 3 and zeros
the LS part of the width in bits 9 to 4.  This doesn't matter during
initialization as the width is configured afterwards, but subsequent use
of the FBIPUT_HSYNC ioctl would clobber the width.

Preserve bits 9 to 0 of LCD_RASTER_TIMING_0_REG when configuring the
horizontal sync.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm: sti: Add missing dependency on RESET_CONTROLLER

Add missing dependency on RESET_CONTROLLER in order to fix
the following build error.

drivers/gpu/drm/sti/sti_hdmi.c: In function 'sti_hdmi_probe'
drivers/gpu/drm/sti/sti_hdmi.c:780:2: error: implicit declaration of function 'devm_reset_control_get'
[-Werror=implicit-function-declaration]

Benjamin Gaignard remark:
I have change "depends on" to "select" but keep the original author name.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>

drm: sti: Make of_device_id array const

Make of_device_id array const, because all OF functions handle it as const.

Signed-off-by: Kiran Padwal <kiran.padwal@smartplayin.com>

drm: sti: Fix return value check in sti_drm_platform_probe()

In case of error, the function platform_device_register_resndata()
returns ERR_PTR() and never returns NULL. The NULL test in the return
value check should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>

drm: sti: hda: fix return value check in sti_hda_probe()

In case of error, the function devm_ioremap_nocache() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>

drm: sti: hdmi: fix return value check in sti_hdmi_probe()

In case of error, the function devm_ioremap_nocache() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>

drm: sti: tvout: fix return value check in sti_tvout_probe()

In case of error, the function devm_ioremap_nocache() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>

video: of: display_timing: double free on error

The display_timings_release() function frees "disp" and we free it
again on the next line.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drivers: video: fbdev: atmel_lcdfb.c: fix error return code

Convert a zero return value on error to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}

// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

video: ARM CLCD: Fix calculation of bits-per-pixel

If the device-tree specifies a max-memory-bandwidth property then the
CLCD driver uses that to calculate the bits-per-pixel supported,
however, this calculation is faulty for two reasons.

1. It doesn't ensure that the result is a sane value, i.e. a power of 2
   and <= 32 as the rest of the code assumes.

2. It uses the displayed resolution and calculates the average bandwidth
   across the whole frame. It should instead calculate the peak
   bandwidth based on the pixel clock.

This patch fixes both the above.

Signed-off-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

fbdev: Remove __init from chips_hw_init() to fix build failure

Fix build failure caused as follows:

The function chipsfb_pci_init() references
the function __init chips_hw_init().
This is often because chipsfb_pci_init lacks a __init
annotation or the annotation of chips_hw_init is wrong.

make: *** [drivers] Error 2

by removing the __init annotation from chips_hw_init(). The other thing that
could have been done was annotating chipsfb_pci_init(). But that cannot be done
since chipsfb_pci_init() is called from non __init functions.

Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

ARM: brcmstb: revert SMP support

There were several issues (of varying degree of importance) pointed out
with this code late in the review cycle, yet the code was still merged.
Let's rip it out for now and look at resubmitting at a later time.

This reverts most of commit 4fbe66d9903425156c193ae44c81c0f7557755c4.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

trace: Fix epoll hang when we race with new entries

Epoll on trace_pipe can sometimes hang in a weird case.  If the ring buffer is
empty when we set waiters_pending but an event shows up exactly at that moment
we can miss being woken up by the ring buffers irq work.  Since
ring_buffer_empty() is inherently racey we will sometimes think that the buffer
is not empty.  So we don't get woken up and we don't think there are any events
even though there were some ready when we added the watch, which makes us hang.
This patch fixes this by making sure that we are actually on the wait list
before we set waiters_pending, and add a memory barrier to make sure
ring_buffer_empty() is going to be correct.

Link: http://lkml.kernel.org/p/1408989581-23727-1-git-send-email-jbacik@fb.com
Cc: stable@vger.kernel.org # 3.10+
Cc: Martin Lau <kafai@fb.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

ACPI / LPSS: Add ACPI IDs for Intel Braswell

Enable more identifiers for the existing devices for Intel Braswell and
Cherryview.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC

There is platform refusing to respond QR_EC when SCI_EVT isn't set
which is Acer Aspire V5-573G.

By disallowing QR_EC to be issued before the previous one has been
completed we are able to reduce the possibilities to trigger issues on
such platforms.

Note that this fix can only reduce the occurrence rate of this issue, but
this issue may still occur when such a platform doesn't clear SCI_EVT
before or immediately after completing the previous QR_EC transaction.
This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on
the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

But this patch is still useful as it can help to reduce the number of
scheduled QR_EC work items.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set

There is a platform refusing to respond QR_EC when SCI_EVT isn't set
(Acer Aspire V5-573G).

Currently, we rely on the behaviour that the EC firmware can respond
something (for example, 0x00 to indicate "no outstanding events") to
QR_EC even when SCI_EVT is not set, but the reporter has complained
about AC/battery pluging/unpluging and video brightness change delay
on that platform.

This is because the work item that has issued QR_EC has to wait until
timeout in this case, and the _Qxx method evaluation work item queued
after QR_EC one is delayed.

It sounds reasonable to fix this issue by:
 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC
    driver's main state machine.
 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation
    to a seperate IRQ handling thread.

This patch fixes this issue using solution 1.

By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to
handle such platform in the EC driver's main state machine. This patch
enhances the state machine in this way to survive with such malfunctioning
EC firmware.

Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies
on the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed()
Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI: Run fixed event device notifications in process context

Currently, notify callbacks for fixed button events are run from
interrupt context.  That is not necessary and after commit 0bf6368ee8f2
(ACPI / button: Add ACPI Button event via netlink routine) it causes
netlink routines to be called from interrupt context which is not
correct.

Also, that is different from non-fixed device events (including
non-fixed button events) whose notify callbacks are all executed from
process context.

For the above reasons, make fixed button device notify callbacks run
in process context which will avoid the deadlock when using netlink
to report button events to user space.

Fixes: 0bf6368ee8f2 (ACPI / button: Add ACPI Button event via netlink routine)
Link: https://lkml.org/lkml/2014/8/21/606
Reported-by: Benjamin Block <bebl@mageta.org>
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
[rjw: Function names, subject and changelog.]
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI / scan: Allow ACPI drivers to bind to PNP device objects

We generally don't allow ACPI drivers to bind to ACPI device objects
that companion "physical" device objects are created for to avoid
situations in which two different drivers may attempt to handle one
device at the same time.  Recent ACPI device enumeration rework
extended that approach to ACPI PNP devices by starting to use a scan
handler for enumerating them.  However, we previously allowed ACPI
drivers to bind to ACPI device objects with existing PNP device
companions and changing that led to functional regressions on some
systems.

For this reason, add a special check for PNP devices in
acpi_device_probe() so that ACPI drivers can bind to ACPI device
objects having existing PNP device companions as before.

Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971
Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-by: Dirk Griesbach <spamthis@freenet.de>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled

Looks like MUSB cable removal can cause wake-up interrupts to
stop working for device tree based booting at least for UART3
even as nothing is dynamically remuxed. This can be fixed by
calling reconfigure_io_chain() for device tree based booting
in hwmod code. Note that we already do that for legacy booting
if the legacy mux is configured.

My guess is that this is related to UART3 and MUSB ULPI
hsusb0_data0 and hsusb0_data1 support for Carkit mode that
somehow affect the configured IO chain for UART3 and require
rearming the wake-up interrupts.

In general, for device tree based booting, pinctrl-single
calls the rearm hook that in turn calls reconfigure_io_chain
so calling reconfigure_io_chain should not be needed from the
hwmod code for other events.

So let's limit the hwmod rearming of iochain only to
HWMOD_FORCE_MSTANDBY where MUSB is currently the only user
of it. If we see other devices needing similar changes we can
add more checks for it.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: stable@vger.kernel.org # v3.16
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: dts: Enable UART wake-up events for beagleboard

For device tree based booting, we need to use wake-up
interrupts like we already do for some omaps. This fixes
a PM regression on beagleboard compared to legacy booting.

Tested-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: dts: Remove twl6030 clk32g "regulator"

The kernel has never supported clk32g as a regulator since it is a clock
and not a regulator. Fortunately nothing actually references this node so
we can just remove it.

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: omap_device: remove warning that clk alias already exists

When an alias for a clock already exists the warning is printed. For
every module with a main_clk defined, a clk alias for fck is added.
There are some components that have the same main_clk defined, so this
is a really normal situation.

For example the am33xx edma device has 4 components using the same main
clock. So there are three warnings in the boot log for this already
existing clock alias:
platform 49000000.edma: alias fck already exists
platform 49000000.edma: alias fck already exists
platform 49000000.edma: alias fck already exists

As this is only interesting for developers, this patch changes the
message to a debug message.

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: fix %d confusingly prefixed with 0x in format string

Fix %d confusingly prefixed with 0x in format string.

Signed-off-by: Hans Wennborg <hans@hanshq.net>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: dts: DRA7: fix interrupt-cells for GPIO

GPIO modules are also interrupt sources. However, they require both the
GPIO number and IRQ type to function properly.

By declaring that GPIO uses interrupt-cells=<1>, we essentially do not
allow users of the nodes to use the interrupt property appropritely.

With this change, the following now works:

interrupt-parent = <&gpio6>;
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;

Fixes: 6e58b8f1daaf ('ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board')
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc()

commit 65b97cf6b8de introduced in v3.7 caused a regression
by using a reversed CS_MASK thus causing omap_calculate_ecc to
always fail. As the NAND base driver never checks for .calculate()'s
return value, the zeroed ECC values are used as is without showing
any error to the user. However, this won't work and the NAND device
won't be guarded by any error code.

Fix the issue by using the correct mask.

Code was tested on omap3beagle using the following procedure
- flash the primary bootloader (MLO) from the kernel to the first
NAND partition using nandwrite.
- boot the board from NAND. This utilizes OMAP ROM loader that
relies on 1-bit Hamming code ECC.

Fixes: 65b97cf6b8de (mtd: nand: omap2: handle nand on gpmc)

Cc: <stable@vger.kernel.org> [3.7+]
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: dts: omap3430-sdp: Revert to using software ECC for NAND

For v3.14 and prior, 1-bit Hamming code ECC via software was used
for NAND on this board.
Commit c06c52701695 in v3.15 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.14
and prior to be unusable in v3.15 and later. So revert back to
using software ECC scheme.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: GPMC: Support Software ECC scheme via DT

For v3.14 and prior, 1-bit Hamming code ECC via software was the
default choice for some boards e.g. 3430sdp.
Commit ac65caf514ec in v3.15 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.14
and prior to be unusable in v3.15 and later. So don't mark "sw" scheme
as deperecated and support it.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

mtd: nand: omap: Revert to using software ECC by default

For v3.12 and prior, 1-bit Hamming code ECC via software was the
default choice. Commit c66d039197e4 in v3.13 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.12
and prior to be unusable in v3.13 and later. So revert back to
using software ECC by default if an ECC scheme is not explicitely
specified.

This defect can be observed on the following boards during legacy boot

-omap3beagle
-omap3touchbook
-overo
-am3517crane
-devkit8000
-ldp
-3430sdp

Signed-off-by: Roger Quadros <rogerq@ti.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Linux 3.17-rc2

Merge tag 'nfs-for-3.17-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs

Pull NFS client fixes from Trond Myklebust:
 "Highlights:

   - more fixes for read/write codepath regressions
     * sleeping while holding the inode lock
     * stricter enforcement of page contiguity when coalescing requests
     * fix up error handling in the page coalescing code

   - don't busy wait on SIGKILL in the file locking code"

* tag 'nfs-for-3.17-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
  nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait
  nfs: can_coalesce_requests must enforce contiguity
  nfs: disallow duplicate pages in pgio page vectors
  nfs: don't sleep with inode lock in lock_and_join_requests
  nfs: fix error handling in lock_and_join_requests
  nfs: use blocking page_group_lock in add_request
  nfs: fix nonblocking calls to nfs_page_group_lock
  nfs: change nfs_page_group_lock argument

Merge tag 'renesas-sh-drivers-for-v3.17' of git://git./linux/kernel/git/horms/renesas

Pull SH driver fix from Simon Horman:
 "Confine SH_INTC to platforms that need it"

* tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
  sh: intc: Confine SH_INTC to platforms that need it

Merge branch 'upstream' of git://git.linux-mips.org/ralf/upstream-linus

Pull MIPS fixes from Ralf Baechle:
 "Pretty much all across the field so with this we should be in
  reasonable shape for the upcoming -rc2"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: OCTEON: make get_system_type() thread-safe
  MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores
  MIPS: Malta: EVA: Rename 'eva_entry' to 'platform_eva_init'
  MIPS: EVA: Add new EVA header
  MIPS: scall64-o32: Fix indirect syscall detection
  MIPS: syscall: Fix AUDIT value for O32 processes on MIPS64
  MIPS: Loongson: Fix COP2 usage for preemptible kernel
  MIPS: NL: Fix nlm_xlp_defconfig build error
  MIPS: Remove race window in page fault handling
  MIPS: Malta: Improve system memory detection for '{e, }memsize' >= 2G
  MIPS: Alchemy: Fix db1200 PSC clock enablement
  MIPS: BCM47XX: Fix reboot problem on BCM4705/BCM4785
  MIPS: Remove duplicated include from numa.c
  MIPS: Add common plat_irq_dispatch declaration
  MIPS: MSP71xx: remove unused plat_irq_dispatch() argument
  MIPS: GIC: Remove useless parens from GICBIS().
  MIPS: perf: Mark pmu interupt IRQF_NO_THREAD

Merge tag 'trace-fixes-v3.17-rc1' of git://git./linux/kernel/git/rostedt/linux-trace

Pull fix for ftrace function tracer/profiler conflict from Steven Rostedt:
 "The rewrite of the ftrace code that makes it possible to allow for
  separate trampolines had a design flaw with the interaction between
  the function and function_graph tracers.

  The main flaw was the simplification of the use of multiple tracers
  having the same filter (like function and function_graph, that use the
  set_ftrace_filter file to filter their code).  The design assumed that
  the two tracers could never run simultaneously as only one tracer can
  be used at a time.  The problem with this assumption was that the
  function profiler could be implemented on top of the function graph
  tracer, and the function profiler could run at the same time as the
  function tracer.  This caused the assumption to be broken and when
  ftrace detected this failed assumpiton it would spit out a nasty
  warning and shut itself down.

  Instead of using a single ftrace_ops that switches between the
  function and function_graph callbacks, the two tracers can again use
  their own ftrace_ops.  But instead of having a complex hierarchy of
  ftrace_ops, the filter fields are placed in its own structure and the
  ftrace_ops can carefully use the same filter.  This change took a bit
  to be able to allow for this and currently only the global_ops can
  share the same filter, but this new design can easily be modified to
  allow for any ftrace_ops to share its filter with another ftrace_ops.

  The first four patches deal with the change of allowing the ftrace_ops
  to share the filter (and this needs to go to 3.16 as well).

  The fifth patch fixes a bug that was also caused by the new changes
  but only for archs other than x86, and only if those archs implement a
  direct call to the function_graph tracer which they do not do yet but
  will in the future.  It does not need to go to stable, but needs to be
  fixed before the other archs update their code to allow direct calls
  to the function_graph trampoline"

* tag 'trace-fixes-v3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ftrace: Use current addr when converting to nop in __ftrace_replace_code()
  ftrace: Fix function_profiler and function tracer together
  ftrace: Fix up trampoline accounting with looping on hash ops
  ftrace: Update all ftrace_ops for a ftrace_hash_ops update
  ftrace: Allow ftrace_ops to use the hashes from other ops

staging: r8188eu: Add new USB ID

The Elecom WDC-150SU2M uses this chip.

Reported-by: Hiroki Kondo <kompiro@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86: Fix non-PC platform kernel crash on boot due to NULL dereference

Upstream commit:

  95d76acc7518d5 ("x86, irq: Count legacy IRQs by legacy_pic->nr_legacy_irqs instead of NR_IRQS_LEGACY")

removed reserved interrupts for the platforms that do not have a legacy IOAPIC.

Which breaks the boot on Intel MID platforms such as Medfield:

  BUG: unable to handle kernel NULL pointer dereference at 0000003a
  IP: [<c107079a>] setup_irq+0xf/0x4d [    0.000000] *pdpt = 0000000000000000 *pde = 9bbf32453167e510

The culprit is an uncoditional setting of IRQ2 which is used
as cascade IRQ on legacy platforms. It seems we have to check
if we have enough legacy IRQs reserved before we can call
setup_irq().

The fix adds such check in native_init_IRQ() and in setup_default_timer_irq().

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jiang Liu <jiang.liu@linux.intel.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: David Cohen <david.a.cohen@linux.intel.com>
Link: http://lkml.kernel.org/r/1405931920-12871-1-git-send-email-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

staging/rtl8188eu: add 0df6:0076 Sitecom Europe B.V.

The stick is not recognized.
This dongle uses r8188eu but usb-id is missing.
3.16.0

Signed-off-by: Holger Paradies <retabell@gmx.de>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: nfc: fix memory leak in error path

NFC will leak buffer if send failed.
Use single exit point that does the freeing

Cc: stable@vger.kernel.org #3.10+
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: reset client state on queued connect request

If connect request is queued (e.g. device in pg) set client state
to initializing, thus avoid preliminary exit in wait if current
state is disconnected.

This is regression from:

commit e4d8270e604c3202131bac607969605ac397b893
Author: Alexander Usyskin <alexander.usyskin@intel.com>
mei: set connecting state just upon connection request is sent to the fw

CC: stable@vger.kernel.org # 3.15+
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc2: gadget: Set the default EP max packet value as 8 bytes

Set the default EP max packet value as 8 bytes, because in the case
of low-speed, 'ep_mps' is not set. Thus, the default value of 'ep_mps'
should be considered for the case of low-speed.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: ehci: using wIndex + 1 for hub port

The roothub's index per controller is from 0, but the hub port index per hub
is from 1, this patch fixes "can't find device at roohub" problem for connecting
test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical Test.

This patch is for v3.12+.

Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: storage: add quirk for Newer Technology uSCSI SCSI-USB converter

The uSCSI from Newer Technology is a SCSI-USB converter with USB ID 06ca:2003.
Like several other SCSI-USB products, it's a Shuttle Technology OEM device.
Without a suitable entry in unusual-devs.h, the converter can only access the
(single) device with SCSI ID 0. Copying the entry for device 04e6:0002 allows
it to work with devices with other SCSI IDs too.

There are currently six entries for Shuttle-developed SCSI-USB devices in
unusual-devs.h (grep for euscsi):
  04e6:0002  Shuttle eUSCSI Bridge    USB_SC_DEVICE, USB_PR_DEVICE
  04e6:000b  Shuttle eUSCSI Bridge    USB_SC_SCSI, USB_PR_BULK
  04e6:000c  Shuttle eUSCSI Bridge    USB_SC_SCSI, USB_PR_BULK
  050d:0115  Belkin USB SCSI Adaptor  USB_SC_SCSI, USB_PR_BULK
  07af:0004  Microtech USB-SCSI-DB25  USB_SC_DEVICE, USB_PR_DEVICE
  07af:0005  Microtech USB-SCSI-HD50  USB_SC_DEVICE, USB_PR_DEVICE

lsusb -v output for the uSCSI lists
  bInterfaceSubClass      6 SCSI
  bInterfaceProtocol     80 Bulk (Zip)

This patch adds an entry for the uSCSI to unusual_devs.h.

Signed-off-by: Mark Knibbs <markk@clara.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MAINTAINERS: Add an entry for USB/IP driver

This patch adds an entry in MAINTAINERS file for USB/IP
driver.

Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbip: remove struct usb_device_id table

This was used back when usbip-host was an interface device driver;
after the conversion to device driver, the table remained unused.
Remove it in order to stop receiving a warning about it.

Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbip: move usbip kernel code out of staging

At this point, USB/IP kernel code is fully functional
and can be moved out of staging.

Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbip: move usbip userspace code out of staging

At this point, USB/IP userspace code is fully functional
and can be moved out of staging.

Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: hummingboard/cubox-i: change SPDIF output to be more descriptive

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>

ARM: dts: hummingboard/cubox-i: add USB OC pinctrl configuration

Hummingboard has no over current hardware, so disable the over current
detection for both ports.

Cubox-i has over current hardware, so appropriately configure this.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>

HID: logitech-dj: prevent false errors to be shown

Commit "HID: logitech: perform bounds checking on device_id early
enough" unfortunately leaks some errors to dmesg which are not real
ones:
- if the report is not a DJ one, then there is not point in checking
  the device_id
- the receiver (index 0) can also receive some notifications which
  can be safely ignored given the current implementation

Move out the test regarding the report_id and also discards
printing errors when the receiver got notified.

Fixes: ad3e14d7c5268c2e24477c6ef54bbdf88add5d36

Cc: stable@vger.kernel.org
Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

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

Pull x86 fixes from Ingo Molnar:
 "A couple of EFI fixes, plus misc fixes all around the map"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi/arm64: Store Runtime Services revision
  firmware: Do not use WARN_ON(!spin_is_locked())
  x86_32, entry: Clean up sysenter_badsys declaration
  x86/doc: Fix the 'tlb_single_page_flush_ceiling' sysconfig path
  x86/mm: Fix sparse 'tlb_single_page_flush_ceiling' warning and make the variable read-mostly
  x86/mm: Fix RCU splat from new TLB tracepoints

Merge branch 'perf-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull perf fixes from Ingo Molnar:
 "A kprobes and a perf compat ioctl fix"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf: Handle compat ioctl
  kprobes: Skip kretprobe hit in NMI context to avoid deadlock

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

Pull ARM SoC fixes from Olof Johansson:
 "A collection of fixes from this week, it's been pretty quiet and
  nothing really stands out as particularly noteworthy here -- mostly
  minor fixes across the field:

   - ODROID booting was fixed due to PMIC interrupts missing in DT
   - a collection of i.MX fixes
   - minor Tegra fix for regulators
   - Rockchip fix and addition of SoC-specific mailing list to make it
     easier to find posted patches"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  bus: arm-ccn: Fix warning message
  ARM: shmobile: koelsch: Remove non-existent i2c6 pinmux
  ARM: tegra: apalis/colibri t30: fix on-module 5v0 supplies
  MAINTAINERS: add new Rockchip SoC list
  ARM: dts: rockchip: readd missing mmc0 pinctrl settings
  ARM: dts: ODROID i2c improvements
  ARM: dts: Enable PMIC interrupts on ODROID
  ARM: dts: imx6sx: fix the pad setting for uart CTS_B
  ARM: dts: i.MX53: fix apparent bug in VPU clks
  ARM: imx: correct gpu2d_axi and gpu3d_axi clock setting
  ARM: dts: imx6: edmqmx6: change enet reset pin
  ARM: dts: vf610-twr: Fix pinctrl_esdhc1 pin definitions.
  ARM: imx: remove unnecessary ARCH_HAS_OPP select
  ARM: imx: fix TLB missing of IOMUXC base address during suspend
  ARM: imx6: fix SMP compilation again
  ARM: dt: sun6i: Add #address-cells and #size-cells to i2c controller nodes

Merge tag 'gpio-v3.17-2' of git://git./linux/kernel/git/linusw/linux-gpio

Pull gpio fixes from Linus Walleij:

 - a largeish fix for the IRQ handling in the new Zynq driver.  The
   quite verbose commit message gives the exact details.
 - move some defines for gpiod flags outside an ifdef to make stub
   functions work again.
 - various minor fixes that we can accept for -rc1.

* tag 'gpio-v3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio-lynxpoint: enable input sensing in resume
  gpio: move GPIOD flags outside #ifdef
  gpio: delete unneeded test before of_node_put
  gpio: zynq: Fix IRQ handlers
  gpiolib: devres: use correct structure type name in sizeof
  MAINTAINERS: Change maintainer for gpio-bcm-kona.c

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

Pull drm fixes from Dave Airlie:
 "Intel and radeon fixes.

  Post KS/LC git requests from i915 and radeon stacked up.  They are all
  fixes along with some new pci ids for radeon, and one maintainers file
  entry.

   - i915: display fixes and irq fixes
   - radeon: pci ids, and misc gpuvm, dpm and hdp cache"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (29 commits)
  MAINTAINERS: Add entry for Renesas DRM drivers
  drm/radeon: add additional SI pci ids
  drm/radeon: add new bonaire pci ids
  drm/radeon: add new KV pci id
  Revert "drm/radeon: Use write-combined CPU mappings of ring buffers with PCIe"
  drm/radeon: fix active_cu mask on SI and CIK after re-init (v3)
  drm/radeon: fix active cu count for SI and CIK
  drm/radeon: re-enable selective GPUVM flushing
  drm/radeon: Sync ME and PFP after CP semaphore waits v4
  drm/radeon: fix display handling in radeon_gpu_reset
  drm/radeon: fix pm handling in radeon_gpu_reset
  drm/radeon: Only flush HDP cache for indirect buffers from userspace
  drm/radeon: properly document reloc priority mask
  drm/i915: don't try to retrain a DP link on an inactive CRTC
  drm/i915: make sure VDD is turned off during system suspend
  drm/i915: cancel hotplug and dig_port work during suspend and unload
  drm/i915: fix HPD IRQ reenable work cancelation
  drm/i915: take display port power domain in DP HPD handler
  drm/i915: Don't try to enable cursor from setplane when crtc is disabled
  drm/i915: Skip load detect when intel_crtc->new_enable==true
  ...

aio: fix reqs_available handling

As reported by Dan Aloni, commit f8567a3845ac ("aio: fix aio request
leak when events are reaped by userspace") introduces a regression when
user code attempts to perform io_submit() with more events than are
available in the ring buffer.  Reverting that commit would reintroduce a
regression when user space event reaping is used.

Fixing this bug is a bit more involved than the previous attempts to fix
this regression.  Since we do not have a single point at which we can
count events as being reaped by user space and io_getevents(), we have
to track event completion by looking at the number of events left in the
event ring.  So long as there are as many events in the ring buffer as
there have been completion events generate, we cannot call
put_reqs_available().  The code to check for this is now placed in
refill_reqs_available().

A test program from Dan and modified by me for verifying this bug is available
at http://www.kvack.org/~bcrl/20140824-aio_bug.c .

Reported-by: Dan Aloni <dan@kernelim.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Acked-by: Dan Aloni <dan@kernelim.com>
Cc: Kent Overstreet <kmo@daterainc.com>
Cc: Mateusz Guzik <mguzik@redhat.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: stable@vger.kernel.org # v3.16 and anything that f8567a3845ac was backported to
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'fixes-for-v3.17-rc2' of git://git./linux/kernel/git/balbi/usb into work-linus

Felipe writes:

usb: fixes for v3.17-rc2

Here's our first set of fixes for v3.17-rc cycle. Most fixes are
pretty minor changes like the signedness bug in dwc3, or the wrong
string format on MUSB.

The most interesting part is the addition of Intel Quark X1000 support
to PCH UDC.

Signed-of-by: Felipe Balbi <balbi@ti.com>

USB: whiteheat: Added bounds checking for bulk command response

This patch fixes a potential security issue in the whiteheat USB driver
which might allow a local attacker to cause kernel memory corrpution. This
is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On
EHCI and XHCI busses it's possible to craft responses greater than 64
bytes leading a buffer overflow.

Signed-off-by: James Forshaw <forshaw@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bus: arm-ccn: Fix warning message

A message warning a user about wrong vc value was printing
out port instead.

Reported-by: Drew Richardson <drew.richardson@arm.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

ARM: shmobile: koelsch: Remove non-existent i2c6 pinmux

On r8a7791, i2c6 (aka iic3) doesn't need pinmux, but the koelsch dts
refers to non-existent pinmux configuration data:

pinmux core: sh-pfc does not support function i2c6
sh-pfc e6060000.pfc: invalid function i2c6 in map table

Remove it to fix this.

Fixes: commit 1d41f36a68c0f4e9b01d563ce33bab5201858b54 ("ARM: shmobile:
       koelsch dts: Add VDD MPU regulator for DVFS")

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Olof Johansson <olof@lixom.net>

ARM: tegra: apalis/colibri t30: fix on-module 5v0 supplies

Working on Gigabit/PCIe support in U-Boot for Apalis T30 I realised
that the current device tree source includes for our modules only
happen to work due to referencing the on-carrier 5v0 supply from USB
which is not at all available on-module. The modules actually contain
TPS60150 charge pumps to generate the PMIC required 5 volts from the
one and only 3.3 volt module supply. This patch fixes this.

(Note: When back-porting this to v3.16 stable releases, simply drop the
change to tegra30-apalis.dtsi; that file was added in v3.17)

Cc: <stable@vger.kernel.org> #v3.16+
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'v3.17-rockchip-fixes1' of git://git./linux/kernel/git/mmind/linux-rockchip into fixes

Merge "ARM: rockchip: fix for 3.17" from Heiko Stubner:

Pinctrl that got accidentially dropped when reorganizing the
dts files and addition of the new Rockchip list to MAINTAINERS.

* tag 'v3.17-rockchip-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
  MAINTAINERS: add new Rockchip SoC list
  ARM: dts: rockchip: readd missing mmc0 pinctrl settings

Signed-off-by: Olof Johansson <olof@lixom.net>

Btrfs: fix task hang under heavy compressed write

This has been reported and discussed for a long time, and this hang occurs in
both 3.15 and 3.16.

Btrfs now migrates to use kernel workqueue, but it introduces this hang problem.

Btrfs has a kind of work queued as an ordered way, which means that its
ordered_func() must be processed in the way of FIFO, so it usually looks like --

normal_work_helper(arg)
    work = container_of(arg, struct btrfs_work, normal_work);

    work->func() <---- (we name it work X)
    for ordered_work in wq->ordered_list
            ordered_work->ordered_func()
            ordered_work->ordered_free()

The hang is a rare case, first when we find free space, we get an uncached block
group, then we go to read its free space cache inode for free space information,
so it will

file a readahead request
    btrfs_readpages()
         for page that is not in page cache
                __do_readpage()
                     submit_extent_page()
                           btrfs_submit_bio_hook()
                                 btrfs_bio_wq_end_io()
                                 submit_bio()
                                 end_workqueue_bio() <--(ret by the 1st endio)
                                      queue a work(named work Y) for the 2nd
                                      also the real endio()

So the hang occurs when work Y's work_struct and work X's work_struct happens
to share the same address.

A bit more explanation,

A,B,C -- struct btrfs_work
arg   -- struct work_struct

kthread:
worker_thread()
    pick up a work_struct from @worklist
    process_one_work(arg)
worker->current_work = arg;  <-- arg is A->normal_work
worker->current_func(arg)
normal_work_helper(arg)
     A = container_of(arg, struct btrfs_work, normal_work);

     A->func()
     A->ordered_func()
     A->ordered_free()  <-- A gets freed

     B->ordered_func()
  submit_compressed_extents()
      find_free_extent()
  load_free_space_inode()
      ...   <-- (the above readhead stack)
      end_workqueue_bio()
   btrfs_queue_work(work C)
     B->ordered_free()

As if work A has a high priority in wq->ordered_list and there are more ordered
works queued after it, such as B->ordered_func(), its memory could have been
freed before normal_work_helper() returns, which means that kernel workqueue
code worker_thread() still has worker->current_work pointer to be work
A->normal_work's, ie. arg's address.

Meanwhile, work C is allocated after work A is freed, work C->normal_work
and work A->normal_work are likely to share the same address(I confirmed this
with ftrace output, so I'm not just guessing, it's rare though).

When another kthread picks up work C->normal_work to process, and finds our
kthread is processing it(see find_worker_executing_work()), it'll think
work C as a collision and skip then, which ends up nobody processing work C.

So the situation is that our kthread is waiting forever on work C.

Besides, there're other cases that can lead to deadlock, but the real problem
is that all btrfs workqueue shares one work->func, -- normal_work_helper,
so this makes each workqueue to have its own helper function, but only a
wraper pf normal_work_helper.

With this patch, I no long hit the above hang.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Chris Mason <clm@fb.com>

MAINTAINERS: Add entry for Renesas DRM drivers

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>

Merge branch 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux into drm-next

This pull just contains some new pci ids.

* 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: add additional SI pci ids
  drm/radeon: add new bonaire pci ids
  drm/radeon: add new KV pci id

ext4: move i_size,i_disksize update routines to helper function

Cc: stable@vger.kernel.org # needed for bug fix patches
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>

ext4: fix BUG_ON in mb_free_blocks()

If we suffer a block allocation failure (for example due to a memory
allocation failure), it's possible that we will call
ext4_discard_allocated_blocks() before we've actually allocated any
blocks.  In that case, fe_len and fe_start in ac->ac_f_ex will still
be zero, and this will result in mb_free_blocks(inode, e4b, 0, 0)
triggering the BUG_ON on mb_free_blocks():

BUG_ON(last >= (sb->s_blocksize << 3));

Fix this by bailing out of ext4_discard_allocated_blocks() if fs_len
is zero.

Also fix a missing ext4_mb_unload_buddy() call in
ext4_discard_allocated_blocks().

Google-Bug-Id: 16844242

Fixes: 86f0afd463215fc3e58020493482faa4ac3a4d69
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org

ext4: propagate errors up to ext4_find_entry()'s callers

If we run into some kind of error, such as ENOMEM, while calling
ext4_getblk() or ext4_dx_find_entry(), we need to make sure this error
gets propagated up to ext4_find_entry() and then to its callers.  This
way, transient errors such as ENOMEM can get propagated to the VFS.
This is important so that the system calls return the appropriate
error, and also so that in the case of ext4_lookup(), we return an
error instead of a NULL inode, since that will result in a negative
dentry cache entry that will stick around long past the OOM condition
which caused a transient ENOMEM error.

Google-Bug-Id: #17142205

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org