Messages in this thread | | | From | "Dunlap, Randy" <> | Subject | RE: strange usb behavior | Date | Thu, 16 Dec 1999 09:27:49 -0800 |
| |
Hi-
> -----Original Message----- > From: Petko Manolov [mailto:petkan@spct.net] > Sent: Thursday, December 16, 1999 9:04 AM > To: Dunlap, Randy > Cc: linux-kernel@vger.rutgers.edu > Subject: Re: strange usb behavior > > "Dunlap, Randy" wrote: > > > > This says that you did a control msg read/INput, > > requesting 4 bytes, and 0 bytes were actually read > > from the device (i.e., the device sent 0 bytes, not 4). > > I can guess this, but is not true because registers i > modify changed their values.
So are you saying that you do a control msg read/INput to modify device registers? Or could it be that you did a control msg write/OUTput to modify registers and then did a control msg read/INput to read those registers, and we are not seeing the entire log here?
> > > I don't see how this would have anything to do with > > the registers being modified. Wouldn't that usually > > be done with a control pipe write/OUTput message? > > I use vendor specific call that to change MII and > device specific registers. So the change succeed, > the values are set correctly (the read show so), but > warning appears.
So is the vendor-specific [control msg] a write/Output or a read/Input?
> > > usb_bulk_msg() is a synchronous I/O function. It > > waits until I/O complete (or timeout) to return to > > your driver. usb_request_bulk() is an async I/O > > request. Your driver will continue execution > > immediately after the I/O to your device has been > > setup. For any decent performance, I expect that > > you would want to use usb_request_bulk(). > > Hm, that looks ok, but kernel oopses bad blaming me > that do request_bulk in interrupt. Actually i use > request_bulk() from my start_xmit() routine. Speaking > of which i have always thought that start_xmit() is > the top half of the driver and executes in process > context. Is that true?
You certainly couldn't do a usb_bulk_msg() from interrupt context since it calls schedule_timeout(). However, I don't know of any reason that you can't call usb_request_bulk() from interrupt context.
I haven't written a network driver for Linux (I have for NetWare, DOS, and some Windows). In all of those, I agree with you. start_xmit() would be in process context, not interrupt context.
~Randy
> > > BTW, linux-usb has a web site (www.linux-usb.org) and > > a mailing list (linux-usb@suse.com). > > ;-)) Thanks, this simplifies my job very much. > > Best regards, > Petkan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |