- 15 Jul, 2022 5 commits
-
-
Prashant Malani authored
Register mode switch devices for Type C connectors, when they are specified by firmware. These control Type C configuration for any USB Type-C mode switches (sometimes known as "muxes") which are controlled by the Chrome EC. Signed-off-by:
Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20220711072333.2064341-8-pmalani@chromium.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Prashant Malani authored
The Chrome EC updates Type-C status events when mux set requests from the Application Processor (AP) are completed. Add a check to the flow of configuring muxes to look for this status done bit, so that the driver is aware that the mux set completed successfully or not. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Prashant Malani authored
Invoke Chrome EC host commands to set EC-controlled retimer switches to the state the Type-C framework instructs. Signed-off-by:
-
Prashant Malani authored
Introduce a driver to configure USB Type-C mode switches and retimers which are controlled by the Chrome OS EC (Embedded Controller). This allows Type-C port drivers, as well as alternate mode drivers to configure their relevant mode switches and retimers according to the Type-C state they want to achieve. ACPI devices with ID GOOG001A will bind to this driver. Currently, we only register a retimer switch with a stub set function. Subsequent patches will implement the host command set functionality, and introduce mode switches. Reported-by:
-
Prashant Malani authored
Copy EC header definitions for the USB Type-C Mux control command from the EC code base. Also pull in "TBT_UFP_REPLY" definitions, since that is the prior entry in the enum. These headers are already present in the EC code base. [1] [1] https://chromium.googlesource.com/chromiumos/platform/ec/+/b80f85a94a423273c1638ef7b662c56931a138dd/include/ec_commands.hSigned-off-by:
-
- 14 Jul, 2022 15 commits
-
-
Prashant Malani authored
Similar to mux and orientation switch, add a handle for registered retimer to the port, so that it has handles to the various switches connected to it. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20220711072333.2064341-3-pmalani@chromium.orgSigned-off-by:
-
Prashant Malani authored
Introduce a retimer device class and associated functions that register and use retimer "switch" devices. These operate in a manner similar to the "mode-switch" and help configure retimers that exist between the Type-C connector and host controller(s). Type C ports can be linked to retimers using firmware node device references (again, in a manner similar to "mode-switch"). There are no new sysfs files being created; there is the new retimer class directory, but there are no class-specific files being created there. Signed-off-by:
-
Johan Hovold authored
Not all platforms have all of the four currently supported wakeup interrupts so use the optional irq helpers when looking up interrupts to avoid printing error messages when an optional interrupt is not found: dwc3-qcom a6f8800.usb: error -ENXIO: IRQ hs_phy_irq not found Fixes: a4333c3a ("usb: dwc3: Add Qualcomm DWC3 glue driver") Reviewed-by:
Andrew Halaney <ahalaney@redhat.com> Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20220713131340.29401-4-johan+linaro@kernel.orgSigned-off-by:
-
Johan Hovold authored
Not all platforms have all of the four wakeup interrupts currently described by the bindings. Specifically, MSM8953/6/8 and SDM660 do not use the DP/DM interrupts, while the SS PHY interrupt is optional on SDM660 and SC7280. Note that no devicetree in mainline specify any wakeup interrupts for - qcom,ipq4019-dwc3 - qcom,ipq6018-dwc3 - qcom,ipq8064-dwc3 - qcom,ipq8074-dwc3 - qcom,msm8994-dwc3 - qcom,qcs404-dwc3 but let's keep the schema warnings about that for now. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Johan Hovold authored
Add SC8280XP to the DT schema. Note that the SC8280XP controllers use the common set of five clocks and an additional set of four interconnect clocks whose purpose is not entirely clear at this point. The set of wakeup interrupts is also different for SC8280XP. Reviewed-by:
-
Xin Ji authored
Add driver for analogix ANX7411 USB Type-C DRP port controller. Acked-by:
Xin Ji <xji@analogixsemi.com> Link: https://lore.kernel.org/r/20220714081350.36447-2-xji@analogixsemi.comSigned-off-by:
-
Xin Ji authored
Add analogix PD chip anx7411 device binding Reviewed-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Rohith Kollalsi authored
According to the programming guide, it is recommended to perform a GCTL_CORE_SOFTRESET only when switching the mode from device to host or host to device. However, it is found that during bootup when __dwc3_set_mode() is called for the first time, GCTL_CORESOFTRESET is done with suspendable bit(BIT 17) of DWC3_GUSB3PIPECTL set. This some times leads to issues like controller going into bad state and controller registers reading value zero. Until GCTL_CORESOFTRESET is done and run/stop bit is set core initialization is not complete. Setting suspendable bit of DWC3_GUSB3PIPECTL and then performing GCTL_CORESOFTRESET is therefore not recommended. Avoid this by only performing the reset if current_dr_role is set, that is, when doing subsequent role switching. Fixes: f88359e1 ("usb: dwc3: core: Do core softreset when switch mode") Signed-off-by:
Rohith Kollalsi <quic_rkollals@quicinc.com> Link: https://lore.kernel.org/r/20220714045625.20377-1-quic_rkollals@quicinc.comSigned-off-by:
-
Liang He authored
We should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 30d2617f ("usb: gadget: aspeed: allow to set usb strings in device tree") Signed-off-by:
Liang He <windhl@126.com> Link: https://lore.kernel.org/r/20220713120528.368168-1-windhl@126.comSigned-off-by:
-
Jiangshan Yi authored
Fix the following coccicheck warning: drivers/usb/misc/ldusb.c:719: WARNING opportunity for max(). drivers/usb/misc/ldusb.c:721: WARNING opportunity for max(). max_t() macro is defined in include/linux/minmax.h. It avoids multiple evaluations of the arguments when non-constant and performs strict type-checking. Signed-off-by:
Jiangshan Yi <yijiangshan@kylinos.cn> Link: https://lore.kernel.org/r/20220713070205.3047256-1-13667453960@163.comSigned-off-by:
-
Wesley Cheng authored
During a 3 stage SETUP transfer, if the host sends another SETUP token before completing the status phase, it signifies that the host has aborted the current control transfer. Currently, if a setup_packet_pending is received, there are no subsequent calls to dwc3_ep0_out_start() to fetch the new SETUP packet. This leads to a stall on EP0, as host does not expect another STATUS phase as it has aborted the current transfer. Fix this issue by explicitly stalling and restarting EP0, as well as resetting the trb_enqueue indexes. (without this, there is a chance the SETUP TRB is set up on trb_endqueue == 1) Signed-off-by:
Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20220712014403.2977-1-quic_wcheng@quicinc.comSigned-off-by:
-
Matthias Kaehlcke authored
When building with 'W=1' the compiler complains about missing prototypes for onboard_hub_create/destroy_pdevs(). Include the header with the prototypes to fix this. Reported-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220711092431.1.I4016c759fd7fe2b32dd482994a20661f36e2cae3@changeidSigned-off-by:
-
Nícolas F. R. A. Prado authored
This reverts commit ebc4969a. That commit was supposed to make the binding better reflect the MediaTek XHCI hardware block by requiring all clocks to be present. But doing that also causes too much noise in the devicetrees, since it requires updating old MediaTek DTs to add clock handles for the fixed clocks, and going forward every new clock added to the binding would require even more updates. The commit also didn't update the example to match the changes, causing additional warnings. Instead let's keep the clocks optional so that old devicetrees can keep omitting the fixed clocks, and we'll just add the clocks as required on new DTs. Fixes: ebc4969a ("dt-bindings: usb: mtk-xhci: Make all clocks required") Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Acked-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20220708192605.43351-1-nfraprado@collabora.comSigned-off-by:
-
Maxim Devaev authored
It allows to reset prevent_medium_removal flag and "eject" the image. This can be useful to free the drive from a hunging host or if the host continues to use the drive even after unmounting (Linux does this). It's also a bit like using an unfolded paperclip on an optical drive. Previously, the undocumented method of sending SIGUSR1 to a special "file-storage" kernel thread could be used for these purposes, but when using multiple storages there was no way to distinguish one from the other, so we had to send a signal to everyone. Reviewed-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Maxim Devaev <mdevaev@gmail.com> Link: https://lore.kernel.org/r/20220711102956.19642-1-mdevaev@gmail.comSigned-off-by:
-
Randy Dunlap authored
USB_AMD5536UDC should depend on HAS_DMA since it selects USB_SNP_CORE, which depends on HAS_DMA and since 'select' does not follow any dependency chains. Fixes this kconfig warning: WARNING: unmet direct dependencies detected for USB_SNP_CORE Depends on [n]: USB_SUPPORT [=y] && USB_GADGET [=y] && (USB_AMD5536UDC [=y] || USB_SNP_UDC_PLAT [=n]) && HAS_DMA [=n] Selected by [y]: - USB_AMD5536UDC [=y] && USB_SUPPORT [=y] && USB_GADGET [=y] && USB_PCI [=y] Fixes: 97b3ffa2 ("usb: gadget: udc: amd5536: split core and PCI layer") Cc: Raviteja Garimella <raviteja.garimella@broadcom.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220709013601.7536-1-rdunlap@infradead.orgSigned-off-by:
-
- 08 Jul, 2022 19 commits
-
-
Michael Grzeschik authored
For High-Speed Transfers the prepare_one_trb function is calculating the multiplier setting for the trb based on the length parameter of the trb currently prepared. This assumption is wrong. For trbs with a sg list, the length of the actual request has to be taken instead. Fixes: 40d829fb ("usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets") Cc: stable <stable@kernel.org> Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220704141812.1532306-3-m.grzeschik@pengutronix.deSigned-off-by:
-
Michael Grzeschik authored
The function __dwc3_prepare_one_trb has many parameters. Since it is only used in dwc3_prepare_one_trb there is no point in keeping the function. We merge both functions and get rid of the big list of parameters. Fixes: 40d829fb ("usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets") Cc: stable <stable@kernel.org> Signed-off-by:
-
Bryan O'Donoghue authored
Add the ability to detect and print the USB speed as "super-plus" if/when the kernel reports that speed. Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20220708115859.2095714-4-bryan.odonoghue@linaro.orgSigned-off-by:
-
Bryan O'Donoghue authored
Add the ability to detect and print the USB speed as "super" if/when the kernel reports that speed. Signed-off-by:
-
Bryan O'Donoghue authored
Add the ability to detect and print the USB speed as "wireless" if/when the kernel reports that speed. Signed-off-by:
-
Matthias Kaehlcke authored
Call onboard_hub_create/destroy_pdevs() from hub_probe/disconnect() to create/destroy platform devices for onboard USB hubs that may be connected to the hub. The onboard hubs must have nodes in the device tree. onboard_hub_create/destroy_pdevs() are NOPs unless CONFIG_USB_ONBOARD_HUB=y/m. Also add a field to struct usb_hub to keep track of the onboard hub platform devices that are owned by the hub. Reviewed-by:
-
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). Co-developed-by:
Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-by:
-
Matthias Kaehlcke authored
In the context of USB the term 'companion-hub' is misleading, change the name of the property to 'peer-hub'. There are no upstream users of the 'companion-hub' property, neither in the device tree, nor on the driver side, so renaming it shouldn't cause any compatibility issues with existing device trees. Changes in v24: - patch added to the series Reviewed-by:
-
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:
-
Chunfeng Yun authored
Add function wake notification to support function remote wakeup, currently assume the composite device only enable function wake for the first interface. Forward request to function driver when the recipient is an interface, including: GetStatus() request to the first interface in a function returns the information about 'function remote wakeup' and 'function remote wakeup capalbe'; SetFeature request of FUNCTION_SUSPEND to an interface recipient, the controller driver saves the suspend option; Signed-off-by:
-
Chunfeng Yun authored
It is capable of supporting usb3 dual role if there is at least one usb3 port for device and xhci controller, we can check it from the controller's capability, so no need the property "mediatek,usb3-drd" anymore, but I find the property is not decribed in dt-binding. Meanwhile, also take into account if the u3 port is disabled when the u3 phy is shared with pcie. Signed-off-by:
-
Chunfeng Yun authored
We may want to disable device's usb3 port when the combo phy is switched from usb3 mode to pcie mode for some projects. Meanwhile rename member @is_u3_ip to @u3_capable to avoid misleading, due to the member's value may be changed when disable usb3 port, but the controller is still a usb3 IP which also tells us how to manage the fifo. Signed-off-by:
-
Chunfeng Yun authored
Print endpoint type as string instead of decimal value to make the log more readable. Signed-off-by:
-
Xin Ji authored
USB PD controllers which consisting of a microcontroller (acting as the TCPM) and a port controller (TCPC) - may require that the driver for the PD controller accesses directly also the on-chip port controller in some cases. Move tcpci.h to include/linux/usb/ is convenience access TCPC registers. Reviewed-by:
-
Jozef Martiniak authored
after usb_ep_queue() if wait_for_completion_interruptible() is interrupted we need to wait until IRQ gets finished. Otherwise complete() from epio_complete() can corrupt stack. Signed-off-by:
Jozef Martiniak <jomajm@gmail.com> Link: https://lore.kernel.org/r/20220708070645.6130-1-jomajm@gmail.comSigned-off-by:
-
Chunfeng Yun authored
Add compatible for mt8188 Reviewed-by:
-
Michael Walle authored
The driver won't probe on a LAN9668 because the pinctrl driver isn't ready yet. Probe deferral is not supported because the init section is already discarded. With fw_devlink enabled, the probe won't even be called. Convert the driver to a proper platform driver. Signed-off-by:
Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20220705131951.1388968-2-michael@walle.ccSigned-off-by:
-
Michael Walle authored
devm_gpiod_get_optional() might still return an error code, esp. EPROBE_DEFER. Return any errors. Signed-off-by:
-
Steven Rostedt (Google) authored
The event classes udc_log_ep and udc_log_req both declare: __dynamic_array(char, name, UDC_TRACE_STR_MAX) Which will reserve UDC_TRACE_STR_MAX bytes on the ring buffer for the event to write in name. It then uses snprintf() to write into that space. Assuming that the string being copied is nul terminated, it is better to just use the __string() helper. That way only the size of the string is saved into the ring buffer and not the max size (yes, the entire UDC_TRACE_STR_MAX is used in the trace event, and anything not used is just junk in the ring buffer). Worse, there's also meta data saved into the event that denotes where the string is stored in the event and also saves its size, which is always going to be UDC_TRACE_STR_MAX. Convert both to use the __string() and __assign_str() helpers that are for this kind of use case. Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by:Steven Rostedt (Google) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20220703091449.317f94b1@rorschach.local.homeSigned-off-by:
-
- 01 Jul, 2022 1 commit
-
-
Herve Codina authored
The USB device controller available in the Microchip LAN9662 SOC is the same IP as the one present in the SAMA5D3 SOC. Add the LAN9662 compatible string and set the SAMA5D3 compatible string as a fallback for the LAN9662. Signed-off-by:
Herve Codina <herve.codina@bootlin.com> Acked-by:
-
