>
> They might need to be changed. It does seems like a bad idea to tell
> the gadget driver that a disconnect occurred before the host knows
> about it.
>
Yes, it should pull down dp first, then, tell class driver, it has
been disconnected.
> If you change the order of those two calls, does that
On Sun, 8 Jul 2012, Kevin Cernekee wrote:
> On Sun, Jul 8, 2012 at 5:33 PM, Alan Stern wrote:
> > On Sun, 8 Jul 2012, Kevin Cernekee wrote:
> >
> >> usb_gadget_remove_driver() runs through a four-step sequence to shut down
> >> the gadget driver. For the case of a composite gadget + at91 UDC, th
On Sun, Jul 8, 2012 at 5:33 PM, Alan Stern wrote:
> On Sun, 8 Jul 2012, Kevin Cernekee wrote:
>
>> usb_gadget_remove_driver() runs through a four-step sequence to shut down
>> the gadget driver. For the case of a composite gadget + at91 UDC, this
>> would look like:
>>
>> udc->driver->disconn
On Sun, 8 Jul 2012, Kevin Cernekee wrote:
> usb_gadget_remove_driver() runs through a four-step sequence to shut down
> the gadget driver. For the case of a composite gadget + at91 UDC, this
> would look like:
>
> udc->driver->disconnect(udc->gadget); // composite_disconnect()
>
usb_gadget_remove_driver() runs through a four-step sequence to shut down
the gadget driver. For the case of a composite gadget + at91 UDC, this
would look like:
udc->driver->disconnect(udc->gadget); // composite_disconnect()
usb_gadget_disconnect(udc->gadget);// at91
