- 26 Apr, 2022 20 commits
-
-
Matthias Kaehlcke authored
The main issue this driver addresses is that a USB hub needs to be powered before it can be discovered. For discrete onboard hubs (an example for such a hub is the Realtek RTS5411) this is often solved by supplying the hub with an 'always-on' regulator, which is kind of a hack. Some onboard hubs may require further initialization steps, like changing the state of a GPIO or enabling a clock, which requires even more hacks. This driver creates a platform device representing the hub which performs the necessary initialization. Currently it only supports switching on a single regulator, support for multiple regulators or other actions can be added as needed. Different initialization sequences can be supported based on the compatible string. Besides performing the initialization the driver can be configured to power the hub off during system suspend. This can help to extend battery life on battery powered devices which have no requirements to keep the hub powered during suspend. The driver can also be configured to leave the hub powered when a wakeup capable USB device is connected when suspending, and power it off otherwise. Technically the driver consists of two drivers, the platform driver described above and a very thin USB driver that subclasses the generic driver. The purpose of this driver is to provide the platform driver with the USB devices corresponding to the hub(s) (a hub controller may provide multiple 'logical' hubs, e.g. one to support USB 2.0 and another for USB 3.x). Note: the current series only supports hubs connected directly to a root hub, support for other configurations could be added if needed. Co-developed-by:
Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220217104219.v21.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeidSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthias Kaehlcke authored
Code for platform_device_create() and of_platform_device_destroy() is only generated if CONFIG_OF_ADDRESS=y. Add stubs to avoid unresolved symbols when CONFIG_OF_ADDRESS is not set. Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Alan Stern authored
This patch adds a "gadget" bus and uses it for registering gadgets and their drivers. From now on, bindings will be managed by the driver core rather than through ad-hoc manipulations in the UDC core. As part of this change, the driver_pending_list is removed. The UDC core won't need to keep track of unbound drivers for later binding, because the driver core handles all of that for us. However, we do need one new feature: a way to prevent gadget drivers from being bound to more than one gadget at a time. The existing code does this automatically, but the driver core doesn't -- it's perfectly happy to bind a single driver to all the matching devices on the bus. The patch adds a new bitflag to the usb_gadget_driver structure for this purpose. A nice side effect of this change is a reduction in the total lines of code, since now the driver core will do part of the work that the UDC used to do. A possible future patch could add udc devices to the gadget bus, say as a separate device type. Signed-off-by:
-
Alan Stern authored
This patch fixes some minor mistakes in the UDC core's kerneldoc. Signed-off-by:
-
Alan Stern authored
In preparation for adding a "gadget" bus, this patch reverses the order of registration of udc and gadget devices in usb_add_gadget(). The current code adds the gadget device first, probably because that was more convenient at the time and the order didn't really matter. But with the upcoming change, adding the gadget will cause driver probing to occur. Unwinding that on the error pathway will become much more obtrusive, not to mention the fact that a gadget driver might not work properly before the udc is registered. It's better to register the udc device first, particularly since that doesn't involve a bus or driver binding and therefore is simpler to unwind. For symmetry, the order of unregistration in usb_del_gadget() is likewise reversed. Signed-off-by:
-
Alan Stern authored
In preparation for adding a "gadget" bus, this patch renames usb_gadget_probe_driver() to usb_gadget_register_driver(). The new name will be more accurate, since gadget drivers will be registered on the gadget bus and the probing will be done by the driver core, not the UDC core. Signed-off-by:
-
Sergey Shtylyov authored
The USB device dump code often checks for the buffer overflow just before calling the functions that do that first thing anyways. Such checks are redundant and may be dropped... Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/0453cb0d-7b2b-25e6-50e3-091610951e58@omp.ruSigned-off-by:
-
Nick Hawkins authored
Add hpe,gxp-ohci to the generic-ohci list. This is to enable the device tree support. Signed-off-by:
Nick Hawkins <nick.hawkins@hpe.com> Link: https://lore.kernel.org/r/20220421192132.109954-10-nick.hawkins@hpe.comAcked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Nick Hawkins authored
Add hpe,gxp-ehci to the generic-ehci list. This is to enable the device tree. Signed-off-by:
-
Bjorn Andersson authored
The ON Semiconductor FSA4480 is a USB Type-C port multimedia switch with support for analog audio headsets. It allows sharing a common USB Type-C port to pass USB2.0 signal, analog audio, sideband use wires and analog microphone signal. Due to lacking upstream audio support for testing, the audio muxing is left untouched, but implementation of muxing the SBU lines is provided as a pair of Type-C mux and switch devices. This provides the necessary support for enabling the DisplayPort altmode on devices with this circuit. Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220422222351.1297276-8-bjorn.andersson@linaro.orgSigned-off-by:
-
Bjorn Andersson authored
The Fairchild/ON Semiconductor FSA4480 Analog Audio switch is used in USB Type-C configurations for muxing analog audio onto the USB connector, and as such used to control the SBU signals for altmodes such as DisplayPort. Add a binding for this hardware block. Reviewed-by:
-
Bjorn Andersson authored
In the Qualcomm platforms the USB/DP PHY handles muxing and orientation switching of the SuperSpeed lines, but the SBU lines needs to be connected and switched by external (to the SoC) hardware. It's therefor necessary to be able to have the TypeC controller operate multiple TypeC muxes and switches. Use the newly introduced indirection object to handle this, to avoid having to taint the TypeC controllers with knowledge about the downstream hardware configuration. The max number of devs per indirection is set to 3, which account for being able to mux/switch the USB HS, SS and SBU lines, as per defined defined in the usb-c-connector binding. This number could be grown if need arrises at a later point in time. Acked-by:
-
Bjorn Andersson authored
Rather than directly exposing the implementation's representation of the typec muxes to the controller/clients, introduce an indirection object. This enables the introduction of turning this relationship into a one-to-many in the following patch. Acked-by:
-
Bjorn Andersson authored
It's possible that dev_set_name() returns -ENOMEM, catch and handle this. Fixes: 3370db35 ("usb: typec: Registering real device entries for the muxes") Reported-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
-
Bjorn Andersson authored
The newly introduced helpers for searching for matches in the case of multiple connections can be resused by the single-connection case, so do this to save some duplication. Reviewed-by:
-
Bjorn Andersson authored
In some cases multiple connections with the same connection id needs to be resolved from a fwnode graph. One such example is when separate hardware is used for performing muxing and/or orientation switching of the SuperSpeed and SBU lines in a USB Type-C connector. In this case the connector needs to belong to a graph with multiple matching remote endpoints, and the Type-C controller needs to be able to resolve them both. Add a new API that allows this kind of lookup. Reviewed-by:
-
Linyu Yuan authored
When role switch module probe late than ucsi module, fwnode_usb_role_switch_get() will return -EPROBE_DEFER, it is better to restart ucsi init work to find it again every 100ms, total wait time is 10 second. It also means change ucsi init work to delayed_work. Reviewed-by:
Linyu Yuan <quic_linyyuan@quicinc.com> Link: https://lore.kernel.org/r/1650881886-25530-3-git-send-email-quic_linyyuan@quicinc.comSigned-off-by:
-
Linyu Yuan authored
In error path of ucsi_init(), it will unregister all valid ucsi connectors, and similar operation also happen in ucsi_unregister(), add a common function ucsi_unregister_connectors() for two places, inside this function, if con->wq is NULL, it will break the loop, if other kind of error happen after con->wq allocated, ucsi/typec related API is safe to unregister. Also in ucsi_init(), it allocate number of (ucsi->cap.num_connectors + 1) connectors, there is one extra as the ending, ucsi_unregister_connectors() is safe to unregister all ucsi connectors according ucsi->cap.num_connectors, remove the extra one connector to save memory. Reviewed-by:
-
Biju Das authored
Document RZ/G2ULSoC bindings. USBHS block is identical to one found on RZ/A2 SoC. No driver changes are required as generic compatible string "renesas,rza2-usbhs" will be used as a fallback. While at it, make the resets property required on RZ/{G2L,G2UL,V2L} SoC. Reviewed-by:Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20220425140215.186797-1-biju.das.jz@bp.renesas.comSigned-off-by:
-
Haowen Bai authored
Avoid pointer type value compared with 0 to make code clear. Signed-off-by:
Haowen Bai <baihaowen@meizu.com> Link: https://lore.kernel.org/r/1648088171-30912-1-git-send-email-baihaowen@meizu.comSigned-off-by:
-
- 23 Apr, 2022 15 commits
-
-
Vincent Mailhol authored
Rework the body of usb_maxpacket() and just rely on the usb_pipe_endpoint() helper function to retrieve the host endpoint instead of doing it by hand. Signed-off-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-10-mailhol.vincent@wanadoo.frSigned-off-by:
-
Vincent Mailhol authored
Now that all users of usb_maxpacket() have been migrated to only use two arguments, remove the third variadic argument which was introduced for the transition. Signed-off-by:
-
Vincent Mailhol authored
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Jaroslav Kysela <perex@perex.cz> CC: Takashi Iwai <tiwai@suse.com> CC: Clemens Ladisch <clemens@ladisch.de> Acked-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Vincent Mailhol authored
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Duncan Sands <duncan.sands@free.fr> CC: Alan Stern <stern@rowland.harvard.edu> CC: Olav Kongas <ok@artecdesign.ee> CC: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by:
-
Vincent Mailhol authored
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Oliver Neukum <oliver@neukum.org> CC: David S. Miller <davem@davemloft.net> CC: Jakub Kicinski <kuba@kernel.org> CC: Woojung Huh <woojung.huh@microchip.com> CC: Felix Fietkau <nbd@nbd.name> CC: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> CC: Ryder Lee <ryder.lee@mediatek.com> CC: Kalle Valo <kvalo@kernel.org> CC: Matthias Brugger <matthias.bgg@gmail.com> CC: Stanislaw Gruszka <stf_xl@wp.pl> CC: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
-
Vincent Mailhol authored
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Sean Young <sean@mess.org> CC: Mauro Carvalho Chehab <mchehab@kernel.org> CC: Benjamin Valentin <benpicco@googlemail.com> Signed-off-by:
-
Vincent Mailhol authored
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Ville Syrjala <syrjala@sci.fi> CC: Dmitry Torokhov <dmitry.torokhov@gmail.com> CC: Henk Vergonet <Henk.Vergonet@gmail.com> Signed-off-by:
-
Vincent Mailhol authored
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Jiri Kosina <jikos@kernel.org> CC: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Vincent Mailhol authored
This is a transitional patch with the ultimate goal of changing the prototype of usb_maxpacket() from: | static inline __u16 | usb_maxpacket(struct usb_device *udev, int pipe, int is_out) into: | static inline u16 usb_maxpacket(struct usb_device *udev, int pipe) The third argument of usb_maxpacket(): is_out gets removed because it can be derived from its second argument: pipe using usb_pipeout(pipe). Furthermore, in the current version, ubs_pipeout(pipe) is called regardless in order to sanitize the is_out parameter. In order to make a smooth change, we first deprecate the is_out parameter by simply ignoring it (using a variadic function) and will remove it later, once all the callers get updated. The body of the function is reworked accordingly and is_out is replaced by usb_pipeout(pipe). The WARN_ON() calls become unnecessary and get removed. Finally, the return type is changed from __u16 to u16 because this is not a UAPI function. Signed-off-by:
-
Evan Green authored
The documentation for the freeze() method says that it "should quiesce the device so that it doesn't generate IRQs or DMA". The unspoken consequence of not doing this is that MSIs aimed at non-boot CPUs may get fully lost if they're sent during the period where the target CPU is offline. The current callbacks for USB HCD do not fully quiesce interrupts, specifically on XHCI. Change to use the full suspend/resume flow for freeze/thaw to ensure interrupts are fully quiesced. This fixes issues where USB devices fail to thaw during hibernation because XHCI misses its interrupt and cannot recover. Acked-by:
Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20220421103751.v3.2.I8226c7fdae88329ef70957b96a39b346c69a914e@changeidSigned-off-by:
-
Evan Green authored
The PM_EVENT_FREEZE and PM_EVENT_QUIESCE messages should cause the device to stop generating interrupts. USB core was previously allowing devices that were already runtime suspended to keep remote wakeup enabled if they had gone down that way. This violates the contract with pm, and can potentially cause MSI interrupts to be lost. Change that so that if a device is runtime suspended with remote wakeups enabled, it will be resumed to ensure remote wakeup is always disabled across a freeze. Acked-by:
-
Zheng Yongjun authored
If the device is already in a runtime PM enabled state pm_runtime_get_sync() will return 1, so a test for negative value should be used to check for errors. Fixes: 8eed00b2 ("usb: dwc3: pci: Runtime resume child device from wq") Signed-off-by:
Zheng Yongjun <zhengyongjun3@huawei.com> Link: https://lore.kernel.org/r/20220422062652.10575-1-zhengyongjun3@huawei.comSigned-off-by:
-
Duoming Zhou authored
There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock. Signed-off-by:Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/20220417120305.64577-1-duoming@zju.edu.cnSigned-off-by:
-
Wesley Cheng authored
The list_for_each_entry_safe() macro saves the current item (n) and the item after (n+1), so that n can be safely removed without corrupting the list. However, when traversing the list and removing items using gadget giveback, the DWC3 lock is briefly released, allowing other routines to execute. There is a situation where, while items are being removed from the cancelled_list using dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable routine is running in parallel (due to UDC unbind). As the cleanup routine removes n, and the pullup disable removes n+1, once the cleanup retakes the DWC3 lock, it references a request who was already removed/handled. With list debug enabled, this leads to a panic. Ensure all instances of the macro are replaced where gadget giveback is used. Example call stack: Thread#1: __dwc3_gadget_ep_set_halt() - CLEAR HALT -> dwc3_gadget_ep_cleanup_cancelled_requests() ->list_for_each_entry_safe() ->dwc3_gadget_giveback(n) ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list] ->spin_unlock ->Thread#2 executes ... ->dwc3_gadget_giveback(n+1) ->Already removed! Thread#2: dwc3_gadget_pullup() ->waiting for dwc3 spin_lock ... ->Thread#1 released lock ->dwc3_stop_active_transfers() ->dwc3_remove_requests() ->fetches n+1 item from cancelled_list (n removed by Thread#1) ->dwc3_gadget_giveback() ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list] ->spin_unlock Fixes: d4f1afe5 ("usb: dwc3: gadget: move requests to cancelled_list") Signed-off-by:Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20220414183521.23451-1-quic_wcheng@quicinc.comSigned-off-by:
-
Wesley Cheng authored
The usb_ep_clear_halt() API can be called from the function driver, and translates to dwc3_gadget_ep_set_halt(). This routine is shared with when the host issues a clear feature ENDPOINT_HALT, and is differentiated by the protocol argument. If the following sequence occurs, there can be a situation where the delayed_status flag is improperly cleared for the wrong SETUP transaction: 1. Vendor specific control transfer returns USB_GADGET_DELAYED_STATUS. 2. DWC3 gadget sets dwc->delayed_status to '1'. 3. Another function driver issues a usb_ep_clear_halt() call. 4. DWC3 gadget issues dwc3_stop_active_transfer() and sets DWC3_EP_PENDING_CLEAR_STALL. 5. EP command complete interrupt triggers for the end transfer, and dwc3_ep0_send_delayed_status() is allowed to run, as delayed_status is '1' due to step#1. 6. STATUS phase is sent, and delayed_status is cleared. 7. Vendor specific control transfer is finished being handled, and issues usb_composite_setup_continue(). This results in queuing of a data phase. Cache the protocol flag so that DWC3 gadget is aware of when the clear halt is due to a SETUP request from the host versus when it is sourced from a function driver. This allows for the EP command complete interrupt to know if it needs to issue a delayed status phase. Signed-off-by:
-
- 22 Apr, 2022 1 commit
-
-
Andrey Smirnov authored
If the extcon device exists, get the mode from the extcon device. If the controller is DRD and the driver is unable to determine the mode, only then default the dr_mode to USB_DR_MODE_PERIPHERAL. Cc: Felipe Balbi <balbi@kernel.org> Cc: Thinh Nguyen <thinhn@synopsys.com> Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Link: https://lore.kernel.org/r/20220403164907.662860-1-andrew.smirnov@gmail.comSigned-off-by:
-
- 21 Apr, 2022 4 commits
-
-
AngeloGioacchino Del Regno authored
This driver uses three clocks and there's no special handling, they're either enabled or disabled sequentially: migrate to the clk_bulk API to simplify clock handling. This patch brings no functional changes. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220404145558.93340-1-angelogioacchino.delregno@collabora.comSigned-off-by:
-
周琰杰 (Zhou Yanjie) authored
Refresh USB nodes in the jz4780.dtsi, x1000.dtsi, and x1830.dtsi files. Signed-off-by:
周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Link: https://lore.kernel.org/r/1649964337-114337-4-git-send-email-zhouyanjie@wanyeetech.comSigned-off-by:
-
周琰杰 (Zhou Yanjie) authored
Add OTG support for the JZ4775 SoC, the JZ4780 SoC, the X1000 SoC, the X1600 SoC, the X1700 SoC, the X1830 SoC, and the X2000 SoC from Ingenic. Introduce support for disable Ingenic overcurrent detection, once selected, it enables the GOTGCTL register bits VbvalidOvEn and VbvalidOvVal to disable the VBUS overcurrent detection. This patch is derived from Dragan Čečavac (in the kernel 3.18.3 tree of CI20). It is very useful for the MIPS Creator CI20 (r1). Without this patch, OTG port of CI20 has a great probability to face overcurrent warning, which breaks the OTG functionality. Acked-by:
Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Signed-off-by:
Dragan Čečavac <dragancecavac@yahoo.com> Signed-off-by:
-
周琰杰 (Zhou Yanjie) authored
Add the dwc2 bindings for the JZ4775 SoC, the JZ4780 SoC, the X1000 SoC, the X1600 SoC, the X1700 SoC, the X1830 SoC, and the X2000 SoC from Ingenic. Acked-by:
-
