Should usb_gadget_disconnect() call driver's ->disconnect?

[Felipe Balbi <felipe.balbi@linux.intel.com>]

Hi,

Alan Stern <stern@rowland.harvard.edu> writes:
>> >> > The documentation doesn't state whether a gadget driver's 
>> >> > ->disconnect() callback will be invoked when usb_gadget_disconnect() 
>> >> > runs.  Probably the UDC drivers' behavior has changed over the years.
>> >> >
>> >> > In any case, it's likely that various UDC drivers do behave
>> >> > differently.  My current feeling is that ->disconnect() should be
>> >> > invoked only when Vbus turns off, but I can't guarantee that all UDCs 
>> >> > will do this.
>> >> 
>> >> my feeling is that ->disconnect() should be called everytime we cause
>> >> the session to be killed. VBUS Turning off is a guaratee that session is
>> >> gone, but so is disconnecting data pullup, which is what
>> >> usb_gadget_disconnect() does.
>> >
>> > Okay.  I don't mind either way, so long as it is settled.
>> >
>> >> > How do you feel about documenting this ambiguity as in the patch below?
>> >> > If you think this is okay, I'll submit it formally.
>> >> 
>> >> Perhaps a better approach would be to start auditing all UDCs to make
>> >> sure that ->disconnect() is called when pullup is disconnected. Then we
>> >> can move ->disconnect() to usb_gadget_disconnect() itself. No?
>> >
>> > Rather the other way around: Call ->disconnect() from
>> > usb_gadget_disconnect() itself, then audit all the UDCs to make sure
>> > they don't invoke the callbackup.  That's better than adding a callback
>> > to the UDCs that are missing it, only then to remove it from all of
>> > them later on.
>> 
>> Fair enough. Do you want to handle this or would you prefer that I add
>> to my list?
>
> I'll send in a patch modifying usb_gadget_disconnect(), and I'll check 
> up on dummy-hcd and net2280.  The rest I prefer to leave for you.  
> Okay?

Sure, no issues :)