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

Pull ARM SoC fixes from Arnd Bergmann:
 -  multiple omap2+ bug fixes
 - a regression on ux500 dt support
 - a build failure on shmobile

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: OMAP2+: omap2plus_defconfig: EHCI driver is not stable, disable it
  ARM: shmobile: fix platsmp.c build when ARCH_SH73A0=n
  ARM: ux500: Over-ride the DT device naming scheme for pinctrl
  ARM: ux500: Fix build errors/warnings when MACH_UX500_DT is not set
  of: address: Don't fail a lookup just because a node has no reg property
  ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer

Merge tag 'pm-for-3.5-rc7' of git://git./linux/kernel/git/rafael/linux-pm

Pull power management fix from Rafael Wysocki:
 "This removes ACPICA code that had already been removed once from the
  kernel already by commit 2780cc4660e1 ("[ACPI] Fix suspend/resume
  lockup issue by leaving Bus Master Arbitration enabled"), because it
  was known to cause systems to lock up during resume from suspend, but
  was re-introduced by mistake during the v3.4 merge window."

* tag 'pm-for-3.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / PM: Leave Bus Master Arbitration enabled for suspend/resume

Merge tag 'driver-core-3.5-rc6' of git://git./linux/kernel/git/gregkh/driver-core

Pull printk fixes from Greg Kroah-Hartman:
 "Here are some more printk fixes for 3.5-rc6.  They resolve all known
  outstanding issues with the printk changes that have been happening.
  They have been tested by the people reporting the problems.

  This hopefully should be it for the printk stuff for 3.5-final.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'driver-core-3.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  kmsg: merge continuation records while printing
  kmsg: /proc/kmsg - support reading of partial log records
  kmsg: make sure all messages reach a newly registered boot console
  kmsg: properly handle concurrent non-blocking read() from /proc/kmsg
  kmsg: add the facility number to the syslog prefix
  kmsg: escape the backslash character while exporting data
  printk: replacing the raw_spin_lock/unlock with raw_spin_lock/unlock_irq

Merge tag 'usb-3.5-rc6' of git://git./linux/kernel/git/gregkh/usb

Pull USB fixes from Greg Kroah-Hartman:
 "Here are a few fixes and new device ids for the 3.5-rc6 tree.

  The PCI changes resolve a long-standing issue with resuming some EHCI
  controllers.  It has been acked by the PCI maintainer, and he asked
  for it to go through my USB tree instead of his.

  The xhci patches also resolve a number of reported issues.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'usb-3.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  PCI: EHCI: fix crash during suspend on ASUS computers
  USB: cdc-wdm: fix lockup on error in wdm_read
  USB: metro-usb: fix tty_flip_buffer_push use
  USB: option: Add MEDIATEK product ids
  USB: option: add ZTE MF60
  xhci: Fix hang on back-to-back Set TR Deq Ptr commands.
  usb: Add support for root hub port status CAS

Merge tag 'char-misc-3.5-rc6' of git://git./linux/kernel/git/gregkh/char-misc

Pull misc fix from Greg Kroah-Hartman:
 "Here's a single MEI driver fix that resolves a regression from 3.4
  that a number of people have reported (and sent to me in different
  patches.)

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'char-misc-3.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  mei: pci_resume: set IRQF_ONESHOT for msi request_threaded_irq

Merge tag 'fixes-for-v3.5-v2' of git://git./linux/kernel/git/linusw/linux-gpio

Pull a late GPIO fix from Linus Walleij:
 "Grr! So typically -next washed out a bug in the bug fixes.  This v2 of
  the pull request fixes another OF/DT related issue caused by fixing
  another OF/DT related issue, courtesy of Gerard Sintselaar.

  So please pull the v2.  Or pull it on top of the other one, whatever.
  Sorry for the panic mode, I'm in the middle of the Swedish woods,
  supposedly on vacation."

* tag 'fixes-for-v3.5-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio/gpio-tps65910: gpio_chip.of_node referenced without CONFIG_OF_GPIO defined

MN10300: Fix a missing semicolon

The declaration of arch_release_thread_info() needs a semicolon.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

gpio/gpio-tps65910: gpio_chip.of_node referenced without CONFIG_OF_GPIO defined

commit 626f9914 added code to initialize gpio_chip.of_node, but if
CONFIG_OF_GPIO is not defined gps-tps65910 fails to build with an
error complaining gpio_chip has no member of_node. I ran into this
while doing a allyesconfig build on linux-next.

Signed-off-by: Gerard Snitselaar <dev@snitselaar.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Merge tag 'fixes-for-v3.5' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fixes from Linus Walleij:
 "Yes, this is a *LATE* GPIO pull request with fixes for v3.5.

  Grant moved across the planet and accidentally fell off the grid, so
  he asked me to take over the GPIO merges for a while 10 days ago.

  Since then I went over the archives and collected this pile of fixes,
  and pulled two of them from the TI maintainer Kevin Hilman.  Then
  waited for them to at least hit linux-next once or twice."

GPIO fixes for v3.5:
 - Invalid context restore on bank 0 for OMAP driver in runtime
   suspend/resume cycle
 - Check for NULL platform data in sta-2x11 driver
 - Constrain selection of the V1 MSM GPIO driver to applicable platforms
   (Kconfig issue)
 - Make sure the correct output value is set in the wm8994 driver
 - Export devm_gpio_request_one() so it can be used in modules.
   Apparently some in-kernel modules can be configured to use this
   leading to breakage.
 - Check that the GPIO is valid in the lantiq driver
 - Fix the flag bits introduced for v3.5, so they don't overlap
 - Fix a device tree intialization bug for imx21-compatible devices
 - Carry over the OF node to the TPS65910 GPIO chip struct

* tag 'fixes-for-v3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: tps65910: initialize of_node of gpio_chip
  gpio/mxc: make irqs work for fsl,imx21-gpio devices
  gpio: fix bits conflict for gpio flags
  mips: pci-lantiq: Fix check for valid gpio
  gpio: export devm_gpio_request_one
  gpiolib: wm8994: Pay attention to the value set when enabling as output
  gpio/msm_v1: CONFIG_GPIO_MSM_V1 is only available on three SoCs
  gpio-sta2x11: don't use pdata if null
  gpio/omap: fix invalid context restore of gpio bank-0
  gpio/omap: fix irq loss while in idle with debounce on

Merge branch 'merge' of git://git./linux/kernel/git/benh/powerpc

Pull powerpc fixes from Benjamin Herrenschmidt:
 "It looks like my rewrite of our lazy irq scheme is still exposing
  "interesting" issues left and right.  The previous fixes are now
  causing an occasional BUG_ON to trigger (which this patch turns into a
  WARN_ON while at it), due to another issue of disconnect of the lazy
  irq state vs the processor state in the idle loop on pseries and
  cell.

  This should fix it properly once for all moving the nasty code to a
  common helper function.

  There's also couple more fixes for some debug stuff that didn't build
  (and helped resolving those problems so it's worth having), along with
  a compile fix for newer gcc's."

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  tty/hvc_opal: Fix debug function name
  powerpc/numa: Avoid stupid uninitialized warning from gcc
  powerpc: Fix build of some debug irq code
  powerpc: More fixes for lazy IRQ vs. idle

ACPI / PM: Leave Bus Master Arbitration enabled for suspend/resume

This is an old suspend/resume lockup fix:

commit 2780cc4660e1
Author: Len Brown <len.brown@intel.com>
Date:   Thu Dec 23 13:43:30 2004 -0500

    [ACPI] Fix suspend/resume lockup issue
    by leaving Bus Master Arbitration enabled.
    The ACPI spec mandates it be disabled only for C3.

    http://bugzilla.kernel.org/show_bug.cgi?id=3599

Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The bug snuck back in in commit 2feec47d4c5f (ACPICA: ACPI 5: Support
for new FADT SleepStatus, SleepControl registers, 2012-02-14),
presumably by copy/pasting a copy of the code without that fix for the
legacy case.

On affected machines, after that commit, the machine locks up hard on
resume from suspend.  The same fix as seven years ago still works.

Addresses <https://bugzilla.kernel.org/show_bug.cgi?id=43641>.

Reported-bisected-and-tested-by: Octavio Alvarez <alvarezp@alvarezp.com>
Reported-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

Revert "of: match by compatible property first"

This reverts commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6.

Meelis Roos reports a regression since 3.5-rc5 that stops Sun Fire V100
and Sun Netra X1 sparc64 machines from booting, hanging after enabling
serial console.  He bisected it to commit 107a84e61cdd.

Rob Herring explains:
 "The problem is match combinations of compatible plus name and/or type
  fail to match correctly.  I have a fix for this, but given how late it
  is for 3.5 I think it is best to revert this for now.  There could be
  other cases that rely on the current although wrong behavior.  I will
  post an updated version for 3.6."

Bisected-and-reported-by: Meelis Roos <mroos@linux.ee>
Requested-by: Rob Herring <rob.herring@calxeda.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mei: pci_resume: set IRQF_ONESHOT for msi request_threaded_irq

when the default irq quick handler is used then IRQF_ONESHOT must be set
otherwise the request fails and following error is displayed:

mei 0000:00:16.0: irq 48 for MSI/MSI-X
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 48
mei 0000:00:16.0: request_threaded_irq failed: irq = 48.
dpm_run_callback(): pci_pm_resume+0x0/0x140 returns -22
PM: Device 0000:00:16.0 failed to resume async: error -22

Reported-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Tested-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Cc: stable <stable@vger.kernel.org> # 3.5
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: EHCI: fix crash during suspend on ASUS computers

Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend.  It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.

It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working.  Consequently
commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add
NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it
reverted the earlier commit and added a whitelist of known good board
names.

Now we know the actual cause of the problem.  Thanks to AceLan Kao for
tracking it down.

According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows.  When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state.  If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so.  This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3.  The end result is
a system hang or memory corruption.

Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend.  This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.

In theory we could do this for every PCI device.  However to avoid
introducing new problems, the patch restricts itself to EHCI host
controllers.

Finally the affected systems can suspend with USB wakeup working
properly.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
Based-on-patch-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Dâniel Fraga <fragabr@gmail.com>
Tested-by: Javier Marcet <jmarcet@gmail.com>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Cc: stable <stable@vger.kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'omap-fixes-for-v3.5-rc6' of git://git./linux/kernel/git/tmlind/linux-omap into fixes

From Tony Lindgren <tony@atomide.com>:
Here is one PM regression fix and a defconfig change to disable
echi-omap because the driver currently causes issues with PM.
This annoys Kevin as it makes it harder for him to validate that
PM is working. The proper fixes for the echi-omap are being
discussed, but looks like it will not be properly working with PM
until in v3.7.

* tag 'omap-fixes-for-v3.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: omap2plus_defconfig: EHCI driver is not stable, disable it
  ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

tty/hvc_opal: Fix debug function name

udbg_init_debug_opal() should be udbg_init_debug_opal_raw() as
the caller in arch/powerpc/kernel/udbg.c expects

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/numa: Avoid stupid uninitialized warning from gcc

Newer gcc are being a bit blind here (it's pretty obvious we don't
reach the code path using the array if we haven't initialized the
pointer) but none of that is performance critical so let's just
silence it.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Fix build of some debug irq code

There was a typo, checking for CONFIG_TRACE_IRQFLAG instead of
CONFIG_TRACE_IRQFLAGS causing some useful debug code to not be
built

This in turns causes a build error on BookE 64-bit due to incorrect
semicolons at the end of a couple of macros, so let's fix that too

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.4]

powerpc: More fixes for lazy IRQ vs. idle

Looks like we still have issues with pSeries and Cell idle code
vs. the lazy irq state. In fact, the reset fixes that went upstream
are exposing the problem more by causing BUG_ON() to trigger (which
this patch turns into a WARN_ON instead).

We need to be careful when using a variant of low power state that
has the side effect of turning interrupts back on, to properly set
all the SW & lazy state to look as if everything is enabled before
we enter the low power state with MSR:EE off as we will return with
MSR:EE on. If not, we have a discrepancy of state which can cause
things to go very wrong later on.

This patch moves the logic into a helper and uses it from the
pseries and cell idle code. The power4/970 idle code already got
things right (in assembly even !) so I'm not touching it. The power7
"bare metal" idle code is subtly different and correct. Remains PA6T
and some hypervisor based Cell platforms which have questionable
code in there, but they are mostly dead platforms so I'll fix them
when I manage to get final answers from the respective maintainers
about how the low power state actually works on them.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.4]

Merge tag 'regulator-3.5' of git://git./linux/kernel/git/broonie/regulator

Pull regulator fix from Mark Brown:
 "A smallish fix for a lock dependency issue which affects a bunch of
  Qualcomm boards that do unusually complicated things with their
  regulators, the API is unlikely to be called by any other system."

* tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: Fix recursive mutex lockdep warning

gspca_sn9c20x: Fix NULL pointer dereference

Don't call v4l2_ctrl_g_ctrl on ctrls which the model cam in question
does not have.

Reported-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[ Taken directly, since Mauro is on vacation ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'virtio-for-linus' of git://git./linux/kernel/git/rusty/linux-2.6-for-linus

Pull minor virtio-balloon fix from Rusty Russell:
 "Theoretical fix, which greatly simplifies upcoming balloon patches
  which will go in via some vm tree."

* tag 'virtio-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
  virtio-balloon: fix add/get API use

Merge tag 'rpmsg-3.5-fixes' of git://git./linux/kernel/git/ohad/rpmsg

Pull rpmsg fixes from Ohad Ben-Cohen:
 "Fixing two (somewhat rare) endpoint-related race issues, both of which
  were reported by Fernando Guzman Lugo."

* tag 'rpmsg-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg:
  rpmsg: make sure inflight messages don't invoke just-removed callbacks
  rpmsg: avoid premature deallocation of endpoints

Merge tag 'remoteproc-3.5-fixes' of git://git./linux/kernel/git/ohad/remoteproc

Pull remoteproc fixes from Ohad Ben-Cohen:
 "Two build-related remoteproc fixes for 3.5."

* tag 'remoteproc-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc:
  remoteproc: fix missing CONFIG_FW_LOADER configurations
  remoteproc/omap: fix randconfig unmet direct dependencies

Merge tag 'hwspinlock-3.5-fixes' of git://git./linux/kernel/git/ohad/hwspinlock

Pull hwspinlock fix from Ohad Ben-Cohen:
 "A single hwspinlock core fix for multiple hwspinlock devices
  scenarios, from Shinya Kuribayashi."

* tag 'hwspinlock-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock:
  hwspinlock/core: use global ID to register hwspinlocks on multiple devices

kmsg: merge continuation records while printing

In (the unlikely) case our continuation merge buffer is busy, we unfortunately
can not merge further continuation printk()s into a single record and have to
store them separately, which leads to split-up output of these lines when they
are printed.

Add some flags about newlines and prefix existence to these records and try to
reconstruct the full line again, when the separated records are printed.

Reported-By: Michael Neuling <mikey@neuling.org>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Tested-By: Michael Neuling <mikey@neuling.org>
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'kevin' into fixes

Merge tag 'iommu-fixes-v3.5-rc5' of git://git./linux/kernel/git/joro/iommu

Pull IOMMU fixes from Joerg Roedel:
 "The patches fix several issues in the AMD IOMMU driver, the NVidia
  SMMU driver, and the DMA debug code.

  The most important fix for the AMD IOMMU solves a problem with SR-IOV
  devices where virtual functions did not work with IOMMU enabled.  The
  NVidia SMMU patch fixes a possible sleep while spin-lock situation
  (queued the small fix for v3.5, a better but more intrusive fix is
  coming for v3.6).  The DMA debug patches fix a possible data
  corruption issue due to bool vs u32 usage."

* tag 'iommu-fixes-v3.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/amd: fix type bug in flush code
  dma-debug: debugfs_create_bool() takes a u32 pointer
  iommu/tegra: smmu: Fix unsleepable memory allocation
  iommu/amd: Initialize dma_ops for hotplug and sriov devices
  iommu/amd: Fix missing iommu_shutdown initialization in passthrough mode

kmsg: /proc/kmsg - support reading of partial log records

Restore support for partial reads of any size on /proc/kmsg, in case the
supplied read buffer is smaller than the record size.

Some people seem to think is is ia good idea to run:
  $ dd if=/proc/kmsg bs=1 of=...
as a klog bridge.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44211
Reported-by: Jukka Ollila <jiiksteri@gmail.com>
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: OMAP2+: omap2plus_defconfig: EHCI driver is not stable, disable it

The EHCI driver is not stable enough to be enabled by default.  In v3.5,
it has at least the following problems:

- warning dump during bootup
- hang during suspend
- prevents CORE powerdomain from entering retention during idle (even
  when no USB devices connected.)

This demonstrates that this driver has not been thoroughly tested and
therfore should not be enabled in the default defconfig.

In addition, the problems above cause new PM regressions which need be
addressed before this driver should be enabled in the default
defconfig.

Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

virtio-balloon: fix add/get API use

Since ee7cd8981e15bcb365fc762afe3fc47b8242f630 'virtio: expose added
descriptors immediately.', in virtio balloon virtqueue_get_buf might
now run concurrently with virtqueue_kick.  I audited both and this
seems safe in practice but this is not guaranteed by the API.
Additionally, a spurious interrupt might in theory make
virtqueue_get_buf run in parallel with virtqueue_add_buf, which is
racy.

While we might try to protect against spurious callbacks it's
easier to fix the driver: balloon seems to be the only one
(mis)using the API like this, so let's just fix balloon.

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

Merge branch 'for-3.5-fixes' of git://git./linux/kernel/git/tj/cgroup

Pull cgroup fixes from Tejun Heo:
 "The previous cgroup pull request contained a patch to fix a race
  condition during cgroup hierarchy umount.  Unfortunately, while the
  patch reduced the race window such that the test case I and Sasha were
  using didn't trigger it anymore, it wasn't complete - Shyju and Li
  could reliably trigger the race condition using a different test case.

  The problem wasn't the gap between dentry deletion and release which
  the previous patch tried to fix.  The window was between the last
  dput() of a root's child and the resulting dput() of the root.  For
  cgroup dentries, the deletion and release always happen synchronously.
  As this releases the s_active ref, the refcnt of the root dentry,
  which doesn't hold s_active, stays above zero without the
  corresponding s_active.  If umount was in progress, the last
  deactivate_super() proceeds to destory the superblock and triggers
  BUG() on the non-zero root dentry refcnt after shrinking.

  This issue surfaced because cgroup dentries are now allowed to linger
  after rmdir(2) since 3.5-rc1.  Before, rmdir synchronously drained the
  dentry refcnt and the s_active acquired by rmdir from vfs layer
  protected the whole thing.  After 3.5-rc1, cgroup may internally hold
  and put dentry refs after rmdir finishes and the delayed dput()
  doesn't have surrounding s_active ref exposing this issue.

  This pull request contains two patches - one reverting the previous
  incorrect fix and the other adding the surrounding s_active ref around
  the delayed dput().

  This is quite late in the release cycle but the change is on the safer
  side and fixes the test cases reliably, so I don't think it's too
  crazy."

* 'for-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cgroup: fix cgroup hierarchy umount race
  Revert "cgroup: superblock can't be released with active dentries"

Linux 3.5-rc6

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

Pull security docs update from James Morris.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  security: Minor improvements to no_new_privs documentation

vfs: make O_PATH file descriptors usable for 'fchdir()'

We already use them for openat() and friends, but fchdir() also wants to
be able to use O_PATH file descriptors.  This should make it comparable
to the O_SEARCH of Solaris.  In particular, O_PATH allows you to access
(not-quite-open) a directory you don't have read persmission to, only
execute permission.

Noticed during development of multithread support for ksh93.

Reported-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org # O_PATH introduced in 3.0+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

cgroup: fix cgroup hierarchy umount race

48ddbe1946 "cgroup: make css->refcnt clearing on cgroup removal
optional" allowed a css to linger after the associated cgroup is
removed.  As a css holds a reference on the cgroup's dentry, it means
that cgroup dentries may linger for a while.

Destroying a superblock which has dentries with positive refcnts is a
critical bug and triggers BUG() in vfs code.  As each cgroup dentry
holds an s_active reference, any lingering cgroup has both its dentry
and the superblock pinned and thus preventing premature release of
superblock.

Unfortunately, after 48ddbe1946, there's a small window while
releasing a cgroup which is directly under the root of the hierarchy.
When a cgroup directory is released, vfs layer first deletes the
corresponding dentry and then invokes dput() on the parent, which may
recurse further, so when a cgroup directly below root cgroup is
released, the cgroup is first destroyed - which releases the s_active
it was holding - and then the dentry for the root cgroup is dput().

This creates a window where the root dentry's refcnt isn't zero but
superblock's s_active is.  If umount happens before or during this
window, vfs will see the root dentry with non-zero refcnt and trigger
BUG().

Before 48ddbe1946, this problem didn't exist because the last dentry
reference was guaranteed to be put synchronously from rmdir(2)
invocation which holds s_active around the whole process.

Fix it by holding an extra superblock->s_active reference across
dput() from css release, which is the dput() path added by 48ddbe1946
and the only one which doesn't hold an extra s_active ref across the
final cgroup dput().

Signed-off-by: Tejun Heo <tj@kernel.org>
LKML-Reference: <4FEEA5CB.8070809@huawei.com>
Reported-by: shyju pv <shyju.pv@huawei.com>
Tested-by: shyju pv <shyju.pv@huawei.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Acked-by: Li Zefan <lizefan@huawei.com>

Revert "cgroup: superblock can't be released with active dentries"

This reverts commit fa980ca87d15bb8a1317853f257a505990f3ffde.  The
commit was an attempt to fix a race condition where a cgroup hierarchy
may be unmounted with positive dentry reference on root cgroup.  While
the commit made the race condition slightly more difficult to trigger,
the race was still there and could be reliably triggered using a
different test case.

Revert the incorrect fix.  The next commit will describe the race and
fix it correctly.

Signed-off-by: Tejun Heo <tj@kernel.org>
LKML-Reference: <4FEEA5CB.8070809@huawei.com>
Reported-by: shyju pv <shyju.pv@huawei.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Acked-by: Li Zefan <lizefan@huawei.com>

hwspinlock/core: use global ID to register hwspinlocks on multiple devices

Commit 300bab9770 (hwspinlock/core: register a bank of hwspinlocks in a
single API call, 2011-09-06) introduced 'hwspin_lock_register_single()'
to register numerous (a bank of) hwspinlock instances in a single API,
'hwspin_lock_register()'.

At which time, 'hwspin_lock_register()' accidentally passes 'local IDs'
to 'hwspin_lock_register_single()', despite that ..._single() requires
'global IDs' to register hwspinlocks.

We have to convert into global IDs by supplying the missing 'base_id'.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
[ohad: fix error path of hwspin_lock_register, too]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm

Pull ARM fixes from Russell King:
 "Last merge window, we had some updates from Al cleaning up the signal
  restart handling.  These have caused some problems on ARM, and while
  Al has some fixes, we have some concerns with Al's patches but we've
  been unsuccesful with discussing this.

  We have got to the point where we need to do something, and we've
  decided that the best solution is to revert the appropriate commits
  until Al is able to reply to us.

  Also included here are four patches to fix warnings that I've noticed
  in my build system, and one fix for kprobes test code."

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: fix warning caused by wrongly typed arm_dma_limit
  ARM: fix warnings about atomic64_read
  ARM: 7440/1: kprobes: only test 'sub pc, pc, #1b-2b+8-2' on ARMv6
  ARM: 7441/1: perf: return -EOPNOTSUPP if requested mode exclusion is unavailable
  ARM: 7443/1: Revert "new way of handling ERESTART_RESTARTBLOCK"
  ARM: 7442/1: Revert "remove unused restart trampoline"
  ARM: fix set_domain() macro
  ARM: fix mach-versatile/pci.c warning

security: Minor improvements to no_new_privs documentation

The documentation didn't actually mention how to enable no_new_privs.
This also adds a note about possible interactions between
no_new_privs and LSMs (i.e. why teaching systemd to set no_new_privs
is not necessarily a good idea), and it references the new docs
from include/linux/prctl.h.

Suggested-by: Rob Landley <rob@landley.net>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>

Merge tag 'ecryptfs-3.5-rc6-fixes' of git://git./linux/kernel/git/tyhicks/ecryptfs

Pull eCryptfs fixes from Tyler Hicks:
 "Fixes an incorrect access mode check when preparing to open a file in
  the lower filesystem.  This isn't an urgent fix, but it is simple and
  the check was obviously incorrect.

  Also fixes a couple important bugs in the eCryptfs miscdev interface.
  These changes are low risk due to the small number of users that use
  the miscdev interface.  I was able to keep the changes minimal and I
  have some cleaner, more complete changes queued up for the next merge
  window that will build on these patches."

* tag 'ecryptfs-3.5-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
  eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files
  eCryptfs: Fix lockdep warning in miscdev operations
  eCryptfs: Properly check for O_RDONLY flag before doing privileged open

Merge git://git./linux/kernel/git/nab/target-pending

Pull target fixes from Nicholas Bellinger:
 "Two minor target fixes.  There is really nothing exciting and/or
  controversial this time around.

  There's one fix from MDR for a RCU debug warning message within tcm_fc
  code (CC'ed to stable), and a small AC fix for qla_target.c based upon
  a recent Coverity static report.

  Also, there is one other outstanding virtio-scsi LUN scanning bugfix
  that has been uncovered with the in-flight tcm_vhost driver over the
  last days, and that needs to make it into 3.5 final too.  This patch
  has been posted to linux-scsi again here:

    http://marc.info/?l=linux-scsi&m=134160609212542&w=2

  and I've asked James to include it in his next PULL request."

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  qla2xxx: print the right array elements in qlt_async_event
  tcm_fc: Resolve suspicious RCU usage warnings

eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files

File operations on /dev/ecryptfs would BUG() when the operations were
performed by processes other than the process that originally opened the
file. This could happen with open files inherited after fork() or file
descriptors passed through IPC mechanisms. Rather than calling BUG(), an
error code can be safely returned in most situations.

In ecryptfs_miscdev_release(), eCryptfs still needs to handle the
release even if the last file reference is being held by a process that
didn't originally open the file. ecryptfs_find_daemon_by_euid() will not
be successful, so a pointer to the daemon is stored in the file's
private_data. The private_data pointer is initialized when the miscdev
file is opened and only used when the file is released.

https://launchpad.net/bugs/994247

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>

qla2xxx: print the right array elements in qlt_async_event

Based upon Alan's patch from Coverity scan id 793583, these debug
messages in qlt_async_event() should be starting from byte 0, which is
always the Asynchronous Event Status Code from the parent switch statement.

Also, rename reason_code -> login_code following the language used in
2500 FW spec for Port Database Changed (0x8014) -> Port Database Changed
Event Mailbox Register for mailbox[2].

Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Chad Dupuis <chad.dupuis@qlogic.com>
Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

ARM: shmobile: fix platsmp.c build when ARCH_SH73A0=n

Fix build error in the case of SMP=y but ARCH_SH73A0=n
introduced by:

9601e87 ARM: shmobile: fix smp build

The use of of_machine_is_compatible() will link in the
the SoC-specific symbols:
"sh73a0_get_core_count", "sh73a0_smp_prepare_cpus",
"sh73a0_secondary_init" and "sh73a0_boot_secondary".

This patch adds an ugly #ifdef wrapper as a stop-gap
solution.

Signed-off-by: Magnus Damm <damm@opensource.se>
Tested-by: Tested-by: Simon Horman <horms@verge.net.au>
Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

tcm_fc: Resolve suspicious RCU usage warnings

Use rcu_dereference_protected to tell rcu that the ft_lport_lock
is held during ft_lport_create. This resolved "suspicious RCU usage"
warnings when debugging options are turned on.

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

Merge branch 'ux500/fixes-3.5' into fixes

From Lee Jones <lee.jones@linaro.org>:

* ux500/fixes-3.5:
  ARM: ux500: Over-ride the DT device naming scheme for pinctrl
  ARM: ux500: Fix build errors/warnings when MACH_UX500_DT is not set
  of: address: Don't fail a lookup just because a node has no reg property

I ended up rebasing Lee's branch on 3.5-rc5 because we have more patches
lined for 3.6 that depend on them, and I want to keep all branches in
arm-soc be based on -rc releases rather than random commits in the
upstream history.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

ARM: ux500: Over-ride the DT device naming scheme for pinctrl

When pin control mapping tables are written the registered device
name is supplied for use in name-based searches within the pinctrl
driver. In the case of the DB8500 the string "pinctrl-db8500" is
used. However, when we register the driver with Device Tree, its
naming convention uses something that looks more like "pinctrl.2".

To work around the device naming inconsistencies between devices
registered via platform code and the ones registered by Device
Tree, we use AUXDATA to over-ride the Device Tree naming scheme.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

ARM: ux500: Fix build errors/warnings when MACH_UX500_DT is not set

When MACH_UX500_DT and all related Device Tree configurations are forced
off the warning and error below prevent the kernel from compiling. This
simple patch fixes both issues and allows for full build and boot of
ST-Ericsson's low-cost development board, Snowball.

Warnings fixed:
  arch/arm/mach-ux500/board-mop500.c:680:32: warning: ‘snowball_of_platform_devs’ defined but not used

Errors fixed:
  arch/arm/mach-ux500/timer.c: In function ‘ux500_timer_init’:
  arch/arm/mach-ux500/timer.c:66:3: error: implicit declaration of function ‘of_find_matching_node’
  arch/arm/mach-ux500/timer.c:66:6: warning: assignment makes pointer from integer without a cast

Cc: stable@vger.kernel.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

of: address: Don't fail a lookup just because a node has no reg property

Sometimes it doesn't make any sense for a node to have an address.
In this case device lookup will always be unsuccessful because we
currently assume every node will have a reg property. This patch
changes the semantics so that the resource address and the lookup
address will only be compared if one exists.

Things like AUXDATA() rely on of_dev_lookup to return the lookup
entry of a particular device in order to do things like apply
platform_data to a device. However, this is currently broken for
nodes which do not have a reg property, meaning that platform_data
can not be passed in those cases.

Acked-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

Merge tag 'for-linus-20120706' of git://git.infradead.org/linux-mtd

Pull two MTD fixes from David Woodhouse:
 - Fix a logic error in OLPC CAFÉ NAND ready() function.
 - Fix regression due to bitflip handling changes.

* tag 'for-linus-20120706' of git://git.infradead.org/linux-mtd:
  mtd: cafe_nand: fix an & vs | mistake
  mtd: nand: initialize bitflip_threshold prior to BBT scanning

mm: Hold a file reference in madvise_remove

Otherwise the code races with munmap (causing a use-after-free
of the vma) or with close (causing a use-after-free of the struct
file).

The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
mmap_sem i_mutex deadlock")

Cc: Hugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'fixes' of git://git./linux/kernel/git/jlbec/ocfs2

Pull ocfs2 fixes from Joel Becker.

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2:
  aio: make kiocb->private NUll in init_sync_kiocb()
  ocfs2: Fix bogus error message from ocfs2_global_read_info
  ocfs2: for SEEK_DATA/SEEK_HOLE, return internal error unchanged if ocfs2_get_clusters_nocache() or ocfs2_inode_lock() call failed.
  ocfs2: use spinlock irqsave for downconvert lock.patch
  ocfs2: Misplaced parens in unlikley
  ocfs2: clear unaligned io flag when dio fails

Merge git://git.samba.org/sfrench/cifs-2.6

Pull cifs fixes from Steve French.

* git://git.samba.org/sfrench/cifs-2.6:
  cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize
  cifs: fix parsing of password mount option

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

Pull input layer fixes from Dmitry Torokhov:
 "Two fixes for regressions in Wacom driver and fixes for drivers using
  threaded IRQ framework without specifying IRQF_ONESHOT."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: request threaded-only IRQs with IRQF_ONESHOT
  Input: wacom - don't retrieve touch_max when it is predefined
  Input: wacom - fix retrieving touch_max bug
  Input: fix input.h kernel-doc warning

kmsg: make sure all messages reach a newly registered boot console

We suppress printing kmsg records to the console, which are already printed
immediately while we have received their fragments.

Newly registered boot consoles print the entire kmsg buffer during
registration. Clear the console-suppress flag after we skipped the record
during its first storage, so any later print will see these records as usual.

Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kmsg: properly handle concurrent non-blocking read() from /proc/kmsg

The /proc/kmsg read() interface is internally simply wired up to a sequence
of syslog() syscalls, which might are racy between their checks and actions,
regarding concurrency.

In the (very uncommon) case of concurrent readers of /dev/kmsg, relying on
usual O_NONBLOCK behavior, the recently introduced mutex might block an
O_NONBLOCK reader in read(), when poll() returns for it, but another process
has already read the data in the meantime. We've seen that while running
artificial test setups and tools that "fight" about /proc/kmsg data.

This restores the original /proc/kmsg behavior, where in case of concurrent
read()s, poll() might wake up but the read() syscall will just return 0 to
the caller, while another process has "stolen" the data.

This is in the general case not the expected behavior, but it is the exact
same one, that can easily be triggered with a 3.4 kernel, and some tools
might just rely on it.

The mutex is not needed, the original integrity issue which introduced it,
is in the meantime covered by:
  "fill buffer with more than a single message for SYSLOG_ACTION_READ"
  116e90b23f74d303e8d607c7a7d54f60f14ab9f2

Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kmsg: add the facility number to the syslog prefix

After the recent split of facility and level into separate variables,
we miss the facility value (always 0 for kernel-originated messages)
in the syslog prefix.

On Tue, Jul 3, 2012 at 12:45 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Static checkers complain about the impossible condition here.
>
> In 084681d14e ('printk: flush continuation lines immediately to
> console'), we changed msg->level from being a u16 to being an unsigned
> 3 bit bitfield.

Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kmsg: escape the backslash character while exporting data

Non-printable characters in the log data are hex-escaped to ensure safe
post processing. We need to escape a backslash we find in the data, to be
able to distinguish it from a backslash we add for the escaping.

Also escape the non-printable character 127.

Thanks to Miloslav Trmac for the heads up.

Reported-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

printk: replacing the raw_spin_lock/unlock with raw_spin_lock/unlock_irq

In function devkmsg_read/writev/llseek/poll/open()..., the function
raw_spin_lock/unlock is used, there is potential deadlock case happening.
CPU1: thread1 doing the cat /dev/kmsg:
        raw_spin_lock(&logbuf_lock);
        while (user->seq == log_next_seq) {
when thread1 run here, at this time one interrupt is coming on CPU1 and running
based on this thread,if the interrupt handle called the printk which need the
logbuf_lock spin also, it will cause deadlock.

So we should use raw_spin_lock/unlock_irq here.

Acked-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mtd: cafe_nand: fix an & vs | mistake

The intent here was clearly to set result to true if the 0x40000000 flag
was set.  But instead there was a | vs & typo and we always set result
to true.

Artem: check the spec at
wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf
and this fix looks correct.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

Merge branch 'for_3.5/fixes/pm-3' of git://git./linux/kernel/git/khilman/linux-omap-pm into fixes

ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer

Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3.  This prevents device low power
states.

The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active.  This in turn prevents the WKUP
clockdomain from transitioning to idle.  There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.

It turns out that there is no need to take the 32k sync timer out of
idle.  The IP block itself probably does not have any native idle
handling at all, due to its simplicity.  Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active.  So
we can safely leave the 32k sync timer in target-force-idle mode, even
while we continue to access it.

This workaround is implemented by defining a new clockdomain flag,
CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
guaranteed to be active whenever the MPU is inactive.  If an IP
block's main functional clock exists inside this clockdomain, and the
IP block does not support smart-idle modes, then the hwmod code will
place the IP block into target force-idle mode even when enabled.  The
WKUP clockdomains on OMAP3/4 are marked with this flag.  (On OMAP2xxx,
no OCP header existed on the 32k sync timer.)   Other clockdomains also
should be marked with this flag, but those changes are deferred until
a later merge window, to create a minimal fix.

Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses.  These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource.  But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.

Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI.  But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.

This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.

Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
an earlier version of this patch.  Thanks to Tero Kristo
<t-kristo@ti.com> for identifying a bug in an earlier version of this
patch.  Thanks to Benoît Cousson <b-cousson@ti.com> for identifying
some bugs in several versions of this patch and for implementation
comments.

References:

1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
   (SWPU223U), available from:
   http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip

2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
   (SWPU223U)

3. ibid.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>

USB: cdc-wdm: fix lockup on error in wdm_read

Clear the WDM_READ flag on empty reads to avoid running
forever in an infinite tight loop, causing lockups:

Jul  1 21:58:11 nemi kernel: [ 3658.898647] qmi_wwan 2-1:1.2: Unexpected error -71
Jul  1 21:58:36 nemi kernel: [ 3684.072021] BUG: soft lockup - CPU#0 stuck for 23s! [qmi.pl:12235]
Jul  1 21:58:36 nemi kernel: [ 3684.072212] CPU 0
Jul  1 21:58:36 nemi kernel: [ 3684.072355]
Jul  1 21:58:36 nemi kernel: [ 3684.072367] Pid: 12235, comm: qmi.pl Tainted: P           O 3.5.0-rc2+ #13 LENOVO 2776LEG/2776LEG
Jul  1 21:58:36 nemi kernel: [ 3684.072383] RIP: 0010:[<ffffffffa0635008>]  [<ffffffffa0635008>] spin_unlock_irq+0x8/0xc [cdc_wdm]
Jul  1 21:58:36 nemi kernel: [ 3684.072388] RSP: 0018:ffff88022dca1e70  EFLAGS: 00000282
Jul  1 21:58:36 nemi kernel: [ 3684.072393] RAX: ffff88022fc3f650 RBX: ffffffff811c56f7 RCX: 00000001000ce8c1
Jul  1 21:58:36 nemi kernel: [ 3684.072398] RDX: 0000000000000010 RSI: 000000000267d810 RDI: ffff88022fc3f650
Jul  1 21:58:36 nemi kernel: [ 3684.072403] RBP: ffff88022dca1eb0 R08: ffffffffa063578e R09: 0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072407] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000002
Jul  1 21:58:36 nemi kernel: [ 3684.072412] R13: 0000000000000246 R14: ffffffff00000002 R15: ffff8802281d8c88
Jul  1 21:58:36 nemi kernel: [ 3684.072418] FS:  00007f666a260700(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072423] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul  1 21:58:36 nemi kernel: [ 3684.072428] CR2: 000000000270d9d8 CR3: 000000022e865000 CR4: 00000000000007f0
Jul  1 21:58:36 nemi kernel: [ 3684.072433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072438] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jul  1 21:58:36 nemi kernel: [ 3684.072444] Process qmi.pl (pid: 12235, threadinfo ffff88022dca0000, task ffff88022ff76380)
Jul  1 21:58:36 nemi kernel: [ 3684.072448] Stack:
Jul  1 21:58:36 nemi kernel: [ 3684.072458]  ffffffffa063592e 0000000100020000 ffff88022fc3f650 ffff88022fc3f6a8
Jul  1 21:58:36 nemi kernel: [ 3684.072466]  0000000000000200 0000000100000000 000000000267d810 0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072475]  0000000000000000 ffff880212cfb6d0 0000000000000200 ffff880212cfb6c0
Jul  1 21:58:36 nemi kernel: [ 3684.072479] Call Trace:
Jul  1 21:58:36 nemi kernel: [ 3684.072489]  [<ffffffffa063592e>] ? wdm_read+0x1a0/0x263 [cdc_wdm]
Jul  1 21:58:36 nemi kernel: [ 3684.072500]  [<ffffffff8110adb7>] ? vfs_read+0xa1/0xfb
Jul  1 21:58:36 nemi kernel: [ 3684.072509]  [<ffffffff81040589>] ? alarm_setitimer+0x35/0x64
Jul  1 21:58:36 nemi kernel: [ 3684.072517]  [<ffffffff8110aec7>] ? sys_read+0x45/0x6e
Jul  1 21:58:36 nemi kernel: [ 3684.072525]  [<ffffffff813725f9>] ? system_call_fastpath+0x16/0x1b
Jul  1 21:58:36 nemi kernel: [ 3684.072557] Code: <66> 66 90 c3 83 ff ed 89 f8 74 16 7f 06 83 ff a1 75 0a c3 83 ff f4

The WDM_READ flag is normally cleared by wdm_int_callback
before resubmitting the read urb, and set by wdm_in_callback
when this urb returns with data or an error.  But a crashing
device may cause both a read error and cancelling all urbs.
Make sure that the flag is cleared by wdm_read if the buffer
is empty.

We don't clear the flag on errors, as there may be pending
data in the buffer which should be processed.  The flag will
instead be cleared on the next wdm_read call.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: metro-usb: fix tty_flip_buffer_push use

Do not set low_latency flag at open as tty_flip_buffer_push must not be
called in IRQ context with low_latency set.

Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: option: Add MEDIATEK product ids

Signed-off-by: Gaosen Zhang <gaosen.zhang@mediatek.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: option: add ZTE MF60

Switches into a composite device by ejecting the initial
driver CD.  The four interfaces are: QCDM, AT, QMI/wwan
and mass storage.  Let this driver manage the two serial
interfaces:

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 28 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=19d2 ProdID=1402 Rev= 0.00
S:  Manufacturer=ZTE,Incorporated
S:  Product=ZTE WCDMA Technologies MSM
S:  SerialNumber=xxxxx
C:* #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'for-usb-linus-2012-07-02' of git://git./linux/kernel/git/sarah/xhci into usb-linus

xhci: Fix driver hang and resume error path.

Hi Greg,

Here's two bug fixes for 3.5.  The first fixes an issue with port
connections not being reported to the USB core after a system resume.
The second fixes a driver hang when there are two back to back stalls on
an endpoint.

Sarah Sharp

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

Pull ARM SoC fixes from Arnd Bergmann:
 "Small fixes on multiple ARM platforms
   - A build regression from a previous fix on dove and mv78xx0
   - Two fixes for recently (3.5-rc1) changed mmp/pxa code
   - multiple omap2+ bug fixes
   - two trivial fixes for i.MX
   - one v3.5 regression for mxs"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: apx4devkit: fix FEC enabling PHY clock
  ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4
  ARM: OMAP4: hwmod data: temporarily comment out data for the usb_host_fs and aess IP blocks
  ARM: Orion: Fix WDT compile for Dove and MV78xx0
  ARM: mmp: remove mach/gpio-pxa.h
  ARM: imx: assert SCC gate stays enabled
  ARM: OMAP4: TWL6030: ensure sys_nirq1 is mux'd and wakeup enabled
  ARM: OMAP2: Overo: init I2C before MMC to fix MMC suspend/resume failure
  ARM: imx27_visstrim_m10: Do not include <asm/system.h>
  ARM: pxa: hx4700: Fix basic suspend/resume

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

Pull KVM fix from Marcelo Tosatti:
 "Memory leak and oops on the x86 mmu code, and sanitization of the
  KVM_IRQFD ioctl."

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: MMU: fix shrinking page from the empty mmu
  KVM: fix fault page leak
  KVM: Sanitize KVM_IRQFD flags
  KVM: Add missing KVM_IRQFD API documentation
  KVM: Pass kvm_irqfd to functions

Merge branch 'fixes-for-3.5' of git://git./linux/kernel/git/cooloney/linux-leds

Pull leds fix from Bryan Wu:
 "Fix for heartbeat led trigger driver"

* 'fixes-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
  leds: heartbeat: fix bug on panic

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

Pull btrfs updates from Chris Mason:
 "I held off on my rc5 pull because I hit an oops during log recovery
  after a crash.  I wanted to make sure it wasn't a regression because
  we have some logging fixes in here.

  It turns out that a commit during the merge window just made it much
  more likely to trigger directory logging instead of full commits,
  which exposed an old bug.

  The new backref walking code got some additional fixes.  This should
  be the final set of them.

  Josef fixed up a corner where our O_DIRECT writes and buffered reads
  could expose old file contents (not stale, just not the most recent).
  He and Liu Bo fixed crashes during tree log recover as well.

  Ilya fixed errors while we resume disk balancing operations on
  readonly mounts."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: run delayed directory updates during log replay
  Btrfs: hold a ref on the inode during writepages
  Btrfs: fix tree log remove space corner case
  Btrfs: fix wrong check during log recovery
  Btrfs: use _IOR for BTRFS_IOC_SUBVOL_GETFLAGS
  Btrfs: resume balance on rw (re)mounts properly
  Btrfs: restore restriper state on all mounts
  Btrfs: fix dio write vs buffered read race
  Btrfs: don't count I/O statistic read errors for missing devices
  Btrfs: resolve tree mod log locking issue in btrfs_next_leaf
  Btrfs: fix tree mod log rewind of ADD operations
  Btrfs: leave critical region in btrfs_find_all_roots as soon as possible
  Btrfs: always put insert_ptr modifications into the tree mod log
  Btrfs: fix tree mod log for root replacements at leaf level
  Btrfs: support root level changes in __resolve_indirect_ref
  Btrfs: avoid waiting for delayed refs when we must not

Merge branch 'fixes-for-grant' of git://sources.calxeda.com/kernel/linux

Pull DT fixes from Rob Herring:
 "Mainly some documentation updates and 2 fixes:

   - An export symbol fix for of_platform_populate from Stephen W.
   - A fix for the order compatible entries are matched to ensure the
     first compatible string is matched when there are multiple matches."

Normally these would go through Grant Likely (thus the "fixes-for-grant"
branch name), but Grant is in the middle of moving to Scotland, and is
practically offline until sometime in August. So pull directly from Rob.

* 'fixes-for-grant' of git://sources.calxeda.com/kernel/linux:
  of: match by compatible property first
  dt: mc13xxx.txt: Fix gpio number assignment
  dt: fsl-fec.txt: Fix gpio number assignment
  dt: fsl-mma8450.txt: Add missing 'reg' description
  dt: fsl-imx-esdhc.txt: Fix gpio number assignment
  dt: fsl-imx-cspi.txt: Fix comment about GPIOs used for chip selects
  of: Add Avionic Design vendor prefix
  of: export of_platform_populate()

gpio: tps65910: initialize of_node of gpio_chip

Initialize the gpio chip's of_node to the device's node
to work with DT based system.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio/mxc: make irqs work for fsl,imx21-gpio devices

The chained handler was set for the platform device with id == 0.
When the gpio devices are instantiated by a device tree, all have id ==
-1 and so the handler was unset resulting in unusable gpio irqs on
i.MX21 and i.MX27 (when using oftree).

Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: fix bits conflict for gpio flags

The bit 2 and 3 in GPIO flag are allocated for the
flag OPEN_DRAIN/OPEN_SOURCE. These bits are reused
for the flag EXPORT/EXPORT_CHANGEABLE and so creating
conflict.
Fix this conflict by assigning bit 4 and 5 for the
flag EXPORT/EXPORT_CHANGEABLE.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

mips: pci-lantiq: Fix check for valid gpio

This patch fixes two checks for valid gpio number, formerly (wrongly)
considering zero as invalid, now using gpio_is_valid().

Signed-off-by: Roland Stigge <stigge@antcom.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: export devm_gpio_request_one

Without this, modules can't use this API, leading to build failures.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: wm8994: Pay attention to the value set when enabling as output

Not paying attention to the value being set is a bad thing because it
means that we'll not set the hardware up to reflect what was requested.
Not setting the hardware up to reflect what was requested means that the
caller won't get the results they wanted.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio/msm_v1: CONFIG_GPIO_MSM_V1 is only available on three SoCs

The feature GPIO_MSM_V1 is only available on three SoCs. On all other MSM SoCs
the INT_GPIO_GROUP{1,2} is undeclared, but Kconfig does allow such
configurations. Therefore the produced configuration is valid, but does not
compile. The problem is fixed by adding the missing Kconfig constraints.

drivers/gpio/gpio-msm-v1.c: In function â\80\98msm_init_gpioâ\80\99:
drivers/gpio/gpio-msm-v1.c:629:26: error: 'INT_GPIO_GROUP1' undeclared
drivers/gpio/gpio-msm-v1.c:630:26: error: 'INT_GPIO_GROUP2' undeclared

Signed-off-by: Christian Dietrich <christian.dietrich@informatik.uni-erlangen.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio-sta2x11: don't use pdata if null

If there is no platform data available, the driver shouldn't use the
pointer or it will oops.  Since things will mostly work nonetheless,
(the BIOS may have set up the pins properly), I'd better not fail the
probe even in this case.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

ARM: fix warning caused by wrongly typed arm_dma_limit

arch/arm/mm/init.c: In function 'arm_memblock_init':
arch/arm/mm/init.c:380: warning: comparison of distinct pointer types lacks a cast

by fixing the typecast in its definition when DMA_ZONE is disabled.
This was missed in 4986e5c7c (ARM: mm: fix type of the arm_dma_limit
global variable).

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

ARM: fix warnings about atomic64_read

Fix:
net/netfilter/xt_connbytes.c: In function 'connbytes_mt':
net/netfilter/xt_connbytes.c:43: warning: passing argument 1 of 'atomic64_read' discards qualifiers from pointer target type
...

by adding the missing const.

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

ARM: 7440/1: kprobes: only test 'sub pc, pc, #1b-2b+8-2' on ARMv6

'sub pc, pc, #1b-2b+8-2' results in address<1:0> == '10'.

sub pc, pc, #const (== ADR pc, #const) performs an interworking branch
(BXWritePC()) on ARMv7+ and a simple branch (BranchWritePC()) on earlier
versions.

In ARM state, BXWritePC() is UNPREDICTABLE when address<1:0> == '10'.

In ARM state on ARMv6+, BranchWritePC() ignores address<1:0>.  Before
ARMv6, BranchWritePC() is UNPREDICTABLE if address<1:0> != '00'

So the instruction is UNPREDICTABLE both before and after v6.

Acked-by: Jon Medhurst <tixy@yxit.co.uk>
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Merge tag 'omap-fixes-for-v3.5-rc5' of git://git./linux/kernel/git/tmlind/linux-omap into fixes

PM related fixes for omaps mostly to get suspend/resume
working again.

* tag 'omap-fixes-for-v3.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4
  ARM: OMAP4: hwmod data: temporarily comment out data for the usb_host_fs and aess IP blocks
  ARM: OMAP4: TWL6030: ensure sys_nirq1 is mux'd and wakeup enabled
  ARM: OMAP2: Overo: init I2C before MMC to fix MMC suspend/resume failure

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge branch 'mxs/fixes-for-3.5' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes

* 'mxs/fixes-for-3.5' of git://git.linaro.org/people/shawnguo/linux-2.6:
  ARM: apx4devkit: fix FEC enabling PHY clock

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

ARM: 7441/1: perf: return -EOPNOTSUPP if requested mode exclusion is unavailable

We currently return -EPERM if the user requests mode exclusion that is
not supported by the CPU. This looks pretty confusing from userspace
and is inconsistent with other architectures (ppc, x86).

This patch returns -EOPNOTSUPP instead.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7443/1: Revert "new way of handling ERESTART_RESTARTBLOCK"

This reverts commit 6b5c8045ecc7e726cdaa2a9d9c8e5008050e1252.

Conflicts:

arch/arm/kernel/ptrace.c

The new syscall restarting code can lead to problems if we take an
interrupt in userspace just before restarting the svc instruction. If
a signal is delivered when returning from the interrupt, the
TIF_SYSCALL_RESTARTSYS will remain set and cause any syscalls executed
from the signal handler to be treated as a restart of the previously
interrupted system call. This includes the final sigreturn call, meaning
that we may fail to exit from the signal context. Furthermore, if a
system call made from the signal handler requires a restart via the
restart_block, it is possible to clear the thread flag and fail to
restart the originally interrupted system call.

The right solution to this problem is to perform the restarting in the
kernel, avoiding the possibility of handling a further signal before the
restart is complete. Since we're almost at -rc6, let's revert the new
method for now and aim for in-kernel restarting at a later date.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7442/1: Revert "remove unused restart trampoline"

This reverts commit fa18484d0947b976a769d15c83c50617493c81c1.

We need the restart trampoline back so that we can revert a related
problematic patch 6b5c8045ecc7e726cdaa2a9d9c8e5008050e1252 ("arm: new
way of handling ERESTART_RESTARTBLOCK").

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: fix set_domain() macro

Avoid polluting drivers with a set_domain() macro, which interferes with
structure member names:

drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c:294:33: error: macro "set_domain" passed 2 arguments, but takes just 1

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

aio: make kiocb->private NUll in init_sync_kiocb()

Ocfs2 uses kiocb.*private as a flag of unsigned long size. In
commit a11f7e6 ocfs2: serialize unaligned aio, the unaligned
io flag is involved in it to serialize the unaligned aio. As
*private is not initialized in init_sync_kiocb() of do_sync_write(),
this unaligned io flag may be unexpectly set in an aligned dio.
And this will cause OCFS2_I(inode)->ip_unaligned_aio decreased
to -1 in ocfs2_dio_end_io(), thus the following unaligned dio
will hang forever at ocfs2_aiodio_wait() in ocfs2_file_aio_write().

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: stable@vger.kernel.org
Acked-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Joel Becker <jlbec@evilplan.org>

Merge tag 'omap-fixes-b-for-3.5rc' of git://git./linux/kernel/git/pjw/omap-pending into fixes

A few more OMAP fixes for 3.5-rc.  These fix some bugs with power
management and McBSP.

ARM: apx4devkit: fix FEC enabling PHY clock

Ethernet stopped to work after mxs clk framework change.

Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

Input: request threaded-only IRQs with IRQF_ONESHOT

Since commit 1c6c69525b ("genirq: Reject bogus threaded irq requests")
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail. This patch adds the
IRQF_ONESHOT to input drivers where it is missing. Not modified by
this patch are those drivers where the requested IRQ will always be a
nested IRQ (e.g. because it's part of an MFD), since for this special
case IRQF_ONESHOT is not required to be specified when requesting the
IRQ.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

ARM: fix mach-versatile/pci.c warning

arch/arm/mach-versatile/pci.c: In function 'versatile_map_irq':
arch/arm/mach-versatile/pci.c:342: warning: unused variable 'devslot'

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

ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4

The commit 503d0ea24d1d3dd3db95e5e0edd693da7a2a23eb
  ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks

added a wrong "prcm_clk" alias for PRCM clock whereas the McBSP
driver and previous OMAPs are using "prcm_fck".

It thus lead to the following warning.

[   47.409729] omap-mcbsp: clks: could not clk_get() prcm_fck

Fix that by changing the opt_clk role to prcm_fck.

Reported-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Sebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: temporarily comment out data for the usb_host_fs and aess IP blocks

The OMAP4 usb_host_fs (OHCI) and AESS IP blocks require some special
programming for them to enter idle.  Without this programming, they
will prevent the rest of the chip from entering full chip idle.

To implement the idle programming cleanly, this will take some
coordination between maintainers.  This is likely to take some time,
so it is probably best to leave this for 3.6 or 3.7.  So, in the
meantime, prevent these IP blocks from being registered.

Later, once the appropriate support is available, this patch can be
reverted.

This second version comments out the IP block data since Benoît didn't
like removing it.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Merge branch 'fixes' of git://github.com/hzhuang1/linux into fixes

From Haojian Zhuang <haojian.zhuang@gmail.com>:

* 'fixes' of git://github.com/hzhuang1/linux:
  ARM: mmp: remove mach/gpio-pxa.h

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'v3.5-imx-fixes' of git://git.pengutronix.de/git/imx/linux-2.6 into fixes

From Sascha Hauer <s.hauer@pengutronix.de>:

ARM i.MX fixes for v3.5-rc5

* tag 'v3.5-imx-fixes' of git://git.pengutronix.de/git/imx/linux-2.6:
  ARM: imx: assert SCC gate stays enabled
  ARM: imx27_visstrim_m10: Do not include <asm/system.h>

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

rpmsg: make sure inflight messages don't invoke just-removed callbacks

When inbound messages arrive, rpmsg core looks up their associated
endpoint (by destination address) and then invokes their callback.

We've made sure that endpoints will never be de-allocated after they
were found by rpmsg core, but we also need to protect against the
(rare) scenario where the rpmsg driver was just removed, and its
callback function isn't available anymore.

This is achieved by introducing a callback mutex, which must be taken
before the callback is invoked, and, obviously, before it is removed.

Cc: stable <stable@vger.kernel.org>
Reported-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>