linux-toradex.git, branch v3.2.27

Linux 3.2.27

2012-08-09T23:25:22+00:00

pch_uart: Fix parity setting issue

2012-08-09T23:25:19+00:00

commit 38bd2a1ac736901d1cf4971c78ef952ba92ef78b upstream.

Parity Setting value is reverse.
E.G. In case of setting ODD parity, EVEN value is set.
This patch inverts "if" condition.

Signed-off-by: Tomoya MORINAGA 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

pch_uart: Fix rx error interrupt setting issue

2012-08-09T23:25:18+00:00

commit 9539dfb7ac1c84522fe1f79bb7dac2990f3de44a upstream.

Rx Error interrupt(E.G. parity error) is not enabled.
So, when parity error occurs, error interrupt is not occurred.
As a result, the received data is not dropped.

This patch adds enable/disable rx error interrupt code.

Signed-off-by: Tomoya MORINAGA 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
[Backported by Tomoya MORINGA: adjusted context]
Signed-off-by: Ben Hutchings

pch_uart: Fix missing break for 16 byte fifo

2012-08-09T23:25:17+00:00

commit 9bc03743fff0770dc5a5324ba92e67cc377f16ca upstream.

Otherwise we fall back to the wrong value.

Reported-by: 
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44091
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

drop_monitor: dont sleep in atomic context

2012-08-09T23:25:17+00:00

commit bec4596b4e6770c7037f21f6bd27567b152dc0d6 upstream.

drop_monitor calls several sleeping functions while in atomic context.

 BUG: sleeping function called from invalid context at mm/slub.c:943
 in_atomic(): 1, irqs_disabled(): 0, pid: 2103, name: kworker/0:2
 Pid: 2103, comm: kworker/0:2 Not tainted 3.5.0-rc1+ #55
 Call Trace:
  [] __might_sleep+0xca/0xf0
  [] kmem_cache_alloc_node+0x1b3/0x1c0
  [] ? queue_delayed_work_on+0x11c/0x130
  [] __alloc_skb+0x4b/0x230
  [] ? reset_per_cpu_data+0x160/0x160 [drop_monitor]
  [] reset_per_cpu_data+0x2f/0x160 [drop_monitor]
  [] send_dm_alert+0x4b/0xb0 [drop_monitor]
  [] process_one_work+0x130/0x4c0
  [] worker_thread+0x159/0x360
  [] ? manage_workers.isra.27+0x240/0x240
  [] kthread+0x93/0xa0
  [] kernel_thread_helper+0x4/0x10
  [] ? kthread_freezable_should_stop+0x80/0x80
  [] ? gs_change+0xb/0xb

Rework the logic to call the sleeping functions in right context.

Use standard timer/workqueue api to let system chose any cpu to perform
the allocation and netlink send.

Also avoid a loop if reset_per_cpu_data() cannot allocate memory :
use mod_timer() to wait 1/10 second before next try.

Signed-off-by: Eric Dumazet 
Cc: Neil Horman 
Reviewed-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

drop_monitor: prevent init path from scheduling on the wrong cpu

2012-08-09T23:25:16+00:00

commit 4fdcfa12843bca38d0c9deff70c8720e4e8f515f upstream.

I just noticed after some recent updates, that the init path for the drop
monitor protocol has a minor error.  drop monitor maintains a per cpu structure,
that gets initalized from a single cpu.  Normally this is fine, as the protocol
isn't in use yet, but I recently made a change that causes a failed skb
allocation to reschedule itself .  Given the current code, the implication is
that this workqueue reschedule will take place on the wrong cpu.  If drop
monitor is used early during the boot process, its possible that two cpus will
access a single per-cpu structure in parallel, possibly leading to data
corruption.

This patch fixes the situation, by storing the cpu number that a given instance
of this per-cpu data should be accessed from.  In the case of a need for a
reschedule, the cpu stored in the struct is assigned the rescheule, rather than
the currently executing cpu

Tested successfully by myself.

Signed-off-by: Neil Horman 
CC: David Miller 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

drop_monitor: Make updating data->skb smp safe

2012-08-09T23:25:15+00:00

commit 3885ca785a3618593226687ced84f3f336dc3860 upstream.

