error to be returned while suspended

error to be returned while suspended

[Oliver Neukum]

Hi,

which error should a character device return if a read/write cannot be
serviced because the device is suspended? Shouldn't there be an error
code specific to that?

	Regards
		Oliver

Re: error to be returned while suspended

[linux-os (Dick Johnson)]

On Tue, 3 Oct 2006, Oliver Neukum wrote:

> Hi,
>
> which error should a character device return if a read/write cannot be
> serviced because the device is suspended? Shouldn't there be an error
> code specific to that?
>
> 	Regards
> 		Oliver

The de-facto error codes were created long before one could "suspend"
a device, so there isn't a ESUSP code. However, I suggest EIO or EBUSY
unless you want to define an ESUSP and get it accepted by the POSIX
committee.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.72 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: error to be returned while suspended

[Oliver Neukum]

Am Dienstag, 3. Oktober 2006 14:51 schrieb linux-os (Dick Johnson):
> 
> On Tue, 3 Oct 2006, Oliver Neukum wrote:
> 
> > Hi,
> >
> > which error should a character device return if a read/write cannot be
> > serviced because the device is suspended? Shouldn't there be an error
> > code specific to that?
> >
> > 	Regards
> > 		Oliver
> 
> The de-facto error codes were created long before one could "suspend"
> a device, so there isn't a ESUSP code. However, I suggest EIO or EBUSY

CUPS chokes on these. Is it acceptable to say that you should know
what you're doing when suspending?

> unless you want to define an ESUSP and get it accepted by the POSIX
> committee.

This would be the cleanest solution. How does one do that?

	Regards
		Oliver

Re: error to be returned while suspended

[linux-os (Dick Johnson)]

On Tue, 3 Oct 2006, Oliver Neukum wrote:

> Am Dienstag, 3. Oktober 2006 14:51 schrieb linux-os (Dick Johnson):
>>
>> On Tue, 3 Oct 2006, Oliver Neukum wrote:
>>
>>> Hi,
>>>
>>> which error should a character device return if a read/write cannot be
>>> serviced because the device is suspended? Shouldn't there be an error
>>> code specific to that?
>>>
>>> 	Regards
>>> 		Oliver
>>
>> The de-facto error codes were created long before one could "suspend"
>> a device, so there isn't a ESUSP code. However, I suggest EIO or EBUSY
>
> CUPS chokes on these. Is it acceptable to say that you should know
> what you're doing when suspending?
>

Well, you need to look at the CUPS documentation and find out
what return code would be non-fatal and tell it to buffer stuff
to try later (such as the return code you get when the printer
if off-line).

 	http://www.cups.org/documentation.php

>> unless you want to define an ESUSP and get it accepted by the POSIX
>> committee.
>

Even if you did that, CUPS would have to be modified to accept
the new error code. There should be a current error code that
will allow CUPS to continue.

> This would be the cleanest solution. How does one do that?
>
> 	Regards
> 		Oliver
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.72 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: error to be returned while suspended

[Pavel Machek]

On Tue 2006-10-03 13:23:00, Oliver Neukum wrote:
> Hi,
> 
> which error should a character device return if a read/write cannot be
> serviced because the device is suspended? Shouldn't there be an error
> code specific to that?

If you are talking system suspend, then userspace should not run while
devices are suspended.

If you are talking runtime suspend, you should probably just wake the
device up on first access.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: error to be returned while suspended

[Oliver Neukum]

Am Mittwoch, 4. Oktober 2006 13:19 schrieb Pavel Machek:
> On Tue 2006-10-03 13:23:00, Oliver Neukum wrote:
> > Hi,
> > 
> > which error should a character device return if a read/write cannot be
> > serviced because the device is suspended? Shouldn't there be an error
> > code specific to that?
> 
> If you are talking system suspend, then userspace should not run while
> devices are suspended.
> 
> If you are talking runtime suspend, you should probably just wake the
> device up on first access.

Do you really think a device driver should override an explicitely
selected power state?

	Regards
		Oliver

Re: error to be returned while suspended

[Pavel Machek]

Hi!

> > > which error should a character device return if a read/write cannot be
> > > serviced because the device is suspended? Shouldn't there be an error
> > > code specific to that?
> > 
> > If you are talking system suspend, then userspace should not run while
> > devices are suspended.
> > 
> > If you are talking runtime suspend, you should probably just wake the
> > device up on first access.
> 
> Do you really think a device driver should override an explicitely
> selected power state?

(So we are talking runtime suspend?)

No, I do not know what the right interface is. I started to suspect
that drivers should suspend/resume devices automatically, without
userland help. Maybe having autosuspend_timeout in sysfs is enough.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: error to be returned while suspended

[Oliver Neukum]

Am Donnerstag, 5. Oktober 2006 00:44 schrieben Sie:
> Hi!
> 
> > > > which error should a character device return if a read/write cannot be
> > > > serviced because the device is suspended? Shouldn't there be an error
> > > > code specific to that?
> > > 
> > > If you are talking system suspend, then userspace should not run while
> > > devices are suspended.
> > > 
> > > If you are talking runtime suspend, you should probably just wake the
> > > device up on first access.
> > 
> > Do you really think a device driver should override an explicitely
> > selected power state?
> 
> (So we are talking runtime suspend?)

Yes. Otherwise the patch would have been ready two days ago.
But if I am implenting this, I'll do a full implementation.

> No, I do not know what the right interface is. I started to suspect
> that drivers should suspend/resume devices automatically, without
> userland help. Maybe having autosuspend_timeout in sysfs is enough.

If you do this at kernel level, you'll screw up any demon implementing
a power policy to stay within the budget.

	Regards
		Oliver

Re: error to be returned while suspended

[Pavel Machek]

Hi!

> > (So we are talking runtime suspend?)
> 
> Yes. Otherwise the patch would have been ready two days ago.
> But if I am implenting this, I'll do a full implementation.
> 
> > No, I do not know what the right interface is. I started to suspect
> > that drivers should suspend/resume devices automatically, without
> > userland help. Maybe having autosuspend_timeout in sysfs is enough.
> 
> If you do this at kernel level, you'll screw up any demon implementing
> a power policy to stay within the budget.

Well, in case of machine where "must get approval before you can use
printer"... just do exactly that. Make userland ask approval of
powerbudgetd before it opens /dev/lp0.

It will only be neccessary on very small machines, anyway.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] error to be returned while suspended

[Alan Stern]

On Thu, 5 Oct 2006, Oliver Neukum wrote:

> > > > If you are talking runtime suspend, you should probably just wake the
> > > > device up on first access.
> > > 
> > > Do you really think a device driver should override an explicitely
> > > selected power state?
> > 
> > (So we are talking runtime suspend?)
> 
> Yes. Otherwise the patch would have been ready two days ago.
> But if I am implenting this, I'll do a full implementation.
> 
> > No, I do not know what the right interface is. I started to suspect
> > that drivers should suspend/resume devices automatically, without
> > userland help. Maybe having autosuspend_timeout in sysfs is enough.
> 
> If you do this at kernel level, you'll screw up any demon implementing
> a power policy to stay within the budget.

Currently we don't have any userspace APIs for such a daemon to use.  The 
only existing API is deprecated and will go away soon.

Current thinking is that a driver will suspend its device whenever the 
device isn't in use.  With usblp, that would be whenever the device file 
isn't open.  See the example code in usb-skeleton.c.

Alan Stern

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
> Currently we don't have any userspace APIs for such a daemon to use.  The 
> only existing API is deprecated and will go away soon.

I trust it'll be replaced.

> Current thinking is that a driver will suspend its device whenever the 
> device isn't in use.  With usblp, that would be whenever the device file 
> isn't open.  See the example code in usb-skeleton.c.

In the general case the idea seems insufficient. If I close my laptop's lid
I want all input devices suspended, whether the corresponding files are
opened or not. In fact, if I have port level power control I might even
want to cut power to them.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Alan Stern]

On Thu, 5 Oct 2006, Oliver Neukum wrote:

> Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
> > Currently we don't have any userspace APIs for such a daemon to use.  The 
> > only existing API is deprecated and will go away soon.
> 
> I trust it'll be replaced.

Yes.  I think Greg wants to wait until the old API is completely gone.

> > Current thinking is that a driver will suspend its device whenever the 
> > device isn't in use.  With usblp, that would be whenever the device file 
> > isn't open.  See the example code in usb-skeleton.c.
> 
> In the general case the idea seems insufficient. If I close my laptop's lid
> I want all input devices suspended, whether the corresponding files are
> opened or not. In fact, if I have port level power control I might even
> want to cut power to them.

That's a separate issue.  You were talking about runtime suspend, but 
closing the laptop's lid is a system suspend.

Assuming some sort of mechanism is in place to do a suspend-to-RAM or 
suspend-to-disk when the lid is closed, the driver's suspend and resume 
methods will be called in the normal way.  The driver doesn't need to do 
anything special to accomodate it.

The only special thing you need to do is autosuspend when the device isn't
in use, so that even when the laptop's lid is open you can still avoid
using unnecessary power.

Alan Stern

P.S.: Cutting off port power is yet another issue.  It isn't a suspend in 
the strict sense, because it will break an existing power session.

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Donnerstag, 5. Oktober 2006 20:24 schrieb Alan Stern:
> On Thu, 5 Oct 2006, Oliver Neukum wrote:
> 
> > Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
> > > Currently we don't have any userspace APIs for such a daemon to use.  The 
> > > only existing API is deprecated and will go away soon.
> > 
> > I trust it'll be replaced.
> 
> Yes.  I think Greg wants to wait until the old API is completely gone.

I doubt it will. There's a potential need.

[..]
> > In the general case the idea seems insufficient. If I close my laptop's lid
> > I want all input devices suspended, whether the corresponding files are
> > opened or not. In fact, if I have port level power control I might even
> > want to cut power to them.
> 
> That's a separate issue.  You were talking about runtime suspend, but 
> closing the laptop's lid is a system suspend.

Why? If you freeze my batch jobs or make unavailable the servers
running on my laptop I'd be very unhappy.
But I want to make jostling a mouse or other input device safe. Thus
I want them to be suspended without autoresume. We need flexibility.

[..]
> P.S.: Cutting off port power is yet another issue.  It isn't a suspend in 
> the strict sense, because it will break an existing power session.

Yes, it is an additional more complicated option.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Alan Stern]

On Thu, 5 Oct 2006, Oliver Neukum wrote:

> [..]
> > > In the general case the idea seems insufficient. If I close my laptop's lid
> > > I want all input devices suspended, whether the corresponding files are
> > > opened or not. In fact, if I have port level power control I might even
> > > want to cut power to them.
> > 
> > That's a separate issue.  You were talking about runtime suspend, but 
> > closing the laptop's lid is a system suspend.
> 
> Why?

Normally people expect that shutting the lid on a laptop will cause it to 
go to sleep.  If you want different behavior, that's okay too...

> If you freeze my batch jobs or make unavailable the servers
> running on my laptop I'd be very unhappy.
> But I want to make jostling a mouse or other input device safe. Thus
> I want them to be suspended without autoresume. We need flexibility.

So you want a mode in which the input devices are suspended without remote 
wakeup.  Remote wakeup settings are configurable via 
/sys/devices/.../power/wakeup.  At this point nobody has settled on a
new API for suspending the devices.  It's quite possible that different 
drivers or different buses will use their own individual APIs.

Alan Stern

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Donnerstag, 5. Oktober 2006 22:48 schrieb Alan Stern:
> On Thu, 5 Oct 2006, Oliver Neukum wrote:
[..] 
> > If you freeze my batch jobs or make unavailable the servers
> > running on my laptop I'd be very unhappy.
> > But I want to make jostling a mouse or other input device safe. Thus
> > I want them to be suspended without autoresume. We need flexibility.
> 
> So you want a mode in which the input devices are suspended without remote 
> wakeup.  Remote wakeup settings are configurable via 
> /sys/devices/.../power/wakeup.  At this point nobody has settled on a
> new API for suspending the devices.  It's quite possible that different 
> drivers or different buses will use their own individual APIs.

