- 28 Jan, 2024 40 commits
-
-
Ran Wang authored
When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS (or its control signal) will be turned on immediately on related Root Hub ports. Then, the VBUS is turned off for a little while(15us) when do xhci reset (conducted by xhci driver) and back to normal finally, we can observe a negative glitch of related signal happen. This VBUS glitch might cause some USB devices enumeration fail if kernel boot with them connected. Such as LS1012AFWRY/LS1043ARDB/LX2160AQDS /LS1088ARDB with Kingston 16GB USB2.0/Kingston USB3.0/JetFlash Transcend 4GB USB2.0 drives. The fail cases include enumerated as full-speed device or report wrong device descriptor, etc. One SW workaround which can fix this is by programing all xhci PORTSC[PP] to 0 to turn off VBUS immediately after setting host mode in DWC3 driver (per signal measurement result, it will be too late to do it in xhci-plat.c or xhci.c). Then, after xhci reset complete in xhci driver, PORTSC[PP]s' value will back to 1 automatically and VBUS on at that time, no glitch happen and normal enumeration process has no impact. Acked-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by:
Ran Wang <ran.wang_1@nxp.com> Reviewed-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20240124152525.3910311-4-Frank.Li@nxp.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ran Wang authored
When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS (or its control signal) will turn on immediately on related Root Hub ports. Then the VBUS will be de-asserted for a little while during xhci reset (conducted by xhci driver) for a little while and back to normal. This VBUS glitch might cause some USB devices emuration fail if kernel boot with them connected. One SW workaround which can fix this is to program all PORTSC[PP] to 0 to turn off VBUS immediately after setting host mode in DWC3 driver(per signal measurement result, it will be too late to do it in xhci-plat.c or xhci.c). Signed-off-by:
-
Frank Li authored
Split the PORT and CAPs macro definitions into a separate file to facilitate sharing with other files without the need to include the entire xhci.h. Signed-off-by:
-
Nícolas F. R. A. Prado authored
Add a sample board file describing the file's format and with the list of devices expected to be probed on the XPS 13 9300 machine as an example x86 platform. Test output: TAP version 13 Using board file: boards/Dell Inc.,XPS 13 9300.yaml 1..22 ok 1 /pci-controller/14.0/usb2-controller/9/camera.device ok 2 /pci-controller/14.0/usb2-controller/9/camera.0.driver ok 3 /pci-controller/14.0/usb2-controller/9/camera.1.driver ok 4 /pci-controller/14.0/usb2-controller/9/camera.2.driver ok 5 /pci-controller/14.0/usb2-controller/9/camera.3.driver ok 6 /pci-controller/14.0/usb2-controller/10/bluetooth.device ok 7 /pci-controller/14.0/usb2-controller/10/bluetooth.0.driver ok 8 /pci-controller/14.0/usb2-controller/10/bluetooth.1.driver ok 9 /pci-controller/2.0/gpu.device ok 10 /pci-controller/2.0/gpu.driver ok 11 /pci-controller/4.0/thermal.device ok 12 /pci-controller/4.0/thermal.driver ok 13 /pci-controller/12.0/sensors.device ok 14 /pci-controller/12.0/sensors.driver ok 15 /pci-controller/14.3/wifi.device ok 16 /pci-controller/14.3/wifi.driver ok 17 /pci-controller/1d.0/0.0/ssd.device ok 18 /pci-controller/1d.0/0.0/ssd.driver ok 19 /pci-controller/1d.7/0.0/sdcard-reader.device ok 20 /pci-controller/1d.7/0.0/sdcard-reader.driver ok 21 /pci-controller/1f.3/audio.device ok 22 /pci-controller/1f.3/audio.driver Totals: pass:22 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by:
"Nícolas F. R. A. Prado" <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240122-discoverable-devs-ksft-v4-3-d602e1df4aa2@collabora.comSigned-off-by:
-
Nícolas F. R. A. Prado authored
Add a sample board file describing the file's format and with the list of devices expected to be probed on the google,spherion machine as an example. Test output: TAP version 13 Using board file: boards/google,spherion.yaml 1..8 ok 1 /usb2-controller@11200000/1.4.1/camera.device ok 2 /usb2-controller@11200000/1.4.1/camera.0.driver ok 3 /usb2-controller@11200000/1.4.1/camera.1.driver ok 4 /usb2-controller@11200000/1.4.2/bluetooth.device ok 5 /usb2-controller@11200000/1.4.2/bluetooth.0.driver ok 6 /usb2-controller@11200000/1.4.2/bluetooth.1.driver ok 7 /pci-controller@11230000/0.0/0.0/wifi.device ok 8 /pci-controller@11230000/0.0/0.0/wifi.driver Totals: pass:8 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by:
-
Nícolas F. R. A. Prado authored
Add a new test to verify that a list of expected devices from discoverable buses (ie USB, PCI) have been successfully instantiated and probed by a driver. The per-platform list of expected devices is selected from the ones under the boards/ directory based on the DT compatible or the DMI IDs. Signed-off-by:
-
RD Babiera authored
Implement active cable VDM support for SOP' according to the DisplayPort Alt Mode 2.0 specification. When probing the DisplayPort driver, the state machine will transition to Enter Mode on SOP' if an active cable altmode is detected. The SVDM flow is as followed: (1) Enter Mode SOP' (2) Enter Mode SOP (3) Status Update SOP (4) Configure SOP' (5) Configure SOP Status Update on SOP' after Enter Mode is optional and not implemented for now. When exiting the alt mode, send Exit Mode over SOP' after SOP. Should an altmode vdm fail on SOP', the DisplayPort driver will drop its reference to the plug and attempt to continue in SOP operation. Add new dp_state enums DP_STATE_ENTER_PRIME, DP_STATE_CONFIGURE_PRIME, and DP_STATE_EXIT_PRIME. dp_altmode adds typec_displayport_data for the cable plug to store the plug configuration and adds a typec_altmode reference for the cable plug. dp_altmode_configure takes the cable pin assignment capabilities into account when deciding on pin configuration. dp_altmode_configure_vdm_cable sends the configure message on SOP'. dp_altmode_activate now attempts to enter on SOP' if applicable, and will attempt to enter on SOP on failure. dp_cable_altmode_vdm handles VDMs passed to the DisplayPort driver from the tcpm. Signed-off-by:RD Babiera <rdbabiera@google.com> Link: https://lore.kernel.org/r/20240108191620.987785-26-rdbabiera@google.comSigned-off-by:
-
RD Babiera authored
Add tcpm_cable_ops for enter, exit, and vdm to the tcpm, which are registered after registering port alt modes through typec_port_register_cable_ops. Enter Mode on SOP' now sends Exit Mode upon failure to report to the driver. tcpm_queue_vdm_unlocked now takes sop type as input. Proper adev_actions in tcpm_pd_svdm are selected for SOP' messages. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240108191620.987785-25-rdbabiera@google.comSigned-off-by:
-
RD Babiera authored
Adds Discover SVIDs and Discover Modes support for SOP' and Alt Mode SVDM support over SOP'. tcpm_port adds separate Alt Mode data for SOP'. svdm_consume_svids and svdm_consume_modes take the received SVDM's SOP* type to store svids/modes separately, and tcpm_register_plug_altmodes registers the active cable's alt modes. In tcpm_pd_svdm, the port will send Discover SVIDs to SOP' after Discover Modes on SOP if the connected cable is an active cable. Discover Modes on SOP' is sent following Discover SVIDs on SOP. Registering partner alt modes is delayed when an active cable is present until Discover Modes completes on SOP', or if the Discover SVIDs/Discover Modes request on SOP' encounters a transmission error. Signed-off-by:
-
RD Babiera authored
Add SRC_VDM_IDENTITY_REQUEST state which first enters after SRC_STARTUP. The state sends Discover Identity on SOP' and transitions to SRC_SEND_CAPABILITIES. SRC_SEND_CAPABILITIES will transition back into SRC_VDM_IDENTITY_REQUEST instead of retrying immediately. Signed-off-by:
-
RD Babiera authored
Add data message handling and Discover Identity SVDM over SOP' This patch contains the following changes: 1. pd_vdo Add VDO indices for active and passive cables, documentation to reflect expected number of objects depending on PD Revision, and macro to indicate port parter is data host capable. 2. tcpm Add typec_cable and typec_plug to tcpm_port to maintain cable and plug information. tcpm_port also adds send_discover_prime to indicate that Discover Identity should be sent out of the ready state. tcpm_queue_vdm and tcpm_send_vdm now take the SOP* type when transmitting messages. tcpm_handle_vdm_request and tcpm_pd_svdm also use the SOP* type. tcpm_pd_svdm handles Discover Identity messages for SOP and SOP'. In the SOP case, the port uses tcpm_attempt_vconn_swap_discovery to determine if a Vconn swap is needed for cable communication. Otherwise, the port will send Discover Identity on SOP' if it can, or default to Discover SVIDs. svdm_consume_identity_sop_prime consumes the result of Discover Identity on SOP'. It fills out cable identity and description, and it registers the cable. The SOP' plug is registered as well. The VDM state machine is adjusted to construct messages based on the SOP* type. If a transmission error occurs after the max number of retries for Discover Identity over SOP', then the port will send Discover SVIDs over SOP. Signed-off-by: -
RD Babiera authored
Add attempt_vconn_swap_discovery callback to determine whether the TCPM should perform a Vconn swap following Discover Identity on SOP. The tcpci will return false unless chip level drivers implement the callback. Maxim based TCPCs will return true unless the last connection resulted in a Vconn Over Current Fault, which may be the result of the Vconn swap. In addition to the port resetting, the TCPCI will veto the next Vconn swap from occurring. Signed-off-by:
-
RD Babiera authored
Add tx_sop_type to tcpm_pd_send_control and rx_sop_type to tcpm_pd_ctrl_request. TCPC_TX_SOP is added to all pd_send_control calls, but TCPC_TX_SOP_PRIME is added to pd_send_control for a SOFT_RESET message sent after a Vconn swap that makes the Port the Vconn source. Likewise, tcpm_pd_ctrl_request resets the proper protocol layer depending on rx_sop_type for SOFT_RESET. VCONN_SWAP_TURN_ON_VCONN now moves to a new state, VCONN_SWAP_SEND_SOFT_RESET. This state sends SOFT_RESET over SOP' before transitioning to the ready state if applicable. It transitions after PD_T_VCONN_STABLE, definied in pd.h as the time required for Vconn to be on before transmitting messages. Signed-off-by:
-
RD Babiera authored
Add negotiated revision and tx/rx message ids to tcpm_port specific to SOP'. tx_sop_type is added to the tcpm_port to determine whether the current constructed message will be sent over SOP or SOP' if not sent immediately. tcpm_pd_rx_handler updates the received message ids. SOP* messages are not processed afterwards. The handler also calls tcpm_can_communicate_sop_prime to determine if a SOP' message is directed towards the port, and drops SOP' messages it should not respond to. tcpm_can_communicate_sop_prime is added as a helper to determine whether the port is capable of communicating over SOP' at a given moment. Being the Vconn source is a requirement in Power Delivery 3.0 but only a recommendation in Power Delviery 2.0. Because the port should ensure that the cable is powered before communication, always enforce the port is the Vconn source regardless of revision. Signed-off-by:
-
RD Babiera authored
tcpm_pd_receive adds the SOP type as a parameter, and passes it within the pd_rx_event struct for tcpm_pd_rx_handler to use. For now, the handler drops all SOP' messages. Maxim based tcpci drivers are capable of SOP' communication, so process_rx now takes the SOP type into account and passes the value to tcpm_pd_receive. tcpci_set_pd_rx now utilizes the cable_comm_capable flag to determine if TCPC_RX_DETECT_SOP1 should be added to the bitfield when enabling PD message reception. For all other consumers of tcpm_pd_receive, default the new field to TCPC_TX_SOP. Signed-off-by:
-
RD Babiera authored
Add cable_comm_capable to tcpci_data for tcpci drivers to indicate that the port tcpc is capable of communicating to cables over SOP. A corresponding tcpci callback tcpci_cable_comm_capable returns this value. The tcpm will primarily use this in later patches to determine if the port can transmit and receive SOP' messages. Maxim based tcpci drivers are capable of SOP' communication, so the cable_comm_capable flag is set to true. Signed-off-by:
-
RD Babiera authored
Add typec_cable_set_svdm_version and typec_get_cable_svdm version symbols. Cables can operate under a lower PD revision than the port partner, and the max SVDM version is tied to the PD revision. So, typec_cable maintains its own svdm_version. Add typec_altmode_get_cable_svdm_version to return the cable's negotiated svdm_version for altmode drivers to use. Signed-off-by:
-
RD Babiera authored
Add typec_cable_ops struct for enter, exit, and vdm. The struct is added to typec_altmode so port alt modes can have access to partner and cable specific callbacks, and alt mode drivers can specify operations over SOP' and SOP'' without modifying the existing API. typec_port_register_cable_ops is added as a new symbol for port drivers to use to register cable operations to their registered port alt modes. Signed-off-by:
-
Sean Anderson authored
If we enabled vbus, we need to balance that with a disable. Signed-off-by:
Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/20240123225111.1629405-5-sean.anderson@seco.comSigned-off-by:
-
Sean Anderson authored
Some USB controller drivers call otg_set_vbus when entering host or device mode. Implement this callback so that VBUS can be turned on and off automatically. This is especially useful when there is no property for a VBUS supply in the controller's binding. This results in a change in semantics of the vbus_draw regulator. Whereas before it represented the VBUS supplied by an A-Device when we acted as a B-Device, now it represents an internal VBUS source. Accordingly, we no longer set the current limit or enable/disable the bus from nop_gpio_vbus_thread. Because this supply was never initialized before the previous commit, there should be no change in behavior. Signed-off-by:
-
Sean Anderson authored
While support for working with a vbus was added, the regulator was never actually gotten (despite what was documented). Fix this by actually getting the supply from the device tree. Fixes: 7acc9973 ("usb: phy: generic: add vbus support") Signed-off-by:
-
Sean Anderson authored
The vbus-regulator property was never actually read from the device tree. Introduce a new property vbus-supply to represent the regulator powering the VBUS when acting as an A-Device. This supply will be enabled and disabled as necessary. Note that this is different from vbus-regulator, which represented the available current available to draw from VBUS in B-Device mode. Because no one was using vbus-regulator, remove it. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240123225111.1629405-2-sean.anderson@seco.comSigned-off-by:
-
AngeloGioacchino Del Regno authored
Add support for the ip-sleep wakeup functionality on the three MTU3 controllers found on the MT8195 SoC. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20240122111809.148546-2-angelogioacchino.delregno@collabora.comSigned-off-by:
-
AngeloGioacchino Del Regno authored
Of the four USB controllers present on the MediaTek MT8195 SoC, three of them (0, 2 and 3) are behind MTU3: add wakeup controls for them. Acked-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
-
Rob Herring authored
"usb-phy" has multiple type definitions. Unify the type with the looser definition, phandle-array, as there are cases with multiple entries (USB2 and USB3). However, the 'phandle-array' type alone is a bit ambiguous. It can be either just an array of phandles or an array of phandles plus args. "usb-phy" is the former and needs to constrain each entry to a single phandle value. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240124190725.1554080-1-robh@kernel.orgSigned-off-by:
-
Krzysztof Kozlowski authored
Several bindings implement parts of Type-C USB orientation and mode switching, and retiming. Keep definition of such properties in one place, new usb-switch schema, to avoid duplicate defines. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240122094406.32198-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Stanley Chang authored
In Realtek SoC, the parameter of usb phy is designed to can dynamic tuning base on port status. Therefore, add a notify callback of generic phy driver when usb device connect and disconnect change. The Realtek phy driver is designed to dynamically adjust disconnection level and calibrate phy parameters. When the device connected bit changes and when the disconnected bit changes, do connection change notification: Check if portstatus is USB_PORT_STAT_CONNECTION and portchange is USB_PORT_STAT_C_CONNECTION. 1. The device is connected, the driver lowers the disconnection level and calibrates the phy parameters. 2. The device disconnects, the driver increases the disconnect level and calibrates the phy parameters. Generic phy driver in usb core framework does not support device connect and disconnect notifications. Therefore, we add an api to notify phy the connection changes. Additionally, the generic phy only specifies primary_hcd in the original design. Added specific "usb2-phy" on primary_hcd and "usb3-phy" on shared_hcd. Signed-off-by:
Stanley Chang <stanley_chang@realtek.com> Link: https://lore.kernel.org/r/20231213031203.4911-4-stanley_chang@realtek.comSigned-off-by:
-
Stanley Chang authored
Realtek DHC (digital home center) RTD SoCs support DWC3 XHCI USB controller. Added the driver to drive the USB 3.0 PHY transceivers. Note: New driver, remove the port status notification on legacy USB PHY. Use the generic PHY to notify the usb device connect and disconnect. To avoid using these PHYs would require describing the very same PHY using both the generic "phy" property and the deprecated "usb-phy" property. Signed-off-by:
-
Stanley Chang authored
Realtek DHC (digital home center) RTD SoCs support DWC3 XHCI USB controller. Added the driver to drive the USB 2.0 PHY transceivers. Note: New driver,remove the port status notification on legacy USB PHY. Use the generic PHY to notify the usb device connect and disconnect. To avoid using these PHYs would require describing the very same PHY using both the generic "phy" property and the deprecated "usb-phy" property. Signed-off-by:
-
Stanley Chang authored
In Realtek SoC, the parameter of usb phy is designed to be able to do dynamic tuning based in the port status. Therefore, add a notify callback of phy driver when usb connection/disconnection change. Signed-off-by:
-
Niko Mauno authored
Make the default USB device authorization mode configurable at build time. This is useful for systems that require a mode that is stricter than the standard setting, as it avoids relying on the kernel command line being properly set. Signed-off-by:
Niko Mauno <niko.mauno@vaisala.com> Link: https://lore.kernel.org/r/20240105114956.30714-2-niko.mauno@vaisala.comSigned-off-by:
-
Niko Mauno authored
Since the wireless USB implementation has been removed and since the behavior with authorized_default values -1 and 1 is now effectively same, change the initial value to latter in order to stop using the leftover value. The former value can still be passed as a module parameter to retain backwards compatibility. Signed-off-by:
-
Elad Nachman authored
Add support for ac5 to the EHCI Orion platform driver. The ac5 SOC has DDR starting at offset 0x2_0000_0000, Hence it requires a larger than 32-bit DMA mask to operate. Move the dma mask to be pointed by the OF match data, and use that match data when initializng the DMA mask. Signed-off-by:
Elad Nachman <enachman@marvell.com> Link: https://lore.kernel.org/r/20240114172154.2622275-3-enachman@marvell.comSigned-off-by:
-
Elad Nachman authored
Add Marvell ac5 device tree bindings to generic EHCI. This compatible enables the Marvell Orion platform code to properly configure the DMA mask for the Marvell AC5 SOC. Signed-off-by:
-
Haotien Hsu authored
With the Cypress CCGx Type-C controller the following error is sometimes observed on boot: [ 16.087147] ucsi_ccg 1-0008: failed to reset PPM! [ 16.087319] ucsi_ccg 1-0008: PPM init failed (-110) When the above timeout occurs the following happens: 1. The function ucsi_reset_ppm() is called to reset UCSI controller. This function performs an async write to start reset and then polls for completion. 2. An interrupt occurs when the reset completes. In the interrupt handler, the OPM field in the INTR_REG is cleared and this clears the CCI data in the PPM. Hence, the reset completion status is cleared. 3. The function ucsi_reset_ppm() continues to poll for the reset completion, but has missed the reset completion event and eventually timeouts. In this patch, we store CCI when handling the interrupt and make reading after async write gets the correct value. To align with the CCGx UCSI interface guide, this patch updates the driver to copy CCI and MESSAGE_IN before they are reset when UCSI interrupt acknowledged. When a new command is sent, the driver will clear the old CCI to avoid ucsi_ccg_read() getting wrong CCI after ucsi_ccg_async_write() when the UCSI interrupt is not handled. Finally, acking the UCSI_READ_INT interrupt before calling complete() in ISR to ensure that the ucsi_ccg_sync_write() would wait for the interrupt handling to complete. Signed-off-by:
Sing-Han Chen <singhanc@nvidia.com> Signed-off-by:
Haotien Hsu <haotienh@nvidia.com> Reviewed-by:
-
Alexander Tsoy authored
This is likely a copy-paste error. Replace "Source" with "Selector" where appropriate. Fixes: 7e847894 ("linux/usb/audio.h: split header") Signed-off-by:
Alexander Tsoy <alexander@tsoy.me> Link: https://lore.kernel.org/r/20240125211635.30140-1-alexander@tsoy.meSigned-off-by:
-
Philipp Zabel authored
Use of_reset_control_array_get_optional_exclusive() instead, it is implemented as: static inline struct reset_control * of_reset_control_array_get_optional_exclusive(struct device_node *node) { return of_reset_control_array_get(node, false, true, true); } This makes the code easier to understand and removes the last remaining direct use of of_reset_control_array_get(). No functional changes. This change was made possible by commit f4cc91dd ("usb: dwc3: of-simple: remove Amlogic GXL and AXG compatibles"), which made the parameters passed to of_reset_control_array_get() constant. Signed-off-by:Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20240125-dwc3-of-simple-reset-control-array-fix-v2-1-1ab6b52cad21@pengutronix.deSigned-off-by:
-
AngeloGioacchino Del Regno authored
The ITE IT5202 is a USB Type-C Alternate Mode Passive MUX, used for muxing the SBU lines of a Type-C port with DisplayPort altmode and also providing an orientation switch. Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
AngeloGioacchino Del Regno authored
Introduce a binding for the ITE IT5205 Alternate Mode Passive MUX, used for connecting, disconnecting and switching orientation and control the SBU signals for alternate modes on USB Type-C ports. Signed-off-by:
-
Karina Yankevich authored
In sddr55_{read|write}_data(), the address variables are needlessly typed as *unsigned long* -- which is 32-bit type on the 32-bit arches and 64-bit type on the 64-bit arches; those variables' value should fit into just 3 command bytes and consists of 10-bit block # (or at least the max block # seems to be 1023) and 4-/5-bit page # within a block, so 32-bit *unsigned* *int* type should be more than enough... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. [Sergey: rewrote the patch subject/description] Signed-off-by:Karina Yankevich <k.yankevich@omp.ru> Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/4c9485f2-0bfc-591b-bfe7-2059289b554e@omp.ruSigned-off-by:
-
