mjhammel

I think so, but I'm not experienced with the callback/notification methods enough to be clear on that. It uses pm_runtime_*() functions to deal with it, I believe. I did that this morning and, while dwc3-rockchip.c in both are very similar, there are many differences that are not just kernel version related. The processing in various functions is different. I'm going to try to port Ayufan's dwc3-rockchip.c to 5.15.14 and see if that works better - there are only a few API changes I think. The drivers/mfd/fusb302.c is also similar, but very different. These all have the same copyright block at the top but it doesn't tell me which is newer or where they might have a common ancestor. You could manage that in software with a UI that swaps a DT overlay. But it's basically just a software solution to the hardware switch. Also, with kexec, you could reboot with a new DT without a hardware reset, but it's still a kernel reboot. I'm able to switch modes (not that the modes work, but I can switch them) using debugfs instead of sysfs. It's unclear to me how bad it would be to have debugfs mounted on a production system. Might expose things you don't want exposed. I suspose you could move the mode debugfs file to sysfs - you're basically just exposing a function call but it would probably be the same (or the same with a different wrapper for the API) for both.

First, thanks for the tips. It's good to have someone to boune ideas off of. The extcon is the physical port (re: "external connection"), in this case a Typc-C connector on our board. It notifies the phy core that then initiates the callback to the workqueue in the dwc3-rockchip driver. At least that's my understanding. You have to reference the extcon in the usbdrd3 proprerty, which is the rockchip dwc3 driver (the dwc3-simple driver doesn't directly reference an extcon), so it can attach the extcon to the phy. But apparently you also need to attach it to the tcphy0 property, or so it seems based on some other DTS examples. It's very confusing. The extcon driver in this case is fusb302. There is one of those under drivers/usb/typec/tcpm that comes from Google. But that doesn't seem to work no matter what I do with its dts config. So I forward ported the fusb302 driver from the BSP, which comes from rockchip. With some added debug I can see connection events and the callback to the workqueue function. Turns out my version of that patch came later and does not have the call to dwc3_phy_setup() - which is why my port compiled without the core.c/h patch. Of course, that may also be the reason it doesn't work. I ported it from a 4.4 kernel. The ayufan-rock64 kernel is not something I can drop on this device. We're bumped to 5.15.14 (upstream release + custom patches, most if not all are from the net) at the moment and it's tied to the specific u-boot we have. It also probably wouldn't support our display, though I have a serial console so maybe that doesn't matter. My changes are simple, really. They consist of choosing a fusb302 driver: Google's (CONFIG_TYPEC_FUSB302, plus some other typec drivers which I think are required) or Rockchips (CONFIG_FUSB_30X, which is part of my port and is standalone) a dwc3-* driver: dwc3-of-simple (aka CONFIG_USB_DWC3_OF_SIMPLE) or dwc3-rockchip (CONFIG_USB_DWC3_ROCKCHIP, which I've added to the Kconfig). We run as an embedded board so nearly everything is statically compiled, but I make the fusb driver a module and manually load it after boot. This way if any of the drivers lock up it won't happen until the fusb is loaded and I plug something in (or left something plugged in from the last test). Then the DTS is updated to match those selections. There are a few places that this matters. Note that what follows is what I have, but it obviously isn't working. When using the stock drivers (Google fusb302, dwc3-of-simple), it looks like this: &i2c4 { status = "okay"; fusb0: fusb30x@22 { // Google fusb compatible = "fcs,fusb302"; fcs,int_n = <&gpio1 2 GPIO_ACTIVE_HIGH>; interrupt-parent = <&gpio1>; interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; vbus-supply = <&vcc5v0_typec0>; status = "okay"; connector { compatible = "usb-c-connector"; data-role = "dual"; label = "USB-C"; op-sink-microwatt = <1000000>; power-role = "dual"; sink-pdos = <PDO_FIXED(5000, 2500, PDO_FIXED_USB_COMM)>; source-pdos = <PDO_FIXED(5000, 1400, PDO_FIXED_USB_COMM)>; try-power-role = "sink"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; usbc_hs: endpoint { remote-endpoint = <&u2phy0_typec_hs>; }; }; port@1 { reg = <1>; usbc_ss: endpoint { remote-endpoint = <&tcphy0_typec_ss>; }; }; }; }; }; }; &u2phy0 { status = "okay"; extcon = <&fusb0>; // otg-vbus-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; u2phy0_otg: otg-port { // phy-supply = <&vcc5v0_typec0>; status = "okay"; }; u2phy0_host: host-port { phy-supply = <&vcc5v0_typec0>; status = "okay"; }; port { u2phy0_typec_hs: endpoint { remote-endpoint = <&usbc_hs>; }; }; }; &usbdrd3_0 { status = "okay"; }; &usbdrd_dwc3_0 { status = "okay"; dr_mode = "peripheral"; }; &tcphy0 { status = "okay"; extcon = <&fusb0>; }; &tcphy0_usb3 { status = "okay"; extcon = <&fusb0>; port { tcphy0_typec_ss: endpoint { remote-endpoint = <&usbc_ss>; }; }; }; When using the Rockchip fusb302 and dwc3 driver it looks like this: &i2c4 { status = "okay"; fusb0: fusb30x@22 { compatible = "fairchild,fusb302"; vbus-5v-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>; int-n-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; fusb302,role = "ROLE_MODE_DRP"; fusb302,try_role = "ROLE_MODE_DRP"; reg = <0x22>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; status = "okay"; }; }; &u2phy0 { status = "okay"; otg-vbus-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; u2phy0_otg: otg-port { status = "okay"; }; u2phy0_host: host-port { phy-supply = <&vcc5v0_typec0>; status = "disabled"; }; }; &usbdrd3_0 { status = "okay"; extcon = <&fusb0>; }; &usbdrd_dwc3_0 { status = "okay"; extcon = <&fusb0>; dr_mode = "otg"; /* USB 3.0 */ maximum-speed = "super-speed"; phys = <&tcphy0_usb3>; phy-names = "usb3-phy"; }; &tcphy0 { status = "okay"; extcon = <&fusb0>; resets = <&cru SRST_UPHY0>, <&cru SRST_UPHY0_PIPE_L00>, <&cru SRST_P_UPHY0_TCPHY>, <&cru SRST_A_USB3_OTG0>; reset-names = "uphy", "uphy-pipe", "uphy-tcphy", "usb3-otg"; }; &tcphy0_usb3 { status = "okay"; }; I'll try adding that dwc3_phy_setup() call just for grins to see what happens. But I'm not sure it matters if I try to boot in peripheral mode to start with. I think it only matters if I'm trying to use OTG. I'm trying to use peripheral mode only right now just to get device mode working in any way possible (but preferrably at least at HS).

The one I found is here: https://patchwork.kernel.org/project/linux-rockchip/patch/1471251284-1804-1-git-send-email-william.wu@rock-chips.com/ I can probably handle the data sheets but I don't have them, nor do I have the understanding of how the usb upstream expects drivers to be written. The GPIO ISR you mention might use a debugfs/sysfs interface to switch modes. I don't know of a way to do it via sysfs, but the dwc3 drivers have some debugfs mode files that allow it. That said, when I tried using those the system locked and/or rebooted. The issue seems to be with the workqueue item (from the ported BSP driver) that handles the switching - it needs to reset the dwc3 controller and (I think) restart everything. But that seems not to work or maybe it works partly but takes too long while trying to run in a workqueue item. I can tell roughly where the problem is but not why it's happening. The stock dwc3 driver (dwc3-of-simple) doesn't do any of that and thus doesn't seem to support dynamic mode switching. At least as far as I can tell. I'm still experimenting with it. Right now I'm just trying to get back to USB2 HS gadget-devices working. It's a magic incantation of DTS and driver selection whose page is missing from my book of spells. Oh, one thing I do seem to remember from when it worked was: don't over use the DTS. There are lots of possible configurations you can add to the tcphy0 and usbdrd properties but, if I recall correctly, it was best not to use them. So that's what I'm working on now.

I've been working this problem for quite some time for an rk3399 based board we're developing. I need peripheral mode at SS for video/audio gadgets but also need Host mode (probably at any speed) for factory work though we can probably live without host mode. The fix you have above appears to be just a slight variation of what already exists for default rk3399.dtsi. Only the "snps,xhci-slow-suspend-quirk" seems to be new. It didn't have an affect on my testing. My use case requires USB3 OTG or peripheral mode over Type-C. The existing type-c driver, fusb302, does not work at all, as far as I can tell. I've have had no luck getting it to work with either the stock dwc3-of-simple driver of a the (see below) ported rockchip dwc driver. I forward ported both the fusb302.c driver and the associated dwc3-rockchip.c driver from Rockchip's BSP to 5.15.14.. These act better but still don't work. More importantly, you can't set the mode to OTG in the DTS and then try to switch between host and peripheral modes. There are bugs in the dwc3-rockhip.c driver that cause the workqueue to timeout and the system to reboot. I haven't figured out why that is - possibly the workqueue takes too long or, more likely, there is some kind of memory stomping going on. The best you can do is set the mode to peripheral and just stay there. But even that doesn't seem to work to allow the rk3399 to act as a storage device (which is what I use to test this because it's the easiest to setup). At least not consistently. I have seen the ported drivers work in USB2 HS mode and at one point I managed to get the storage device to be seen at SS, but I don't know how I did it, it didn't stay stable on the host side, and I have not been able to repeat it. The BSP driver was rejected by the upstream USB developers back in 2016, so this path is just to make it work. It would never make into the upstream. I've noticed there is a hw switch on the RockPi4 for OTG vs Host mode. I suspect they use that to load a different overlay at boot time. It's a neat trick. I don't know what drivers or DTS config they're using. If anyone has additional information that might help getting the stock drivers or the ported drivers working, at a minimum as a peripheral at SS speed, let me know. Thanks.