> even though this seems to be a good thing to do I think
> this puts a lot of overhead into the submition path especially for
> embedded USB hosts. A 50MHz CPU will need a significant
> amount of time to pass those checks. For example a MPC823
> needs about 30 to 50 % of its CPU-time to manage its
> USB host controller and the checks probably adds some other percents.
Surely most of that MPC823 time is computing 5bit CRC codes on the
host or device/"gadget" side ... :)
I've had a similar thought, but there actually isn't that much code
(and it's mostly for periodic transfers). In any case, almost all
of it just moved from the OHCI and UHCI drivers into the HCD framework
code. (And then, with this patch, to an even more generic place.)
We really don't want to have each HCD providing its own interpretation
of the API integrity rules!
> Also the checks are only good for bug finding. If all bugs have been
> found during development then we don't need the checks during ordinary
> runs.
That's not entirely true, unfortunately ... often flakey devices
or typical "partially debugged" drivers (or code paths) trigger
errors. Me, I prefer them to be detected before they cause HCDs
to oops, or scribble memory; it's a lot easier to find and fix
the inevitable problems that way.
Although I've had much the same thought, for some of the tests.
Since those tests were mostly from inside the (mainstream) OHCI
and UHCI HCDs, I didn't want to remove any of them: that'd be
a loss of functionality/integrity, as well as a change to the
API integrity rules. Doable, but not something I wanted to
rush on ... :)
> Or a more pragmatic approach: Let us find the bugs on fast
> CPU / low USB overhead systems and don't bother embedded HCDs
> with those checks.
A few of the checks are already #ifdef DEBUG. Some others
might be moved there. I'd certainly be in favor of moving
some more code to that #ifdef DEBUG block, though I don't
have any particular suggestions for what should move.
Also, I'd like 2.5 to move all the periodic scheduling info
out of urbs into some config/altsetting state inside the device.
(Maybe an array of endpoint descriptors, and primitives to let
polling intervals be overridden.) That would let us move that
data out of the URB, and checking it would be done outside the
submit path for all HCDs.
> Another remark:
> As far as I can remember it is legal to transfer more than
> maxpacketsize bytes (= more than one packet) at
> interrupt transfers.
>
> So
> > + case PIPE_INTERRUPT:
> > + if (urb->transfer_buffer_length > max)
> > return -EMSGSIZE;
> seems to be wrong.
I know that high speed makes a special case ("high bandwidth")
for multiple packet periodic transfers (including iso), which
is addressed in computing "max" ... it's not legal to do so
except for "high bandwidth" mode. And the UHCIs have that policy.
I don't think it's appropriate at this point for any Linux HCD
to support more than one, on grounds of driver portability,
even if the USB spec is a bit fuzzy on that topic for full
and low speed transfers. (I'm not sure what it says, though
many folk seem convinced there _is_ a one packet limit to each
full/low speed periodic transfer period.)
What I'd _like_ to see happen is to see the URB API just make
interrupt transfers be identical bulk in all ways except that
they're on the periodic schedule: queued, no automagic resubmit,
and so on ... including lifting that size restriction. So host
side drivers could just read a full HID report, and device side
ones could just write them, without extra copies. (That's just
one example.)
- Dave
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
