linux-toradex.git/drivers/usb, branch v3.12.42 Linux kernel for Apalis and Colibri modules usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers 2015-04-22T06:58:42+00:00 Lu Baolu baolu.lu@linux.intel.com 2015-03-23T16:27:42+00:00 0bd2650374e49b61e9cac8e22ae6ee3ed847b355 commit 227a4fd801c8a9fa2c4700ab98ec1aec06e3b44d upstream. When a device with an isochronous endpoint is plugged into the Intel xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under Intel xHCI host controllers, if the event ring is full of events from transfers with BEI set, an "Event Ring is Full" event will be posted to the last entry of the event ring, but no interrupt is generated. Host will cease all transfer and command executions and wait until software completes handling the pending events in the event ring. That means xHC stops, but event of "event ring is full" is not notified. As the result, the xHC looks like dead to user. This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And it should be backported to kernels as old as 3.0, that contains the commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching."). Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Tested-by: Alistair Grant <akgrant0710@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit 227a4fd801c8a9fa2c4700ab98ec1aec06e3b44d upstream.

When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
but the last TD for the URB. This causes the host controller to place
an event on the event ring, but not send an interrupt. When the last
TD for the URB completes, BEI is cleared, and we get an interrupt for
the whole URB.

However, under Intel xHCI host controllers, if the event ring is full
of events from transfers with BEI set,  an "Event Ring is Full" event
will be posted to the last entry of the event ring,  but no interrupt
is generated. Host will cease all transfer and command executions and
wait until software completes handling the pending events in the event
ring.  That means xHC stops, but event of "event ring is full" is not
notified. As the result, the xHC looks like dead to user.

