linux.git/drivers, branch v3.0.48

tpm: Propagate error from tpm_transmit to fix a timeout hang

2012-10-21T16:17:12+00:00

commit abce9ac292e13da367bbd22c1f7669f988d931ac upstream.

tpm_write calls tpm_transmit without checking the return value and
assigns the return value unconditionally to chip->pending_data, even if
it's an error value.
This causes three bugs.

So if we write to /dev/tpm0 with a tpm_param_size bigger than
TPM_BUFSIZE=0x1000 (e.g. 0x100a)
and a bufsize also bigger than TPM_BUFSIZE (e.g. 0x100a)
tpm_transmit returns -E2BIG which is assigned to chip->pending_data as
-7, but tpm_write returns that TPM_BUFSIZE bytes have been successfully
been written to the TPM, altough this is not true (bug #1).

As we did write more than than TPM_BUFSIZE bytes but tpm_write reports
that only TPM_BUFSIZE bytes have been written the vfs tries to write
the remaining bytes (in this case 10 bytes) to the tpm device driver via
tpm_write which then blocks at

 /* cannot perform a write until the read has cleared
 either via tpm_read or a user_read_timer timeout */
 while (atomic_read(&chip->data_pending) != 0)
	 msleep(TPM_TIMEOUT);

for 60 seconds, since data_pending is -7 and nobody is able to
read it (since tpm_read luckily checks if data_pending is greater than
0) (#bug 2).

After that the remaining bytes are written to the TPM which are
interpreted by the tpm as a normal command. (bug #3)
So if the last bytes of the command stream happen to be a e.g.
tpm_force_clear this gets accidentally sent to the TPM.

This patch fixes all three bugs, by propagating the error code of
tpm_write and returning -E2BIG if the input buffer is too big,
since the response from the tpm for a truncated value is bogus anyway.
Moreover it returns -EBUSY to userspace if there is a response ready to be
read.

Signed-off-by: Peter Huewe 
Signed-off-by: Kent Yoder 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy().

2012-10-21T16:17:12+00:00

commit 082918471139b07964967cfe5f70230909c82ae1 upstream.

radeon_i2c_fini() walks thru the list of I2C bus recs rdev->i2c_bus[]
to destroy each of them.
radeon_ext_tmds_enc_destroy() however also has code to destroy it's
associated I2C bus rec which has been obtained by radeon_i2c_lookup()
and is therefore also in the i2c_bus[] list.
This causes a double free resulting in a kernel panic when unloading
the radeon driver.
Removing destroy code from radeon_ext_tmds_enc_destroy() fixes this
problem.

agd5f: fix compiler warning

Signed-off-by: Egbert Eich 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

Add CDC-ACM support for the CX93010-2x UCMxx USB Modem

2012-10-21T16:17:11+00:00

commit e7d491a19d3e3aac544070293891a2542ae0c565 upstream.

This USB V.92/V.32bis Controllered Modem have the USB vendor ID 0x0572
and device ID 0x1340. It need the NO_UNION_NORMAL quirk to be recognized.

Reference:
http://www.conexant.com/servlets/DownloadServlet/DSH-201723-005.pdf?docid=1725&revid=5
See idVendor and idProduct in table 6-1. Device Descriptors

Signed-off-by: Jean-Christian de Rivaz 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tg3: Apply short DMA frag workaround to 5906

2012-10-21T16:17:11+00:00

commit b7abee6ef888117f92db370620ebf116a38e3f4d upstream.

5906 devices also need the short DMA fragment workaround.  This patch
makes the necessary change.

Signed-off-by: Matt Carlson 
Tested-by: Christian Kujau 
Signed-off-by: David S. Miller 
Signed-off-by: Mike Pagano

viafb: don't touch clock state on OLPC XO-1.5

2012-10-21T16:17:10+00:00

commit 012a1211845eab69a5488d59eb87d24cc518c627 upstream.

As detailed in the thread titled "viafb PLL/clock tweaking causes XO-1.5
instability," enabling or disabling the IGA1/IGA2 clocks causes occasional
stability problems during suspend/resume cycles on this platform.

This is rather odd, as the documentation suggests that clocks have two
states (on/off) and the default (stable) configuration is configured to
enable the clock only when it is needed. However, explicitly enabling *or*
disabling the clock triggers this system instability, suggesting that there
is a 3rd state at play here.

Leaving the clock enable/disable registers alone solves this problem.
This fixes spurious reboots during suspend/resume behaviour introduced by
commit b692a63a.

Signed-off-by: Daniel Drake 
Signed-off-by: Florian Tobias Schandinat 
Signed-off-by: Greg Kroah-Hartman

video/udlfb: fix line counting in fb_write

2012-10-21T16:17:10+00:00

commit b8c4321f3d194469007f5f5f2b34ec278c264a04 upstream.

Line 0 and 1 were both written to line 0 (on the display) and all subsequent
lines had an offset of -1. The result was that the last line on the display
was never overwritten by writes to /dev/fbN.

Signed-off-by: Alexander Holler 
Acked-by: Bernie Thompson 
Signed-off-by: Florian Tobias Schandinat 
Signed-off-by: Greg Kroah-Hartman

firewire: cdev: fix user memory corruption (i386 userland on amd64 kernel)

2012-10-21T16:17:10+00:00

commit 790198f74c9d1b46b6a89504361b1a844670d050 upstream.

Fix two bugs of the /dev/fw* character device concerning the
FW_CDEV_IOC_GET_INFO ioctl with nonzero fw_cdev_get_info.bus_reset.
(Practically all /dev/fw* clients issue this ioctl right after opening
the device.)

Both bugs are caused by sizeof(struct fw_cdev_event_bus_reset) being 36
without natural alignment and 40 with natural alignment.

 1) Memory corruption, affecting i386 userland on amd64 kernel:
    Userland reserves a 36 bytes large buffer, kernel writes 40 bytes.
    This has been first found and reported against libraw1394 if
    compiled with gcc 4.7 which happens to order libraw1394's stack such
    that the bug became visible as data corruption.

 2) Information leak, affecting all kernel architectures except i386:
    4 bytes of random kernel stack data were leaked to userspace.

Hence limit the respective copy_to_user() to the 32-bit aligned size of
struct fw_cdev_event_bus_reset.

Reported-by: Simon Kirby 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop

2012-10-21T16:17:09+00:00

commit 67bfa9b60bd689601554526d144b21d529f78a09 upstream.

By enlarging the GPE storm threshold back to 20, that laptop's
EC works fine with interrupt mode instead of polling mode.

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

Reported-and-Tested-by: Francesco 
Signed-off-by: Feng Tang 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Make the GPE storm threshold a module parameter

2012-10-21T16:17:09+00:00

commit a520d52e99b14ba7db135e916348f12f2a6e09be upstream.

The Linux EC driver includes a mechanism to detect GPE storms,
and switch from interrupt-mode to polling mode.  However, polling
mode sometimes doesn't work, so the workaround is problematic.
Also, different systems seem to need the threshold for detecting
the GPE storm at different levels.

ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and
was changed to 8 in 2.6.28 commit 06cf7d3c7 "ACPI: EC: lower interrupt storm
threshold" to fix kernel bug 11892 by forcing the laptop in that bug to
work in polling mode. However in bug 45151, it works fine in interrupt
mode if we lift the threshold back to 20.

This patch makes the threshold a module parameter so that user has a
flexible option to debug/workaround this issue.

The default is unchanged.

This is also a preparation patch to fix specific systems:
	https://bugzilla.kernel.org/show_bug.cgi?id=45151

Signed-off-by: Feng Tang 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

mtd: omap2: fix module loading

2012-10-12T20:28:15+00:00

commit 4d3d688da8e7016f15483e9319b41311e1db9515 upstream.

Unloading the omap2 nand driver missed to release the memory region which will
result in not being able to request it again if one want to load the driver
later on.

This patch fixes following error when loading omap2 module after unloading:
---8<---
~ $ rmmod omap2
~ $ modprobe omap2
[   37.420928] omap2-nand: probe of omap2-nand.0 failed with error -16
~ $
--->8---

This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which
was the first commit of this driver.

Signed-off-by: Andreas Bießmann 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman