On Tue, Aug 26, 2014 at 3:37 AM, David Laight <David.Laight@xxxxxxxxxx> wrote: > From: Dan Williams >> It's confusing (to me at least) to keep on remembering the differences >> between event rings (managed by the hardware) and non-event rings >> managed by the host. Replace "if (ring->type == FOO)" branches with >> ring ops that are specific to the type of ring. >> >> This is a tradeoff of direct code readability vs isolation and better >> readability of diffs (i.e. diff-context will now explicitly identify the >> ring type). > > I think it would be better to completely separate the event/cmd rings > calls at their call sites. > IIRC there is almost no overlap because the operations are different. > Using common code must have seemed a good idea at the start. > >> It promotes "quirky" rings to their own type in that they have their own >> distinct ring ops, as a result we no longer need to pass 'xhci' to >> queue_trb(). >> >> Finally, this is a preparation for xhci1.0+ ring handling which will >> have it's own ring ops. > > Do you need to worry? > I suspect the 0.9 hardware will be happy with the 1.0 ring handling. > Maybe even the setting for the residual number of transfer buffers. > That's exactly the point, I don't have to worry because v0.9 hardware will not see any of this thrash. This situation might be a good candidate for a flag that forces v1.0 ring handling on v0.9 hardware so others can test it over time. For now, since I can't/won't test on v0.9 hardware, I'd rather not worry about inadvertently breaking those hosts. -- 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
