mfd: compile fix for twl4030 renaming
[linux-3.10.git] / Documentation / keys-request-key.txt
index c1f64fd..09b55e4 100644 (file)
@@ -11,15 +11,31 @@ request_key*():
 
        struct key *request_key(const struct key_type *type,
                                const char *description,
-                               const char *callout_string);
+                               const char *callout_info);
 
 or:
 
        struct key *request_key_with_auxdata(const struct key_type *type,
                                             const char *description,
-                                            const char *callout_string,
+                                            const char *callout_info,
+                                            size_t callout_len,
                                             void *aux);
 
+or:
+
+       struct key *request_key_async(const struct key_type *type,
+                                     const char *description,
+                                     const char *callout_info,
+                                     size_t callout_len);
+
+or:
+
+       struct key *request_key_async_with_auxdata(const struct key_type *type,
+                                                  const char *description,
+                                                  const char *callout_info,
+                                                  size_t callout_len,
+                                                  void *aux);
+
 Or by userspace invoking the request_key system call:
 
        key_serial_t request_key(const char *type,
@@ -32,10 +48,14 @@ does not need to link the key to a keyring to prevent it from being immediately
 destroyed.  The kernel interface returns a pointer directly to the key, and
 it's up to the caller to destroy the key.
 
-The request_key_with_auxdata() call is like the in-kernel request_key() call,
-except that it permits auxiliary data to be passed to the upcaller (the default
-is NULL).  This is only useful for those key types that define their own upcall
-mechanism rather than using /sbin/request-key.
+The request_key*_with_auxdata() calls are like the in-kernel request_key*()
+calls, except that they permit auxiliary data to be passed to the upcaller (the
+default is NULL).  This is only useful for those key types that define their
+own upcall mechanism rather than using /sbin/request-key.
+
+The two async in-kernel calls may return keys that are still in the process of
+being constructed.  The two non-async ones will wait for construction to
+complete first.
 
 The userspace interface links the key to a keyring associated with the process
 to prevent the key from going away, and returns the serial number of the key to