lkml.org 
[lkml]   [2003]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
[ CC list trimmed, most folk are on one of the cc'd lists ]

> By the way, here is the list of routines that cause trouble for usbfs:
>
> usb_probe_interface

In proc_resetdevice() ... after usb_reset_device().
If usb_reset_device() worked sanely, it wouldn't be
necessary to try fixing up its result. Plus, last I
looked, I don't think usbfs fixed it up correctly.

Actually that call is dangerous and probably should
fail if usbfs isn't controlling all the interfaces
on the device ... checking before it tries.

> usb_reset_device

We've known for some time this routine needs a rewrite.
It's never quite worked right, and it doesn't handle
DFU style devices (like the most common USB 802.11b
adapters) well at all.

> usb_set_configuration

That is, you're saying that _if_ usbfs is modified to
get rid of ps->devsem and use dev->serialize instead,
then you'd need some other way to guard proc_setconfig()
against disconnect? That still seems like a chicken/egg
issue to me.

> usb_unbind_interface

See the patch I posted yesterday evening, with usbfs parts
of the updates to driver binding. It's incorrect for usbfs
ever to be calling that ... device_release_driver() is the
thing to call, for drivers that weren't bound using the
usb_driver_claim_interface() call. That way the sysfs
state also gets cleaned up ...

- Dave


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.135 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site