On Tue, 16 Oct 2007, Matthew Dharm wrote:

quoted text
> I haven't looked at this code at all, but neither approach feels right to
> me.
> 
> How does this work at all?  Even if you load a driver later, wouldn't it
> call usb_set_interface(), which would call usb_create_sysfs_intf_files()
> and hit the same issue?

usb_set_interface() is smart enough to remove the old interface files
before creating new ones, since it expects them to exist already.  
Hence there's no problem in that scenario.

But usb_set_configuration doesn't expect there to be any pre-existing
interface files, because there isn't even an interface until the
registration is performed.

quoted text
> Heck, why do both call usb_create_sysfs_intf_file()?  I would guess if
> you're *changing* the active configuration you would need to do that, but
> why in usb_set_interface() at all?

For a couple of reasons.  The "interface" attribute file contains the
iInterface string descriptor, and that file is present only if such a
descriptor exists.  Since different altsettings might not agree on
whether or not iInterface exists, the attribute has to be created anew
for each altsetting.  (Yes, we could let the file always be present and
just be blank if there is no descriptor.)

The most important reason has to do with the endpoint pseudo-devices.  
Different altsettings can have different endpoints, so those have to be
removed and re-created whenever the altsetting changes.

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-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel