On Tue, 12 Aug 2003, David Brownell wrote: > Alan Stern wrote: > > > There's another time. That's if the device driver happens to know that > > the device has to operate in a configuration other than the default one > > (or other than the one installed when probe() is called). Yes, I know > > there are issues of policy involved there, and just who should decide > > which configuration to use, but it's a legitimate thing to do. > > Eventually. But it's never really worked correctly yet, so to > that extent it's a new feature -- not a backwards compatibility > issue. Essentially all current callers of usb_set_configuration() > other than khubd (setting the default) and usbfs (causing trouble) > want usb_reset_configuration() functionality -- not config changes.
While that's true, there's no reason we shouldn't add the capability as part of this reorganization -- especially if it's easy to do so. > I just noticed that my previous usb_set_configuration() experiment > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=105484578921888&w=2 > > was the simplified version, without a driver configure() callback. Posted back in June! No wonder I don't remember it :-) (Quite aside from it being the simplified version.) > Sorry, I forgot I didn't send that. Briefly, for multi-config > devices, drivers that matched the device descriptor and had a > configure() callback were given the opportunity to choose a > non-default configuration. I read the archived message, and I see what you have in mind. Basically we're talking about a design decision here. Should drivers be able to request configuration changes at arbitrary times, or should they be restricted to config matching in this new callback routine (which gets invoked when the core wants to select a config)? Many of the advantages of the second choice would be negated by the fact that config changes can be requested via usbfs or sysfs at any time. What about drivers that are loaded by hand, well after the initial device setup has finished? Would they get a say in choosing a configuration? > I'm still expecting that any driver API would use something like > that configure() callback. I think that approach is simpler. > (But I also don't think kernel drivers need that capability much > at all today, and it's enough to be available from userland.) We shouldn't let the fact that no drivers today need this ability sway us to declare that drivers will _never_ be allowed to do it. > > No, as you pointed out above, unbind for the driver/interface making the > > usb_set_configuration() call must be deferred also. All the other > > interfaces can be unbound immediately. Also, I don't see any harm in > > always deferring the re-binding -- it would simplify things, and in any > > case it can't be done until the calling driver has been unbound. > > I see different assumptions: namely, that usb_set_configuration() > should be available to device drivers in almost all contexts, not > just in controlled configure() contexts. Don't forget, this discussion applies equally well to usb_reset_device() in the "device morphed" pathway. I doubt you want to restrict that capability to these configure() contexts. > > There _is_ a problem, which Oliver identified. What if one driver > > requests a reset or config change at the same time that another interface > > is being probed (or unbound)? Then the serialization must block the > > request until the probe is done. But if a driver makes such a request > > within its own probe(), serialization shouldn't block it. Arranging that > > will require a little effort. > > It's easy to serialize for a new configure() callback, which isn't > doing double duty. Or to let userspace deal with the problem. Again, we also have to deal with usb_reset_device(). But handling this correctly shouldn't be too hard; we simply have to record which interface is probed/disconnected as it happens. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
