On Mon, Jul 27, 2009 at 10:37:21PM +0200, ext David Brownell wrote: > On Monday 27 July 2009, Felipe Balbi wrote: > > gadgets with multiple configurations will have problems with > > deactivations since they will register function_driver * configurations > > instances of each function driver, which will make > > cdev->deactivations to never become zero as it should. > > I don't follow. Surely if there is *any* function which isn't > ready to go, in any configuration, the device then must not be > activated. The only time it's safe to activate/reactivate the > device is if every function, in every configuration, is ready. > > Because the first thing the host can do is activate the config > with that un-ready configuration, and then try to use the function > which is not ready... > > > > Moving deactivations to usb_configuration in order seems to > > be the right fix to prevent the failure where gadget won't > > ever connect to usb bus. > > I'd have said the issue is that some function isn't properly > listing itself as ready-to-go ... imagine a gadget with two configurations and one (or more) f_obex instances on each one. We don't really want to create two /dev/ttyGS* for both obex instances since the configurations are mutually exclusive and endpoints will most likely be re-used. So why do we have to increment deactivations anyway ? Or you really _did_ want us to treat those both obexes as completely separate functions ? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
