commit 5d14e472c60de8791259a0dbb8ba5252d0862a63
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Feb 3 09:19:48 2012 -0800

    Linux 3.0.19

commit 614a5aed26447b940748514f77b5487cdba2c5d6
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:53 2012 +0100

    USB: cp210x: allow more baud rates above 1Mbaud
    
    commit d1620ca9e7bb0030068c3b45b653defde8839dac upstream.
    
    Allow more baud rates to be set in [1M,2M] baud.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 872a9a09233a2ff601bf3449cdd2be9e9b2c0ac2
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:52 2012 +0100

    USB: cp210x: initialise baud rate at open
    
    commit cdc32fd6f7b2b2580d7f1b74563f888e4dd9eb8a upstream.
    
    The newer cp2104 devices require the baud rate to be initialised after
    power on. Make sure it is set when port is opened.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9dbd22994fae588903b99c328f81870e09795b8
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:51 2012 +0100

    USB: cp210x: clean up, refactor and document speed handling
    
    commit e5990874e511d5bbca23b3396419480cb2ca0ee7 upstream.
    
    Clean up and refactor speed handling.
    Document baud rate handling for CP210{1,2,4,5,10}.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 193aec6a3db750e58f5aac26e68dbb124b7328e9
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:49 2012 +0100

    USB: cp210x: fix up set_termios variables
    
    commit 34b76fcaee574017862ea3fa0efdcd77a9d0e57d upstream.
    
    [Based on a patch from Johan, mangled by gregkh to keep things in line]
    
    Fix up the variable usage in the set_termios call.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb04bab862c91d0bd75e5c5339039e5444973d16
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:50 2012 +0100

    USB: cp210x: do not map baud rates to B0
    
    commit be125d9c8d59560e7cc2d6e2b65c8fd233498ab7 upstream.
    
    We do not implement B0 hangup yet so map low baudrates to 300bps.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e23f5bd613d19b6ad224bd8e4768a1963a42330c
Author: Preston Fick <preston.fick@silabs.com>
Date:   Mon Jan 16 18:14:09 2012 -0600

    USB: cp210x: fix CP2104 baudrate usage
    
    commit 7f482fc88ac47662228d6b1f05759797c8936a30 upstream.
    
    This fix changes the way baudrates are set on the CP210x devices from
    Silicon Labs. The CP2101/2/3 will respond to both a GET/SET_BAUDDIV
    command, and GET/SET_BAUDRATE command, while CP2104 and higher devices
    only respond to GET/SET_BAUDRATE. The current cp210x.ko driver in
    kernel version 3.2.0 only implements the GET/SET_BAUDDIV command.
    
    This patch implements the two new codes for the GET/SET_BAUDRATE
    commands. Then there is a change in the way that the baudrate is
    assigned or retrieved. This is done according to the CP210x USB
    specification in AN571. This document can be found here:
    http://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/AN571.pdf&src=DocumentationWebPart
    
    Sections 5.3/5.4 describe the USB packets for the old baudrate method.
    Sections 5.5/5.6 describe the USB packets for the new method. This
    patch also implements the new request scheme, and eliminates the
    unnecessary baudrate calculations since it uses the "actual baudrate"
    method.
    
    This patch solves the problem reported for the CP2104 in bug 42586,
    and also keeps support for all other devices (CP2101/2/3).
    
    This patchfile is also attached to the bug report on
    bugzilla.kernel.org. This patch has been developed and test on the
    3.2.0 mainline kernel version under Ubuntu 10.11.
    
    Signed-off-by: Preston Fick <preston.fick@silabs.com>
    [duplicate patch also sent by Johan - gregkh]
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea453b01d323ab09758a56c06e808420b63b5a1a
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:48 2012 +0100

    USB: cp210x: call generic open last in open
    
    commit 55b2afbb92ad92e9f6b0aa4354eb1c94589280c3 upstream.
    
    Make sure port is fully initialised before calling generic open.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4148500eefcc1b84a1985e9f8835a330d25f051
Author: Renato Caldas <rmsc@fe.up.pt>
Date:   Fri Jan 6 15:20:51 2012 +0000

    USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
    
    commit 791b7d7cf69de11275e4dccec2f538eec02cbff6 upstream.
    
    This device is a Oscilloscope/Logic Analizer/Pattern Generator/TDR,
    using a Silabs CP2103 USB to UART Bridge.
    
    Signed-off-by: Renato Caldas <rmsc@fe.up.pt>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81ecd154d0b07bd5dab6e4f09336cb068b70bcb9
Author: shawnlu <shawn.lu@ericsson.com>
Date:   Fri Jan 20 12:22:04 2012 +0000

    tcp: md5: using remote adress for md5 lookup in rst packet
    
    [ Upstream commit 8a622e71f58ec9f092fc99eacae0e6cf14f6e742 ]
    
    md5 key is added in socket through remote address.
    remote address should be used in finding md5 key when
    sending out reset packet.
    
    Signed-off-by: shawnlu <shawn.lu@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b4bb350e120fe0b32a0b1b8d227e65af03e3993
Author: Neal Cardwell <ncardwell@google.com>
Date:   Sat Jan 28 17:29:46 2012 +0000

    tcp: fix tcp_trim_head() to adjust segment count with skb MSS
    
    [ Upstream commit 5b35e1e6e9ca651e6b291c96d1106043c9af314a ]
    
    This commit fixes tcp_trim_head() to recalculate the number of
    segments in the skb with the skb's existing MSS, so trimming the head
    causes the skb segment count to be monotonically non-increasing - it
    should stay the same or go down, but not increase.
    
    Previously tcp_trim_head() used the current MSS of the connection. But
    if there was a decrease in MSS between original transmission and ACK
    (e.g. due to PMTUD), this could cause tcp_trim_head() to
    counter-intuitively increase the segment count when trimming bytes off
    the head of an skb. This violated assumptions in tcp_tso_acked() that
    tcp_trim_head() only decreases the packet count, so that packets_acked
    in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to
    pass u32 pkts_acked values as large as 0xffffffff to
    ca_ops->pkts_acked().
    
    As an aside, if tcp_trim_head() had really wanted the skb to reflect
    the current MSS, it should have called tcp_set_skb_tso_segs()
    unconditionally, since a decrease in MSS would mean that a
    single-packet skb should now be sliced into multiple segments.
    
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Nandita Dukkipati <nanditad@google.com>
    Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f217c4711d71aa6811b6e71d219b9efafa5d55a6
Author: David S. Miller <davem@davemloft.net>
Date:   Tue Jan 24 17:03:44 2012 -0500

    rds: Make rds_sock_lock BH rather than IRQ safe.
    
    [ Upstream commit efc3dbc37412c027e363736b4f4c74ee5e8ecffc ]
    
    rds_sock_info() triggers locking warnings because we try to perform a
    local_bh_enable() (via sock_i_ino()) while hardware interrupts are
    disabled (via taking rds_sock_lock).
    
    There is no reason for rds_sock_lock to be a hardware IRQ disabling
    lock, none of these access paths run in hardware interrupt context.
    
    Therefore making it a BH disabling lock is safe and sufficient to
    fix this bug.
    
    Reported-by: Kumar Sanghvi <kumaras@chelsio.com>
    Reported-by: Josh Boyer <jwboyer@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d020b1d3d3379d183d0649cdc2f6de9131268419
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed Jan 18 07:21:42 2012 +0000

    net: bpf_jit: fix divide by 0 generation
    
    [ Upstream commit d00a9dd21bdf7908b70866794c8313ee8a5abd5c ]
    
    Several problems fixed in this patch :
    
    1) Target of the conditional jump in case a divide by 0 is performed
       by a bpf is wrong.
    
    2) Must 'generate' the full function prologue/epilogue at pass=0,
       or else we can stop too early in pass=1 if the proglen doesnt change.
       (if the increase of prologue/epilogue equals decrease of all
        instructions length because some jumps are converted to near jumps)
    
    3) Change the wrong length detection at the end of code generation to
       issue a more explicit message, no need for a full stack trace.
    
    Reported-by: Phil Oester <kernel@linuxace.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1334533665277ccc5568c5104cd2358788a02e02
Author: James Chapman <jchapman@katalix.com>
Date:   Wed Jan 25 02:39:05 2012 +0000

    l2tp: l2tp_ip - fix possible oops on packet receive
    
    [ Upstream commit 68315801dbf3ab2001679fd2074c9dc5dcf87dfa ]
    
    When a packet is received on an L2TP IP socket (L2TPv3 IP link
    encapsulation), the l2tpip socket's backlog_rcv function calls
    xfrm4_policy_check(). This is not necessary, since it was called
    before the skb was added to the backlog. With CONFIG_NET_NS enabled,
    xfrm4_policy_check() will oops if skb->dev is null, so this trivial
    patch removes the call.
    
    This bug has always been present, but only when CONFIG_NET_NS is
    enabled does it cause problems. Most users are probably using UDP
    encapsulation for L2TP, hence the problem has only recently
    surfaced.
    
    EIP: 0060:[<c12bb62b>] EFLAGS: 00210246 CPU: 0
    EIP is at l2tp_ip_recvmsg+0xd4/0x2a7
    EAX: 00000001 EBX: d77b5180 ECX: 00000000 EDX: 00200246
    ESI: 00000000 EDI: d63cbd30 EBP: d63cbd18 ESP: d63cbcf4
     DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Call Trace:
     [<c1218568>] sock_common_recvmsg+0x31/0x46
     [<c1215c92>] __sock_recvmsg_nosec+0x45/0x4d
     [<c12163a1>] __sock_recvmsg+0x31/0x3b
     [<c1216828>] sock_recvmsg+0x96/0xab
     [<c10b2693>] ? might_fault+0x47/0x81
     [<c10b2693>] ? might_fault+0x47/0x81
     [<c1167fd0>] ? _copy_from_user+0x31/0x115
     [<c121e8c8>] ? copy_from_user+0x8/0xa
     [<c121ebd6>] ? verify_iovec+0x3e/0x78
     [<c1216604>] __sys_recvmsg+0x10a/0x1aa
     [<c1216792>] ? sock_recvmsg+0x0/0xab
     [<c105a99b>] ? __lock_acquire+0xbdf/0xbee
     [<c12d5a99>] ? do_page_fault+0x193/0x375
     [<c10d1200>] ? fcheck_files+0x9b/0xca
     [<c10d1259>] ? fget_light+0x2a/0x9c
     [<c1216bbb>] sys_recvmsg+0x2b/0x43
     [<c1218145>] sys_socketcall+0x16d/0x1a5
     [<c11679f0>] ? trace_hardirqs_on_thunk+0xc/0x10
     [<c100305f>] sysenter_do_call+0x12/0x38
    Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff <ff> 76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0c
    
    Signed-off-by: James Chapman <jchapman@katalix.com>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03024e3d2d6705443980f956abb56d4453319e95
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Wed Jan 18 12:24:54 2012 +0000

    bonding: fix enslaving in alb mode when link down
    
    [ Upstream commit b924551bed09f61b64f21bffe241afc5526b091a ]
    
    bond_alb_init_slave() is called from bond_enslave() and sets the slave's MAC
    address. This is done differently for TLB and ALB modes.
    bond->alb_info.rlb_enabled is used to discriminate between the two modes but
    this flag may be uninitialized if the slave is being enslaved prior to calling
    bond_open() -> bond_alb_initialize() on the master.
    
    It turns out all the callers of alb_set_slave_mac_addr() pass
    bond->alb_info.rlb_enabled as the hw parameter.
    
    This patch cleans up the unnecessary parameter of alb_set_slave_mac_addr() and
    makes the function decide based on the bonding mode instead, which fixes the
    above problem.
    
    Reported-by: Narendra K <Narendra_K@Dell.com>
    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62252cba2867cec7cc484ebb2d3ec705c41d9684
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Jan 26 14:04:53 2012 +0000

    net caif: Register properly as a pernet subsystem.
    
    [ Upstream commit 8a8ee9aff6c3077dd9c2c7a77478e8ed362b96c6 ]
    
    caif is a subsystem and as such it needs to register with
    register_pernet_subsys instead of register_pernet_device.
    
    Among other problems using register_pernet_device was resulting in
    net_generic being called before the caif_net structure was allocated.
    Which has been causing net_generic to fail with either BUG_ON's or by
    return NULL pointers.
    
    A more ugly problem that could be caused is packets in flight why the
    subsystem is shutting down.
    
    To remove confusion also remove the cruft cause by inappropriately
    trying to fix this bug.
    
    With the aid of the previous patch I have tested this patch and
    confirmed that using register_pernet_subsys makes the failure go away as
    it should.
    
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc1be3611bae365c2399f5208732ddd0969cf46d
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Jan 26 14:02:55 2012 +0000

    netns: Fail conspicously if someone uses net_generic at an inappropriate time.
    
    [ Upstream commit 5ee4433efe99b9f39f6eff5052a177bbcfe72cea ]
    
    By definition net_generic should never be called when it can return
    NULL.  Fail conspicously with a BUG_ON to make it clear when people mess
    up that a NULL return should never happen.
    
    Recently there was a bug in the CAIF subsystem where it was registered
    with register_pernet_device instead of register_pernet_subsys.  It was
    erroneously concluded that net_generic could validly return NULL and
    that net_assign_generic was buggy (when it was just inefficient).
    Hopefully this BUG_ON will prevent people to coming to similar erroneous
    conclusions in the futrue.
    
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 561331eae0a03d0c4cf60f3cf485aa3e8aa5ab48
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Thu Jan 26 00:41:38 2012 +0000

    netns: fix net_alloc_generic()
    
    [ Upstream commit 073862ba5d249c20bd5c49fc6d904ff0e1f6a672 ]
    
    When a new net namespace is created, we should attach to it a "struct
    net_generic" with enough slots (even empty), or we can hit the following
    BUG_ON() :
    
    [  200.752016] kernel BUG at include/net/netns/generic.h:40!
    ...
    [  200.752016]  [<ffffffff825c3cea>] ? get_cfcnfg+0x3a/0x180
    [  200.752016]  [<ffffffff821cf0b0>] ? lockdep_rtnl_is_held+0x10/0x20
    [  200.752016]  [<ffffffff825c41be>] caif_device_notify+0x2e/0x530
    [  200.752016]  [<ffffffff810d61b7>] notifier_call_chain+0x67/0x110
    [  200.752016]  [<ffffffff810d67c1>] raw_notifier_call_chain+0x11/0x20
    [  200.752016]  [<ffffffff821bae82>] call_netdevice_notifiers+0x32/0x60
    [  200.752016]  [<ffffffff821c2b26>] register_netdevice+0x196/0x300
    [  200.752016]  [<ffffffff821c2ca9>] register_netdev+0x19/0x30
    [  200.752016]  [<ffffffff81c1c67a>] loopback_net_init+0x4a/0xa0
    [  200.752016]  [<ffffffff821b5e62>] ops_init+0x42/0x180
    [  200.752016]  [<ffffffff821b600b>] setup_net+0x6b/0x100
    [  200.752016]  [<ffffffff821b6466>] copy_net_ns+0x86/0x110
    [  200.752016]  [<ffffffff810d5789>] create_new_namespaces+0xd9/0x190
    
    net_alloc_generic() should take into account the maximum index into the
    ptr array, as a subsystem might use net_generic() anytime.
    
    This also reduces number of reallocations in net_assign_generic()
    
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Pavel Emelyanov <xemul@openvz.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4df9c291640da8992e146076f57a8e563c449e31
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Jan 20 01:49:57 2012 +0100

    USB: cdc-wdm: Avoid hanging on interface with no USB_CDC_DMM_TYPE
    
    commit 15699e6fafc3a90e5fdc2ef30555a04dee62286f upstream.
    
    The probe does not strictly require the USB_CDC_DMM_TYPE
    descriptor, which is a good thing as it makes the driver
    usable on non-conforming interfaces.  A user could e.g.
    bind to it to a CDC ECM interface by using the new_id and
    bind sysfs files.  But this would fail with a 0 buffer length
    due to the missing descriptor.
    
    Fix by defining a reasonable fallback size: The minimum
    device receive buffer size required by the CDC WMC standard,
    revision 1.1
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5256ca41663c848ac24783a5161a97730a21696c
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jan 16 15:11:59 2012 +0100

    USB: cdc-wdm: better allocate a buffer that is at least as big as we tell the USB core
    
    commit 655e247daf52b202a6c2d0f8a06dd2051e756ce4 upstream.
    
    As it turns out, there was a mismatch between the allocated inbuf size
    (desc->bMaxPacketSize0, typically something like 64) and the length we
    specified in the URB (desc->wMaxCommand, typically something like 2048)
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1abac982c49f35615f47ff1f94a8ca5ba962bd8
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jan 16 15:11:57 2012 +0100

    USB: cdc-wdm: call wake_up_all to allow driver to shutdown on device removal
    
    commit 62aaf24dc125d7c55c93e313d15611f152b030c7 upstream.
    
    wdm_disconnect() waits for the mutex held by wdm_read() before
    calling wake_up_all().  This causes a deadlock, preventing device removal
    to complete.  Do the wake_up_all() before we start waiting for the locks.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Oliver Neukum <oliver@neukum.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b4e97269313969faf20f4c341af10d734d6d00d
