This eliminates an error case (current cost, memleak) when
disabling endpoints that have control requests queued.
Please merge.
- Dave
--- 1.70/drivers/usb/core/hcd.c Fri Jul 25 06:48:06 2003
+++ edited/drivers/usb/core/hcd.c Tue Aug 5 16:46:38 2003
@@ -1307,7 +1307,8 @@
On Wed, 6 Aug 2003, Soewono Effendi wrote:
On Wed, 6 Aug 2003 10:47:15 -0400 (EDT)
Alan Stern [EMAIL PROTECTED] wrote:
The upshot is that for USB, which is hotpluggable, __devinit and __devexit
are useless.
useless - danger! if usb modules are statically linked to kernel, since
the
Am Mittwoch, 6. August 2003 14:01 schrieb Soewono Effendi:
Hi,
__init and __devinit are defined in linux/include/linux/init.h
There are some usefull hints in the file. __devinit is used mostly by HotPlug.
This might also help: Found in linux/init/main.c
...
static int init(void *
Hi,
sending should check for ESHUTDOWN as well.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
Hi,
there are a few things to clean up
1. usb_submit_urb called from a completion handler must use GFP_ATOMIC
2. you should also check for ESHUTDOWN if you check for ENOENT
3. you cannot blink an LED with usb_ctrl_msg from a completion handler,
as it sleeps, this needs schedule_work. Is it worth
if ( buffersNotAllocated ) AllocateBuffers();//these are my
defined functions
ssize_t retval = 0 ;
sRead.nOffset = 0;
retval=usb_bulk_msg (my_dev, usb_rcvbulkpipe
(my_dev,endpoint_r),sRead.pBuff, frame_size, count, HZ*5);
wait_for_urb (sRead.pUrb);
Either use
I'm not sure if it's worth discussing this any farther, since the
controller hardware probably won't support it, but ...
On Wed, 6 Aug 2003, David Brownell wrote:
Alan Stern wrote:
A related issue has to do with setting the HALT feature when the host
tries to read/write too much. The
David T Hollis wrote:
Problems with 2.6.0-test2-mm4 hid are continuing. My usual temporary
remedy was to remove hid and reload it which reactivated my usb
mouse. Today I got this dump and rmmod hung trying to remove hid:
I'm rebuilding the kernel as we speak with USB_DEBUG enabled to see if
On Tue, Aug 05, 2003 at 07:53:12PM -0700, David Brownell wrote:
This eliminates an error case (current cost, memleak) when
disabling endpoints that have control requests queued.
Please merge.
Applied, thanks.
greg k-h
---
This SF.Net
On Wed, 6 Aug 2003 10:47:15 -0400 (EDT)
Alan Stern [EMAIL PROTECTED] wrote:
The upshot is that for USB, which is hotpluggable, __devinit and __devexit
are useless.
useless - danger! if usb modules are statically linked to kernel, since the functions
with __init are removed! unless
David T Hollis wrote:
Here is dmesg output showing my unloading/loading of hid and the
subsequent 'lockup' of the mouse that followed.
drivers/usb/core/usb.c: deregistering driver hiddev
drivers/usb/core/usb.c: deregistering driver hid
ohci-hcd :02:0e.0: shutdown urb f7587480 pipe 40408380
David:
A few things have come while planning my gadget driver.
The gadgetfs API still looks a bit preliminary. Judging by the source,
there doesn't even appear to be any way to halt an endpoint! Anyway, I
decided not to use it; the performance penalties would make it a bad model
for this
Changes a handful of things in enumeration error paths.
Bugfixes:
- consistent cleanup, and consistent return of -Ewhatever/0;
- a usb_put_dev() gets rid of the extra refcount; this
one's in bugzilla at osdl.
Diagnostics:
- new diagnostic for when there's a choice of configurations;
-
13 matches
Mail list logo