Eric Dumazet pointed out to me that the drop_monitor protocol has some holes in
its smp protections.  Specifically, its possible to replace data->skb while its
being written.  This patch corrects that by making data->skb an rcu protected
variable.  That will prevent it from being overwritten while a tracepoint is
modifying it.

Signed-off-by: Neil Horman 
Reported-by: Eric Dumazet 
CC: David Miller 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

drop_monitor: fix sleeping in invalid context warning

2012-08-09T23:25:15+00:00

commit cde2e9a651b76d8db36ae94cd0febc82b637e5dd upstream.

Eric Dumazet pointed out this warning in the drop_monitor protocol to me:

[   38.352571] BUG: sleeping function called from invalid context at kernel/mutex.c:85
[   38.352576] in_atomic(): 1, irqs_disabled(): 0, pid: 4415, name: dropwatch
[   38.352580] Pid: 4415, comm: dropwatch Not tainted 3.4.0-rc2+ #71
[   38.352582] Call Trace:
[   38.352592]  [] ? trace_napi_poll_hit+0xd0/0xd0
[   38.352599]  [] __might_sleep+0xca/0xf0
[   38.352606]  [] mutex_lock+0x26/0x50
[   38.352610]  [] ? trace_napi_poll_hit+0xd0/0xd0
[   38.352616]  [] tracepoint_probe_register+0x29/0x90
[   38.352621]  [] set_all_monitor_traces+0x105/0x170
[   38.352625]  [] net_dm_cmd_trace+0x2a/0x40
[   38.352630]  [] genl_rcv_msg+0x21a/0x2b0
[   38.352636]  [] ? zone_statistics+0x99/0xc0
[   38.352640]  [] ? genl_rcv+0x30/0x30
[   38.352645]  [] netlink_rcv_skb+0xa9/0xd0
[   38.352649]  [] genl_rcv+0x20/0x30
[   38.352653]  [] netlink_unicast+0x1ae/0x1f0
[   38.352658]  [] netlink_sendmsg+0x2b6/0x310
[   38.352663]  [] sock_sendmsg+0x10f/0x130
[   38.352668]  [] ? move_addr_to_kernel+0x60/0xb0
[   38.352673]  [] ? verify_iovec+0x64/0xe0
[   38.352677]  [] __sys_sendmsg+0x386/0x390
[   38.352682]  [] ? handle_mm_fault+0x139/0x210
[   38.352687]  [] ? do_page_fault+0x1ec/0x4f0
[   38.352693]  [] ? set_next_entity+0x9d/0xb0
[   38.352699]  [] ? tty_ldisc_deref+0x9/0x10
[   38.352703]  [] ? pick_next_task_fair+0x63/0x140
[   38.352708]  [] sys_sendmsg+0x44/0x80
[   38.352713]  [] system_call_fastpath+0x16/0x1b

It stems from holding a spinlock (trace_state_lock) while attempting to register
or unregister tracepoint hooks, making in_atomic() true in this context, leading
to the warning when the tracepoint calls might_sleep() while its taking a mutex.
Since we only use the trace_state_lock to prevent trace protocol state races, as
well as hardware stat list updates on an rcu write side, we can just convert the
spinlock to a mutex to avoid this problem.

Signed-off-by: Neil Horman 
Reported-by: Eric Dumazet 
CC: David Miller 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

rt2x00: Add support for BUFFALO WLI-UC-GNM2 to rt2800usb.

2012-08-09T23:25:14+00:00

commit a769f9577232afe2c754606a83aad85127e7052a upstream.

This is a RT3070 based device.

Signed-off-by: Jeongdo Son 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

drm/i915: prefer wide & slow to fast & narrow in DP configs

2012-08-09T23:25:13+00:00

commit 2514bc510d0c3aadcc5204056bb440fa36845147 upstream.

High frequency link configurations have the potential to cause trouble
with long and/or cheap cables, so prefer slow and wide configurations
instead.  This patch has the potential to cause trouble for eDP
configurations that lie about available lanes, so if we run into that we
can make it conditional on eDP.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
Tested-by: peter@colberg.org
Signed-off-by: Jesse Barnes 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings