Hi,
On Fri, Aug 19, 2011 at 03:30:51PM +0300, Heikki Krogerus wrote:
> On Fri, Aug 19, 2011 at 02:46:04PM +0300, Felipe Balbi wrote:
> > Hi,
> >
> > (review the typos)
> >
> > On Tue, Aug 16, 2011 at 01:09:32PM +0300, Heikki Krogerus wrote:
> > > diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
> > > index 6692df8..309f45c 100644
> > > --- a/include/linux/usb/otg.h
> > > +++ b/include/linux/usb/otg.h
> > > @@ -48,11 +48,36 @@ struct usb_transceiver;
> > > /* for transceivers connected thru an ULPI interface, the user must
> > > * provide access ops
> > > */
> > > -struct otg_io_access_ops {
> > > +struct usb_phy_io_ops {
> > > int (*read)(struct usb_transceiver *x, u32 reg);
> > > int (*write)(struct usb_transceiver *x, u32 val, u32 reg);
> > > };
> > >
> > > +struct otg {
> > > + u8 default_a;
> > > + enum usb_otg_state state;
> >
> > state isn't OTG specific. Only A_DEVICE and B_HOST are OTG-related, I
> > guess. the others can be used in host-only (A_*) and device-only (B_*)
> > modes.
> >
> > I think it's better to keep state on struct usb_transceiver but WARN()
> > if you get B_HOST or A_DEVICE on non-OTG configurations.
>
> Well, my final goal is to introduce the generic otg state machine, and
> the plan was to not allow the drivers to even see the state. I would
> prefer to keep it in otg. I think the UDC drivers except musb do not
> care about the state, and musb has basically the otg support embedded
> in the driver. What do you think?
Like I said, the state is not OTG-specific. And knowing the state we
are, might be interesting at least for debugging, but also we might need
to know which state the transceiver is to take certain decisions.
--
balbi
Attachment:
signature.asc
Description: Digital signature
