linux-toradex.git/drivers, branch v2.6.38.6

fix oops in scsi_run_queue()

2011-05-09T22:06:51+00:00

commit c055f5b2614b4f758ae6cc86733f31fa4c2c5844 upstream.

The recent commit closing the race window in device teardown:

commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b
Author: James Bottomley 
Date:   Fri Apr 22 10:39:59 2011 -0500

    [SCSI] put stricter guards on queue dead checks

is causing a potential NULL deref in scsi_run_queue() because the
q->queuedata may already be NULL by the time this function is called.
Since we shouldn't be running a queue that is being torn down, simply
add a NULL check in scsi_run_queue() to forestall this.

Tested-by: Jim Schutt 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

cx88: Fix HVR4000 IR keymap

2011-05-09T22:06:49+00:00

[fixed in .39 in a much different way that is too big to backport to
.38 - gregkh]

Fixes the RC key input for Nova-S plus, HVR1100, HVR3000 and HVR4000 in
the 2.6.38 kernel.

Signed-off-by: Lawrence Rust 
Acked-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab

ath9k: fix the return value of ath_stoprecv

2011-05-09T22:06:45+00:00

commit 2232d31bf18ba02f5cd632bbfc3466aeca394c75 upstream.

The patch 'ath9k_hw: fix stopping rx DMA during resets' added code to detect
a condition where rx DMA was stopped, but the MAC failed to enter the idle
state. This condition requires a hardware reset, however the return value
of ath_stoprecv was 'true' in that case, which allowed it to skip the reset
when issuing a fast channel change.

Signed-off-by: Felix Fietkau 
Reported-by: Paul Stewart 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

imon: add conditional locking in change_protocol

2011-05-09T22:06:43+00:00

commit 23ef710e1a6c4d6b9ef1c2fa19410f7f1479401e upstream.

The imon_ir_change_protocol function gets called two different ways, one
way is from rc_register_device, for initial protocol selection/setup,
and the other is via a userspace-initiated protocol change request,
either by direct sysfs prodding or by something like ir-keytable.

In the rc_register_device case, the imon context lock is already held,
but when initiated from userspace, it is not, so we must acquire it,
prior to calling send_packet, which requires that the lock is held.

Without this change, there's an easily reproduceable deadlock when
another function calls send_packet (such as either of the display write
fops) after a userspace-initiated change_protocol.

With a lock-debugging-enabled kernel, I was getting this:

[   15.014153] =====================================
[   15.015048] [ BUG: bad unlock balance detected! ]
[   15.015048] -------------------------------------
[   15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at:
[   15.015048] [] mutex_unlock+0xe/0x10
[   15.015048] but there are no more locks to release!
[   15.015048]
[   15.015048] other info that might help us debug this:
[   15.015048] 2 locks held by ir-keytable/773:
[   15.015048]  #0:  (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x3c/0x144
[   15.015048]  #1:  (s_active#87){.+.+.+}, at: [] sysfs_write_file+0xe7/0x144
[   15.015048]
[   15.015048] stack backtrace:
[   15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1
[   15.015048] Call Trace:
[   15.015048]  [] ? print_unlock_inbalance_bug+0xca/0xd5
[   15.015048]  [] ? lock_release_non_nested+0xc1/0x263
[   15.015048]  [] ? mutex_unlock+0xe/0x10
[   15.015048]  [] ? mutex_unlock+0xe/0x10
[   15.015048]  [] ? lock_release+0x17d/0x1a4
[   15.015048]  [] ? __mutex_unlock_slowpath+0xc5/0x125
[   15.015048]  [] ? mutex_unlock+0xe/0x10
[   15.015048]  [] ? send_packet+0x1c9/0x264 [imon]
[   15.015048]  [] ? lock_release_non_nested+0xdb/0x263
[   15.015048]  [] ? imon_ir_change_protocol+0x126/0x15e [imon]
[   15.015048]  [] ? store_protocols+0x1c3/0x286 [rc_core]
[   15.015048]  [] ? dev_attr_store+0x20/0x22
[   15.015048]  [] ? sysfs_write_file+0x108/0x144
...

The original report that led to the investigation was the following:

[ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds.
[ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1679.457309] LCDd            D ffff88010fcd89c8     0  8460      1 0x00000000
[ 1679.457312]  ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8
[ 1679.457314]  00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0
[ 1679.457316]  ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8
[ 1679.457319] Call Trace:
[ 1679.457324]  [] ? zone_statistics+0x75/0x90
[ 1679.457327]  [] ? get_page_from_freelist+0x3c7/0x820
[ 1679.457330]  [] __mutex_lock_slowpath+0x139/0x320
[ 1679.457335]  [] mutex_lock+0x11/0x30
[ 1679.457338]  [] display_open+0x66/0x130 [imon]
[ 1679.457345]  [] usb_open+0x180/0x310 [usbcore]
[ 1679.457349]  [] chrdev_open+0x1bb/0x2d0
[ 1679.457350]  [] __dentry_open+0x10d/0x370
[ 1679.457352]  [] ? chrdev_open+0x0/0x2d0
...

Bump the driver version here so its easier to tell if people have this
locking fix or not, and also make locking during probe easier to follow.

Reported-by: Benjamin Hodgetts 
Signed-off-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

v4l: make sure drivers supply a zeroed struct v4l2_subdev

2011-05-09T22:06:43+00:00

commit 80845a33165278f3236812009e9c568ba8c29938 upstream.

Some v4l drivers currently don't initialize their struct v4l2_subdev
with zeros, and this is a problem since some of the v4l2 code expects
this. One example is the addition of internal_ops in commit 45f6f84,
after that we are at risk of random oopses with these drivers when code
in v4l2_device_register_subdev tries to dereference sd->internal_ops->*,
as can be shown by the report at http://bugs.launchpad.net/bugs/745213
and analysis of its crash at https://lkml.org/lkml/2011/4/1/168

Use kzalloc within problematic drivers to ensure we have a zeroed struct
v4l2_subdev.

BugLink: http://bugs.launchpad.net/bugs/745213
Signed-off-by: Herton Ronaldo Krzesinski 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

usbnet: add support for some Huawei modems with cdc-ether ports

2011-05-09T22:06:42+00:00

commit b3c914aa84f4e4bbb3efc8f41c359d96e5e932d2 upstream.

Some newer Huawei devices (T-Mobile Rocket, others) have cdc-ether
compatible ports, so recognize and expose them.

Signed-off-by: Dan Williams 
Acked-by: Oliver Neukum 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

firewire: Fix for broken configrom updates in quick succession

2011-05-09T22:06:42+00:00

commit 2e053a27d9d5ad5e0831e002cbf8043836fb2060 upstream.

Current implementation of ohci_set_config_rom() uses a deferred
bus reset via fw_schedule_bus_reset(). If clients add multiple
unit descriptors to the config_rom in quick succession, the
deferred bus reset may not have fired before succeeding update
requests have come in. This can lead to an incorrect partial
update of the config_rom for both addition and removal of
config_rom descriptors, as the ohci_set_config_rom() routine
will return -EBUSY if a previous pending update has not been
completed yet; the requested update just gets dropped on the floor.

This patch recognizes that the "in-flight" update can be modified
until it has been processed by the bus-reset, and the locking
in the bus_reset_tasklet ensures that the update is done atomically
with respect to modifications made by ohci_set_config_rom(). The
-EBUSY error case is simply removed.

[Stefan R:  The bug always existed at least theoretically.  But it
became easy to trigger since 2.6.36 commit 02d37bed188c "firewire: core:
integrate software-forced bus resets with bus management" which
introduced long mandatory delays between janitorial bus resets.]

Signed-off-by: Benjamin Buchalter 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

USB: fix regression in usbip by setting has_tt flag

2011-05-09T22:06:41+00:00

commit cee6a262550f53a13acfefbc1e3e5ff35c96182c upstream.

This patch (as1460) fixes a regression in the usbip driver caused by
the new check for Transaction Translators in USB-2 hubs.  The root hub
registered by vhci_hcd needs to have the has_tt flag set, because it
can connect to low- and full-speed devices as well as high-speed
devices.

Signed-off-by: Alan Stern 
Reported-and-tested-by: Nikola Ciprich 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix regression on atom cards with hardcoded EDID record.

2011-05-09T22:06:41+00:00

commit eaa4f5e1d0b816291a59a47917e569c0384f2b6f upstream.

Since fafcf94e2b5732d1e13b440291c53115d2b172e9 introduced an edid size, it seems to have broken this path.

This manifest as oops on T500 Lenovo laptops with dual graphics primarily.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33812

Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish

2011-05-09T22:06:40+00:00

commit 0c9c99a765321104cc5f9c97f949382a9ba4927e upstream.

It seems that under certain circumstances the sdhci_tasklet_finish()
call can be entered with mrq set to NULL, causing the system to crash
with a NULL pointer de-reference.

Seen on S3C6410 system.  Based on a patch by Dimitris Papastamos.

Reported-by: Dimitris Papastamos 
Signed-off-by: Chris Ball 
Signed-off-by: Greg Kroah-Hartman