Re: [linux-usb-devel] Patches still in the queue
Am Dienstag, 22. Mai 2007 04:10 schrieb Alan Stern: On Mon, 21 May 2007, Oliver Neukum wrote: Am Montag, 21. Mai 2007 23:16 schrieben Sie: On Mon, 21 May 2007, Oliver Neukum wrote: No. We are discussing what to do when the method doesn't exist, not what to do when it fails. In this situation we must assume the driver was working fine and it simply can't cope with a device reset. Ok, this narrowly put, my answer is: - don't autosuspend - on resume, disconnect the driver And then rebind the same driver back again? Essentially yes. Simply use the standard probe logic, no need for special casing. But what if the current driver got there in the first place by some sort of special casing? Then the special casing better be in place for new devices turning up, too. Remember that we are talking about a system suspend, which needs root priviledge. For that matter, what if the current driver is usbfs, by way of USBDEVFS_CLAIMINTERFACE? Hmmm, maybe the usbfs driver will need to have a reset_resume method; at the moment it doesn't even have suspend or resume. (But I don't know what any of them could do...) It will and they'll have to make sure user space learns about the situation and cannot submit any more io until then. But this should be discussed in terms of requirements for usbfs2. May I suggest to involve everybody involved in that be involved in that discusion, possibly in a separate thread? Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
Am Mittwoch, 16. Mai 2007 16:30 schrieb Alan Stern: On Wed, 16 May 2007, Oliver Neukum wrote: Now consider cases where the driver does perform an identity check. Combine this with a previous remark you made: Devices with the reset_resume quirk are quite rare. Hence such drivers won't stand to lose much if they also do the identify check in reset_resume. Sure it would be unnecessary, but it wouldn't cost much and it would hardly ever happen. In other words, there's never any real reason for powerloss_resume and reset_resume to do different things. So there's no reason to have two separate methods. I had not considered that. You are right. reset_resume will happen only because of the quirk. But when it happens during an autoresume, we cannot unbind the driver because we don't own the device lock. So what do you want to do then? This would need a separate thread. Yes. Along with all the complications of keeping track of references and making sure the thread gets flushed at the right time. How to avoid it? If the original driver fails, I see no alternative but to yield to other drivers and usbfs. But if a driver does not support reset_resume() and a device is quirky, why would you autosuspend in the first place? You would autosuspend a quirky device for the same reason you autosuspend a normal device: to save power. The fact that it needs a reset to resume isn't necessarily a drawback. You don't autosuspend a device unless the driver explicitely supports autosuspend. I could add a check to prevent autosuspend for quirky devices with a driver that doesn't support reset_resume. Is this really needed? Yes. It seems to me that this issue arises only if reset_resume() returns an error. Is there a reason to treat this differently from resume() failing? On a system resume, we can unbind. The only reason to treat it differently is because it occurs in a different context. System resume is different from autoresume, most especially because autoresume is often invoked by the driver itself. When that happens, trying to unbind could lead to deadlock. Let's disallow drivers failing during autoresume. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
Am Mittwoch, 16. Mai 2007 16:30 schrieb Alan Stern: In other words, there's never any real reason for powerloss_resume and reset_resume to do different things. So there's no reason to have two separate methods. BTW, with these changes it seems to me that everything is in place to do autodepower. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Mon, 21 May 2007, Oliver Neukum wrote: reset_resume will happen only because of the quirk. But when it happens during an autoresume, we cannot unbind the driver because we don't own the device lock. So what do you want to do then? This would need a separate thread. Yes. Along with all the complications of keeping track of references and making sure the thread gets flushed at the right time. How to avoid it? If the original driver fails, I see no alternative but to yield to other drivers and usbfs. Well, you don't really want to yield to other drivers and usbfs. Remember, we're talking about situations where the only problem is that the device has been reset and the driver doesn't know what to do about it. If the driver was working okay with the device before then it should be kept, not replaced by some other driver which might not work as well. So we should do unbind followed immediately by rebind, as in the patch I sent a week or so back. But maybe we can avoid having to use a separate thread. Like you said, disallowing autosuspend for quirky devices whose driver doesn't support reset_resume should eliminate the locking difficulty. But if a driver does not support reset_resume() and a device is quirky, why would you autosuspend in the first place? You would autosuspend a quirky device for the same reason you autosuspend a normal device: to save power. The fact that it needs a reset to resume isn't necessarily a drawback. You don't autosuspend a device unless the driver explicitely supports autosuspend. You do if the driver isn't bound to the device. :-) That's what happened with the quirky Philips audio thing. During bootup the system was very busy with other things, and the hotplug manager took a long time to load the usb-audio driver module. During that time the device was autosuspended. Then when the driver was finally loaded and the device was resumed so that probe() could be called, the device stopped working. Of course, in this situation we wouldn't need to call the driver's reset_resume method (if it had one) because at resume time the driver wasn't yet bound to the interface. It seems to me that this issue arises only if reset_resume() returns an error. Is there a reason to treat this differently from resume() failing? On a system resume, we can unbind. The only reason to treat it differently is because it occurs in a different context. System resume is different from autoresume, most especially because autoresume is often invoked by the driver itself. When that happens, trying to unbind could lead to deadlock. Let's disallow drivers failing during autoresume. reset_resume() methods will return void. Normal resume methods do return a status code, but we ignore it. So we should be okay. 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
Re: [linux-usb-devel] Patches still in the queue
Am Montag, 21. Mai 2007 17:15 schrieb Alan Stern: On Mon, 21 May 2007, Oliver Neukum wrote: How to avoid it? If the original driver fails, I see no alternative but to yield to other drivers and usbfs. Well, you don't really want to yield to other drivers and usbfs. What else do you do if you cannot resume ? This method needs to carry out IO to restore the state. Hence it may fail. Remember, we're talking about situations where the only problem is that the device has been reset and the driver doesn't know what to do about Who tells you that? Any IO might fail. it. If the driver was working okay with the device before then it should be kept, not replaced by some other driver which might not work If the method fails, we know that the previous driver is not working. In that case pseudo continuity cannot be preserved. Either the device is zombified or renumerated. Which third option exists? [..] reset_resume() methods will return void. Normal resume methods do return a status code, but we ignore it. So we should be okay. That is simply wrong and should not be allowed to infiltrate other methods. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Mon, 21 May 2007, Oliver Neukum wrote: Am Montag, 21. Mai 2007 17:15 schrieb Alan Stern: On Mon, 21 May 2007, Oliver Neukum wrote: How to avoid it? If the original driver fails, I see no alternative but to yield to other drivers and usbfs. Well, you don't really want to yield to other drivers and usbfs. What else do you do if you cannot resume ? This method needs to carry out IO to restore the state. Hence it may fail. Remember, we're talking about situations where the only problem is that the device has been reset and the driver doesn't know what to do about Who tells you that? Any IO might fail. The original context for this discussion has been cropped... We were talking about what to do when a driver doesn't have a reset_resume method. So when the core resets a device instead of resuming it, obviously the core knows there's something wrong when it sees the reset_resume method pointer is NULL. it. If the driver was working okay with the device before then it should be kept, not replaced by some other driver which might not work If the method fails, we know that the previous driver is not working. No. We are discussing what to do when the method doesn't exist, not what to do when it fails. In this situation we must assume the driver was working fine and it simply can't cope with a device reset. In that case pseudo continuity cannot be preserved. Either the device is zombified or renumerated. Which third option exists? [..] reset_resume() methods will return void. Normal resume methods do return a status code, but we ignore it. So we should be okay. That is simply wrong and should not be allowed to infiltrate other methods. You have raised a separate question (what to do when an interface driver's resume method or post_reset method fails) and it should be discussed in a separate email thread. If you're suggesting that the post_reset and reset_resume methods should return a status, that's okay with me. For the time being we will ignore that status, just as we ignore the status from a normal resume. 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
Re: [linux-usb-devel] Patches still in the queue
Am Montag, 21. Mai 2007 18:04 schrieb Alan Stern: it. If the driver was working okay with the device before then it should be kept, not replaced by some other driver which might not work If the method fails, we know that the previous driver is not working. No. We are discussing what to do when the method doesn't exist, not what to do when it fails. In this situation we must assume the driver was working fine and it simply can't cope with a device reset. Ok, this narrowly put, my answer is: - don't autosuspend - on resume, disconnect the driver Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Mon, 21 May 2007, Oliver Neukum wrote: No. We are discussing what to do when the method doesn't exist, not what to do when it fails. In this situation we must assume the driver was working fine and it simply can't cope with a device reset. Ok, this narrowly put, my answer is: - don't autosuspend - on resume, disconnect the driver And then rebind the same driver back again? 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
Re: [linux-usb-devel] Patches still in the queue
Am Montag, 21. Mai 2007 23:16 schrieben Sie: On Mon, 21 May 2007, Oliver Neukum wrote: No. We are discussing what to do when the method doesn't exist, not what to do when it fails. In this situation we must assume the driver was working fine and it simply can't cope with a device reset. Ok, this narrowly put, my answer is: - don't autosuspend - on resume, disconnect the driver And then rebind the same driver back again? Essentially yes. Simply use the standard probe logic, no need for special casing. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Mon, 21 May 2007, Oliver Neukum wrote: Am Montag, 21. Mai 2007 23:16 schrieben Sie: On Mon, 21 May 2007, Oliver Neukum wrote: No. We are discussing what to do when the method doesn't exist, not what to do when it fails. In this situation we must assume the driver was working fine and it simply can't cope with a device reset. Ok, this narrowly put, my answer is: - don't autosuspend - on resume, disconnect the driver And then rebind the same driver back again? Essentially yes. Simply use the standard probe logic, no need for special casing. But what if the current driver got there in the first place by some sort of special casing? For that matter, what if the current driver is usbfs, by way of USBDEVFS_CLAIMINTERFACE? Hmmm, maybe the usbfs driver will need to have a reset_resume method; at the moment it doesn't even have suspend or resume. (But I don't know what any of them could do...) 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
Re: [linux-usb-devel] Patches still in the queue
On Wed, 16 May 2007, Oliver Neukum wrote: Am Dienstag, 15. Mai 2007 23:49 schrieb Alan Stern: On Tue, 15 May 2007, Oliver Neukum wrote: I think we're getting off the point here. Suppose the usbhid driver gets a powerloss_resume call for a mouse. What do you want it to do that we aren't already doing? Nothing. My point was that powerloss_resume() would be a benefit for every driver. Only that some drivers can't implement it. Okay. In very many cases it should be true that drivers won't try to verify a device's identify in powerloss_resume, since there isn't much they can check that the core hasn't checked already. In these cases powerloss_resume and reset_resume would do exactly the same things. Now consider cases where the driver does perform an identity check. Combine this with a previous remark you made: Devices with the reset_resume quirk are quite rare. Hence such drivers won't stand to lose much if they also do the identify check in reset_resume. Sure it would be unnecessary, but it wouldn't cost much and it would hardly ever happen. In other words, there's never any real reason for powerloss_resume and reset_resume to do different things. So there's no reason to have two separate methods. reset_resume will happen only because of the quirk. But when it happens during an autoresume, we cannot unbind the driver because we don't own the device lock. So what do you want to do then? This would need a separate thread. Yes. Along with all the complications of keeping track of references and making sure the thread gets flushed at the right time. But if a driver does not support reset_resume() and a device is quirky, why would you autosuspend in the first place? You would autosuspend a quirky device for the same reason you autosuspend a normal device: to save power. The fact that it needs a reset to resume isn't necessarily a drawback. I could add a check to prevent autosuspend for quirky devices with a driver that doesn't support reset_resume. Is this really needed? It seems to me that this issue arises only if reset_resume() returns an error. Is there a reason to treat this differently from resume() failing? On a system resume, we can unbind. The only reason to treat it differently is because it occurs in a different context. System resume is different from autoresume, most especially because autoresume is often invoked by the driver itself. When that happens, trying to unbind could lead to deadlock. 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
Re: [linux-usb-devel] Patches still in the queue
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
Re: [linux-usb-devel] Patches still in the queue
Am Dienstag, 15. Mai 2007 16:33 schrieb Alan Stern: On Tue, 15 May 2007, Oliver Neukum wrote: 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(). With the additional option of running tests to make sure that the device is indeed still the device it is supposed to be, eg reading out MAC. 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? Firstly, perhaps we should unbind if there's no post_reset(). Secondly, we are asking drivers to do something outside the spec. It's not against the spec, but by no means inside. There is a way to handle power failure in the spec, that is to reenumerate. Thirdly, in some error cases, you _will_ need to reenumerate anyway, eg. firmware gone, configuration cannot be restord, etc... Fourthly, some drivers cannot do it in principal, because they cannot restore a device's state, eg. printer, scanner, ... 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 You surely want to do this in single threaded manner before user space is unfrozen, don't you? 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? I think that locking matters only for autosuspend/resume. For pre/post_reset the caller initiating the reset should be responsible for locking the device. I don't see your line of reasoning here. Could you elaborate? Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Tue, 15 May 2007, Oliver Neukum wrote: Firstly, perhaps we should unbind if there's no post_reset(). Perhaps so. Secondly, we are asking drivers to do something outside the spec. It's not against the spec, but by no means inside. There is a way to handle power failure in the spec, that is to reenumerate. This is somewhat questionable. I can't find anything in the USB 2.0 spec that directly addresses this situation (maybe the OTG spec has something). But I do agree that it is contrary to the spirit of the spec. In any case, the reset-resume code _does_ reenumerate. So the situation is perhaps not as bad as you think. Thirdly, in some error cases, you _will_ need to reenumerate anyway, eg. firmware gone, configuration cannot be restord, etc... As I said, usb_reset_device() does reenumerate. It handles the examples you mention properly. Fourthly, some drivers cannot do it in principal, because they cannot restore a device's state, eg. printer, scanner, ... Yes. Conversely, some drivers don't care about it at all because they don't maintain any state in the device. 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 You surely want to do this in single threaded manner before user space is unfrozen, don't you? If we're talking about resuming from a system sleep, yes. But the same code paths get used in other circumstances. For example, you may remember the Philips audio device which needs to be reset because it can't resume -- it would get a reset_resume call during normal autoresume processing. Resets can occur whenever userspace requests them via usbfs, just as userspace can force a device to be suspended and resumed. So in any context we may face the possibility of a driver without a resume(), reset_resume(), or post_reset() method. I think that locking matters only for autosuspend/resume. For pre/post_reset the caller initiating the reset should be responsible for locking the device. I don't see your line of reasoning here. Could you elaborate? You are correct that autosuspend and autoresume are the only paths in which the device might not be locked. Hence rebinding a driver would be troublesome only in cases where the driver sets .supports_autosuspend and yet doesn't define both a resume() and a reset_resume() method. In such cases we could skip the rebinding. 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
Re: [linux-usb-devel] Patches still in the queue
Am Dienstag, 15. Mai 2007 20:40 schrieb Alan Stern: On Tue, 15 May 2007, Oliver Neukum wrote: Fourthly, some drivers cannot do it in principal, because they cannot restore a device's state, eg. printer, scanner, ... Yes. Conversely, some drivers don't care about it at all because they don't maintain any state in the device. That I doubt. There's always the relationship with open files. Usually eg. with mice you don't care because you use /dev/input/mice, but if for any reason you use a specific mouse, you care. You surely want to do this in single threaded manner before user space is unfrozen, don't you? If we're talking about resuming from a system sleep, yes. But the same code paths get used in other circumstances. For example, you may remember the Philips audio device which needs to be reset because it can't resume -- it would get a reset_resume call during normal autoresume processing. I think you are mixing things that shouldn't be. Recovery from a loss of power is different from getting reset for resume. In the latter case identity is not in doubt. Resets can occur whenever userspace requests them via usbfs, just as userspace can force a device to be suspended and resumed. So in any context we may face the possibility of a driver without a resume(), reset_resume(), or post_reset() method. Yes. But reset_resume() is another category. I think that locking matters only for autosuspend/resume. For pre/post_reset the caller initiating the reset should be responsible for locking the device. I don't see your line of reasoning here. Could you elaborate? You are correct that autosuspend and autoresume are the only paths in which the device might not be locked. Hence rebinding a driver would be troublesome only in cases where the driver sets .supports_autosuspend and yet doesn't define both a resume() and a A driver that does not resume() but autosuspend is buggy. Plain and simple. reset_resume() method. In such cases we could skip the rebinding. Indeed. But if we do that we must unbind. We can't have undead devices. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Tue, 15 May 2007, Oliver Neukum wrote: Am Dienstag, 15. Mai 2007 20:40 schrieb Alan Stern: On Tue, 15 May 2007, Oliver Neukum wrote: Fourthly, some drivers cannot do it in principal, because they cannot restore a device's state, eg. printer, scanner, ... Yes. Conversely, some drivers don't care about it at all because they don't maintain any state in the device. That I doubt. There's always the relationship with open files. Usually eg. with mice you don't care because you use /dev/input/mice, but if for any reason you use a specific mouse, you care. That relationship isn't stored in the device! Even if you use a specific mouse, you don't care if the mouse gets reset -- the usbhid driver won't need to restore any of the mouse's state. (Actually that's not quite true, because usbhid uses a set-idle request to prevent the device from sending updates when nothing has changed. The set-idle has to be repeated by the reset_resume method. But you know what I mean...) I think you are mixing things that shouldn't be. Recovery from a loss of power is different from getting reset for resume. In the latter case identity is not in doubt. So then do you want to add _two_ new methods: one for reset_resume and the other for powerloss_resume? If we do, reset_resume will be used only for devices with the USB_QUIRK_RESET_RESUME flag set. A driver that does not resume() but autosuspend is buggy. Plain and simple. reset_resume() method. In such cases we could skip the rebinding. Indeed. But if we do that we must unbind. We can't have undead devices. Not at all -- we should fix the driver! If it claims to support autosuspend then it should also be able to handle reset_resume without any need for rebinding. 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
Re: [linux-usb-devel] Patches still in the queue
Am Dienstag, 15. Mai 2007 22:03 schrieb Alan Stern: On Tue, 15 May 2007, Oliver Neukum wrote: Am Dienstag, 15. Mai 2007 20:40 schrieb Alan Stern: On Tue, 15 May 2007, Oliver Neukum wrote: Fourthly, some drivers cannot do it in principal, because they cannot restore a device's state, eg. printer, scanner, ... Yes. Conversely, some drivers don't care about it at all because they don't maintain any state in the device. That I doubt. There's always the relationship with open files. Usually eg. with mice you don't care because you use /dev/input/mice, but if for any reason you use a specific mouse, you care. That relationship isn't stored in the device! Even if you use a The physical identity of the device determines it. specific mouse, you don't care if the mouse gets reset -- the usbhid driver won't need to restore any of the mouse's state. But I do care about my device still being my device. A loss of power does affect that. I think you are mixing things that shouldn't be. Recovery from a loss of power is different from getting reset for resume. In the latter case identity is not in doubt. So then do you want to add _two_ new methods: one for reset_resume and the other for powerloss_resume? If we do, reset_resume will be used only for devices with the USB_QUIRK_RESET_RESUME flag set. Yes yes. Specific methods are good. A driver that does not resume() but autosuspend is buggy. Plain and simple. reset_resume() method. In such cases we could skip the rebinding. Indeed. But if we do that we must unbind. We can't have undead devices. Not at all -- we should fix the driver! If it claims to support autosuspend then it should also be able to handle reset_resume without any need for rebinding. Why? Or rather which kind? Quirky devices are very rare. Why would all drivers need to handle that? As for powerloss, a printer driver can never do that, as it cannot restore the printer's setting. Likewise anything claimed by usbfs. There are other examples. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Tue, 15 May 2007, Oliver Neukum wrote: Yes. Conversely, some drivers don't care about it at all because they don't maintain any state in the device. That I doubt. There's always the relationship with open files. Usually eg. with mice you don't care because you use /dev/input/mice, but if for any reason you use a specific mouse, you care. That relationship isn't stored in the device! Even if you use a The physical identity of the device determines it. specific mouse, you don't care if the mouse gets reset -- the usbhid driver won't need to restore any of the mouse's state. But I do care about my device still being my device. A loss of power does affect that. I think we're getting off the point here. Suppose the usbhid driver gets a powerloss_resume call for a mouse. What do you want it to do that we aren't already doing? Not at all -- we should fix the driver! If it claims to support autosuspend then it should also be able to handle reset_resume without any need for rebinding. Why? Or rather which kind? Quirky devices are very rare. Why would all drivers need to handle that? As for powerloss, a printer driver can never do that, as it cannot restore the printer's setting. Likewise anything claimed by usbfs. There are other examples. Two separate issues: reset_resume will happen only because of the quirk. But when it happens during an autoresume, we cannot unbind the driver because we don't own the device lock. So what do you want to do then? powerloss_resume will happen only when waking up from a system sleep, and since it won't be an autoresume we will own the device lock. Hence we will be able to rebind drivers. 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
Re: [linux-usb-devel] Patches still in the queue
Am Dienstag, 15. Mai 2007 23:49 schrieb Alan Stern: On Tue, 15 May 2007, Oliver Neukum wrote: I think we're getting off the point here. Suppose the usbhid driver gets a powerloss_resume call for a mouse. What do you want it to do that we aren't already doing? Nothing. My point was that powerloss_resume() would be a benefit for every driver. Only that some drivers can't implement it. Not at all -- we should fix the driver! If it claims to support autosuspend then it should also be able to handle reset_resume without any need for rebinding. Why? Or rather which kind? Quirky devices are very rare. Why would all drivers need to handle that? As for powerloss, a printer driver can never do that, as it cannot restore the printer's setting. Likewise anything claimed by usbfs. There are other examples. Two separate issues: reset_resume will happen only because of the quirk. But when it happens during an autoresume, we cannot unbind the driver because we don't own the device lock. So what do you want to do then? This would need a separate thread. But if a driver does not support reset_resume() and a device is quirky, why would you autosuspend in the first place? It seems to me that this issue arises only if reset_resume() returns an error. Is there a reason to treat this differently from resume() failing? On a system resume, we can unbind. powerloss_resume will happen only when waking up from a system sleep, and since it won't be an autoresume we will own the device lock. Hence we will be able to rebind drivers. Good. This method can potentially find out that it is running on the wrong device. The others cannot. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Mon, 14 May 2007, Oliver Neukum wrote: I agree. Hibernation with a mounted fs on usb sucks, no matter what you do. Don't forget that persistence applies to network interfaces just as much as to block devices. Yes, but it is not problematic, as you run no additional risk. The worst thing that could happen is that you assign an IP to the wrong interface. But if the driver can't tell apart devices, neither can udev. So you've got nothing to lose and a lot to gain. A driver has more information available to it than usbcore does. With a network interface, the driver might be able to distinguish two devices based on their MAC addresses, even when usbcore can't tell them apart. (I really should add Serial Number string checking to the config_descriptors_changed() routine...) However I admit it's hard to think up a scenario where this would matter significantly. I suggest a setting per interface in sysfs. That approach isn't feasible. For one thing, persistence applies to entire devices, not to interfaces. For another, we can't make a device persistent unless we also make all its ancestor hubs persistent. (If a hub disappears during resume then its children are destroyed too.) Well, we have again a distinction between device and interface persistance. Some drivers and therefore interfaces will be unable to support persistance. It must be possible to resurrect only some interfaces of a device. In other words, it must be possible for a driver's post_reset() method to fail. That's a separate email thread. On the core side persistance is asked for if a devices's interface or a device lower in the tree want persistance. While a per-device flag might be workable, I think the most straightforward approach is a single system-wide On/Off setting. Why? Treating a hard drive differently than a floppy seems very reasonable to me. Maybe so, but you're putting a burden on both the core and the user. The core would have to check, when resuming a hub, whether _any_ of the hub's descendants want to be persistent. It can be done but it's messy. And then the user has to decide, for every device that gets attached, whether or not it should be persistent. You know, this problem isn't even unique to USB. Suppose you have an IDE CDROM drive, with a disc loaded and mounted, when you hibernate. Suppose a different disc gets put in the drive before you resume -- then what happens to your mounted filesystem? It's a general problem and it needs to be handled at the filesystem layer. Adding USB persistence doesn't really make it any worse. 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
Re: [linux-usb-devel] Patches still in the queue
Am Montag, 14. Mai 2007 16:16 schrieb Alan Stern: Well, we have again a distinction between device and interface persistance. Some drivers and therefore interfaces will be unable to support persistance. It must be possible to resurrect only some interfaces of a device. In other words, it must be possible for a driver's post_reset() method to fail. That's a separate email thread. Worse. A driver may _lack_ a post_reset() method. On the core side persistance is asked for if a devices's interface or a device lower in the tree want persistance. While a per-device flag might be workable, I think the most straightforward approach is a single system-wide On/Off setting. Why? Treating a hard drive differently than a floppy seems very reasonable to me. Maybe so, but you're putting a burden on both the core and the user. The core would have to check, when resuming a hub, whether _any_ of the hub's descendants want to be persistent. It can be done but it's messy. And then the user has to decide, for every device that gets attached, whether or not it should be persistent. It is the same tree logic used to decide whether a hub can be suspended. I suggest solving it the same way. This feature _is_ dangerous. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Mon, 14 May 2007, Oliver Neukum wrote: Am Montag, 14. Mai 2007 16:16 schrieb Alan Stern: Well, we have again a distinction between device and interface persistance. Some drivers and therefore interfaces will be unable to support persistance. It must be possible to resurrect only some interfaces of a device. In other words, it must be possible for a driver's post_reset() method to fail. That's a separate email thread. 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. Maybe so, but you're putting a burden on both the core and the user. The core would have to check, when resuming a hub, whether _any_ of the hub's descendants want to be persistent. It can be done but it's messy. And then the user has to decide, for every device that gets attached, whether or not it should be persistent. It is the same tree logic used to decide whether a hub can be suspended. I suggest solving it the same way. This feature _is_ dangerous. It will be simpler to add a persist attribute for non-hub devices and always assume it is enabled for hubs. I don't think there's any downside to making hubs persistent. 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
Re: [linux-usb-devel] Patches still in the queue
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() It will be simpler to add a persist attribute for non-hub devices and always assume it is enabled for hubs. I don't think there's any downside to making hubs persistent. Good idea. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
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. 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
Re: [linux-usb-devel] Patches still in the queue
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. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
Am Samstag, 12. Mai 2007 21:26 schrieb Alan Stern: It could be controlled by both a Kconfig option and a writable module parameter. I'm not sure that would satisfy everybody. But maybe there _is_ no way to satisfy everyone... I agree. Hibernation with a mounted fs on usb sucks, no matter what you do. I suggest a setting per interface in sysfs. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Sun, 13 May 2007, Oliver Neukum wrote: Am Samstag, 12. Mai 2007 21:26 schrieb Alan Stern: It could be controlled by both a Kconfig option and a writable module parameter. I'm not sure that would satisfy everybody. But maybe there _is_ no way to satisfy everyone... I agree. Hibernation with a mounted fs on usb sucks, no matter what you do. Don't forget that persistence applies to network interfaces just as much as to block devices. I suggest a setting per interface in sysfs. That approach isn't feasible. For one thing, persistence applies to entire devices, not to interfaces. For another, we can't make a device persistent unless we also make all its ancestor hubs persistent. (If a hub disappears during resume then its children are destroyed too.) While a per-device flag might be workable, I think the most straightforward approach is a single system-wide On/Off setting. 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
Re: [linux-usb-devel] Patches still in the queue
On Sat, May 12, 2007 at 03:26:19PM -0400, Alan Stern wrote: On Fri, 11 May 2007, Greg KH wrote: Can you suggest a better way of packaging it to help support the distros? I'm perfectly willing to change the way USB-persist gets enabled, to insure that people don't turn it on unless they really mean to. Is there any way to turn it on at run-time? That would be better for everyone involved so that the feature will always be present and no rebuilding of kernels is needed. Ha! When I first started working on this stuff, it was controlled by a module parameter. Dave Brownell objected then because there was no way for distros to turn it off! Well, as long as we make it so that root access is required to turn it on, and we spit out some nasty meesage to the kernel log when it is disabled, I don't mind. It could be controlled by both a Kconfig option and a writable module parameter. I'm not sure that would satisfy everybody. But maybe there _is_ no way to satisfy everyone... That sounds reasonable, I don't object to that. thanks, greg k-h - 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
Re: [linux-usb-devel] Patches still in the queue
Am Sonntag, 13. Mai 2007 17:15 schrieb Alan Stern: On Sun, 13 May 2007, Oliver Neukum wrote: Am Samstag, 12. Mai 2007 21:26 schrieb Alan Stern: It could be controlled by both a Kconfig option and a writable module parameter. I'm not sure that would satisfy everybody. But maybe there _is_ no way to satisfy everyone... I agree. Hibernation with a mounted fs on usb sucks, no matter what you do. Don't forget that persistence applies to network interfaces just as much as to block devices. Yes, but it is not problematic, as you run no additional risk. The worst thing that could happen is that you assign an IP to the wrong interface. But if the driver can't tell apart devices, neither can udev. So you've got nothing to lose and a lot to gain. I suggest a setting per interface in sysfs. That approach isn't feasible. For one thing, persistence applies to entire devices, not to interfaces. For another, we can't make a device persistent unless we also make all its ancestor hubs persistent. (If a hub disappears during resume then its children are destroyed too.) Well, we have again a distinction between device and interface persistance. Some drivers and therefore interfaces will be unable to support persistance. It must be possible to resurrect only some interfaces of a device. On the core side persistance is asked for if a devices's interface or a device lower in the tree want persistance. While a per-device flag might be workable, I think the most straightforward approach is a single system-wide On/Off setting. Why? Treating a hard drive differently than a floppy seems very reasonable to me. Regards Oliver - 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
Re: [linux-usb-devel] Patches still in the queue
On Fri, May 11, 2007 at 10:05:49AM -0400, Alan Stern wrote: On Thu, 10 May 2007, Greg KH wrote: On Thu, May 10, 2007 at 02:10:07PM -0400, Alan Stern wrote: Greg: You have applied most of the patches I sent, but not the USB-persist ones. Any particular reason? The main reason is that I'm still on the road, and I really want to spend the time and test those patches, as I'm still not sure about the use of them. I'm scared because this is not an option that a distro can enable in their releases, and that bad things can happen to people's data if they are not careful. Also I feel that the number of legit users for such a thing is so small that I wonder if it is really worth it. Can you suggest a better way of packaging it to help support the distros? I'm perfectly willing to change the way USB-persist gets enabled, to insure that people don't turn it on unless they really mean to. Is there any way to turn it on at run-time? That would be better for everyone involved so that the feature will always be present and no rebuilding of kernels is needed. It's surprising to hear you bring up the small number of legit users! You're on record as saying that the kernel includes code and drivers which exist to support only one or two machines in the whole world. :-) Yes, as long as those drivers and code don't break other users :) This could cause data loss for users who do not fully realize it, and so, the distros will not enable the feature, so people who might want to really use it, will have a very hard time of it. Making it able to be switched on at run-time, should help with that problem. I'll repackage it and resubmit just the infrastructure and quirks part, leaving the rest for later. Thanks, that would be great. Note that I'm going to be away from an internet connection until some-time Monday, due to travel issues. thanks, greg k-h - 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
Re: [linux-usb-devel] Patches still in the queue
On Fri, 11 May 2007, Greg KH wrote: Can you suggest a better way of packaging it to help support the distros? I'm perfectly willing to change the way USB-persist gets enabled, to insure that people don't turn it on unless they really mean to. Is there any way to turn it on at run-time? That would be better for everyone involved so that the feature will always be present and no rebuilding of kernels is needed. Ha! When I first started working on this stuff, it was controlled by a module parameter. Dave Brownell objected then because there was no way for distros to turn it off! It could be controlled by both a Kconfig option and a writable module parameter. I'm not sure that would satisfy everybody. But maybe there _is_ no way to satisfy everyone... 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
Re: [linux-usb-devel] Patches still in the queue
On Thu, 10 May 2007, Greg KH wrote: On Thu, May 10, 2007 at 02:10:07PM -0400, Alan Stern wrote: Greg: You have applied most of the patches I sent, but not the USB-persist ones. Any particular reason? The main reason is that I'm still on the road, and I really want to spend the time and test those patches, as I'm still not sure about the use of them. I'm scared because this is not an option that a distro can enable in their releases, and that bad things can happen to people's data if they are not careful. Also I feel that the number of legit users for such a thing is so small that I wonder if it is really worth it. Can you suggest a better way of packaging it to help support the distros? I'm perfectly willing to change the way USB-persist gets enabled, to insure that people don't turn it on unless they really mean to. It's surprising to hear you bring up the small number of legit users! You're on record as saying that the kernel includes code and drivers which exist to support only one or two machines in the whole world. :-) So these are still in my queue, I just want to give them some serious scrutiny. Okay. Suggestions for improvements are welcome. The infrastructure added for USB-persist is also used for a new type of quirks entry (devices which need to be reset when they resume). Would you prefer it if I separate out that common infrastructure and send it along with the quirks code first? Then adding USB-persist on top would be a relatively small change. Sure, if you want to rework it that way, I was holding off applying those other patches as the dependancy was there. If by doing that, we get that new feature in sooner, it would probably be much better. I'll repackage it and resubmit just the infrastructure and quirks part, leaving the rest for later. 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
Re: [linux-usb-devel] Patches still in the queue
On Thu, May 10, 2007 at 02:10:07PM -0400, Alan Stern wrote: Greg: You have applied most of the patches I sent, but not the USB-persist ones. Any particular reason? The main reason is that I'm still on the road, and I really want to spend the time and test those patches, as I'm still not sure about the use of them. I'm scared because this is not an option that a distro can enable in their releases, and that bad things can happen to people's data if they are not careful. Also I feel that the number of legit users for such a thing is so small that I wonder if it is really worth it. So these are still in my queue, I just want to give them some serious scrutiny. The infrastructure added for USB-persist is also used for a new type of quirks entry (devices which need to be reset when they resume). Would you prefer it if I separate out that common infrastructure and send it along with the quirks code first? Then adding USB-persist on top would be a relatively small change. Sure, if you want to rework it that way, I was holding off applying those other patches as the dependancy was there. If by doing that, we get that new feature in sooner, it would probably be much better. thanks, greg k-h - 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