Author: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date:   Thu Jan 26 15:59:00 2012 -0500

    hwmon: (sht15) fix bad error code
    
    commit 6edf3c30af01854c416f8654d3d5d2652470afd4 upstream.
    
    When no platform data was supplied, returned error code was 0.
    
    Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70c3e9e41475dd3d7dbd816130ff8c21e6e1f745
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Jan 27 17:56:06 2012 -0800

    hwmon: (w83627ehf) Disable setting DC mode for pwm2, pwm3 on NCT6776F
    
    commit ad77c3e1808f07fa70f707b1c92a683b7c7d3f85 upstream.
    
    NCT6776F only supports pwm mode for pwm2 and pwm3. Return error if an attempt
    is made to set those pwm channels to DC mode.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c39714f1da06b21e4d4250d030448099912ae79f
Author: Jean Delvare <khali@linux-fr.org>
Date:   Fri Jan 20 10:09:23 2012 -0500

    hwmon: (f71805f) Fix clamping of temperature limits
    
    commit 86b2bbfdbd1fcc4a3aa62ccd3f245c40c5ad5b85 upstream.
    
    Properly clamp temperature limits set by the user. Without this fix,
    attempts to write temperature limits above the maximum supported by
    the chip (255 degrees Celsius) would arbitrarily and unexpectedly
    result in the limit being set to 0 degree Celsius.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd5a1b14d8c2f6ca3692aa4d829aa4afb1319f0e
