On Sun, May 16, 2021 at 12:43:58PM +0300, Felipe Balbi wrote: > > Hi, > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > > > > If it's okay to call those functions in interrupt context then the > > kerneldoc definitely should be updated. However, I don't see why you > > would want to make DELAYED_STATUS mandatory. If all the necessary work > > can be done in the set_alt handler, why not return the status > > immediately? > > because we avoid a special case. Instead of having magic return value to > mean "Don't do anything until I enqueue a request" we can just make that > an assumption, i.e. gadget driver *must* enqueue requests for data and > status stages. Okay. But that would require auditing every gadget/function driver to ensure that they _do_ enqueue status stage requests, and auditing every UDC driver to ensure they don't send unsolicited status responses to control requests with data stages. Until this happens, we're forced to use the DELAYED_STATUS magic value. > > BTW, does it seem odd to you that these function drivers defer some of > > the set_alt activities into a work thread but do the ep_enable/disable > > parts right away, in interrupt context? I should think the drivers > > would want to minimize the amount of processing that happens > > in_interrupt. > > it is a bit odd, yes. I'm pretty sure this is forcing odd things to > happen in at least camera gadget, which must communicate with v4l2. > > IIRC, camera gadget processes frames in the same context as the > ->complete callback, as well, which also runs in_interrupt. Something for the UVC maintainers to cogitate on... Alan Stern
