This (trivial) patch:
 1. Deletes several useless header inclusions.
 2. Kernel codes should always include <linux/acpi.h> instead of
    <acpi/acpi_bus.h> or <acpi/acpi_drivers.h> where many conditional
    declarations are handled.
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 (trivial) patch.
 1. Changes dynamic mutex initialization to static initialization.
 2. Removes one acpi_ipmi_init() variable initialization as it is not
    needed.
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 (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>

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>

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>

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>

According to Designware I2C spec, if I2C_DYNAMIC_TAR_UPDATE is set to 1,
the 10-bit addressing mode is controlled by IC_10BITADDR_MASTER bit of
IC_TAR register instead of IC_CON register. The IC_10BITADDR_MASTER
in IC_CON register becomes read-only copy. Since I2C_DYNAMIC_TAR_UPDATE
value can't be detected from hardware register, so we will always set the
IC_10BITADDR_MASTER bit in both IC_CON and IC_TAR register whenever 10-bit
addresing mode is requested by user application.
Signed-off-by: NChew, Chiau Ee <chiau.ee.chew@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The driver is used on PowerPC which don't provide writel_relaxed(). This
breaks the c2k and prpmc2800 default configurations. To fix the build,
turn the calls to writel_relaxed() into writel(). The impacts for ARM
should be minimal.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Some functions and variables are only used if the configuration selects
HAVE_CLK. Protect them with a corresponding #ifdef CONFIG_HAVE_CLK block
to avoid compiler warnings.
Signed-off-by: NThierry Reding <treding@nvidia.com>
[wsa: added marker to #endif]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

commit d16933b3 "i2c: s3c2410: Move
location of clk_prepare_enable() call in probe function" refactored
clk_enable and clk_disable calls yet neglected to remove the
clk_disable_unprepare call in the module's remove().

It helps remove warnings on an arndale during unbind:

echo 12c90000.i2c > /sys/bus/platform/devices/12c90000.i2c/driver/unbind

------------[ cut here ]------------
WARNING: CPU: 0 PID: 2548 at drivers/clk/clk.c:842 clk_disable+0x18/0x24()
Modules linked in:
CPU: 0 PID: 2548 Comm: bash Not tainted 3.11.0-next-20130916-00003-gf4bddbc #6
[<c0014d48>] (unwind_backtrace+0x0/0xf8) from [<c00117d0>] (show_stack+0x10/0x14)
[<c00117d0>] (show_stack+0x10/0x14) from [<c0361be8>] (dump_stack+0x6c/0xac)
[<c0361be8>] (dump_stack+0x6c/0xac) from [<c001d864>] (warn_slowpath_common+0x64/0x88)
[<c001d864>] (warn_slowpath_common+0x64/0x88) from [<c001d8a4>] (warn_slowpath_null+0x1c/0x24)
[<c001d8a4>] (warn_slowpath_null+0x1c/0x24) from [<c02c4a64>] (clk_disable+0x18/0x24)
[<c02c4a64>] (clk_disable+0x18/0x24) from [<c028d0b0>] (s3c24xx_i2c_remove+0x28/0x70)
[<c028d0b0>] (s3c24xx_i2c_remove+0x28/0x70) from [<c0217a10>] (platform_drv_remove+0x18/0x1c)
[<c0217a10>] (platform_drv_remove+0x18/0x1c) from [<c0216358>] (__device_release_driver+0x58/0xb4)
[<c0216358>] (__device_release_driver+0x58/0xb4) from [<c02163d0>] (device_release_driver+0x1c/0x28)
[<c02163d0>] (device_release_driver+0x1c/0x28) from [<c02153c0>] (unbind_store+0x58/0x90)
[<c02153c0>] (unbind_store+0x58/0x90) from [<c0214c90>] (drv_attr_store+0x20/0x2c)
[<c0214c90>] (drv_attr_store+0x20/0x2c) from [<c01032c0>] (sysfs_write_file+0x168/0x198)
[<c01032c0>] (sysfs_write_file+0x168/0x198) from [<c00ae1c0>] (vfs_write+0xb0/0x194)
[<c00ae1c0>] (vfs_write+0xb0/0x194) from [<c00ae594>] (SyS_write+0x3c/0x70)
[<c00ae594>] (SyS_write+0x3c/0x70) from [<c000e3e0>] (ret_fast_syscall+0x0/0x30)
---[ end trace 4c9f9403066f57a6 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2548 at drivers/clk/clk.c:751 clk_unprepare+0x14/0x1c()
Modules linked in:
CPU: 0 PID: 2548 Comm: bash Tainted: G        W    3.11.0-next-20130916-00003-gf4bddbc #6
[<c0014d48>] (unwind_backtrace+0x0/0xf8) from [<c00117d0>] (show_stack+0x10/0x14)
[<c00117d0>] (show_stack+0x10/0x14) from [<c0361be8>] (dump_stack+0x6c/0xac)
[<c0361be8>] (dump_stack+0x6c/0xac) from [<c001d864>] (warn_slowpath_common+0x64/0x88)
[<c001d864>] (warn_slowpath_common+0x64/0x88) from [<c001d8a4>] (warn_slowpath_null+0x1c/0x24)
[<c001d8a4>] (warn_slowpath_null+0x1c/0x24) from [<c02c5834>] (clk_unprepare+0x14/0x1c)
[<c02c5834>] (clk_unprepare+0x14/0x1c) from [<c028d0b8>] (s3c24xx_i2c_remove+0x30/0x70)
[<c028d0b8>] (s3c24xx_i2c_remove+0x30/0x70) from [<c0217a10>] (platform_drv_remove+0x18/0x1c)
[<c0217a10>] (platform_drv_remove+0x18/0x1c) from [<c0216358>] (__device_release_driver+0x58/0xb4)
[<c0216358>] (__device_release_driver+0x58/0xb4) from [<c02163d0>] (device_release_driver+0x1c/0x28)
[<c02163d0>] (device_release_driver+0x1c/0x28) from [<c02153c0>] (unbind_store+0x58/0x90)
[<c02153c0>] (unbind_store+0x58/0x90) from [<c0214c90>] (drv_attr_store+0x20/0x2c)
[<c0214c90>] (drv_attr_store+0x20/0x2c) from [<c01032c0>] (sysfs_write_file+0x168/0x198)
[<c01032c0>] (sysfs_write_file+0x168/0x198) from [<c00ae1c0>] (vfs_write+0xb0/0x194)
[<c00ae1c0>] (vfs_write+0xb0/0x194) from [<c00ae594>] (SyS_write+0x3c/0x70)
[<c00ae594>] (SyS_write+0x3c/0x70) from [<c000e3e0>] (ret_fast_syscall+0x0/0x30)
---[ end trace 4c9f9403066f57a7 ]---
Signed-off-by: NKim Phillips <kim.phillips@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The DLink DWA-125 Rev D1 also uses this driver.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Reported-by: NSergey Kostanbaev <sergey.kostanbaev@gmail.com>
Tested-by: NSergey Kostanbaev <sergey.kostanbaev@gmail.com>
Cc: Sergey Kostanbaev <sergey.kostanbaev@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add PCI id for Intel Merrifield
Signed-off-by: NDavid Cohen <david.a.cohen@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In case of usb phy reinitialization:
e.g. insmod usb-module(usb works well) -> rmmod usb-module -> insmod usb-module
It found the PHY_CLK_VALID bit didn't work if it's not with the power-on reset.
So we just check PHY_CLK_VALID bit during the stage with POR, this can be met
by the tricky of checking FSL_SOC_USB_PRICTRL register.
Signed-off-by: NShengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

	There's a bunch of failure exits in ffs_fs_mount() with
seriously broken recovery logics.  Most of that appears to stem
from misunderstanding of the ->kill_sb() semantics; unlike
->put_super() it is called for *all* superblocks of given type,
no matter how (in)complete the setup had been.  ->put_super()
is called only if ->s_root is not NULL; any failure prior to
setting ->s_root will have the call of ->put_super() skipped.
->kill_sb(), OTOH, awaits every superblock that has come from
sget().

Current behaviour of ffs_fs_mount():

We have struct ffs_sb_fill_data data on stack there.  We do
	ffs_dev = functionfs_acquire_dev_callback(dev_name);
and store that in data.private_data.  Then we call mount_nodev(),
passing it ffs_sb_fill() as a callback.  That will either fail
outright, or manage to call ffs_sb_fill().  There we allocate an
instance of struct ffs_data, slap the value of ffs_dev (picked
from data.private_data) into ffs->private_data and overwrite
data.private_data by storing ffs into an overlapping member
(data.ffs_data).  Then we store ffs into sb->s_fs_info and attempt
to set the rest of the things up (root inode, root dentry, then
create /ep0 there).  Any of those might fail.  Should that
happen, we get ffs_fs_kill_sb() called before mount_nodev()
returns.  If mount_nodev() fails for any reason whatsoever,
we proceed to
	functionfs_release_dev_callback(data.ffs_data);

That's broken in a lot of ways.  Suppose the thing has failed in
allocation of e.g. root inode or dentry.  We have
	functionfs_release_dev_callback(ffs);
	ffs_data_put(ffs);
done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by
	functionfs_release_dev_callback(ffs);
from ffs_fs_mount() (via data.ffs_data).  Note that the second
functionfs_release_dev_callback() has every chance to be done to freed memory.

Suppose we fail *before* root inode allocation.  What happens then?
ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all,
or it doesn't have a pointer to ffs stored in sb->s_fs_info).  And
	functionfs_release_dev_callback(data.ffs_data);
is called by ffs_fs_mount(), but here we are in nasal daemon country - we
are reading from a member of union we'd never stored into.  In practice,
we'll get what we used to store into the overlapping field, i.e. ffs_dev.
And then we get screwed, since we treat it (struct gfs_ffs_obj * in
disguise, returned by functionfs_acquire_dev_callback()) as struct
ffs_data *, pick what would've been ffs_data ->private_data from it
(*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data
is much bigger) and poke in whatever it points to.

FWIW, there's a minor leak on top of all that in case if ffs_sb_fill()
fails on kstrdup() - ffs is obviously forgotten.

The thing is, there is no point in playing all those games with union.
Just allocate and initialize ffs_data *before* calling mount_nodev() and
pass a pointer to it via data.ffs_data.  And once it's stored in
sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that
it doesn't need to kill the sucker manually - from that point on
we'll have it done by ->kill_sb().
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Cc: stable <stable@vger.kernel.org> # 3.3+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The put_device(dev) at the bottom of the loop of device_shutdown
may result in the dev being cleaned up. In device_create_release,
the dev is kfreed.

However, device_shutdown attempts to use the dev pointer again after
put_device by referring to dev->parent.

Copy the parent pointer instead to avoid this condition.

This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11.
See bug report : https://code.google.com/p/chromium/issues/detail?id=297842
This can easily be reproduced when shutting down with
hidraw devices that report battery condition.
Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse.
For example, with the magic mouse :
The dev in question is "hidraw0"
dev->parent is "magicmouse"

In the course of the shutdown for this device, the input event cleanup calls
a put on hidraw0, decrementing its reference count.
When we finally get to put_device(dev) in device_shutdown, kobject_cleanup
is called and device_create_release does kfree(dev).
dev->parent is no longer valid, and we may crash in
put_device(dev->parent).

This change should be applied on any kernel with this change :
d1c6c030

Cc: stable@vger.kernel.org
Signed-off-by: NBenson Leung <bleung@chromium.org>
Reviewed-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 666b9adc terminated vmbus
version negotiation incorrectly. We need to terminate the version
negotiation only if the current negotiation were to timeout.
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Cc: Olaf Hering <ohering@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current code does not correctly negotiate the version numbers for the util
driver when hosted on earlier hosts. The version numbers presented by this
driver were not compatible with the version numbers supported by Windows Server
2008. Fix this problem.

I would like to thank Olaf Hering (ohering@suse.com) for identifying the problem.
Reported-by: NOlaf Hering <ohering@suse.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Unset init_clients_timer and amthif_stall_timers
in mei_reset in order to cancel timer ticking and hence
avoid recursive reset calls.

Cc:  <stable@vger.kernel.org> # 3.9+
Signed-off-by: NAlexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Bus layer omitted check for client state transition while waiting
for read completion
The client state transition may occur for example as result
of firmware initiated reset

Add mei_cl_is_transitioning wrapper to reduce the code
repetition.:

Cc:  <stable@vger.kernel.org> # 3.9+
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

1. u8 counters are prone to hard to detect overflow:
 make them unsigned long to match bit_ functions argument type

2. don't check me_clients_num for negativity, it is unsigned.

3. init all the me client counters from one place

Cc:  <stable@vger.kernel.org> # 3.9+
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For controller versions greater than 1.6, setting ULPI_PHY_CLK_SEL
bit when USB_EN bit is already set causes instability issues with
PHY_CLK_VLD bit. So USB_EN is set only for IP controller version
below 1.6 before setting ULPI_PHY_CLK_SEL bit
Signed-off-by: NRamneek Mehresh <ramneek.mehresh@freescale.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add missing break into the restore function.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

After reports from Chris and Josh Boyer of a rare crash in applesmc,
Guenter pointed at the initialization problem fixed below. The patch
has not been verified to fix the crash, but should be applied
regardless.

Reported-by: <jwboyer@fedoraproject.org>
Suggested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Cc: stable@vger.kernel.org
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

of_get_display_timing(s) use of_find_node_by_name
to get child node, this is incorrect, of_get_child_by_name
should be used instead. The patch fixes it.
Small typo is also corrected.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Fix to return -EINVAL when virtual vertical size smaller than real
instead of 0, as done elsewhere in this function. Also remove dup code.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The nice thing about devm_* is that the driver doesn't need to free the
resources but the driver core takes care about that. This also
simplifies the error path quite a bit and removes the wrong check for a
clock pointer being NULL.

Russell King - ARM Linux <linux@arm.linux.org.uk>:
"And this patch also fixes the above: disabling/unpreparing _after_ putting
the thing - which was quite silly... :)"
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The DSI-CM driver uses the backlight class so needs to build depend on it.
Signed-off-by: NMark Brown <broonie@linaro.org>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Commit 'e7f3880c'
  tty: Fix recursive deadlock in tty_perform_flush()
introduced a regression where tcflush() does not generate
SIGTTOU for background process groups.

Make sure ioctl(TCFLSH) calls tty_check_change() when
invoked from the line discipline.

Cc: stable@vger.kernel.org # v3.10+
Reported-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Update the STI driver by setting cpu_possible_mask to make EMEV2
SMP work as expected together with the ARM broadcast timer.

This breakage was introduced by:

f7db706b ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event

Without this fix SMP operation is broken on EMEV2 since no
broadcast timer interrupts trigger on the secondary CPU cores.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Tested-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).

The reason is a USB control message
 usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.

The kernel thus rejects the IO and thus we see the failure.

Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.

It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to.  The device seems to happily deal with that though (and
seems to not really care about this value much).

So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.

The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)

With attached patch, the app in Windows in KVM works.
 usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81

I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].

[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/Signed-off-by: NKurt Garloff <kurt@garloff.de>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>