On Tue, 13 Aug 2013, Felipe Balbi wrote:
> > That's not what I meant. Yes, the test-device driver knows what test
> > it wants to run, based on the VID/PID. I was asking how it would
> > communicate this knowledge to the HCD.
> >
> > For example, it doesn't make sense to have a callback that means
> > "Insert a 15-second delay into the next URB that I submit", because the
> > HCD doesn't know where URBs come from.
>
> static int ehci_test_mode(struct usb_hcd *hcd, unsigned int test)
> {
> struct ehci_hcd *ehci = to_ehci(hcd);
>
> ....
>
> switch (test) {
> case USB_TEST_SINGLE_STEP_GET_DESC:
> start_test();
> wait_15_seconds();
> finish_test();
> break;
> ...
>
> default:
> return -ENOTSUP;
> }
>
> return ret;
> }
>
> ...
>
> static struct hc_driver ehci_hcd_driver = {
> ....
>
> .test_mode = ehci_test_mode,
>
> ...
> };
This is almost exactly the same as the way it is done in the newly
merged code. The only difference is that it uses a special test_mode
callback instead of a special selector value.
Didn't you say you wanted a large part of the support moved into
usbcore? For example, the routines that create and enqueue this "URB
with a delay in the middle" are little more than copies of the core
code.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
