hi,
Stephen Williams wrote:
>>You could try to issue a usb_reset_device() at driver initialisation in
>>order to restart the firmware. Please report if this solves your problem.
>>thanks,
>>
>>Holger
>>
>>
>
>That certainly sounds like it could help. I'll give this a try the
>next time the device locks itself up (could be a few days). Am I right
>in thinking that I just need to make the following changes to the
>cinergyt2_probe function:
>
>
> INIT_WORK(&cinergyt2->query_work, cinergyt2_query, cinergyt2);
>
> cinergyt2->udev = udev;
>
>+ if ((err = usb_reset_device(&cinergyt2->udev)) != 0) {
>+ printk("%s: usb_reset_device() failed (err = %d)\n",
>+ __FUNCTION__, err);
>+ goto bailout;
>+ }
>
>
looks ok to me, but one would have to test to be sure.
> if (cinergyt2_alloc_stream_urbs (cinergyt2) < 0) {
> dprintk(1, "unable to allocate stream urbs\n");
> kfree(cinergyt2);
>
>Thanks for your help.
>
>
something else you might try: in order to re-synchronize the
communication you may insert a dummy read/write/read command and ignore
the error code if an error occurs. The first read will fail in normal
case (no previous write issued, the device is awaiting a new command)
and succeed in the unusual case when the device communication is
out-of-sync...
please report your experiences and let us know whether this makes the
code more robust,
Holger
