On Thu, Jan 25, 2007 at 04:17:03PM +0100, Oliver Neukum wrote: [] > > > > It is relatively new. As comment states, it doesn't guarantee > > anything, caller hangs in air... > > Yes, unfortunately this is true. However, as I understand it, you are > helpless if you are called with the wrong configuration. So you don't really > lose anything. > If you wish to, you can return 0 from probe() and you'll be disconnected > from the device by the change of configuration.
Well, any kind of crutch may be used, still it's crutch. > The alternative is a deep change to the API for one odd type of device. > Do you absolutely need an error return? AFAIK, this is standard USB firmware update logic. Greg even co-authored a standard for this. As for me, driver must have full control of plugged device until it unplugged. USB ID games make this impossible at first glance. But i don't know about problems to have some kind of history of device acting during plug-unplug period. > Regards > Oliver ____ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
