On Thu, 8 Dec 2011, Sebastian Andrzej Siewior wrote: > * Alan Stern | 2011-12-08 15:15:26 [-0500]: > > >> >No, I meant the three lines above, where max_streams is set to 0 if the > >> >emulated connection isn't SuperSpeed. Leave it in and let it run. > >> > >> You think it makes sense to do so? It is only used by the two > >> ep_autoconfig functions which look for the proper ep which is done at > >> bind time. So afterwards it is never looked at. > > > >Binding can occur many times during the life of dummy-hcd. Besides, > >it's not exactly a lot of code. I prefer to leave it in. I thought about this some more last night and changed my mind. Real UDC drivers won't erase the max_stream information when they connect at high speed, because it's always possible for them to reconnect later at SuperSpeed. Therefore dummy-hcd shouldn't erase the information either. > At bind-time you have to have that max_streams flag set. This happens > currently only once in the life time of gadget. > Meaning: > - dummy's init, max_streams != 0 > - load gadget, connect at HS, max_streams drops to 0 dummy is a little unusual; it knows from the start the speed at which it will operate. Of course, real UDC drivers don't know this. > - replace the gadget while dummy is unconnected dummy is never unconnected. At least, not in the usual sense -- it's like a device that sometimes turns off its pullup resistors, but whose cable never gets unplugged. > - the new gadget gets only eps with max_streams = 0. bind is done only > once. > > Since a gadget grabs endpoints only once it is wise to grab those with > max_stream capability _if_ the gadget supports SS. However if you happen > to connect at HS speed you may not use your stream feature even if the > endpoint supports it. That's more or less true. So go ahead, take out the code. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
