Hi, On Thu, Apr 24, 2014 at 09:37:32AM +0000, Peter Chen wrote: <snip> > > > > Also, I think most of that code should be agnostic of the PHY layer > > > > and sit in usb-common.c. Quite frankly, OTG shouldn't depend on the > > > > PHY at all, we could very well have implementations which need/have > > > > no SW control over the PHY and still be fully OTG compliant. > > > > > > > > > > Thanks, I agreed with you too long time ago that otg should not be > > > related to PHY. > > > One more thing, I think we should move out otg staff from phy/, and > > > have a new folder named otg, if you agree with it, I can do it. > > > > I think we can move code to usb-common/usb-otg.c or usb-otg-fsm.c or > > whatever. Just make sure to build it only if CONFIG_USB_OTG is enabled. > > > > Hi Felipe, > > I am trying to move out usb otg things from phy folder, but still have some > concerns for it. > > - There is no usb-common folder, only usb-common.c, if I move usb otg > things in usb-common.c, this file looks large (~500 lines), I wonder > if we can create a folder named usb-common, and put usb-common.c and > usb-otg.c in it. sounds like a good approach to me, but Greg will have the final answer > - Since the CONFIG_USB_OTG_FSM still exists, when the user goes to > configure kernel, he will see two configurations at menu, one is "USB > 2.0 OTG FSM implementation" and the other is "OTG support". hmm... I see... There might be people who want to use OTG helpers but not the generic FSM. MUSB, for instance, implements the OTG state machine completely in HW. > P.S: The two other patches in this patchset are bug fixes, help queue > it please. will do. -- balbi
Attachment:
signature.asc
Description: Digital signature
