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

USB: pl2303: add ids for Hewlett-Packard HP POS pole displays

2014-05-06T14:51:46+00:00

commit b16c02fbfb963fa2941b7517ebf1f8a21946775e upstream.

Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:

LD960: 03f0:0B39
LCM220: 03f0:3139
LCM960: 03f0:3239

[ Johan: fix indentation and sort PIDs numerically ]

Signed-off-by: Aaron Sanders 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: unbind all interfaces before rebinding any

2014-05-06T14:51:45+00:00

commit 6aec044cc2f5670cf3b143c151c8be846499bd15 upstream.

When a driver doesn't have pre_reset, post_reset, or reset_resume
methods, the USB core unbinds that driver when its device undergoes a
reset or a reset-resume, and then rebinds it afterward.

The existing straightforward implementation can lead to problems,
because each interface gets unbound and rebound before the next
interface is handled.  If a driver claims additional interfaces, the
claim may fail because the old binding instance may still own the
additional interface when the new instance tries to claim it.

This patch fixes the problem by first unbinding all the interfaces
that are marked (i.e., their needs_binding flag is set) and then
rebinding all of them.

The patch also makes the helper functions in driver.c a little more
uniform and adjusts some out-of-date comments.

Signed-off-by: Alan Stern 
Reported-and-tested-by: "Poulain, Loic" 
Signed-off-by: Greg Kroah-Hartman

hvc: ensure hvc_init is only ever called once in hvc_console.c

2014-05-06T14:51:45+00:00

commit f76a1cbed18c86e2d192455f0daebb48458965f3 upstream.

Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of
khcvd thread") moved the call of hvc_init from being a device_initcall
into hvc_alloc, and used a non-null hvc_driver as indication of whether
hvc_init had already been called.

The problem with this is that hvc_driver is only assigned a value
at the bottom of hvc_init, and so there is a window where multiple
hvc_alloc calls can be in progress at the same time and hence try
and call hvc_init multiple times.  Previously the use of device_init
guaranteed that hvc_init was only called once.

This manifests itself as sporadic instances of two hvc_init calls
racing each other, and with the loser of the race getting -EBUSY
from tty_register_driver() and hence that virtual console fails:

    Couldn't register hvc console driver
    virtio-ports vport0p1: error -16 allocating hvc for port

Here we add an atomic_t to guarantee we'll never run hvc_init twice.

Cc: Rusty Russell 
Cc: Greg Kroah-Hartman 
Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread")
Reported-by: Jim Somerville 
Tested-by: Jim Somerville 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: fix wrong bit mask in dwc3_event_devt

2014-05-06T14:51:44+00:00

commit 06f9b6e59661cee510b04513b13ea7927727d758 upstream.

Around DWC USB3 2.30a release another bit has been added to the
Device-Specific Event (DEVT) Event Information (EvtInfo) bitfield.

Because of that, what used to be 8 bits long, has become 9 bits long.

Per dwc3 2.30a+ spec in the Device-Specific Event (DEVT), the field of
Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits
not 8 bits. And the following reserved field uses [31:25] bits not
[31:24] bits, and it has 7 bits.

So in dwc3_event_devt, the bit mask should be:
event_info	[24:16]		9 bits
reserved31_25	[31:25]		7 bits

This patch makes sure that newer core releases will work fine with
Linux and that we will decode the event information properly on new
core releases.

[ balbi@ti.com : improve commit log a bit ]

Signed-off-by: Huang Rui 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM

2014-05-06T14:51:44+00:00

commit 01bb59ebffdec314da8da66266edf29529372f9b upstream.

When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]

Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.

This warning has been in since 3.2 kernel and was
caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c
"usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
until 3.13 when a configuration with these options was tried

Signed-off-by: David Cohen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: extend quirk for Renesas cards

2014-05-06T14:51:44+00:00

commit 6db249ebefc6bf5c39f35dfaacc046d8ad3ffd70 upstream.

