Date: Thu, 11 Nov 2004 17:10:50 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-usb@FreeBSD.org Subject: Re: new USB driver Message-ID: <20041111171049.B887@curly.tele2.no> In-Reply-To: <200411110110.aa80909@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Thu, Nov 11, 2004 at 01:10:53AM %2B0000 References: <20041109232129.A283@curly.tele2.no> <200411110110.aa80909@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 11, 2004 at 01:10:53AM +0000, Ian Dowse wrote: > In message <20041109232129.A283@curly.tele2.no>, Hans Petter Selasky writes: > > > >Does the USB developers agree that the USB-core should use and support > >mutexes? If you want mutex support you will need to to call the callback the > >way I have done, else you get reverse locking problems ... > > Yes, we would certainly like to see the USB code brought out from > under Giant (it's probably not quite as critical as having it > function reliably, but still very important). What is it about > callbacks that needs to be changed? The callback cannot be called from usb_transfer_complete(), like it is currently done, due to the locking situation: starting a transfer: lock(priv) // setup data // I don't think it is a good idea // to unlock priv before accessing // the hardware, because if another // thread is about to stop the same // transfer, one doesn't know which // thread will run first, because // there is no lock held. lock(usb) // access and start hardware unlock(usb) unlock(priv) when the HC interrupts: lock(usb) // check if the transfer is complete and // enqueue transfer for completion if it has not been // queued for completion by another thread already // (NOTE: the queue is on the stack) // cannot lock priv here because then the locking // order will reverse which might cause a dead-lock unlock(usb) lock(priv) // check if another thread has stopped the transfer // or called the callback (e.g. timeout) // call callback unlock(priv) See the file _uhci.c and the functions uhci_timeout() and uhci_interrupt(). > > >> Do you have time to bring your driver up to date with -current, and > >> start undoing some of the unnecessary changes? > > > >Yes, but it might take some time. When will USB 2.0 HUB support be in place? > > Basic support is there already, but only for talking to USB2 devices > through USB2 hubs. How much more works with your driver? I have not added more USB HUB support than there is in FreeBSD-5-current. Yours -HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041111171049.B887>