This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
it should be backported to kernels as old as 3.0, that contains the
commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").

Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Tested-by: Alistair Grant <akgrant0710@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
usb: xhci: handle Config Error Change (CEC) in xhci driver 2015-04-22T06:58:41+00:00 Lu Baolu baolu.lu@linux.intel.com 2015-03-23T16:27:41+00:00 55d572b94414646ebcd04840f28a8681fe50059e commit 9425183d177aa4a2f09d01a74925124f0778b595 upstream. Linux xHCI driver doesn't report and handle port cofig error change. If Port Configure Error for root hub port occurs, CEC bit in PORTSC would be set by xHC and remains 1. This happends when the root port fails to configure its link partner, e.g. the port fails to exchange port capabilities information using Port Capability LMPs. Then the Port Status Change Events will be blocked until all status change bits(CEC is one of the change bits) are cleared('0') (refer to xHCI spec 4.19.2). Otherwise, the port status change event for this root port will not be generated anymore, then root port would look like dead for user and can't be recovered until a Host Controller Reset(HCRST). This patch is to check CEC bit in PORTSC in xhci_get_port_status() and set a Config Error in the return status if CEC is set. This will cause a ClearPortFeature request, where CEC bit is cleared in xhci_clear_port_change_bit(). [The commit log is based on initial Marvell patch posted at http://marc.info/?l=linux-kernel&m=142323612321434&w=2] Reported-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit 9425183d177aa4a2f09d01a74925124f0778b595 upstream.

Linux xHCI driver doesn't report and handle port cofig error change.
If Port Configure Error for root hub port occurs, CEC bit in PORTSC
would be set by xHC and remains 1. This happends when the root port
fails to configure its link partner, e.g. the port fails to exchange
port capabilities information using Port Capability LMPs.

Then the Port Status Change Events will be blocked until all status
change bits(CEC is one of the change bits) are cleared('0') (refer to
xHCI spec 4.19.2). Otherwise, the port status change event for this
root port will not be generated anymore, then root port would look
like dead for user and can't be recovered until a Host Controller
Reset(HCRST).

This patch is to check CEC bit in PORTSC in xhci_get_port_status()
and set a Config Error in the return status if CEC is set. This will
cause a ClearPortFeature request, where CEC bit is cleared in
xhci_clear_port_change_bit().

[The commit log is based on initial Marvell patch posted at
http://marc.info/?l=linux-kernel&m=142323612321434&w=2]

Reported-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
USB: ftdi_sio: Use jtag quirk for SNAP Connect E10 2015-04-22T06:58:37+00:00 Doug Goldstein cardoe@cardoe.com 2015-03-24T01:34:48+00:00 708d0b8820cbf11df7a7dc2003c950c733bad2b6 commit b229a0f840f774d29d8fedbf5deb344ca36b7f1a upstream. This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order to avoid attaching a TTY to the JTAG port as this board is based on the CALAO Systems reference design and needs the same fix up. Signed-off-by: Doug Goldstein <cardoe@cardoe.com> [johan: clean up probe logic ] Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit b229a0f840f774d29d8fedbf5deb344ca36b7f1a upstream.

This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order
to avoid attaching a TTY to the JTAG port as this board is based on the
CALAO Systems reference design and needs the same fix up.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
[johan: clean up probe logic ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
USB: ftdi_sio: Added custom PID for Synapse Wireless product 2015-04-22T06:58:37+00:00 Doug Goldstein cardoe@cardoe.com 2015-03-16T02:56:04+00:00 4b54431d13031c3eec8102859e3413b06e322569 commit 4899c054a90439477b24da8977db8d738376fe90 upstream. Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their SNAP Stick 200 product. Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit 4899c054a90439477b24da8977db8d738376fe90 upstream.

Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their
SNAP Stick 200 product.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
USB: zte_ev: fix removed PIDs 2015-04-09T12:13:33+00:00 Johan Hovold johan@kernel.org 2014-08-28T10:46:54+00:00 10b98d53f150f146e115d1c17d870b21274e2fdb commit 3096691011d01cef56b243a5e65431405c07d574 upstream. Add back some PIDs that were mistakingly remove when reverting commit 73228a0538a7 ("USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"), which apparently did more than its commit message claimed in that it not only moved some PIDs from option to zte_ev but also added some new ones. Fixes: 63a901c06e3c ("Revert "USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"") Reported-by: Lei Liu <lei35151@163.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit 3096691011d01cef56b243a5e65431405c07d574 upstream.

Add back some PIDs that were mistakingly remove when reverting commit
73228a0538a7 ("USB: option,zte_ev: move most ZTE CDMA devices to
zte_ev"), which apparently did more than its commit message claimed in
that it not only moved some PIDs from option to zte_ev but also added
some new ones.

Fixes: 63a901c06e3c ("Revert "USB: option,zte_ev: move most ZTE CDMA
devices to zte_ev"")

Reported-by: Lei Liu <lei35151@163.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
HID: yet another buggy ELAN touchscreen 2015-03-16T10:09:26+00:00 Oliver Neukum oneukum@suse.de 2014-11-17T16:11:42+00:00 7a9e5752e88d6f6aedf3052857f398298df9c0ed commit a32c99e7ab8410bae7c276a7e94ca84d108de034 upstream. The touchscreen needs the same quirk as the other models. Signed-off-by: Oliver Neukum <oneukum@suse.de> Reported-by: Bryan Poling <poli0048@umn.edu> CC: stable@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit a32c99e7ab8410bae7c276a7e94ca84d108de034 upstream.

The touchscreen needs the same quirk as the other models.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Reported-by: Bryan Poling <poli0048@umn.edu>
CC: stable@vger.kernel.org
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
xhci: no switching back on non-ULT Haswell 2015-03-13T11:13:43+00:00 Oliver Neukum oneukum@suse.de 2014-10-27T13:53:29+00:00 dc9d0f676e3722772d07b2d39f333ba313ea4862 commit b45abacde3d551c6696c6738bef4a1805d0bf27a upstream. The switch back is limited to ULT even on HP. The contrary finding arose by bad luck in BIOS versions for testing. This fixes spontaneous resume from S3 on some HP laptops. Signed-off-by: Oliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit b45abacde3d551c6696c6738bef4a1805d0bf27a upstream.

The switch back is limited to ULT even on HP. The contrary
finding arose by bad luck in BIOS versions for testing.
This fixes spontaneous resume from S3 on some HP laptops.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
cdc-acm: Add support for Denso cradle CU-321 2015-03-12T16:31:25+00:00 Björn Gerhart oss@airbjorn.de 2015-02-18T06:19:44+00:00 e3bc11535cdd5e26a162dbc280c2e062b7749254 commit b20b1618b8fca858c83e52da4aa22cd6b13b0359 upstream. In order to support an older USB cradle by Denso, I added its vendor- and product-ID to the array of usb_device_id acm_ids. In this way cdc-acm feels responsible for this cradle. The related /dev/ttyACM node is being created properly, and the data transfer works. However, later cradle models by Denso do have proper descriptors, so the patch is not required for these. At the same time both the older and the later model have the same vendor- and product-ID, but they both work with the patched driver. Declaration of the Denso cradles I tested: - both models have the same IDs: vendorID 0x076d, productID 0x0006 - older model: Denso CU-321 (descriptors not properly set) - later model: Denso CU-821 (with proper descriptors) Signed-off-by: Bjoern Gerhart <oss@airbjorn.de> Acked-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit b20b1618b8fca858c83e52da4aa22cd6b13b0359 upstream.

In order to support an older USB cradle by Denso, I added its vendor- and product-ID to the array of usb_device_id acm_ids. In this way cdc-acm feels responsible for this cradle. The related /dev/ttyACM node is being created properly, and the data transfer works.

However, later cradle models by Denso do have proper descriptors, so the patch is not required for these. At the same time both the older and the later model have the same vendor- and product-ID, but they both work with the patched driver.

Declaration of the Denso cradles I tested:
- both models have the same IDs: vendorID 0x076d, productID 0x0006
- older model: Denso CU-321 (descriptors not properly set)
- later model: Denso CU-821 (with proper descriptors)

Signed-off-by: Bjoern Gerhart <oss@airbjorn.de>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
usb: musb: core: add pm_runtime_irq_safe() 2015-03-12T16:31:24+00:00 Felipe Balbi balbi@ti.com 2015-02-02T23:12:00+00:00 95353e3525c5eb75881dc4ab7690541fb2c1776e commit 3e43a0725637299a14369e3ef109c25a8ec5c008 upstream. We need a pm_runtime_get_sync() call from within musb_gadget_pullup() to make sure registers are accessible at that time. The problem is that musb_gadget_pullup() is called with IRQs disabled and, because of that, we need to tell pm_runtime that this pm_runtime_get_sync() is IRQ safe. We can simply add pm_runtime_irq_safe(), however, because we need to make our read/write accessor function pointers have been initialized before trying to use them. This means that all pm_runtime initialization for musb_core needs to be moved down so that when we call pm_runtime_irq_safe(), the pm_runtime_get_sync() that it calls on the parent, won't cause a crash due to NULL musb_read/write accessors. Reported-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit 3e43a0725637299a14369e3ef109c25a8ec5c008 upstream.

We need a pm_runtime_get_sync() call from
within musb_gadget_pullup() to make sure
registers are accessible at that time.

The problem is that musb_gadget_pullup() is
called with IRQs disabled and, because of that,
we need to tell pm_runtime that this pm_runtime_get_sync()
is IRQ safe.

We can simply add pm_runtime_irq_safe(), however, because
we need to make our read/write accessor function pointers
have been initialized before trying to use them. This means
that all pm_runtime initialization for musb_core needs to
be moved down so that when we call pm_runtime_irq_safe(),
the pm_runtime_get_sync() that it calls on the parent, won't
cause a crash due to NULL musb_read/write accessors.

Reported-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
usb: gadget: function: phonet: balance usb_ep_disable calls 2015-03-12T16:31:24+00:00 Felipe Balbi balbi@ti.com 2015-02-02T22:24:17+00:00 2019319b6ab967b7c3de01472b3feca251976cf7 commit 9ec36f7fe20ef919cc15171e1da1b6739222541a upstream. f_phonet's ->set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit 9ec36f7fe20ef919cc15171e1da1b6739222541a upstream.

f_phonet's ->set_alt() method will call usb_ep_disable()
potentially on an endpoint which is already disabled. That's
something the gadget/function driver must guarantee that it's
always balanced.

In order to balance the calls, just make sure the endpoint
was enabled before by means of checking the validity of
driver_data.

Reported-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>