This (trivial) patch:
 1. Deletes a member of the acpi_ipmi_device, smi_data, which is not
    actually used.
 2. Updates a member of the acpi_ipmi_device, pnp_dev, which is only used
    by dev_warn() invocations, so changes it to a struct device.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch adds reference counting for ACPI IPMI transfers to tune the
locking granularity of tx_msg_lock.

This patch also makes the whole acpi_ipmi module's coding style consistent
by using reference counting for all its objects (i.e., acpi_ipmi_device and
acpi_ipmi_msg).

The acpi_ipmi_msg handling is re-designed using referece counting.
 1. tx_msg is always unlinked before complete(), so that it is safe to put
    complete() out side of tx_msg_lock.
 2. tx_msg reference counters are incremented before calling
    ipmi_request_settime() and tx_msg_lock protection is added to
    ipmi_cancel_tx_msg() so that a complete() can be safely called in
    parellel with tx_msg unlinking in failure cases.
 3. tx_msg holds a reference to acpi_ipmi_device so that it can be flushed
    and freed in the contexts other than acpi_ipmi_space_handler().

The lockdep_chains shows all acpi_ipmi locks are leaf locks after the
tuning:
 1. ipmi_lock is always leaf:
    irq_context: 0
    [ffffffff81a943f8] smi_watchers_mutex
    [ffffffffa06eca60] driver_data.ipmi_lock
    irq_context: 0
    [ffffffff82767b40] &buffer->mutex
    [ffffffffa00a6678] s_active#103
    [ffffffffa06eca60] driver_data.ipmi_lock
 2. without this patch applied, lock used by complete() is held after
    holding tx_msg_lock:
    irq_context: 0
    [ffffffff82767b40] &buffer->mutex
    [ffffffffa00a6678] s_active#103
    [ffffffffa06ecce8] &(&ipmi_device->tx_msg_lock)->rlock
    irq_context: 1
    [ffffffffa06ecce8] &(&ipmi_device->tx_msg_lock)->rlock
    irq_context: 1
    [ffffffffa06ecce8] &(&ipmi_device->tx_msg_lock)->rlock
    [ffffffffa06eccf0] &x->wait#25
    irq_context: 1
    [ffffffffa06ecce8] &(&ipmi_device->tx_msg_lock)->rlock
    [ffffffffa06eccf0] &x->wait#25
    [ffffffff81e36620] &p->pi_lock
    irq_context: 1
    [ffffffffa06ecce8] &(&ipmi_device->tx_msg_lock)->rlock
    [ffffffffa06eccf0] &x->wait#25
    [ffffffff81e36620] &p->pi_lock
    [ffffffff81e5d0a8] &rq->lock
 3. with this patch applied, tx_msg_lock is always leaf:
    irq_context: 0
    [ffffffff82767b40] &buffer->mutex
    [ffffffffa00a66d8] s_active#107
    [ffffffffa07ecdc8] &(&ipmi_device->tx_msg_lock)->rlock
    irq_context: 1
    [ffffffffa07ecdc8] &(&ipmi_device->tx_msg_lock)->rlock
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
  Device (PMI0)
  {
      Name (_HID, "ACPI000D")  // _HID: Hardware ID
      OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
      Field (SYSI, BufferAcc, Lock, Preserve)
      {
          AccessAs (BufferAcc, 0x01),
          Offset (0x58),
          SCMD,   8,
          GCMD,   8
      }

      OperationRegion (POWR, IPMI, 0x3000, 0x0100)
      Field (POWR, BufferAcc, Lock, Preserve)
      {
          AccessAs (BufferAcc, 0x01),
          Offset (0xB3),
          GPMM,   8
      }
  }

  Device (PCI0)
  {
      Device (ISA)
      {
          Device (NIPM)
          {
              Name (_HID, EisaId ("IPI0001"))  // _HID: Hardware ID
              Method (_IFT, 0, NotSerialized)  // _IFT: IPMI Interface Type
              {
                  Return (0x01)
              }
          }
      }
  }

Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM.  Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
  ACPI Error: No handlers for Region [IPMI]
  ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.

When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS.  The patch tries to select one system interface by
monitoring the system interface notification.  IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.

The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace).  It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:

  A BMC device may make available multiple system interfaces, but only one
  management controller is allowed to be 'active' BMC that provides BMC
  functionality for the system (in case of a 'partitioned' system, there
  can be only one active BMC per partition).  Only the system interface(s)
  for the active BMC allowed to respond to the 'Get Device Id' command.

According to the ipmi_si desigin:

  The ipmi_si registeration notifications can only happen after a
  successful "Get Device ID" command.

Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.

References: https://bugzilla.kernel.org/show_bug.cgi?id=46741Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch uses reference counting to fix the race caused by the
unprotected ACPI IPMI user.

There are two rules for using the ipmi_si APIs:
 1. In ipmi_si, ipmi_destroy_user() can ensure that no ipmi_recv_msg will
    be passed to ipmi_msg_handler(), but ipmi_request_settime() can not
    use an invalid ipmi_user_t.  This means the ipmi_si users must ensure
    that there won't be any local references on ipmi_user_t before invoking
    ipmi_destroy_user().
 2. In ipmi_si, the smi_gone()/new_smi() callbacks are protected by
    smi_watchers_mutex, so their execution is serialized.  But as a
    new smi can re-use a freed intf_num, it requires that the callback
    implementation must not use intf_num as an identification mean or it
    must ensure all references to the previous smi are all dropped before
    exiting smi_gone() callback.

As the acpi_ipmi_device->user_interface check in acpi_ipmi_space_handler()
can happen before setting user_interface to NULL and codes after the check
in acpi_ipmi_space_handler() can happen after user_interface becomes NULL,
the on-going acpi_ipmi_space_handler() still can pass an invalid
acpi_ipmi_device->user_interface to ipmi_request_settime().  Such race
conditions are not allowed by the IPMI layer's API design as a crash will
happen in ipmi_request_settime() if something like that happens.

This patch follows the ipmi_devintf.c design:
 1. Invoke ipmi_destroy_user() after the reference count of
    acpi_ipmi_device drops to 0.  References of acpi_ipmi_device dropping
    to 0 also means tx_msg related to this acpi_ipmi_device are all freed.
    This matches the IPMI layer's API calling rule on ipmi_destroy_user()
    and ipmi_request_settime().
 2. ipmi_flush_tx_msg() is performed so that no on-going tx_msg can still be
    running in acpi_ipmi_space_handler().  And it is invoked after invoking
    __ipmi_dev_kill() where acpi_ipmi_device is deleted from the list with a
    "dead" flag set, and the "dead" flag check is also introduced to the
    point where a tx_msg is going to be added to the tx_msg_list so that no
    new tx_msg can be created after returning from the __ipmi_dev_kill().
 3. The waiting codes in ipmi_flush_tx_msg() is deleted because it is not
    required since this patch ensures no acpi_ipmi reference is still held
    for ipmi_user_t before calling ipmi_destroy_user() and
    ipmi_destroy_user() can ensure no more ipmi_msg_handler() can happen
    after returning from ipmi_destroy_user().
 4. The flushing of tx_msg is also moved out of ipmi_lock in this patch.

The forthcoming IPMI operation region handler installation changes also
requires acpi_ipmi_device be handled in this style.

The header comment of the file is also updated due to this design change.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch fixes races caused by timed out ACPI IPMI transfers.

This patch uses timeout mechanism provided by ipmi_si to avoid the race
that the msg_done flag is set but without any protection, its content can
be invalid.  Thanks for the suggestion of Corey Minyard.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch fixes races caused by unprotected ACPI IPMI transfers.

We can see that the following crashes may occur:
 1. There is no tx_msg_lock held for iterating tx_msg_list in
    ipmi_flush_tx_msg() while it may be unlinked on failure in
    parallel in acpi_ipmi_space_handler() under tx_msg_lock.
 2. There is no lock held for freeing tx_msg in acpi_ipmi_space_handler()
    while it may be accessed in parallel in ipmi_flush_tx_msg() and
    ipmi_msg_handler().

This patch enhances tx_msg_lock to protect all tx_msg accesses to solve
this issue.  Then tx_msg_lock is always held around complete() and tx_msg
accesses.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch enhances sanity checks on message size to avoid potential buffer
overflow.

The kernel IPMI message size is IPMI_MAX_MSG_LENGTH(272 bytes) while the
ACPI specification defined IPMI message size is 64 bytes.  The difference
is not handled by the original codes.  This may cause crash in the response
handling codes.

This patch closes this gap and also combines rx_data/tx_data to use single
data/len pair since they need not be seperate.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull USB fixes from Greg KH:
 "Here are a number of USB driver fixes for 3.12-rc3.

  These are all for host controller issues that have been reported, and
  there's a fix for an annoying error message that gets printed every
  time you remove a USB 3 device from the system that's been bugging me
  for a while"

* tag 'usb-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  usb: dwc3: add support for Merrifield
  USB: fsl/ehci: fix failure of checking PHY_CLK_VALID during reinitialization
  USB: Fix breakage in ffs_fs_mount()
  fsl/usb: Resolve PHY_CLK_VLD instability issue for ULPI phy
  usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit
  usb: chipidea: USB_CHIPIDEA should depend on HAS_DMA
  usb: chipidea: udc: free pending TD at removal procedure
  usb: chipidea: imx: Add usb_phy_shutdown at probe's error path
  usb: chipidea: Fix memleak for ci->hw_bank.regmap when removal
  usb: chipidea: udc: fix the oops after rmmod gadget
  USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd
  USB: OHCI: accept very late isochronous URBs
  USB: UHCI: accept very late isochronous URBs
  USB: iMX21: accept very late isochronous URBs
  usbcore: check usb device's state before sending a Set SEL control transfer
  xhci: Fix race between ep halt and URB cancellation
  usb: Fix xHCI host issues on remote wakeup.
  xhci: Ensure a command structure points to the correct trb on the command ring
  xhci: Fix oops happening after address device timeout

Pull tty/serial fixes from Greg KH:
 "Here are some serial at tty driver fixes for 3.12-rc3

  The serial driver fixes some kref leaks, documentation is moved to the
  proper places, and the tty and n_tty fixes resolve some reported
  regressions.  There is still one outstanding tty regression fix that
  isn't in here yet, as I want to test it out some more, it will be sent
  for 3.12-rc4 if it checks out"

* tag 'tty-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  tty: ar933x_uart: move devicetree binding documentation
  tty: Fix SIGTTOU not sent with tcflush()
  n_tty: Fix EOF push index when termios changes
  serial: pch_uart: remove unnecessary tty_port_tty_get
  serial: pch_uart: fix tty-kref leak in dma-rx path
  serial: pch_uart: fix tty-kref leak in rx-error path
  serial: tegra: fix tty-kref leak

Pull staging fixes from Greg KH:
 "Here are some staging driver fixes, MAINTAINER updates, and a new
  device id.  All of these have been in the linux-next tree, and are
  pretty simple patches"

* tag 'staging-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: r8188eu: Add new device ID
  staging: imx-drm: Fix probe failure
  staging: vt6656: [BUG] iwctl_siwencodeext return if device not open
  staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier.
  staging: vt6656: rxtx.c [BUG] s_vGetFreeContext dead lock on null apTD.
  Staging: rtl8192u: r819xU_cmdpkt: checking NULL value after doing dev_alloc_skb
  staging: usbip: Orphan usbip
  staging: r8188eu: Add files for new drive: Cocci spatch "noderef"
  staging: r8188eu: Cocci spatch "noderef"
  staging: octeon-usb: Cocci spatch "noderef"
  staging: r8188eu: Add files for new drive: Cocci spatch "noderef"
  MAINTAINERS: staging: dgnc and dgap drivers: add maintainer
  staging: lustre: Cocci spatch "noderef"

Merge tag 'driver-core-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core / sysfs fixes from Greg KH:
 "Here are 2 fixes for 3.12-rc3.  One fixes a sysfs problem with
  mounting caused by 3.12-rc1, and the other is a bug reported by the
  chromeos developers with the driver core.

  Both have been in linux-next for a bit"

* tag 'driver-core-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  driver core : Fix use after free of dev->parent in device_shutdown
  sysfs: Allow mounting without CONFIG_NET

Pull char/misc driver fixes from Greg KH:
 "Here are some HyperV and MEI driver fixes for 3.12-rc3.  They resolve
  some issues that people have been reporting for them"

* tag 'char-misc-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  Drivers: hv: vmbus: Terminate vmbus version negotiation on timeout
  Drivers: hv: util: Correctly support ws2008R2 and earlier
  mei: cancel stall timers in mei_reset
  mei: bus: stop wait for read during cl state transition
  mei: make me client counters less error prone

Pull perf revert from Ingo Molnar:
 "This fixes the 'perf top' regression Markus Trippelsdorf reported"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  Revert "perf symbols: Demangle cloned functions"

