On Tue, 15 May 2007, Oliver Neukum wrote: > Am Montag, 14. Mai 2007 22:09 schrieb Alan Stern: > > On Mon, 14 May 2007, Oliver Neukum wrote: > > > > > Am Montag, 14. Mai 2007 20:14 schrieb Alan Stern: > > > > On Mon, 14 May 2007, Oliver Neukum wrote: > > > > > > > > Worse. A driver may _lack_ a post_reset() method. > > > > > > > > In which case its resume() method gets called, in lieu of anything > > > > better. > > > > Drivers like that are in trouble whenever their device gets reset, > > > > whether > > > > it is related to hibernation or not. > > > > > > Well, disconnect() > > > > No, it should be up to the driver. Some drivers may not mind if a reset > > comes along. > > Yes, and it seems to me that persist should have its own method. > Those drivers that don't define it, don't support it.
It could have its own method. The method would be nearly identical to post_reset(), since they have to do exactly the same thing as far as the device is concerned. In fact, it probably would call post_reset(). The difference arises because is a reset is expected to be fairly quick, whereas a suspend followed by reset-resume can leave the device idle for a long time. And it's probably better to have a separate method than to pass a flag indicating whether a particular call is really for post_reset or for reset-resume. So I will add a new method pointer. I'm not sure what you want to do with drivers that don't define a reset_resume method. To say they don't support it is like saying they don't support regular resume; it may be true but it doesn't help. We don't unbind drivers with no resume method and we don't unbind drivers with no post_reset method, so why should we unbind drivers with no reset_resume method? Another reason for not doing it is because there's a certain amount of fragility involved in unbinding drivers during a reset-resume (or during any kind of suspend or resume, for that matter). These events can occur without the device lock being held; this happens with autosuspend and autoresume. Hence the unbind would have to be deferred to a different thread -- as in that usb_rebind_interface() patch I wrote. I don't like that approach; it adds too much additional complexity. On the other hand, if a driver doesn't support autosuspend then its device will never be autosuspended or autoresumed. Hence suspend, resume, and reset calls will always occur with the device lock held. In this case it would be safe to allow for rebinding in lieu of resume, post_reset, or reset_resume. What do you think? Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
