svn commit: r278320 - in head: contrib/mdocml lib lib/libdevctl share/mk sys/dev/acpica sys/dev/pci sys/kern sys/sys usr.sbin usr.sbin/devctl

[John-Mark Gurney]

John Baldwin wrote this message on Fri, Feb 06, 2015 at 11:58 -0500:
> On Friday, February 06, 2015 04:09:02 PM John Baldwin wrote:
> > Author: jhb
> > Date: Fri Feb  6 16:09:01 2015
> > New Revision: 278320
> > URL: https://svnweb.freebsd.org/changeset/base/278320
> > 
> > Log:
> >   Add a new device control utility for new-bus devices called devctl.  This
> >   allows the user to request administrative changes to individual devices
> >   such as attach or detaching drivers or disabling and re-enabling devices.
> 
> For now I would consider this somewhat experimental.  Some bus drivers may not
> take kindly to device_detach/device_probe_and_attach being called (Hans 
> mentioned USB as a likely candidate).
> 
> Also, in theory you can use 'devctl suspend' to power off PCI devices you 
> don't need, but most drivers probably don't expect to have to deal with user 
> requests while suspended (e.g. I tested this by suspending hdac0 on a laptop, 
> but I didn't try playing a sound to see if that blew up.. it would not 
> surprise me if it did).
> 
> There are also some other rough edges such as: 
> 
>   1) An administratively suspended device will resume if you do a system-wide
>      suspend and resume.

Could we add a flag for this?

>   2) There is no nice way for a driver to reject an administrative suspend
>      request.  It could fail its device_suspend method perhaps, but the driver
>      can't easily tell if a suspend request is administrative or due to a
>      system suspend.  Perhaps we could re-use device_quiesce for this?

We should look at expanding this... For the PCIe hot plug work, we
definately want administrative suspention to work so that people can
unplug their devices, or get notification that it is rejected (say,
disk is still mounted)...

Also, looks like quiesce will be rejected if the device is busy...
That should be changed or at least clearer description of what
device_busy is suppose to do to a device...

The good news is that very few drivers make use of device_busy, so
cleaning it up, or removing it won't be too hard...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."