Re: [PATCH 2/2 v2] sierra_net: fix issues with SYNC/RESTART messages and interrupt pipe setup

[Dan Williams <dcbw@redhat.com>]

On Wed, 2013-02-13 at 12:44 +0100, Bjørn Mork wrote:
> Dan Williams <dcbw@redhat.com> 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