[RFC] Disabling Devices

[RFC] Disabling Devices

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]


One potentially important aspect of power management is the ability for the
user to disable a device that he or she does not intend to use.  Our current
model does not allow for this.  Calling PMSG_SUSPEND won't cut it, because it
might enable wake events and is expecting the system to sleep.  It seems we
need to implement something specifically for this case.  Also, there is the
posibility of resource rebalancing, which requires yet another slightly
different behavior.

Consider if a user wanted to disable a pci bus...  If the bus was just
suspended, it would be straightforward, put all the children to sleep and
then turn off the bus.  However, in the case of disabling it (as in "do not
use me") all of the child devices would actually need to be unregistered.

Furthermore, take an ethernet controller as an example.  When suspending, just
run the driver specific logic.  When disabling, you actually want to unregister
from the net class interface.

Unbinding the driver may not be the solution, because the driver may be
retaining configuration state information lost during the power-down.

"Disabling" is just one possible user preference.  Selective-suspending a
device is another.  For example, if a user was using an ethernet interface on
a laptop, the wireless interface should probably reduce power consumption.
The kernel may be able to take care of this automatically via idle timers etc.

I'm interested in any opinions.  Should we try to support something like
this?  How might we go about it?

As another issue, how should we handle surprise removal between suspend and
resume?  It seems like we would need to tell the resume method about this.

Thanks,
Adam

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

Hi!

> One potentially important aspect of power management is the ability for the
> user to disable a device that he or she does not intend to use.  Our current
> model does not allow for this.  Calling PMSG_SUSPEND won't cut it, because it
> might enable wake events and is expecting the system to sleep.  It seems we
> need to implement something specifically for this case.  Also, there is the
> posibility of resource rebalancing, which requires yet another slightly
> different behavior.
> 
> Consider if a user wanted to disable a pci bus...  If the bus was just
> suspended, it would be straightforward, put all the children to sleep and
> then turn off the bus.  However, in the case of disabling it (as in "do not
> use me") all of the child devices would actually need to be unregistered.

I think you should talk to hotplug people from high-end
machines. "Disable PCI bus" seems very similar to "hey, I want to
unplug that PCI bus". And they have to the ethernet case for
hot-pluggable PCI cards, too.

								Pavel

-- 
Boycott Kodak -- for their patent abuse against Java.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2438 bytes --]

On Sun, 8 May 2005, Adam Belay wrote:

> One potentially important aspect of power management is the ability for the
> user to disable a device that he or she does not intend to use.  Our current
> model does not allow for this.  Calling PMSG_SUSPEND won't cut it, because it
> might enable wake events and is expecting the system to sleep.  It seems we
> need to implement something specifically for this case.  Also, there is the
> posibility of resource rebalancing, which requires yet another slightly
> different behavior.
> 
> Consider if a user wanted to disable a pci bus...  If the bus was just
> suspended, it would be straightforward, put all the children to sleep and
> then turn off the bus.  However, in the case of disabling it (as in "do not
> use me") all of the child devices would actually need to be unregistered.
> 
> Furthermore, take an ethernet controller as an example.  When suspending, just
> run the driver specific logic.  When disabling, you actually want to unregister
> from the net class interface.

You're taking this too far.  "Disable", as in "do not use me", really 
requires nothing more than that the device be suspended (with remote 
wakeup turned off) and that the driver respond to requests with an error.

What you describe is more like "do your best to pretend this device 
doesn't exist at all"!  I don't see any need to unregister anything, 
unload drivers, or take other special action.


> As another issue, how should we handle surprise removal between suspend and
> resume?  It seems like we would need to tell the resume method about this.

I don't know how it should be handled in other subsystems.  With USB, we 
detect the removal at or close to the time when we attempt to resume the 
device.  Of course USB is peculiar, in that the drivers don't bind 
directly to the devices (they bind to interfaces within the devices).  
Hence by the time the drivers' ->resume gets called, there's a good chance 
we already know the device is gone.

But even if we didn't know, it wouldn't matter much.  The driver would
encounter a rash of errors as it tried to communicate with the missing
device, and they would end abruptly when we learned that the device had
been disconnected.

In any case, isn't it up to the bus to detect new devices and removals?  
Why should removal during suspend be treated any differently from removal 
at any other time when the device is not in use?

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 3738 bytes --]

On Mon, May 09, 2005 at 10:26:20AM -0400, Alan Stern wrote:
> On Sun, 8 May 2005, Adam Belay wrote:
> 
> > One potentially important aspect of power management is the ability for the
> > user to disable a device that he or she does not intend to use.  Our current
> > model does not allow for this.  Calling PMSG_SUSPEND won't cut it, because it
> > might enable wake events and is expecting the system to sleep.  It seems we
> > need to implement something specifically for this case.  Also, there is the
> > posibility of resource rebalancing, which requires yet another slightly
> > different behavior.
> > 
> > Consider if a user wanted to disable a pci bus...  If the bus was just
> > suspended, it would be straightforward, put all the children to sleep and
> > then turn off the bus.  However, in the case of disabling it (as in "do not
> > use me") all of the child devices would actually need to be unregistered.
> > 
> > Furthermore, take an ethernet controller as an example.  When suspending, just
> > run the driver specific logic.  When disabling, you actually want to unregister
> > from the net class interface.
> 
> You're taking this too far.  "Disable", as in "do not use me", really 
> requires nothing more than that the device be suspended (with remote 
> wakeup turned off) and that the driver respond to requests with an error.
> 
> What you describe is more like "do your best to pretend this device 
> doesn't exist at all"!  I don't see any need to unregister anything, 
> unload drivers, or take other special action.

Really this is an implementation detail.  The point I was trying to make is
that we don't currently have a way of even suspending devices without wakeup.
However, "pretend this device doesn't exist" seems logical to me, it frees
memory and removes clutter.

> 
> 
> > As another issue, how should we handle surprise removal between suspend and
> > resume?  It seems like we would need to tell the resume method about this.
> 
> I don't know how it should be handled in other subsystems.  With USB, we 
> detect the removal at or close to the time when we attempt to resume the 
> device.  Of course USB is peculiar, in that the drivers don't bind 
> directly to the devices (they bind to interfaces within the devices).  
> Hence by the time the drivers' ->resume gets called, there's a good chance 
> we already know the device is gone.
> 
> But even if we didn't know, it wouldn't matter much.  The driver would
> encounter a rash of errors as it tried to communicate with the missing
> device, and they would end abruptly when we learned that the device had
> been disconnected.

Most drivers aren't this smart, and not every bus will be happy with drivers
tearing through the remains of previously removed hardware.

> 
> In any case, isn't it up to the bus to detect new devices and removals?  
> Why should removal during suspend be treated any differently from removal 
> at any other time when the device is not in use?

It's a very different situation.  Take PCI as an example...  If the device has
been removed while suspended, the goal changes from "restore this device" to
"free up this saved state information and unregister stuff".

Notice how surprise removal is connected and related with manual device
disabling.  We need to have unregistration infustructure anyway, why not
handle device disabling completely?

Also, there is no way to ensure that a removal will not occur during a reduced
power state (dynamic power management) that wasn't invoked by suspend.  So, in
short, hotplug drivers will need to be really robust.  I think the PM
subsystem should try to be helpful here when it can.

Finally, we need to have device resume routines rescan for child devices.

Adam

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]

Hi!

> > > As another issue, how should we handle surprise removal between suspend and
> > > resume?  It seems like we would need to tell the resume method about this.
> > 
> > I don't know how it should be handled in other subsystems.  With USB, we 
> > detect the removal at or close to the time when we attempt to resume the 
> > device.  Of course USB is peculiar, in that the drivers don't bind 
> > directly to the devices (they bind to interfaces within the devices).  
> > Hence by the time the drivers' ->resume gets called, there's a good chance 
> > we already know the device is gone.
> > 
> > But even if we didn't know, it wouldn't matter much.  The driver would
> > encounter a rash of errors as it tried to communicate with the missing
> > device, and they would end abruptly when we learned that the device had
> > been disconnected.
> 
> Most drivers aren't this smart, and not every bus will be happy with drivers
> tearing through the remains of previously removed hardware.
> 

...so fix the drivers. If the device fails, they should handle it. And bus should
handle it, too...
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Sunday 08 May 2005 7:15 pm, Adam Belay wrote:
> 
> One potentially important aspect of power management is the ability for the
> user to disable a device that he or she does not intend to use.  

I tend to agree with Alan on this:  this doesn't seem like something
that should need separate attention.

Though maybe I'm not clear on what you mean by "disable".  How would
that differ from having inactive drivers be in low power modes?

- Dave

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Monday 09 May 2005 8:37 am, Alan Stern wrote:

> As for the remains of previously-removed hardware -- I shouldn't think it 
> matters very much what anybody tries to do to a piece of hardware, once 
> that hardware has been removed from the system!

Depends on the hardware.  Maybe it's a silent failure (as with
CardBus reads returning all ones); or a message passing error that
the driver sees; or maybe the lack of handshake means a bus error
gets generated, and the driver oopses.  That last is unfriendly,
enough so that I think nobody would design a "hotpluggable" bus
where hardware behaves like that.

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1545 bytes --]

There's an issue here that needs to be discussed explicitly.  How finely
should the kernel allow userspace to control runtime power management?

    (A) Do we want userspace to have to make decisions on the lines
	of: Put this device into D2, set that clock frequency to
	1 MHz, set that GPIO line to 0, and so on?

    (B) Or should the kernel export a relatively small set of power 
	domains and a small set of primitives for each domain?  Like:
	suspend, turn off remote wakeup, go to full power, suspend
	after N seconds of inactivity?

(A) means that the kernel provides very transparent access.  On the other
hand, it requires userspace applications to have a tremendous amount of
platform-specific knowledge built in -- knowledge that really belongs only
in the kernel.

(B) seems a lot easier for apps to handle and is closer to what users will
expect to see.  But it does mean that the kernel has to contain mechanisms
for implementing and exporting these power domain abstractions.

In general (A) most resembles what sysfs does right now.  I suspect that 
(B) will be a better solution in the end.

Regarding Dave's comments about hdparm and xset dpms -- what matters most 
about these interfaces is not that they are application-specific but that 
they are ad-hoc.  I don't see why we can't strive to present a much more 
uniform interface, even if it does describe widely varying subsystems.  I 
also don't see anything wrong with implementing this interface by means of 
sysfs instead of using driver-specific ioctls.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On Monday 09 May 2005 11:06 am, Alan Stern wrote:
> There's an issue here that needs to be discussed explicitly.  How finely
> should the kernel allow userspace to control runtime power management?
> 
> ...
>     (B) Or should the kernel export a relatively small set of power 
> 	domains and a small set of primitives for each domain?  Like:
> 	suspend, turn off remote wakeup, go to full power, suspend
> 	after N seconds of inactivity?
> 
> ...
> 
> In general (A) most resembles what sysfs does right now.  I suspect that 
> (B) will be a better solution in the end.

