Hi Thinh, > On Mon, Aug 07, 2023, Stanley Chang[昌育德] wrote: > > Hi Thinh, > > > > > > > > > > +static int dwc3_rtk_setup_role_switch(struct dwc3_rtk > > > > > > > > +*rtk) > > > > > > > > > > > > > > Any reason why we're doing the role switch here and not > > > > > > > what's implemented from the core? > > > > > > > > > > > > > Because we have to set the usb 2.0 phy mode through > > > > > > switch_usb2_dr_mode > > > > > in the function dwc3_rtk_set_dr_mode. > > > > > > In fact, switch_dwc3_dr_mode will use the role switching > > > > > > implemented by > > > > > core. > > > > > > > > > > > > > > > > I don't think this is a good way to go about it. Do you (the > > > > > glue > > > > > driver) create a role switch structure and register to the same > > > > > role switch device that the dwc3 core would register later? I > > > > > did not expect that to work at all. > > > > > > > > > In our application, this role switch in the glue driver works fine. > > > > > > Is the order of operation between the switch from the core vs the > > > glue determinate? Also, which operation should happen first? It's > > > not clear how you handle it here. > > > > We have a type c driver that first calls role switch in glue. > > The role switching function in glue will call the role switching function in > core. > > How do we know that? You're registering to the same switch device, wouldn't > the switch event notify the switch work in both the glue and the core? Perhaps > I'm missing something here, but is there some mechanism that waits for the > switch work from the glue to complete before the core. First, the switches in glue and core are different devices. In the type-c driver, we only notify the switch in the glue. Then, the switch in the glue calls the switch in the core to change roles. This is a sequential process. So there is no order problem. Thanks, Stanley
