commit 490d31e7a5d3074712325919ca8c2daecb69e382
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Sat Dec 6 16:06:44 2014 +0100

    Linux 3.12.35

commit 0ac8b68cefb09d4fe332b76f3171dfece2582104
Author: Cong Wang <cwang@twopensource.com>
Date:   Thu May 22 11:57:17 2014 -0700

    batman: fix a bogus warning from batadv_is_on_batman_iface()
    
    commit b6ed5498601df40489606dbc14a9c7011c16630b upstream.
    
    batman tries to search dev->iflink to check if it's a batman interface,
    but ->iflink could be 0, which is not a valid ifindex. It should just
    avoid iflink == 0 case.
    
    Reported-by: Jet Chen <jet.chen@intel.com>
    Tested-by: Jet Chen <jet.chen@intel.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Antonio Quartulli <antonio@open-mesh.com>
    Cc: Marek Lindner <mareklindner@neomailbox.ch>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Cong Wang <cwang@twopensource.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3dbce781ec9e44932b9eb441d22c2b3a3cadeac3
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Tue Oct 7 16:12:36 2014 +1100

    powerpc/powernv: Honor the generic "no_64bit_msi" flag
    
    commit 360743814c4082515581aa23ab1d8e699e1fbe88 upstream.
    
    Instead of the arch specific quirk which we are deprecating
    and that drivers don't understand.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cac69a82453f8cf8097d0550d53942c5333f07de
