On Mon, Jan 31, 2022 at 12:08:20PM +0000, Kieran Bingham wrote:
> Hi Michael, Alan,
>
> Quoting Michael Grzeschik (2022-01-26 18:31:38)
> > On Wed, Jan 26, 2022 at 11:09:23AM -0500, Alan Stern wrote:
> > >On Wed, Jan 26, 2022 at 02:22:49PM +0100, Michael Grzeschik wrote:
> > >> With this patch, the dummy_hcd gains first support for isoc transfers.
> > >> It will complete the whole urb with all packages.
> > >
> > >"packets", not "packages".
> >
> > Right.
> >
> > >> Even if the gadget
> > >> side did not enqueue any request, the urb will be handled.
> > >>
> > >> Signed-off-by: Michael Grzeschik <m.grzeschik@xxxxxxxxxxxxxx>
> > >
> > >I don't like this idea. If support for isochronous transfers is added,
> > >it should be done correctly. That is, the implementation should support
> > >scheduling of transfers, periodic bandwidth reservation, high-bandwidth
> > >transfers, and so on.
> > >
> > >The whole point of dummy-hcd is to emulate a real host controller as
> > >closely as possible. Real isochronous transfers do not complete all at
> > >once.
>
> Being able to at least test uvc-gadget in a virtual environment would
> already be a big benefit. As this is emulation, not simulation is it
> essential that an exact mapping of the hardware is in place?
Bindly being a sink for all data is not emulation for drivers that
require some sort of feedback loop.
> Is there anything we can do to support the progression of this
> development?
>
> I.e. could we support this method first with a
> WARN_ONCE("This does not fully emulate Isochronous support");
That would instantly trigger syzbot to send us reports for no good
reason. Please don't do that :(
thanks,
greg k-h
