Dan Williams <[email protected]> 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.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