Author: Andiry Xu <andiry.xu@amd.com>
Date:   Wed Jan 18 17:47:12 2012 +0800

    xHCI: Cleanup isoc transfer ring when TD length mismatch found
    
    commit cf840551a884360841bd3d3ce1ad0868ff0b759a upstream.
    
    When a TD length mismatch is found during isoc TRB enqueue, it directly
    returns -EINVAL. However, isoc transfer is partially enqueued at this time,
    and the ring should be cleared.
    
    This should be backported to kernels as old as 2.6.36, which contain the
    commit 522989a27c7badb608155b1f1dea3487ed431f74 "xhci: Fix failed
    enqueue in the middle of isoch TD."
    
    Signed-off-by: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5c55d20f4251bcc22ce82ff82add9839027e818
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Nov 14 17:51:39 2011 -0800

    xhci: Fix USB 3.0 device restart on resume.
    
    commit d0cd5d482b8a6dc92c6c69a5387baf72ea84f23a upstream.
    
    The xHCI hub port code gets passed a zero-based port number by the USB
    core.  It then adds one to in order to find a device slot by port number
    and device speed by calling xhci_find_slot_id_by_port.  That function
    clearly states it requires a one-based port number.  The xHCI port
    status change event handler was using a zero-based port number that it
    got from find_faked_portnum_from_hw_portnum, not a one-based port
    number.  This lead to the doorbells never being rung for a device after
    a resume, or worse, a different device with the same speed having its
    doorbell rung (which could lead to bad power management in the xHCI host
    controller).
    
    This patch should be backported to kernels as old as 2.6.39.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Acked-by: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a1d0b0af0dcb47bab73e4aa95b4b6afaee4a75c
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Thu Jan 12 10:55:13 2012 +0100

    drivers/usb/host/ehci-fsl.c: add missing iounmap
    
    commit 2492c6e6454ff3edb11e273b071a6ea80a199c71 upstream.
    
    Add missing iounmap in error handling code, in a case where the function
    already preforms iounmap on some other execution path.
    
    A simplified version of the semantic match that finds this problem is as
    follows: (http://coccinelle.lip6.fr/)
    
    // <smpl>
    @@
    expression e;
    statement S,S1;
    int ret;
    @@
    e = \(ioremap\|ioremap_nocache\)(...)
    ... when != iounmap(e)
    if (<+...e...+>) S
    ... when any
        when != iounmap(e)
    *if (...)
       { ... when != iounmap(e)
         return ...; }
    ... when any
    iounmap(e);
    // </smpl>
    
    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a607902f65e6d425f8d115ac891a3c89f3b36d33
Author: Harrison Metzger <harrisonmetz@gmail.com>
Date:   Sun Jan 15 08:43:24 2012 -0600

    USB: usbsevseg: fix max length
    
    commit 1097ccebe630170080c41df0edcf88e0626e9c75 upstream.
    
    This changes the max length for the usb seven segment delcom device to 8
    from 6. Delcom has both 6 and 8 variants and having 8 works fine with
    devices which are only 6.
    
    Signed-off-by: Harrison Metzger <harrisonmetz@gmail.com>
    Signed-off-by: Stuart Pook <stuart@acm.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fc6b6671559d947f3f9a6d8829d3481a17934f4
Author: Ryan Mallon <rmallon@gmail.com>
Date:   Sat Jan 28 08:51:40 2012 +1100

    vmwgfx: Fix assignment in vmw_framebuffer_create_handle
    
    commit bf9c05d5b6d19b3e4c9fe21047694e94f48db89b upstream.
    
    The assignment of handle in vmw_framebuffer_create_handle doesn't actually do anything useful and is incorrectly assigning an integer value to a pointer argument. It appears that this is a typo and should be dereferencing handle rather than assigning to it directly. This fixes a bug where an undefined handle value is potentially returned to user-space.
    
    Signed-off-by: Ryan Mallon <rmallon@gmail.com>
    Reviewed-by: Jakob Bornecrantz<jakob@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5f0416d678ccf6e903002637c3bd9ce82ddb30f
Author: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
Date:   Mon Jan 9 10:58:06 2012 -0200

    jsm: Fixed EEH recovery error
    
    commit 26aa38cafae0dbef3b2fe75ea487c83313c36d45 upstream.
    
    There was an error on the jsm driver that would cause it to be unable to
    recover after a second error is detected.
    
    At the first error, the device recovers properly:
    
    [72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0
    [72521.485695] EEH: This PCI device has failed 1 times in the last hour:
    ...
    [72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm
    [72532.105689] jsm: Port 3 added
    
    However, at the second error, it cascades until EEH disables the device:
    
    [72631.229549] Call Trace:
    ...
    [72641.725687] jsm: Port 3 added
    [72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0
    [72641.725698] EEH: This PCI device has failed 3 times in the last hour:
    
    It was caused because the PCI state was not being saved after the first
    restore. Therefore, at the second recovery the PCI state would not be
    restored.
    
    Signed-off-by: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
    Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
    Acked-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0661faa597be0c7fb7612e8968c2f508e168adf
Author: Rabin Vincent <rabin.vincent@stericsson.com>
Date:   Tue Jan 17 11:52:28 2012 +0100

    serial: amba-pl011: lock console writes against interrupts
    
    commit ef605fdb33883d687cff5ba75095a91b313b4966 upstream.
    
    Protect against pl011_console_write() and the interrupt for
    the console UART running concurrently on different CPUs.
    
    Otherwise the console_write could spin for a long time
    waiting for the UART to become not busy, while the other
    CPU continuously services UART interrupts and keeps the
    UART busy.
    
    The checks for sysrq and oops_in_progress are taken
    from 8250.c.
    
    Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
    Reviewed-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
    Reviewed-by: Bibek Basu <bibek.basu@stericsson.com>
    Reviewed-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47f7a05bd076caf9bc2d60555a1282517c6eca31
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Thu Jan 12 22:55:15 2012 +0100

    TTY: fix UV serial console regression
    
    commit 0eee50af5b13e00b3fb7a5fe8480419a71b8235d upstream.
    
    Commit 74c2107759d (serial: Use block_til_ready helper) and its fixup
    3f582b8c110 (serial: fix termios settings in open) introduced a
    regression on UV systems. The serial eventually freezes while being
    used. It's completely unpredictable and sometimes needs a heap of
    traffic to happen first.
    
    To reproduce this, yast installation was used as it turned out to be
    pretty reliable in reproducing. Especially during installation process
    where one doesn't have an SSH daemon running. And no monitor as the HW
    is completely headless. So this was fun to find. Given the machine
    doesn't boot on vanilla before 2.6.36 final. (And the commits above
    are older.)
    
    Unless there is some bad race in the code, the hardware seems to be
    pretty broken. Otherwise pure MSR read should not cause such a bug,
    or?
    
    So to prevent the bug, revert to the old behavior. I.e. read modem
    status only if we really have to -- for non-CLOCAL set serials.
    Non-CLOCAL works on this hardware OK, I tried. See? I don't.
    
    And document that shit.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    References: https://lkml.org/lkml/2011/12/6/573
    References: https://bugzilla.novell.com/show_bug.cgi?id=718518
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74a6015d2ba393187bbfddcc910afb9e239a3e35
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Jan 13 21:32:06 2012 -0800

    usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
    
    commit 6d443d8499e4e59ffb949759cdded32730f8d2f6 upstream.
    
    Calling edge_remove_sysfs_attrs from edge_disconnect is too late
    as the device has already been removed from sysfs.
    
    Do the simple and obvious thing and make edge_remove_sysfs_attrs
    the port_remove method.
    
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Reported-by: Wolfgang Frisch <wfpub@roembden.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06434d3275a9d6ae3ca39f114523f015e003d8ea
Author: Dan Williams <dcbw@redhat.com>
Date:   Tue Jan 24 17:16:54 2012 -0600

    qcaux: add more Pantech UML190 and UML290 ports
    
    commit 074cc73506f529f39fef32ad1c9e1d4cdd8acf6c upstream.
    
    More ports we now know how to talk to.
    
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c40c07af28b365175593f69a7391a3b6cfd8ac12
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jan 16 12:41:48 2012 +0100

    USB: cdc-wdm: use two mutexes to allow simultaneous read and write
    
    commit e8537bd2c4f325a4796da33564ddcef9489b7feb upstream.
    
    using a separate read and write mutex for locking is sufficient to make the
    driver accept simultaneous read and write. This improves useability a lot.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 906e114c35cd8f98be1f672a2f32c0cf9800296b
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jan 16 12:41:47 2012 +0100

    USB: cdc-wdm: updating desc->length must be protected by spin_lock
    
    commit c428b70c1e115c5649707a602742e34130d19428 upstream.
    
    wdm_in_callback() will also touch this field, so we cannot change it without locking
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b09a4eb286bdc9dbc4c9620faa562c8470b2366
Author: Alan Cox <alan@linux.intel.com>
Date:   Thu Jan 26 17:41:34 2012 +0000

    USB: ftdi_sio: Add more identifiers
    
    commit 2353f806c97020d4c7709f15eebb49b591f7306d upstream.
    
    0x04d8, 0x000a: Hornby Elite
    
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f43828eb93fe27108df3e81090bcf0cdbfe882e3
Author: Peter Naulls <peter@chocky.org>
Date:   Tue Jan 17 18:27:09 2012 -0800

    USB: serial: ftdi additional IDs
    
    commit fc216ec363f4d174932df90bbf35c77d0540e561 upstream.
    
    I tested this against 2.6.39 in the Ubuntu kernel, however I see the IDs
    are not in latest 3.2 git.
    
    This adds IDs for the FTDI controller in the Rainforest Automation
    Zigbee dongle.
    
    Signed-off-by: Peter Naulls <peter@chocky.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab9ef74e2580b4909bd9fb0c381027f54cb6d3de
Author: Peter Korsgaard <jacmet@sunsite.dk>
Date:   Wed Jan 18 23:43:45 2012 +0100

    USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
    
    commit 55f13aeae0346f0c89bfface91ad9a97653dc433 upstream.
    
    Port A for JTAG, port B for serial.
    
    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b89a3229080c1464ab892cc413cc806b06d4ffa3
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Jan 18 01:46:00 2012 +0100

    USB: ftdi_sio: fix initial baud rate
    
    commit 108e02b12921078a59dcacd048079ece48a4a983 upstream.
    
    Fix regression introduced by commit b1ffb4c851f1 ("USB: Fix Corruption
    issue in USB ftdi driver ftdi_sio.c") which caused the termios settings
    to no longer be initialised at open. Consequently it was no longer
    possible to set the port to the default speed of 9600 baud without first
    changing to another baud rate and back again.
    
    Reported-by: Roland Ramthun <mail@roland-ramthun.de>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Tested-by: Roland Ramthun <mail@roland-ramthun.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38a464d3f7a94a7bd3cac9d8cd18474385e27633
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Jan 10 23:33:37 2012 +0100

    USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
    
    commit eb833a9e0972f60beb4ab8104ad7ef6bf30f02fc upstream.
    
    Return EINVAL if new baud_base does not match the current one.
    
    The baud_base is device specific and can not be changed. This restores
    the old (pre-2005) behaviour which was changed due to a
    misunderstanding regarding this fact (see
    https://lkml.org/lkml/2005/1/20/84).
    
    Reported-by: Torbjörn Lofterud <torbjorn@pi.nxs.se>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 163071a2a0d661eb3b8abe14d892a88e6dedc77f
Author: Kentaro Matsuyama <kentaro.matsuyama@gmail.com>
Date:   Thu Jan 12 23:07:51 2012 +0900

    USB: option: Add LG docomo L-02C
    
    commit e423d7401fd0717cb56a6cf51dd8341cc3e800d2 upstream.
    
    Add vendor and product ID for USB 3G/LTE modem of docomo L-02C
    
    Signed-off-by: Kentaro Matsuyama <kentaro.matsuyama@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95086de856ca703588967f63cc54b8059db55888
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jan 20 12:10:18 2012 +0100

    ARM: 7296/1: proc-v7.S: remove HARVARD_CACHE preprocessor guards
    
    commit 612539e81f655f6ac73c7af1da8701c1ee618aee upstream.
    
    On v7, we use the same cache maintenance instructions for data lines
    as for unified lines. This was not the case for v6, where HARVARD_CACHE
    was defined to indicate the L1 cache topology.
    
    This patch removes the erroneous compile-time check for HARVARD_CACHE in
    proc-v7.S, ensuring that we perform I-side invalidation at boot.
    
    Reported-and-Acked-by: Shawn Guo <shawn.guo@linaro.org>
    
    Acked-by: Catalin Marinas <Catalin.Marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e29fa93520b401b81a719fe053f06c6937d5b66
Author: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
Date:   Thu Jan 12 11:07:43 2012 +0530

    mach-ux500: enable ARM errata 764369
    
    commit d65015f7c5c5be9fd3f5e567889c844ba81bdc9c upstream.
    
    This applies ARM errata 764369 for all ux500 platforms.
    
    Signed-off-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e21ed1cebed09df11b4bf7809fd6d69b25457127
Author: Jonathan Nieder <jrnieder@gmail.com>
Date:   Mon Aug 8 06:22:43 2011 +0200

    cap_syslog: don't use WARN_ONCE for CAP_SYS_ADMIN deprecation warning
    
    commit f2c0d0266cc5eb36a4aa44944b4096ec121490aa upstream.
    
    syslog-ng versions before 3.3.0beta1 (2011-05-12) assume that
    CAP_SYS_ADMIN is sufficient to access syslog, so ever since CAP_SYSLOG
    was introduced (2010-11-25) they have triggered a warning.
    
    Commit ee24aebffb75 ("cap_syslog: accept CAP_SYS_ADMIN for now")
    improved matters a little by making syslog-ng work again, just keeping
    the WARN_ONCE().  But still, this is a warning that writes a stack trace
    we don't care about to syslog, sets a taint flag, and alarms sysadmins
    when nothing worse has happened than use of an old userspace with a
    recent kernel.
    
    Convert the WARN_ONCE to a printk_once to avoid that while continuing to
    give userspace developers a hint that this is an unwanted
    backward-compatibility feature and won't be around forever.
    
    Reported-by: Ralf Hildebrandt <ralf.hildebrandt@charite.de>
    Reported-by: Niels <zorglub_olsen@hotmail.com>
    Reported-by: Paweł Sikora <pluto@agmk.net>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Liked-by: Gergely Nagy <algernon@madhouse-project.org>
    Acked-by: Serge Hallyn <serge@hallyn.com>
    Acked-by: James Morris <jmorris@namei.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e2d7afcbacf7683c72e98980c6a9284a5a2a01c
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Jan 6 19:45:34 2012 -0200

    drm/i915/sdvo: always set positive sync polarity
    
    commit ba68e086223a5f149f37bf8692c8cdbf1b0ba3ef upstream.
    
    This is a revert of 81a14b46846fea0741902e8d8dfcc6c6c78154c8.
    
    We already set the mode polarity using the SDVO commands with struct
    intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch.
    The documentation, despite not clear, can also be interpreted in a way
    that suggests this patch is needed.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=15766
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42174
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43333
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80f1aff93c34feff6ad229ff2a1307e82cb5b132
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jan 26 15:56:16 2012 +0100

    ALSA: hda - Fix silent output on Haier W18 laptop
    
    commit b3a81520bd37a28f77cb0f7002086fb14061824d upstream.
    
    The very same problem is seen on Haier W18 laptop with ALC861 as seen
    on ASUS A6Rp, which was fixed by the commit 3b25eb69.
    Now we just need to add a new SSID entry pointing to the same fixup.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42656
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fd55451aab99558e8b3ccefd88a1c14ed888c75
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 25 09:55:46 2012 +0100

    ALSA: hda - Fix silent output on ASUS A6Rp
    
    commit 3b25eb690e8c7424eecffe1458c02b87b32aa001 upstream.
    
    The refactoring of Realtek codec driver in 3.2 kernel caused a
    regression for ASUS A6Rp laptop; it doesn't give any output.
    The reason was that this machine has a secret master mute (or EAPD)
    control via NID 0x0f VREF.  Setting VREF50 on this node makes the
    sound working again.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42588
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 231f0496129d5d41ae77cc2410e3cea97540cd7b
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date:   Fri Jan 20 17:44:12 2012 +0100

    x86/microcode_amd: Add support for CPU family specific container files
    
    commit 5b68edc91cdc972c46f76f85eded7ffddc3ff5c2 upstream.
    
    We've decided to provide CPU family specific container files
    (starting with CPU family 15h). E.g. for family 15h we have to
    load microcode_amd_fam15h.bin instead of microcode_amd.bin
    
    Rationale is that starting with family 15h patch size is larger
    than 2KB which was hard coded as maximum patch size in various
    microcode loaders (not just Linux).
    
    Container files which include patches larger than 2KB cause
    different kinds of trouble with such old patch loaders. Thus we
    have to ensure that the default container file provides only
    patches with size less than 2KB.
    
    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Cc: Borislav Petkov <borislav.petkov@amd.com>
    Cc: <stable@kernel.org>
    Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com
    [ documented the naming convention and tidied the code a bit. ]
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c6f009ebfcdae4196be7e456c99ad44eb013420
Author: Russ Anderson <rja@sgi.com>
Date:   Wed Jan 18 20:07:54 2012 -0600

    x86/uv: Fix uv_gpa_to_soc_phys_ram() shift
    
    commit 5a51467b146ab7948d2f6812892eac120a30529c upstream.
    
    uv_gpa_to_soc_phys_ram() was inadvertently ignoring the
    shift values.  This fix takes the shift into account.
    
    Signed-off-by: Russ Anderson <rja@sgi.com>
    Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 810b80a70cd24a682239d82370725cc3b847bab8
Author: Dave Chinner <dchinner@redhat.com>
Date:   Thu Jan 26 13:47:42 2012 -0600

    xfs: fix endian conversion issue in discard code
    
    commit b1c770c273a4787069306fc82aab245e9ac72e9d upstream
    
    When finding the longest extent in an AG, we read the value directly
    out of the AGF buffer without endian conversion. This will give an
    incorrect length, resulting in FITRIM operations potentially not
    trimming everything that it should.
    
    Note, for 3.0-stable this has been modified to apply to
    fs/xfs/linux-2.6/xfs_discard.c instead of fs/xfs/xfs_discard.c.  -bpm
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffee9a18f29a0645c2d117083e025f557c738018
Author: Nick Bowler <nbowler@elliptictech.com>
Date:   Thu Nov 10 09:01:27 2011 +0000

    ah: Don't return NET_XMIT_DROP on input.
    
    commit 4b90a603a1b21d63cf743cc833680cb195a729f6 upstream.
    
    When the ahash driver returns -EBUSY, AH4/6 input functions return
    NET_XMIT_DROP, presumably copied from the output code path.  But
    returning transmit codes on input doesn't make a lot of sense.
    Since NET_XMIT_DROP is a positive int, this gets interpreted as
    the next header type (i.e., success).  As that can only end badly,
    remove the check.
    
    Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da8ae089a79cdc37589cab581a2ca9cf48f98904
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Mon Dec 5 18:22:48 2011 +0100

    ftrace: Fix unregister ftrace_ops accounting
    
    commit 30fb6aa74011dcf595f306ca2727254d708b786e upstream.
    
    Multiple users of the function tracer can register their functions
    with the ftrace_ops structure. The accounting within ftrace will
    update the counter on each function record that is being traced.
    When the ftrace_ops filtering adds or removes functions, the
    function records will be updated accordingly if the ftrace_ops is
    still registered.
    
    When a ftrace_ops is removed, the counter of the function records,
    that the ftrace_ops traces, are decremented. When they reach zero
    the functions that they represent are modified to stop calling the
    mcount code.
    
    When changes are made, the code is updated via stop_machine() with
    a command passed to the function to tell it what to do. There is an
    ENABLE and DISABLE command that tells the called function to enable
    or disable the functions. But the ENABLE is really a misnomer as it
    should just update the records, as records that have been enabled
    and now have a count of zero should be disabled.
    
    The DISABLE command is used to disable all functions regardless of
    their counter values. This is the big off switch and is not the
    complement of the ENABLE command.
    
    To make matters worse, when a ftrace_ops is unregistered and there
    is another ftrace_ops registered, neither the DISABLE nor the
    ENABLE command are set when calling into the stop_machine() function
    and the records will not be updated to match their counter. A command
    is passed to that function that will update the mcount code to call
    the registered callback directly if it is the only one left. This
    means that the ftrace_ops that is still registered will have its callback
    called by all functions that have been set for it as well as the ftrace_ops
    that was just unregistered.
    
    Here's a way to trigger this bug. Compile the kernel with
    CONFIG_FUNCTION_PROFILER set and with CONFIG_FUNCTION_GRAPH not set:
    
     CONFIG_FUNCTION_PROFILER=y
     # CONFIG_FUNCTION_GRAPH is not set
    
    This will force the function profiler to use the function tracer instead
    of the function graph tracer.
    
      # cd /sys/kernel/debug/tracing
      # echo schedule > set_ftrace_filter
      # echo function > current_tracer
      # cat set_ftrace_filter
     schedule
      # cat trace
     # tracer: nop
     #
     # entries-in-buffer/entries-written: 692/68108025   #P:4
     #
     #                              _-----=> irqs-off
     #                             / _----=> need-resched
     #                            | / _---=> hardirq/softirq
     #                            || / _--=> preempt-depth
     #                            ||| /     delay
     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
     #              | |       |   ||||       |         |
          kworker/0:2-909   [000] ....   531.235574: schedule <-worker_thread
               <idle>-0     [001] .N..   531.235575: schedule <-cpu_idle
          kworker/0:2-909   [000] ....   531.235597: schedule <-worker_thread
                 sshd-2563  [001] ....   531.235647: schedule <-schedule_hrtimeout_range_clock
    
      # echo 1 > function_profile_enabled
      # echo 0 > function_porfile_enabled
      # cat set_ftrace_filter
     schedule
      # cat trace
     # tracer: function
     #
     # entries-in-buffer/entries-written: 159701/118821262   #P:4
     #
     #                              _-----=> irqs-off
     #                             / _----=> need-resched
     #                            | / _---=> hardirq/softirq
     #                            || / _--=> preempt-depth
     #                            ||| /     delay
     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
     #              | |       |   ||||       |         |
               <idle>-0     [002] ...1   604.870655: local_touch_nmi <-cpu_idle
               <idle>-0     [002] d..1   604.870655: enter_idle <-cpu_idle
               <idle>-0     [002] d..1   604.870656: atomic_notifier_call_chain <-enter_idle
               <idle>-0     [002] d..1   604.870656: __atomic_notifier_call_chain <-atomic_notifier_call_chain
    
    The same problem could have happened with the trace_probe_ops,
    but they are modified with the set_frace_filter file which does the
    update at closure of the file.
    
    The simple solution is to change ENABLE to UPDATE and call it every
    time an ftrace_ops is unregistered.
    
    Link: http://lkml.kernel.org/r/1323105776-26961-3-git-send-email-jolsa@redhat.com
    
    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ffe3ccf80eba0ac9ca71c41e7357d92f1c08fc3
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Wed Jul 13 15:08:31 2011 -0400

    ftrace: Update filter when tracing enabled in set_ftrace_filter()
    
    commit 072126f4529196f71a97960248bca54fd4554c2d upstream.
    
    Currently, if set_ftrace_filter() is called when the ftrace_ops is
    active, the function filters will not be updated. They will only be updated
    when tracing is disabled and re-enabled.
    
    Update the functions immediately during set_ftrace_filter().
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f935e6192f9e068da8f8395f032ff4b721fe8510
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Wed Jul 13 15:03:44 2011 -0400

    ftrace: Balance records when updating the hash
    
    commit 41fb61c2d08107ce96a5dcb3a6289b2afd3e135c upstream.
    
    Whenever the hash of the ftrace_ops is updated, the record counts
    must be balance. This requires disabling the records that are set
    in the original hash, and then enabling the records that are set
    in the updated hash.
    
    Moving the update into ftrace_hash_move() removes the bug where the
    hash was updated but the records were not, which results in ftrace
    triggering a warning and disabling itself because the ftrace_ops filter
    is updated while the ftrace_ops was registered, and then the failure
    happens when the ftrace_ops is unregistered.
    
    The current code will not trigger this bug, but new code will.
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ce5564096c4444197e6f7dc83a9dbc63392b084
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Sat Jan 14 21:40:57 2012 +0300

    crypto: sha512 - reduce stack usage to safe number
    
    commit 51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 upstream.
    
    For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16].
    Consequently, keeping all W[80] array on stack is unnecessary,
    only 16 values are really needed.
    
    Using W[16] instead of W[80] greatly reduces stack usage
    (~750 bytes to ~340 bytes on x86_64).
    
    Line by line explanation:
    * BLEND_OP
      array is "circular" now, all indexes have to be modulo 16.
      Round number is positive, so remainder operation should be
      without surprises.
    
    * initial full message scheduling is trimmed to first 16 values which
      come from data block, the rest is calculated before it's needed.
    
    * original loop body is unrolled version of new SHA512_0_15 and
      SHA512_16_79 macros, unrolling was done to not do explicit variable
      renaming. Otherwise it's the very same code after preprocessing.
      See sha1_transform() code which does the same trick.
    
    Patch survives in-tree crypto test and original bugreport test
    (ping flood with hmac(sha512).
    
    See FIPS 180-2 for SHA-512 definition
    http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ca6029f1a492528e65bc676113eeb1acf3779e4
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Sat Jan 14 21:27:37 2012 +0300

    crypto: sha512 - make it work, undo percpu message schedule
    
    commit 84e31fdb7c797a7303e0cc295cb9bc8b73fb872d upstream.
    
    commit f9e2bca6c22d75a289a349f869701214d63b5060
    aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
    created global message schedule area.
    
    If sha512_update will ever be entered twice, hash will be silently
    calculated incorrectly.
    
    Probably the easiest way to notice incorrect hashes being calculated is
    to run 2 ping floods over AH with hmac(sha512):
    
    	#!/usr/sbin/setkey -f
    	flush;
    	spdflush;
    	add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
    	add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
    	spdadd IP1 IP2 any -P out ipsec ah/transport//require;
    	spdadd IP2 IP1 any -P in  ipsec ah/transport//require;
    
    XfrmInStateProtoError will start ticking with -EBADMSG being returned
    from ah_input(). This never happens with, say, hmac(sha1).
    
    With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
    with multiple bidirectional ping flood streams like it doesn't tick
    with SHA-1.
    
    After this patch sha512_transform() will start using ~750 bytes of stack on x86_64.
    This is OK for simple loads, for something more heavy, stack reduction will be done
    separatedly.
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fbe11fed22ed2751aaf4b4926f27730aaac5470
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jan 11 18:52:10 2012 +0000

    xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()
    
    commit 9b025eb3a89e041bab6698e3858706be2385d692 upstream.
    
    Commit b52a360b forgot to call xfs_iunlock() when it detected corrupted
    symplink and bailed out. Fix it by jumping to 'out' instead of doing return.
    
    CC: Carlos Maiolino <cmaiolino@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Alex Elder <elder@kernel.org>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90af660bec3b2d47e17cb3caae742810656e2d4f
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Tue Jan 24 18:54:21 2012 +0100

    drm: Fix authentication kernel crash
    
    commit 598781d71119827b454fd75d46f84755bca6f0c6 upstream.
    
    If the master tries to authenticate a client using drm_authmagic and
    that client has already closed its drm file descriptor,
    either wilfully or because it was terminated, the
    call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
    and corrupt it.
    
    Typically this results in a hard system hang.
    
    This patch fixes that problem by removing any authentication tokens
    (struct drm_magic_entry) open for a file descriptor when that file
    descriptor is closed.
    
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c196878589eb5f88e244a557a55b229a3c285b3b
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Sun Jan 15 08:51:12 2012 -0500

    drm/radeon/kms: Add an MSI quirk for Dell RS690
    
    commit 44517c44496062180a6376cc704b33129441ce60 upstream.
    
    Interrupts only work with MSIs.
    https://bugs.freedesktop.org/show_bug.cgi?id=37679
    
    Reported-by: Dmitry Podgorny <pasis.uax@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df29ca6c2b93813c987b35972b215d9b2a0a9159
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Jan 24 10:02:22 2012 -0600

    eCryptfs: Fix oops when printing debug info in extent crypto functions
    
    commit 58ded24f0fcb85bddb665baba75892f6ad0f4b8a upstream.
    
    If pages passed to the eCryptfs extent-based crypto functions are not
    mapped and the module parameter ecryptfs_verbosity=1 was specified at
    loading time, a NULL pointer dereference will occur.
    
    Note that this wouldn't happen on a production system, as you wouldn't
    pass ecryptfs_verbosity=1 on a production system. It leaks private
    information to the system logs and is for debugging only.
    
    The debugging info printed in these messages is no longer very useful
    and rather than doing a kmap() in these debugging paths, it will be
    better to simply remove the debugging paths completely.
    
    https://launchpad.net/bugs/913651
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 714ca4ef28276f142b00ff2e1893f472cc30b07b
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Thu Jan 19 20:33:44 2012 -0600

    eCryptfs: Check inode changes in setattr
    
    commit a261a03904849c3df50bd0300efb7fb3f865137d upstream.
    
    Most filesystems call inode_change_ok() very early in ->setattr(), but
    eCryptfs didn't call it at all. It allowed the lower filesystem to make
    the call in its ->setattr() function. Then, eCryptfs would copy the
    appropriate inode attributes from the lower inode to the eCryptfs inode.
    
    This patch changes that and actually calls inode_change_ok() on the
    eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
    would happen earlier in ecryptfs_setattr(), but there are some possible
    inode initialization steps that must happen first.
    
    Since the call was already being made on the lower inode, the change in
    functionality should be minimal, except for the case of a file extending
    truncate call. In that case, inode_newsize_ok() was never being
    called on the eCryptfs inode. Rather than inode_newsize_ok() catching
    maximum file size errors early on, eCryptfs would encrypt zeroed pages
    and write them to the lower filesystem until the lower filesystem's
    write path caught the error in generic_write_checks(). This patch
    introduces a new function, called ecryptfs_inode_newsize_ok(), which
    checks if the new lower file size is within the appropriate limits when
    the truncate operation will be growing the lower file.
    
    In summary this change prevents eCryptfs truncate operations (and the
    resulting page encryptions), which would exceed the lower filesystem
    limits or FSIZE rlimits, from ever starting.
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reviewed-by: Li Wang <liwang@nudt.edu.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8d66a0b58b353d47b05891fd20b3bdc4c8a8015
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Wed Jan 18 18:30:04 2012 -0600

    eCryptfs: Make truncate path killable
    
    commit 5e6f0d769017cc49207ef56996e42363ec26c1f0 upstream.
    
    ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
    page, zeroes out the appropriate portions, and then encrypts the page
    before writing it to the lower filesystem. It was unkillable and due to
    the lack of sparse file support could result in tying up a large portion
    of system resources, while encrypting pages of zeros, with no way for
    the truncate operation to be stopped from userspace.
    
    This patch adds the ability for ecryptfs_write() to detect a pending
    fatal signal and return as gracefully as possible. The intent is to
    leave the lower file in a useable state, while still allowing a user to
    break out of the encryption loop. If a pending fatal signal is detected,
    the eCryptfs inode size is updated to reflect the modified inode size
    and then -EINTR is returned.
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b9f40e785724a265fb6027216fb2bd1e97894f7
Author: Tim Gardner <tim.gardner@canonical.com>
Date:   Thu Jan 12 16:31:55 2012 +0100

    ecryptfs: Improve metadata read failure logging
    
    commit 30373dc0c87ffef68d5628e77d56ffb1fa22e1ee upstream.
    
    Print inode on metadata read failure. The only real
    way of dealing with metadata read failures is to delete
    the underlying file system file. Having the inode
    allows one to 'find . -inum INODE`.
    
    [tyhicks@canonical.com: Removed some minor not-for-stable parts]
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdce30003c234575bbcfddb0980adc04b82408c7
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Thu Jan 12 11:30:44 2012 +0100

    eCryptfs: Sanitize write counts of /dev/ecryptfs
    
    commit db10e556518eb9d21ee92ff944530d84349684f4 upstream.
    
    A malicious count value specified when writing to /dev/ecryptfs may
    result in a a very large kernel memory allocation.
    
    This patch peeks at the specified packet payload size, adds that to the
    size of the packet headers and compares the result with the write count
    value. The resulting maximum memory allocation size is approximately 532
    bytes.
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3c9ccb3e13812e13be045a97ab309a4e23d9ac4
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 23 18:23:36 2012 +0100

    ALSA: hda - Fix silent outputs from docking-station jacks of Dell laptops
    
    commit b4ead019afc201f71c39cd0dfcaafed4a97b3dd2 upstream.
    
    The recent change of the power-widget handling for IDT codecs caused
    the silent output from the docking-station line-out jack.  This was
    partially fixed by the commit f2cbba7602383cd9cdd21f0a5d0b8bd1aad47b33
    "ALSA: hda - Fix the lost power-setup of seconary pins after PM resume".
    But the line-out on the docking-station is still silent when booted
    with the jack plugged even by this fix.
    
    The remainig bug is that the power-widget is set off in stac92xx_init()
    because the pins in cfg->line_out_pins[] aren't checked there properly
    but only hp_pins[] are checked in is_nid_hp_pin().
    
    This patch fixes the problem by checking both HP and line-out pins
    and leaving the power-map correctly.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42637
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
