11 years agoPCI: Rework ASPM disable code
Matthew Garrett [Thu, 10 Nov 2011 21:38:33 +0000 (16:38 -0500)]
PCI: Rework ASPM disable code

commit 3c076351c4027a56d5005a39a0b518a4ba393ce2 upstream.

Right now we forcibly clear ASPM state on all devices if the BIOS indicates
that the feature isn't supported. Based on the Microsoft presentation
"PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
that this may be an error. The implication is that unless the platform
grants full control via _OSC, Windows will not touch any PCIe features -
including ASPM. In that case clearing ASPM state would be an error unless
the platform has granted us that control.

This patch reworks the ASPM disabling code such that the actual clearing
of state is triggered by a successful handoff of PCIe control to the OS.
The general ASPM code undergoes some changes in order to ensure that the
ability to clear the bits isn't overridden by ASPM having already been
disabled. Further, this theoretically now allows for situations where
only a subset of PCIe roots hand over control, leaving the others in the
BIOS state.

It's difficult to know for sure that this is the right thing to do -
there's zero public documentation on the interaction between all of these
components. But enough vendors enable ASPM on platforms and then set this
bit that it seems likely that they're expecting the OS to leave them alone.

Measured to save around 5W on an idle Thinkpad X220.

Signed-off-by: Matthew Garrett <>
Signed-off-by: Jesse Barnes <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoLinux 3.2.4 v3.2.4
Greg Kroah-Hartman [Fri, 3 Feb 2012 20:39:51 +0000 (12:39 -0800)]
Linux 3.2.4

11 years agoRevert "ASoC: Don't go through cache when applying WM5100 rev A updates"
Greg Kroah-Hartman [Fri, 3 Feb 2012 20:27:49 +0000 (12:27 -0800)]
Revert "ASoC: Don't go through cache when applying WM5100 rev A updates"

This reverts commit 78fd75340768980ce6ca646106762a6928289e0c (upstream
commit 495174a8ffbaa0d15153d855cf206cdc46d51cf4) as it breaks the build.

Reported-by: Tim Gardner <>
Cc: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoRevert "ASoC: Mark WM5100 register map cache only when going into BIAS_OFF"
Greg Kroah-Hartman [Fri, 3 Feb 2012 20:26:40 +0000 (12:26 -0800)]
Revert "ASoC: Mark WM5100 register map cache only when going into BIAS_OFF"

This reverts commit 11a17e56ac9c607c6eaecf64b618cd17c828ade0
(e53e417331c57b9b97e3f8be870214a02c99265c upstream) as it breaks the

Reported-by: Tim Gardner <>
Cc: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoLinux 3.2.3 v3.2.3
Greg Kroah-Hartman [Fri, 3 Feb 2012 17:23:33 +0000 (09:23 -0800)]
Linux 3.2.3

11 years agomach-ux500: no MMC_CAP_SD_HIGHSPEED on Snowball
Philippe Langlais [Fri, 20 Jan 2012 08:20:40 +0000 (09:20 +0100)]
mach-ux500: no MMC_CAP_SD_HIGHSPEED on Snowball

commit 2ab1159e80e8f416071e9f51e4f77b9173948296 upstream.

MMC_CAP_SD_HIGHSPEED is not supported on Snowball board resulting on
initialization errors.

Signed-off-by: Mathieu Poirier <>
Signed-off-by: Fredrik Soderstedt <>
Signed-off-by: Philippe Langlais <>
Signed-off-by: Linus Walleij <>
11 years agoUSB: cp210x: allow more baud rates above 1Mbaud
Johan Hovold [Sun, 15 Jan 2012 23:36:53 +0000 (00:36 +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 <>
Cc: Preston Fick <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cp210x: initialise baud rate at open
Johan Hovold [Sun, 15 Jan 2012 23:36:52 +0000 (00:36 +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 <>
Cc: Preston Fick <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cp210x: clean up, refactor and document speed handling
Johan Hovold [Sun, 15 Jan 2012 23:36:51 +0000 (00:36 +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 <>
Cc: Preston Fick <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cp210x: fix up set_termios variables
Johan Hovold [Sun, 15 Jan 2012 23:36:49 +0000 (00:36 +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 <>
Cc: Preston Fick <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cp210x: do not map baud rates to B0
Johan Hovold [Sun, 15 Jan 2012 23:36:50 +0000 (00:36 +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 <>
Cc: Preston Fick <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cp210x: fix CP2104 baudrate usage
Preston Fick [Tue, 17 Jan 2012 00:14:09 +0000 (18:14 -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:

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"

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 This patch has been developed and test on the
3.2.0 mainline kernel version under Ubuntu 10.11.

Signed-off-by: Preston Fick <>
[duplicate patch also sent by Johan - gregkh]
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cp210x: call generic open last in open
Johan Hovold [Sun, 15 Jan 2012 23:36:48 +0000 (00:36 +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 <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
Renato Caldas [Fri, 6 Jan 2012 15:20:51 +0000 (15:20 +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 <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agotcp: md5: using remote adress for md5 lookup in rst packet
shawnlu [Fri, 20 Jan 2012 12:22:04 +0000 (12:22 +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 <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agotcp: fix tcp_trim_head() to adjust segment count with skb MSS
Neal Cardwell [Sat, 28 Jan 2012 17:29:46 +0000 (17:29 +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

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 <>
Acked-by: Nandita Dukkipati <>
Acked-by: Ilpo Järvinen <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agords: Make rds_sock_lock BH rather than IRQ safe.
David S. Miller [Tue, 24 Jan 2012 22:03:44 +0000 (17:03 -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 <>
Reported-by: Josh Boyer <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agonet: reintroduce missing rcu_assign_pointer() calls
Eric Dumazet [Thu, 12 Jan 2012 04:41:32 +0000 (04:41 +0000)]
net: reintroduce missing rcu_assign_pointer() calls

[ Upstream commit cf778b00e96df6d64f8e21b8395d1f8a859ecdc7 ]

commit a9b3cd7f32 (rcu: convert uses of rcu_assign_pointer(x, NULL) to
RCU_INIT_POINTER) did a lot of incorrect changes, since it did a
complete conversion of rcu_assign_pointer(x, y) to RCU_INIT_POINTER(x,

We miss needed barriers, even on x86, when y is not NULL.

Signed-off-by: Eric Dumazet <>
CC: Stephen Hemminger <>
CC: Paul E. McKenney <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agonet: bpf_jit: fix divide by 0 generation
Eric Dumazet [Wed, 18 Jan 2012 07:21:42 +0000 (07:21 +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 <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agomacvlan: fix a possible use after free
Eric Dumazet [Mon, 23 Jan 2012 05:38:59 +0000 (05:38 +0000)]
macvlan: fix a possible use after free

[ Upstream commit 4ec7ac1203bcf21f5e3d977c9818b1a56c9ef40d ]

Commit bc416d9768 (macvlan: handle fragmented multicast frames) added a
possible use after free in macvlan_handle_frame(), since
ip_check_defrag() uses pskb_may_pull() : skb header can be reallocated.

Signed-off-by: Eric Dumazet <>
Cc: Ben Greear <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agol2tp: l2tp_ip - fix possible oops on packet receive
James Chapman [Wed, 25 Jan 2012 02:39:05 +0000 (02:39 +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

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 <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agobonding: fix enslaving in alb mode when link down
Jiri Bohac [Wed, 18 Jan 2012 12:24:54 +0000 (12:24 +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 <>
Signed-off-by: Jiri Bohac <>
Signed-off-by: Jay Vosburgh <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoaf_unix: fix EPOLLET regression for stream sockets
Eric Dumazet [Sat, 28 Jan 2012 16:11:03 +0000 (16:11 +0000)]
af_unix: fix EPOLLET regression for stream sockets

[ Upstream commit 6f01fd6e6f6809061b56e78f1e8d143099716d70 ]

Commit 0884d7aa24 (AF_UNIX: Fix poll blocking problem when reading from
a stream socket) added a regression for epoll() in Edge Triggered mode

Appropriate fix is to use skb_peek()/skb_unlink() instead of
skb_dequeue(), and only call skb_unlink() when skb is fully consumed.

This remove the need to requeue a partial skb into sk_receive_queue head
and the extra sk->sk_data_ready() calls that added the regression.

This is safe because once skb is given to sk_receive_queue, it is not
modified by a writer, and readers are serialized by u->readlock mutex.

This also reduce number of spinlock acquisition for small reads or
MSG_PEEK users so should improve overall performance.

Reported-by: Nick Mathewson <>
Signed-off-by: Eric Dumazet <>
Cc: Alexey Moiseytsev <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agonet caif: Register properly as a pernet subsystem.
Eric W. Biederman [Thu, 26 Jan 2012 14:04:53 +0000 (14:04 +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 <>
Acked-by: Sjur Brændeland <>
Tested-by: Sasha Levin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agonetns: Fail conspicously if someone uses net_generic at an inappropriate time.
Eric W. Biederman [Thu, 26 Jan 2012 14:02:55 +0000 (14:02 +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 <>
Tested-by: Sasha Levin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agonetns: fix net_alloc_generic()
Eric Dumazet [Thu, 26 Jan 2012 00:41:38 +0000 (00:41 +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 <>
Tested-by: Sasha Levin <>
Signed-off-by: Eric Dumazet <>
Cc: Sjur Brændeland <>
Cc: Eric W. Biederman <>
Cc: Pavel Emelyanov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cdc-wdm: Avoid hanging on interface with no USB_CDC_DMM_TYPE
Bjørn Mork [Fri, 20 Jan 2012 00:49:57 +0000 (01:49 +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 <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cdc-wdm: better allocate a buffer that is at least as big as we tell the USB...
Bjørn Mork [Mon, 16 Jan 2012 14:11:59 +0000 (15:11 +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 <>
Cc: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cdc-wdm: call wake_up_all to allow driver to shutdown on device removal
Bjørn Mork [Mon, 16 Jan 2012 14:11:57 +0000 (15:11 +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 <>
Cc: Oliver Neukum <>
Cc: stable <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agohwmon: (sht15) fix bad error code
Vivien Didelot [Thu, 26 Jan 2012 20:59:00 +0000 (15:59 -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 <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agohwmon: (w83627ehf) Disable setting DC mode for pwm2, pwm3 on NCT6776F
Guenter Roeck [Sat, 28 Jan 2012 01:56:06 +0000 (17:56 -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 <>
Acked-by: Jean Delvare <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agohwmon: (f71805f) Fix clamping of temperature limits
Jean Delvare [Fri, 20 Jan 2012 15:09:23 +0000 (10:09 -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 <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agousb: musb: davinci: fix build breakage
Sekhar Nori [Wed, 28 Dec 2011 06:32:57 +0000 (12:02 +0530)]
usb: musb: davinci: fix build breakage

commit 006896fc612f11bf0624db7814a75d0d5410855f upstream.

Commit 0020afb369859472a461ef4af6410732e929d402 (ARM: mach-davinci:
remove mach/memory.h) removed mach/memory.h for DaVinci which broke
DaVinci MUSB build.

mach/memory.h is not actually needed in davinci.c, so remove it.
While at it, also remove some more machine specific inclulde
files which are not needed for build.

Tested on DM644x EVM using USB card reader.

Signed-off-by: Sekhar Nori <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoxHCI: Cleanup isoc transfer ring when TD length mismatch found
Andiry Xu [Wed, 18 Jan 2012 09:47:12 +0000 (17:47 +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 <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoxhci: Fix USB 3.0 device restart on resume.
Sarah Sharp [Tue, 15 Nov 2011 01:51:39 +0000 (17:51 -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

This patch should be backported to kernels as old as 2.6.39.

Signed-off-by: Sarah Sharp <>
Acked-by: Andiry Xu <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agodrivers/usb/host/ehci-fsl.c: add missing iounmap
Julia Lawall [Thu, 12 Jan 2012 09:55:13 +0000 (10:55 +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: (

// <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
// </smpl>

Signed-off-by: Julia Lawall <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agousb: gadget: storage: endian fix
Andiry Xu [Wed, 4 Jan 2012 07:18:27 +0000 (15:18 +0800)]
usb: gadget: storage: endian fix

commit a85016390135d577c457876d0e905095600751de upstream.

Fix some endian issues for storage gadgets.

Signed-off-by: Andiry Xu <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agousb: gadget: langwell: don't call gadget's disconnect()
Alexander Shishkin [Wed, 21 Dec 2011 08:19:40 +0000 (10:19 +0200)]
usb: gadget: langwell: don't call gadget's disconnect()

commit 37fd37108449d574da11aa9055c5c8afb39ff226 upstream.

UDC core will call disconnect() and unbind() for us upon the gadget
removal, so we should not do it ourselves. Otherwise, a composite
gadget will explode, for example. Others might too.

This was introduced during conversion to new style gadget in 2c7f0989
(usb: gadget: langwell: convert to new style).

Signed-off-by: Alexander Shishkin <>
Cc: Heikki Krogerus <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: usbsevseg: fix max length
Harrison Metzger [Sun, 15 Jan 2012 14:43:24 +0000 (08:43 -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 <>
Signed-off-by: Stuart Pook <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: Realtek cr: fix autopm scheduling while atomic
Stanislaw Gruszka [Thu, 26 Jan 2012 11:29:42 +0000 (12:29 +0100)]
USB: Realtek cr: fix autopm scheduling while atomic

commit b3ef051db763b640d1ff724b616ffba940896b44 upstream.


Reported-by: Francis Moreau <>
Reported-and-tested-by: Christian D <>
Reported-and-tested-by: Jimmy Dorff <>
Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agovmwgfx: Fix assignment in vmw_framebuffer_create_handle
Ryan Mallon [Fri, 27 Jan 2012 21:51:40 +0000 (08:51 +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 <>
Reviewed-by: Jakob Bornecrantz<>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoiwlwifi: fix PCI-E transport "inta" race
Johannes Berg [Thu, 19 Jan 2012 16:20:57 +0000 (08:20 -0800)]
iwlwifi: fix PCI-E transport "inta" race

commit b49ba04a3a0382e7314d990707c21094c410425a upstream.

When an interrupt comes in, we read the reason
bits and collect them into "trans_pcie->inta".
This happens with the spinlock held. However,
there's a bug resetting this variable -- that
happens after the spinlock has been released.
This means that it is possible for interrupts
to be missed if the reset happens after some
other interrupt reasons were already added to
the variable.

I found this by code inspection, looking for a
reason that we sometimes see random commands
time out. It seems possible that this causes
such behaviour, but I can't say for sure right
now since it happens extremely infrequently on
my test systems.

Signed-off-by: Johannes Berg <>
Signed-off-by: Wey-Yi Guy <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agojsm: Fixed EEH recovery error
Lucas Kannebley Tavares [Mon, 9 Jan 2012 12:58:06 +0000 (10:58 -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

Signed-off-by: Lucas Kannebley Tavares <>
Signed-off-by: Breno Leitao <>
Acked-by: Thadeu Lima de Souza Cascardo <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoserial: amba-pl011: lock console writes against interrupts
Rabin Vincent [Tue, 17 Jan 2012 10:52:28 +0000 (11:52 +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 <>
Reviewed-by: Srinidhi Kasagar <>
Reviewed-by: Bibek Basu <>
Reviewed-by: Shreshtha Kumar Sahu <>
Signed-off-by: Linus Walleij <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoTTY: fix UV serial console regression
Jiri Slaby [Thu, 12 Jan 2012 21:55:15 +0000 (22:55 +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,

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 <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agousb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
Eric W. Biederman [Sat, 14 Jan 2012 05:32:06 +0000 (21:32 -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 <>
Reported-by: Wolfgang Frisch <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agousb: dwc3: ep0: tidy up Pending Request handling
Felipe Balbi [Thu, 29 Dec 2011 04:32:29 +0000 (06:32 +0200)]
usb: dwc3: ep0: tidy up Pending Request handling

commit 68d8a781575d7be490f97eb2c403fb13b083da6a upstream.

The way our code was written, we should never have
a DWC3_EP_PENDING_REQUEST flag set out of a Data Phase
and the code in __dwc3_gadget_ep0_queue() did not
reflect that situation properly.

Tidy up that case to avoid any possible mistakes
when starting requests for IRQs which are long

Signed-off-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoqcaux: add more Pantech UML190 and UML290 ports
Dan Williams [Tue, 24 Jan 2012 23:16:54 +0000 (17:16 -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 <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cdc-wdm: use two mutexes to allow simultaneous read and write
Bjørn Mork [Mon, 16 Jan 2012 11:41:48 +0000 (12:41 +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 <>
Cc: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: cdc-wdm: updating desc->length must be protected by spin_lock
Bjørn Mork [Mon, 16 Jan 2012 11:41:47 +0000 (12:41 +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 <>
Acked-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: ftdi_sio: Add more identifiers
Alan Cox [Thu, 26 Jan 2012 17:41:34 +0000 (17:41 +0000)]
USB: ftdi_sio: Add more identifiers

commit 2353f806c97020d4c7709f15eebb49b591f7306d upstream.

0x04d8, 0x000a: Hornby Elite

Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: serial: ftdi additional IDs
Peter Naulls [Wed, 18 Jan 2012 02:27:09 +0000 (18:27 -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 <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
Peter Korsgaard [Wed, 18 Jan 2012 22:43:45 +0000 (23:43 +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 <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: ftdi_sio: fix initial baud rate
Johan Hovold [Wed, 18 Jan 2012 00:46:00 +0000 (01:46 +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 <>
Signed-off-by: Johan Hovold <>
Tested-by: Roland Ramthun <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: ftdi_sio: fix TIOCSSERIAL baud_base handling
Johan Hovold [Tue, 10 Jan 2012 22:33:37 +0000 (23:33 +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

Reported-by: Torbjörn Lofterud <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoUSB: option: Add LG docomo L-02C
Kentaro Matsuyama [Thu, 12 Jan 2012 14:07:51 +0000 (23:07 +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 <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agompt2sas: Removed redundant calling of _scsih_probe_devices() from _scsih_probe [Tue, 13 Dec 2011 03:59:15 +0000 (09:29 +0530)]
mpt2sas: Removed redundant calling of _scsih_probe_devices() from _scsih_probe

commit 2cb6fc8c014b9b00c4487a79b8f6ed0da4121f45 upstream.

Removed redundant calling of _scsih_probe_devices() from _scsih_probe as
it is getting called from _scsih_scan_finished.

Also moved the function scsi_scan_host(shost) to get called after the
volumes on warp drive are reported to the OS. Otherwise by the time
the (ioc->hide_drives) flags is set, the volumes on warp drive
are reported to the OS already.

Also modified the initialization of reply queues only in case of driver load
time in the function _base_make_ioc_operational().

Signed-off-by: Nagalakshmi Nandigama <>
Signed-off-by: James Bottomley <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agox86: xen: size struct xen_spinlock to always fit in arch_spinlock_t
David Vrabel [Mon, 23 Jan 2012 19:32:25 +0000 (19:32 +0000)]
x86: xen: size struct xen_spinlock to always fit in arch_spinlock_t

commit 7a7546b377bdaa25ac77f33d9433c59f259b9688 upstream.

If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
xen_spinlock is 32 bits.  When a spin lock is contended and
xl->spinners is modified the two bytes immediately after the spin lock
would be corrupted.

This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
(x86, ticketlock: Clean up types and accessors) which reduced the size
of arch_spinlock_t.

Fix this by making xl->spinners a u8 if NR_CPUS < 256.  A
BUILD_BUG_ON() is also added to check the sizes of the two structures
are compatible.

In many cases this was not noticable as there would often be padding
bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,

The bnx2 driver is affected. In struct bnx2, phy_lock and
indirect_lock may have no padding after them.  Contention on phy_lock
would corrupt indirect_lock making it appear locked and the driver
would deadlock.

Signed-off-by: David Vrabel <>
Signed-off-by: Jeremy Fitzhardinge <>
Acked-by: Ian Campbell <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agosysfs: Complain bitterly about attempts to remove files from nonexistent directories.
Eric W. Biederman [Sat, 14 Jan 2012 05:32:59 +0000 (21:32 -0800)]
sysfs: Complain bitterly about attempts to remove files from nonexistent directories.

commit ce597919361dcec97341151690e780eade2a9cf4 upstream.

Recently an OOPS was observed from the usb serial io_ti driver when it tried to remove
sysfs directories.  Upon investigation it turns out this driver was always buggy
and that a recent sysfs change had stopped guarding itself against removing attributes
from sysfs directories that had already been removed. :(

Historically we have been silent about attempting to files from nonexistent sysfs
directories and have politely returned error codes.  That has resulted in people writing
broken code that ignores the error codes.

Issue a kernel WARNING and a stack backtrace to make it clear in no uncertain
terms that abusing sysfs is not ok, and the callers need to fix their code.

This change transforms the io_ti OOPS into a more comprehensible error message
and stack backtrace.

Signed-off-by: Eric W. Biederman <>
Reported-by: Wolfgang Frisch <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoARM: 7296/1: proc-v7.S: remove HARVARD_CACHE preprocessor guards
Will Deacon [Fri, 20 Jan 2012 11:10:18 +0000 (12:10 +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 <>
Acked-by: Catalin Marinas <>
Signed-off-by: Will Deacon <>
Signed-off-by: Russell King <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agomach-ux500: enable ARM errata 764369
Srinidhi KASAGAR [Thu, 12 Jan 2012 05:37:43 +0000 (11:07 +0530)]
mach-ux500: enable ARM errata 764369

commit d65015f7c5c5be9fd3f5e567889c844ba81bdc9c upstream.

This applies ARM errata 764369 for all ux500 platforms.

Signed-off-by: Srinidhi Kasagar <>
Signed-off-by: Linus Walleij <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoARM: at91: fix at91rm9200 soc subtype handling
Nicolas Ferre [Wed, 28 Dec 2011 11:10:04 +0000 (13:10 +0200)]
ARM: at91: fix at91rm9200 soc subtype handling

commit 3e90772f76010c315474bde59eaca7cc4c94d645 upstream.

Currently setting it to PQFP changes subtype to BGA as subtypes are
swapped in at91rm9200_set_type().

Wrong subtype causes GPIO bank D not to work at all.

After this fix, subtype is still set as unknown. But board code should
fill it in with proper value. Another information is thus printed.

Bug discovery and first implementation made by Veli-Pekka Peltola.

Signed-off-by: Nicolas Ferre <>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agodrm/i915: Re-enable gen7 RC6 and GPU turbo after resume.
Eric Anholt [Tue, 24 Jan 2012 00:14:06 +0000 (16:14 -0800)]
drm/i915: Re-enable gen7 RC6 and GPU turbo after resume.

commit 04115a9dee110b52a8eaa556c574022fa3bf4704 upstream.

Signed-off-by: Eric Anholt <>
Reviewed-by: Keith Packard <>
Reviewed-by: Eugeni Dodonov <>
Reviewed-by: Kenneth Graunke <>
Signed-off-by: Keith Packard <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agodrm/i915/sdvo: always set positive sync polarity
Paulo Zanoni [Fri, 6 Jan 2012 21:45:34 +0000 (19:45 -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.

Reviewed-by: Eric Anholt <>
Reviewed-by: Jesse Barnes <>
Signed-off-by: Paulo Zanoni <>
Signed-off-by: Keith Packard <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agodrm/i915: paper over missed irq issues with force wake voodoo
Daniel Vetter [Fri, 14 Dec 2012 15:01:25 +0000 (16:01 +0100)]
drm/i915: paper over missed irq issues with force wake voodoo

commit 4cd53c0c8b01fc05c3ad5b2acdad02e37d3c2f55 upstream.

Two things seem to do the trick on my ivb machine here:
- prevent the gt from powering down while waiting for seqno
  notification interrupts by grabbing the force_wake in get_irq (and
  dropping it in put_irq again).
- ordering writes from the ring's CS by reading a CS register, ACTHD
  seems to work.

Only the blt&bsd ring on ivb seem to be massively affected by this,
but for paranoia do this dance also on the render ring and on snb
(i.e. all gpus with forcewake).

Tested with Eric's glCopyPixels loop which without this patch scores a
missed irq every few seconds.

This patch needs my forcewake rework to use a spinlock instead of

After crawling through docs a lot I've found the following nugget:

Internal doc "SNB GT PM Programming Guide", Section 4.3.1:

"GT does not generate interrupts while in RC6 (by design)"

So it looks like rc6 and irq generation are indeed related.

v2: Improve the comment per Eugeni Dodonov's suggestion.

v3: Add the documentation snipped. Also restrict the w/a to ivb only
for -fixes, as suggested by Keith Packard.

Cc: Eric Anholt <>
Cc: Kenneth Graunke <>
Cc: Eugeni Dodonov <>
Tested-by: Eugeni Dodonov <>
Reviewed-by: Eugeni Dodonov <>
Signed-Off-by: Daniel Vetter <>
Signed-off-by: Keith Packard <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoALSA: hda - Fix silent output on Haier W18 laptop
Takashi Iwai [Thu, 26 Jan 2012 14:56:16 +0000 (15:56 +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.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoALSA: hda - Fix silent output on ASUS A6Rp
Takashi Iwai [Wed, 25 Jan 2012 08:55:46 +0000 (09:55 +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.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoALSA: hda: set mute led polarity for laptops with buggy BIOS based on SSID
Gustavo Maciel Dias Vieira [Tue, 24 Jan 2012 15:27:56 +0000 (13:27 -0200)]
ALSA: hda: set mute led polarity for laptops with buggy BIOS based on SSID

commit a6a600d10aaddf1da38053c4c6b64f50f56176e6 upstream.

HP laptop models with buggy BIOS are apparently frequent, including
machines with different codecs. Set the polarity of the mute led based
on the SSID and include an entry for the HP Mini 110-3100.

Signed-off-by: Gustavo Maciel Dias Vieira <>
Tested-by: Predrag Ivanovic <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agom68k: Fix assembler constraint to prevent overeager gcc optimisation
Andreas Schwab [Mon, 9 Jan 2012 14:10:15 +0000 (15:10 +0100)]
m68k: Fix assembler constraint to prevent overeager gcc optimisation

commit 2a3535069e33d8b416f406c159ce924427315303 upstream.

Passing the address of a variable as an operand to an asm statement
doesn't mark the value of this variable as used, so gcc may optimize its
initialisation away.  Fix this by using the "m" constraint instead.

Signed-off-by: Andreas Schwab <>
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agox86/microcode_amd: Add support for CPU family specific container files
Andreas Herrmann [Fri, 20 Jan 2012 16:44:12 +0000 (17:44 +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 <>
Cc: Borislav Petkov <>
Cc: <>
[ documented the naming convention and tidied the code a bit. ]
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agox86/uv: Fix uv_gpa_to_soc_phys_ram() shift
Russ Anderson [Thu, 19 Jan 2012 02:07:54 +0000 (20:07 -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 <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agox86/uv: Fix uninitialized spinlocks
Cliff Wickman [Wed, 18 Jan 2012 15:40:47 +0000 (09:40 -0600)]
x86/uv: Fix uninitialized spinlocks

commit d2ebc71d472020bc30e29afe8c4d2a85a5b41f56 upstream.

Initialize two spinlocks in tlb_uv.c and also properly define/initialize
the uv_irq_lock.

The lack of explicit initialization seems to be functionally
harmless, but it is diagnosed when these are turned on:


Signed-off-by: Cliff Wickman <>
Cc: Dimitri Sivanich <>
[ Added the uv_irq_lock initialization fix by Dimitri Sivanich ]
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agotpm_tis: add delay after aborting command
Stefan Berger [Fri, 11 Nov 2011 17:57:06 +0000 (12:57 -0500)]
tpm_tis: add delay after aborting command

commit a927b8131794ee449b7f6666e7ab61301949b20f upstream.

This patch adds a delay after aborting a command. Some TPMs need
this and will not process the subsequent command correctly otherwise.

It's worth noting that a TPM randomly failing to process a command,
maps to randomly failing suspend/resume operations.

Signed-off-by: Stefan Berger <>
Signed-off-by: Rajiv Andrade <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agocrypto: sha512 - reduce stack usage to safe number
Alexey Dobriyan [Sat, 14 Jan 2012 18:40:57 +0000 (21:40 +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:
  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

Signed-off-by: Alexey Dobriyan <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agocrypto: sha512 - make it work, undo percpu message schedule
Alexey Dobriyan [Sat, 14 Jan 2012 18:27:37 +0000 (21:27 +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
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

Signed-off-by: Alexey Dobriyan <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agojbd: Issue cache flush after checkpointing
Jan Kara [Fri, 25 Nov 2011 23:35:39 +0000 (00:35 +0100)]
jbd: Issue cache flush after checkpointing

commit 353b67d8ced4dc53281c88150ad295e24bc4b4c5 upstream.

When we reach cleanup_journal_tail(), there is no guarantee that
checkpointed buffers are on a stable storage - especially if buffers were
written out by log_do_checkpoint(), they are likely to be only in disk's
caches. Thus when we update journal superblock, effectively removing old
transaction from journal, this write of superblock can get to stable storage
before those checkpointed buffers which can result in filesystem corruption
after a crash.

A similar problem can happen if we replay the journal and wipe it before
flushing disk's caches.

Thus we must unconditionally issue a cache flush before we update journal
superblock in these cases. The fix is slightly complicated by the fact that we
have to get log tail before we issue cache flush but we can store it in the
journal superblock only after the cache flush. Otherwise we risk races where
new tail is written before appropriate cache flush is finished.

I managed to reproduce the corruption using somewhat tweaked Chris Mason's
barrier-test scheduler. Also this should fix occasional reports of 'Bit already
freed' filesystem errors which are totally unreproducible but inspection of
several fs images I've gathered over time points to a problem like this.

Signed-off-by: Jan Kara <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agomac80211: fix work removal on deauth request
Johannes Berg [Wed, 18 Jan 2012 13:10:25 +0000 (14:10 +0100)]
mac80211: fix work removal on deauth request

commit bc4934bc61d0a11fd62c5187ff83645628f8be8b upstream.

When deauth is requested while an auth or assoc
work item is in progress, we currently delete it
without regard for any state it might need to
clean up. Fix it by cleaning up for those items.

In the case Pontus found, the problem manifested
itself as such:

authenticate with 00:23:69:aa:dd:7b (try 1)
failed to insert Dummy STA entry for the AP (error -17)
deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2)

It could also happen differently if the driver
uses the tx_sync callback.

We can't just call the ->done() method of the work
items because that will lock up due to the locking
in cfg80211. This fix isn't very clean, but that
seems acceptable since I have patches pending to
remove this code completely.

Reported-by: Pontus Fuchs <>
Tested-by: Pontus Fuchs <>
Signed-off-by: Johannes Berg <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agobrcmsmac: fix tx queue flush infinite loop
Stanislaw Gruszka [Tue, 17 Jan 2012 11:38:50 +0000 (12:38 +0100)]
brcmsmac: fix tx queue flush infinite loop

commit f96b08a7e6f69c0f0a576554df3df5b1b519c479 upstream.

This patch workaround live deadlock problem caused by infinite loop
in brcms_c_wait_for_tx_completion(). I do not consider the patch as
the proper fix, which should fix the real reason of tx queue flush
failure, but patch helps with system lockup.


Reported-and-tested-by: Patrick <>
Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoASoC: wm8996: Call _POST_PMU callback for CPVDD
Mark Brown [Sat, 21 Jan 2012 21:48:53 +0000 (21:48 +0000)]
ASoC: wm8996: Call _POST_PMU callback for CPVDD

commit a14304edcd5e8323205db34b08f709feb5357e64 upstream.

We should be allowing a 5ms delay after the charge pump is started in
order to ensure it has finished ramping.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoASoC: Don't go through cache when applying WM5100 rev A updates
Mark Brown [Thu, 19 Jan 2012 11:16:37 +0000 (11:16 +0000)]
ASoC: Don't go through cache when applying WM5100 rev A updates

commit 495174a8ffbaa0d15153d855cf206cdc46d51cf4 upstream.

These are all to either uncached registers or fixes to register defaults,
in the former case the cache won't do anything and in the latter case
we're fixing things so the cache sync will do the right thing.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoASoC: Disable register synchronisation for low frequency WM8996 SYSCLK
Mark Brown [Wed, 18 Jan 2012 19:17:06 +0000 (19:17 +0000)]
ASoC: Disable register synchronisation for low frequency WM8996 SYSCLK

commit fed22007113cb857e917913ce016d9b539dc3a80 upstream.

With a low frequency SYSCLK and a fast I2C clock register synchronisation
may occasionally take too long to take effect, causing I/O issues. Disable
synchronisation in order to avoid any issues.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoASoC: Mark WM5100 register map cache only when going into BIAS_OFF
Mark Brown [Wed, 18 Jan 2012 20:02:38 +0000 (20:02 +0000)]
ASoC: Mark WM5100 register map cache only when going into BIAS_OFF

commit e53e417331c57b9b97e3f8be870214a02c99265c upstream.

Writing to the registers won't work if we do actually manage to hit a fully
powered off state.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoxfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()
Jan Kara [Wed, 11 Jan 2012 18:52:10 +0000 (18:52 +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 <>
Signed-off-by: Jan Kara <>
Reviewed-by: Alex Elder <>
Reviewed-by: Dave Chinner <>
Signed-off-by: Ben Myers <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agodrm: Fix authentication kernel crash
Thomas Hellstrom [Tue, 24 Jan 2012 17:54:21 +0000 (18:54 +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 <>
Reviewed-by: Daniel Vetter <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agodrm/radeon/kms: rework modeset sequence for DCE41 and DCE5
Alex Deucher [Fri, 20 Jan 2012 20:01:30 +0000 (15:01 -0500)]
drm/radeon/kms: rework modeset sequence for DCE41 and DCE5

commit 3a47824d85eeca122895646f027dc63480994199 upstream.

dig transmitter control table only has ENABLE/DISABLE actions
on DCE4.1/DCE5.


Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agodrm/radeon/kms: move panel mode setup into encoder mode set
Alex Deucher [Fri, 20 Jan 2012 20:01:29 +0000 (15:01 -0500)]
drm/radeon/kms: move panel mode setup into encoder mode set

commit 386d4d751e8e0b4b693bb724f09aae064ee5297d upstream.

Needs to happen earlier in the mode set.

Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agodrm/radeon/kms: Add an MSI quirk for Dell RS690
Alex Deucher [Sun, 15 Jan 2012 13:51:12 +0000 (08:51 -0500)]
drm/radeon/kms: Add an MSI quirk for Dell RS690

commit 44517c44496062180a6376cc704b33129441ce60 upstream.

Interrupts only work with MSIs.

Reported-by: Dmitry Podgorny <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoeCryptfs: Fix oops when printing debug info in extent crypto functions
Tyler Hicks [Tue, 24 Jan 2012 16:02:22 +0000 (10:02 -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.

Signed-off-by: Tyler Hicks <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoeCryptfs: Check inode changes in setattr
Tyler Hicks [Fri, 20 Jan 2012 02:33:44 +0000 (20:33 -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 <>
Reviewed-by: Li Wang <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoeCryptfs: Make truncate path killable
Tyler Hicks [Thu, 19 Jan 2012 00:30:04 +0000 (18:30 -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 <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoecryptfs: Improve metadata read failure logging
Tim Gardner [Thu, 12 Jan 2012 15:31:55 +0000 (16:31 +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`.

[ Removed some minor not-for-stable parts]
Signed-off-by: Tim Gardner <>
Reviewed-by: Kees Cook <>
Signed-off-by: Tyler Hicks <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoeCryptfs: Sanitize write counts of /dev/ecryptfs
Tyler Hicks [Thu, 12 Jan 2012 10:30:44 +0000 (11:30 +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

Signed-off-by: Tyler Hicks <>
Reported-by: Sasha Levin <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoALSA: hda - Fix silent outputs from docking-station jacks of Dell laptops
Takashi Iwai [Mon, 23 Jan 2012 17:23:36 +0000 (18:23 +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.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoALSA: hda - Fix buffer-alignment regression with Nvidia HDMI
Takashi Iwai [Mon, 23 Jan 2012 16:10:24 +0000 (17:10 +0100)]
ALSA: hda - Fix buffer-alignment regression with Nvidia HDMI

commit 52409aa6a0e96337da137c069856298f4dd825a0 upstream.

The commit 2ae66c26550cd94b0e2606a9275eb0ab7070ad0e
    ALSA: hda: option to enable arbitrary buffer/period sizes
introduced a regression on machines with Intel controller and Nvidia
HDMI.  The reason is that the driver modifies the global variable
align_buffer_size when an Intel controller is found, and the Nvidia
HDMI controller is probed after Intel although Nvidia chips require
the aligned buffers.

This patch fixes the problem by moving the flag into the local struct
so that it's not affected by other controllers.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoLinux 3.2.2 v3.2.2
Greg Kroah-Hartman [Thu, 26 Jan 2012 00:39:32 +0000 (16:39 -0800)]
Linux 3.2.2

11 years agoSHM_UNLOCK: fix Unevictable pages stranded after swap
Hugh Dickins [Fri, 20 Jan 2012 22:34:21 +0000 (14:34 -0800)]
SHM_UNLOCK: fix Unevictable pages stranded after swap

commit 245132643e1cfcd145bbc86a716c1818371fcb93 upstream.

Commit cc39c6a9bbde ("mm: account skipped entries to avoid looping in
find_get_pages") correctly fixed an infinite loop; but left a problem
that find_get_pages() on shmem would return 0 (appearing to callers to
mean end of tree) when it meets a run of nr_pages swap entries.

The only uses of find_get_pages() on shmem are via pagevec_lookup(),
called from invalidate_mapping_pages(), and from shmctl SHM_UNLOCK's
scan_mapping_unevictable_pages().  The first is already commented, and
not worth worrying about; but the second can leave pages on the
Unevictable list after an unusual sequence of swapping and locking.

Fix that by using shmem_find_get_pages_and_swap() (then ignoring the
swap) instead of pagevec_lookup().

But I don't want to contaminate vmscan.c with shmem internals, nor
shmem.c with LRU locking.  So move scan_mapping_unevictable_pages() into
shmem.c, renaming it shmem_unlock_mapping(); and rename
check_move_unevictable_page() to check_move_unevictable_pages(), looping
down an array of pages, oftentimes under the same lock.

Leave out the "rotate unevictable list" block: that's a leftover from
when this was used for /proc/sys/vm/scan_unevictable_pages, whose flawed
handling involved looking at pages at tail of LRU.

Was there significance to the sequence first ClearPageUnevictable, then
test page_evictable, then SetPageUnevictable here? I think not, we're
under LRU lock, and have no barriers between those.

Signed-off-by: Hugh Dickins <>
Reviewed-by: KOSAKI Motohiro <>
Cc: Minchan Kim <>
Cc: Rik van Riel <>
Cc: Shaohua Li <>
Cc: Eric Dumazet <>
Cc: Johannes Weiner <>
Cc: Michel Lespinasse <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoSHM_UNLOCK: fix long unpreemptible section
Hugh Dickins [Fri, 20 Jan 2012 22:34:19 +0000 (14:34 -0800)]
SHM_UNLOCK: fix long unpreemptible section

commit 85046579bde15e532983438f86b36856e358f417 upstream.

scan_mapping_unevictable_pages() is used to make SysV SHM_LOCKed pages
evictable again once the shared memory is unlocked.  It does this with
pagevec_lookup()s across the whole object (which might occupy most of
memory), and takes 300ms to unlock 7GB here.  A cond_resched() every
PAGEVEC_SIZE pages would be good.

However, KOSAKI-san points out that this is called under shmem.c's
info->lock, and it's also under shm.c's shm_lock(), both spinlocks.
There is no strong reason for that: we need to take these pages off the
unevictable list soonish, but those locks are not required for it.

So move the call to scan_mapping_unevictable_pages() from shmem.c's
unlock handling up to shm.c's unlock handling.  Remove the recently
added barrier, not needed now we have spin_unlock() before the scan.

Use get_file(), with subsequent fput(), to make sure we have a reference
to mapping throughout scan_mapping_unevictable_pages(): that's something
that was previously guaranteed by the shm_lock().

Remove shmctl's lru_add_drain_all(): we don't fault in pages at SHM_LOCK
time, and we lazily discover them to be Unevictable later, so it serves
no purpose for SHM_LOCK; and serves no purpose for SHM_UNLOCK, since
pages still on pagevec are not marked Unevictable.

The original code avoided redundant rescans by checking VM_LOCKED flag
at its level: now avoid them by checking shp's SHM_LOCKED.

The original code called scan_mapping_unevictable_pages() on a locked
area at shm_destroy() time: perhaps we once had accounting cross-checks
which required that, but not now, so skip the overhead and just let
inode eviction deal with them.

Put check_move_unevictable_page() and scan_mapping_unevictable_pages()
under CONFIG_SHMEM (with stub for the TINY case when ramfs is used),
more as comment than to save space; comment them used for SHM_UNLOCK.

Signed-off-by: Hugh Dickins <>
Reviewed-by: KOSAKI Motohiro <>
Cc: Minchan Kim <>
Cc: Rik van Riel <>
Cc: Shaohua Li <>
Cc: Eric Dumazet <>
Cc: Johannes Weiner <>
Cc: Michel Lespinasse <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoiwlegacy: 3945: fix hw passive scan on radar channels
Stanislaw Gruszka [Fri, 23 Dec 2011 07:13:50 +0000 (08:13 +0100)]
iwlegacy: 3945: fix hw passive scan on radar channels

commit 68acc4afb040d98ddfd2cae0de09e2f4e1ee127f upstream.

Patch fix firmware error on "iw dev wlan0 scan passive" for
hardware scanning (with disable_hw_scan=0 module parameter).

 iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008.
 iwl3945 0000:03:00.0: Loaded firmware version:
 iwl3945 0000:03:00.0: Start IWL Error Log Dump:
 iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1
 iwl3945 0000:03:00.0: Desc       Time       asrtPC blink2 ilink1  nmiPC   Line
 iwl3945 0000:03:00.0: SYSASSERT     (0x5) 0041263900 0x13756 0x0031C 0x00000 764
 iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000
 iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error
 iwl3945 0000:03:00.0: Can't stop Rx DMA.

We have disable ability to change passive scanning to active on
particular channel when traffic is detected on that channel. Otherwise
firmware will report error, when we try to do passive scan on radar

Reported-and-debugged-by: Pedro Francisco <>
Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agoiwlagn: check for SMPS mode
Wey-Yi Guy [Thu, 10 Nov 2011 14:55:04 +0000 (06:55 -0800)]
iwlagn: check for SMPS mode

commit b2ccccdca46273c7b321ecf5041c362cd950da20 upstream.

Check and report WARN only when its invalid


Signed-off-by: Wey-Yi Guy <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
11 years agomm: fix NULL ptr dereference in __count_immobile_pages
Michal Hocko [Fri, 20 Jan 2012 22:33:55 +0000 (14:33 -0800)]
mm: fix NULL ptr dereference in __count_immobile_pages

commit 687875fb7de4a95223af20ee024282fa9099f860 upstream.

Fix the following NULL ptr dereference caused by

  cat /sys/devices/system/memory/memory0/removable

Pid: 13979, comm: sed Not tainted 3.0.13-0.5-default #1 IBM BladeCenter LS21 -[7971PAM]-/Server Blade
RIP: __count_immobile_pages+0x4/0x100
Process sed (pid: 13979, threadinfo ffff880221c36000, task ffff88022e788480)
Call Trace:

We are crashing because we are trying to dereference NULL zone which
came from pfn=0 (struct page ffffea0000000000). According to the boot
log this page is marked reserved:
e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)

and early_node_map confirms that:
early_node_map[3] active PFN ranges
    1: 0x00000010 -> 0x0000009c
    1: 0x00000100 -> 0x000bffa3
    1: 0x00100000 -> 0x00240000

The problem is that memory_present works in PAGE_SECTION_MASK aligned
blocks so the reserved range sneaks into the the section as well.  This
also means that free_area_init_node will not take care of those reserved
pages and they stay uninitialized.

When we try to read the removable status we walk through all available
sections and hope that the zone is valid for all pages in the section.
But this is not true in this case as the zone and nid are not initialized.

We have only one node in this particular case and it is marked as node=1
(rather than 0) and that made the problem visible because page_to_nid will
return 0 and there are no zones on the node.

Let's check that the zone is valid and that the given pfn falls into its
boundaries and mark the section not removable.  This might cause some
false positives, probably, but we do not have any sane way to find out
whether the page is reserved by the platform or it is just not used for
whatever other reasons.

Signed-off-by: Michal Hocko <>
Acked-by: Mel Gorman <>
Cc: KAMEZAWA Hiroyuki <>
Cc: Andrea Arcangeli <>
Cc: David Rientjes <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>