Author: Jeff Layton <jlayton@redhat.com>
Date:   Mon Feb 3 12:13:07 2014 -0500

    locks: eliminate BUG() call when there's an unexpected lock on file close
    
    commit 8c3cac5e6a85f03602ffe09c44f14418699e31ec upstream.
    
    A leftover lock on the list is surely a sign of a problem of some sort,
    but it's not necessarily a reason to panic the box. Instead, just log a
    warning with some info about the lock, and then delete it like we would
    any other lock.
    
    In the event that the filesystem declares a ->lock f_op, we may end up
    leaking something, but that's generally preferable to an immediate
    panic.
    
    Acked-by: J. Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Cc: Markus Blank-Burian <burian@muenster.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 021e15481284fe72834def5cb456dcfd8b7d9529
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Oct 3 15:18:59 2014 +1000

    gpu/radeon: Set flag to indicate broken 64-bit MSI
    
    commit 91ed6fd2c383bb8f02d66e98b4a4d2f7207249dc upstream.
    
    Some radeon ASICs don't support all 64 address bits of MSIs despite
    advertising support for 64-bit MSIs in their configuration space.
    
    This breaks on systems such as IBM POWER7/8, where 64-bit MSIs can
    be assigned with some of the high address bits set.
    
    This makes use of the newly introduced "no_64bit_msi" flag in structure
    pci_dev to allow the MSI allocation code to fallback to 32-bit MSIs
    on those adapters.
    
    Adding Alex's review tag. Patch to the driver is identical to the
    reviewed one, I dropped the arch/powerpc hunk rewrote the subject
    and cset comment.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 14d7ed4da86b540486d78ce119106afb5666ea76
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Nov 12 19:17:02 2014 -0500

    drm/radeon: fix endian swapping in vbios fetch for tdp table
    
    commit 28731d5818ae25b92d1fb82fe0ac196e97102c1b upstream.
    
    Value needs to be swapped on BE.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 46068266788323ee1d8c4299cdfae30840a9ce57
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Thu Nov 20 11:17:33 2014 +0100

    bnx2fc: do not add shared skbs to the fcoe_rx_list
    
    commit 01a4cc4d0cd6a836c7b923760e8eb1cbb6a47258 upstream.
    
    In some cases, the fcoe_rx_list may contains multiple instances
    of the same skb (the so called "shared skbs").
    
    the bnx2fc_l2_rcv thread is a loop that extracts a skb from the list,
    modifies (and destroys) its content and then proceed to the next one.
    The problem is that if the skb is shared, the remaining instances will
    be corrupted.
    
    The solution is to use skb_share_check() before adding the skb to the
    fcoe_rx_list.
    
    [ 6286.808725] ------------[ cut here ]------------
    [ 6286.808729] WARNING: at include/scsi/fc_frame.h:173 bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]()
    [ 6286.808748] Modules linked in: bnx2x(-) mdio dm_service_time bnx2fc cnic uio fcoe libfcoe 8021q garp stp mrp libfc llc scsi_transport_fc scsi_tgt sg iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel e1000e ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper ptp cryptd hpilo serio_raw hpwdt lpc_ich pps_core ipmi_si pcspkr mfd_core ipmi_msghandler shpchp pcc_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit ata_piix drm_kms_helper ttm drm libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mdio]
    [ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 3.10.0-121.el7.x86_64 #1
    [ 6286.808750] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
    [ 6286.808752]  0000000000000000 000000000b36e715 ffff8800deba1e00 ffffffff815ec0ba
    [ 6286.808753]  ffff8800deba1e38 ffffffff8105dee1 ffffffffa05618c0 ffff8801e4c81888
    [ 6286.808754]  ffffe8ffff663868 ffff8801f402b180 ffff8801f56bc000 ffff8800deba1e48
    [ 6286.808754] Call Trace:
    [ 6286.808759]  [<ffffffff815ec0ba>] dump_stack+0x19/0x1b
    [ 6286.808762]  [<ffffffff8105dee1>] warn_slowpath_common+0x61/0x80
    [ 6286.808763]  [<ffffffff8105e00a>] warn_slowpath_null+0x1a/0x20
    [ 6286.808765]  [<ffffffffa054f415>] bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]
    [ 6286.808767]  [<ffffffffa054eff0>] ? bnx2fc_disable+0x90/0x90 [bnx2fc]
    [ 6286.808769]  [<ffffffff81085aef>] kthread+0xcf/0xe0
    [ 6286.808770]  [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
    [ 6286.808772]  [<ffffffff815fc76c>] ret_from_fork+0x7c/0xb0
    [ 6286.808773]  [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
    [ 6286.808774] ---[ end trace c6cdb939184ccb4e ]---
    
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Acked-by: Chad Dupuis <chad.dupuis@qlogic.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 29c881caca77550c4f0c97be09f5fc659c9955c5
Author: Jane Zhou <a17711@motorola.com>
Date:   Mon Nov 24 11:44:08 2014 -0800

    net/ping: handle protocol mismatching scenario
    
    commit 91a0b603469069cdcce4d572b7525ffc9fd352a6 upstream.
    
    ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
    dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
    sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
    sock will be returned.
    the fix is to "continue" the searching, if no matching, return NULL.
    
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
    Cc: James Morris <jmorris@namei.org>
    Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: netdev@vger.kernel.org
    Signed-off-by: Jane Zhou <a17711@motorola.com>
    Signed-off-by: Yiwei Zhao <gbjc64@motorola.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 55c8dd290be7ca4e64432b837d774314add709c0
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Wed Nov 19 12:47:50 2014 -0500

    nfsd: Fix slot wake up race in the nfsv4.1 callback code
    
    commit c6c15e1ed303ffc47e696ea1c9a9df1761c1f603 upstream.
    
    The currect code for nfsd41_cb_get_slot() and nfsd4_cb_done() has no
    locking in order to guarantee atomicity, and so allows for races of
    the form.
    
    Task 1                                  Task 2
    ======                                  ======
    if (test_and_set_bit(0) != 0) {
                                            clear_bit(0)
                                            rpc_wake_up_next(queue)
            rpc_sleep_on(queue)
            return false;
    }
    
    This patch breaks the race condition by adding a retest of the bit
    after the call to rpc_sleep_on().
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e030e3fc04533f70a52584ff4a54a33014286340
Author: Christoph Hellwig <hch@lst.de>
Date:   Sat Nov 8 13:11:03 2014 +0100

    nfsd: correctly define v4.2 support attributes
    
    commit 6d0ba0432a5e10bc714ba9c5adc460e726e5fbb4 upstream.
    
    Even when security labels are disabled we support at least the same
    attributes as v4.1.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8c3b78ffdeff62372503e92c606a262be51fb19a
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Tue Nov 11 14:28:47 2014 +0100

    rt2x00: do not align payload on modern H/W
    
    commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.
    
    RT2800 and newer hardware require padding between header and payload if
    header length is not multiple of 4.
    
    For historical reasons we also align payload to to 4 bytes boundary, but
    such alignment is not needed on modern H/W.
    
    Patch fixes skb_under_panic problems reported from time to time:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=84911
    https://bugzilla.kernel.org/show_bug.cgi?id=72471
    http://marc.info/?l=linux-wireless&m=139108549530402&w=2
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591
    
    Panic happened because we eat 4 bytes of skb headroom on each
    (re)transmission when sending frame without the payload and the header
    length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
    case because paylad_aling=2 is bigger than header_align=0 we increase
    header_align by 4 bytes. To prevent that we could change the check to:
    
    	if (payload_length && payload_align > header_align)
    		header_align += 4;
    
    but not aligning payload at all is more effective and alignment is not
    really needed by H/W (that has been tested on OpenWrt project for few
    years now).
    
    Reported-and-tested-by: Antti S. Lankila <alankila@bel.fi>
    Debugged-by: Antti S. Lankila <alankila@bel.fi>
    Reported-by: Henrik Asp <solenskiner@gmail.com>
    Originally-From: Helmut Schaa <helmut.schaa@googlemail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 20542e3efc5012451f8e05c17bea46119763fddf
Author: Thomas Körper <thomas.koerper@esd.eu>
Date:   Fri Oct 31 07:33:54 2014 +0100

    can: dev: avoid calling kfree_skb() from interrupt context
    
    commit 5247a589c24022ab34e780039cc8000c48f2035e upstream.
    
    ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
    Error) interrupt, which triggers the folloing warning:
    
    [ 1153.360705] ------------[ cut here ]------------
    [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
    [ 1153.360772] Call Trace:
    [ 1153.360778]  [<c167906f>] dump_stack+0x41/0x52
    [ 1153.360782]  [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
    [ 1153.360784]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
    [ 1153.360786]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
    [ 1153.360788]  [<c105bc42>] warn_slowpath_null+0x22/0x30
    [ 1153.360791]  [<c158b909>] skb_release_head_state+0xb9/0xd0
    [ 1153.360793]  [<c158be90>] skb_release_all+0x10/0x30
    [ 1153.360795]  [<c158bf06>] kfree_skb+0x36/0x80
    [ 1153.360799]  [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
    [ 1153.360802]  [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
    [ 1153.360805]  [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
    [ 1153.360809]  [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
    [ 1153.360811]  [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
    [ 1153.360813]  [<c10a7731>] handle_irq_event+0x31/0x50
    [ 1153.360816]  [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
    [ 1153.360818]  [<c10a9c10>] ? handle_edge_irq+0x110/0x110
    [ 1153.360822]  [<c1011b61>] handle_irq+0x71/0x90
    [ 1153.360823]  <IRQ>  [<c168152c>] do_IRQ+0x3c/0xd0
    [ 1153.360829]  [<c1680b6c>] common_interrupt+0x2c/0x34
    [ 1153.360834]  [<c107d277>] ? finish_task_switch+0x47/0xf0
    [ 1153.360836]  [<c167c27b>] __schedule+0x35b/0x7e0
    [ 1153.360839]  [<c10a5334>] ? console_unlock+0x2c4/0x4d0
    [ 1153.360842]  [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
    [ 1153.360845]  [<c10707b6>] ? process_one_work+0x196/0x370
    [ 1153.360847]  [<c167c723>] schedule+0x23/0x60
    [ 1153.360849]  [<c1070de1>] worker_thread+0x161/0x460
    [ 1153.360852]  [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
    [ 1153.360854]  [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
    [ 1153.360856]  [<c1074f01>] kthread+0xa1/0xc0
    [ 1153.360859]  [<c1680401>] ret_from_kernel_thread+0x21/0x30
    [ 1153.360861]  [<c1074e60>] ? kthread_create_on_node+0x110/0x110
    [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---
    
    This patch replaces the kfree_skb() by dev_kfree_skb_any().
    
    Signed-off-by: Thomas Körper <thomas.koerper@esd.eu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 57c63d276bc4984cb67f8642401b55aaa3e45af6
Author: Christian Sünkenberg <christian.suenkenberg@hfg-karlsruhe.de>
Date:   Tue Nov 18 20:23:32 2014 +0100

    scsi: add Intel Multi-Flex to scsi scan blacklist
    
    commit 1899045510ff109980d9cc34e330fd8ca3631871 upstream.
    
    Intel Multi-Flex LUNs choke on REPORT SUPPORTED OPERATION CODES
    resulting in sd_mod hanging for several minutes on startup.
    The issue was introduced with WRITE SAME discovery heuristics.
    
    Fixes: 5db44863b6eb ("[SCSI] sd: Implement support for WRITE SAME")
    Signed-off-by: Christian Sünkenberg <christian.suenkenberg@hfg-karlsruhe.de>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 32d48b3cc855df95001e80b1dc07adc2079d26fd
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Oct 8 06:19:20 2014 +0000

    vhost-scsi: Take configfs group dependency during VHOST_SCSI_SET_ENDPOINT
    
    commit ab8edab132829b26dd13db6caca3c242cce35dc1 upstream.
    
    This patch addresses a bug where individual vhost-scsi configfs endpoint
    groups can be removed from below while active exports to QEMU userspace
    still exist, resulting in an OOPs.
    
    It adds a configfs_depend_item() in vhost_scsi_set_endpoint() to obtain
    an explicit dependency on se_tpg->tpg_group in order to prevent individual
    vhost-scsi WWPN endpoints from being released via normal configfs methods
    while an QEMU ioctl reference still exists.
    
    Also, add matching configfs_undepend_item() in vhost_scsi_clear_endpoint()
    to release the dependency, once QEMU's reference to the individual group
    at /sys/kernel/config/target/vhost/$WWPN/$TPGT is released.
    
    (Fix up vhost_scsi_clear_endpoint() error path - DanC)
    
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 982b1001490f09f2a8810775a6c237d6b8e626f2
Author: Thor Thayer <tthayer@opensource.altera.com>
Date:   Thu Nov 6 13:54:27 2014 -0600

    spi: dw: Fix dynamic speed change.
    
    commit 0a8727e69778683495058852f783eeda141a754e upstream.
    
    An IOCTL call that calls spi_setup() and then dw_spi_setup() will
    overwrite the persisted last transfer speed. On each transfer, the
    SPI speed is compared to the last transfer speed to determine if the
    clock divider registers need to be updated (did the speed change?).
    This bug was observed with the spidev driver using spi-config to
    update the max transfer speed.
    
    This fix: Don't overwrite the persisted last transaction clock speed
    when updating the SPI parameters in dw_spi_setup(). On the next
    transaction, the new speed won't match the persisted last speed
    and the hardware registers will be updated.
    On initialization, the persisted last transaction clock
    speed will be 0 but will be updated after the first SPI
    transaction.
    
    Move zeroed clock divider check into clock change test because
    chip->clk_div is zero on startup and would cause a divide-by-zero
    error. The calculation was wrong as well (can't support odd #).
    
    Reported-by: Vlastimil Setka <setka@vsis.cz>
    Signed-off-by: Vlastimil Setka <setka@vsis.cz>
    Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0a915349e2da9a0d2a9467934234c97ce855f733
Author: Sagi Grimberg <sagig@dev.mellanox.co.il>
Date:   Tue Oct 28 13:45:03 2014 -0700

    iser-target: Handle DEVICE_REMOVAL event on network portal listener correctly
    
    commit 3b726ae2de02a406cc91903f80132daee37b6f1b upstream.
    
    In this case the cm_id->context is the isert_np, and the cm_id->qp
    is NULL, so use that to distinct the cases.
    
    Since we don't expect any other events on this cm_id we can
    just return -1 for explicit termination of the cm_id by the
    cma layer.
    
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 63af3438d269f8a2c27ad1c2d5da7f4b190b8462
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Oct 14 14:16:24 2014 -0700

    target: Don't call TFO->write_pending if data_length == 0
    
    commit 885e7b0e181c14e4d0ddd26c688bad2b84c1ada9 upstream.
    
    If an initiator sends a zero-length command (e.g. TEST UNIT READY) but
    sets the transfer direction in the transport layer to indicate a
    data-out phase, we still shouldn't try to transfer data.  At best it's
    a NOP, and depending on the transport, we might crash on an
    uninitialized sg list.
    
    Reported-by: Craig Watson <craig.watson@vanguard-rugged.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 090ec5fef8c36ce8cac294eddaaacf1a1cb9e56e
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Sun Oct 19 18:05:33 2014 +0300

    srp-target: Retry when QP creation fails with ENOMEM
    
    commit ab477c1ff5e0a744c072404bf7db51bfe1f05b6e upstream.
    
    It is not guaranteed to that srp_sq_size is supported
    by the HCA. So if we failed to create the QP with ENOMEM,
    try with a smaller srp_sq_size. Keep it up until we hit
    MIN_SRPT_SQ_SIZE, then fail the connection.
    
    Reported-by: Mark Lehrer <lehrer@gmail.com>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 52c0674a23d9309d07cca0ca50403b304faf83c4
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Nov 25 00:38:17 2014 -0800

    Input: xpad - use proper endpoint type
    
    commit a1f9a4072655843fc03186acbad65990cc05dd2d upstream.
    
    The xpad wireless endpoint is not a bulk endpoint on my devices, but
    rather an interrupt one, so the USB core complains when it is submitted.
    I'm guessing that the author really did mean that this should be an
    interrupt urb, but as there are a zillion different xpad devices out
    there, let's cover out bases and handle both bulk and interrupt
    endpoints just as easily.
    
    Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2c2bbb8a720934e493feb6dc52dd84bb04e60562
Author: Ben Sagal <bensagal@gmail.com>
Date:   Sun Nov 16 17:23:40 2014 -0800

    Input: synaptics - adjust min/max on Thinkpad E540
    
    commit bce4f9e764c36bc35dd5c9cf9e057c09f422397d upstream.
    
    The LEN2006 Synaptics touchpad (as found in Thinkpad E540) returns wrong
    min max values.
    
    touchpad-edge-detector output:
    >  Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event6
    >  Move one finger around the touchpad to detect the actual edges
    >  Kernel says:    x [1472..5674], y [1408..4684]
    >  Touchpad sends: x [1264..5675], y [1171..4688]
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88211
    Signed-off-by: Binyamin Sagal <bensagal@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 932307a475b5c56786987a98472c8e6c5bb5cd78
Author: Vladimir Murzin <vladimir.murzin@arm.com>
Date:   Thu Nov 27 11:39:04 2014 +0100

    ARM: 8226/1: cacheflush: get rid of restarting block
    
    commit 3f4aa45ceea5789a4aade536acc27f2e0d3da5e1 upstream.
    
    We cannot restart cacheflush safely if a process provides user-defined
    signal handler and signal is pending. In this case -EINTR is returned
    and it is expected that process re-invokes syscall. However, there are
    a few problems with that:
     * looks like nobody bothers checking return value from cacheflush
     * but if it did, we don't provide the restart address for that, so the
       process has to use the same range again
     * ...and again, what might lead to looping forever
    
    So, remove cacheflush restarting code and terminate cache flushing
    as early as fatal signal is pending.
    
    Reported-by: Chanho Min <chanho.min@lge.com>
    Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 72741f17d30ed08eb9eb64711bfd6c7e11ab7841
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Tue Nov 25 18:43:15 2014 +0100

    ARM: 8222/1: mvebu: enable strex backoff delay
    
    commit 995ab5189d1d7264e79e665dfa032a19b3ac646e upstream.
    
    Under extremely rare conditions, in an MPCore node consisting of at
    least 3 CPUs, two CPUs trying to perform a STREX to data on the same
    shared cache line can enter a livelock situation.
    
    This patch enables the HW mechanism that overcomes the bug. This fixes
    the incorrect setup of the STREX backoff delay bit due to a wrong
    description in the specification.
    
    Note that enabling the STREX backoff delay mechanism is done by
    leaving the bit *cleared*, while the bit was currently being set by
    the proc-v7.S code.
    
    [Thomas: adapt to latest mainline, slightly reword the commit log, add
    stable markers.]
    
    Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")
    
    Signed-off-by: Nadav Haklai <nadavh@marvell.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Acked-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 77e62e1c163fa7af5b2bd6def0b7253448247a06
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Fri Nov 21 15:29:00 2014 +0100

    ARM: 8216/1: xscale: correct auxiliary register in suspend/resume
    
    commit ef59a20ba375aeb97b3150a118318884743452a8 upstream.
    
    According to the manuals I have, XScale auxiliary register should be
    reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init
    correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and
    cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to
    also use c1, c0, 1.
    
    The issue was primarily noticed thanks to qemu reporing "unsupported
    instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255
    XScale Core manuals and in PXA270 and PXA320 Developers Guides.
    
    Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board.
    
    Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cab86d8c6534900243994bb0558e66a41fcbc39d
Author: Gu Zheng <guz.fnst@cn.fujitsu.com>
Date:   Thu Nov 6 17:46:21 2014 +0800

    aio: fix uncorrent dirty pages accouting when truncating AIO ring buffer
    
    commit 835f252c6debd204fcd607c79975089b1ecd3472 upstream.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=86831
    
    Markus reported that when shutting down mysqld (with AIO support,
    on a ext3 formatted Harddrive) leads to a negative number of dirty pages
    (underrun to the counter). The negative number results in a drastic reduction
    of the write performance because the page cache is not used, because the kernel
    thinks it is still 2 ^ 32 dirty pages open.
    
    Add a warn trace in __dec_zone_state will catch this easily:
    
    static inline void __dec_zone_state(struct zone *zone, enum
    	zone_stat_item item)
    {
         atomic_long_dec(&zone->vm_stat[item]);
    +    WARN_ON_ONCE(item == NR_FILE_DIRTY &&
    	atomic_long_read(&zone->vm_stat[item]) < 0);
         atomic_long_dec(&vm_stat[item]);
    }
    
    [   21.341632] ------------[ cut here ]------------
    [   21.346294] WARNING: CPU: 0 PID: 309 at include/linux/vmstat.h:242
    cancel_dirty_page+0x164/0x224()
    [   21.355296] Modules linked in: wutbox_cp sata_mv
    [   21.359968] CPU: 0 PID: 309 Comm: kworker/0:1 Not tainted 3.14.21-WuT #80
    [   21.366793] Workqueue: events free_ioctx
    [   21.370760] [<c0016a64>] (unwind_backtrace) from [<c0012f88>]
    (show_stack+0x20/0x24)
    [   21.378562] [<c0012f88>] (show_stack) from [<c03f8ccc>]
    (dump_stack+0x24/0x28)
    [   21.385840] [<c03f8ccc>] (dump_stack) from [<c0023ae4>]
    (warn_slowpath_common+0x84/0x9c)
    [   21.393976] [<c0023ae4>] (warn_slowpath_common) from [<c0023bb8>]
    (warn_slowpath_null+0x2c/0x34)
    [   21.402800] [<c0023bb8>] (warn_slowpath_null) from [<c00c0688>]
    (cancel_dirty_page+0x164/0x224)
    [   21.411524] [<c00c0688>] (cancel_dirty_page) from [<c00c080c>]
    (truncate_inode_page+0x8c/0x158)
    [   21.420272] [<c00c080c>] (truncate_inode_page) from [<c00c0a94>]
    (truncate_inode_pages_range+0x11c/0x53c)
    [   21.429890] [<c00c0a94>] (truncate_inode_pages_range) from
    [<c00c0f6c>] (truncate_pagecache+0x88/0xac)
    [   21.439252] [<c00c0f6c>] (truncate_pagecache) from [<c00c0fec>]
    (truncate_setsize+0x5c/0x74)
    [   21.447731] [<c00c0fec>] (truncate_setsize) from [<c013b3a8>]
    (put_aio_ring_file.isra.14+0x34/0x90)
    [   21.456826] [<c013b3a8>] (put_aio_ring_file.isra.14) from
    [<c013b424>] (aio_free_ring+0x20/0xcc)
    [   21.465660] [<c013b424>] (aio_free_ring) from [<c013b4f4>]
    (free_ioctx+0x24/0x44)
    [   21.473190] [<c013b4f4>] (free_ioctx) from [<c003d8d8>]
    (process_one_work+0x134/0x47c)
    [   21.481132] [<c003d8d8>] (process_one_work) from [<c003e988>]
    (worker_thread+0x130/0x414)
    [   21.489350] [<c003e988>] (worker_thread) from [<c00448ac>]
    (kthread+0xd4/0xec)
    [   21.496621] [<c00448ac>] (kthread) from [<c000ec18>]
    (ret_from_fork+0x14/0x20)
    [   21.503884] ---[ end trace 79c4bf42c038c9a1 ]---
    
    The cause is that we set the aio ring file pages as *DIRTY* via SetPageDirty
    (bypasses the VFS dirty pages increment) when init, and aio fs uses
    *default_backing_dev_info* as the backing dev, which does not disable
    the dirty pages accounting capability.
    So truncating aio ring file will contribute to accounting dirty pages (VFS
    dirty pages decrement), then error occurs.
    
    The original goal is keeping these pages in memory (can not be reclaimed
    or swapped) in life-time via marking it dirty. But thinking more, we have
    already pinned pages via elevating the page's refcount, which can already
    achieve the goal, so the SetPageDirty seems unnecessary.
    
    In order to fix the issue, using the __set_page_dirty_no_writeback instead
    of the nop .set_page_dirty, and dropped the SetPageDirty (don't manually
    set the dirty flags, don't disable set_page_dirty(), rely on default behaviour).
    
    With the above change, the dirty pages accounting can work well. But as we
    known, aio fs is an anonymous one, which should never cause any real write-back,
    we can ignore the dirty pages (write back) accounting by disabling the dirty
    pages (write back) accounting capability. So we introduce an aio private
    backing dev info (disabled the ACCT_DIRTY/WRITEBACK/ACCT_WB capabilities) to
    replace the default one.
    
    Reported-by: Markus Königshaus <m.koenigshaus@wut.de>
    Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 38446d657f98f5bc266ec46eaaa87f2bd9880768
Author: Jurgen Kramer <gtmkramer@xs4all.nl>
Date:   Sat Nov 15 14:01:21 2014 +0100

    ALSA: usb-audio: Add ctrl message delay quirk for Marantz/Denon devices
    
    commit 6e84a8d7ac3ba246ef44e313e92bc16a1da1b04a upstream.
    
    This patch adds a USB control message delay quirk for a few specific Marantz/Denon
    devices. Without the delay the DACs will not work properly and produces the
    following type of messages:
    
    Nov 15 10:09:21 orwell kernel: [   91.342880] usb 3-13: clock source 41 is not valid, cannot use
    Nov 15 10:09:21 orwell kernel: [   91.343775] usb 3-13: clock source 41 is not valid, cannot use
    
    There are likely other Marantz/Denon devices using the same USB module which exhibit the
    same problems. But as this cannot be verified I limited the patch to the devices
    I could test.
    
    The following two devices are covered by this path:
    - Marantz SA-14S1
    - Marantz HD-DAC1
    
    Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 000245b631cbc9dde4bebb0f378ec8cac5d60c07
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Sat Oct 11 00:31:07 2014 +0400

    can: esd_usb2: fix memory leak on disconnect
    
    commit efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream.
    
    It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
    the missing deallocation.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6facb9b2fae7b8cfc3a667d04ca89be6c190d8bb
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Tue Nov 18 11:27:14 2014 +0200

    usb: xhci: rework root port wake bits if controller isn't allowed to wakeup
    
    commit a1377e5397ab321e21b793ec8cd2b6f12bd3c718 upstream.
    
    When system is being suspended, if host device is not allowed to do wakeup,
    xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
    platforms may generate spurious wakeup, even if PCI PME# is disabled.
    
    The initial commit ff8cbf250b44 ("xhci: clear root port wake on bits"),
    which also got into stable, turned out to not work correctly and had to
    be reverted, and is now rewritten.
    
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Suggested-by: Alan Stern <stern@rowland.harvard.edu>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    [Mathias Nyman: reword commit message]
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d2cd8e2e70a55feb028e63fc3022da1d90467760
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Nov 18 11:27:11 2014 +0200

    USB: xhci: don't start a halted endpoint before its new dequeue is set
    
    commit c3492dbfa1050debf23a5b5cd2bc7514c5b37896 upstream.
    
    A halted endpoint ring must first be reset, then move the ring
    dequeue pointer past the problematic TRB. If we start the ring too
    early after reset, but before moving the dequeue pointer we
    will end up executing the same problematic TRB again.
    
    As we always issue a set transfer dequeue command after a reset
    endpoint command we can skip starting endpoint rings at reset endpoint
    command completion.
    
    Without this fix we end up trying to handle the same faulty TD for
    contol endpoints. causing timeout, and failing testusb ctrl_out write
    tests.
    
    Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per endpoint.)
    Tested-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4a6c782d1e4663edf05448267dc0a7afb5855c49
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Nov 24 11:22:38 2014 +0100

    usb-quirks: Add reset-resume quirk for MS Wireless Laser Mouse 6000
    
    commit 263e80b43559a6103e178a9176938ce171b23872 upstream.
    
    This wireless mouse receiver needs a reset-resume quirk to properly come
    out of reset.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1165206
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 712f9205f69016416c0e91163408f47d8666d9b4
Author: Troy Clark <tclark@matrixorbital.ca>
Date:   Mon Nov 17 14:33:17 2014 -0800

    usb: serial: ftdi_sio: add PIDs for Matrix Orbital products
    
    commit 204ec6e07ea7aff863df0f7c53301f9cbbfbb9d3 upstream.
    
    Add PIDs for new Matrix Orbital GTT series products.
    
    Signed-off-by: Troy Clark <tclark@matrixorbital.ca>
    [johan: shorten commit message ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 301f6f3d6bbf1768efe08be08733464ee10ace16
Author: Preston Fick <pffick@gmail.com>
Date:   Fri Nov 7 23:26:11 2014 -0600

    USB: serial: cp210x: add IDs for CEL MeshConnect USB Stick
    
    commit ffcfe30ebd8dd703d0fc4324ffe56ea21f5479f4 upstream.
    
    Signed-off-by: Preston Fick <pffick@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b20d1dbcbf5fec5ae4d574ad482073d9476cd7c1
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 18 11:25:19 2014 +0100

    USB: keyspan: fix tty line-status reporting
    
    commit 5d1678a33c731b56e245e888fdae5e88efce0997 upstream.
    
    Fix handling of TTY error flags, which are not bitmasks and must
    specifically not be ORed together as this prevents the line discipline
    from recognising them.
    
    Also insert null characters when reporting overrun errors as these are
    not associated with the received character.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7f293483b05b6f3472942b9c733daaf05ec2115e
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 18 11:25:20 2014 +0100

    USB: keyspan: fix overrun-error reporting
    
    commit 855515a6d3731242d85850a206f2ec084c917338 upstream.
    
    Fix reporting of overrun errors, which are not associated with a
    character. Instead insert a null character and report only once.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6aac77da2f675a7b47ef4a48a0f58a3d3d2c0026
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 18 11:25:21 2014 +0100

    USB: ssu100: fix overrun-error reporting
    
    commit 75bcbf29c284dd0154c3e895a0bd1ef0e796160e upstream.
    
    Fix reporting of overrun errors, which should only be reported once
    using the inserted null character.
    
    Fixes: 6b8f1ca5581b ("USB: ssu100: set tty_flags in ssu100_process_packet")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 69eca4e448962aa167058c680776879568c6e788
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Thu Nov 27 10:10:21 2014 -0600

    staging: r8188eu: Add new device ID for DLink GO-USB-N150
    
    commit 6d4556fc0309608f760f1d329df56d77fdd0c31a upstream.
    
    The DLink GO-USB-N150 with revision B1 uses this driver.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7abd18f7bad812dbab0bca2492d55a9800dcd479
Author: Cristina Ciocan <cristina.ciocan@intel.com>
Date:   Tue Nov 11 16:07:42 2014 +0200

    iio: Fix IIO_EVENT_CODE_EXTRACT_DIR bit mask
    
    commit ccf54555da9a5e91e454b909ca6a5303c7d6b910 upstream.
    
    The direction field is set on 7 bits, thus we need to AND it with 0111 111 mask
    in order to retrieve it, that is 0x7F, not 0xCF as it is now.
    
    Fixes: ade7ef7ba (staging:iio: Differential channel handling)
    Signed-off-by: Cristina Ciocan <cristina.ciocan@intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b9e0147db158e5d24346e5dafa9a84652d55a467
Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Date:   Mon Nov 24 15:07:53 2014 +0100

    powerpc/pseries: Fix endiannes issue in RTAS call from xmon
    
    commit 3b8a3c01096925a824ed3272601082289d9c23a5 upstream.
    
    On pseries system (LPAR) xmon failed to enter when running in LE mode,
    system is hunging. Inititating xmon will lead to such an output on the
    console:
    
    SysRq : Entering xmon
    cpu 0x15: Vector: 0  at [c0000003f39ffb10]
        pc: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
        lr: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
        sp: c0000003f39ffc70
       msr: 8000000000009033
      current = 0xc0000003fafa7180
      paca    = 0xc000000007d75e80	 softe: 0	 irq_happened: 0x01
        pid   = 14617, comm = bash
    Bad kernel stack pointer fafb4b0 at eca7cc4
    cpu 0x15: Vector: 300 (Data Access) at [c000000007f07d40]
        pc: 000000000eca7cc4
        lr: 000000000eca7c44
        sp: fafb4b0
       msr: 8000000000001000
       dar: 10000000
     dsisr: 42000000
      current = 0xc0000003fafa7180
      paca    = 0xc000000007d75e80	 softe: 0	 irq_happened: 0x01
        pid   = 14617, comm = bash
    cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop
    xmon: WARNING: bad recursive fault on cpu 0x15
    
    The root cause is that xmon is calling RTAS to turn off the surveillance
    when entering xmon, and RTAS is requiring big endian parameters.
    
    This patch is byte swapping the RTAS arguments when running in LE mode.
    
    Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 61a926913b3d5ea35d69d4f0a9c5c0e068abe72c
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Tue Oct 7 16:12:55 2014 +1100

    powerpc/pseries: Honor the generic "no_64bit_msi" flag
    
    commit 415072a041bf50dbd6d56934ffc0cbbe14c97be8 upstream.
    
    Instead of the arch specific quirk which we are deprecating
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9a9c085844ed2582ae5cf5e5c11166adedc0a491
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Nov 14 17:55:03 2014 +1100

    of/base: Fix PowerPC address parsing hack
    
    commit 746c9e9f92dde2789908e51a354ba90a1962a2eb upstream.
    
    We have a historical hack that treats missing ranges properties as the
    equivalent of an empty one. This is needed for ancient PowerMac "bad"
    device-trees, and shouldn't be enabled for any other PowerPC platform,
    otherwise we get some nasty layout of devices in sysfs or even
    duplication when a set of otherwise identically named devices is
    created multiple times under a different parent node with no ranges
    property.
    
    This fix is needed for the PowerNV i2c busses to be exposed properly
    and will fix a number of other embedded cases.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Grant Likely <grant.likely@linaro.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1043c385dd176fc1061781f9a9896cff540f6ea7
Author: Miaoqing Pan <miaoqing@qca.qualcomm.com>
Date:   Thu Nov 6 10:52:23 2014 +0530

    ath9k: Fix RTC_DERIVED_CLK usage
    
    commit 4e6ce4dc7ce71d0886908d55129d5d6482a27ff9 upstream.
    
    Based on the reference clock, which could be 25MHz or 40MHz,
    AR_RTC_DERIVED_CLK is programmed differently for AR9340 and AR9550.
    But, when a chip reset is done, processing the initvals
    sets the register back to the default value.
    
    Fix this by moving the code in ath9k_hw_init_pll() to
    ar9003_hw_override_ini(). Also, do this override for AR9531.
    
    js: remove AR_SREV_9531 test as 9531 support is not in 3.12 yet
    
    Signed-off-by: Miaoqing Pan <miaoqing@qca.qualcomm.com>
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 10ef1755917a46812dec017112f88ffafc309f94
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Nov 4 16:52:28 2014 +0100

    ASoC: dpcm: Fix race between FE/BE updates and trigger
    
    commit ea9d0d771fcd32cd56070819749477d511ec9117 upstream.
    
    DPCM can update the FE/BE connection states totally asynchronously
    from the FE's PCM state.  Most of FE/BE state changes are protected by
    mutex, so that they won't race, but there are still some actions that
    are uncovered.  For example, suppose to switch a BE while a FE's
    stream is running.  This would call soc_dpcm_runtime_update(), which
    sets FE's runtime_update flag, then sets up and starts BEs, and clears
    FE's runtime_update flag again.
    
    When a device emits XRUN during this operation, the PCM core triggers
    snd_pcm_stop(XRUN).  Since the trigger action is an atomic ops, this
    isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
    It eventually updates and clears FE's runtime_update flag while
    soc_dpcm_runtime_update() is running concurrently, and it results in
    confusion.
    
    Usually, for avoiding such a race, we take a lock.  There is a PCM
    stream lock for that purpose.  However, as already mentioned, the
    trigger action is atomic, and we can't take the lock for the whole
    soc_dpcm_runtime_update() or other operations that include the lengthy
    jobs like hw_params or prepare.
    
    This patch provides an alternative solution.  This adds a way to defer
    the conflicting trigger callback to be executed at the end of FE/BE
    state changes.  For doing it, two things are introduced:
    
    - Each runtime_update state change of FEs is protected via PCM stream
      lock.
    - The FE's trigger callback checks the runtime_update flag.  If it's
      not set, the trigger action is executed there.  If set, mark the
      pending trigger action and returns immediately.
    - At the exit of runtime_update state change, it checks whether the
      pending trigger is present.  If yes, it executes the trigger action
      at this point.
    
    Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0655044cc4972492962c4bb6f6c7098beb0b98c2
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Mon Nov 17 10:48:21 2014 +0000

    ASoC: wm_adsp: Avoid attempt to free buffers that might still be in use
    
    commit 9da7a5a9fdeeb76b2243f6b473363a7e6147ab6f upstream.
    
    We should not free any buffers associated with writing out coefficients
    to the DSP until all the async writes have completed. This patch updates
    the out of memory path when allocating a new buffer to include a call to
    regmap_async_complete.
    
    Reported-by: JS Park <aitdark.park@samsung.com>
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d1c6c007710cb9b487e79e1e4e34d4efd8e4f2d2
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Fri Nov 14 02:14:47 2014 -0200

    ASoC: sgtl5000: Fix SMALL_POP bit definition
    
    commit c251ea7bd7a04f1f2575467e0de76e803cf59149 upstream.
    
    On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound  to happen
    5 seconds after the end of a playback.
    
    The SMALL_POP bit should fix this, but its definition is incorrect:
    according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not
    bit 1.
    
    Fix the definition accordingly and enable the bit as intended per the code
    comment.
    
    After applying this change, no loud 'click' sound is heard after playback
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit befc717fc64a47bbb7cb3998f3bf8eb09c91faf1
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Tue Oct 28 21:01:53 2014 -0700

    ASoC: fsi: remove unsupported PAUSE flag
    
    commit c1b9b9b1ad2df6144ca3fbe6989f7bd9ea5c5562 upstream.
    
    FSI doesn't support PAUSE.
    Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e3040095dc397a3b6a55ecb3f7051a7d0a330011
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Tue Oct 28 21:02:03 2014 -0700

    ASoC: rsnd: remove unsupported PAUSE flag
    
    commit 706c66213e5e623e23f521b1acbd8171af7a3549 upstream.
    
    R-Car sound doesn't support PAUSE.
    Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bad84a260c714cb8f5ded73c9d24aeee0b153199
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Wed Oct 22 14:55:49 2014 -0700

    ib_isert: Add max_send_sge=2 minimum for control PDU responses
    
    commit f57915cfa5b2b14c1cffa2e83c034f55e3f0e70d upstream.
    
    This patch adds a max_send_sge=2 minimum in isert_conn_setup_qp()
    to ensure outgoing control PDU responses with tx_desc->num_sge=2
    are able to function correctly.
    
    This addresses a bug with RDMA hardware using dev_attr.max_sge=3,
    that in the original code with the ConnectX-2 work-around would
    result in isert_conn->max_sge=1 being negotiated.
    
    Originally reported by Chris with ocrdma driver.
    
    Reported-by: Chris Moore <Chris.Moore@emulex.com>
    Tested-by: Chris Moore <Chris.Moore@emulex.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a202e873db134652f98074849d2299a01d390aa1
Author: Chris Moore <Chris.Moore@Emulex.Com>
Date:   Tue Nov 4 16:28:29 2014 +0000

    IB/isert: Adjust CQ size to HW limits
    
    commit b1a5ad006b34ded9dc7ec64988deba1b3ecad367 upstream.
    
    isert has an issue of trying to create a CQ with more CQEs than are
    supported by the hardware, that currently results in failures during
    isert_device creation during first session login.
    
    This is the isert version of the patch that Minh Tran submitted for
    iser, and is simple a workaround required to function with existing
    ocrdma hardware.
    
    Signed-off-by: Chris Moore <chris.moore@emulex.com>
    Reviewied-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1b0a21003bd3b81a0b935f51f4e6988910cb0ae1
Author: Maxime Ripard <maxime.ripard@free-electrons.com>
Date:   Tue Nov 18 23:59:33 2014 +0100

    clockevent: sun4i: Fix race condition in the probe code
    
    commit 6bab4a8a1888729f17f4923cc5867e4674f66333 upstream.
    
    The interrupts were activated and the handler registered before the clockevent
    was registered in the probe function.
    
    The interrupt handler, however, was making the assumption that the clockevent
    device was registered.
    
    That could cause a null pointer dereference if the timer interrupt was firing
    during this narrow window.
    
    Fix that by moving the clockevent registration before the interrupt is enabled.
    
    Reported-by: Roman Byshko <rbyshko@gmail.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5545f8b0fca9fa9efe65d8084dbb536aebabdb61
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Oct 3 15:13:24 2014 +1000

    PCI/MSI: Add device flag indicating that 64-bit MSIs don't work
    
    commit f144d1496b47e7450f41b767d0d91c724c2198bc upstream.
    
    This can be set by quirks/drivers to be used by the architecture code
    that assigns the MSI addresses.
    
    We additionally add verification in the core MSI code that the values
    assigned by the architecture do satisfy the limitation in order to fail
    gracefully if they don't (ie. the arch hasn't been updated to deal with
    that quirk yet).
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c50db3a5b930ef107cf6df611e729032e69de350
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Fri Nov 21 13:26:07 2014 -0800

    uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME
    
    commit 82975bc6a6df743b9a01810fb32cb65d0ec5d60b upstream.
    
    x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set but
    not on non-paranoid returns.  I suspect that this is a mistake and that
    the code only works because int3 is paranoid.
    
    Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a workaround
    for the x86 bug.  With that bug fixed, we can remove _TIF_NOTIFY_RESUME
    from the uprobes code.
    
    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Acked-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 868b19cb0314da9725ec108ec6abb082965cd0c2
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Nov 14 11:47:37 2014 -0800

    x86, mm: Set NX across entire PMD at boot
    
    commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58 upstream.
    
    When setting up permissions on kernel memory at boot, the end of the
    PMD that was split from bss remained executable. It should be NX like
    the rest. This performs a PMD alignment instead of a PAGE alignment to
    get the correct span of memory.
    
    Before:
    ---[ High Kernel Mapping ]---
    ...
    0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
    0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
    0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
    0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
    0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
    
    After:
    ---[ High Kernel Mapping ]---
    ...
    0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
    0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
    0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
    
    [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
            We really should unmap the reminder along with the holes
            caused by init,initdata etc. but thats a different issue ]
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Toshi Kani <toshi.kani@hp.com>
    Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Cc: David Vrabel <david.vrabel@citrix.com>
    Cc: Wang Nan <wangnan0@huawei.com>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 64d6bef08627721e538f457da75cf43aa64f838b
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date:   Tue Nov 11 14:01:33 2014 -0800

    x86: Require exact match for 'noxsave' command line option
    
    commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3 upstream.
    
    We have some very similarly named command-line options:
    
    arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
    arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
    arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
    
    __setup() is designed to match options that take arguments, like
    "foo=bar" where you would have:
    
    	__setup("foo", x86_foo_func...);
    
    The problem is that "noxsave" actually _matches_ "noxsaves" in
    the same way that "foo" matches "foo=bar".  If you boot an old
    kernel that does not know about "noxsaves" with "noxsaves" on the
    command line, it will interpret the argument as "noxsave", which
    is not what you want at all.
    
    This makes the "noxsave" handler only return success when it finds
    an *exact* match.
    
    [ tglx: We really need to make __setup() more robust. ]
    
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Dave Hansen <dave@sr71.net>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: x86@kernel.org
    Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ae0256eb36f88f75533d57c957cc73a2660e1327
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Sat Nov 22 18:00:33 2014 -0800

    x86_64, traps: Rework bad_iret
    
    commit b645af2d5905c4e32399005b867987919cbfc3ae upstream.
    
    It's possible for iretq to userspace to fail.  This can happen because
    of a bad CS, SS, or RIP.
    
    Historically, we've handled it by fixing up an exception from iretq to
    land at bad_iret, which pretends that the failed iret frame was really
    the hardware part of #GP(0) from userspace.  To make this work, there's
    an extra fixup to fudge the gs base into a usable state.
    
    This is suboptimal because it loses the original exception.  It's also
    buggy because there's no guarantee that we were on the kernel stack to
    begin with.  For example, if the failing iret happened on return from an
    NMI, then we'll end up executing general_protection on the NMI stack.
    This is bad for several reasons, the most immediate of which is that
    general_protection, as a non-paranoid idtentry, will try to deliver
    signals and/or schedule from the wrong stack.
    
    This patch throws out bad_iret entirely.  As a replacement, it augments
    the existing swapgs fudge into a full-blown iret fixup, mostly written
    in C.  It's should be clearer and more correct.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e40598270a40040461c8b8d3a8656d54fb59b9cd
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Sat Nov 22 18:00:32 2014 -0800

    x86_64, traps: Stop using IST for #SS
    
    commit 6f442be2fb22be02cafa606f1769fa1e6f894441 upstream.
    
    On a 32-bit kernel, this has no effect, since there are no IST stacks.
    
    On a 64-bit kernel, #SS can only happen in user code, on a failed iret
    to user space, a canonical violation on access via RSP or RBP, or a
    genuine stack segment violation in 32-bit kernel code.  The first two
    cases don't need IST, and the latter two cases are unlikely fatal bugs,
    and promoting them to double faults would be fine.
    
    This fixes a bug in which the espfix64 code mishandles a stack segment
    violation.
    
    This saves 4k of memory per CPU and a tiny bit of code.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8f9d4f83ed394c6add6be0f27ca466304f1fc42a
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Sat Nov 22 18:00:31 2014 -0800

    x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C
    
    commit af726f21ed8af2cdaa4e93098dc211521218ae65 upstream.
    
    There's nothing special enough about the espfix64 double fault fixup to
    justify writing it in assembly.  Move it to C.
    
    This also fixes a bug: if the double fault came from an IST stack, the
    old asm code would return to a partially uninitialized stack frame.
    
    Fixes: 3891a04aafd668686239349ea58f3314ea2af86b
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1518cde157af1021c44565d6260a152e65df214f
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Thu Nov 20 01:05:38 2014 +0200

    MIPS: Loongson: Make platform serial setup always built-in.
    
    commit 26927f76499849e095714452b8a4e09350f6a3b9 upstream.
    
    If SERIAL_8250 is compiled as a module, the platform specific setup
    for Loongson will be a module too, and it will not work very well.
    At least on Loongson 3 it will trigger a build failure,
    since loongson_sysconf is not exported to modules.
    
    Fix by making the platform specific serial code always built-in.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Reported-by: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: Huacai Chen <chenhc@lemote.com>
    Cc: Markos Chandras <Markos.Chandras@imgtec.com>
    Patchwork: https://patchwork.linux-mips.org/patch/8533/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit be5c8e57cd3ead1a28f73319b68bf2e12148a3c7
Author: Aaro Koskinen <aaro.koskinen@nsn.com>
Date:   Fri Oct 17 18:10:24 2014 +0300

    MIPS: oprofile: Fix backtrace on 64-bit kernel
    
    commit bbaf113a481b6ce32444c125807ad3618643ce57 upstream.
    
    Fix incorrect cast that always results in wrong address for the new
    frame on 64-bit kernels.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/8110/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 00df39d248ac037f06dfa97c59dc2a7da8b58728
Author: Alexander Gordeev <agordeev@redhat.com>
Date:   Mon Dec 16 09:34:56 2013 +0100

    PCI/MSI: Return msix_capability_init() failure if populate_msi_sysfs() fails
    
    commit 2adc7907bac2c72535894732c4b41f9210f9e577 upstream.
    
    If populate_msi_sysfs() function failed msix_capability_init() must return
    the error code, but it returns the success instead.  This update fixes the
    described misbehaviour.
    
    Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Tejun Heo <tj@kernel.org>
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c5ddd2b1c74f81410950298b964bbb9c588f5aa6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 6 09:27:11 2014 -0800

    Input: synaptics - add min/max quirk for Lenovo T440s
    
    commit e4742b1e786ca386e88e6cfb2801e14e15e365cd upstream.
    
    The new Lenovo T440s laptop has a different PnP ID "LEN0039", and it
    needs the similar min/max quirk to make its clickpad working.
    
    BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=903748
    Reported-and-tested-by: Joschi Brauchle <joschibrauchle@gmx.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f24045932464431eb19b346924212657b0125220
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Jul 14 17:12:21 2014 -0700

    Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531)
    
    commit e76aed9da7189eeb41b9856552ce5721181e8e8d upstream.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1114768
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6608dfb5328a3769e9aea98a5a1d9c5435b7104c
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Sat Jun 7 22:37:47 2014 -0700

    Input: synaptics - fix resolution for manually provided min/max
    
    commit d49cb7aeebb974713f9f7ab2991352d3050b095b upstream.
    
    commit 421e08c41fda fixed the reported min/max for the X and Y axis,
    but unfortunately, it broke the resolution of those same axis.
    
    On the t540p, the resolution is the same regarding X and Y. It is not
    a problem for xf86-input-synaptics because this driver is only interested
    in the ratio between X and Y.
    Unfortunately, xf86-input-cmt uses directly the resolution, and having a
    null resolution leads to some divide by 0 errors, which are translated by
    -infinity in the resulting coordinates.
    
    Reported-by: Peter Hutterer <peter.hutterer@who-t.net>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a847eeed11769b29fa4a944e269cf89a08f32c26
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon May 19 22:54:09 2014 -0700

    Input: synaptics - change min/max quirk table to pnp-id matching
    
    commit 0f68f39c393bc06ac5ccc8794f0e2ed841e41c3e upstream.
    
    Most of the affected models share pnp-ids for the touchpad. So switching
    to pnp-ids give us 2 advantages:
    1) It shrinks the quirk list
    2) It will lower the new quirk addition frequency, ie the recently added W540
       quirk would not have been necessary since it uses the same LEN0034 pnp ids
       as other models already added before it
    
    As an added bonus it actually puts the quirk on the actual psmouse, rather
    then on the machine, which is technically more correct.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ea70c325e0ec1e393ee7caf5c1b2496ee743cb71
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon May 19 22:53:23 2014 -0700

    Input: synaptics - add a matches_pnp_id helper function
    
    commit e2f611029b370bb7a04236215ad4b36aa8cb98cd upstream.
    
    This is a preparation patch for simplifying the min/max quirk table.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8f878acdf87a288172225f91418bae8e74f3ec58
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 19 22:26:41 2014 -0700

    Input: synaptics - report INPUT_PROP_TOPBUTTONPAD property
    
    commit 43e19888b1fe2a3e8a5543030c5b286cde38b3f5 upstream.
    
    Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD
    property for for touchpads with top button areas.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a4e2b94ab9353230fe45187ee0c15a2fc9195fc3
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 19 22:25:45 2014 -0700

    Input: Add INPUT_PROP_TOPBUTTONPAD device property
    
    commit f37c013409bb78ebb958821aa10d069e707cabac upstream.
    
    On some newer laptops with a trackpoint the physical buttons for the
    trackpoint have been removed to allow for a larger touchpad. On these
    laptops the buttonpad has clearly marked areas on the top which are to be
    used as trackpad buttons.
    
    Users of the event device-node need to know about this, so that they can
    properly interpret BTN_LEFT events as being a left / right / middle click
    depending on where on the button pad the clicking finger is.
    
    This commits adds a INPUT_PROP_TOPBUTTONPAD device property which drivers
    for such buttonpads will use to signal to the user that this buttonpad not
    only has the normal bottom button area, but also a top button area.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9abcb95a72698fe08402c7204d2375af50a1e01d
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 19 20:47:35 2014 -0700

    Input: i8042 - add firmware_id support
    
    commit a7c5868c3482127cb308c779b8a6460a3353c17f upstream.
    
    Fill in the new serio firmware_id sysfs attribute for pnp instantiated
    8042 serio ports.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d278ba6471641f99eda3b3c76f8414339c9dbed0
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 19 20:39:35 2014 -0700

    Input: serio - add firmware_id sysfs attribute
    
    commit 0456c66f4e905e1ca839318219c770988b47975c upstream.
    
    serio devices exposed via platform firmware interfaces such as ACPI may
    provide additional identifying information of use to userspace.
    
    We don't associate the serio devices with the firmware device (we don't
    set it as parent), so there's no way for userspace to make use of this
    information.
    
    We cannot change the parent for serio devices instantiated though a
    firmware interface as that would break suspend / resume ordering.
    
    Therefore this patch adds a new firmware_id sysfs attribute so that
    userspace can get a string from there with any additional identifying
    information the firmware interface may provide.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>