I have a few observations, but no solution either:
- if root tells a device to suspend, it shall do so
- the issues of manual & automatic suspend and remote wakeup are orthogonal
- there should be a common API for all devices
- there's no direct connection between power save and open()

The question when a device is in use is far from trivial.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Alan Stern]

On Thu, 5 Oct 2006, Oliver Neukum wrote:

> I have a few observations, but no solution either:
> - if root tells a device to suspend, it shall do so

Probably everyone will agree on that.

> - the issues of manual & automatic suspend and remote wakeup are orthogonal

Except for the fact that remote wakeup kicks in only when a device is 
suspended.

> - there should be a common API for all devices

It would be nice, wouldn't it?  But we _already_ have several vastly
different power-management APIs.  Consider for example DPMI and IDE 
spindown.

> - there's no direct connection between power save and open()

Why shouldn't a device always be put into a power-saving mode whenever it 
isn't open?  Agreed, you might want to reduce its power usage at times 
even when it is open...

> The question when a device is in use is far from trivial.

Yes.  It has to be decided by each individual driver.  For simple 
character-oriented devices, "open" is a good first start.

Alan Stern

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Donnerstag, 5. Oktober 2006 23:45 schrieb Alan Stern:
> On Thu, 5 Oct 2006, Oliver Neukum wrote:
> 
> > I have a few observations, but no solution either:
> > - if root tells a device to suspend, it shall do so
> 
> Probably everyone will agree on that.

But should it stay suspended until explictely resumed? Do we have
consensus on that?

> > - the issues of manual & automatic suspend and remote wakeup are orthogonal
> 
> Except for the fact that remote wakeup kicks in only when a device is 
> suspended.

Yes.
 
> > - there should be a common API for all devices
> 
> It would be nice, wouldn't it?  But we _already_ have several vastly
> different power-management APIs.  Consider for example DPMI and IDE 
> spindown.

No reason to make matters worse.
 
> > - there's no direct connection between power save and open()
> 
> Why shouldn't a device always be put into a power-saving mode whenever it 
> isn't open?  Agreed, you might want to reduce its power usage at times 
> even when it is open...

That and you are putting the latency/power choice into kernel space.
I've seen GPS recievers that need 30 seconds to get a fix. Autosuspend
needs to be in kernel space. But that doesn't mean that it is sufficient
as a mechanism nor that it doesn't need parameters supplied from
user space.

> > The question when a device is in use is far from trivial.
> 
> Yes.  It has to be decided by each individual driver.  For simple 
> character-oriented devices, "open" is a good first start.

Yes. However, simple character devices are the first candidates for
libusb so kernel space is left with the hard cases.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Alan Stern]

On Fri, 6 Oct 2006, Oliver Neukum wrote:

> Am Donnerstag, 5. Oktober 2006 23:45 schrieb Alan Stern:
> > On Thu, 5 Oct 2006, Oliver Neukum wrote:
> > 
> > > I have a few observations, but no solution either:
> > > - if root tells a device to suspend, it shall do so
> > 
> > Probably everyone will agree on that.
> 
> But should it stay suspended until explictely resumed? Do we have
> consensus on that?

If remote wakeup is disabled, the device will remain suspended until 
something tells it to wake up.

> > > - there should be a common API for all devices
> > 
> > It would be nice, wouldn't it?  But we _already_ have several vastly
> > different power-management APIs.  Consider for example DPMI and IDE 
> > spindown.
> 
> No reason to make matters worse.

Yes, there is.  Consider that in many cases (think especially of embedded 
platforms) devices have more than 2 power states, on or suspended.  That's 
true even for PCI and ATA.  Each sort of bus has its own set of possible 
power states, and it's hopeless to try and unify them.

> > > - there's no direct connection between power save and open()
> > 
> > Why shouldn't a device always be put into a power-saving mode whenever it 
> > isn't open?  Agreed, you might want to reduce its power usage at times 
> > even when it is open...
> 
> That and you are putting the latency/power choice into kernel space.
> I've seen GPS recievers that need 30 seconds to get a fix. Autosuspend
> needs to be in kernel space. But that doesn't mean that it is sufficient
> as a mechanism nor that it doesn't need parameters supplied from
> user space.

Like I said, drivers need to make their own individual choices.  
Suspending during "close" may not always be best for all devices.  But for
many it is acceptable and a lot better than nothing.

Alan Stern

Re: [linux-usb-devel] error to be returned while suspended

[Pavel Machek]

On Thu 2006-10-05 17:45:25, Alan Stern wrote:
> On Thu, 5 Oct 2006, Oliver Neukum wrote:
> 
> > I have a few observations, but no solution either:
> > - if root tells a device to suspend, it shall do so
> 
> Probably everyone will agree on that.

Not sure... I'm not sure if root is in business of telling devices
what to do...

> > - there's no direct connection between power save and open()

...if you want to suspend device X, close its device file/ifconfig it
down/hdparm -y it.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] error to be returned while suspended

[David Brownell]

On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:

> - the issues of manual & automatic suspend and remote wakeup are orthogonal
> - there should be a common API for all devices

AFAIK there is no demonstrated need for an API to suspend
individual devices.  Of course there's the question of who
would _use_ such a thing (some unspecified component, worth
designing one first), but drivers can use internal runtime
suspend mechanisms to be in low power modes and hide that
fact from the rest of the system.  That is, activate on
demand, suspend when idle.

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Freitag, 6. Oktober 2006 04:47 schrieb David Brownell:
> On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
> 
> > - the issues of manual & automatic suspend and remote wakeup are orthogonal
> > - there should be a common API for all devices
> 
> AFAIK there is no demonstrated need for an API to suspend
> individual devices.  Of course there's the question of who
> would _use_ such a thing (some unspecified component, worth
> designing one first), but drivers can use internal runtime
> suspend mechanisms to be in low power modes and hide that
> fact from the rest of the system.  That is, activate on
> demand, suspend when idle.

I doubt that a lot. Eg. Again, if I close the lid I may want my USB
network cards be suspended or not and that decision might change several
times a day. It's a policy decision in many cases. And I'd not be happy
with being required to down the interfaces to do so. Suspension should
be as transparent as possible.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Pavel Machek]