After suspend another Renesas PCI-X USB 3.0 card doesn't work.
[root@fedora-20 ~]# lspci -vmnnd 1912:
Device:	03:00.0
Class:	USB controller [0c03]
Vendor:	Renesas Technology Corp. [1912]
Device:	uPD720202 USB 3.0 Host Controller [0015]
SVendor:	Renesas Technology Corp. [1912]
SDevice:	uPD720202 USB 3.0 Host Controller [0015]
Rev:	02
ProgIf:	30

This patch should be applied to stable kernel 3.14 that contain
the commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d
"xhci: Fix resume issues on Renesas chips in Samsung laptops"

Reported-and-tested-by: Anatoly Kharchenko 
Reference: http://redmine.russianfedora.pro/issues/1315
Signed-off-by: Igor Gnatenko 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: musb: set TXMAXP and AUTOSET for full speed bulk in device mode

2014-05-06T14:51:44+00:00

commit bb3a2ef2eb8cfaea335dcb3426350df7f3d48069 upstream.

The TXMAXP register is not set correctly for full speed bulk case
when the can_bulk_split() is used. Without this PIO transfers will
not take place correctly

The "mult" factor needs to be updated correctly for the
can_bulk_split() case

The AUTOSET bit in the TXCSR is not being set if the "mult"
factor is greater than 0 for the High Bandwidth ISO case.
But the "mult" factor is also greater than 0 in case of Full speed
bulk transfers with the packet splitting in TXMAXP register

Without the AUTOSET the DMA transfers will not progress in mode1

[ balbi@ti.com : add braces to both branches ]

Signed-off-by: supriya karanth 
Signed-off-by: Praveena NADAHALLY 
Acked-by: Linus Walleij 
Signed-off-by: Felipe Balbi 
Cc: ian coolidge 
Signed-off-by: Greg Kroah-Hartman

target/tcm_fc: Fix use-after-free of ft_tpg

2014-05-06T14:51:44+00:00

commit 2c42be2dd4f6586728dba5c4e197afd5cfaded78 upstream.

ft_del_tpg checks tpg->tport is set before unlinking the tpg from the
tport when the tpg is being removed. Set this pointer in ft_tport_create,
or the unlinking won't happen in ft_del_tpg and tport->tpg will reference
a deleted object.

This patch sets tpg->tport in ft_tport_create, because that's what
ft_del_tpg checks, and is the only way to get back to the tport to
clear tport->tpg.

The bug was occuring when:

- lport created, tport (our per-lport, per-provider context) is
  allocated.
  tport->tpg = NULL
- tpg created
- a PRLI is received. ft_tport_create is called, tpg is found and
  tport->tpg is set
- tpg removed. ft_tpg is freed in ft_del_tpg. Since tpg->tport was not
  set, tport->tpg is not cleared and points at freed memory
- Future calls to ft_tport_create return tport via first conditional,
  instead of searching for new tpg by calling ft_lport_find_tpg.
  tport->tpg is still invalid, and will access freed memory.

see https://bugzilla.redhat.com/show_bug.cgi?id=1071340

Signed-off-by: Andy Grover 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

iscsi-target: Fix ERL=2 ASYNC_EVENT connection pointer bug

2014-05-06T14:51:43+00:00

commit d444edc679e7713412f243b792b1f964e5cff1e1 upstream.

This patch fixes a long-standing bug in iscsit_build_conn_drop_async_message()
where during ERL=2 connection recovery, a bogus conn_p pointer could
end up being used to send the ISCSI_OP_ASYNC_EVENT + DROPPING_CONNECTION
notifying the initiator that cmd->logout_cid has failed.

The bug was manifesting itself as an OOPs in iscsit_allocate_cmd() with
a bogus conn_p pointer in iscsit_build_conn_drop_async_message().

Reported-by: Arshad Hussain 
Reported-by: santosh kulkarni 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

SCSI: arcmsr: upper 32 of dma address lost

2014-05-06T14:51:43+00:00

commit e2c70425f05219b142b3a8a9489a622c736db39d upstream.

The original code always set the upper 32 bits to zero because it was
doing a shift of the wrong variable.

Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other fixes')
Signed-off-by: Dan Carpenter 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman