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

drm/nouveau: fix booting with plymouth + dumb support

2012-09-19T14:05:24+00:00

commit 610bd7da160f76f1644ecb4cd7f39511b49a22cc upstream.

We noticed a plymouth bug on Fedora 18, and I then
noticed this stupid thinko, fixing it fixed the problem
with plymouth.

Acked-by: Ben Skeggs 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/radeon: rework pll selection (v3)

2012-09-19T14:05:23+00:00

commit 985f61f7ee647ad570c05eab0b74915da2ac8e19 upstream.

For DP we can use the same PPLL for all active DP
encoders.  Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work.  Also clean up the code
a bit.

v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
    - document functions
    - break in main encoder search loop after matching.
      no need to keep checking additional encoders.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54471

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings

drm/radeon: fix ordering in pll picking on dce4+

2012-09-19T14:05:23+00:00

commit ecd67955fd4c8e66e4df312098989d5fa7da624c upstream.

No functional change, but re-order the cases so they
evaluate properly due to the way the DCE macros work.

Noticed by kallisti5 on IRC.

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings

drm/radeon: fix up pll selection on DCE5/6

2012-09-19T14:05:22+00:00

commit 26fe45a0a76f165425f332a5aaa298f149f9db22 upstream.

Selecting ATOM_PPLL_INVALID should be equivalent as the
DCPLL or PPLL0 are already programmed for the DISPCLK, but
the preferred method is to always specify the PLL selected.
SetPixelClock will check the parameters and skip the
programming if the PLL is already set up.

Signed-off-by: Alex Deucher 
Reviewed-by: Christian König 
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings

ahci: Add alternate identifier for the 88SE9172

2012-09-19T14:05:22+00:00

commit 17c60c6b763cb5b83b0185e7d38d01d18e55a05a upstream.

This can also appear as 0x9192. Reported in bugzilla and confirmed with the
board documentation for these boards.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42970
Signed-off-by: Alan Cox 
Signed-off-by: Jeff Garzik 
Signed-off-by: Ben Hutchings

vmwgfx: add dumb ioctl support

2012-09-19T14:05:21+00:00

commit 5e1782d224c79b26ab7d5c31e3f87657000714fb upstream.

Testing and works with the -modesetting driver,

Reviewed-by: Jakob Bornecrantz 
Signed-off-by: Dave Airlie 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

hwmon: (twl4030-madc-hwmon) Initialize uninitialized structure elements

2012-09-19T14:05:21+00:00

commit 73d7c119255615a26070f9d6cdb722a166a29015 upstream.

twl4030_madc_conversion uses do_avg and type structure elements of
twl4030_madc_request. Initialize structure to avoid random operation.

Fix for: Coverity CID 200794 Uninitialized scalar variable.

Cc: Keerthy 
Signed-off-by: Guenter Roeck 
Acked-by: Jean Delvare 
Acked-by: Keerthy 
Signed-off-by: Ben Hutchings

EHCI: Update qTD next pointer in QH overlay region during unlink

2012-09-19T14:05:20+00:00

commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b upstream.

There is a possibility of QH overlay region having reference to a stale
qTD pointer during unlink.

Consider an endpoint having two pending qTD before unlink process begins.
The endpoint's QH queue looks like this.

qTD1 --> qTD2 --> Dummy

To unlink qTD2, QH is removed from asynchronous list and Asynchronous
Advance Doorbell is programmed.  The qTD1's next qTD pointer is set to
qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell
interrupt.  If QH's current qTD pointer points to qTD1, transfer overlay
region still have reference to qTD2. But qtD2 is just unlinked and freed.
This may cause EHCI system error.  Fix this by updating qTD next pointer
in QH overlay region with the qTD next pointer of the current qTD.

Signed-off-by: Pavankumar Kondeti 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

staging: r8712u: fix bug in r8712_recv_indicatepkt()

2012-09-19T14:05:20+00:00

commit abf02cfc179bb4bd30d05f582d61b3b8f429b813 upstream.

64bit arches have a buggy r8712u driver, let's fix it.

skb->tail must be set properly or network stack behavior is undefined.

Addresses https://bugzilla.redhat.com/show_bug.cgi?id=847525
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45071

Signed-off-by: Eric Dumazet 
Cc: Dave Jones 
Acked-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: ftdi_sio: do not claim CDC ACM function

2012-09-19T14:05:19+00:00

commit f08dea734844aa42ec57c229b0b73b3d7d21f810 upstream.

The Microchip vid:pid 04d8:000a is used for their CDC ACM
demo firmware application.  This is a device with a single
function conforming to the CDC ACM specification and with
the intention of demonstrating CDC ACM class firmware and
driver interaction.  The demo is used on a number of
development boards, and may also be used unmodified by
vendors using Microchip hardware.

Some vendors have re-used this vid:pid for other types of
firmware, emulating FTDI chips. Attempting to continue to
support such devices without breaking class based
applications that by matching on interface
class/subclass/proto being ff/ff/00.  I have no information
about the actual device or interface descriptors, but this
will at least make the proper CDC ACM devices work again.
Anyone having details of the offending device's descriptors
should update this entry with the details.

Reported-by: Florian Wöhrl 
Reported-by: Xiaofan Chen 
Cc: Alan Cox 
Cc: Bruno Thomsen 
Signed-off-by: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings