linux-toradex.git/drivers, branch v3.0.101

drm/radeon: fix hw contexts for SUMO2 asics

2013-10-22T07:41:44+00:00

commit 50b8f5aec04ebec7dbdf2adb17220b9148c99e63 upstream.

They have 4 rather than 8.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=63599

Signed-off-by: wojciech kapuscinski 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

watchdog: ts72xx_wdt: locking bug in ioctl

2013-10-22T07:41:44+00:00

commit 8612ed0d97abcf1c016d34755b7cf2060de71963 upstream.

Calling the WDIOC_GETSTATUS & WDIOC_GETBOOTSTATUS and twice will cause a
interruptible deadlock.

Signed-off-by: Dan Carpenter 
Reviewed-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

random: run random_int_secret_init() run after all late_initcalls

2013-10-22T07:41:44+00:00

commit 47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream.

The some platforms (e.g., ARM) initializes their clocks as
late_initcalls for some unknown reason.  So make sure
random_int_secret_init() is run after all of the late_initcalls are
run.

Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

Tools: hv: verify origin of netlink connector message

2013-10-13T21:51:09+00:00

commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.

The SuSE security team suggested to use recvfrom instead of recv to be
certain that the connector message is originated from kernel.

CVE-2012-2669

Signed-off-by: Olaf Hering 
Signed-off-by: Marcus Meissner 
Signed-off-by: Sebastian Krahmer 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

tg3: fix length overflow in VPD firmware parsing

2013-10-13T21:51:08+00:00

commit 715230a44310a8cf66fbfb5a46f9a62a9b2de424 upstream.

Commit 184b89044fb6e2a74611dafa69b1dce0d98612c6 ("tg3: Use VPD fw version
when present") introduced VPD parsing that contained a potential length
overflow.

Limit the hardware's reported firmware string length (max 255 bytes) to
stay inside the driver's firmware string length (32 bytes). On overflow,
truncate the formatted firmware string instead of potentially overwriting
portions of the tg3 struct.

http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.pdf

-js: This fixes CVE-2013-1929.

Signed-off-by: Kees Cook 
Reported-by: Oded Horovitz 
Reported-by: Brad Spengler 
Cc: stable@vger.kernel.org
Cc: Matt Carlson 
Signed-off-by: David S. Miller 
Acked-by: Jeff Mahoney 
Signed-off-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()

2013-10-13T21:51:08+00:00

commit 06a8566bcf5cf7db9843a82cde7a33c7bf3947d9 upstream.

This patch fixes the issues indicated by the test results that
ipmi_msg_handler() is invoked in atomic context.

BUG: scheduling while atomic: kipmi0/18933/0x10000100
Modules linked in: ipmi_si acpi_ipmi ...
CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G       AW    3.10.0-rc7+ #2
Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.070120100606 07/01/2010
 ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8
 ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4
 0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8
Call Trace:
   [] dump_stack+0x19/0x1b
 [] __schedule_bug+0x46/0x54
 [] __schedule+0x83/0x59c
 [] __cond_resched+0x22/0x2d
 [] _cond_resched+0x14/0x1d
 [] mutex_lock+0x11/0x32
 [] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58
 [] ipmi_msg_handler+0x23/0x166 [ipmi_si]
 [] deliver_response+0x55/0x5a
 [] handle_new_recv_msgs+0xb67/0xc65
 [] ? read_tsc+0x9/0x19
 [] ? _raw_spin_lock_irq+0xa/0xc
 [] ipmi_thread+0x5c/0x146 [ipmi_si]
 ...

Also Tony Camuso says:

 We were getting occasional "Scheduling while atomic" call traces
 during boot on some systems. Problem was first seen on a Cisco C210
 but we were able to reproduce it on a Cisco c220m3. Setting
 CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around
 tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device.

 =================================
 [ INFO: inconsistent lock state ]
 2.6.32-415.el6.x86_64-debug-splck #1
 ---------------------------------
 inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
 ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (&ipmi_device->tx_msg_lock){+.?...}, at: [] ipmi_msg_handler+0x71/0x126
 {SOFTIRQ-ON-W} state was registered at:
   [] __lock_acquire+0x63c/0x1570
   [] lock_acquire+0xa4/0x120
   [] __mutex_lock_common+0x4c/0x400
   [] mutex_lock_nested+0x4a/0x60
   [] acpi_ipmi_space_handler+0x11b/0x234
   [] acpi_ev_address_space_dispatch+0x170/0x1be

The fix implemented by this change has been tested by Tony:

 Tested the patch in a boot loop with lockdep debug enabled and never
 saw the problem in over 400 reboots.

Reported-and-tested-by: Tony Camuso 
Signed-off-by: Lv Zheng 
Reviewed-by: Huang Ying 
Signed-off-by: Rafael J. Wysocki 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: ni_65xx: (bug fix) confine insn_bits to one subdevice

2013-10-13T21:51:08+00:00

commit 677a31565692d596ef42ea589b53ba289abf4713 upstream.

The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that
currently writes (optionally) and reads back up to 5 "ports" consisting
of 8 channels each.  It reads up to 32 1-bit channels but can only read
and write a whole port at once - it needs to handle up to 5 ports as the
first channel it reads might not be aligned on a port boundary.  It
breaks out of the loop early if the next port it handles is beyond the
final port on the card.  It also breaks out early on the 5th port in the
loop if the first channel was aligned.  Unfortunately, it doesn't check
that the current port it is dealing with belongs to the comedi subdevice
the `insn_bits` handler is acting on.  That's a bug.

Redo the `for` loop to terminate after the final port belonging to the
subdevice, changing the loop variable in the process to simplify things
a bit.  The `for` loop could now try and handle more than 5 ports if the
subdevice has more than 40 channels, but the test `if (bitshift >= 32)`
ensures it will break out early after 4 or 5 ports (depending on whether
the first channel is aligned on a port boundary).  (`bitshift` will be
between -7 and 7 inclusive on the first iteration, increasing by 8 for
each subsequent operation.)

Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

p54usb: add USB ID for Corega WLUSB2GTST USB adapter

2013-10-13T21:51:08+00:00

commit 1e43692cdb7cc445d6347d8a5207d9cef0c71434 upstream.

Added USB ID for Corega WLUSB2GTST USB adapter.

Reported-by: Joerg Kalisch 
Signed-off-by: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: Align private space in rtl_priv struct

2013-10-13T21:51:08+00:00

commit 60ce314d1750fef843e9db70050e09e49f838b69 upstream.

The private array at the end of the rtl_priv struct is not aligned.
On ARM architecture, this causes an alignment trap and is fixed by aligning
that array with __align(sizeof(void *)). That should properly align that
space according to the requirements of all architectures.

Reported-by: Jason Andrews 
Tested-by: Jason Andrews 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

USB: serial: option: Ignore card reader interface on Huawei E1750

2013-10-13T21:51:08+00:00

commit eb2addd4044b4b2ce77693bde5bc810536dd96ee upstream.

Hi,

my Huawei 3G modem has an embedded Smart Card reader which causes
trouble when the modem is being detected (a bunch of "  (ttyUSBx):
open blocked by driver for more than 7 seconds!" in messages.log). This
trivial patch corrects the problem for me. The modem identifies itself
as "12d1:1406 Huawei Technologies Co., Ltd. E1750" in lsusb although the
description on the body says "Model E173u-1"

Signed-off-by: Michal Malý 
Cc: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman