On Mon, 24 Sep 2007, Blair Sadewitz wrote:
> While reading the OpenBSD commit log for
> sys/dev/pci/azalia.c, I noticed this:
>
>  In a drivers activate() entry point, if on
>  DVACT_DEACTIVATE it does something, then it MUST
>  return zero on DVACT_ACTIVATE, not EOPNOTSUPP;
>  this very popular bug has been cut and pasted a
>  lot of times...
>
> Does NetBSD follow the same convention?

looking at subr_autoconf.c, it would seem that we do since the deactivate
call is not made unless the device is marked active, which it is not when
DVACT_ACTIVATE returns an error.

seems that this bug is popular here too..  driver(9) could be clearer,
does the below look good?

iain

--- /usr/src/share/man/man9/driver.9	2007-09-05 22:22:31.000000000 +0100
+++ driver.9	2007-10-01 11:12:59.000000000 +0100
@@ -297,7 +297,7 @@
 do not print a notice
 .Pc .
 .Pp
-The autoconfiguration framework calls the driver's activate function
+The autoconfiguration framework may call the driver's activate function
 to notify the driver of a change in the resources that have been
 allocated to it.
 For example, an Ethernet driver has to be notified if the network stack
@@ -318,6 +318,8 @@
 .Pc .
 If the action is not supported the activate function should return
 EOPNOTSUPP.
+The DVACT_DEACTIVATE call will only be made if the DVACT_ACTIVATE call
+was successful.
 The activate function is called in interrupt context.
 .Pp
 Most drivers will want to make use of interrupt facilities.