summaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2021-06-16usb: cdns3: Fix runtime PM imbalance on errorDinghao Liu1-1/+3
[ Upstream commit 07adc0225484fc199e3dc15ec889f75f498c4fca ] When cdns3_gadget_start() fails, a pairing PM usage counter decrement is needed to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Link: https://lore.kernel.org/r/20210412054908.7975-1-dinghao.liu@zju.edu.cn Signed-off-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-10usb: dwc2: Fix build in periphal-only modePhil Elwell1-0/+4
In branches to which 24d209dba5a3 ("usb: dwc2: Fix hibernation between host and device modes.") has been back-ported, the bus_suspended member of struct dwc2_hsotg is only present in builds that support host-mode. To avoid having to pull in several more non-Fix commits in order to get it to compile, wrap the usage of the member in a macro conditional. Fixes: 24d209dba5a3 ("usb: dwc2: Fix hibernation between host and device modes.") Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03usb: core: reduce power-on-good delay time of root hubChunfeng Yun1-2/+4
commit 90d28fb53d4a51299ff324dede015d5cb11b88a2 upstream. Return the exactly delay time given by root hub descriptor, this helps to reduce resume time etc. Due to the root hub descriptor is usually provided by the host controller driver, if there is compatibility for a root hub, we can fix it easily without affect other root hub Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1618017645-12259-1-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03usb: typec: mux: Fix matching with typec_altmode_descBjorn Andersson1-3/+4
commit acf5631c239dfc53489f739c4ad47f490c5181ff upstream. In typec_mux_match() "nval" is assigned the number of elements in the "svid" fwnode property, then the variable is used to store the success of the read and finally attempts to loop between 0 and "success" - i.e. not at all - and the code returns indicating that no match was found. Fix this by using a separate variable to track the success of the read, to allow the loop to get a change to find a match. Fixes: 96a6d031ca99 ("usb: typec: mux: Find the muxes by also matching against the device node") Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210516034730.621461-1-bjorn.andersson@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03usb: gadget: udc: renesas_usb3: Fix a race in usb3_start_pipen()Yoshihiro Shimoda1-2/+3
commit e752dbc59e1241b13b8c4f7b6eb582862e7668fe upstream. The usb3_start_pipen() is called by renesas_usb3_ep_queue() and usb3_request_done_pipen() so that usb3_start_pipen() is possible to cause a race when getting usb3_first_req like below: renesas_usb3_ep_queue() spin_lock_irqsave() list_add_tail() spin_unlock_irqrestore() usb3_start_pipen() usb3_first_req = usb3_get_request() --- [1] --- interrupt --- usb3_irq_dma_int() usb3_request_done_pipen() usb3_get_request() usb3_start_pipen() usb3_first_req = usb3_get_request() ... (the req is possible to be finished in the interrupt) The usb3_first_req [1] above may have been finished after the interrupt ended so that this driver caused to start a transfer wrongly. To fix this issue, getting/checking the usb3_first_req are under spin_lock_irqsave() in the same section. Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: stable <stable@vger.kernel.org> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20210524060155.1178724-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03usb: dwc3: gadget: Properly track pending and queued SGThinh Nguyen1-6/+7
commit 25dda9fc56bd90d45f9a4516bcfa5211e61b4290 upstream. The driver incorrectly uses req->num_pending_sgs to track both the number of pending and queued SG entries. It only prepares the next request if the previous is done, and it doesn't update num_pending_sgs until there is TRB completion interrupt. This may starve the controller of more TRBs until the num_pending_sgs is decremented. Fix this by decrementing the num_pending_sgs after they are queued and properly track both num_mapped_sgs and num_queued_sgs. Fixes: c96e6725db9d ("usb: dwc3: gadget: Correct the logic for queuing sgs") Cc: <stable@vger.kernel.org> Reported-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Tested-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/ba24591dbcaad8f244a3e88bd449bb7205a5aec3.1620874069.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03USB: serial: pl2303: add device id for ADLINK ND-6530 GCZolton Jheng2-0/+2
commit f8e8c1b2f782e7391e8a1c25648ce756e2a7d481 upstream. This adds the device id for the ADLINK ND-6530 which is a PL2303GC based device. Signed-off-by: Zolton Jheng <s6668c2t@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03USB: serial: ftdi_sio: add IDs for IDS GmbH ProductsDominik Andreas Schorpp2-0/+10
commit c5a80540e425a5f9a82b0f3163e3b6a4331f33bc upstream. Add the IDS GmbH Vendor ID and the Product IDs for SI31A (2xRS232) and CM31A (LoRaWAN Modem). Signed-off-by: Dominik Andreas Schorpp <dominik.a.schorpp@ids.de> Signed-off-by: Juergen Borleis <jbe@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03USB: serial: option: add Telit LE910-S1 compositions 0x7010, 0x7011Daniele Palmas1-0/+4
commit e467714f822b5d167a7fb03d34af91b5b6af1827 upstream. Add support for the following Telit LE910-S1 compositions: 0x7010: rndis, tty, tty, tty 0x7011: ecm, tty, tty, tty Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20210428072634.5091-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03USB: serial: ti_usb_3410_5052: add startech.com device idSean MacLennan1-0/+3
commit 89b1a3d811e6f8065d6ae8a25e7682329b4a31e2 upstream. This adds support for the Startech.com generic serial to USB converter. It seems to be a bone stock TI_3410. I have been using this patch for years. Signed-off-by: Sean MacLennan <seanm@seanm.ca> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03USB: usbfs: Don't WARN about excessively large memory allocationsAlan Stern1-3/+8
commit 4f2629ea67e7225c3fd292c7fe4f5b3c9d6392de upstream. Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers. CC: Andrew Morton <akpm@linux-foundation.org> CC: <stable@vger.kernel.org> Reported-and-tested-by: syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20210518201835.GA1140918@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03USB: trancevibrator: fix control-request directionJohan Hovold1-2/+2
commit 746e4acf87bcacf1406e05ef24a0b7139147c63e upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the set-speed request which erroneously used USB_DIR_IN and update the default timeout argument to match (same value). Fixes: 5638e4d92e77 ("USB: add PlayStation 2 Trance Vibrator driver") Cc: stable@vger.kernel.org # 2.6.19 Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210521133109.17396-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03misc/uss720: fix memory leak in uss720_probeDongliang Mu1-0/+1
commit dcb4b8ad6a448532d8b681b5d1a7036210b622de upstream. uss720_probe forgets to decrease the refcount of usbdev in uss720_probe. Fix this by decreasing the refcount of usbdev by usb_put_dev. BUG: memory leak unreferenced object 0xffff888101113800 (size 2048): comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s) hex dump (first 32 bytes): ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1........... 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................ backtrace: [<ffffffff82b8e822>] kmalloc include/linux/slab.h:554 [inline] [<ffffffff82b8e822>] kzalloc include/linux/slab.h:684 [inline] [<ffffffff82b8e822>] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582 [<ffffffff82b98441>] hub_port_connect drivers/usb/core/hub.c:5129 [inline] [<ffffffff82b98441>] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline] [<ffffffff82b98441>] port_event drivers/usb/core/hub.c:5509 [inline] [<ffffffff82b98441>] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591 [<ffffffff81259229>] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275 [<ffffffff81259b19>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421 [<ffffffff81261228>] kthread+0x178/0x1b0 kernel/kthread.c:292 [<ffffffff8100227f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Fixes: 0f36163d3abe ("[PATCH] usb: fix uss720 schedule with interrupts off") Cc: stable <stable@vger.kernel.org> Reported-by: syzbot+636c58f40a86b4a879e7@syzkaller.appspotmail.com Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com> Link: https://lore.kernel.org/r/20210514124348.6587-1-mudongliangabcd@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22usb: sl811-hcd: improve misleading indentationArnd Bergmann1-5/+4
commit 8460f6003a1d2633737b89c4f69d6f4c0c7c65a3 upstream. gcc-11 now warns about a confusingly indented code block: drivers/usb/host/sl811-hcd.c: In function ‘sl811h_hub_control’: drivers/usb/host/sl811-hcd.c:1291:9: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation] 1291 | if (*(u16*)(buf+2)) /* only if wPortChange is interesting */ | ^~ drivers/usb/host/sl811-hcd.c:1295:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 1295 | break; Rewrite this to use a single if() block with the __is_defined() macro. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210322164244.827589-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: typec: tcpm: Fix error while calculating PPS out valuesBadhri Jagan Sridharan1-3/+3
commit 374157ff88ae1a7f7927331cbc72c1ec11994e8a upstream. "usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply" introduced a regression for req_out_volt and req_op_curr calculation. req_out_volt should consider the newly calculated max voltage instead of previously accepted max voltage by the port partner. Likewise, req_op_curr should consider the newly calculated max current instead of previously accepted max current by the port partner. Fixes: e3a072022487 ("usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply") Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20210415050121.1928298-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19cdc-wdm: untangle a circular dependency between callback and softintOliver Neukum1-8/+22
commit 18abf874367456540846319574864e6ff32752e2 upstream. We have a cycle of callbacks scheduling works which submit URBs with those callbacks. This needs to be blocked, stopped and unblocked to untangle the circle. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20210426092622.20433-1-oneukum@suse.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19xhci: Add reset resume quirk for AMD xhci controller.Sandeep Singh1-1/+3
commit 3c128781d8da463761495aaf8898c9ecb4e71528 upstream. One of AMD xhci controller require reset on resume. Occasionally AMD xhci controller does not respond to Stop endpoint command. Once the issue happens controller goes into bad state and in that case controller needs to be reset. Cc: <stable@vger.kernel.org> Signed-off-by: Sandeep Singh <sandeep.singh@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210512080816.866037-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19xhci: Do not use GFP_KERNEL in (potentially) atomic contextChristophe JAILLET1-3/+3
commit dda32c00c9a0fa103b5d54ef72c477b7aa993679 upstream. 'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be submitted in interrupt context" (see comment related to 'usb_submit_urb()' in 'drivers/usb/core/urb.c') So this flag should be used in all the calling chain. Up to now, 'xhci_check_maxpacket()' which is only called from 'xhci_urb_enqueue()', uses GFP_KERNEL. Be safe and pass the mem_flags to this function as well. Fixes: ddba5cd0aeff ("xhci: Use command structures when queuing commands on the command ring") Cc: <stable@vger.kernel.org> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210512080816.866037-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19xhci-pci: Allow host runtime PM as default for Intel Alder Lake xHCIAbhijeet Rao1-1/+3
commit b813511135e8b84fa741afdfbab4937919100bef upstream. In the same way as Intel Tiger Lake TCSS (Type-C Subsystem) the Alder Lake TCSS xHCI needs to be runtime suspended whenever possible to allow the TCSS hardware block to enter D3cold and thus save energy. Cc: stable@vger.kernel.org Signed-off-by: Abhijeet Rao <abhijeet.rao@intel.com> Signed-off-by: Nikunj A. Dadhania <nikunj.dadhania@intel.com> Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210512080816.866037-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: typec: ucsi: Put fwnode in any case during ->probe()Andy Shevchenko1-1/+4
commit b9a0866a5bdf6a4643a52872ada6be6184c6f4f2 upstream. device_for_each_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210504222337.3151726-1-andy.shevchenko@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4Jack Pham2-11/+36
commit 1f4642b72be79757f050924a9b9673b6a02034bc upstream. commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs. If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now(). With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one. [ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64 We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command. Fixes: 992a60ed0d5e ("usb: typec: ucsi: register with power_supply class") Fixes: 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") Cc: stable@vger.kernel.org Reported-and-tested-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210503074611.30973-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: dwc3: gadget: Return success always for kick transfer in ep queueWesley Cheng1-1/+3
commit 18ffa988dbae69cc6e9949cddd9606f6fe533894 upstream. If an error is received when issuing a start or update transfer command, the error handler will stop all active requests (including the current USB request), and call dwc3_gadget_giveback() to notify function drivers of the requests which have been stopped. Avoid returning an error for kick transfer during EP queue, to remove duplicate cleanup operations on the request being queued. Fixes: 8d99087c2db8 ("usb: dwc3: gadget: Properly handle failed kick_transfer") cc: stable@vger.kernel.org Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1620410119-24971-1-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: dwc3: gadget: Enable suspend eventsJack Pham1-0/+4
commit d1d90dd27254c44d087ad3f8b5b3e4fff0571f45 upstream. commit 72704f876f50 ("dwc3: gadget: Implement the suspend entry event handler") introduced (nearly 5 years ago!) an interrupt handler for U3/L1-L2 suspend events. The problem is that these events aren't currently enabled in the DEVTEN register so the handler is never even invoked. Fix this simply by enabling the corresponding bit in dwc3_gadget_enable_irq() using the same revision check as found in the handler. Fixes: 72704f876f50 ("dwc3: gadget: Implement the suspend entry event handler") Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210428090111.3370-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: core: hub: fix race condition about TRSMRCY of resumeChunfeng Yun1-3/+3
commit 975f94c7d6c306b833628baa9aec3f79db1eb3a1 upstream. This may happen if the port becomes resume status exactly when usb_port_resume() gets port status, it still need provide a TRSMCRY time before access the device. CC: <stable@vger.kernel.org> Reported-by: Tianping Fang <tianping.fang@mediatek.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210512020738.52961-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: dwc2: Fix gadget DMA unmap directionPhil Elwell2-1/+4
commit 75a41ce46bae6cbe7d3bb2584eb844291d642874 upstream. The dwc2 gadget support maps and unmaps DMA buffers as necessary. When mapping and unmapping it uses the direction of the endpoint to select the direction of the DMA transfer, but this fails for Control OUT transfers because the unmap occurs after the endpoint direction has been reversed for the status phase. A possible solution would be to unmap the buffer before the direction is changed, but a safer, less invasive fix is to remember the buffer direction independently of the endpoint direction. Fixes: fe0b94abcdf6 ("usb: dwc2: gadget: manage ep0 state in software") Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Phil Elwell <phil@raspberrypi.com> Link: https://lore.kernel.org/r/20210506112200.2893922-1-phil@raspberrypi.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: xhci: Increase timeout for HC haltMaximilian Luz1-2/+3
commit ca09b1bea63ab83f4cca3a2ae8bc4f597ec28851 upstream. On some devices (specifically the SC8180x based Surface Pro X with QCOM04A6) HC halt / xhci_halt() times out during boot. Manually binding the xhci-hcd driver at some point later does not exhibit this behavior. To work around this, double XHCI_MAX_HALT_USEC, which also resolves this issue. Cc: <stable@vger.kernel.org> Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210512080816.866037-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: dwc3: pci: Enable usb2-gadget-lpm-disable for Intel MerrifieldFerry Toth1-0/+1
commit 04357fafea9c7ed34525eb9680c760245c3bb958 upstream. On Intel Merrifield LPM is causing host to reset port after a timeout. By disabling LPM entirely this is prevented. Fixes: 066c09593454 ("usb: dwc3: pci: Enable extcon driver for Intel Merrifield") Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Ferry Toth <ftoth@exalondelft.nl> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210425150947.5862-1-ftoth@exalondelft.nl Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: dwc3: omap: improve extcon initializationMarcel Hamer1-0/+5
commit e17b02d4970913233d543c79c9c66e72cac05bdd upstream. When extcon is used in combination with dwc3, it is assumed that the dwc3 registers are untouched and as such are only configured if VBUS is valid or ID is tied to ground. In case VBUS is not valid or ID is floating, the registers are not configured as such during driver initialization, causing a wrong default state during boot. If the registers are not in a default state, because they are for instance touched by a boot loader, this can cause for a kernel error. Signed-off-by: Marcel Hamer <marcel@solidxs.se> Link: https://lore.kernel.org/r/20210427122118.1948340-1-marcel@solidxs.se Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19usb: musb: Fix an error messageChristophe JAILLET1-1/+1
[ Upstream commit d9ff1096a840dddea3d5cfa2149ff7da9f499fb2 ] 'ret' is known to be 0 here. Initialize 'ret' with the expected error code before using it. Fixes: 0990366bab3c ("usb: musb: Add support for MediaTek musb controller") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/69f514dc7134e3c917cad208e73cc650cb9e2bd6.1620159879.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-19usb: fotg210-hcd: Fix an error messageChristophe JAILLET1-2/+2
[ Upstream commit a60a34366e0d09ca002c966dd7c43a68c28b1f82 ] 'retval' is known to be -ENODEV here. This is a hard-coded default error code which is not useful in the error message. Moreover, another error message is printed at the end of the error handling path. The corresponding error code (-ENOMEM) is more informative. So remove simplify the first error message. While at it, also remove the useless initialization of 'retval'. Fixes: 7d50195f6c50 ("usb: host: Faraday fotg210-hcd driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/94531bcff98e46d4f9c20183a90b7f47f699126c.1620333419.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-19usb: dwc3: gadget: Free gadget structure only after freeing endpointsJack Pham1-1/+2
[ Upstream commit bb9c74a5bd1462499fe5ccb1e3c5ac40dcfa9139 ] As part of commit e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") the dwc3_gadget_release() was added which will free the dwc->gadget structure upon the device's removal when usb_del_gadget_udc() is called in dwc3_gadget_exit(). However, simply freeing the gadget results a dangling pointer situation: the endpoints created in dwc3_gadget_init_endpoints() have their dep->endpoint.ep_list members chained off the list_head anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed, the first dwc3_ep in the list now has a dangling prev pointer and likewise for the next pointer of the dwc3_ep at the tail of the list. The dwc3_gadget_free_endpoints() that follows will result in a use-after-free when it calls list_del(). This was caught by enabling KASAN and performing a driver unbind. The recent commit 568262bf5492 ("usb: dwc3: core: Add shutdown callback for dwc3") also exposes this as a panic during shutdown. There are a few possibilities to fix this. One could be to perform a list_del() of the gadget->ep_list itself which removes it from the rest of the dwc3_ep chain. Another approach is what this patch does, by splitting up the usb_del_gadget_udc() call into its separate "del" and "put" components. This allows dwc3_gadget_free_endpoints() to be called before the gadget is finally freed with usb_put_gadget(). Fixes: e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") Reviewed-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210501093558.7375-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14usb: dwc2: Fix hibernation between host and device modes.Artur Petrosyan1-71/+83
[ Upstream commit 24d209dba5a3959b2ebde7cf3ad40c8015e814cf ] When core is in hibernation in host mode and a device cable was connected then driver exited from device hibernation. However, registers saved for host mode and when exited from device hibernation register restore would be done for device register which was wrong because there was no device registers stored to restore. - Added dwc_handle_gpwrdn_disc_det() function which handles gpwrdn disconnect detect flow and exits hibernation without restoring the registers. - Updated exiting from hibernation in GPWRDN_STS_CHGINT with calling dwc_handle_gpwrdn_disc_det() function. Here no register is restored which is the solution described above. Fixes: 65c9c4c6b01f ("usb: dwc2: Add dwc2_handle_gpwrdn_intr() handler") Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Signed-off-by: Artur Petrosyan <Arthur.Petrosyan@synopsys.com> Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Link: https://lore.kernel.org/r/20210416124715.75355A005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14usb: dwc2: Fix host mode hibernation exit with remote wakeup flow.Artur Petrosyan1-1/+9
[ Upstream commit c2db8d7b9568b10e014af83b3c15e39929e3579e ] Added setting "port_connect_status_change" flag to "1" in order to re-enumerate, because after exit from hibernation port connection status is not detected. Fixes: c5c403dc4336 ("usb: dwc2: Add host/device hibernation functions") Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Signed-off-by: Artur Petrosyan <Arthur.Petrosyan@synopsys.com> Link: https://lore.kernel.org/r/20210416124707.5EEC2A005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14usbip: vudc: fix missing unlock on error in usbip_sockfd_store()Ye Bin1-0/+2
[ Upstream commit 1d08ed588c6a85a35a24c82eb4cf0807ec2b366a ] Add the missing unlock before return from function usbip_sockfd_store() in the error handling case. Fixes: bd8b82042269 ("usbip: vudc synchronize sysfs code paths") Reported-by: Hulk Robot <hulkci@huawei.com> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Ye Bin <yebin10@huawei.com> Link: https://lore.kernel.org/r/20210408112305.1022247-1-yebin10@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14USB: cdc-acm: fix TIOCGSERIAL implementationJohan Hovold1-2/+1
[ Upstream commit 496960274153bdeb9d1f904ff1ea875cef8232c1 ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. The xmit_fifo_size parameter could be used to set the hardware transmit fifo size of a legacy UART when it could not be detected, but the interface is limited to eight bits and should be left unset when it is not used. Similarly, baud_base could be used to set the UART base clock when it could not be detected, but might as well be left unset when it is not known (which is the case for CDC). Fix the cdc-acm TIOCGSERIAL implementation by dropping its custom interpretation of the unused xmit_fifo_size and baud_base fields, which overflowed the former with the URB buffer size and set the latter to the current line speed. Also return the port line number, which is the only other value used besides the close parameters. Note that the current line speed can still be retrieved through the standard termios interfaces. Fixes: 18c75720e667 ("USB: allow users to run setserial with cdc-acm") Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210408131602.27956-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14USB: cdc-acm: fix unprivileged TIOCCSERIALJohan Hovold1-2/+0
[ Upstream commit dd5619582d60007139f0447382d2839f4f9e339b ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. A non-privileged user has only ever been able to set the since long deprecated ASYNC_SPD flags and trying to change any other *supported* feature should result in -EPERM being returned. Setting the current values for any supported features should return success. Fix the cdc-acm implementation which instead indicated that the TIOCSSERIAL ioctl was not even implemented when a non-privileged user set the current values. Fixes: ba2d8ce9db0a ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)") Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210408131602.27956-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14usb: gadget: r8a66597: Add missing null check on return from ↵Colin Ian King1-0/+2
platform_get_resource [ Upstream commit 9c2076090c2815fe7c49676df68dde7e60a9b9fc ] The call to platform_get_resource can potentially return a NULL pointer on failure, so add this check and return -EINVAL if it fails. Fixes: c41442474a26 ("usb: gadget: R8A66597 peripheral controller support.") Signed-off-by: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Dereference null return") Link: https://lore.kernel.org/r/20210406184510.433497-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14USB: gadget: udc: fix wrong pointer passed to IS_ERR() and PTR_ERR()Yang Yingliang1-2/+2
[ Upstream commit 2e3d055bf27d70204cae349335a62a4f9b7c165a ] IS_ERR() and PTR_ERR() use wrong pointer, it should be udc->virt_addr, fix it. Fixes: 1b9f35adb0ff ("usb: gadget: udc: Add Synopsys UDC Platform driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210330130159.1051979-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14usb: gadget: aspeed: fix dma map failureTao Ren2-2/+3
[ Upstream commit bd4d607044b961cecbf8c4c2f3bb5da4fb156993 ] Currently the virtual port_dev device is passed to DMA API, and this is wrong because the device passed to DMA API calls must be the actual hardware device performing the DMA. The patch replaces usb_gadget_map_request/usb_gadget_unmap_request APIs with usb_gadget_map_request_by_dev/usb_gadget_unmap_request_by_dev APIs so the DMA capable platform device can be passed to the DMA APIs. The patch fixes below backtrace detected on Facebook AST2500 OpenBMC platforms: [<80106550>] show_stack+0x20/0x24 [<80106868>] dump_stack+0x28/0x30 [<80823540>] __warn+0xfc/0x110 [<8011ac30>] warn_slowpath_fmt+0xb0/0xc0 [<8011ad44>] dma_map_page_attrs+0x24c/0x314 [<8016a27c>] usb_gadget_map_request_by_dev+0x100/0x1e4 [<805cedd8>] usb_gadget_map_request+0x1c/0x20 [<805cefbc>] ast_vhub_epn_queue+0xa0/0x1d8 [<7f02f710>] usb_ep_queue+0x48/0xc4 [<805cd3e8>] ecm_do_notify+0xf8/0x248 [<7f145920>] ecm_set_alt+0xc8/0x1d0 [<7f145c34>] composite_setup+0x680/0x1d30 [<7f00deb8>] ast_vhub_ep0_handle_setup+0xa4/0x1bc [<7f02ee94>] ast_vhub_dev_irq+0x58/0x84 [<7f0309e0>] ast_vhub_irq+0xb0/0x1c8 [<7f02e118>] __handle_irq_event_percpu+0x50/0x19c [<8015e5bc>] handle_irq_event_percpu+0x38/0x8c [<8015e758>] handle_irq_event+0x38/0x4c Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Tao Ren <rentao.bupt@gmail.com> Link: https://lore.kernel.org/r/20210331045831.28700-1-rentao.bupt@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14usb: gadget: s3c: Fix the error handling path in 's3c2410_udc_probe()'Christophe JAILLET1-4/+12
[ Upstream commit e5242861ec6a0bce25b4cd10af0fc8a508fd067d ] Some 'clk_prepare_enable()' and 'clk_get()' must be undone in the error handling path of the probe function, as already done in the remove function. Fixes: 3fc154b6b813 ("USB Gadget driver for Samsung s3c2410 ARM SoC") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/2bee52e4ce968f48b4c32545cf8f3b2ab825ba82.1616830026.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14usb: gadget: s3c: Fix incorrect resources releasingChristophe JAILLET1-11/+3
[ Upstream commit 42067ccd9eb2077979ac3ce8b7b95c694bd09e14 ] Since commit 188db4435ac6 ("usb: gadget: s3c: use platform resources"), 'request_mem_region()' and 'ioremap()' are no more used, so they don't need to be undone in the error handling path of the probe and in the remove function. Remove these calls and the unneeded 'rsrc_start' and 'rsrc_len' global variables. Fixes: 188db4435ac6 ("usb: gadget: s3c: use platform resources") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/b317638464f188159bd8eea44427dd359e480625.1616830026.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14fotg210-udc: Complete OUT requests on short packetsFabian Vogt1-2/+6
[ Upstream commit 75bb93be0027123b5db6cbcce89eb62f0f6b3c5b ] A short packet indicates the end of a transfer and marks the request as complete. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de> Link: https://lore.kernel.org/r/20210324141115.9384-8-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14fotg210-udc: Don't DMA more than the buffer can takeFabian Vogt1-2/+3
[ Upstream commit 3e7c2510bdfe89a9ec223dd7acd6bfc8bb1cbeb6 ] Before this, it wrote as much as available into the buffer, even if it didn't fit. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de> Link: https://lore.kernel.org/r/20210324141115.9384-7-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14fotg210-udc: Mask GRP2 interrupts we don't handleFabian Vogt1-0/+6
[ Upstream commit 9aee3a23d6455200702f3a57e731fa11e8408667 ] Currently it leaves unhandled interrupts unmasked, but those are never acked. In the case of a "device idle" interrupt, this leads to an effectively frozen system until plugging it in. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de> Link: https://lore.kernel.org/r/20210324141115.9384-5-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14fotg210-udc: Remove a dubious condition leading to fotg210_doneFabian Vogt1-2/+1
[ Upstream commit c7f755b243494d6043aadcd9a2989cb157958b95 ] When the EP0 IN request was not completed but less than a packet sent, it would complete the request successfully. That doesn't make sense and can't really happen as fotg210_start_dma always sends min(length, maxpkt) bytes. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de> Link: https://lore.kernel.org/r/20210324141115.9384-4-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14fotg210-udc: Fix EP0 IN requests bigger than two packetsFabian Vogt1-1/+1
[ Upstream commit 078ba935651e149c92c41161e0322e3372cc2705 ] For a 134 Byte packet, it sends the first two 64 Byte packets just fine, but then notice that less than a packet is remaining and call fotg210_done without actually sending the rest. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de> Link: https://lore.kernel.org/r/20210324141115.9384-3-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14fotg210-udc: Fix DMA on EP0 for length > max packet sizeFabian Vogt1-1/+1
[ Upstream commit 755915fc28edfc608fa89a163014acb2f31c1e19 ] For a 75 Byte request, it would send the first 64 separately, then detect that the remaining 11 Byte fit into a single DMA, but due to this bug set the length to the original 75 Bytes. This leads to a DMA failure (which is ignored...) and the request completes without the remaining bytes having been sent. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de> Link: https://lore.kernel.org/r/20210324141115.9384-2-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14usb: gadget: pch_udc: Provide a GPIO line used on Intel Minnowboard (v1)Andy Shevchenko1-14/+57
[ Upstream commit 049d3db625a652e23488db88b6104de4d5b62f16 ] Intel Minnowboard (v1) uses SCH GPIO line SUS7 (i.e. 12) for VBUS sense. Provide a DMI based quirk to have it's being used. Fixes: e20849a8c883 ("usb: gadget: pch_udc: Convert to use GPIO descriptors") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210323153626.54908-7-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14