Pull drm fixes from Dave Airlie:
 "Nothing too major, radeon still has some dpm changes for off by
  default.

  Radeon, intel, msm:
   - radeon: a few more dpm fixes (still off by default), uvd fixes
   - i915: runtime warn backtrace and regression fix
   - msm: iommu changes fallout"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (27 commits)
  drm/msm: use drm_gem_dumb_destroy helper
  drm/msm: deal with mach/iommu.h removal
  drm/msm: Remove iommu include from mdp4_kms.c
  drm/msm: Odd PTR_ERR usage
  drm/i915: Fix up usage of SHRINK_STOP
  drm/radeon: fix hdmi audio on DCE3.0/3.1 asics
  drm/i915: preserve pipe A quirk in i9xx_set_pipeconf
  drm/i915/tv: clear adjusted_mode.flags
  drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER
  drm/radeon/cik: fix overflow in vram fetch
  drm/radeon: add missing hdmi callbacks for rv6xx
  drm/i915: Use a temporary va_list for two-pass string handling
  drm/radeon/uvd: lower msg&fb buffer requirements on UVD3
  drm/radeon: disable tests/benchmarks if accel is disabled
  drm/radeon: don't set default clocks for SI when DPM is disabled
  drm/radeon/dpm/ci: filter clocks based on voltage/clk dep tables
  drm/radeon/dpm/si: filter clocks based on voltage/clk dep tables
  drm/radeon/dpm/ni: filter clocks based on voltage/clk dep tables
  drm/radeon/dpm/btc: filter clocks based on voltage/clk dep tables
  drm/radeon/dpm: fetch the max clk from voltage dep tables helper
  ...

This reverts commit de95ab53.

Markus Trippelsdorf reported that this commit broke 'perf top':

 > I just see a gray screen with no text at all. Sometimes the
 > following error messages are printed:
 >
 >  *** Error in `perf': invalid fastbin entry (free): 0x00000000029b18c0
 >  ***
 >  *** Error in `perf': malloc(): memory corruption (fast): 0x0000000000ee0b10 ***

While this code is fixable, the commit itself fails on several levels:

 - it should have been a separate helper function
 - why the heck does it do strchr() twice
 - it casts a const char * over into char *
 - sloppy style
 - it's not even a regression fix!

So lets revert it and re-try the patch in v3.13.
Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>

A small fix + deal with fallout of iommu changes + use new
drm_gem_dumb_destroy helper.

* 'msm-fixes-3.12-rc2' of git://people.freedesktop.org/~robclark/linux:
  drm/msm: use drm_gem_dumb_destroy helper
  drm/msm: deal with mach/iommu.h removal
  drm/msm: Remove iommu include from mdp4_kms.c
  drm/msm: Odd PTR_ERR usage

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

Pull scheduler, timer and x86 fixes from Ingo Molnar:
 - A context tracking ARM build and functional fix
 - A handful of ARM clocksource/clockevent driver fixes
 - An AMD microcode patch level sysfs reporting fixlet

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  arm: Fix build error with context tracking calls

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clocksource: em_sti: Set cpu_possible_mask to fix SMP broadcast
  clocksource: of: Respect device tree node status
  clocksource: exynos_mct: Set IRQ affinity when the CPU goes online
  arm: clocksource: mvebu: Use the main timer as clock source from DT

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/microcode/AMD: Fix patch level reporting for family 15h

Pull perf fixes from Ingo Molnar:
 "A couple of tooling fixlets and a PMU detection printout fix"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86: Fix PMU detection printout when no PMU is detected
  perf symbols: Demangle cloned functions
  perf machine: Fix path unpopulated in machine__create_modules()
  perf tools: Explicitly add libdl dependency
  perf probe: Fix probing symbols with optimization suffix
  perf trace: Add mmap2 handler
  perf kmem: Make it work again on non NUMA machines

Pull xfs bugfixes from Ben Myers:
 - fix for directory node collapse regression
 - fix for recovery over stale on disk structures
 - fix for eofblocks ioctl
 - fix asserts in xfs_inode_free
 - lock the ail before removing an item from it

* tag 'xfs-for-linus-v3.12-rc3' of git://oss.sgi.com/xfs/xfs:
  xfs: fix node forward in xfs_node_toosmall
  xfs: log recovery lsn ordering needs uuid check
  xfs: fix XFS_IOC_FREE_EOFBLOCKS definition
  xfs: asserting lock not held during freeing not valid
  xfs: lock the AIL before removing the buffer item

Pull i2c fixes from Wolfram Sang:
 "Some driver bugfixes for the I2C subsystem"

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: ismt: initialize DMA buffer
  i2c: designware: 10-bit addressing mode enabling if I2C_DYNAMIC_TAR_UPDATE is set
  i2c: mv64xxx: Do not use writel_relaxed()
  i2c: mv64xxx: Fix some build warnings
  i2c: s3c2410: fix clk_disable/clk_unprepare WARNings

Pull ACPI and power management fixes from Rafael Wysocki:
 "These fix one recent cpufreq regression, a few older bugs that may
  harm users and a kerneldoc typo.

  Specifics:

   1) After the recent locking changes in the cpufreq core it is
      possible to trigger BUG_ON(!policy) in lock_policy_rwsem_read() if
      cpufreq_get() is called before registering a cpufreq driver.  Fix
      from Viresh Kumar.

   2) If intel_pstate has been loaded already, it doesn't make sense to
      do anything in acpi_cpufreq_init() and moreover doing something in
      there in that case may be harmful, so make that function return
      immediately if another cpufreq driver is already present.  From
      Yinghai Lu.

   3) The ACPI IPMI driver sometimes attempts to acquire a mutex from
      interrupt context, which can be avoided by replacing that mutex
      with a spinlock.  From Lv Zheng.

   4) A NULL pointer may be dereferenced by the exynos5440 cpufreq
      driver if a memory allocation made by it fails.  Fix from Sachin
      Kamat.

   5) Hanjun Guo's commit fixes a typo in the kerneldoc comment
      documenting acpi_bus_unregister_driver()"

* tag 'pm+acpi-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / scan: fix typo in comments of acpi_bus_unregister_driver()
  cpufreq: exynos5440: Fix potential NULL pointer dereference
  cpufreq: check cpufreq driver is valid and cpufreq isn't disabled in cpufreq_get()
  acpi-cpufreq: skip loading acpi_cpufreq after intel_pstate
  ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()

Ben Herrenschmidt found that commit 928bea96 ("PCI: Delay enabling
bridges until they're needed") breaks PCI in some powerpc environments.

The reason is that the PCIe port driver will call pci_enable_device() on
the bridge, so the device is enabled, but skips pci_set_master because
pcie_port_auto and no acpi on powerpc.

Because of that, pci_enable_bridge() later on (called as a result of the
child device driver doing pci_enable_device) will see the bridge as
already enabled and will not call pci_set_master() on it.

Fixed by add checking in pci_enable_bridge, and call pci_set_master
if driver skip that.

That will make the code more robot and wade off problem for missing
pci_set_master in drivers.
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull s390 lockref enablement from Heiko Carstens:
 "Enabling the new lockless lockref variant on s390 would have been
  trivial until Tony Luck added a cpu_relax() call into the
  CMPXCHG_LOOP(), with commit d472d9d9 ("lockref: Relax in cmpxchg
  loop")

  As already mentioned cpu_relax() is very expensive on s390 since it
  yields() the current virtual cpu.  So we are talking of several
  thousand cycles.  Considering this enabling the lockless lockref
  variant would contradict the intention of the new semantics.  And also
  some quick measurements show performance regressions of 50% and more.

  Simply removing the cpu_relax() call again seems also not very
  desireable since Waiman Long reported that for some workloads the call
  improved performance by 5%."

* 'lockref' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390: enable ARCH_USE_CMPXCHG_LOCKREF
  lockref: use arch_mutex_cpu_relax() in CMPXCHG_LOOP()
  mutex: replace CONFIG_HAVE_ARCH_MUTEX_CPU_RELAX with simple ifdef

Commit 6072ddc8 ("kernel: replace strict_strto*() with kstrto*()")
broke the handling of signed integer types, fix it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Reported-by: NChristian Kujau <lists@nerdbynature.de>
Tested-by: NChristian Kujau <lists@nerdbynature.de>
Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull DeviceTree fixes from Rob Herring:
 "Clean-up to fix some warnings for !OF builds and spelling fixes in
  docs:

   - Clean-up openrisc prom.h
   - Fix warnings caused by of_irq.h ifdefs
   - Spelling fix for Synopsys"

* tag 'devicetree-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  dts: Fix misspelling of Synopsys
  of: clean-up ifdefs in of_irq.h
  openrisc: clean-up prom.h

Pull ARM fixes from Russell King:
 "Just a few relatively small ARM fixes found since the last merge
  window, nothing too exciting"

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7837/3: fix Thumb-2 bug in AES assembler code
  ARM: only allow kernel mode neon with AEABI
  ARM: 7839/1: entry: fix tracing of ARM-private syscalls
  ARM: 7836/1: add __get_user_unaligned/__put_user_unaligned

This patch adds code to initialize the DMA buffer to compensate for
possible hardware data corruption.
Signed-off-by: NJames Ralston <james.d.ralston@intel.com>
[wsa: changed to use 'sizeof']
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

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

We still need an API exported by msm iommu driver (but not visible in
any public header anymore).  For now, just declare the prototype
ourselves, but when msm iommu driver provides a better option, use that
instead.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Ran into this cryptic PMU bootup log recently:

[    0.124047] Performance Events:
[    0.125000] smpboot: ...

Turns out we print this if no PMU is detected. Fall back to
the right condition so that the following is printed:

[    0.122381] Performance Events: no PMU driver, software events only.

Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: http://lkml.kernel.org/n/tip-u2fwaUffakjp0qkpRfqljgsn@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

The include file has been removed and the file does not
need it anyway, so remove it. Fixes a compile error.
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The variable priv->kms is not initialized yet.

Found by "scripts/coccinelle/tests/odd_ptr_err.cocci".
PTR_ERR should access the value just tested by IS_ERR.
Signed-off-by: NThomas Meyer <thomas@m3y3r.de>

Enable ARCH_USE_CMPXCHG_LOCKREF since it shows performance improvements
with Linus' simple stat() test case of up to 50% on a 30 cpu system.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

Make use of arch_mutex_cpu_relax() so architectures can override the
default cpu_relax() semantics.
This is especially useful for s390, where cpu_relax() means that we
yield() the current (virtual) cpu and therefore is very expensive,
and would contradict the whole purpose of the lockless cmpxchg loop.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

Linus suggested to replace

 #ifndef CONFIG_HAVE_ARCH_MUTEX_CPU_RELAX
 #define arch_mutex_cpu_relax() cpu_relax()
 #endif

with just a simple

  #ifndef arch_mutex_cpu_relax
  # define arch_mutex_cpu_relax() cpu_relax()
  #endif

to get rid of CONFIG_HAVE_CPU_RELAX_SIMPLE. So architectures can
simply define arch_mutex_cpu_relax if they want an architecture
specific function instead of having to add a select statement in
their Kconfig in addition.
Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

Merge branch 'context_tracking/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks into sched/urgent

Pull context tracking ARM fix from Frederic Weisbecker.
Signed-off-by: NIngo Molnar <mingo@kernel.org>

More radeon fixes for 3.12.  Kind of all over the place: UVD, DPM,
tiling, etc.

* 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: fix hdmi audio on DCE3.0/3.1 asics
  drm/radeon/cik: fix overflow in vram fetch
  drm/radeon: add missing hdmi callbacks for rv6xx
  drm/radeon/uvd: lower msg&fb buffer requirements on UVD3
  drm/radeon: disable tests/benchmarks if accel is disabled
  drm/radeon: don't set default clocks for SI when DPM is disabled
  drm/radeon/dpm/ci: filter clocks based on voltage/clk dep tables
  drm/radeon/dpm/si: filter clocks based on voltage/clk dep tables
  drm/radeon/dpm/ni: filter clocks based on voltage/clk dep tables
  drm/radeon/dpm/btc: filter clocks based on voltage/clk dep tables
  drm/radeon/dpm: fetch the max clk from voltage dep tables helper
  drm/radeon: fix missed variable sized access
  drm/radeon: Make r100_cp_ring_info() and radeon_ring_gfx() safe (v2)
  drm/radeon/cik: Add tiling mode index for 1D tiled depth/stencil surfaces
  drm/radeon/cik: Fix encoding of number of banks in tiling configuration info
  drm/radeon/cik: Fix printing of client name on VM protection fault
  drm/radeon: additional gcc fixes for radeon_atombios.c
  drm/radeon: avoid UVD corruption on AGP cards using GPU gart

Merge tag 'drm-intel-fixes-2013-09-26' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Just a few fixes for regressions and other serious stuff.

Two fix state tracking mismatches, together with an additional patch that
I've submitted to stable (somehow forgotten to tag it) we should have them
fixed now (I hope).

* tag 'drm-intel-fixes-2013-09-26' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Fix up usage of SHRINK_STOP
  drm/i915: preserve pipe A quirk in i9xx_set_pipeconf
  drm/i915/tv: clear adjusted_mode.flags
  drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER
  drm/i915: Use a temporary va_list for two-pass string handling

Pull hwmon fix from Guenter Roeck:
 "Fix potential crash condition in applesmc driver"

* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (applesmc) Check key count before proceeding