Yes.


> Regarding Dave's comments about hdparm and xset dpms -- what matters most 
> about these interfaces is not that they are application-specific but that 
> they are ad-hoc. 

How does "application-specific" differ from "ad-hoc" though?
In practical terms; one is more pejorative than the other, but
how exactly does one measure a difference?

For example, the kernel doesn't know about X11 protocol at all,
or those particular IDE protocol requests.  And most folk would
probably say that it shouldn't need to ...


> I don't see why we can't strive to present a much more  
> uniform interface, even if it does describe widely varying subsystems.  I 
> also don't see anything wrong with implementing this interface by means of 
> sysfs instead of using driver-specific ioctls.

For new things, or things being generalized into kernel support,
I've no fundamental issue with using sysfs.  But for things that
are widely deployed today, I don't see much point in changing
interfaces.

- Dave

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2430 bytes --]

On Wed, 11 May 2005, David Brownell wrote:

> On Monday 09 May 2005 11:06 am, Alan Stern wrote:
> > There's an issue here that needs to be discussed explicitly.  How finely
> > should the kernel allow userspace to control runtime power management?
> > 
> > ...
> >     (B) Or should the kernel export a relatively small set of power 
> > 	domains and a small set of primitives for each domain?  Like:
> > 	suspend, turn off remote wakeup, go to full power, suspend
> > 	after N seconds of inactivity?
> > 
> > ...
> > 
> > In general (A) most resembles what sysfs does right now.  I suspect that 
> > (B) will be a better solution in the end.
> 
> Yes.

