summaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2017-01-13USB: serial: option: add dlink dwm-158Giuseppe Lippolis1-0/+1
[ Upstream commit d8a12b7117b42fd708f1e908498350232bdbd5ff ] Adding registration for 3G modem DWM-158 in usb-serial-option Signed-off-by: Giuseppe Lippolis <giu.lippolis@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-01-13USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041Daniele Palmas1-0/+6
[ Upstream commit 5b09eff0c379002527ad72ea5ea38f25da8a8650 ] This patch adds support for PIDs 0x1040, 0x1041 of Telit LE922A. Since the interface positions are the same than the ones used for other Telit compositions, previous defined blacklists are used. Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-01-13USB: cdc-acm: add device id for GW Instek AFG-125Nathaniel Quillin1-0/+1
[ Upstream commit 301216044e4c27d5a7323c1fa766266fad00db5e ] Add device-id entry for GW Instek AFG-125, which has a byte swapped bInterfaceSubClass (0x20). Signed-off-by: Nathaniel Quillin <ndq@google.com> Acked-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-01-13USB: serial: kl5kusb105: fix open error pathJohan Hovold1-9/+24
[ Upstream commit 6774d5f53271d5f60464f824748995b71da401ab ] Kill urbs and disable read before returning from open on failure to retrieve the line state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-01-13usb: hub: Fix auto-remount of safely removed or ejected USB-3 devicesMathias Nyman1-65/+36
[ Upstream commit 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 ] USB-3 does not have any link state that will avoid negotiating a connection with a plugged-in cable but will signal the host when the cable is unplugged. For USB-3 we used to first set the link to Disabled, then to RxDdetect to be able to detect cable connects or disconnects. But in RxDetect the connected device is detected again and eventually enabled. Instead set the link into U3 and disable remote wakeups for the device. This is what Windows does, and what Alan Stern suggested. Cc: stable@vger.kernel.org Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-01-13USB: UHCI: report non-PME wakeup signalling for Intel hardwareAlan Stern1-0/+4
[ Upstream commit ccdb6be9ec6580ef69f68949ebe26e0fb58a6fb0 ] The UHCI controllers in Intel chipsets rely on a platform-specific non-PME mechanism for wakeup signalling. They can generate wakeup signals even though they don't support PME. We need to let the USB core know this so that it will enable runtime suspend for UHCI controllers. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: stable@vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-01-13usb: gadget: composite: correctly initialize ep->maxpacketFelipe Balbi1-1/+1
[ Upstream commit e8f29bb719b47a234f33b0af62974d7a9521a52c ] usb_endpoint_maxp() returns wMaxPacketSize in its raw form. Without taking into consideration that it also contains other bits reserved for isochronous endpoints. This patch fixes one occasion where this is a problem by making sure that we initialize ep->maxpacket only with lower 10 bits of the value returned by usb_endpoint_maxp(). Note that seperate patches will be necessary to audit all call sites of usb_endpoint_maxp() and make sure that usb_endpoint_maxp() only returns lower 10 bits of wMaxPacketSize. Cc: <stable@vger.kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-11-26USB: serial: cp210x: fix tiocmget error handlingJohan Hovold1-1/+3
[ Upstream commit de24e0a108bc48062e1c7acaa97014bce32a919f ] The current tiocmget implementation would fail to report errors up the stack and instead leaked a few bits from the stack as a mask of modem-status flags. Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-11-24usb: increase ohci watchdog delay to 275 msecBryan Paluch1-1/+1
[ Upstream commit ed6d6f8f42d7302f6f9b6245f34927ec20d26c12 ] Increase ohci watchout delay to 275 ms. Previous delay was 250 ms with 20 ms of slack, after removing slack time some ohci controllers don't respond in time. Logs from systems with controllers that have the issue would show "HcDoneHead not written back; disabled" Signed-off-by: Bryan Paluch <bryanpaluch@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-11-24USB: serial: fix potential NULL-dereference at probeJohan Hovold1-1/+2
[ Upstream commit 126d26f66d9890a69158812a6caa248c05359daa ] Make sure we have at least one port before attempting to register a console. Currently, at least one driver binds to a "dummy" interface and requests zero ports for it. Should such an interface also lack endpoints, we get a NULL-deref during probe. Fixes: e5b1e2062e05 ("USB: serial: make minor allocation dynamic") Cc: stable <stable@vger.kernel.org> # 3.11 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-11-24xhci: workaround for hosts missing CAS bitMathias Nyman3-0/+46
[ Upstream commit 346e99736c3ce328fd42d678343b70243aca5f36 ] If a device is unplugged and replugged during Sx system suspend some Intel xHC hosts will overwrite the CAS (Cold attach status) flag and no device connection is noticed in resume. A device in this state can be identified in resume if its link state is in polling or compliance mode, and the current connect status is 0. A device in this state needs to be warm reset. Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 Observed on Cherryview and Apollolake as they go into compliance mode if LFPS times out during polling, and re-plugged devices are not discovered at resume. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-11-24xhci: add restart quirk for Intel Wildcatpoint PCHMathias Nyman1-1/+3
[ Upstream commit 4c39135aa412d2f1381e43802523da110ca7855c ] xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the same quirks to prevent machines from spurious restart while shutting them down. Reported-by: Hasan Mahmood <hasan.mahm@gmail.com> CC: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-11-01USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7Stefan Tauner2-3/+5
[ Upstream commit ca006f785fbfd7a5c901900bd3fe2b26e946a1ee ] This adds support to ftdi_sio for the Infineon TriBoard TC2X7 engineering board for first-generation Aurix SoCs with Tricore CPUs. Mere addition of the device IDs does the job. Signed-off-by: Stefan Tauner <stefan.tauner@technikum-wien.at> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-11-01usb: gadget: function: u_ether: don't starve tx request queueFelipe Balbi1-2/+3
[ Upstream commit 6c83f77278f17a7679001027e9231291c20f0d8a ] If we don't guarantee that we will always get an interrupt at least when we're queueing our very last request, we could fall into situation where we queue every request with 'no_interrupt' set. This will cause the link to get stuck. The behavior above has been triggered with g_ether and dwc3. Cc: <stable@vger.kernel.org> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-10-24xhci: fix usb2 resume timing and races.Mathias Nyman2-6/+42
[ Upstream commit f69115fdbc1ac0718e7d19ad3caa3da2ecfe1c96 ] According to USB 2 specs ports need to signal resume for at least 20ms, in practice even longer, before moving to U0 state. Both host and devices can initiate resume. On device initiated resume, a port status interrupt with the port in resume state in issued. The interrupt handler tags a resume_done[port] timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer. Root hub timer requests for port status, finds the port in resume state, checks if resume_done[port] timestamp passed, and set port to U0 state. On host initiated resume, current code sets the port to resume state, sleep 20ms, and finally sets the port to U0 state. This should also be changed to work in a similar way as the device initiated resume, with timestamp tagging, but that is not yet tested and will be a separate fix later. There are a few issues with this approach 1. A host initiated resume will also generate a resume event. The event handler will find the port in resume state, believe it's a device initiated resume, and act accordingly. 2. A port status request might cut the resume signalling short if a get_port_status request is handled during the host resume signalling. The port will be found in resume state. The timestamp is not set leading to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0. get_port_status will proceed with moving the port to U0. 3. If an error, or anything else happens to the port during device initiated resume signalling it will leave all the device resume parameters hanging uncleared, preventing further suspend, returning -EBUSY, and cause the pm thread to busyloop trying to enter suspend. Fix this by using the existing resuming_ports bitfield to indicate that resume signalling timing is taken care of. Check if the resume_done[port] is set before using it for timestamp comparison, and also clear out any resume signalling related variables if port is not in U0 or Resume state This issue was discovered when a PM thread busylooped, trying to runtime suspend the xhci USB 2 roothub on a Dell XPS Cc: stable <stable@vger.kernel.org> Reported-by: Daniel J Blueman <daniel@quora.org> Tested-by: Daniel J Blueman <daniel@quora.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-10-03USB: change bInterval default to 10 msAlan Stern1-11/+17
[ Upstream commit 08c5cd37480f59ea39682f4585d92269be6b1424 ] Some full-speed mceusb infrared transceivers contain invalid endpoint descriptors for their interrupt endpoints, with bInterval set to 0. In the past they have worked out okay with the mceusb driver, because the driver sets the bInterval field in the descriptor to 1, overwriting whatever value may have been there before. However, this approach was never sanctioned by the USB core, and in fact it does not work with xHCI controllers, because they use the bInterval value that was present when the configuration was installed. Currently usbcore uses 32 ms as the default interval if the value in the endpoint descriptor is invalid. It turns out that these IR transceivers don't work properly unless the interval is set to 10 ms or below. To work around this mceusb problem, this patch changes the endpoint-descriptor parsing routine, making the default interval value be 10 ms rather than 32 ms. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Wade Berrier <wberrier@gmail.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-10-03USB: serial: simple: add support for another Infineon flashloaderDaniele Palmas1-1/+2
[ Upstream commit f190fd92458da3e869b4e2c6289e2c617490ae53 ] This patch adds support for Infineon flashloader 0x8087/0x0801. The flashloader is used in Telit LE940B modem family with Telit flashing application. Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-10-03usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phaseClemens Gruber1-0/+9
[ Upstream commit 6f3c4fb6d05e63c9c6d8968302491c3a5457be61 ] Problems with the signal integrity of the high speed USB data lines or noise on reference ground lines can cause the i.MX6 USB controller to violate USB specs and exhibit unexpected behavior. It was observed that USBi_UI interrupts were triggered first and when isr_setup_status_phase was called, ci->status was NULL, which lead to a NULL pointer dereference kernel panic. This patch fixes the kernel panic, emits a warning once and returns -EPIPE to halt the device and let the host get stalled. It also adds a comment to point people, who are experiencing this issue, to their USB hardware design. Cc: <stable@vger.kernel.org> #4.1+ Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-10-03xhci: fix null pointer dereference in stop command timeout functionMathias Nyman1-1/+5
[ Upstream commit bcf42aa60c2832510b9be0f30c090bfd35bb172d ] The stop endpoint command has its own 5 second timeout timer. If the timeout function is triggered between USB3 and USB2 host removal it will try to call usb_hc_died(xhci_to_hcd(xhci)->primary_hcd) the ->primary_hcd will be set to NULL at USB3 hcd removal. Fix this by first checking if the PCI host is being removed, and also by using only xhci_to_hcd() as it will always return the primary hcd. CC: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-10-03usb: renesas_usbhs: fix clearing the {BRDY,BEMP}STS conditionYoshihiro Shimoda1-2/+9
[ Upstream commit 519d8bd4b5d3d82c413eac5bb42b106bb4b9ec15 ] The previous driver is possible to stop the transfer wrongly. For example: 1) An interrupt happens, but not BRDY interruption. 2) Read INTSTS0. And than state->intsts0 is not set to BRDY. 3) BRDY is set to 1 here. 4) Read BRDYSTS. 5) Clear the BRDYSTS. And then. the BRDY is cleared wrongly. Remarks: - The INTSTS0.BRDY is read only. - If any bits of BRDYSTS are set to 1, the BRDY is set to 1. - If BRDYSTS is 0, the BRDY is set to 0. So, this patch adds condition to avoid such situation. (And about NRDYSTS, this is not used for now. But, avoiding any side effects, this patch doesn't touch it.) Fixes: d5c6a1e024dd ("usb: renesas_usbhs: fixup interrupt status clear method") Cc: <stable@vger.kernel.org> # v3.8+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-12USB: serial: option: add WeTelecom 0x6802 and 0x6803 productsAleksandr Makarov1-0/+4
[ Upstream commit 40d9c32525cba79130612650b1abc47c0c0f19a8 ] These product IDs are listed in Windows driver. 0x6803 corresponds to WeTelecom WM-D300. 0x6802 name is unknown. Signed-off-by: Aleksandr Makarov <aleksandr.o.makarov@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-12USB: avoid left shift by -1Alan Stern1-5/+11
[ Upstream commit 53e5f36fbd2453ad69a3369a1db62dc06c30a4aa ] UBSAN complains about a left shift by -1 in proc_do_submiturb(). This can occur when an URB is submitted for a bulk or control endpoint on a high-speed device, since the code doesn't bother to check the endpoint type; normally only interrupt or isochronous endpoints have a nonzero bInterval value. Aside from the fact that the operation is illegal, it shouldn't matter because the result isn't used. Still, in theory it could cause a hardware exception or other problem, so we should work around it. This patch avoids doing the left shift unless the shift amount is >= 0. The same piece of code has another problem. When checking the device speed (the exponential encoding for interrupt endpoints is used only by high-speed or faster devices), we need to look for speed >= USB_SPEED_SUPER as well as speed == USB_SPEED HIGH. The patch adds this check. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Vittorio Zecca <zeccav@gmail.com> Tested-by: Vittorio Zecca <zeccav@gmail.com> Suggested-by: Bjørn Mork <bjorn@mork.no> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-12USB: serial: option: add WeTelecom WM-D200Aleksandr Makarov1-0/+5
[ Upstream commit 6695593e4a7659db49ac6eca98c164f7b5589f72 ] Add support for WeTelecom WM-D200. T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=22de ProdID=6801 Rev=00.00 S: Manufacturer=WeTelecom Incorporated S: Product=WeTelecom Mobile Products C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Signed-off-by: Aleksandr Makarov <aleksandr.o.makarov@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-12usb: chipidea: udc: don't touch DP when controller is in host modeLi Jun1-2/+5
[ Upstream commit c4e94174983a86c935be1537a73e496b778b0287 ] When the controller is configured to be dual role and it's in host mode, if bind udc and gadgt driver, those gadget operations will do gadget disconnect and finally pull down DP line, which will break host function. Cc: <stable@vger.kernel.org> # 4.1+ Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-12USB: serial: mos7840: fix non-atomic allocation in write pathAlexey Khoroshilov1-2/+2
[ Upstream commit 3b7c7e52efda0d4640060de747768360ba70a7c0 ] There is an allocation with GFP_KERNEL flag in mos7840_write(), while it may be called from interrupt context. Follow-up for commit 191252837626 ("USB: kobil_sct: fix non-atomic allocation in write path") Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-12USB: serial: mos7720: fix non-atomic allocation in write pathAlexey Khoroshilov1-1/+1
[ Upstream commit 5a5a1d614287a647b36dff3f40c2b0ceabbc83ec ] There is an allocation with GFP_KERNEL flag in mos7720_write(), while it may be called from interrupt context. Follow-up for commit 191252837626 ("USB: kobil_sct: fix non-atomic allocation in write path") Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: xhci: Fix panic if disconnectJim Lin1-0/+3
[ Upstream commit 88716a93766b8f095cdef37a8e8f2c93aa233b21 ] After a device is disconnected, xhci_stop_device() will be invoked in xhci_bus_suspend(). Also the "disconnect" IRQ will have ISR to invoke xhci_free_virt_device() in this sequence. xhci_irq -> xhci_handle_event -> handle_cmd_completion -> xhci_handle_cmd_disable_slot -> xhci_free_virt_device If xhci->devs[slot_id] has been assigned to NULL in xhci_free_virt_device(), then virt_dev->eps[i].ring in xhci_stop_device() may point to an invlid address to cause kernel panic. virt_dev = xhci->devs[slot_id]; : if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue) [] Unable to handle kernel paging request at virtual address 00001a68 [] pgd=ffffffc001430000 [] [00001a68] *pgd=000000013c807003, *pud=000000013c807003, *pmd=000000013c808003, *pte=0000000000000000 [] Internal error: Oops: 96000006 [#1] PREEMPT SMP [] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G U [] Workqueue: pm pm_runtime_work [] task: ffffffc0bc0e0bc0 ti: ffffffc0bc0ec000 task.ti: ffffffc0bc0ec000 [] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4 This issue is found when running with realtek ethernet device (0bda:8153). Signed-off-by: Jim Lin <jilin@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01xhci: always handle "Command Ring Stopped" eventsMathias Nyman1-6/+7
[ Upstream commit 33be126510974e2eb9679f1ca9bca4f67ee4c4c7 ] Fix "Command completion event does not match command" errors by always handling the command ring stopped events. The command ring stopped event is generated as a result of aborting or stopping the command ring with a register write. It is not caused by a command in the command queue, and thus won't have a matching command in the comman list. Solve it by handling the command ring stopped event before checking for a matching command. In most command time out cases we abort the command ring, and get a command ring stopped event. The events command pointer will point at the current command ring dequeue, which in most cases matches the timed out command in the command list, and no error messages are seen. If we instead get a command aborted event before the command ring stopped event, the abort event will increse the command ring dequeue pointer, and the following command ring stopped events command pointer will point at the next, not yet queued command. This case triggered the error message Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01cdc-acm: fix wrong pipe type on rx interrupt xfersGavin Li2-4/+2
[ Upstream commit add125054b8727103631dce116361668436ef6a7 ] This fixes the "BOGUS urb xfer" warning logged by usb_submit_urb(). Signed-off-by: Gavin Li <git@thegavinli.com> Acked-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: misc: usbtest: add fix for driver hangLu Baolu1-3/+4
[ Upstream commit 539587511835ea12d8daa444cbed766cf2bc3612 ] In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling into usb_sg_cancel(). usb_sg_cancel() will do nothing and return directly if req->status has been set to a non-zero value. This will cause driver hang whenever transfer time out is triggered. This patch fixes this issue. It could be backported to stable kernel with version later than v3.15. Cc: stable@vger.kernel.org # 3.15+ Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: renesas_usbhs: Use dmac only if the pipe type is bulkYoshihiro Shimoda1-2/+2
[ Upstream commit 700aa7ff8d2c2b9cc669c99375e2ccd06d3cd38d ] This patch fixes an issue that isochronous transfer's data is possible to be lost as a workaround. Since this driver uses a workqueue to start the dmac, the transfer is possible to be delayed when system load is high. Fixes: 6e4b74e4690d ("usb: renesas: fix scheduling in atomic context bug") Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: renesas_usbhs: clear the BRDYSTS in usbhsg_ep_enable()Yoshihiro Shimoda1-2/+5
[ Upstream commit 9ab967e6db7412b675ecbff80d5371d53c82cb2e ] This patch fixes an issue that unexpected BRDY interruption happens when the usb_ep_{enable,disable}() are called with different direction. In this case, the driver will cause the following message: renesas_usbhs e6590000.usb: irq_ready run_error 1 : -16 This issue causes the followings: 1) A pipe is enabled as transmission 2) The pipe sent a data 3) The pipe is disabled and re-enabled as reception. 4) The pipe got a queue Since the driver doesn't clear the BRDYSTS flags after 2) above, the issue happens. If we add such clearing the flags into the driver, the code will become complicate. So, this patch clears the BRDYSTS flag of reception in usbhsg_ep_enable() to avoid complicate. Cc: <stable@vger.kernel.org> # v4.1+ (usbhs_xxxsts_clear() is needed) Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: dwc3: pci: add Intel Kabylake PCI IDHeikki Krogerus1-0/+2
[ Upstream commit 4491ed5042f0419b22a4b08331adb54af31e2caa ] Intel Kabylake PCH has the same DWC3 than Intel Sunrisepoint. Add the new ID to the supported devices. Cc: <stable@vger.kernel.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: dwc3: pci: add support for Intel Broxton SOCHeikki Krogerus1-0/+4
[ Upstream commit b4c580a43d520b7812c0fd064fbab929ce2f1da0 ] PCI IDs for Broxton based platforms. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: dwc3: pci: trivial: FormattingJohn Youn1-8/+8
[ Upstream commit 9a5a0783e4910d9e2063e87184fbd9cac7161a16 ] Fix the alignment of the PCI device definitions. Also change the hex digit capitalization of one constant to make it consistent with the rest of the file and driver. Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: dwc3: gadget: always cleanup all TRBsFelipe Balbi1-1/+1
[ Upstream commit 7c705dfe2ebe731c8fd068623b6b4df2d3512c08 ] If we stop earlier due to short packet, we will not be able to giveback all TRBs. Cc: <stable@vger.kernel.org> Cc: Brian E Rogers <brian.e.rogers@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: dwc3: gadget: fix for short pkts during chained xfersFelipe Balbi1-3/+21
[ Upstream commit e5b36ae2f851024d43c76e51f395d32ce8d769ce ] DWC3 has one interesting peculiarity with chained transfers. If we setup N chained transfers and we get a short packet before processing all N TRBs, DWC3 will (conditionally) issue a XferComplete or XferInProgress event and retire all TRBs from the one which got a short packet to the last without clearing their HWO bits. This means SW must clear HWO bit manually, which this patch is doing. Cc: <stable@vger.kernel.org> Cc: Brian E Rogers <brian.e.rogers@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: dwc3: gadget: increment request->actual onceFelipe Balbi1-8/+11
[ Upstream commit c7de573471832dff7d31f0c13b0f143d6f017799 ] When using SG lists, we would end up setting request->actual to: num_mapped_sgs * (request->length - count) Let's fix that up by incrementing request->actual only once. Cc: <stable@vger.kernel.org> Reported-by: Brian E Rogers <brian.e.rogers@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-09-01usb: ehci: change order of register cleanup during shutdownMarc Ohlf1-2/+2
[ Upstream commit bc337b51508beb2d039aff5074a76cfe1c212030 ] In ehci_turn_off_all_ports() all EHCI port registers are cleared to zero. On some hardware, this can lead to an system hang, when ehci_port_power() accesses the already cleared registers. This patch changes the order of cleanup. First call ehci_port_power() which respects the current bits in port status registers and afterwards cleanup the hard way by setting everything to zero. Signed-off-by: Marc Ohlf <ohlf@mkt-sys.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-24usb: hub: Fix unbalanced reference count/memory leak/deadlocksViresh Kumar1-2/+0
[ Upstream commit 6bb47e8ab98accb1319bd43c64966340ba3bba9a ] Memory leak and unbalanced reference count: If the hub gets disconnected while the core is still activating it, this can result in leaking memory of few USB structures. This will happen if we have done a kref_get() from hub_activate() and scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect() gets called before the delayed work expires, then we will cancel the work from hub_quiesce(), but wouldn't do a kref_put(). And so the unbalance. kmemleak reports this as (with the commit e50293ef9775 backported to 3.10 kernel with other changes, though the same is true for mainline as well): unreferenced object 0xffffffc08af5b800 (size 1024): comm "khubd", pid 73, jiffies 4295051211 (age 6482.350s) hex dump (first 32 bytes): 30 68 f3 8c c0 ff ff ff 00 a0 b2 2e c0 ff ff ff 0h.............. 01 00 00 00 00 00 00 00 00 94 7d 40 c0 ff ff ff ..........}@.... backtrace: [<ffffffc0003079ec>] create_object+0x148/0x2a0 [<ffffffc000cc150c>] kmemleak_alloc+0x80/0xbc [<ffffffc000303a7c>] kmem_cache_alloc_trace+0x120/0x1ac [<ffffffc0006fa610>] hub_probe+0x120/0xb84 [<ffffffc000702b20>] usb_probe_interface+0x1ec/0x298 [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374 [<ffffffc0005d5308>] __device_attach+0x28/0x4c [<ffffffc0005d3164>] bus_for_each_drv+0x78/0xac [<ffffffc0005d4ee0>] device_attach+0x6c/0x9c [<ffffffc0005d42b8>] bus_probe_device+0x28/0xa0 [<ffffffc0005d23a4>] device_add+0x324/0x604 [<ffffffc000700fcc>] usb_set_configuration+0x660/0x6cc [<ffffffc00070a350>] generic_probe+0x44/0x84 [<ffffffc000702914>] usb_probe_device+0x54/0x74 [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374 [<ffffffc0005d5308>] __device_attach+0x28/0x4c Deadlocks: If the hub gets disconnected early enough (i.e. before INIT2/INIT3 are finished and the init_work is still queued), the core may call hub_quiesce() after acquiring interface device locks and it will wait for the work to be cancelled synchronously. But if the work handler is already running in parallel, it may try to acquire the same interface device lock and this may result in deadlock. Fix both the issues by removing the call to cancel_delayed_work_sync(). CC: <stable@vger.kernel.org> #4.4+ Fixes: e50293ef9775 ("USB: fix invalid memory access in hub_activate()") Reported-by: Manu Gautam <mgautam@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-24USB: serial: fix memleak in driver-registration error pathAlexey Klimov1-1/+3
[ Upstream commit 647024a7df36014bbc4479d92d88e6b77c0afcf6 ] udriver struct allocated by kzalloc() will not be freed if usb_register() and next calls fail. This patch fixes this by adding one more step with kfree(udriver) in error path. Signed-off-by: Alexey Klimov <klimov.linux@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-24USB: serial: option: add support for Telit LE920A4Daniele Palmas1-0/+21
[ Upstream commit 01d7956b58e644ea0d2e8d9340c5727a8fc39d70 ] This patch adds a set of compositions for Telit LE920A4. Compositions in short are: 0x1207: tty + tty 0x1208: tty + adb + tty + tty 0x1211: tty + adb + ecm 0x1212: tty + adb 0x1213: ecm + tty 0x1214: tty + adb + ecm + tty telit_le922_blacklist_usbcfg3 is reused for compositions 0x1211 and 0x1214 due to the same interfaces positions. Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-24USB: serial: ftdi_sio: add device ID for WICED USB UART dev boardSheng-Hui J. Chu2-0/+7
[ Upstream commit ae34d12cc1e212ffcd92e069030e54dae69c832f ] BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO IC. To support BCM920706V2_EVAL dev board for WICED development on Linux. Add the VID(0a5c) and PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board. Signed-off-by: Sheng-Hui J. Chu <s.jeffrey.chu@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-24USB: serial: ftdi_sio: add PIDs for Ivium Technologies devicesRobert Deliën2-0/+8
[ Upstream commit 6977495c06f7f47636a076ee5a0ca571279d9697 ] Ivium Technologies uses the FTDI VID with custom PIDs for their line of electrochemical interfaces and the PalmSens they developed for PalmSens BV. Signed-off-by: Robert Delien <robert@delien.nl> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-24USB: serial: option: add D-Link DWM-156/A3Lubomir Rintel1-0/+1
[ Upstream commit cf1b18030de29e4e5b0a57695ae5db4a89da0ff7 ] The device has four interfaces; the three serial ports ought to be handled by this driver: 00 Diagnostic interface serial port 01 NMEA device serial port 02 Mass storage (sd card) 03 Modem serial port The other product ids listed in the Windows driver are present already. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-20USB: OHCI: Don't mark EDs as ED_OPER if scheduling failsMichał Pecio1-1/+2
[ Upstream commit c66f59ee5050447b3da92d36f5385a847990a894 ] Since ed_schedule begins with marking the ED as "operational", the ED may be left in such state even if scheduling actually fails. This allows future submission attempts to smuggle this ED to the hardware behind the scheduler's back and without linking it to the ohci->eds_in_use list. The former causes bandwidth saturation and data loss on isoc endpoints, the latter crashes the kernel when attempt is made to unlink such ED from this list. Fix ed_schedule to update ED state only on successful return. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-20USB: serial: option: add support for Telit LE910 PID 0x1206Daniele Palmas1-0/+3
[ Upstream commit 3c0415fa08548e3bc63ef741762664497ab187ed ] This patch adds support for 0x1206 PID of Telit LE910. Since the interfaces positions are the same than the ones for 0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used. Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-20usb: quirks: Add no-lpm quirk for ElanJoseph Salisbury1-0/+3
[ Upstream commit 25b1f9acc452209ae0fcc8c1332be852b5c52f53 ] BugLink: http://bugs.launchpad.net/bugs/1498667 As reported in BugLink, this device has an issue with Linux Power Management so adding a quirk. This quirk was reccomended by Alan Stern: http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05590.html Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-20USB: quirks: Fix another ELAN touchscreenAdrien Vergé1-0/+3
[ Upstream commit df36c5bede207f734e4750beb2b14fb892050280 ] Like other buggy models that had their fixes [1], the touchscreen with id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier quirk. Otherwise, it fails to respond, blocks the boot for a random amount of time and pollutes dmesg with: [ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd [ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71 [ 2889.502005] usb 1-5: can't read configurations, error -71 [ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd [ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71 [ 2891.783443] usb 1-5: can't read configurations, error -71 [1]: See commits c68929f, 876af5d, d749947, a32c99e and dc703ec. Tested-by: Adrien Vergé <adrienverge@gmail.com> Signed-off-by: Adrien Vergé <adrienverge@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2016-08-16usb: renesas_usbhs: protect the CFIFOSEL setting in usbhsg_ep_enable()Yoshihiro Shimoda1-1/+8
[ Upstream commit 15e4292a2d21e9997fdb2b8c014cc461b3f268f0 ] This patch fixes an issue that the CFIFOSEL register value is possible to be changed by usbhsg_ep_enable() wrongly. And then, a data transfer using CFIFO may not work correctly. For example: # modprobe g_multi file=usb-storage.bin # ifconfig usb0 192.168.1.1 up (During the USB host is sending file to the mass storage) # ifconfig usb0 down In this case, since the u_ether.c may call usb_ep_enable() in eth_stop(), if the renesas_usbhs driver is also using CFIFO for mass storage, the mass storage may not work correctly. So, this patch adds usbhs_lock() and usbhs_unlock() calling in usbhsg_ep_enable() to protect CFIFOSEL register. This is because: - CFIFOSEL.CURPIPE = 0 is also needed for the pipe configuration - The CFIFOSEL (fifo->sel) is already protected by usbhs_lock() Fixes: 97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area") Cc: <stable@vger.kernel.org> # v3.1+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>