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
> > > > > w
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 drive
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
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 i
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 dis
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 w
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 yo
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 separ
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 autod
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 stan
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
> > t
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 tha
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 yo
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
> > > > resto
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. Conv
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 t
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, tha
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:
> 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 p
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
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 l
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 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
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
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 addition
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 mayb
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
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.
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 w
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
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?
>
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
>
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 n
Greg:
You have applied most of the patches I sent, but not the "USB-persist"
ones. Any particular reason?
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
34 matches
Mail list logo