Assuming other people agree, the question becomes: What structures and 
resources does the kernel need in order to implement and export these 
power domains and primitives?


> > Regarding Dave's comments about hdparm and xset dpms -- what matters most 
> > about these interfaces is not that they are application-specific but that 
> > they are ad-hoc. 
> 
> How does "application-specific" differ from "ad-hoc" though?
> In practical terms; one is more pejorative than the other, but
> how exactly does one measure a difference?

"Application-specific" refers to the fact that the interfaces are used (or
are intended to be used) by only one or two applications; the term has
nothing to do with kernel code.  "Ad-hoc" on the other hand describes the
way in which the kernel implements the interfaces.

> For example, the kernel doesn't know about X11 protocol at all,
> or those particular IDE protocol requests.  And most folk would
> probably say that it shouldn't need to ...

Isn't it true that with IDE drives, you tell the drive how long to wait 
before doing an idle spindown?  So the kernel doesn't have to worry about 
keeping track of when the timeout expires; the firmware takes care of it.  
If the kernel _did_ need to keep track of the timeout then it _would_ 
need to understand the IDE protocol for spinning down a disk.

> For new things, or things being generalized into kernel support,
> I've no fundamental issue with using sysfs.  But for things that
> are widely deployed today, I don't see much point in changing
> interfaces.

There's no need to change the existing interfaces.  But we could add new
interfaces so that all devices can be controlled in a uniform way, in
addition to the application-specific ways they are controlled now.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 4028 bytes --]

On Wednesday 11 May 2005 12:10 pm, Alan Stern wrote:
> On Wed, 11 May 2005, David Brownell wrote:
> 
> > On Monday 09 May 2005 11:06 am, Alan Stern wrote:
> > > There's an issue here that needs to be discussed explicitly.  How finely
> > > should the kernel allow userspace to control runtime power management?
> > > 
> > > ...
> > >     (B) Or should the kernel export a relatively small set of power 
> > > 	domains and a small set of primitives for each domain?  Like:
> > > 	suspend, turn off remote wakeup, go to full power, suspend
> > > 	after N seconds of inactivity?
> > > 
> > > ...
> > > 
> > > In general (A) most resembles what sysfs does right now.  I suspect that 
> > > (B) will be a better solution in the end.
> > 
> > Yes.
> 
> Assuming other people agree, the question becomes: What structures and 
> resources does the kernel need in order to implement and export these 
> power domains and primitives?

And for what purposes?  Different purposes tend to need different answers
for those other questions.


> > > Regarding Dave's comments about hdparm and xset dpms -- what matters most 
> > > about these interfaces is not that they are application-specific but that 
> > > they are ad-hoc. 
> > 
> > How does "application-specific" differ from "ad-hoc" though?
> > In practical terms; one is more pejorative than the other, but
> > how exactly does one measure a difference?
> 
> "Application-specific" refers to the fact that the interfaces are used (or
> are intended to be used) by only one or two applications; the term has
> nothing to do with kernel code. 

Actually it does; "application" is a pretty generic term, and
from the hardware perspective, the "application" often includes
things like OS software (which is different in each product).
It's not just different userspace programs or user interfaces.

So for example PM concepts exported through a driver stack can
be "application specific" ... different subsystems may need to
handle them differently, because of different requirements.


> "Ad-hoc" on the other hand describes the 
> way in which the kernel implements the interfaces.

This doesn't enlighten me in terms of objective measures.
Different applications imply different implementations,
and often different interfaces.  X11 is a network
protocol, so 'xset dpms' uses network messages.  But IDE
isn't, so "hdparm" uses IDE messages.


> > For example, the kernel doesn't know about X11 protocol at all,
> > or those particular IDE protocol requests.  And most folk would
> > probably say that it shouldn't need to ...
> 
> Isn't it true that with IDE drives, you tell the drive how long to wait 
> before doing an idle spindown?  So the kernel doesn't have to worry about 
> keeping track of when the timeout expires; the firmware takes care of it.  
> If the kernel _did_ need to keep track of the timeout then it _would_ 
> need to understand the IDE protocol for spinning down a disk.