On Fri 2006-10-06 09:04:51, Oliver Neukum wrote:
> Am Freitag, 6. Oktober 2006 04:47 schrieb David Brownell:
> > On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
> > 
> > > - the issues of manual & automatic suspend and remote wakeup are orthogonal
> > > - there should be a common API for all devices
> > 
> > AFAIK there is no demonstrated need for an API to suspend
> > individual devices.  Of course there's the question of who
> > would _use_ such a thing (some unspecified component, worth
> > designing one first), but drivers can use internal runtime
> > suspend mechanisms to be in low power modes and hide that
> > fact from the rest of the system.  That is, activate on
> > demand, suspend when idle.
> 
> I doubt that a lot. Eg. Again, if I close the lid I may want my USB
> network cards be suspended or not and that decision might change several
> times a day. It's a policy decision in many cases. And I'd not be
> happy

If you want your usb network card suspended... there's perfectly fine
interface to do that. It is called "ifconfig usbeth0 down".

> with being required to down the interfaces to do so. Suspension should
> be as transparent as possible.

What you want is fairly hard to implement in kernel, and it is not
clear if it is kernel job after all. "Transparent" is nice, but
"simple kernel code" is nice, too.

If you have very simple&easy&nice&transparent kernel code that can do
what you want, fine; but maybe we want to trade "transparent" for
"KISS".

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Freitag, 6. Oktober 2006 13:27 schrieben Sie:
> > with being required to down the interfaces to do so. Suspension should
> > be as transparent as possible.
> 
> What you want is fairly hard to implement in kernel, and it is not
> clear if it is kernel job after all. "Transparent" is nice, but
> "simple kernel code" is nice, too.
> 
> If you have very simple&easy&nice&transparent kernel code that can do
> what you want, fine; but maybe we want to trade "transparent" for
> "KISS".

It seems to me that a network driver needs to have the ability to drop
packets onto the floor while disconnect() is running. In the case of
a disconnection triggered by usbfs a lack of this ability is a race condition.
I've done an implementation of kaweth which allows suspending the interface
while it is alive.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[David Brownell]

On Friday 06 October 2006 12:04 am, Oliver Neukum wrote:
> Am Freitag, 6. Oktober 2006 04:47 schrieb David Brownell:
> > On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
> > 
> > > - the issues of manual & automatic suspend and remote wakeup are orthogonal
> > > - there should be a common API for all devices
> > 
> > AFAIK there is no demonstrated need for an API to suspend
> > individual devices.  ...
> 
> I doubt that a lot. 

You haven't demonstrated such a need either; so why doubt it?


> Eg. Again, if I close the lid I may want my USB 
> network cards be suspended 

If "close lid" means system suspend, then you _do_ want that
(by definition of system suspend).  If that doesn't trigger
system suspend, then it's up to you to decide whether or not
you "ifdown eth1" or not ... as with non-USB network adapters.

Likewise with autosuspending of network devices, which I'd
actually like to see happen.  Starting in 2.6.19-rc, the USB
drivers could be updated to do that, as I understand ... at
least for hardware that has sane remote wakeup capabilities.
No point in having host controllers doing nothing except
polling a USB network adapter, unless there's actually some
traffic directed to that host!


> or not and that decision might change several 
> times a day. It's a policy decision in many cases. And I'd not be happy
> with being required to down the interfaces to do so.

Lots of us would be even more unhappy to see USB network adapters
be made to follow different rules than non-USB ones.

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Freitag, 6. Oktober 2006 23:10 schrieb David Brownell:
> On Friday 06 October 2006 12:04 am, Oliver Neukum wrote:
> > Am Freitag, 6. Oktober 2006 04:47 schrieb David Brownell:
> > > On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
> > > 
> > > > - the issues of manual & automatic suspend and remote wakeup are orthogonal
> > > > - there should be a common API for all devices
> > > 
> > > AFAIK there is no demonstrated need for an API to suspend
> > > individual devices.  ...
> > 
> > I doubt that a lot. 
> 
> You haven't demonstrated such a need either; so why doubt it?

OK, let me state the basics.

To get real power savings, we:
- blank the display
- spin down the hard drive
- put the CPU into an ACPI sleep state

To do the latter well, we need to make sure there's no DMA. It is
important that less or little DMA will not help. We need no DMA.
So we need to handle the commonest scenarios fully.

I dare say that the commonest scenario involving USB is a laptop with
an input device attached. Input devices are for practical purposes always
opened. A simple resume upon open and suspend upon close is useless.

Now you could et X (and gpm, etc...) to close the device after some
timeout. However, if you do so, you arrive at the counterintuitive
situation that you have to enable remote wakeup for a closed device
and the added complication that you need to generate and propagate
wakeup events. Allowing X to explicitely suspend on opened device is
simpler and more flexible. Furthermore, such a model can be extended
to keyboards.

[..]
> Likewise with autosuspending of network devices, which I'd
> actually like to see happen.  Starting in 2.6.19-rc, the USB
> drivers could be updated to do that, as I understand ... at
> least for hardware that has sane remote wakeup capabilities.
> No point in having host controllers doing nothing except
> polling a USB network adapter, unless there's actually some
> traffic directed to that host!

That's true, but insufficient.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Pavel Machek]

Hi!

> > > > > - the issues of manual & automatic suspend and remote wakeup are orthogonal
> > > > > - there should be a common API for all devices
> > > > 
> > > > AFAIK there is no demonstrated need for an API to suspend
> > > > individual devices.  ...
> > > 
> > > I doubt that a lot. 
> > 
> > You haven't demonstrated such a need either; so why doubt it?
> 
> OK, let me state the basics.
> 
> To get real power savings, we:
> - blank the display
> - spin down the hard drive
> - put the CPU into an ACPI sleep state
> 
> To do the latter well, we need to make sure there's no DMA. It is
> important that less or little DMA will not help. We need no DMA.
> So we need to handle the commonest scenarios fully.
> 
> I dare say that the commonest scenario involving USB is a laptop with
> an input device attached. Input devices are for practical purposes always
> opened. A simple resume upon open and suspend upon close is useless.

Okay, but you can simply do autosuspend with remote wakeup completely
inside input driver. You do ot need it to be controlled from X... at
most you need one variable ('autosuspend_inactivity_timeout')
controlled from userland.

That's what we already do for hdd spindown... you simply tell disk to
aitospindown after X seconds of inactivity.
							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Samstag, 7. Oktober 2006 13:08 schrieb Pavel Machek:
> Hi!
> 
> > > > > > - the issues of manual & automatic suspend and remote wakeup are orthogonal
> > > > > > - there should be a common API for all devices
> > > > > 
> > > > > AFAIK there is no demonstrated need for an API to suspend
> > > > > individual devices.  ...
> > > > 
> > > > I doubt that a lot. 
> > > 
> > > You haven't demonstrated such a need either; so why doubt it?
> > 
> > OK, let me state the basics.
> > 
> > To get real power savings, we:
> > - blank the display
> > - spin down the hard drive
> > - put the CPU into an ACPI sleep state
> > 
> > To do the latter well, we need to make sure there's no DMA. It is
> > important that less or little DMA will not help. We need no DMA.
> > So we need to handle the commonest scenarios fully.
> > 
> > I dare say that the commonest scenario involving USB is a laptop with
> > an input device attached. Input devices are for practical purposes always
> > opened. A simple resume upon open and suspend upon close is useless.
> 
> Okay, but you can simply do autosuspend with remote wakeup completely
> inside input driver. You do ot need it to be controlled from X... at
> most you need one variable ('autosuspend_inactivity_timeout')
> controlled from userland.
> 
> That's what we already do for hdd spindown... you simply tell disk to
> aitospindown after X seconds of inactivity.

The firmware in the drive supplies this function. It's hardly by choice
that it is made available. The power management functions without
timeout are also exported. For other power control features like
cpu frequency considerable effort has been made to export them to
user space.

A simple timeout solution has drawbacks.

- there's no guarantee the user wants wakeup (think laptop on crowded table)
- you want to suspend immediately when you blank the screen (or switch to
a text console)
- you want to consider all devices' activity. I am not pleased if my mouse
becomes less responsive just because I used only the keyboard for a
few minutes. Coordinating this inside the driver is hard as some input
devices might well be not usb (eg. bluetooth mouse, usb tablet)

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[David Brownell]

On Saturday 07 October 2006 10:16 am, Oliver Neukum wrote:

> > > I dare say that the commonest scenario involving USB is a laptop with
> > > an input device attached. Input devices are for practical purposes always
> > > opened. A simple resume upon open and suspend upon close is useless.

That is, the standard model is useless?  I think you've made
a few strange leaps of logic there ... care to fill in those
gaps and explain just _why_ that standard model is "useless"???

Recall by the way that the autosuspend stuff kicked off with
discussions about exactly how to make sure that Linux could
get the power savings inherent in suspending USB root hubs,
with remote wakeup enabling use of the mouse on that keyboard.
(I remember Len Brown talking to me a few years back about how
that was the "last" 2W per controller easily available to save
power on Centrino laptops ... now we're almost ready to claim
that savings.)


> > Okay, but you can simply do autosuspend with remote wakeup completely
> > inside input driver. You do ot need it to be controlled from X... at
> > most you need one variable ('autosuspend_inactivity_timeout')
> > controlled from userland.
> > 
> > That's what we already do for hdd spindown... you simply tell disk to
> > aitospindown after X seconds of inactivity.
> 
> The firmware in the drive supplies this function. It's hardly by choice
> that it is made available.

Sure it is.  Nobody had to write that code.  Of course, Pavel was
skipping some details too ... "laptop_mode" kicks some other system
controls so that the disk drive isn't accessed so much.


> The power management functions without 
> timeout are also exported. For other power control features like
> cpu frequency considerable effort has been made to export them to
> user space.

Yes, and many of us use the much lighter weight kernel based control
models by preference.   Why waste hundreds of Kbytes of userspace for
a daemon when a few hundred bytes of kernel code can implement a
better and more reactive kernel policy for cpufreq?


> A simple timeout solution has drawbacks.

Plus lots of advantages, including the not-to-be-underrated simplicity.

> - there's no guarantee the user wants wakeup (think laptop on crowded table)

In which case the /sys/devices/.../power/wakeup flag can be
marked as disabled.  No wakeup ... but of course, no power
savings either.  (One can still unplug the mouse...)

> - you want to suspend immediately when you blank the screen (or switch to
> a text console)

Unrelated to USB or any other specific subsystem; the system
suspends by "echo mem > /sys/power/state" regardless.  (That is,
once the bugs in ACPI, and sometimes drivers, get fixed.)

> - you want to consider all devices' activity. I am not pleased if my mouse
> becomes less responsive just because I used only the keyboard for a
> few minutes. Coordinating this inside the driver is hard as some input
> devices might well be not usb (eg. bluetooth mouse, usb tablet)

The reasons X11 becomes unresponsive have very little to do with USB
or autosuspend; happens all the time with PS2 mice, trackpads, etc.
Again, those issues are unrelated to USB, or to the API you said you
wanted to see.

Re: [linux-usb-devel] error to be returned while suspended

[Alan Stern]

On Sat, 7 Oct 2006, David Brownell wrote:

> On Saturday 07 October 2006 10:16 am, Oliver Neukum wrote:
> 
> > > > I dare say that the commonest scenario involving USB is a laptop with
> > > > an input device attached. Input devices are for practical purposes always
> > > > opened. A simple resume upon open and suspend upon close is useless.

You are distorting what I said.  The "resume upon open and suspend upon
close" scheme was not intended for things like input devices, which are
more or less permanently open.  It was intended for things like
fingerprint readers or printers, which spend most of their time not being
used.

> That is, the standard model is useless?  I think you've made
> a few strange leaps of logic there ... care to fill in those
> gaps and explain just _why_ that standard model is "useless"???
> 
> Recall by the way that the autosuspend stuff kicked off with
> discussions about exactly how to make sure that Linux could
> get the power savings inherent in suspending USB root hubs,
> with remote wakeup enabling use of the mouse on that keyboard.
> (I remember Len Brown talking to me a few years back about how
> that was the "last" 2W per controller easily available to save
> power on Centrino laptops ... now we're almost ready to claim
> that savings.)

