This patch (as861) adds sysfs attributes to expose the autosuspend
delay value for each USB device. If the user changes the delay from 0
(no autosuspend) to a positive value, an autosuspend is attempted.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb-2.6/drivers/usb/core/sysfs.c
=
On Tue, Feb 20, 2007 at 03:03:32PM -0500, Alan Stern wrote:
> This patch (as861) adds sysfs attributes to expose the autosuspend
> delay value for each USB device. If the user changes the delay from 0
> (no autosuspend) to a positive value, an autosuspend is attempted.
But if a user changes the v
On Fri, 23 Feb 2007, Greg KH wrote:
> On Tue, Feb 20, 2007 at 03:03:32PM -0500, Alan Stern wrote:
> > This patch (as861) adds sysfs attributes to expose the autosuspend
> > delay value for each USB device. If the user changes the delay from 0
> > (no autosuspend) to a positive value, an autosuspe
On Fri, Feb 23, 2007 at 06:44:27PM -0500, Alan Stern wrote:
> On Fri, 23 Feb 2007, Greg KH wrote:
>
> > On Tue, Feb 20, 2007 at 03:03:32PM -0500, Alan Stern wrote:
> > > This patch (as861) adds sysfs attributes to expose the autosuspend
> > > delay value for each USB device. If the user changes t
On Fri, 23 Feb 2007, Greg KH wrote:
> > The gist of it runs like this: The autosuspend attribute file controls
> > when & whether autosuspend events will occur. If you set it to 0 then
> > there will be no more autosuspend events. Devices that are awake will
> > remain awake and devices that are
On Fri, Feb 23, 2007 at 07:08:29PM -0500, Alan Stern wrote:
> On Fri, 23 Feb 2007, Greg KH wrote:
>
> > > The gist of it runs like this: The autosuspend attribute file controls
> > > when & whether autosuspend events will occur. If you set it to 0 then
> > > there will be no more autosuspend even
On Fri, 23 Feb 2007, Greg KH wrote:
> > Part of the development I did with Oliver was to add a .../power/suspended
> > attribute for USB devices. Writing 1 would immediately suspend the device
> > and writing 0 would immediately resume it. Should I submit that part as a
> > separate new patch
On Friday 23 February 2007 5:05 pm, Alan Stern wrote:
> On Fri, 23 Feb 2007, Greg KH wrote:
> > I have heard rumors that both Intel and mvista are starting to dig up
> > the old patches and want to get this stuff all sorted out and into the
> > main kernel tree. Hopefully something comes of it...
Am Samstag, 24. Februar 2007 01:08 schrieb Alan Stern:
> > > (although this is deprecated and will vanish in July -- we may want to add
> > > a new attribute file just for USB devices so that people won't lose the
> > > ability to do selective suspends and resumes). Even if you are just a
> > > no
On Sun, 25 Feb 2007, Oliver Neukum wrote:
> Coming to think of it, maybe the confusion could be avoided, if
> zero were accepted as a permissible value for autosuspend delay.
> Is there a reason there has to be a delay?
Yes. It's a bad idea to in general to disable any resource as soon as you
a
Am Sonntag, 25. Februar 2007 17:43 schrieb Alan Stern:
> On Sun, 25 Feb 2007, Oliver Neukum wrote:
>
> > Coming to think of it, maybe the confusion could be avoided, if
> > zero were accepted as a permissible value for autosuspend delay.
> > Is there a reason there has to be a delay?
>
> Yes. It
On Sun, 25 Feb 2007, Oliver Neukum wrote:
> Am Sonntag, 25. Februar 2007 17:43 schrieb Alan Stern:
> > On Sun, 25 Feb 2007, Oliver Neukum wrote:
> >
> > > Coming to think of it, maybe the confusion could be avoided, if
> > > zero were accepted as a permissible value for autosuspend delay.
> > > I
Am Sonntag, 25. Februar 2007 23:43 schrieb Alan Stern:
> On Sun, 25 Feb 2007, Oliver Neukum wrote:
>
> > Am Sonntag, 25. Februar 2007 17:43 schrieb Alan Stern:
> > > On Sun, 25 Feb 2007, Oliver Neukum wrote:
> > >
> > > > Coming to think of it, maybe the confusion could be avoided, if
> > > > zer
Am Sonntag, 25. Februar 2007 23:43 schrieb Alan Stern:
> It just doesn't seem like a useful capability. What harm will it do to
> suspend a USB device after 1 second rather than right away? It's hard to
> imagine a situation where you would really want to do that.
To elaborate a bit. You want
On Mon, 26 Feb 2007, Oliver Neukum wrote:
> > It just doesn't seem like a useful capability. What harm will it do to
> > suspend a USB device after 1 second rather than right away? It's hard to
>
> What harm will the opposite do? User settings exist to let the user do
> as he pleases. Embedded
On Fri, Feb 23, 2007 at 06:23:08PM -0800, David Brownell wrote:
> On Friday 23 February 2007 5:05 pm, Alan Stern wrote:
> > On Fri, 23 Feb 2007, Greg KH wrote:
>
> > > I have heard rumors that both Intel and mvista are starting to dig up
> > > the old patches and want to get this stuff all sorted
On Fri, Feb 23, 2007 at 08:05:57PM -0500, Alan Stern wrote:
> On Fri, 23 Feb 2007, Greg KH wrote:
>
> > > Part of the development I did with Oliver was to add a
> > > .../power/suspended
> > > attribute for USB devices. Writing 1 would immediately suspend the
> > > device
> > > and writing 0
Am Montag, 26. Februar 2007 03:37 schrieb Alan Stern:
> On Mon, 26 Feb 2007, Oliver Neukum wrote:
> Next you'll be saying that people will want to specify the delay more
> precisely than the nearest second...
Am I that predictable? It occured to me, but the process takes so long
that it makes li
On Mon, 26 Feb 2007, Oliver Neukum wrote:
> Am Montag, 26. Februar 2007 03:37 schrieb Alan Stern:
> > On Mon, 26 Feb 2007, Oliver Neukum wrote:
>
> > Next you'll be saying that people will want to specify the delay more
> > precisely than the nearest second...
>
> Am I that predictable? It occu
Am Montag, 26. Februar 2007 17:03 schrieb Alan Stern:
> On Mon, 26 Feb 2007, Oliver Neukum wrote:
> I agree, except for one thing. If the delay is set to 0, we might still
> want to use a very short delay. For one thing, queue_delayed_work() with
> a zero delay won't do anything until the next c
On Mon, 26 Feb 2007, Oliver Neukum wrote:
> If you want to specify it in milliseconds, I have no objections. Other times
> are also given in those units.
Seconds are easier, except in this one case where you want a value less
than 1 second. I'm inclined not to worry about it and keep things
si
Am Montag, 26. Februar 2007 18:37 schrieb Alan Stern:
> > - don't do an immediate suspend independent of autosuspend
>
> Why not? In extreme cases the user can force an immediate suspend by
> doing suspend-to-RAM anyway. This merely preserves the capability we are
> about to lose when the powe
Am Montag, 26. Februar 2007 18:37 schrieb Alan Stern:
> > a) The kernel will (or rather should) export its oppinion whether a device
> > should be suspended (eg. from the blacklist or set by a driver)
>
> Be careful in your choice of words. Do you mean "suspended" or
> "autosuspended"? The kerne
On Mon, 26 Feb 2007, Oliver Neukum wrote:
> Am Montag, 26. Februar 2007 18:37 schrieb Alan Stern:
> > > - don't do an immediate suspend independent of autosuspend
> >
> > Why not? In extreme cases the user can force an immediate suspend by
> > doing suspend-to-RAM anyway. This merely preserves
On Tuesday 27 February 2007 10:47 am, Alan Stern wrote:
> On Mon, 26 Feb 2007, Oliver Neukum wrote:
> The main reason for deprecating power/state was that it did not have the
> necessary expressive power. Different buses have different sets of power
> states and requirements (sometimes individual
Am Dienstag, 27. Februar 2007 20:10 schrieb David Brownell:
> > > > WE ALWAYS WAKE UP ON DEMAND!
> > >
> > > Why? Repeating the assertion doesn't make it any more logical.
> >
> > What's illogical about always waking up on demand?
>
> Nothing at all -- right Oliver?
Well, it is
On Tuesday 27 February 2007 2:05 pm, Oliver Neukum wrote:
> Am Dienstag, 27. Februar 2007 20:10 schrieb David Brownell:
> > > > > WE ALWAYS WAKE UP ON DEMAND!
> > > >
> > > > Why? Repeating the assertion doesn't make it any more logical.
> > >
> > > What's illogical about always w
Am Dienstag, 27. Februar 2007 23:12 schrieb David Brownell:
> On Tuesday 27 February 2007 2:05 pm, Oliver Neukum wrote:
> > Am Dienstag, 27. Februar 2007 20:10 schrieb David Brownell:
> > > > > > WE ALWAYS WAKE UP ON DEMAND!
> > > > >
> > > > > Why? Repeating the assertion doesn't
Am Dienstag, 27. Februar 2007 19:47 schrieb Alan Stern:
> On Mon, 26 Feb 2007, Oliver Neukum wrote:
> > STR/D freeeze user space, thus making additional guarantees we wouldn't
> > meet. power/state is being obsoleted.
>
> We can't meet those additional guarantees when doing an autosuspend
> eith
On Wed, 28 Feb 2007, Oliver Neukum wrote:
> > The main reason for deprecating power/state was that it did not have the
> > necessary expressive power. Different buses have different sets of power
> > states and requirements (sometimes individual devices do too), but
> > power/state only allowed f
Am Mittwoch, 28. Februar 2007 19:44 schrieb Alan Stern:
> As David mentioned, there are also other reasons for getting rid of
> power/state.
Then I suggest that we go through to make sure we don't repeat them.
> We never came to a solution partly because people have all sorts of
> varying requ
On Thu, 1 Mar 2007, Oliver Neukum wrote:
> Am Mittwoch, 28. Februar 2007 19:44 schrieb Alan Stern:
>
> > As David mentioned, there are also other reasons for getting rid of
> > power/state.
>
> Then I suggest that we go through to make sure we don't repeat them.
As I recall, none of them (or a
On Sunday 25 February 2007 9:29 pm, Greg KH wrote:
> That's what Documentation/ABI/ is there for :)
Someone snuck that in while I wasn't looking, it seems ... ;)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join Sou
Am Donnerstag, 1. März 2007 21:07 schrieb Alan Stern:
> On Thu, 1 Mar 2007, Oliver Neukum wrote:
> > There is no uniform user space. IO requests originate from different users
> > and sometimes the kernel itself. You cannot assume that the priviledge to do
> > IO with a device at the time open() (
On Thu, Mar 01, 2007 at 01:18:56PM -0800, David Brownell wrote:
> On Sunday 25 February 2007 9:29 pm, Greg KH wrote:
>
> > That's what Documentation/ABI/ is there for :)
>
> Someone snuck that in while I wasn't looking, it seems ... ;)
Unfortunatly, you aren't the only one who missed that, despi
On Thu, 1 Mar 2007, Oliver Neukum wrote:
> Down an interface and it stays down. Suspend an interface and it ...
... and it stays suspended until the kernel tries to send a packet out
through that interface or until a packet is received (assuming proper
hardware wakeup support is available and ena
Am Freitag, 2. März 2007 17:27 schrieb Alan Stern:
> On Thu, 1 Mar 2007, Oliver Neukum wrote:
>
> > Down an interface and it stays down. Suspend an interface and it ...
>
> ... and it stays suspended until the kernel tries to send a packet out
> through that interface or until a packet is receive
On Fri, 2 Mar 2007, Oliver Neukum wrote:
> Have a delay attribute per interface and give each device an attribute
> "SuspensionState" with the permissible values "on", "auto" & "suspend"
> Handle RemoteWakeup as an orthogonal issue.
We could even arrange things so that writing "suspend" will caus
On Fri, 2 Mar 2007, Oliver Neukum wrote:
> Have a delay attribute per interface and give each device an attribute
> "SuspensionState" with the permissible values "on", "auto" & "suspend"
> Handle RemoteWakeup as an orthogonal issue.
After some more thinking...
As you say, remote wakeup is an ort
Am Montag, 5. März 2007 20:45 schrieb Alan Stern:
> On Fri, 2 Mar 2007, Oliver Neukum wrote:
>
> > Have a delay attribute per interface and give each device an attribute
> > "SuspensionState" with the permissible values "on", "auto" & "suspend"
> > Handle RemoteWakeup as an orthogonal issue.
>
>
On Tue, 6 Mar 2007, Oliver Neukum wrote:
> > As you say, remote wakeup is an orthogonal issue. So if remote wakeup is
> > enabled when the user writes "suspend" to the attribute, the device will
> > wakeup when an external event occurs. If not, it won't.
>
> OK, so we have two attributes "Can
Am Dienstag, 6. März 2007 16:50 schrieb Alan Stern:
> On Tue, 6 Mar 2007, Oliver Neukum wrote:
> Actually we have a single attribute, named "wakeup". If the descriptor
> says that remote wakeup isn't available then the attribute file is empty
> and is ro. If the descriptor says remote wakeup i
On Thu, 8 Mar 2007, Oliver Neukum wrote:
> > All right, maybe it wouldn't if you did it for a short time -- but then
> > what would be the point? Surely if you want to power down the network
> > interface and leave it that way, you must realize that you can't keep
> > live sessions bound to the i
Am Donnerstag, 8. März 2007 16:57 schrieb Alan Stern:
> On Thu, 8 Mar 2007, Oliver Neukum wrote:
>
> > > All right, maybe it wouldn't if you did it for a short time -- but then
> > > what would be the point? Surely if you want to power down the network
> > > interface and leave it that way, you m
On Fri, 9 Mar 2007, Oliver Neukum wrote:
> Am Donnerstag, 8. März 2007 16:57 schrieb Alan Stern:
> > On Thu, 8 Mar 2007, Oliver Neukum wrote:
> >
> > > > All right, maybe it wouldn't if you did it for a short time -- but then
> > > > what would be the point? Surely if you want to power down the
Am Freitag, 9. März 2007 20:50 schrieb Alan Stern:
> On Fri, 9 Mar 2007, Oliver Neukum wrote:
>
> > Am Donnerstag, 8. März 2007 16:57 schrieb Alan Stern:
> > > What happens when the opposite end of a network connection tries to send
> > > data to a suspended system? Yes, TCP is pretty aggressiv
On Fri, 9 Mar 2007, Oliver Neukum wrote:
> > I'm still not sure how good an idea it is. But let's say we do it.
> > Then the new power/level attribute file would have 4 possible values:
> >
> > on, auto, suspend, and suspend-without-autoresume
>
> Why? What's the difference to remote wakeup
47 matches
Mail list logo