That's my point.  The application in this case is "everything
accessing the IDE drive" and it involves both kernel components
(block driver) and userspace ones ("hdparm").  The IDE disk sure
can't tell the difference in where a request came from!

It's a good point that the firmware itself is another software
component.  In this case it's one with a standardized interface
to setting that spindown timer:  IDE messages, no driver model.


> > For new things, or things being generalized into kernel support,
> > I've no fundamental issue with using sysfs.  But for things that
> > are widely deployed today, I don't see much point in changing
> > interfaces.
> 
> There's no need to change the existing interfaces.  But we could add new
> interfaces so that all devices can be controlled in a uniform way, in
> addition to the application-specific ways they are controlled now.

There are lots of things we could do, yes.  Whether we should, or not,
is a question worth answering.  What's the benefit of a "more uniform"
way to do things?  Is there some problem being solved?

- Dave
 

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] Disabling Devices

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4120 bytes --]

On Fri, 13 May 2005, David Brownell wrote:

> > "Application-specific" refers to the fact that the interfaces are used (or
> > are intended to be used) by only one or two applications; the term has
> > nothing to do with kernel code. 
> 
> Actually it does; "application" is a pretty generic term, and
> from the hardware perspective, the "application" often includes
> things like OS software (which is different in each product).
> It's not just different userspace programs or user interfaces.

That's true, but I'm interested in doing Linux kernel development.  Hence 
I use the OS's perspective, according to which an application is a user 
program.

> > "Ad-hoc" on the other hand describes the 
> > way in which the kernel implements the interfaces.
> 
> This doesn't enlighten me in terms of objective measures.
> Different applications imply different implementations,
> and often different interfaces.  X11 is a network
> protocol, so 'xset dpms' uses network messages.  But IDE
> isn't, so "hdparm" uses IDE messages.

You're mixing things up here.  Sure the xset program uses X protocol
messages over a network.  But the X server then carries out the display
power management request either by calling through some OS interface or by
writing directly to the hardware (actually I don't know which).  
Likewise, hdparm doesn't send IDE messages directly to the hardware -- it
uses ioctl to ask the kernel to send the messages for it.  The ioctl and
related kernel interfaces are the ad-hoc ones.

(Surely you can't argue with that!  ioctl is notorious for being ad-hoc.)

> That's my point.  The application in this case is "everything
> accessing the IDE drive" and it involves both kernel components
> (block driver) and userspace ones ("hdparm").  The IDE disk sure
> can't tell the difference in where a request came from!

I disagree.  The application in this case is hdparm.  The kernel is 
separate from the application.  If my viewpoint differs from yours it's 
because I'm working on the Linux kernel, not on disk drive development!

> It's a good point that the firmware itself is another software
> component.  In this case it's one with a standardized interface
> to setting that spindown timer:  IDE messages, no driver model.

True again, but the firmware isn't an application.  And in general we
don't want to have applications talking directly to the firmware; we want
them to talk to device drivers, which means involving the driver model.

(To be honest, I really dislike this use of the word "application".  It's 
short for "application program", which implies some sort of distinction: 
application program vs. utility program vs. system-management program vs. 
program-development program vs...  From the kernel's point of view there's 
just user programs, no more and no less.  Equally detestable is the use 
of "folder" to mean "directory".  Is Apple to blame for all of this?)


> > There's no need to change the existing interfaces.  But we could add new
> > interfaces so that all devices can be controlled in a uniform way, in
> > addition to the application-specific ways they are controlled now.
> 
> There are lots of things we could do, yes.  Whether we should, or not,
> is a question worth answering.  What's the benefit of a "more uniform"
> way to do things?  Is there some problem being solved?

The benefit is for people who write the userspace programs for doing power 
management.  It makes their life much easier if they have a uniform way of 
knowing what power domains are available, what operations are available 
for each domain, and how those operations are carried out.

If you're only concerned about managing a couple of different kinds of 
subsystem (like the display and the IDE drives), then yes, it's okay for 
each to have its own idiosyncratic way of doing things.  For a more 
generalized setting this is something to avoid.

It might even make life easier for kernel programmers to have a single 
unified framework for doing power management.  This doesn't have to mean 
that every driver does exactly the same things as every other driver.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]