The most obvious model for suspending keyboards or mice is an inactivity 
timeout (with the timeout limit set from userspace), but other policies 
certainly could be useful in specific circumstances.

Considering that we have virtually no autosuspend capability now, taking
the first few simple steps will be a big help.  Just getting an
infrastructure in place is a good start, even without a userspace API.  
Later on, when we have a better idea of what we want, bells and whistles
can be added.

Even Oliver has admitted that the implementation issues are very tricky 
and he doesn't know the best approach to take.

Alan Stern

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Sonntag, 8. Oktober 2006 04:03 schrieb Alan Stern:
> On Sat, 7 Oct 2006, David Brownell wrote:
> 
> > On Saturday 07 October 2006 10:16 am, Oliver Neukum wrote:
> > 
> > > > > I dare say that the commonest scenario involving USB is a laptop with
> > > > > an input device attached. Input devices are for practical purposes always
> > > > > opened. A simple resume upon open and suspend upon close is useless.
> 
> You are distorting what I said.  The "resume upon open and suspend upon

Sorry.

> close" scheme was not intended for things like input devices, which are
> more or less permanently open.  It was intended for things like
> fingerprint readers or printers, which spend most of their time not being
> used.

OK.

> > That is, the standard model is useless?  I think you've made
> > a few strange leaps of logic there ... care to fill in those
> > gaps and explain just _why_ that standard model is "useless"???
> > 
> > Recall by the way that the autosuspend stuff kicked off with
> > discussions about exactly how to make sure that Linux could
> > get the power savings inherent in suspending USB root hubs,
> > with remote wakeup enabling use of the mouse on that keyboard.
> > (I remember Len Brown talking to me a few years back about how
> > that was the "last" 2W per controller easily available to save
> > power on Centrino laptops ... now we're almost ready to claim
> > that savings.)
> 
> The most obvious model for suspending keyboards or mice is an inactivity 
> timeout (with the timeout limit set from userspace), but other policies 
> certainly could be useful in specific circumstances.

The simplicity is much reduced if each class of devices needs to have
its own method of determining activity. And if you don't find a good way
for some devices, users with these are out in the rain and can do nothing
about it if suspension cannot be triggered from user space.

> Considering that we have virtually no autosuspend capability now, taking
> the first few simple steps will be a big help.  Just getting an

No question about that.

> infrastructure in place is a good start, even without a userspace API.  
> Later on, when we have a better idea of what we want, bells and whistles
> can be added.

I've never said that autosuspend is a bad idea. For many devices it is
simple and painless. But it is insufficient. Therefore I think removing
the ability to explicitely request a suspension from user space is wrong.

> Even Oliver has admitted that the implementation issues are very tricky 
> and he doesn't know the best approach to take.

If so many people cannot come up with a good design, doesn't that indicate
there's no single method that satisfies all needs?

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Alan Stern]

On Sun, 8 Oct 2006, Oliver Neukum wrote:

> I've never said that autosuspend is a bad idea. For many devices it is
> simple and painless. But it is insufficient. Therefore I think removing
> the ability to explicitely request a suspension from user space is wrong.

I tend to agree.  And I expect we _will_ end up with a userspace interface 
for suspending some devices.  Other devices, like USB hubs, have no need 
of such an interface (other than for testing, perhaps).

The reason for removing the current interface is just that it is so bad.  
Look how confused you were when you saw it recently.  Values are 0, 2, and
3, 3 automatically gets changed to 2,...  There isn't even any way for a
driver to tell whether a suspend message is a runtime request from
userspace or a system sleep transition notification!

> If so many people cannot come up with a good design, doesn't that indicate
> there's no single method that satisfies all needs?

Probably.  That's why I've been saying all along that these things need to 
be decided by the individual drivers.  No single design will be 
appropriate for all of them.

Alan Stern

Re: [linux-usb-devel] error to be returned while suspended

[Pavel Machek]

Hi!

> > That is, the standard model is useless?  I think you've made
> > a few strange leaps of logic there ... care to fill in those
> > gaps and explain just _why_ that standard model is "useless"???
> > 
> > Recall by the way that the autosuspend stuff kicked off with
> > discussions about exactly how to make sure that Linux could
> > get the power savings inherent in suspending USB root hubs,
> > with remote wakeup enabling use of the mouse on that keyboard.
> > (I remember Len Brown talking to me a few years back about how
> > that was the "last" 2W per controller easily available to save
> > power on Centrino laptops ... now we're almost ready to claim
> > that savings.)
> 
> The most obvious model for suspending keyboards or mice is an inactivity 
> timeout (with the timeout limit set from userspace), but other policies 
> certainly could be useful in specific circumstances.
> 
> Considering that we have virtually no autosuspend capability now, taking
> the first few simple steps will be a big help.  Just getting an
> infrastructure in place is a good start, even without a userspace API.  
> Later on, when we have a better idea of what we want, bells and whistles
> can be added.

<AOL>Mee too</AOL>

Please, lets do few "autosuspend" things, and when we know how it
looks, we can think about doing something more advanced.

								Pavel 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Sonntag, 8. Oktober 2006 21:36 schrieb Pavel Machek:
> <AOL>Mee too</AOL>
> 
> Please, lets do few "autosuspend" things, and when we know how it
> looks, we can think about doing something more advanced.

Very well, which drivers do you want first?

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Pavel Machek]

On Sun 2006-10-08 21:57:17, Oliver Neukum wrote:
> Am Sonntag, 8. Oktober 2006 21:36 schrieb Pavel Machek:
> > <AOL>Mee too</AOL>
> > 
> > Please, lets do few "autosuspend" things, and when we know how it
> > looks, we can think about doing something more advanced.
> 
> Very well, which drivers do you want first?

USB mouse would be very nice first step. Way less usb keyboards are
used, and that would be very nice second step.

If you want to try something different, autosuspending SATA can save
about 1W on my machine...

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Sonntag, 8. Oktober 2006 02:03 schrieben Sie:
> On Saturday 07 October 2006 10:16 am, Oliver Neukum wrote:
> 
> > > > I dare say that the commonest scenario involving USB is a laptop with
> > > > an input device attached. Input devices are for practical purposes always
> > > > opened. A simple resume upon open and suspend upon close is useless.
> 
> That is, the standard model is useless?  I think you've made
> a few strange leaps of logic there ... care to fill in those
> gaps and explain just _why_ that standard model is "useless"???

If a device is always opened, as mice are, it will not be suspended.
Yet they can be without any data to deliver forever.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[David Brownell]

On Saturday 07 October 2006 11:40 pm, Oliver Neukum wrote:
> Am Sonntag, 8. Oktober 2006 02:03 schrieben Sie:
> > On Saturday 07 October 2006 10:16 am, Oliver Neukum wrote:
> > 
> > > > > I dare say that the commonest scenario involving USB is a laptop with
> > > > > an input device attached. Input devices are for practical purposes always
> > > > > opened. A simple resume upon open and suspend upon close is useless.
> > 
> > That is, the standard model is useless?  I think you've made
> > a few strange leaps of logic there ... care to fill in those
> > gaps and explain just _why_ that standard model is "useless"???
> 
> If a device is always opened, as mice are, it will not be suspended.

Of course it wiill be suspended, as part of system-wide suspend.
That's the standard model.

> Yet they can be without any data to deliver forever.

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Sonntag, 8. Oktober 2006 02:03 schrieb David Brownell:
> > A simple timeout solution has drawbacks.
> 
> Plus lots of advantages, including the not-to-be-underrated simplicity.

That simplicity means setting up timers in kernel space and determining when
a device is "active". You only simplify the interface.

> > - there's no guarantee the user wants wakeup (think laptop on crowded table)
> 
> In which case the /sys/devices/.../power/wakeup flag can be
> marked as disabled.  No wakeup ... but of course, no power
> savings either.  (One can still unplug the mouse...)

I can have suspend without wakeup. It just means that I need to
hit a key to make X notice me again.

> > - you want to suspend immediately when you blank the screen (or switch to
> > a text console)
> 
> Unrelated to USB or any other specific subsystem; the system

That is exactly the point.

> suspends by "echo mem > /sys/power/state" regardless.  (That is,
> once the bugs in ACPI, and sometimes drivers, get fixed.)

What allows you to assume that I want to suspend the whole system?
That power/latency tradeoff is not a policy to be set in kernel.

> > - you want to consider all devices' activity. I am not pleased if my mouse
> > becomes less responsive just because I used only the keyboard for a
> > few minutes. Coordinating this inside the driver is hard as some input
> > devices might well be not usb (eg. bluetooth mouse, usb tablet)
> 
> The reasons X11 becomes unresponsive have very little to do with USB
> or autosuspend; happens all the time with PS2 mice, trackpads, etc.
> Again, those issues are unrelated to USB, or to the API you said you
> wanted to see.

I did not speak about X11. I can keep X pretty busy with keyboard and
touchpad. Nevertheless my mouse has no business going to sleep even
if I don't move it and it is the only usb device.

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Sonntag, 8. Oktober 2006 02:03 schrieb David Brownell:
> On Saturday 07 October 2006 10:16 am, Oliver Neukum wrote:
> 
> > > > I dare say that the commonest scenario involving USB is a laptop with
> > > > an input device attached. Input devices are for practical purposes always
> > > > opened. A simple resume upon open and suspend upon close is useless.
> 
> That is, the standard model is useless?  I think you've made

To be precise a simple implementation of autosuspend is useless.
The idea can be expanded as I wrote if you care to read a bit further.
But still I find the idea to have drawbacks for input devices.

That is not to say that autosuspend is bad in all cases, but there are
unavoidable cases in which it is not optimal, which leads me to conclude
that suspension for a device must remain triggerable from user space.

	Regards
		Oliver
 

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Sonntag, 8. Oktober 2006 02:03 schrieb David Brownell:
> > The power management functions without 
> > timeout are also exported. For other power control features like
> > cpu frequency considerable effort has been made to export them to
> > user space.
> 
> Yes, and many of us use the much lighter weight kernel based control
> models by preference.   Why waste hundreds of Kbytes of userspace for
> a daemon when a few hundred bytes of kernel code can implement a
> better and more reactive kernel policy for cpufreq?

That's an important aspect. How about implementing autosuspend
first and keeping the sysfs-based suspension for now? If autosuspend
is done, we have something to compare too. If a different solution
emerges to be advantagous under some conditions we can talk about
the interface later.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Alan Stern]

On Sun, 8 Oct 2006, Oliver Neukum wrote:

> That's an important aspect. How about implementing autosuspend
> first and keeping the sysfs-based suspension for now? If autosuspend
> is done, we have something to compare too. If a different solution
> emerges to be advantagous under some conditions we can talk about
> the interface later.

Well, autosuspend for USB is on its way.  There are just a few bugs
remaining in my changes to ehci-hcd.  They should be ironed out soon and 
then Greg will merge it.

The existing sysfs power/state implementation isn't going away
immediately.  It is deprecated and scheduled for removal in July 2007.

Alan Stern

/sys/.../power/state Re: [linux-usb-devel] error to be returned while suspended

[Pavel Machek]

Hi!

> > > The power management functions without 
> > > timeout are also exported. For other power control features like
> > > cpu frequency considerable effort has been made to export them to
> > > user space.
> > 
> > Yes, and many of us use the much lighter weight kernel based control
> > models by preference.   Why waste hundreds of Kbytes of userspace for
> > a daemon when a few hundred bytes of kernel code can implement a
> > better and more reactive kernel policy for cpufreq?
> 
> That's an important aspect. How about implementing autosuspend
> first and keeping the sysfs-based suspension for now? If autosuspend

Current sysfs-based suspension allows people to do bad stuff to
drivers, like confusing them, oopsing them, etc. It is so broken that
it can not be fixed. (When I suspend my USB this way, I end up with
dead USB. When I suspend my sound card, I get any soundcard users in
unrecoverable D state.)

