RE: [PATCH v2 1/2] usb: dwc3: add Realtek DHC RTD SoC dwc3 glue layer driver

[Stanley Chang[昌育德]]

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