In answer to some of your original questions: On Thu, 11 Oct 2007, Phil Endecott wrote:
> Hi Oliver, thanks for the quick reply. > > Oliver Neukum wrote: > > Am Donnerstag 11 Oktober 2007 schrieb Phil Endecott: > >> Claiming devices: I understand how the usb core offers new devices to > >> kernel drivers based on the struct usb_device_id. Is there any way for > >> my user-space driver to influence this process? (A sufficient solution > >> for me for the time being would be a way to temporarily disable the > >> kernel matching while my user-space code is running; for example, I'd > >> be happy to load a small kernel module that clobbers the existing > >> matching somehow.) > > > > You can unbind a device from its driven with an ioctl through usbfs. > > OK; is it one of the ones listed at the end of usbdevice_fs.h ? I > don't see an obvious one... > > I would be happier if I could prevent it from ever getting bound in the > first place though! There's no question that userspace drivers are second-class citizens. But even kernel drivers have the same sort of problem: If two kernel drivers can both manage the same device, there's no mechanism to make sure which one will get bound. (Well, there _is_ one special-case mechanism. libusual mediates conflicts between ub and usb-storage.) There's no way to temporarily disable the kernel's built-in driver matching. > >> Choosing configurations: It looks as if I get two uevents when a device > >> is attached, one for the unconfigured device and another once the core > >> has done SetConfiguration. Is there any way for my driver to influence > >> the SetConfiguration process? Presumably I could do a > >> USBDEVFS_SETCONFIGURATION if I were unhappy with the configuration that > > > > Yes, what's wrong with that? > > Nothing at all, except that the device will have been given first one > configuration and then another in quick succession. I don't know if > that would ever be a problem. It shouldn't be a problem. Depends on the device, though. > >> it had chosen. (Is there any way for a kernel driver to influence the > >> SetConfiguration process?) > > > > usb_driver_set_configuration() whose semantics are a bit strange. > > Thanks, I'll have a look at that. It ends up doing much the same thing; a new configuration is installed quickly after the original one. There's no way for a driver to influence the original choice of a default configuration. > Order of events: I have some code that listens for KOBJECT_UEVENTs > using netlink and then opens the corresponding /proc/bus/usb/ file. > But this sometimes fails, because the uevents are sent before the files > are created. I could simply retry, but there's also the converse > situation where the device has already been removed (e.g. it has > "bounced") to worry about - is there a better way to do this? This last problem is unavoidable. A USB device can be unplugged at any time, and nothing -- not even a kernel driver -- will learn about it immediately. Drivers have to be prepared to handle errors caused by devices that unexpectedly disappear. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
