Changes between Version 15 and Version 16 of DeviceDrivers


Ignore:
Timestamp:
2011-11-14T21:10:04Z (13 years ago)
Author:
Jiri Svoboda
Comment:

dev_add, dev_remove, dev_gone

Legend:

Unmodified
Added
Removed
Modified
  • DeviceDrivers

    v15 v16  
    6868 * driver_t
    6969 * driver_ops_t
    70    * add_device (rename to dev_add)
     70   * dev_add
    7171   * dev_remove
    7272   * dev_gone
     
    7474   * fun_offline
    7575 * ddf_dev_ops_t
     76
     77Every driver must define a ''driver_t'' structure which links to a ''driver_ops_t'' structure.
     78''driver_ops_t'' fields point to various driver entry points. ''dev_add'' is necessary in order
     79for the driver to work. ''dev_remove'', ''dev_gone'', ''fun_online'', ''fun_offline'' are required
     80in order for the driver to support hot unplug (all drivers should support hot unplug).
     81
     82=== Driver Entry Points (driver_opts_t) ===
     83==== dev_add ====
     84{{{
     85int (*dev_add)(ddf_dev_t *dev)
     86}}}
     87This entry point is called by DDF to ask the driver to take ownership of a new device. The driver
     88should probe the device to verify that it is there and operational. If not, it should return failure.
     89If the device is operational, the driver should take ownership and return EOK. The driver should
     90also allocate soft state and create functions to expose functionality of the device (in case of bus driver
     91some of these will correspond to devices currently connected to the bus).
     92
     93It is up to the driver to which extent it wants to perform these initialization steps
     94before or after returning from ''dev_add''. This entry point is mandatory, it must always be implemented.
     95
     96==== dev_remove ====
     97{{{
     98int (*dev_remove)(ddf_dev_t *dev)
     99}}}
     100This entry point is called by DDF to ask the driver to gracefully give up ownership of a device. The driver
     101should gracefully terminate any pending operations on the device, quiesce the device and return it
     102to some suitable, clean state (from which it could be picked up by ''dev_add'', for example).
     103
     104The driver must unbind all functions belonging to this device and it should also clean up any
     105software state associated with the device. If this entry point is not implemented, it should
     106be either set to NULL or it should always return ENOTSUP.
     107
     108==== dev_gone ====
     109{{{
     110int (*dev_gone)(ddf_dev_t *dev)
     111}}}
     112This entry point is called by DDF to inform the driver that connectivity to a device has been lost
     113(e.g. because the device has been physically unplugged). The driver must coordinate with its parent
     114to terminate any pending operations on the device. The parent will normally not allow any new operations
     115to be started and, possibly, it will abort all outstanding operations (or wait for the driver to
     116abort them).
     117
     118The driver must unbind all functions belonging to this device and it should also clean up any
     119software state associated with the device. If this entry point is not implemented, it should
     120be either set to NULL or it should always return ENOTSUP.
    76121
    77122== Device and Function Life Cycle ==