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
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
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
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.
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
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
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
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:
-
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
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
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
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.
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
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
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
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
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
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
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
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
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,
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
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,
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
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
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
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.
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
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
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
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?
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
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
33 matches
Mail list logo
