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. 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. David ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
