aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2022-03-18media: Kconfig: cleanup VIDEO_DEV dependenciesMauro Carvalho Chehab2-2/+2
media Kconfig has two entries associated to V4L API: VIDEO_DEV and VIDEO_V4L2. On Kernel 2.6.x, there were two V4L APIs, each one with its own flag. VIDEO_DEV were meant to: 1) enable Video4Linux and make its Kconfig options to appear; 2) it makes the Kernel build the V4L core. while VIDEO_V4L2 where used to distinguish between drivers that implement the newer API and drivers that implemented the former one. With time, such meaning changed, specially after the removal of all V4L version 1 drivers. At the current implementation, VIDEO_DEV only does (1): it enables the media options related to V4L, that now has: menu "Video4Linux options" visible if VIDEO_DEV source "drivers/media/v4l2-core/Kconfig" endmenu but it doesn't affect anymore the V4L core drivers. The rationale is that the V4L2 core has a "soft" dependency at the I2C bus, and now requires to select a number of other Kconfig options: config VIDEO_V4L2 tristate depends on (I2C || I2C=n) && VIDEO_DEV select RATIONAL select VIDEOBUF2_V4L2 if VIDEOBUF2_CORE default (I2C || I2C=n) && VIDEO_DEV In the past, merging them would be tricky, but it seems that it is now possible to merge those symbols, in order to simplify V4L dependencies. Let's keep VIDEO_DEV, as this one is used on some make *defconfig configurations. Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> # for meson-vdec & meson-ge2d Acked-by: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com> Acked-by: Łukasz Stelmach <l.stelmach@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-03-16xen/usb: harden xen_hcd against malicious backendsJuergen Gross1-14/+43
Make sure a malicious backend can't cause any harm other than wrong I/O data. Missing are verification of the request id in a response, sanitizing the reported actual I/O length, and protection against interrupt storms from the backend. Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220311103509.12908-1-jgross@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-16Merge tag 'v5.17-rc8' into usb-nextGreg Kroah-Hartman1-8/+18
We need the Xen USB fixes as other patches depend on those changes. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15xen/grant-table: remove readonly parameter from functionsJuergen Gross1-2/+2
The gnttab_end_foreign_access() family of functions is taking a "readonly" parameter, which isn't used. Remove it from the function parameters. Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220311103429.12845-3-jgross@suse.com Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2022-03-15usb: gadget: Fix use-after-free bug by not setting udc->dev.driverAlan Stern1-3/+0
The syzbot fuzzer found a use-after-free bug: BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320 Read of size 8 at addr ffff88802b934098 by task udevd/3689 CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 dev_uevent+0x712/0x780 drivers/base/core.c:2320 uevent_show+0x1b8/0x380 drivers/base/core.c:2391 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094 Although the bug manifested in the driver core, the real cause was a race with the gadget core. dev_uevent() does: if (dev->driver) add_uevent_var(env, "DRIVER=%s", dev->driver->name); and between the test and the dereference of dev->driver, the gadget core sets dev->driver to NULL. The race wouldn't occur if the gadget core registered its devices on a real bus, using the standard synchronization techniques of the driver core. However, it's not necessary to make such a large change in order to fix this bug; all we need to do is make sure that udc->dev.driver is always NULL. In fact, there is no reason for udc->dev.driver ever to be set to anything, let alone to the value it currently gets: the address of the gadget's driver. After all, a gadget driver only knows how to manage a gadget, not how to manage a UDC. This patch simply removes the statements in the gadget core that touch udc->dev.driver. Fixes: 2ccea03a8f7e ("usb: gadget: introduce UDC Class") CC: <stable@vger.kernel.org> Reported-and-tested-by: syzbot+348b571beb5eeb70a582@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/YiQgukfFFbBnwJ/9@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: usbtmc: Fix bug in pipe direction for control transfersAlan Stern1-3/+10
The syzbot fuzzer reported a minor bug in the usbtmc driver: usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0 WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Modules linked in: CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline] The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for all of its transfers, whether they are in or out. It's easy to fix. CC: <stable@vger.kernel.org> Reported-and-tested-by: syzbot+a48e3d1a875240cab5de@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/YiEsYTPEE6lOCOA5@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: gadget: Wait for ep0 xfers to complete during dequeueThinh Nguyen4-5/+31
If a Setup packet is received but yet to DMA out, the controller will not process the End Transfer command of any endpoint. Polling of its DEPCMD.CmdAct may block setting up TRB for Setup packet, causing a command timeout. This may occur if the driver doesn’t service the completion interrupt of the control status stage yet due to system latency, then it won’t prepare TRB and start the transfer for the next Setup Stage. To the host side, the control transfer had completed, and the host can send a new Setup packet at this point. In the meanwhile, if the driver receives an async call to dequeue a request (triggering End Transfer) to any endpoint, then the driver will service that End transfer first, blocking the control status stage completion handler. Since no TRB is available for the Setup stage, the Setup packet can’t be DMA’ed out and the End Transfer gets hung. The driver must not block setting up of the Setup stage. So track and only issue the End Transfer command only when there’s Setup TRB prepared so that the controller can DMA out the Setup packet. Delay the End transfer command if there's no Setup TRB available. This is applicable to all DWC_usb3x IPs. Co-developed-by: Wesley Cheng <quic_wcheng@quicinc.com> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20220309205402.4467-1-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: gadget: move cmd_endtransfer to extra functionMichael Grzeschik1-32/+37
This patch adds the extra function __dwc3_stop_active_transfer to consolidate the same codepath. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220306211251.2281335-3-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: gadget: ep_queue simplify isoc start conditionMichael Grzeschik1-6/+4
To improve reading the code this patch moves the cases to start_isoc or return the function under one common condition check. Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220306211251.2281335-2-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15xen/usb: don't use arbitrary_virt_to_machine()Juergen Gross1-3/+1
arbitrary_virt_to_machine() is meant to be used in PV guests only. Replace its usage with virt_to_gfn(). Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220311103500.12885-1-jgross@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: isp1760: remove redundant max_packet() macroVincent Mailhol1-3/+2
The function usb_endpoint_maxp() (called by usb_maxpacket()) already does the sanitazation of the USB endpoint max packet size. The call to max_packet() does the same thing and is thus removed. The macro max_packet() not being used anymore also gets removed. Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220306075524.706660-3-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: oxu210hp-hcd: remove redundant call to max_packet() macroVincent Mailhol1-1/+1
The function usb_endpoint_maxp() (called by usb_maxpacket()) already does the sanitazation of the USB endpoint max packet size. The call to max_packet() does the same thing and is thus removed. However, the macro max_packet() is kept because it is used elsewhere in the file. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220306075524.706660-2-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: common: usb-conn-gpio: Make VBUS supply completely optionalAlexander Stein1-17/+3
It makes sense that if the USB connector is a child of an USB port providing VBUS supply, there is no need to do it again. But this does not handle the case where VBUS is controlled by PWR from USB host controller, without any regulator at all. Support this by making VBUS pure optional. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20220309093842.113260-1-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15USB: storage: ums-realtek: fix error code in rts51x_read_mem()Dan Carpenter1-1/+1
The rts51x_read_mem() function should return negative error codes. Currently if the kmalloc() fails it returns USB_STOR_TRANSPORT_ERROR (3) which is treated as success by the callers. Fixes: 065e60964e29 ("ums_realtek: do not use stack memory for DMA") Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220304073504.GA26464@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: early: xhci-dbc: Fix xdbc number parsingPeter Zijlstra1-2/+6
kstrtoul() assumes the string contains the number only and is \0 terminated, this is not the case, as such things like: earlyprintk=xdbc1,keep go completely sideways. Use simple_strtoul() instead. Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20220304152136.035911620@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: early: xhci-dbc: Remove duplicate keep parsingPeter Zijlstra1-3/+2
The generic earlyprintk= parsing already parses the optional ",keep", no need to duplicate that in the xdbc driver. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20220304152135.975568860@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: s3c2410: remove usage of list iterator past the loop bodyJakob Koschel1-8/+9
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-27-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: dummy_hcd: remove usage of list iterator past the loop bodyJakob Koschel1-8/+9
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-26-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: core: remove usage of list iterator past the loop bodyJakob Koschel1-8/+12
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-25-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: composite: remove usage of list iterator past the loop bodyJakob Koschel1-13/+14
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-24-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: pxa27x_udc: replace usage of rc to check if a list element was ↵Jakob Koschel1-6/+7
found To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-23-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: composite: remove check of list iterator against head past the ↵Jakob Koschel1-4/+5
loop body When list_for_each_entry() completes the iteration over the whole list without breaking the loop, the iterator value will be a bogus pointer computed based on the head element. While it is safe to use the pointer to determine if it was computed based on the head element, either with list_entry_is_head() or &pos->member == head, using the iterator variable after the loop should be avoided. In preparation to limiting the scope of a list iterator to the list traversal loop, use a dedicated pointer to point to the found element [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-22-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: tegra-xudc: remove using list iterator after loop body as a ptrJakob Koschel1-5/+7
If the list does not contain the expected element, the value of list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to list_for_each_entry() loop. In preparation to limiting scope of a list iterator to the list traversal loop, use a dedicated pointer to point to the found element [1]. Determining if an element was found is then simply checking if the pointer is != NULL instead of using the potentially bogus pointer. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-21-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: max3420_udc: remove using list iterator after loop body as ↵Jakob Koschel1-7/+11
a ptr If the list does not contain the expected element, the value of list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to list_for_each_entry() loop. In preparation to limiting scope of a list iterator to the list traversal loop, use a dedicated pointer to point to the found element [1]. Determining if an element was found is then simply checking if the pointer is != NULL instead of using the potentially bogus pointer. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-20-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: legacy: remove using list iterator after loop body as a ptrJakob Koschel1-11/+12
If the list does not contain the expected element, the value of list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to list_for_each_entry() loop. In preparation to limiting scope of a list iterator to the list traversal loop, use a dedicated pointer to point to the found element [1]. Determining if an element was found is then simply checking if the pointer is != NULL instead of using the potentially bogus pointer. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-19-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: configfs: remove using list iterator after loop body as a ptrJakob Koschel1-10/+14
If the list does not contain the expected element, the value of list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to list_for_each_entry() loop. In preparation to limiting scope of a list iterator to the list traversal loop, use a dedicated pointer to point to the found element [1]. Determining if an element was found is then simply checking if the pointer is != NULL instead of using the potentially bogus pointer. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-18-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: aspeed: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-17-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc-xilinx: remove usage of list iterator past the loop bodyJakob Koschel1-5/+8
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-16-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: s3c-hsudc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-15-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: omap_udc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-14-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: net2280: remove usage of list iterator past the loop bodyJakob Koschel1-5/+8
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-13-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: net2272: remove usage of list iterator past the loop bodyJakob Koschel1-6/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-12-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: mv_udc_core: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-11-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: mv_u3d: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-10-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: lpc32xx_udc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-9-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: gr_udc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-8-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: goku_udc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-7-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: at91: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-6-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: pxa25x: remove usage of list iterator past the loop bodyJakob Koschel1-5/+8
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-5-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: atmel: remove usage of list iterator past the loop bodyJakob Koschel1-5/+8
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-4-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: bdc: remove usage of list iterator past the loop bodyJakob Koschel1-4/+9
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-3-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: fsl: remove usage of list iterator past the loop bodyJakob Koschel2-10/+16
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-2-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15partially Revert "usb: musb: Set the DT node on the child device"H. Nikolaus Schaller1-1/+0
This reverts the omap2430 changes of commit cf081d009c44 ("usb: musb: Set the DT node on the child device") Since v5.17-rc1, musb is broken on the gta04 and openpandora devices (omap3530/dm3730). BeagleBone Black (am335x) seems to work. Symptoms of this bug are a) main symptom [ 21.336517] using random host ethernet address [ 21.341430] using host ethernet address: 32:70:05:18:ff:78 [ 21.341461] using self ethernet address: 46:10:3a:b3:af:d9 [ 21.358184] usb0: HOST MAC 32:70:05:18:ff:78 [ 21.376678] usb0: MAC 46:10:3a:b3:af:d9 [ 21.388305] using random self ethernet address [ 21.393371] using random host ethernet address [ 21.398162] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 [ 21.421081] g_ether gadget: g_ether ready [ 21.492156] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 21.691345] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 21.803192] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 21.819427] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 22.124450] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 22.168518] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 22.179382] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 23.213592] musb-hdrc musb-hdrc.1.auto: pm runtime get failed in musb_gadget_queue [ 23.221832] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 23.227905] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 23.239440] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 23.401000] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 23.407073] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 23.426361] musb-hdrc musb-hdrc.1.auto: Could not enable: -22 [ 23.734466] musb-hdrc musb-hdrc.1.auto: pm runtime get failed in musb_gadget_queue [ 23.742462] musb-hdrc musb-hdrc.1.auto: pm runtime get failed in musb_gadget_queue [ 23.750396] musb-hdrc musb-hdrc.1.auto: pm runtime get failed in musb_gadget_queue ... (repeats with high frequency) This stops if the USB cable is unplugged and restarts if it is plugged in again. b) also found in the log [ 6.498107] ------------[ cut here ]------------ [ 6.502960] WARNING: CPU: 0 PID: 868 at arch/arm/mach-omap2/omap_hwmod.c:1885 _enable+0x50/0x234 [ 6.512207] omap_hwmod: usb_otg_hs: enabled state can only be entered from initialized, idle, or disabled state [ 6.522766] Modules linked in: omap2430(+) bmp280_i2c bmp280 itg3200 at24 tsc2007 leds_tca6507 bma180 hmc5843_i2c hmc5843_core industrialio_triggered_buffer lis3lv02d_i2c kfifo_buf lis3lv02d phy_twl4030_usb snd_soc_omap_mcbsp snd_soc_ti_sdma musb_hdrc snd_soc_twl4030 gnss_sirf twl4030_vibra twl4030_madc twl4030_charger twl4030_pwrbutton gnss industrialio ehci_omap omapdrm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks cec [ 6.566436] CPU: 0 PID: 868 Comm: udevd Not tainted 5.16.0-rc5-letux+ #8251 [ 6.573730] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 6.580322] [<c010ed30>] (unwind_backtrace) from [<c010a1d0>] (show_stack+0x10/0x14) [ 6.588470] [<c010a1d0>] (show_stack) from [<c0897c14>] (dump_stack_lvl+0x40/0x4c) [ 6.596405] [<c0897c14>] (dump_stack_lvl) from [<c0130cc4>] (__warn+0xb4/0xdc) [ 6.604003] [<c0130cc4>] (__warn) from [<c0130d5c>] (warn_slowpath_fmt+0x70/0x9c) [ 6.611846] [<c0130d5c>] (warn_slowpath_fmt) from [<c011f4d4>] (_enable+0x50/0x234) [ 6.619903] [<c011f4d4>] (_enable) from [<c012081c>] (omap_hwmod_enable+0x28/0x40) [ 6.627838] [<c012081c>] (omap_hwmod_enable) from [<c0120ff4>] (omap_device_enable+0x4c/0x78) [ 6.636779] [<c0120ff4>] (omap_device_enable) from [<c0121030>] (_od_runtime_resume+0x10/0x3c) [ 6.645812] [<c0121030>] (_od_runtime_resume) from [<c05c688c>] (__rpm_callback+0x3c/0xf4) [ 6.654510] [<c05c688c>] (__rpm_callback) from [<c05c6994>] (rpm_callback+0x50/0x54) [ 6.662628] [<c05c6994>] (rpm_callback) from [<c05c66b0>] (rpm_resume+0x448/0x4e4) [ 6.670593] [<c05c66b0>] (rpm_resume) from [<c05c6784>] (__pm_runtime_resume+0x38/0x50) [ 6.678985] [<c05c6784>] (__pm_runtime_resume) from [<bf14ab20>] (musb_init_controller+0x350/0xa5c [musb_hdrc]) [ 6.689727] [<bf14ab20>] (musb_init_controller [musb_hdrc]) from [<c05bccb8>] (platform_probe+0x58/0xa8) [ 6.699737] [<c05bccb8>] (platform_probe) from [<c05badf0>] (really_probe+0x170/0x2fc) [ 6.708068] [<c05badf0>] (really_probe) from [<c05bb040>] (__driver_probe_device+0xc4/0xd8) [ 6.716827] [<c05bb040>] (__driver_probe_device) from [<c05bb084>] (driver_probe_device+0x30/0xac) [ 6.726226] [<c05bb084>] (driver_probe_device) from [<c05bb3d0>] (__device_attach_driver+0x94/0xb4) [ 6.735717] [<c05bb3d0>] (__device_attach_driver) from [<c05b93f8>] (bus_for_each_drv+0xa0/0xb4) [ 6.744934] [<c05b93f8>] (bus_for_each_drv) from [<c05bb248>] (__device_attach+0xc0/0x134) [ 6.753631] [<c05bb248>] (__device_attach) from [<c05b9fcc>] (bus_probe_device+0x28/0x80) [ 6.762207] [<c05b9fcc>] (bus_probe_device) from [<c05b7e40>] (device_add+0x5fc/0x788) [ 6.770507] [<c05b7e40>] (device_add) from [<c05bd240>] (platform_device_add+0x70/0x1bc) [ 6.779022] [<c05bd240>] (platform_device_add) from [<bf177830>] (omap2430_probe+0x260/0x2d4 [omap2430]) [ 6.789001] [<bf177830>] (omap2430_probe [omap2430]) from [<c05bccb8>] (platform_probe+0x58/0xa8) [ 6.798309] [<c05bccb8>] (platform_probe) from [<c05badf0>] (really_probe+0x170/0x2fc) [ 6.806610] [<c05badf0>] (really_probe) from [<c05bb040>] (__driver_probe_device+0xc4/0xd8) [ 6.815399] [<c05bb040>] (__driver_probe_device) from [<c05bb084>] (driver_probe_device+0x30/0xac) [ 6.824798] [<c05bb084>] (driver_probe_device) from [<c05bb4b4>] (__driver_attach+0xc4/0xd8) [ 6.833648] [<c05bb4b4>] (__driver_attach) from [<c05b9308>] (bus_for_each_dev+0x64/0xa0) [ 6.842224] [<c05b9308>] (bus_for_each_dev) from [<c05ba248>] (bus_add_driver+0x148/0x1a4) [ 6.850891] [<c05ba248>] (bus_add_driver) from [<c05bbd1c>] (driver_register+0xb4/0xf8) [ 6.859313] [<c05bbd1c>] (driver_register) from [<c0101f54>] (do_one_initcall+0x90/0x1c8) [ 6.867889] [<c0101f54>] (do_one_initcall) from [<c0893968>] (do_init_module+0x4c/0x204) [ 6.876373] [<c0893968>] (do_init_module) from [<c01b4c30>] (load_module+0x13f0/0x1928) [ 6.884796] [<c01b4c30>] (load_module) from [<c01b53a0>] (sys_finit_module+0xa0/0xc0) [ 6.893005] [<c01b53a0>] (sys_finit_module) from [<c0100080>] (ret_fast_syscall+0x0/0x54) [ 6.901580] Exception stack(0xc2807fa8 to 0xc2807ff0) [ 6.906890] 7fa0: b6e517d4 00052068 00000006 b6e509f8 00000000 b6e5131c [ 6.915466] 7fc0: b6e517d4 00052068 cd718000 0000017b 00020000 00037f78 00050048 00063368 [ 6.924011] 7fe0: bed8fef0 bed8fee0 b6e4ac4b b6f55a42 [ 6.929321] ---[ end trace d715ff121b58763c ]--- c) git bisect result on testing for "musb-hdrc" in the console log: cf081d009c447647c6b36aced535ca427dbebe72 is the first bad commit commit cf081d009c447647c6b36aced535ca427dbebe72 Author: Rob Herring <robh@kernel.org> Date: Wed Dec 15 17:07:57 2021 -0600 usb: musb: Set the DT node on the child device The musb glue drivers just copy the glue resources to the musb child device. Instead, set the musb child device's DT node pointer to the parent device's node so that platform_get_irq_byname() can find the resources in the DT. This removes the need for statically populating the IRQ resources from the DT which has been deprecated for some time. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211215230756.2009115-3-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> drivers/usb/musb/am35x.c | 2 ++ drivers/usb/musb/da8xx.c | 2 ++ drivers/usb/musb/jz4740.c | 1 + drivers/usb/musb/mediatek.c | 2 ++ drivers/usb/musb/omap2430.c | 1 + drivers/usb/musb/ux500.c | 1 + 6 files changed, 9 insertions(+) Reverting this patch makes musb work again as before. Fixes: cf081d009c44 ("usb: musb: Set the DT node on the child device") Cc: Rob Herring <robh@kernel.org> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/f62f5fc11f9ecae7e57f3fd66939e051bd3b11fc.1646744166.git.hns@goldelico.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: rndis: prevent integer overflow in rndis_set_response()Dan Carpenter1-0/+1
If "BufOffset" is very large the "BufOffset + 8" operation can have an integer overflow. Cc: stable@kernel.org Fixes: 38ea1eac7d88 ("usb: gadget: rndis: check size of RNDIS_MSG_SET command") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220301080424.GA17208@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: pci: Add support for Intel Alder LakeShruthi Sanil1-0/+4
Add the PCI device ID and update the dwc3_pci_id_table for Intel Alder Lake SoC. The DWC3 controllor in the CPU block handles the USB3 traffic and the device ID is common across the Alder Lake platforms. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> Link: https://lore.kernel.org/r/20220308170848.30722-1-shruthi.sanil@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: omap: fix "unbalanced disables for smps10_out1" on omap5evmH. Nikolaus Schaller1-1/+1
Usually, the vbus_regulator (smps10 on omap5evm) boots up disabled. Hence calling regulator_disable() indirectly through dwc3_omap_set_mailbox() during probe leads to: [ 10.332764] WARNING: CPU: 0 PID: 1628 at drivers/regulator/core.c:2853 _regulator_disable+0x40/0x164 [ 10.351919] unbalanced disables for smps10_out1 [ 10.361298] Modules linked in: dwc3_omap(+) clk_twl6040 at24 gpio_twl6040 palmas_gpadc palmas_pwrbutton industrialio snd_soc_omap_mcbsp(+) snd_soc_ti_sdma display_connector ti_tpd12s015 drm leds_gpio drm_panel_orientation_quirks ip_tables x_tables ipv6 autofs4 [ 10.387818] CPU: 0 PID: 1628 Comm: systemd-udevd Not tainted 5.17.0-rc1-letux-lpae+ #8139 [ 10.405129] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 10.411455] unwind_backtrace from show_stack+0x10/0x14 [ 10.416970] show_stack from dump_stack_lvl+0x40/0x4c [ 10.422313] dump_stack_lvl from __warn+0xb8/0x170 [ 10.427377] __warn from warn_slowpath_fmt+0x70/0x9c [ 10.432595] warn_slowpath_fmt from _regulator_disable+0x40/0x164 [ 10.439037] _regulator_disable from regulator_disable+0x30/0x64 [ 10.445382] regulator_disable from dwc3_omap_set_mailbox+0x8c/0xf0 [dwc3_omap] [ 10.453116] dwc3_omap_set_mailbox [dwc3_omap] from dwc3_omap_probe+0x2b8/0x394 [dwc3_omap] [ 10.467021] dwc3_omap_probe [dwc3_omap] from platform_probe+0x58/0xa8 [ 10.481762] platform_probe from really_probe+0x168/0x2fc [ 10.481782] really_probe from __driver_probe_device+0xc4/0xd8 [ 10.481782] __driver_probe_device from driver_probe_device+0x24/0xa4 [ 10.503762] driver_probe_device from __driver_attach+0xc4/0xd8 [ 10.510018] __driver_attach from bus_for_each_dev+0x64/0xa0 [ 10.516001] bus_for_each_dev from bus_add_driver+0x148/0x1a4 [ 10.524880] bus_add_driver from driver_register+0xb4/0xf8 [ 10.530678] driver_register from do_one_initcall+0x90/0x1c4 [ 10.536661] do_one_initcall from do_init_module+0x4c/0x200 [ 10.536683] do_init_module from load_module+0x13dc/0x1910 [ 10.551159] load_module from sys_finit_module+0xc8/0xd8 [ 10.561319] sys_finit_module from __sys_trace_return+0x0/0x18 [ 10.561336] Exception stack(0xc344bfa8 to 0xc344bff0) [ 10.561341] bfa0: b6fb5778 b6fab8d8 00000007 b6ecfbb8 00000000 b6ed0398 [ 10.561341] bfc0: b6fb5778 b6fab8d8 855c0500 0000017b 00020000 b6f9a3cc 00000000 b6fb5778 [ 10.595500] bfe0: bede18f8 bede18e8 b6ec9aeb b6dda1c2 [ 10.601345] ---[ end trace 0000000000000000 ]--- Fix this unnecessary warning by checking if the regulator is enabled. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/af3b750dc2265d875deaabcf5f80098c9645da45.1646744616.git.hns@goldelico.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: gadget: Give some time to schedule isocThinh Nguyen1-1/+7
Currently the driver will schedule isoc transfers immediately on the next interval, which is quite aggressive when the interval is 125us. There's report that some platforms may need more time to process the transfer, otherwise the controller may miss the first interval. Let's keep it simple and give the controller at least 500us to schedule the isoc transfer. Link: https://lore.kernel.org/linux-usb/20220302143539.GI11577@pengutronix.de/ Tested-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/deb8146b8e1f7f8495ef2d5647017270934cb2d8.1646708142.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: core: do not use 3.0 clock when operating in 2.0 modeBin Yang2-0/+6
In the 3.0 device core, if the core is programmed to operate in 2.0 only, then setting the GUCTL1.DEV_FORCE_20_CLK_FOR_30_CLK makes the internal 2.0(utmi/ulpi) clock to be routed as the 3.0 (pipe) clock. Enabling this feature allows the pipe3 clock to be not-running when forcibly operating in 2.0 device mode. Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Bin Yang <yangbin@rock-chips.com> Signed-off-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20220228135700.1089526-6-pgwipeout@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: imx8mp: Add support for setting SOC specific flagsAlexander Stein1-0/+63
The i.MX8MP glue layer has support for the following flags: * over-current polarity * PWR pad polarity * controlling PPC flag in HCCPARAMS register * permanent port attach for usb2 & usb3 port Allow setting these flags by supporting specific flags in the glue node. In order to get this to work an additional IORESOURCE_MEM and clock is necessary. For backward compatibility this is purely optional. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20220218152707.2198357-4-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: imx8mp: rename iomem base pointerAlexander Stein1-8/+8
Until now the iomem used is not USB glue as the name suggests, but HSIO BLK_CTL. Rename the struct member accordingly. This is a preparing patch for when USB glue is actually used. Reviewed-by: Li Jun <jun.li@nxp.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20220218152707.2198357-2-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>