On Wed, 19 Aug 2009, Sarah Sharp wrote: > If the driver got 8 stream IDs for both calls, then it would be fine for > them to make two calls. However, different endpoints can support > different numbers of streams. So a driver could ask for 255 streams for > both endpoints, and get allocated 63 and 31 streams. It would be up to > the driver to use streams 1-31 for both endpoints if it wanted to > coordinate between the two endpoints. It might be easier for the driver > to make one call instead. Maybe. But wouldn't the driver be able to find out how many streams an endpoint supports? So it should know not to ask for 255 streams from an endpoint that only has 31 available. It's not a big deal. Either way would work. > But it's unlikely that a UASP device will have endpoints with different > numbers of supported streams. The real reason that paragraph is in > there is because of secondary stream context arrays. They're sort of > like second-level page tables, and the xHCI driver needs to reserve some > stream IDs to point to these second-level entries. If the xHCI driver > doesn't set up all the endpoints at the same time, there's a chance the > xHCI driver will reserve different stream IDs in the paired endpoints if > it has to use secondary stream arrays. > > I was going to deal with secondary stream arrays and reserved streams by > making the drivers ask for the next available stream ID. In the end, I > found out that the first host controllers probably aren't going to > support secondary stream arrays, and decided it was too much work. > The code changed but the documentation didn't. All right. Designing interfaces with an eye toward later improvements is a legitimate approach. > > This seems like unnecessary overhead. Why not ask drivers to pass an > > array of pointers in the first place? That's just as natural as an > > array of endpoint addresses. > > I thought drivers didn't have access to the usb_host_endpoints, or > weren't supposed to access them anyway. Functions I looked at, like > usb_reset_endpoint(), all took endpoint addresses. That's because those routines were written before the usb_host_endpoint structure existed. There's nothing at all to prevent drivers from accessing these structures, and they do. > > Keeping track of the number of streams in the usb_host_endpoint > > structure seems like a reasonable thing to do. Then automatically > > re-enabling the streams after a device reset would be fairly > > straightforward. > > Sure. Should we re-enable streams for a driver that doesn't have > pre_reset() and post_reset() methods? If the driver is going to be > unbound and rebound, then won't it try to allocate the streams again? Since unbinding frees the streams, there won't be anything to re-enable in this case. 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
