> > >
> > > > struct twl6030_usb {
> > > > > > > + struct usb_phy phy;
> > > > > > > + struct usb_otg otg;
> > >
> > > struct usb_otg {
> > > unsigned otg_specific;
> > >
> > > >
> > > struct otg_phy {
> > > unsigned phy_specific;
> > > }
> > >
> > > Besides, for some SoCs, there is no otg driver at mainline until now,
> but
> > > they need to get usb_phy.
> >
> > the thing is that OTG adds a few extra bits and pieces to the PHY. For
> > example we have extra states on the USB state machine, we have a few
> > analog comparators (for VBUS and ID pin) and so on. So, when we _do_
> > have OTG, some of it is handled by the PHY.
>
Felipe, I still not understand why it needs struct otg in struct usb_phy.
At vendor's otg driver, the usb_phy is in vendor's otg struct, like above struct twl6030_usb.
We can get line states (ID,DP/DM,VBUS) from the PHY, and we can update OTG status
according to PHY's status.
> One more question before I make the v9. If you have two PHYs but only
> one of the is OTG, how do you make sure the other PHY driver can not
> take advantage of OTG utility?
>
> Peter, didn't you say that this is what you guys have, two
> transceivers and only one of them is OTG?
>
> --
> heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
