On Tue, Aug 26, 2014 at 9:21 AM, David Laight <David.Laight@xxxxxxxxxx> wrote: > From: Dan Williams [mailto:dan.j.williams@xxxxxxxxx] >> 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. > > But the indirected function calls are probably over-engineering. I'm more than willing to rip it out, but only in the presence of positive test results. > They also come at moderate execution cost. > Not that any of the xhci code seems to have considered execution time. > I could saturate a Ge full duplex, but the next version of USB hardware > will be fast enough for 10Ge - and then execution time does start mattering. > It might even matter for USB3 on newer tablets/phones. Yes, we can cross that bridge when we come to it. But, I will say, modern cpus are quite good at indirect-branches. -- 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
