Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: >> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: >> > Felipe: >> > >> > 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? -- balbi
Attachment:
signature.asc
Description: PGP signature
