usbd_bulk_transfer returns 1 (USBD_IN_PROGRESS) ?!

[Seb]

Hello,

On Thursday 26 May 2005 13:46, Hans Petter Selasky wrote:
> Have you got a link to the tarball of your driver?

Sure. http://lekernel.host.lya-network.biz/download/prism54u-bsd-0.1.tar.bz2

> I downloaded one of the files I found and had a look.
>
> When you detach, you have to stop the pipes/transfers you are using. Then
> usbd_bulk_transfer will return USBD_CANCELLED and must not be called again!

Ok, I'll add this, thanks for the info. But this won't solve the 
USBD_IN_PROGRESS problem...

> Also you must make sure that transfers (xfer) are not started two times in
> success, before the first call has returned transfer status.
>
> I'm not too familiar with swi_sched, but it might be that it runs the
> interrupt handler in parallell.

According to the ithread and swi_add manual pages, since I don't specify the 
INTR_MPSAFE flag the Giant mutex is acquired before the interrupt thread runs 
my code and is released right after my function returns. So there is no 
possibility for parallel USB transfers AFAIK.

> Where are you tearing down your software interrupt handler?

In p54u_netdev_free (netdev.c) :
if(sc->update_state != NULL) ithread_remove_handler(sc->update_state);
and in p54u_shutdown (usb_init.c) :
if(sc->send_pending != NULL) ithread_remove_handler(sc->send_pending);
if(sc->swi != NULL) ithread_destroy(sc->swi);
The update_state handler is responsible for reconfiguring the device (LED 
status, frequency, RX filter) ; and send_pending handler sends the 802.11 
frames.
USB transfers also occur in the sc_stats_ch callout to update the network 
statistics, but since the mpsafe argument in callout_init is set to zero, the 
Giant mutex is held while the callout function executes ; therefore the USB 
transfers shouldn't race.

> Does the same problem happen with my USB driver?

I'll try.

Regards,
Sebastien