Integrate linux-seco-rk/seco_5.10.110_c31_typec_dp
Commit: edgehog/bsp/rockchip/linux-seco-rk@3a2e59b4
[UPSTREAM] usb: dwc3: gadget: Remove invalid low-speed setting
Commit: 0c59f678fcfc6dd53ba493915794636a230bc4cc Authored-by: Thinh Nguyen Thinh.Nguyen@synopsys.com Date: Thu, 11 Mar 2021 16:58:50 -0800
None of the DWC_usb3x IPs (and all their versions) supports low-speed setting in device mode. In the early days, our "Early Adopter Edition" DWC_usb3 databook shows that the controller may be configured to operate in low-speed, but it was revised on release. Let's remove this invalid speed setting to avoid any confusion.
link: https://github.com/torvalds/linux/commit/0c59f678fcfc6dd53ba493915794636a230bc4cc
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@6499dee2
[DRIVERS] usb: dwc3: core: Apply patch: disable 3.0 clock when operating in 2.0 device mode
Authored-by: Piyush Mehta piyush.mehta@amd.com
The GUCTL1.DEV_FORCE_20_CLK_FOR_30_CLK bit enable the feature of internal 2.0(utmi/ulpi) clock to be routed as the 3.0 (pipe) clock. This feature is applicable when core is operating in 2.0 device mode.
When this bit is set in host mode and core is in 2.0 device mode (maximum speed = high-speed) then usb super speed devices not detected on host.
To address the above issue added usb device mode conditional check.
Add also DWC3 version 2.90a check(from upstream), that was probably lost by mistake.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@e8b8b08c
[UPSTREAM] Revert "usb: dwc3: core: Enable AutoRetry feature in the controller"
Commit: 734ae15ab95a18d3d425fc9cb38b7a627d786f08 Authored-by: Jakub Vanek linuxtardis@gmail.com Date: Fri, 14 Jul 2023 14:24:19 +0200
This reverts commit b138e23d3dff90c0494925b4c1874227b81bddf7.
AutoRetry has been found to sometimes cause controller freezes when communicating with buggy USB devices.
This controller feature allows the controller in host mode to send non-terminating/burst retry ACKs instead of terminating retry ACKs to devices when a transaction error (CRC error or overflow) occurs.
Unfortunately, if the USB device continues to respond with a CRC error, the controller will not complete endpoint-related commands while it keeps trying to auto-retry. [3] The xHCI driver will notice this once it tries to abort the transfer using a Stop Endpoint command and does not receive a completion in time. [1] This situation is reported to dmesg:
[sda] tag#29 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [sda] tag#29 CDB: opcode=0x28 28 00 00 69 42 80 00 00 48 00 xhci-hcd: xHCI host not responding to stop endpoint command xhci-hcd: xHCI host controller not responding, assume dead xhci-hcd: HC died; cleaning up
Some users observed this problem on an Odroid HC2 with the JMS578 USB3-to-SATA bridge. The issue can be triggered by starting a read-heavy workload on an attached SSD. After a while, the host controller would die and the SSD would disappear from the system. [1]
Further analysis by Synopsys determined that controller revisions other than the one in Odroid HC2 are also affected by this. The recommended solution was to disable AutoRetry altogether. This change does not have a noticeable performance impact. [2]
Revert the enablement commit. This will keep the AutoRetry bit in the default state configured during SoC design [2].
Fixes: b138e23d3dff ("usb: dwc3: core: Enable AutoRetry feature in the controller") Link: https://lore.kernel.org/r/a21f34c04632d250cd0a78c7c6f4a1c9c7a43142.camel@gmail.com/ [1] Link: https://lore.kernel.org/r/20230711214834.kyr6ulync32d4ktk@synopsys.com/ [2] Link: https://lore.kernel.org/r/20230712225518.2smu7wse6djc7l5o@synopsys.com/ [3]
Commit link: https://github.com/torvalds/linux/commit/734ae15ab95a18d3d425fc9cb38b7a627d786f08
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@9ab810b0
[DRIVERS] phy-rockchip-inno-usb2: Get VBUS regulator from CC logic chip
In case of Type-C port, when vbus regulator is already owned by CC logic controller, try to get its device node via remote endpoint, if any, and then its regulator to enable/disable when necessary, but without passing regulator to the driver data.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@a5792adb
[DRIVERS] fusb302: Add get_vbus_regulator function
A regulator should have one consumer to get possibility of being enabled/disabled , so in case of type-c, CC logic controller (fusb302) should be the only consumer of vbus regulator, otherwise it won't be disabled/enabled when necessary (depending on type of the attachment: device or host). But rockchip-usb2phy driver in OTG mode is looking for a vbus regulator as well, in this case vbus should be shared without incrementing consumer counter (without passing regulator to the driver data).
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@622eb400
[DRIVERS] cdn-dp: Call phy_init from driver probe function
In the phy_init function bus_width is set and we check whether the type-c port is already registered and then Altmode is entered in the active state, otherwise try probing driver again later.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@866305a1
[DRIVERS] phy-rockchip-typec: Add init to PHY ops functions for DP
The CDN DP controller driver is probed quite early on startup and we need to issue -EPROBE_DEFER to re-probe this driver when the Type-C port is registered and then Altmode is entered in the active state. Also we need to set bus_width, because cdn-dp driver will try to get the lane number by calling phy_get_bus_width.
Add the init function to phy ops and handle the things described above, then call phy_init from the cdn-dp driver probe function.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@d5b0be79
[DRIVERS] phy-rockchip-typec: Get mode from type-c port when extcon is NULL
When there is no extcon try to get mode from the type-c port.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@471c4e48
[DRIVERS] usb:class: Add function to get USB Type-C port Altmode state
Add function to get state of Altmode for Type-C port, it can be useful when, for example, a CC logic controller driver does not register the extcon device with its get/set state functions to use.
Introduce the bool variable typec_altmode_entered into the typec_port structure to save the current Altmode been entered/exited when updated
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@fb8ec01f
[DRIVERS] usb:class: Add functions to get USB Type-C port power/data role
Add functions to get a current power/data role for type-c port, it can be useful when, for example, a CC logic controller driver does not register the extcon device with its get/set state functions to use.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@860130dd
[DRIVERS] phy-rockchip-typec: Add set_mode to PHY ops functions
in case the CC logic controller does not register an extcon device, instead to use the only mode - MODE_DFP_USB, we can get a mode set by USB driver when it's too early to get mode from typec_port, because it's not still registered.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@eef4a329
[DRIVERS] usb: dwc3: Add dwc3_core_default_mode for SoC RK3399
Since rockchip,rk3399-typec-phy is still looking for extcon to get mode, but the CC logic controller no longer registers the extcon device we need to get a mode somehow before dwc3_core_init calls phy_power_on, so as a workaround set the default mode from the dwc3 core driver only for the RK3399 SoC.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@48d2a970
[DRIVERS] phy-rockchip-typec: Add tcphy_get_typec_port
Try to get type-c port by remote endpoint if any. In case when CC logic controller driver does not register extcon device, there is no extcon_set/get logic, and when we need to get a mode (DFP/UFP/DP) we need to get typec_port.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@47b76075
[DRIVERS] tcpm: Add function to get type-c port
Add function that gives the possibility to access typec_port, this is useful when we need to get the data role and power role, for example.
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@79e6b5ad
[DRIVERS] fusb302: Add function to get TCPM port
Added function that gives the possibility to access tcpm_port, registered from the CC logic controller driver.
this then will give access to typec_port and is useful when we need to get the data role and power role
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@332f6bd2
[UPSTREAM] usb: dwc3: Fix default mode initialization
Commit: 10d510abd096d620b9fda2dd3e0047c5efc4ad2b Authored-by: Alexander Stein alexander.stein@ew.tq-group.com Date: Wed, 25 Oct 2023 11:51:10 +0200
The default mode, configurable by DT, shall be set before usb role switch driver is registered. Otherwise there is a race between default mode and mode set by usb role switch driver. Link: https://github.com/torvalds/linux/commit/10d510abd096d620b9fda2dd3e0047c5efc4ad2b
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@679c6cf7
[UPSTREAM] usb: dwc3: Try usb-role-switch first in dwc3_drd_init
Commit: ab7aa2866d295438dc60522f85c5421c6b4f1507 Authored-by: Sven Peter sven@svenpeter.dev Date: Mon, 11 Apr 2022 17:53:00 +0200
If the PHY controller node has a "port" dwc3 tries to find an extcon device even when "usb-role-switch" is present. This happens because dwc3_get_extcon() sees that "port" node and then calls extcon_find_edev_by_node() which will always return EPROBE_DEFER in that case.
On the other hand, even if an extcon was present and dwc3_get_extcon() was successful it would still be ignored in favor of "usb-role-switch".
Let's just first check if "usb-role-switch" is configured in the device tree and directly use it instead and only try to look for an extcon device otherwise. Link: https://github.com/torvalds/linux/commit/ab7aa2866d295438dc60522f85c5421c6b4f1507
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@d5ac0ca4
[UPSTREAM] usb: dwc3: Remove DWC3 locking during gadget suspend/resume
Commit: 5265397f94424eaea596026fd34dc7acf474dcec Authored-by: Wesley Cheng quic_wcheng@quicinc.com Date: Thu, 1 Sep 2022 12:36:22 -0700
Remove the need for making dwc3_gadget_suspend() and dwc3_gadget_resume() to be called in a spinlock, as dwc3_gadget_run_stop() could potentially take some time to complete. Link: https://github.com/torvalds/linux/commit/5265397f94424eaea596026fd34dc7acf474dcec
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@19cb56c3
[BACKPORT] usb: dwc3: Soft reset phy on probe for host
Commit: 8bea147dfdf823eaa8d3baeccc7aeb041b41944b Authored-by: Thinh Nguyen Thinh.Nguyen@synopsys.com Date: Wed, 13 Sep 2023 00:52:15 +0000
When there's phy initialization, we need to initiate a soft-reset sequence. That's done through USBCMD.HCRST in the xHCI driver and its initialization, However, the dwc3 driver may modify core configs before the soft-reset. This may result in some connection instability. So, ensure the phy is ready before the controller updates the GCTL.PRTCAPDIR or other settings by issuing phy soft-reset.
Note that some host-mode configurations may not expose device registers to initiate the controller soft-reset (via DCTL.CoreSftRst). So we reset through GUSB3PIPECTL and GUSB2PHYCFG instead. Link: https://github.com/torvalds/linux/commit/8bea147dfdf823eaa8d3baeccc7aeb041b41944b
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@60efaa09
[UPSTREAM] usb: dwc3: core: Fix tx/rx threshold settings
From f28ad9069363dec7deb88032b70612755eed9ee6 Authored-by: Thinh Nguyen Thinh.Nguyen@synopsys.com Date: Mon, 11 Apr 2022 18:33:47 -0700
The current driver logic checks against 0 to determine whether the periodic tx/rx threshold settings are set, but we may get bogus values from uninitialized variables if no device property is set. Properly default these variables to 0.
Link: https://github.com/torvalds/linux/commit/f28ad9069363dec7deb88032b70612755eed9ee6
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@4f8c65af
[BACKPORT] usb: dwc3: core: Only handle soft-reset in DCTL
Commit: f4fd84ae0765a80494b28c43b756a95100351a94 Authored-by: Thinh Nguyen Thinh.Nguyen@synopsys.com Date: Thu, 21 Apr 2022 19:33:56 -0700
Make sure not to set run_stop bit or link state change request while initiating soft-reset. Register read-modify-write operation may unintentionally start the controller before the initialization completes with its previous DCTL value, which can cause initialization failure.
Link: https://github.com/torvalds/linux/commit/f4fd84ae0765a80494b28c43b756a95100351a94
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@5d9d5aac
[UPSTREAM] usb: dwc3: Fix bare use of unsigned checkpatch warning
Commit: ca80ca61863f70df1eb055bcccb302013d2d6308 Authored-by:: Kushagra Verma kushagra765@outlook.com Date: Fri, 20 May 2022 17:40:45 +0530
Fixes the bare use of unsigned warning from checkpatch.pl in core.c by changing 'unsigned' to 'unsigned int'.
Link: https://github.com/torvalds/linux/commit/ca80ca61863f70df1eb055bcccb302013d2d6308
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@0d7c3fe8
[UPSTREAM] usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode
Commit: 62c73bfea048e66168df09da6d3e4510ecda40bb Authored-by: Sven Peter sven@svenpeter.dev Date: Mon, 28 Nov 2022 17:15:26 +0100
dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen:
CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work);
CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags);
CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags);
CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc);
We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Link: https://github.com/torvalds/linux/commit/62c73bfea048e66168df09da6d3e4510ecda40bb
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@54e530a7
[UPSTREAM] usb: dwc3: core: Do not perform GCTL_CORE_SOFTRESET during bootup
commit: 07903626d98853e605fe63e5ce149f1b7314bbea Date: Thu, 14 Jul 2022 10:26:25 +0530
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.
Authored-by: Rohith Kollalsi quic_rkollals@quicinc.com Link: https://github.com/torvalds/linux/commit/07903626d98853e605fe63e5ce149f1b7314bbea
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@73fc6fb8
[UPSTREAM] usb: dwc3: core: Deprecate GCTL.CORESOFTRESET
commit: afbd04e66e5d16ca3c7ea2e3c56eca25558eacf3 From: Thinh Nguyen Thinh.Nguyen@synopsys.com Date: Wed, 15 Jun 2022 17:24:32 -0700
Synopsys IP DWC_usb32 and DWC_usb31 version 1.90a and above deprecated GCTL.CORESOFTRESET. The DRD mode switching flow is updated to remove the GCTL soft reset. Add version checks to prevent using deprecated setting in mode switching flow.
Authored-by: Thinh Nguyen Thinh.Nguyen@synopsys.com link: https://github.com/torvalds/linux/commit/afbd04e66e5d16ca3c7ea2e3c56eca25558eacf3
--
Commit: edgehog/bsp/rockchip/linux-seco-rk@95796f42
[DRIVERS] displayport: Check for a possible NULL pointer in probe function
typec_altmode_get_partner can return NULL in the driver's probe function and a check for a possible NULL pointer is needed before accessing it.