On Thu, 29 Jul 2004, Wolfgang M�es wrote: > Hello, > > On Wednesday 28 July 2004 21:10, Alan Stern wrote: > > > This is still relatively new and hasn't percolated down to the level > > of the hotplug scripts yet. Nevertheless, in a hotplug script is the > > right place to do it. > > Hmmmm... if I had a choice, I prefer choosing the configuration from > inside the kernel driver... because then there is _one_ place which is > doing all the stuff which is needed to set up the device correctly.
You can always do it indirectly, using the schedule_work() mechanism. The USB API deliberately makes it difficult for drivers to change configurations. The idea is that with USB, a driver manages an interface (rather than the whole device) -- and when you change configurations the interface goes away. It would be kind of like a hard disk driver telling the system to replace the hard disk with a floppy. > If the configuration can be set inside the drivers device table, and > find its way into the hotplug scripts automaticly, this will be > fine.... > > But fiddling the hotplug scripts by hand? This seems not ideal to me, > because these scripts are not distributed with the kernel... The scripts shouldn't be fiddled with by hand; they should be changed at the source -- the hotplug project at Sourceforge. The fact that they aren't distributed with the kernel doesn't matter; after all, your particular device isn't distributed with the kernel either... > The hotplug script is executed _before_ probe() is called? Even if the > driver is already in memory? And the sysfs is doing the > set_configuration() before probe() is called? The hotplug script is executed _while_ probe() is called. That is, the script is run in a different process that gets started just before probe(); hence they execute concurrently. That's true whether the driver is in memory or not -- although if it isn't in memory then probe() will be delayed until the driver is loaded (which might happen only as a result of an action taken by the hotplug script). As for when sysfs does the set_configuration(), that depends on when you write to the bConfigurationValue file. If the driver is already present in memory then it will be probed before the set_configuration() call; that's guaranteed by the device locking. If not, things might work out the other way round. In the end it shouldn't matter, because set_configuration() will automatically unbind any existing drivers as its first step and it will probe for new drivers after changing the config. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