Now... you can prove me wrong, but that likely means auditing all the
drivers with suspend() and/or resume() methods. I'm not prepared to do
that work... are you?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] error to be returned while suspended

[Pavel Machek]

Hi!

> > > OK, let me state the basics.
> > > 
> > > To get real power savings, we:
> > > - blank the display
> > > - spin down the hard drive
> > > - put the CPU into an ACPI sleep state
> > > 
> > > To do the latter well, we need to make sure there's no DMA. It is
> > > important that less or little DMA will not help. We need no DMA.
> > > So we need to handle the commonest scenarios fully.
> > > 
> > > I dare say that the commonest scenario involving USB is a laptop with
> > > an input device attached. Input devices are for practical purposes always
> > > opened. A simple resume upon open and suspend upon close is useless.
> > 
> > Okay, but you can simply do autosuspend with remote wakeup completely
> > inside input driver. You do ot need it to be controlled from X... at
> > most you need one variable ('autosuspend_inactivity_timeout')
> > controlled from userland.
> > 
> > That's what we already do for hdd spindown... you simply tell disk to
> > aitospindown after X seconds of inactivity.
> 
> The firmware in the drive supplies this function. It's hardly by choice
> that it is made available. The power management functions without
> timeout are also exported. For other power control features like
> cpu frequency considerable effort has been made to export them to
> user space.
> 
> A simple timeout solution has drawbacks.
> 
> - there's no guarantee the user wants wakeup (think laptop on
> crowded table)

If you do not want wakeups (=> do not want any input from that
device), then close that device.

> - you want to suspend immediately when you blank the screen (or switch to
> a text console)

I kind-of understand "when you blank", but I do not think this
mandatory. Why would you want to suspend when switching to text
console? Am I no longer allowed to use gpm?

> - you want to consider all devices' activity. I am not pleased if my mouse
> becomes less responsive just because I used only the keyboard for a
> few minutes. Coordinating this inside the driver is hard as some input
> devices might well be not usb (eg. bluetooth mouse, usb tablet)

Yep, that would be nice; but not at price of /sys/.../power/state like
monstrosity that never ever worked properly.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum]

Am Sonntag, 8. Oktober 2006 09:20 schrieb David Brownell:
> > If a device is always opened, as mice are, it will not be suspended.
> > Yet they can be without any data to deliver forever.
> 
> In 2.6.19-rc1 read Documentation/power/devices.txt about runtime
> suspend states.  Then think about how why mouse in a runtime suspend
> state, with remote wakeup enabled, looks externally ** EXACTLY ** like
> a mouse that's fully active ....

I've done so. And I've read the HID spec. It just says that a mouse
may support remote wakeup, not what should wake it up. A device
that wakes only if a button is clicked is within spec.

	Regards
		Oliver

Re: [linux-usb-devel] error to be returned while suspended

[Dmitry Torokhov]

On Sunday 08 October 2006 04:39, Oliver Neukum wrote:
> Am Sonntag, 8. Oktober 2006 09:20 schrieb David Brownell:
> > > If a device is always opened, as mice are, it will not be suspended.
> > > Yet they can be without any data to deliver forever.
> > 
> > In 2.6.19-rc1 read Documentation/power/devices.txt about runtime
> > suspend states.  Then think about how why mouse in a runtime suspend
> > state, with remote wakeup enabled, looks externally ** EXACTLY ** like
> > a mouse that's fully active ....
> 
> I've done so. And I've read the HID spec. It just says that a mouse
> may support remote wakeup, not what should wake it up. A device
> that wakes only if a button is clicked is within spec.
> 

And that's what some devices do. Apologies for a non-USB example, but
since we are talking about input devices and it would be nice to have
the rules consistent across all hardware interfaces I think it's OK...
Synaptics PS/2 touchpad can be put into a sleep mode where it only
reacts on button presses. While this behavior is reasonable for system-
wide suspend it would hardly work for autosuspend.

-- 
Dmitry

Re: [linux-usb-devel] error to be returned while suspended

[Pavel Machek]

On Thu 2006-10-05 20:43:59, Oliver Neukum wrote:
> Am Donnerstag, 5. Oktober 2006 20:24 schrieb Alan Stern:
> > On Thu, 5 Oct 2006, Oliver Neukum wrote:
> > 
> > > Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
> > > > Currently we don't have any userspace APIs for such a daemon to use.  The 
> > > > only existing API is deprecated and will go away soon.
> > > 
> > > I trust it'll be replaced.
> > 
> > Yes.  I think Greg wants to wait until the old API is completely gone.
> 
> I doubt it will. There's a potential need.

"potential". OTOH functionality this provides is fairly hard to do, so
you need to be really interested...

> [..]
> > > In the general case the idea seems insufficient. If I close my laptop's lid
> > > I want all input devices suspended, whether the corresponding files are
> > > opened or not. In fact, if I have port level power control I might even
> > > want to cut power to them.
> > 
> > That's a separate issue.  You were talking about runtime suspend, but 
> > closing the laptop's lid is a system suspend.
> 
> Why? If you freeze my batch jobs or make unavailable the servers
> running on my laptop I'd be very unhappy.
> But I want to make jostling a mouse or other input device safe. Thus
> I want them to be suspended without autoresume. We need flexibility.

You are not doing power saving, you are going "ignore input devices
when (condition)". That is useful for other cases, too, like touchpad
should be ignored when user is typing.

This belongs either to input subsystem or to X server...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] error to be returned while suspended

[Pavel Machek]

On Thu 2006-10-05 18:35:21, Oliver Neukum wrote:
> Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
> > Currently we don't have any userspace APIs for such a daemon to use.  The 
> > only existing API is deprecated and will go away soon.
> 
> I trust it'll be replaced.

It does not seem that API was that useful after all.

> > Current thinking is that a driver will suspend its device whenever the 
> > device isn't in use.  With usblp, that would be whenever the device file 
> > isn't open.  See the example code in usb-skeleton.c.
> 
> In the general case the idea seems insufficient. If I close my laptop's lid
> I want all input devices suspended, whether the corresponding files are
> opened or not. In fact, if I have port level power control I might even
> want to cut power to them.

I do not see how this is useful.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html