> > > > > According to USB_OTG_and_EH_2-0-final_plus_errata_and_ecn_20110714 - > final.pdf > > Chapter7.1, 7,2. The states at enum usb_otg_state are all OTG state. > > > > If you think others (except for A_DEVICE and B_HOST) are not otg- > specific states, > > then what are they? > > granted, they were defined on the OTG spec, but if you think about them, > every peripheral usb controller starts on B_IDLE state. > > The OTG spec also says that any device can start SRP and any host can > reply to that, not only OTG-capable devices; which means that B_SRP_INIT > also applies to any device. > > B_PERIPHERAL applies to any device which gets enumerated. > > B_WAIT_ACON also applies to any device; it's that small timeframe where > your device is ready and just waits for host. > > A_IDLE it's when your host is fully initialized but has no > devices attached to it. > > A_WAIT_VRISE and A_WAIT_VFALL is applicable to any hosts which can > control their charge pumps. > > A_WAIT_BCON is applicable to any host > > A_HOST is the normal operation of a host when it enumerated a device > > A_SUSPEND applies to any host. It's when it drives bus suspend > signalling on the bus > > A_VBUS_ERR is that state when you just caught overcurrent. >
So, the others are usb_state not usb_otg_state. Then, when we generalize otg driver, what kinds of **states** do you plan to use to stand for otg state machine? Besides, if we name something different with spec, does it will confuse the users? > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html