diff options
| author | Samuel Ortiz <sameo@linux.intel.com> | 2013-04-09 01:51:38 +0300 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2013-04-08 16:57:15 -0700 |
| commit | e46980a10a76ec3282dd6832c1974b880acd23d3 (patch) | |
| tree | 42d8e5abab5991b4026af385545e23af619f610b /Documentation/misc-devices | |
| parent | d6c36a475fccfca05fd05362c98e49f6dd07721c (diff) | |
| download | lwn-e46980a10a76ec3282dd6832c1974b880acd23d3.tar.gz lwn-e46980a10a76ec3282dd6832c1974b880acd23d3.zip | |
mei: bus: Add device enabling and disabling API
It should be left to the drivers to enable and disable the device on the
MEI bus when e.g getting probed.
For drivers to be able to safely call the enable and disable hooks, the
mei_cl_ops must be set before it's probed and thus this should happen
before registering the device on the MEI bus. Hence the mei_cl_add_device()
prototype change.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation/misc-devices')
| -rw-r--r-- | Documentation/misc-devices/mei/mei-client-bus.txt | 7 |
1 files changed, 5 insertions, 2 deletions
diff --git a/Documentation/misc-devices/mei/mei-client-bus.txt b/Documentation/misc-devices/mei/mei-client-bus.txt index 9dc5ebf94eb1..f83910a8ce76 100644 --- a/Documentation/misc-devices/mei/mei-client-bus.txt +++ b/Documentation/misc-devices/mei/mei-client-bus.txt @@ -104,13 +104,16 @@ int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id) struct contact_driver *contact; [...] + mei_cl_enable_device(dev); + mei_cl_register_event_cb(dev, contact_event_cb, contact); return 0; } -In the probe routine the driver basically registers an ME bus event handler -which is as close as it can get to registering a threaded IRQ handler. +In the probe routine the driver first enable the MEI device and then registers +an ME bus event handler which is as close as it can get to registering a +threaded IRQ handler. The handler implementation will typically call some I/O routine depending on the pending events: |