On Thu, Nov 15, 2001 at 04:09:59PM +0530, Praveen Madhavan wrote: > Would you send me the patch or link for latest bluetooth.c.
It's available in the latest kernel source tree at kernel.org. > I think bluetooth_write( tty->ttydriver->write) function need not to be > a blocking call always. > I mean, ttydriver write function are implemented in such way that it can > be either called from > process context or an interrupt context. What do you mean by "interrupt context"? From an interrupt bottom or top half? bluetooth_write() can _not_ be called from a top half, as it could call schedule() from a number of different places. bluetooth_write() can safely be called from a bottom half. > Some what similar to the way in which PPP line-discipline access > serial driver( tty driver) in linux. Here, PPP invokes serial driver write > function in process context or an interrupt context. serial driver write > function has to just copy the data into its own transfer buffer and > transmit them later. > Similary bluetooth_write in Bluetooth driver has to copy the data > into its transfer buffers and submit Write URBS non-blockingly.Then > Bluetooth_write function can be still invoked from interrupt context safely. What code wants to call bluetooth_write() from a top half interrupt handler? I don't see the problem. Sure bluetooth_write() could be rewritten to work a bit differently, but then returning any errors that are caused by the USB subsystem to the caller would be almost impossible. The current code handles error handling quite well. Remember, this is quite different from dealing with a serial UART :) Again, I don't see a reason to change the current code. A number of different Bluetooth stacks seem to work quite fine with it. What Bluetooth stack are you using that is causing problems? thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
