RE: [PATCH v2 0/3] Some update for USB OTG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 
> >
> > > > >
> > > > > Hi Felipe,
> > > > >
> > > > > Two for fsm, the other one is to delete CONFIG_USB_OTG_FSM since
> > > > > it is duplicated with CONFIG_USB_OTG, thanks.
> > > > >
> > > > > Change on v1:
> > > > > Remove "{}" for a single statement in patch:
> > > > > usb: phy-fsm: update OTG HNP state transition.
> > > > >
> > > > > Li Jun (1):
> > > > >   usb: phy-fsm: update OTG HNP state transition
> > > > >
> > > > > Peter Chen (2):
> > > > >   usb: phy: delete CONFIG_USB_OTG_FSM
> > > > >   usb: phy-fsm: change "|" to "||" for condition
> > > OTG_STATE_A_WAIT_BCON
> > > > >     at statemachine
> > > > >
> > > > >  drivers/usb/phy/Kconfig       |   11 +----------
> > > > >  drivers/usb/phy/Makefile      |    2 +-
> > > > >  drivers/usb/phy/phy-fsm-usb.c |    9 +++++----
> > > > >  3 files changed, 7 insertions(+), 15 deletions(-)
> > > > >
> > > > > --
> > > > > 1.7.9.5
> > > > >
> > > > >
> > > >
> > > > Hi Felipe,
> > > >
> > > > Would you give some comments for this patchset please? For the
> > > > patch
> > > > "usb: phy: delete CONFIG_USB_OTG_FSM", I sent it more than two
> > > > months ago, I need to know your comments if it can be accepted or
> > > > not, we are working on OTG FSM patchset for chipidea, and it is
> > > > close to review process, we need to know if we can use
> > > > CONFIG_USB_OTG_FSM to cover OTG
> > > > (fsm) code, or just CONFIG_USB_OTG is ok, thanks.
> > >
> > > I know you've sent this a long time ago and I've been banging my
> > > head ever since trying to decide if we should delete OTG FSM or not.
> > > On the one hand the OTG is pretty generic and aparently everybody
> > > would benefit from it but on the other hand we might have HW which
> > > implements the state machine without much SW control - though I
> > > can't remind of any good examples.
> > >
> > > 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.
- 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".

P.S: The two other patches in this patchset are bug fixes, help queue it please.

Thanks,
Peter
--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux