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

drm/radeon/combios: add some validation of lvds values

2015-08-12T14:33:24+00:00

commit 0a90a0cff9f429f886f423967ae053150dce9259 upstream.

Fixes a broken hsync start value uncovered by:
abc0b1447d4974963548777a5ba4a4457c82c426
(drm: Perform basic sanity checks on probed modes)

The driver handled the bad hsync start elsewhere, but
the above commit prevented it from getting added.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91401

Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

vhost: actually track log eventfd file

2015-08-12T14:33:24+00:00

commit 7932c0bd7740f4cd2aa168d3ce0199e7af7d72d5 upstream.

While reviewing vhost log code, I found out that log_file is never
set. Note: I haven't tested the change (QEMU doesn't use LOG_FD yet).

Signed-off-by: Marc-André Lureau 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Ben Hutchings

niu: don't count tx error twice in case of headroom realloc fails

2015-08-12T14:33:23+00:00

commit 42288830494cd51873ca745a7a229023df061226 upstream.

Fixes: a3138df9 ("[NIU]: Add Sun Neptune ethernet driver.")
Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

iscsi-target: Fix use-after-free during TPG session shutdown

2015-08-12T14:33:23+00:00

commit 417c20a9bdd1e876384127cf096d8ae8b559066c upstream.

This patch fixes a use-after-free bug in iscsit_release_sessions_for_tpg()
where se_portal_group->session_lock was incorrectly released/re-acquired
while walking the active se_portal_group->tpg_sess_list.

The can result in a NULL pointer dereference when iscsit_close_session()
shutdown happens in the normal path asynchronously to this code, causing
a bogus dereference of an already freed list entry to occur.

To address this bug, walk the session list checking for the same state
as before, but move entries to a local list to avoid dropping the lock
while walking the active list.

As before, signal using iscsi_session->session_restatement=1 for those
list entries to be released locally by iscsit_free_session() code.

Reported-by: Sunilkumar Nadumuttlu 
Cc: Sunilkumar Nadumuttlu 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Ben Hutchings

md/raid1: fix test for 'was read error from last working device'.

2015-08-12T14:33:23+00:00

commit 34cab6f42003cb06f48f86a86652984dec338ae9 upstream.

When we get a read error from the last working device, we don't
try to repair it, and don't fail the device.  We simple report a
read error to the caller.

However the current test for 'is this the last working device' is
wrong.
When there is only one fully working device, it assumes that a
non-faulty device is that device.  However a spare which is rebuilding
would be non-faulty but so not the only working device.

So change the test from "!Faulty" to "In_sync".  If ->degraded says
there is only one fully working device and this device is in_sync,
this must be the one.

This bug has existed since we allowed read_balance to read from
a recovering spare in v3.0

Reported-and-tested-by: Alexander Lyakas 
Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
Signed-off-by: NeilBrown 
Signed-off-by: Ben Hutchings

Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen

2015-08-12T14:33:23+00:00

commit 968491709e5b1aaf429428814fff3d932fa90b60 upstream.

This patch fixes a problem in the usbtouchscreen driver for DMC TSC-30
touch screen.  Due to a missing delay between the RESET and SET_RATE
commands, the touch screen may become unresponsive during system startup or
driver loading.

According to the DMC documentation, a delay is needed after the RESET
command to allow the chip to complete its internal initialization. As this
delay is not guaranteed, we had a system where the touch screen
occasionally did not send any touch data. There was no other indication of
the problem.

The patch fixes the problem by adding a 150ms delay between the RESET and
SET_RATE commands.

Suggested-by: Jakob Mustafa 
Signed-off-by: Bernhard Bender 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Ben Hutchings

usb-storage: ignore ZTE MF 823 card reader in mode 0x1225

2015-08-12T14:33:23+00:00

commit 5fb2c782f451a4fb9c19c076e2c442839faf0f76 upstream.

This device automatically switches itself to another mode (0x1405)
unless the specific access pattern of Windows is followed in its
initial mode. That makes a dirty unmount of the internal storage
devices inevitable if they are mounted. So the card reader of
such a device should be ignored, lest an unclean removal become
inevitable.

This replaces an earlier patch that ignored all LUNs of this device.
That patch was overly broad.

Signed-off-by: Oliver Neukum 
Reviewed-by: Lars Melin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

xhci: do not report PLC when link is in internal resume state

2015-08-12T14:33:23+00:00

commit aca3a0489ac019b58cf32794d5362bb284cb9b94 upstream.

Port link change with port in resume state should not be
reported to usbcore, as this is an internal state to be
handled by xhci driver. Reporting PLC to usbcore may
cause usbcore clearing PLC first and port change event irq
won't be generated.

Signed-off-by: Zhuang Jin Can 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2:
 - Adjust indentation
 - s/raw_port_status/temp/]
Signed-off-by: Ben Hutchings

xhci: report U3 when link is in resume state

2015-08-12T14:33:23+00:00

commit 243292a2ad3dc365849b820a64868927168894ac upstream.

xhci_hub_report_usb3_link_state() returns pls as U0 when the link
is in resume state, and this causes usb core to think the link is in
U0 while actually it's in resume state. When usb core transfers
control request on the link, it fails with TRB error as the link
is not ready for transfer.

To fix the issue, report U3 when the link is in resume state, thus
usb core knows the link it's not ready for transfer.

Signed-off-by: Zhuang Jin Can 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

xhci: Calculate old endpoints correctly on device reset

2015-08-12T14:33:22+00:00

commit 326124a027abc9a7f43f72dc94f6f0f7a55b02b3 upstream.

When resetting a device the number of active TTs may need to be
corrected by xhci_update_tt_active_eps, but the number of old active
endpoints supplied to it was always zero, so the number of TTs and the
bandwidth reserved for them was not updated, and could rise
unnecessarily.

This affected systems using Intel's Patherpoint chipset, which rely on
software bandwidth checking.  For example, a Lenovo X230 would lose the
ability to use ports on the docking station after enough suspend/resume
cycles because the bandwidth calculated would rise with every cycle when
a suitable device is attached.

The correct number of active endpoints is calculated in the same way as
in xhci_reserve_bandwidth.

Signed-off-by: Brian Campbell 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings