On Wed, 2013-02-13 at 12:44 +0100, Bjørn Mork wrote:
> Dan Williams <dcbw@xxxxxxxxxx> writes:
>
> > It doesn't need to run exactly at probe, but it appears to need to be
> > the first thing the driver does when communicating with the firmware to
> > ensure clear state and whatnot. Possibly like the QMI SYNC message that
> > clears all the client IDs and resets the internal stack. (the driver
> > also sends a "shutdown" message to the firmware when unbinding).
> >
> > So I do think that somewhere around probe() is the best time to do this,
> > because it's best to initialize the device when the driver binds to it
> > and react to errors as soon as possible, rather than trying to set
> > everything up on open/IFF_UP and then fail right before you want to
> > actually use the device. Late-fail is quite unhelpful for applications.
> >
> > I don't really care if it happens in probe() or somewhere else right
> > after the driver is bound to the device, but it should be part of the
> > initialization process.
>
> I was looking for something else in the rndis_host driver right now and
> noticed that it has the same sort of problem. The generic_rndis_bind()
> function will call rndis_command() which does
>
> usb_control_msg(.., USB_CDC_SEND_ENCAPSULATED_COMMAND, ..);
> usb_interrupt_msg(.., dev->status->desc.bEndpointAddress, .. );
> for (count = 0; count < 10; count++) {
> usb_control_msg(.., USB_CDC_GET_ENCAPSULATED_RESPONSE, ..);
> if (ok)
> return 0;
> msleep(20);
> }
>
> Somewhat ugly, but it is a way to send and receive commands while
> probing. This driver also sends a command in unbind().
>
> Looks like your patch would allow this to be solved a lot cleaner,
> replacing the loop over USB_CDC_GET_ENCAPSULATED_RESPONSE with proper
> interrupt endpoint handling.
It would end up being more "correct" but more complicated, because you'd
need to have rndis_command() block on a semaphore or something until the
response was processed by a "status" handler, which neither rndis_host.c
or rndis_wlan.c actually implement. The status handler would have to
know that something was waiting on it, and then package up the response
in some way that the rndis_command() (which is now blocking on the
status interrupt) can read it and return it to the caller.
More correct, more code, more complicated... but probably still
worthwhile?
Dan
--
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
